The modern SOC: why it needs AI

An average SOC receives between 5,000 and 50,000 alerts daily. A Tier 1 analyst can review between 20 and 40 per hour if they are fast. The math does not add up. The result is predictable: alert fatigue, false positives being ignored, real incidents slipping through the noise unnoticed.

AI is not here to replace the analyst. It is here to eliminate the repetitive work that exhausts them. A well-trained model can classify an alert in milliseconds, automatically enrich IOCs and propose a verdict that the human analyst validates or corrects. This transforms the Tier 1 analyst from a ticket operator into a real analyst.

The three waves of AI in the SOC

The evolution of AI in security operations has followed three clear phases:

• Wave 1: Rules and signatures (2000-2015). SIEM with basic correlation. Sigma rules, YARA. Effective against known threats, useless against new techniques. The rule maintenance burden grows exponentially.
• Wave 2: Classical machine learning (2015-2023). Anomaly detection with supervised and unsupervised models. Random forests for alert classification. UEBA (User and Entity Behavior Analytics). Problem: requires manual feature engineering and models degrade quickly.
• Wave 3: LLMs and agents (2023-present). Language models that understand context, correlate events narratively and generate human-readable explanations. Autonomous agents that execute playbooks. The analyst supervises instead of executing.

AI-integrated SOC pipeline

An AI-integrated SOC pipeline is not a model that receives alerts and returns verdicts. It is a processing chain where each phase has its role and its appropriate model.

Phase 1: Ingestion and normalization

Alerts arrive from multiple sources: SIEM (Splunk, Elastic, Sentinel), EDR (CrowdStrike, SentinelOne), NDR (Darktrace, Vectra), firewalls, proxies, cloud logs. Each source has its own format. The first step is to normalize to a common schema.

Here AI helps with NER (Named Entity Recognition) to extract IOCs from unstructured alerts and with source classification to automatically tag the origin and event type.

Phase 2: Automatic enrichment

Each alert is enriched with external and internal context: IP reputation (VirusTotal, AbuseIPDB, OTX), geolocation, blocklist membership, user history in Active Directory, vulnerabilities of the affected asset.

An LLM can synthesize all this enrichment into a readable paragraph instead of forcing the analyst to review 6 different tabs.

Phase 3: Classification and prioritization

The model classifies the alert by severity (critical, high, medium, low, informational) and by type (malware, phishing, lateral movement, data exfiltration, policy violation). Additionally, it assigns a confidence score indicating how much to "trust" the automated verdict.

Phase 4: Decision and response

Based on the confidence score and severity, the alert follows one of three paths: auto-close (false positive with high confidence), escalation to Tier 2/Tier 3 (critical or low confidence), or automated playbook execution (known action with high confidence).

Automated alert triage

Automated triage is the use case with the highest immediate ROI. A Tier 1 analyst spends 70% of their time deciding whether an alert is a false positive or requires investigation. A model trained on the SOC's historical data can make that decision in milliseconds.

Triage model architecture

The most effective approach combines a fast classifier with an LLM for ambiguous cases:

# Pseudocode of the triage pipeline
def triage_alert(alert: Alert) -> TriageResult:
    # Step 1: Fast classifier (XGBoost or similar)
    quick_score = fast_classifier.predict(alert.features)

    if quick_score > 0.95:  # High confidence: false positive
        return TriageResult(verdict="FP", confidence=quick_score, auto_close=True)

    if quick_score < 0.20:  # High confidence: true positive
        return TriageResult(verdict="TP", confidence=1-quick_score, escalate=True)

    # Step 2: Gray zone -> LLM analyzes full context
    context = enrich_alert(alert)
    llm_analysis = llm.analyze(
        system_prompt=SOC_ANALYST_PROMPT,
        alert_data=alert.to_dict(),
        enrichment=context,
        historical_similar=find_similar_alerts(alert, top_k=5)
    )

    return TriageResult(
        verdict=llm_analysis.verdict,
        confidence=llm_analysis.confidence,
        explanation=llm_analysis.reasoning,
        recommended_actions=llm_analysis.actions
    )

