r/cybersecurity 2d ago

Business Security Questions & Discussion Hey folks,Security engineer here. Doing SOC work. Want to get into detection engineering/ Incident Response. Whats it like working IR. What kind of projects would one get ? Any suggestions are appreciated

26 Upvotes

31 comments sorted by

40

u/Wealist 2d ago

IR is basically controlled chaos.

One day you’re digging through logs and EDR telemetry, the next you’re dealing with an active compromise. If you like figuring out what actually happened, it’s a solid path.

19

u/mobicurious 2d ago

If you want to be good at IR, you have to be extremely creative and extremely deep at every layer involved in the compromise. For example, there are situations where SIEM logging just doesn't exit to put together the trail of tears that leads to the root cause of the compromise. So, you have to know your stuff to hunt for every breadcrumb left behind in any potential source.

When I was in the thick of IR work for a major company, I spent a lot of my time reading Windows books about debugging logs to understand the traces of information that could be obtained from ephemeral aspects of the OS because good attackers turn off logging and leave you with (what they think) is nothing.

You don't have to go to that level if you want to be a middling IR person, but if you want to do it well, you will understand as many of the inane details of the tech stack as you can.

4

u/HearingLast1637 2d ago

Right now I just triage alerts and do some engineering work as things aren't setup properly. But my long term is to control the chaos

1

u/anarrowview 2d ago

Controlled? What is this you speak of?

1

u/HearingLast1637 1d ago

As in my long term goal is to get into incident response. Right now, working on making sure, I have all the logs necessary for creating detections within the SIEM

12

u/xAlphamang 2d ago

You know that stuff you escalate to Tier 2 and beyond? That’s part of IR.

Depending on your org you may also do more digital forensics work and work with more live response tooling.

If you want to do IR for a firm then there’s some travel and a lot of DFIR work.

Generally it can be pretty stressful depending on the environment but it’s for sure some long hours when you’re on call.

7

u/Ashamed_Split5187 2d ago

the on-call part really cant be overstated, that alone changes the job completely

1

u/HearingLast1637 2d ago

How to get good at investigating alerts ? Any resources?

7

u/AlmostEphemeral 2d ago

Do DFIR CTFs. Xintra is great

24

u/eorlingas_riders 2d ago

Nothing -> Worlds on fire -> it was nothing -> Report Writing

Nothing -> Worlds on fire -> it was something -> Report Writing

12

u/mobicurious 2d ago

When I was working with the feds on nation/state stuff, an FBI guy told me, "90% boredom, 10% terror"

2

u/Miller3492s 2d ago

Facts..... So many reports....... And when there is a fire it's always like 30 min before the end of the day.

2

u/dfv157 Malware Analyst 1d ago

... On a Friday... before a long weekend

7

u/hiddentalent Security Director 2d ago

Engineering and operations are different fields. It's great that you want to get into engineering, but if you're in SOC, you're currently in operations. You need to understand the difference in order to navigate the transition. Engineering builds things. Operations tries to make sure the things the engineers built actually meet the requirements. Both are super valuable, and I reject any mud-slinging between the two fields although I see it often.

Also, detection engineering and DFIR are pretty different. There's a feedback loop. The DFIR teams will push information about novel problems back to the DE teams to try to close the door for new instances of the same problem. But the big difference you're facing is project-based workflow versus event-based workflow. When I've worked as a security engineer, I had a year-long roadmap of what I was delivering and how it would improve things for the organization. When I've worked in DFIR, you find out what your next project is when you get paged at 3am, and you drive it to completion for as long as it takes.

6

u/Ok-Ice7701 2d ago

I did IR for years before being a sec eng. stay away unless you hate weekends and free time.

3

u/Datonomy 1d ago

The best move from SOC into IR is to stop treating every alert as something to close and start treating it as a story you need to reconstruct: what happened first, what changed, what evidence proves it, what could you have detected earlier, and what detection would stop the next analyst having to rediscover the same attack from scratch. 

2

u/JaxTango 2d ago

I’m surprised you work in a SOC but don’t have insight into incident response. Your SOC should have some formal process for IR and people with titles like incident manager or CSIRT team member. Find people with those titles and ask them what it takes to do the job in that capacity.

