When I started in infosec, I realized that I had absolutely no clue how to “investigate”. Think about how many folks out there are working in cybersecurity roles but never received training on how to investigate something. Most of the time we tend to “jump in” until something sticks out to us, but that makes it hard to believe you looked at everything you need to. Not to mention that method leads to intense burnout since you never give yourself a point to stop if you never find anything worthwhile. I’m going to go over my phased approach to investigations with a focus around DFIR, but intended for anyone working in infosec or even IT.

Investigation Framework

• Incident Scoping
• Evidence Collection
• Analysis
• Correlation
• Timeline Analysis
• Intelligence Correlation
• Reporting

Incident Scoping

Often the most overlooked aspect of an investigation is understanding what the hell you’re even dealing with. Scoping an incident may sometimes seem like a waste of time, I mean you can’t know what you don’t know right? Well… you can, if you ask the right questions and take some time to assess what’s going on before “jumping in”. So how do you scope an incident?

There are two primary goals when scoping an incident:

• Determine if the event should be considered an incident.
• Understanding the incident and what needs to be done.

What is an incident? Really?

When you hear the alarms go off, it’s tough to remember it might be a false alarm. The worst feeling is spending hours on end investigating only to find the whole issue was the CFO using an “approved” custom Excel macro. You always want to check early whether it’s truly an incident.

Even better, establish criteria for your organization to deem something an incident. Ask yourself what exactly constitutes a “critical” level incident in your organization? Systems impacted? Users impacted? Or even the type of data which was affected? You might be thinking where I can possibly store all this information, the answer an Incident Response Plan.

Whatever the criteria, make sure you can answer the question, is this an incident?

Prepare For the Interview

Interview?? You already got the job what are you interviewing for? Not a job interview, silly. When you know an incident is going on, someone either brought the detection to you or you found it yourself. If you want an idea of when this stage is happening, it’s probably when you said, “Uh oh”.

Sometimes we see an alert, suspicious event or receive a weird ticket and immediately start investigating to see what’s going on. Before you start you should always take a second and ask yourself or whoever is reporting the issue a few questions. As soon as you say “Uh oh” try to do the following:

1. Get contact information for the person reporting the incident (if it’s not you)
2. Let them know right away that you may have some follow up questions soon
3. Grab a friend to make sure you both believe this could be an incident
4. Shackle that friend to you. You do not want to investigate alone!
5. Reach out to the incident reporter and start asking questions
   • Or if you discovered it, answer these questions based on your knowledge

I will stress this again if you can, DO NOT GO ALONE! Investigating solo may sound cool but it’s incredibly stressful and you will get burnt out quick. Apologies for the one-person security teams out there but I urge you try your best to get someone to assist.

With at least two people, you want to have one person asking questions and the other taking notes. It’s near impossible to write/type everything so having someone act as a scribe will let you focus on asking good questions and keep a record of everything you’ve learned.

What questions do you ask? Well, I’ve already started that for you, here you can find a link to my SCOPING TEMPLATE. This is a series of questions to ask about the incident to get as much detail as possible. It’s not perfect but it will give you a head start and make sure you don’t miss any obvious questions. Generally, you want to cover these points:

• Summary of the incident
• Details about the affected hosts/users
• Timestamps of key events
• Details around the detection
• Objectives (what do they want done)

Asking the Right Questions

So, now you know this is truly an incident. Cool, time to panic! Except you read a great blog post talking about how to scope an incident, so you came prepared.

The first question I like to always start with is “Describe the incident to me?”. It may seem counterproductive and too open ended, but I’ve learned a very important thing after being a part of so many incidents.

Whatever the first question you ask is, the person responding will start telling you EVERYTHING about the incident.

Keep in mind, you are talking to a human being. Whoever this is, they are probably a bit panicked or want to get this off their plate. So, understand that you need to let them dump some information and let the scribe take as many notes as they can. I call this the BLURT PHASE. It will be messy, but that’s why you have your questions already written down so you can go through your process at your own pace once they’ve blurted a bit.

In addition, try to empathize. If this is truly an incident, this could be the worst day of their career. If you can keep a calm voice and present a solid plan, everyone will feel better. Even if you are just the SOC analyst, this is your time to shine and show your skill.

Once you’ve moved past the BLURT PHASE, it’s time to ask direct questions that do not leave any room for misinterpretation. Again, refer to my template to have a good starting spot. Remember to keep your audience in mind, the finance director may not know what the workstation IP is, but the IT folks might. Don’t be afraid to ask these questions in an open forum, war rooms may be spun up for incidents so it might be a great time to bring up some of these points.

Meeting of the Minds

I will urge any team of investigators to meet after you’ve collected all your information for scoping. Whether it’s a CSIRT, security team or concerned sysadmins take some time to compare notes and make sure everyone is on the same page in terms of what the incident is.

At this point you should also select an Incident Lead, Commander, General or whatever you want to call it. Someone to oversee the incident and make sure tasks are accomplished, they would also serve as the point of contact (POC) for the incident. This role typically goes to a SOC manager, SOC lead, Security Manager or anyone who understands the technical analysis but may not be “in the weeds” every day.

From there, the following steps NEED to be accomplished before ending this meeting:

• Determine what evidence sources are available to further investigate
• Confirm what are the objectives for the organization
• Make sure everyone in the room knows what their next task is
• Establish the next time you will meet (4 hours? Before lunch? End of the day?)

These steps are crucial to ensure everyone can move into the next phase of investigation. If you don’t discuss evidence sources, folks won’t know where to look. If objectives aren’t clear, someone may waste a ton of time chasing down information that isn’t relevant. If everyone doesn’t have a task assigned, they may just sit at their desk waiting for someone to tell them what to do. Finally, if you don’t give a timeframe on when to meet next, folks will run down the rabbit hole and not update findings in a timely manner. It also gives your team a small break, so they know when to pause what they are working on.

Now it’s time to start moving into the investigation, next I will cover Evidence Collection. I hope this gives some perspective on how to handle scoping an investigation. No one really teaches you this stuff, so I hope it helps you get you a tiny bit more prepared.

Twitter: @CyberCoat

DFIR Documentation Templates: https://github.com/chocolatecoat/DFIR-Templates