Good Analysis Starts with a Question: Why?
One of the most common mistakes among SOC analysts is believing that the analysis is complete the moment they find an alert. In reality, an alert is not the answer. An alert is only the beginning of an investigation.
Security tools are designed to help analysts understand what is happening or what has happened on a system. They collect, correlate, and highlight events that may be security-relevant and direct attention toward activities that require further investigation. However, on their own, they rarely provide a complete picture of an incident. That is why contextual analysis remains one of the most important responsibilities of every SOC analyst.
This is precisely why two identical alerts can represent completely different situations. One may be a legitimate administrative activity, while the other may be the beginning of a serious compromise.
When an alert appears, the first question should not be how to close it. The first question should be why the rule triggered in the first place. Only when we understand the logic behind the rule can we understand what actually happened on the system.
For example, if we see an "Encoded PowerShell" alert, the mere fact that PowerShell was executed is not enough to draw a conclusion. We need to understand what was executed, who executed it, from which context, and for what purpose.
At that point, the analysis is only beginning.
What Does the Analysis Process Actually Look Like?
Step 1 – An Alert Is Received
The first step is to review the alert and gather basic information. This includes checking the rule name, event time, user, device, data source, and severity level.
At this stage, no conclusions should be made. The goal is to understand what the system has detected.
Step 2 – Read the Rule Name
The rule name often provides the first clues about what should be analyzed.
If we see a rule called "Abnormal Parent Child Process," we immediately know that we will need to analyze the relationship between the parent process and the child process.
If we see "Encoded PowerShell," the investigation will focus on PowerShell commands and command-line arguments.
If we see "Impossible Travel," we will analyze user logins, geolocation data, and authentication events.
A good analyst first tries to understand what the rule is attempting to detect.
Step 3 – Read the Rule Description
After reading the rule name, the next step is to review the rule description.
The description explains why the alert was generated, what behavior is considered suspicious, and what the rule is actually designed to detect.
Only after understanding the rule logic can a quality investigation begin.
Step 4 – Determine the Starting Point of the Investigation
Every rule has its own starting point.
If the alert is related to a user account, login activity, multi-factor authentication events, IP addresses, and geolocation data should be analyzed.
If the alert is related to a process, the parent process, child process, command-line arguments, and execution path should be reviewed.
If the alert is related to network activity, IP addresses, domains, network connections, and destination reputation should be examined.
The rule determines where the investigation begins.
Step 5 – Gather Context
A single alert almost never provides the complete picture.
Additional alerts, related incidents, indicators of compromise, process activity, user actions, network communications, and historical events should all be collected and reviewed.
Only then can we begin to understand what actually happened.
Step 6 – Analyze Process Context
Many analysts focus solely on the process name.
That is not enough.
For example, powershell.exe by itself means very little. It is necessary to determine who launched it, when it was launched, which parent process initiated it, what commands were executed, whether network communication occurred, and whether the process is digitally signed.
It is especially important to analyze the relationship between the parent process and the child process. While processes routinely spawn other processes during normal operation, there are situations where that relationship may indicate a system compromise.
For example, if explorer.exe launches cmd.exe or powershell.exe, the behavior may be perfectly legitimate. However, if a Microsoft Office document launches powershell.exe, which then launches additional processes or establishes network communication, further investigation is required to determine whether the activity is legitimate or malicious.
Process context is often more important than the process itself. Analysts must understand why the process was executed, under what circumstances, by which user, and whether the behavior is normal for the environment being analyzed.
Step 7 – Analyze the Process Execution Path
It is very important to determine where a process was launched from.
A process executing from C:\Windows\System32 is very different from a process executing from AppData, Temp, or Downloads directories.
However, this is where one of the most common mistakes in security analysis occurs.
Activity originating from the Temp directory does not automatically indicate an attack.
During software upgrades, installations, patch deployments, and system implementation activities, it is common for files to be temporarily extracted and executed from temporary directories.
In other words, legitimate activity can sometimes look very similar to malicious activity.
Likewise, PowerShell is not malicious by itself. Cmd is not malicious by itself. Rundll32 is not malicious by itself. These are legitimate Windows tools used by both administrators and attackers.
This is why context determines whether an activity is legitimate or malicious.
For that reason, the execution path alone should never be the sole factor used to assess an incident. The entire context must be considered before drawing conclusions.
Step 8 – Verify Whether the Activity Is Legitimate
After completing the technical analysis, it is important to answer a simple question:
Did the user expect this activity?
Very often, the user provides the information needed to confirm or dismiss suspicion.
It may turn out that the activity was part of a software upgrade, an administrative task, a new system deployment, an automated process, or a legitimate business operation.
At first glance, such activities may appear identical to a compromise.
Step 9 – Draw a Conclusion
Only after gathering all relevant information can a conclusion be reached.
Is this legitimate activity? Is it a false positive? Is it suspicious activity? Is it a confirmed compromise?
Skipping investigation steps almost always leads to incorrect conclusions.
Step 10 – Apply the Appropriate Response Procedure
Once we understand what happened, we apply the appropriate response procedure.
This may involve procedures for user accounts, endpoints, malware, persistence mechanisms, lateral movement, or incident response.
A procedure is not intended to limit an analyst. Its purpose is not to encourage blind execution of steps.
A good procedure serves as a guide that ensures every analyst follows the same critical investigative steps. It helps ensure that important information, indicators of compromise, related events, and key findings are not overlooked.
An Analyst Must Think Like an Investigator
Quality analysis is not a checklist of clicks performed in a SIEM or EDR platform. Quality analysis is the process of asking questions and finding answers through available data.
A good analyst constantly looks for additional context. Are there related alerts? Has the user performed unusual actions? Are there indicators of compromise? Has similar activity been observed on other systems? Is there communication with suspicious IP addresses or domains?
The difference between an operator who processes alerts and an analyst who performs investigations lies in the way they think.
An operator sees an alert and looks for a reason to close it.
An analyst sees an alert and looks for the reason it was triggered.
Every detection rule has a specific purpose and logic. If we do not understand what a rule is trying to detect, there is a high probability that we will miss important indicators of compromise or incorrectly assess the severity of an event.
Why Are Response Procedures Important?
Only after understanding what happened can we apply the appropriate response procedure.
The purpose of a procedure is to ensure that every analyst follows the same critical analysis steps and does not overlook important information during the investigation.
A good procedure does not tell an analyst what to think.
A good procedure ensures that the analyst asks all the right questions.
Conclusion
The most important skill of a SOC analyst is not knowledge of a specific tool, but the ability to understand context and connect information.
Analysis begins by reading the rule. It continues through understanding the context. It ends with conclusions based on evidence.
An alert is not proof of compromise. An alert is an indicator that something requires further investigation.
Good analysis does not look for a reason to close an alert. Good analysis looks for the reason why the alert was triggered.