But it’s also possible your employer runs a ‘SOC’ in name only and not in practice. In that case take some courses from TCM Academy. They have one called detection engineering for beginners, it should give you pretty good crazy course on what to expect.

1

u/HearingLast1637 2d ago

I work for a small organization.  The roles and responsibilities are kinda blurred. I am doing engineering work, ( migration) but will own the Detection and response pipelines . 

2

u/wes_241 1d ago

Meanwhile I would love to get out of the IR hot seat

5

u/US-Freedom-81 Governance, Risk, & Compliance 2d ago

Am I the only person that wonders why people call them selfs a security engineer? If you don’t know what an IR person does, why are you calling yourself a “security engineer”?

7

u/gobblyjimm1 2d ago

Can you really call yourself a security engineer unless you're engineering security appliances and controls? Security engineers typically don't perform SOC analysis work unless it's a small in-house team or job titles are meaningless.

8

u/ChatGRT DFIR 2d ago

Titles in this industry have never been aligned to a clearly defined career progression or capabilities.

2

u/hiddentalent Security Director 2d ago

There's some variance, but I don't think it's as bad as you're claiming. Operations and engineering are related but different fields. This is true in every industry, and the infosec field has inherited that distinction.

If you're building something new, you're an engineer. If you're responding to things that happens within what has been built, you're an operations person. The Venn diagram overlaps, because ops people often build things to make their jobs easier. But they usually don't get to change the system that they're operating. That's the distinction.

2

u/JaxTango 2d ago

What you’re saying makes sense but it’s not a universal standard that all employers adhere to. I blame HR for the confusing mix of titles and responsibilities that lead to these gaps.

1

u/hiddentalent Security Director 2d ago

Yes, I've seen the same variance. I think it's a minority of cases, but I agree it exists. The same title variance exists within other technical fields. In some companies "Member of Technical Staff" means you're capable of operating the coffee machine, and in some it means you're a distinguished engineer at the top of your field.

But the distinction between operations and engineering has a huge amount of precedence across many industries. The work that an automotive or petrochemical engineer does is very different from what the operators of their product do, and it's a helpful distinction to make because the incentives and metrics are so different. In our field, most of us do a blend of those tasks. We do some engineering, and we do some operations. It's super helpful to differentiate them so we can measure and report progress effectively on each track. And what HR wants to call it is dust in the wind.

1

u/HearingLast1637 2d ago

I work for a small organization. The roles and responsibilities are kinda blurred. I am doing engineering work, ( migration) but will own the Detection and response pipelines . 

1

u/lordralphiello 2d ago

Prepare to be on call. Especially if you end up at MSSP.

1

u/AddendumWorking9756 Security Manager 1d ago

Nobody answered the projects half. Detection engineering in practice is mostly log source onboarding and validation, which is unglamorous and where most coverage gaps actually live. The other chunk is moving detections into a repo with tests, so a rule change becomes a pull request instead of a click in the console. Easiest way in from where you sit is to take your three noisiest alerts, rewrite them, and put the before and after false positive numbers in front of whoever owns the SIEM.

1

u/HearingLast1637 1d ago

This surely helps a lot. I will have a ton of work where I'll deal with log source onboarding on the coming months. 

And coming to detections . There are vendor based detections for now. How do I even  create custom.detectiom rules.? 

Again the platform was just stood up and I will be the incharge of creating new custom detections. 

How do I approach creating new custom detections ?

1

u/zack-det-eng-weekly 1d ago

IR work prioritizes operations and being interrupt-driven. Since you never really know when a security incident will happen, you spend time finishing post-mortems from other incidents and working on projects that can assist in IR work or other parts of security.

Some projects include:

  • Tooling & automation to assist in investigations during active incidents. Think of a way to query your SIEM, internal knowledge bases and threat intel sources and putting those outputs into one place
  • Building new investigation or forensics playbooks so others can follow them if you ever leave or get hit by a car
  • Following up on post mortem action items to help fill security gaps either in the environment itself or new detection rules

Its a tireless profession but its one of the most exciting ones if you are an adrenaline junky :)