The fast classifier (XGBoost, LightGBM) handles 70-80% of alerts. These are the obvious ones: known port scans, commodity malware signatures, failed logins from bots. The LLM is reserved for the ambiguous 20-30%, where context matters.

Features for the fast classifier

The most discriminative features for a SOC triage model are:

• Historical: number of times this rule has generated false positives, TP/FP ratio of the source, alert frequency in the last 24 hours.
• Contextual: criticality of the affected asset, event time (vs business hours), source geolocation vs country of operation.
• Technical: protocol type, ports involved, payload size, user-agent, TLS version.
• User-related: user role, department, usual behavior pattern, whether they are traveling or on leave.

Detection engineering with LLMs

Detection engineering is the discipline of creating, maintaining and optimizing the SOC's detection rules. Traditionally it is a manual, slow and error-prone process. An analyst reads a threat report, extracts the techniques, and writes Sigma rules or KQL queries.

LLMs can accelerate every step of this process:

From threat report to detection rule

Given a threat report (blog, advisory, paper), an LLM can:

1. Extract the MITRE ATT&CK techniques mentioned or implied.
2. Identify IOCs (hashes, IPs, domains, paths, registry keys).
3. Generate Sigma rules in standard format.
4. Propose hunting queries for Splunk, Elastic or Sentinel.

# Example: prompt to generate a Sigma rule from a report
DETECTION_ENGINEER_PROMPT = """
You are a senior detection engineer. Given the following threat report,
generate Sigma rules that detect the described techniques.

Requirements:
- Valid Sigma v2 format (YAML)
- Include fields: title, status, description, author, date, logsource, detection, level
- Map to MITRE ATT&CK (tags)
- Minimize false positives with specific conditions
- Include falsepositive section with known scenarios

Report:
{threat_report}

Generate the Sigma rules:
"""

Automated rule validation

An LLM can also review existing rules to detect issues:

• Overly broad rules: process_creation with CommandLine="*powershell*" without further filters generates thousands of false positives.
• Redundant rules: two rules detecting the same thing with slightly different conditions.
• Obsolete rules: detecting techniques that are no longer used or tools that no longer exist.
• Coverage gaps: MITRE techniques with no rule covering them.

Rule testing with synthetic data

Before deploying a new rule, you need to test it. An LLM can generate synthetic events that should trigger the rule (true positives) and similar events that should not (true negatives). This allows calculating expected precision before putting it in production.

False positive reduction

False positives are the SOC's cancer. A false positive ratio of 95% (common in many SOCs) means that out of every 100 alerts, 95 are noise. The analyst learns to ignore alerts, and when the real one comes, they ignore it too.

AI-driven reduction strategies

1. Automated feedback loop. Every time an analyst closes an alert as a false positive, that decision feeds the model. Over time, the model learns the patterns specific to that organization's environment.

2. Intelligent allowlisting. Instead of static allowlists (which rot over time), a model learns that "the backup server makes connections to these 15 external IPs every night at 3AM" and stops alerting on that specific pattern.

3. Temporal correlation. An isolated "failed login" alert is noise. Three failed logins followed by a successful login from another IP within 10 minutes is an attack. An LLM can narrate this correlation and explain why the combination is suspicious even though each individual event is not.

4. Business context. Deploying a new application generates hundreds of "unknown new process" alerts. Without business context, the SOC investigates each one. With CMDB integration and the change calendar, the model knows it is a planned deployment.

SOAR integration

SOAR (Security Orchestration, Automation and Response) is the execution engine. The SIEM detects, the SOAR acts. AI connects both: it decides what action to execute and when.

Popular SOAR platforms

