Skip to main content

SOC L1 Alert Triage: System and Workflow

1. System Overview​

The SOC L1 analyst acts as the verification layer between automated detection systems and manual incident response.

  • Data Source: Endpoints (laptops, servers), Firewalls, and Cloud services generate raw logs.
  • Aggregation: A SIEM (Security Information and Event Management) tool collects these logs.
  • Detection: The SIEM applies logic rules (correlations) to the logs.
  • Output: When a rule condition is met, an Alert is generated.

The L1 role is to validate whether the Alert represents a real security threat or a system error (noise).

2. The Triage Lifecycle​

The workflow follows a standard logic gate to ensure alerts are handled efficiently.

Step A: Queue Management​

Alerts appear in a dashboard queue. They must be selected based on a specific hierarchy to minimize risk.

  1. Severity: Prioritize Critical and High alerts first. These represent immediate threats (e.g., Ransomware, Data Exfiltration).
  2. Time: If severity is equal, prioritize the oldest alert.
  3. Assignment: The analyst must assign the alert to themselves. This locks the ticket and prevents duplication of effort.

Step B: Contextual Analysis​

An alert provides a timestamp and a trigger event. The analyst must query surrounding data to understand the Intent.

  • User Context: Is the user's behavior anomalous?
    • Example: A Human Resources user running PowerShell scripts is suspicious. A Developer doing the same is likely normal.
  • Host Context: What is the function of the machine?
    • Example: High traffic on a web server is normal; high traffic on a printer is suspicious.
  • External Intelligence:
    • Check destination IPs against reputation databases (e.g., AbuseIPDB, Talos).
    • Check file hashes against VirusTotal.

Step C: The Decision (Logic Gate)​

Every alert must end in a binary decision.

1. False Positive (Benign) The system logic triggered correctly, but the activity is not malicious.

  • Causes: Legitimate administrative work, software updates, or overly broad detection rules.
  • Action: Close the alert. Note the business justification (e.g., "User authorized to install Spotify").

2. True Positive (Malicious) The activity is unauthorized and harmful.

  • Causes: Malware execution, credential theft, unauthorized access.
  • Action: Escalate to L2/Incident Response. The L1 typically prepares the evidence package but does not perform the containment (isolation/wiping) themselves.

3. Technical Indicators​

When analyzing raw logs during Triage, look for these specific anomalies:

  • Parent-Child Process Drift:
    • Standard: explorer.exe opens chrome.exe.
    • Suspicious: winword.exe (Word) opens powershell.exe. This suggests a malicious macro.
  • Beaconing:
    • Consistent, rhythmic network connections to an external IP at regular intervals (e.g., every 5 minutes). This indicates Command and Control (C2) communication.
  • Double Extensions:
    • Files named document.pdf.exe or invoice.xlsx.scr. The system hides the final extension, tricking the user into executing a binary.

4. Operational Reality vs. Theory​

  • Noise: In a production environment, SIEM rules drift. Valid software updates often trigger "System Modification" alerts. The majority of L1 work is filtering out this noise.
  • Living off the Land: Attackers often use standard administrative tools (PowerShell, PsExec) to blend in. The SIEM cannot distinguish between an Admin using PowerShell and a Hacker using PowerShell. The analyst must verify the source and intent manually.