To detect security incidents, we started by defining the events to be identified, and then we set up data collection.
But how can we use this data to detect incidents? This is what we’ll be looking at in this chapter!
Understand the Role of the SIEM
The SIEM is a dedicated tool that makes use of data to detect incidents.
In practice, the SIEM is one of the SOC’s main tools. It’s essentially your control tower that allows you to:
monitor the IS in real time, 24/7.
define alerts by cross-referencing events.
create visualization charts.
perform complex searches in the data.
Visualize the State of Your IS
SOC visualization work is essential, because simply watching the logs scroll by one by one makes no sense in terms of analysis.
On the contrary, a good analyst is someone who can clearly explain a situation by designing new ways of presenting relevant data in a simplified manner!
Search for Information
When you need to handle an alert (we’ll come to this later in the course), you’ll use the SIEM to understand what happened by querying the SIEM with very specific search requests. These results can be displayed as lists or graphs, allowing you to visualize quantities and variations.
By combining visualization and search requests, you can quickly obtain the answers you need.
Raise Alerts
To detect the events you’re searching for, you need to use a detection rule to tell the SIEM to raise the alert.
Detection rules are defined as conditions:
If “these various conditions are met”
Then “an alert is generated”
With “this level of severity”
The alert is then sent to the Security orchestration, automation and response (SOAR) alert processing tool, which will be introduced in the following section.
Depending on the adopted level of security, the alert can take different forms. For example, the alert can simply be sent to the SOAR, there might be a notification, an email can be sent automatically, a ticket can be created automatically, and so on.
Identify Malicious Events
How do you define rules that identify malicious events in a relevant manner?
There are a number of signs that we can use to identify a malicious event:
The event is unusual, such as an administrator password change in the middle of the night or two simultaneous logins from two different countries.
The event corresponds to a technique in the MITRE ATT&CK matrix that you need to detect, such as the execution of a macro in an emailed document attachment. It may be a legitimate email, but if you want to detect this technique, you need to define a rule, even if it means having to determine legitimacy later.
The event corresponds to a feared event. For example, if several hundred files are changed, this could mean that there is ransomware on the system! Since you have already identified this risk as critical to your organization, you need to define a rule that detects it.
The event is a prerequisite for exploiting a known vulnerability.
The event involves known traces of an attacker, like an IP address used to distribute malware.
This kind of trace is known as an Indicator of Compromise (IoC) and can take the form of an IP address, a domain name, or a file associated with a threat actor.
Finally, use the security tools described in the previous chapter: EDR, NDR, XDR, etc. These tools generate alerts that can be added to the alerts defined in the SIEM.
Use YARA Rules to Detect Malicious Files
Among the various ways of defining detection rules, YARA rules are a standardized way of detecting malicious files.
These rules identify the presence of specific bytes or strings.
For example, the following rule detects that a macro is contained in a document based on the following conditions:
The sequence of the first bytes of the file indicates that it is an Excel document.
One of the two byte sequences indicates that it contains a macro, or the string “Excel 4.0 Macros” is included.
A known malicious IP address is present in the document.
Use SIGMA Rules to Search for Indicators in Logs
SIGMA rules are another standardized format for detection rules. These rules define a condition to search for in a particular type of log.
In practice, a SIGMA rule is a YAML file with a data source ( logsource ) and conditions ( detection ).
For example, the following rule identifies exploits of the Zerologon vulnerability:
In the logsource section, the rule states that it relates to the analysis of Windows logs, more specifically security event logs. The condition keyword indicates that it searches these logs for events with event ID 4742 with specific attributes, except those indicating a change in the Password Last Set attribute. You will notice that the rule’s creators were careful to indicate:
where to find out more about this vulnerability.
what false positives this rule could generate.
the criticality level for this vulnerability.
Use All of the Resources at Your Disposal
The advantage of standardized rules like YARA and SIGMA is that you don’t have to reinvent the wheel. Many resources are available online to help you. This is particularly important when a new vulnerability or attack technique is identified.
Let’s Recap!
SIEM is the tool used to view and analyze all logs collected by the SOC.
SIEM enables multiple events to be cross-referenced to raise alerts based on preconfigured rules. This is called correlation.
These rules are defined by the SOC using information gathered from other teams, through their Cyber Threat Intelligence (CTI) activities, including alert bulletins, IoCs, and TTPs.
The YARA and SIGMA formats standardize the writing of rules, making them easier to share and deploy.
MITRE CAR is a useful resource for finding detection rules that other SOCs have already created.
Now that you have the objectives, tools, and detection rules, your SOC has almost everything it needs to function—all that’s left is organization!
In the next chapter, you’ll learn how to organize and equip your SOC for effective incident management.