• Palo Alto XSOAR (Cortex): the most mature, with an integration marketplace and predefined playbooks. Expensive, but comprehensive.
• Splunk SOAR (Phantom): native integration with Splunk. Good option if your SIEM is already Splunk.
• Tines: no-code SOAR with a free tier. Ideal for small teams that want to automate without coding.
• Shuffle: open source SOAR. Limited but sufficient to get started.
• n8n + custom: not a native SOAR, but with the right nodes you can build automated response workflows.

AI + SOAR integration pattern

# Typical flow: alert -> AI -> SOAR
1. SIEM generates alert
2. AI classifies and enriches (triage model)
3. If confidence > threshold:
   a. AI selects appropriate playbook
   b. SOAR executes playbook (IP block, endpoint isolation, etc.)
   c. AI generates incident report
4. If confidence < threshold:
   a. AI generates enriched summary
   b. Escalates to human analyst with full context
   c. Human decision feeds the model (feedback loop)

High-confidence automatable actions

• IP blocking at the perimeter firewall (if the IP has confirmed malicious reputation from 3+ sources).
• Endpoint isolation via EDR (if known ransomware signature execution is detected).
• Credential reset (if account compromise is confirmed).
• Hash blocking in EDR (known malware).
• User notification (confirmed phishing).

Intelligent playbooks

Traditional playbooks are static decision trees: "if X, then Y." Intelligent playbooks use AI to adapt the response to the context.

Key differences

Example: phishing playbook with AI

# Intelligent playbook: phishing detected
def phishing_playbook(alert, context):
    # 1. AI analyzes the email
    analysis = llm.analyze_email(
        headers=alert.email_headers,
        body=alert.email_body,
        attachments=alert.attachments,
        sender_reputation=context.sender_score
    )

    # 2. Determine scope
    recipients = email_gateway.find_recipients(alert.message_id)
    clicked = [r for r in recipients if r.clicked_link]

    # 3. Adaptive response
    if analysis.is_targeted_spearphishing:
        # Targeted spearphishing: escalate to Tier 3 + CTI
        escalate_to_n3(alert, analysis)
        notify_cti_team(analysis.threat_actor_indicators)
    elif len(clicked) > 10:
        # Mass campaign with clicks: rapid response
        quarantine_email(alert.message_id)
        block_sender(alert.sender)
        reset_credentials(clicked)
        notify_users(recipients, template="phishing_alert")
    else:
        # Phishing blocked, no clicks: log and close
        quarantine_email(alert.message_id)
        log_iocs(analysis.iocs)
        auto_close(alert, reason=analysis.summary)

Reference architecture

An AI-integrated SOC architecture has these components:

Data layer

• Security data lake: all logs normalized in a common format (ECS, OCSF). Hot storage (30 days), warm (90 days), cold (1 year).
• Vector store: embeddings of past alerts and their resolution, to search for similar historical alerts.
• Knowledge base: internal documentation, runbooks, security policies indexed for the LLM to query.

Model layer

• Fast classifier: XGBoost/LightGBM for high-volume triage. Latency <50ms.
• Analysis LLM: 7B-27B model for contextual analysis of ambiguous alerts. Self-hosted for data sovereignty.
• Anomaly model: autoencoder or isolation forest for UEBA. Detects deviations from normal behavior.

Orchestration layer

• SOAR: playbook execution engine. Integrated with EDR, firewall, email gateway, CMDB.
• Coordinator agent: decides which model to use, which playbook to execute, when to escalate to a human.
• Analyst dashboard: single view with alert + enrichment + AI analysis + recommended actions.

Sovereignty considerations

In regulated environments (ENS, NIS2, DORA), SOC data cannot leave controlled infrastructure. This implies:

• Self-hosted LLMs (vLLM, Ollama) instead of external APIs.
• IOC enrichment using hashes only (do not send full payloads to VirusTotal).
• Logs stored exclusively in the EU.
• Complete audit trail of every automated decision.

Ejercicio practico

Puntos clave