Cyber Security Incident Response — How to use Assumptions and Believes to drive your Investigation

A more negative title I was thinking of using 😒

If you use assumptions and believes in Cyber Security Incident Response to make decisions you have failed

Security Incident Response Basics

Most Incident Responders or SOC people are aware of the standard cyber security (or information security) incident response process.

Normally the process follow the basic premise:

1. Prepare and Plan
2. Detect and Analyses (triage); for example an alarm triggers in your SIEM and the SOC analysts needs to asses if this is a true positive and other indicators of compromise
3. Contain the threat
4. Eradicate and Recover from the threat
5. Post Incident Review and Lessons learned

There are plenty of posts and articles about this and many Cyber Security courses hammer this home and I won’t go into any details here.

However, I keep seeing a basic (human) logical flaw in the Detect and Analyses phase more often then I would like to admin which will either result in no Security Incident or the wrong containment and eradication and recovery actions.

The Problem — To believe is not To know

I keep seeing that during the detection & analyses phase some (often inexperienced) SOC members and Incident Responders confuse facts and believes (or assumptions) which then leads to no fact finding nor a proper analysis of a (potentially) detected threat.

The main job of a SOC analyst is to understand and analyses the situation and then to take the necessary actions to contain a threat with the Incident Response team (if separate).

Believing that A is true and not knowing can lead to a cyber security disaster.

The Solution

Use assumptions or believes to drive your analysis or incident response actions. Lets see how we can use this.

Understanding & Definitions

First understand these three little words.

• A fact is by definition “a thing that is indisputable the case”
• An assumption “a thing that is accepted as true or certain to happen without proof”.
• A believe “is to think (!not know!) that you know something is true, correct, or real.”

Simple, right? That I believe something does not make it a fact and truth.

Knowing and having proof (often) is a fact.

Basic logical flow of analysis

The though process or flow during the detect and analyses phase, and often during the later stages also, should always be something along the lines of:

• I don’t know -> What do I need to do to know and find out -> I know
• I believe something -> I need to proof or disproof it -> Questions -> Answers -> I know
• Assumption -> Questions -> Research/Analysis -> Answers

Obviously sometimes you cannot proof something or you don’t technically know how to verify or analyses something. Or ever worse you don’t know what questions to ask. If this happens you hopefully have a team to support you (and sometimes google is your friend).

Analysis Flow and Documentation

1. Use assumptions/believes to drive your investigation! For example we assume a computer is compromised -> what question do we need to ask and what answers/facts can we obtain to answer the questions to get ‘facts’
2. Document your questions against any assumptions/believes (1)
3. Take action on these questions (2) and get the answers
4. Document the answers from the questions (3)

Sometimes 4 leads to 1 again and sometimes you have multiple assumptions.

This flow can also become a long loop and if you document (which you should) steps 1 to 4 you can end up very a very long list of items for said steps.

If you have ever gone from the initial assumption “we have what looks like malicious activity by a human threat actor on this endpoint” to the much later in an investigation the assumption and question “we believe our Active Directory domain is compromised; how can we find out?” you can have hundreds of steps🥳

Document items 1 to 4 in a structured way and build a list of facts; management loves facts. But also document any assumptions you cannot verify (or the questions to answer) for whatever reasons. For example dependency on other team/group and waiting for feedback, technically not verifiable questions as X occurred months ago and we have no data to verify this assumption. Etc. etc.

This way you can quickly refer to your documentation/notes and look at what facts you have, what assumptions you have and what questions or things need to be looked at to answer said questions to drive your analysis/investigation/incident forward.

Assumptions should drive the investigation forward, just don’t make assumptions facts.

Believes are a fickle thing and should not really exist at all if it can be avoided but this is why you document believes and assumption as in their own “box” and not as facts.

Small pro IR tip: date and time the above items for each item and if necessary document who is working on what (if multiple people or teams are involved) and when you expect a reply/answer/output. If you do have a proper Incident and somebody asks why did you not do action X straight away you can say at this point in time we didn’t know this fact yet but asked the question and only 1 day later did we know said information from person Y and only then could we take action X. Good Incident Response and Forensic (process) courses teach you this also.

Examples of the Flow

Here is some examples of the analysis flow but not the documentation of assumptions questions and facts.

• “I believe this alarm in the SIEM is a false positive; let me close this ticket/alarm”.

I call this the totally wrong way to work and my smack head against table example 😩.

You might assume this is a false positive, but how did you come to that conclusion and what questions and steps did you take to verify this?

If anything the statement should look like “I know this is a false positive and I took steps X Y and have facts Z that this is a false positive”.

• The source code leaker

You get contacted by somebody in your company and they say:

“This person on this Internet forum is an employee of ours and works on project Y (top secret) and talks about his project and posted partial source code to show his amazing coding skills. Help data leakage and trade secret disclosure, fire him.”

Not the most cyber security incident but a good example.

So this sounds like a lot of facts but are they? At a maximum you assume the above is correct after looking at the forum posts because the code looks real and the project name you know exists and the employee names also exists. However do your communicate to your management the above as fact or an assumption? Should you even go to management or the next level up in your organization with such an assumption? No!

You know nothing yet and need to investigate to make assumptions facts.

• Does this employee work on this project?
• Is this code from the project?
• Does the employee or other employees access this forum from work computers at the time the forum post(s?) are made?
• Does the forum username use a real name (which could be setup by somebody else) or is it an alias? Is the alias used somewhere else?
• Etc.

Facts -> collect them and bundle them up into “here is what we know for sure” and “here are my assumptions”. Once you cannot collect any more facts you can take the investigation to the next level (ok this somewhat depends on the potential severity and your organizations normal Incident Response plans).

• The hacked server

“The server is popped cause our anti-malware solution triggered an alarm as it detected a hacking tool in memory; lets isolate it from the network and inform senior management and then take the next steps in the response process”.

So you get an alert in your SIEM; saw a hacking tool was detected on a server that host a business critical application (cause the SIEM says so). You create a ticket and write the above into the ticket and inform the next level up in your SOC center to start the containment phase.

Does this sound right? It gets rather embarrassing for the Security department if it turns out the server sits in the development area and the developers decided to open pen-testing documentation (which lands in memory) to harden the server and application against know security exploits and the malware tool basic matching triggered on documentation open in notepad.

So how do you make sure this does not happen? You ask the right questions again! And this time around I think you get the process and what some of the questions should be to drive the analysis / investigation 🥳

Summary

• If you make Incident Response/Analytics decisions based on believes or assumptions you are doing it wrong. Stop this.
• Use assumptions to ask questions (often for analysis) to get answers (facts)
• Document and maintain the assumptions, questions and facts against a timeline and have an overall ‘here is what we know’ facts overview
• Assumptions should drive the investigation forward, just don’t make assumptions facts
• If you don’t know how to ask the right questions -> ask and learn

Conclusion

I am not the natural born writer but hope this makes my thoughts somewhat understandable to everybody and helps you out in your job.

I think I will write another post soon on the last bullet point in the summary items but how to fix the issue of ‘I am junior, I don’t know’ from a technical perspective is a real challenge.