Before you jump into action when a security alrm sounds, you need to first assess what happened. Pulling together the details of the event will help you determine if there is a real security incident, and if so, how you will need to respond.
But often in the frenzy of security alerts, we get caught up in processes or start jumping to conclusions without enough info. This can lead to a haphazard incident response.
From my experience, there's a simpler way; one that is efficienct, not bogged down by unnecessary processes, and easy for organizations of all sizes to follow.
The 3-Step Security Event Triage Process
Security teams often follow linear triaging processes where one system or artifact is investigated at a time. But, as we’ve talked about before, linear processes can be dangerous. If you only work from a list of predefined tasks, you can easily miss key pieces of information.
For example, if the assumption is that an attacker went after a high-priority application server and you follow a process to apply protective defenses to that server, you may miss a critical indicator that the threat, in fact, entered through a low-priority R&D workstation.
Linear thinking may overlook the pivot path of an attacker. So instead, we as defenders need to reverse-engineer the triage process. Think of it like debugging or troubleshooting, but for security incidents, and use these three steps:
Step 1: Identify
Begin by identifying artifacts of the incident. Here, you’ll be looking for the highest value targets in the attack so you can prioritize your response accordingly. Step 1 includes tasks such as network security monitoring and performing deeper investigations.
Let’s say you were dealing with a potential malware threat. Step one would be to identify how the malware entered the network and which system(s) it infected. Some types of malware can spread quickly — both internally and externally to your customers and partners — so it’s critical that all infected endpoints are identified fast.
Step 2: Map
Once you have gathered the key indicators of a threat, you can throw on your Sherlock Holmes hat and begin piecing the artifacts together. Draw a timeline of events (or grab the audit logs and playback recordings from your monitoring tool) to visualize the steps the attacker followed in the attack. If you are triaging malware, at this stage you need to identify how it was able to compromise your network by looking at its trajectory.
What was the entry point? Where did it go next? And after that?
This step can be treated much like software debugging. This means that, as you look at the information, you can pursue and discard certain tasks and assumptions as you go along rather than following a rigid diagnostic process.
If you discover along the way that the suspected production server, in fact, wasn’t the target (as in the previous example), be ready to pivot your focus to the R&D workstation to find out why it was the target and how the threat got in.
Step 3: Eradicate
With a clear understanding of the attack path, you can prioritize your response based on the highest-value targets. So taking the information you gathered during triage, you can begin swiftly removing the malware from the identified system(s) and restoring the system(s) from a backup.
Of note, since this 3-step process is built to be agile, you should reach step 3 pretty fast — ideally fast enough to catch the incident in progress—before it completes its mission. That’s the ideal way to minimize damage to your systems.
Streamlining Your Triage Process for Effectiveness
Triaging security events isn't always easy, but it can be simplified. While an established process is good, be sure it’s not so rigid that it bogs down your time-to-response or paralyzes your team from pivoting to follow the attacker’s real path.
To give your security event triage processes an extra boost, you can utilize security automation and orchestration to handle the manual and repetitive tasks for you. Check out our to get an idea on how security automation could fit into your security operations.