Now, what do we do?
Receive Your First Security Alert
Accept Your Assignment
SOAR is constantly receiving alerts, and even in an experienced SOC, there are always false alarms. It’s essential to filter them out to avoid mobilizing the SOC for nothing. However, some of these alerts involve serious incidents that must be addressed immediately. Clearly, you don’t have time to investigate every alert!
Your first task, should you choose to accept it, will be to quickly decide whether the alert should be escalated to the next stage or whether it’s a false alarm that needs to be filtered out. This is known as classification. This step should take no longer than 10 minutes.
Use SOAR
So what does this alert look like?
On Méditronique’s IS, it is the SIEM and the EDR that trigger alerts, but these alerts are sent in the SOAR. In other words, you’ll communicate with your SOC through the SOAR to sort alerts and organize your response to the relevant incidents.
The alert includes some additional information:
the rule that was triggered
the system where the event was identified
the user who performed the detected action (when possible)
the time of the event
etc.
In the screenshot that shows the rule for the Zerologon vulnerability in a previous chapter, we can see that each alert has a severity level and a status.
The severity level is automatically assessed by the system (SIEM or EDR) that triggered the alert, based on the details of the event or the detection rule. However, the assessment may be incorrect. These systems automatically apply detection rules and can completely overlook contextual elements that would be obvious to a human.
In fact, this severity level only serves to prioritize the order in which you should classify the various alerts. Instead, it should be seen more as a priority.
In addition to the severity level, you can see the alert status, which indicates that this is a new alert.
Your goal in classification is to assign a new status to the alert, indicating the next steps to be taken.
Identify False Positives Quickly
Can we really be sure that this is a cyberattack?
That’s an excellent question. It’s often the case that a non-malicious event can still trigger an alert. This is called a false positive.
This happens when an alert fails to differentiate malicious behavior from legitimate behavior (e.g., a privileged login) or when malicious behavior has occurred by mistake or in a harmless manner (e.g., an application crash).
It’s important to identify false positives as soon as possible to avoid mobilizing the SOC for nothing.
But how do we identify them?
Broadly speaking, the idea is to prioritize anything that could indicate a false positive as quickly as possible—and to close it as soon as you can prove it.
Understand the Alert
Start by asking yourself what the alert means.
When an alert is sent to SOAR, it contains contextual information related to the event, such as the date, the system involved, and possibly the affected user or the suspicious file.
This becomes easier once you gain more experience. But how does a new arrival to the SOC know how to respond?
Start by investigating the context, which may be enough to conclude that it’s a false positive. For example, it may be a false positive if you know that the triggering event is the result of a planned action, such as maintenance. Another possibility is if the event often occurs at this particular time, on this system, or involving this particular user.
On the other hand, the malicious nature of the alert may be obvious. If you can link it with certainty to a technique in the MITRE ATT&CK matrix, such as if you recognize the use of known malware, you can prioritize a rapid response and escalate the alert. You may be more inclined to escalate the alert right away if the technique appears on the right side of the matrix, indicating that the potential attacker is closer to inflicting damage on the organization.
It might also be a frequently recurring alert. Once again, you’ll learn to recognize these alerts more quickly with experience. For example, a script that creates a suspicious login may regularly raise the same alert, which you’ll quickly recognize because it always involves the same server and the same user.
Determine If an Investigation Is in Progress or Has Already Taken Place
This is the power of SOAR as an orchestration tool. It is a wonderful source of knowledge that contains all known incidents. If you don’t yet have the experience or a clear understanding of the context, rest assured that the SOAR does!
Search for the attributes contained in the alert, such as the server name, user name, or file name. These are called observables in Méditronique’s SOAR.
These observables will allow you to find alerts or investigations. Are they linked to your alert?
There are several possible scenarios:
You find an investigation that has already been conducted on the observable, which explains the cause of the alert. This allows you to quickly decide whether or not to process the alert.
There is an investigation in progress on an observable. You believe that this alert is linked to the investigation. You can then add the alert to the investigation.
There have previously been similar alerts, but no investigations. Why were no investigations conducted? If the reason is clear to you, you can mark the alert as a duplicate or false positive. Otherwise, now might be a good time to look into the alert!
If you can’t identify any similar alerts or investigations that might be related, you need to keep looking.
Deepen Your Understanding of the Alert
At this stage of your research, you haven’t identified anything that would allow you to filter the alert.
What questions should I ask to help determine, in five minutes, whether it’s a false positive?
Generally, all these questions are guided by internal guidelines—and therefore by operational procedures.
Here are a few examples:
Can you contact the person or team responsible for the alert? If the alert was triggered by a program, there is a team responsible for this system (application, data, workstation, middleware, etc.). You can also contact the business team that uses the system and knows it best. A quick call is still the most efficient solution!
Can you identify any events that would explain this alert? A quick glance at the user’s calendar or the IS department’s schedule can provide this information right away.
Does the state of the system explain the alert? Search the SIEM and EDR for information about when the event took place. The aim is not to perform a thorough analysis, but simply to check—in less than five minutes—whether there is any obvious information indicating a false positive (e.g., a system undergoing maintenance or an expired password).
Document Your Conclusion and Trigger the Next Step
If you’ve completed all of this, you should come to one of following three conclusions:
The alert is a false positive: This must be recorded in the SOAR with the status “false positive”! After all, even false positives are useful because they help to improve the SOC.
There is an investigation in progress: Add the alert to the investigation in the SOAR. This may be useful in moving the investigation along.
A new investigation must be created from the alert in the SOAR, if neither of the above conditions are met. None of the above. In this case, you need to know more about the alert.
Generally, we try to filter alerts as much as possible so that we only launch relevant investigations. That said, it’s better to investigate and later conclude that it’s a false positive.
You can think of this process as a funnel, where false positives are discarded at each stage.
You must therefore create a new investigation in the SOAR. We need to describe the alert and assign it a criticality level. We could even assign it to someone.
Estimate the Criticality of the Investigation
How do you estimate the criticality of an incident?
You already have a partial view of the severity of the incident from the work you’ve done to filter out the false positives.
To estimate the severity, you need to ask a number of questions.
First, based on the intrinsic characteristics of the alert:
Which MITRE ATT&CK matrix technique does this alert reference?
In which column (tactic) of the matrix is this technique located?
The further the tactic is to the right of the matrix, the more advanced the attack—and the more critical the alert. By looking at the corresponding technique, you can identify the potential impacts.
But that isn’t enough! We also have to consider everything that surrounds the alert, namely the event’s context within the organization. These are the extrinsic characteristics and what assets are involved (i.e., computers or accounts).
The more sensitive the asset, the more critical the alert. An alert involving a website or an ordinary employee’s laptop is less worrying than an alert involving a server, which is less critical than an alert involving an administrator’s workstation.
In particular, there is a set of assets that are at the heart of an organization’s security: Tier 0. By default, every alert concerning these assets is assigned maximum criticality. That’s because an attacker who has compromised them can do absolutely anything they want within the organization.
Enrich Your Investigation
To take it a step further, you should add any other information that was useful to you in your search for a false positive.
This process is called enrichment. It’s a quick process, allowing the investigation to remain the priority. Throughout the incident’s lifecycle, it will be enriched with new, relevant information.
On the topic of enrichment, take a moment to watch this video from Binetou, who tells us about classifying alerts on a daily basis.
Over to You!
You need to classify the following three alerts that arrive in Méditronique’s SOAR:
The user charlie.dupont@méditronique.com made five successive incorrect password attempts at 08:39. The associated technique is compromising an account with a bruteforce attack by an attacker on the network.
The user alice.martin@méditronique.com logged on from an IP address in Morocco at 09:21. Alice then logged into their email from an address in France at 10:02. The associated technique is the recovery of a valid account by an external attacker.
The EDR identified a malicious program called
somekatz.exeon a backup server. This server is critical, as it performs backups of applications that are critical to Méditronique’s business. The technique identified by the EDR is an attempt to retrieve the login credentials of other logged-in users from the server’s memory.
For each alert, provide three questions to quickly classify these alerts. When you have finished, compare your suggestions with the answer key.
Let’s Recap!
Classification is the first action to perform when an alert is received.
The goal is to determine whether the alert is a false positive, a confirmed security incident that needs to be investigated or whether it is linked to an incident that is already being addressed.
The main tool in this stage is the SOAR; this is where alerts are received, filtered, and possibly investigated.
The SOAR also enables information to be shared about ongoing investigations and past incidents.
To sort incidents, we try to answer the following questions:
Is this a known alert or an obvious false positive?
Is this alert related to an investigation, an incident in progress, or an incident that has already been handled?
Can I verify in five minutes that it’s a false positive?
Do I need to know more about the alert?
At the end of this process, there are three possible conclusions:
The alert is a false positive: Record it in the SOAR and move on.
We need more information: Create an investigation, add the information required for an alert, and estimate the criticality of the incident.
The incident indicates a major and immediate danger for the organization—a crisis situation.
The next step is to investigate the cause of the incident. That’s what we’ll look at in the following chapter.
