00 - Detection Engineering come Disciplina: Da Script a Pipeline

01 - Detection Engineering: dalla Disciplina allo Script alla Pipeline

In un panorama di minacce informatiche in costante evoluzione, la capacità di rilevare attivita malevole prima che causino danni significativi rappresenta il vero differenziale tra un'organizzazione resiliente e una vulnerabile. Per decenni, il rilevamento delle minacce e stato affidato a regole scritte ad hoc, firme antivirus e intuizioni individuali degli analisti SOC. Oggi, questo approccio artigianale non e più sostenibile: il volume di log, la complessità delle infrastrutture cloud-native e la sofisticazione degli attaccanti richiedono un approccio ingegneristico e sistematico.

Nasce cosi la Detection Engineering: una disciplina che applica i principi dell'ingegneria del software al processo di creazione, test, distribuzione e manutenzione delle regole di rilevamento. Non si tratta più di scrivere query isolate in un SIEM, ma di costruire pipeline automatizzate, versionare le detection come codice, testarle con dati simulati e misurarle con metriche oggettive.

Cos'è la Detection Engineering

La Detection Engineering e il processo sistematico di progettazione, sviluppo, test e manutenzione della logica che identifica attivita malevole all'interno della telemetria di un'organizzazione. Questa telemetria include log provenienti da endpoint, infrastruttura cloud, identity provider, applicazioni web, sistemi di rete e molto altro.

A differenza dell'approccio tradizionale, dove un analista SOC scriveva una query nel SIEM in risposta a un incidente specifico, la Detection Engineering adotta un workflow strutturato che ricorda lo sviluppo software moderno: versionamento del codice, code review, test automatizzati, deployment continuo e monitoraggio delle prestazioni in produzione.

"Detection Engineering is to SOC what Software Engineering is to coding: it transforms an ad-hoc, reactive activity into a systematic, measurable, and continuously improving discipline."
- SANS Institute, 2025 Detection Engineering Survey

I Tre Pilastri della Detection Engineering

La disciplina si fonda su tre pilastri interconnessi che ne definiscono la maturita:

1. Threat Intelligence - Comprendere chi sono gli avversari, quali tecniche usano (MITRE ATT&CK), e quali asset dell'organizzazione sono a rischio. Senza una comprensione profonda delle minacce, le detection saranno generiche e poco efficaci.
2. Data Engineering - Garantire che i log necessari siano raccolti, normalizzati e disponibili per l'analisi. Una detection perfetta e inutile se i dati su cui opera non sono presenti o sono di scarsa qualità.
3. Software Engineering - Applicare le best practice dello sviluppo software: version control, testing, CI/CD, documentazione, metriche. Le detection devono essere trattate come codice di produzione.

L'Evoluzione: dagli Script Ad Hoc alla Disciplina Ingegneristica

Il percorso che ha portato alla Detection Engineering moderna può essere suddiviso in quattro fasi distinte, ciascuna caratterizzata da un livello crescente di maturita e automazione.

Fase 1: L'Era delle Firme (1990-2005)

Le prime forme di rilevamento si basavano su firme statiche: pattern noti di malware, hash di file malevoli, stringhe specifiche nei payload di rete. Ogni antivirus e IDS (Intrusion Detection System) manteneva un database di firme che veniva aggiornato periodicamente. L'approccio funzionava ragionevolmente bene con minacce note, ma era completamente cieco di fronte a varianti nuove o attacchi personalizzati.

Fase 2: L'Era degli Script SIEM (2005-2015)

Con la diffusione dei primi SIEM (Security Information and Event Management), gli analisti iniziarono a scrivere query e correlazioni personalizzate. Ogni analista aveva il proprio approccio, i propri script, le proprie naming convention. Le regole venivano create direttamente nell'interfaccia web del SIEM, senza versionamento, senza test, senza documentazione standardizzata. Quando un analista lasciava l'organizzazione, le sue detection spesso diventavano incomprensibili per i successori.

Fase 3: La Nascita della Detection Engineering (2015-2022)

Tra il 2015 e il 2022, la comunita di sicurezza inizia a riconoscere la necessità di un approccio più strutturato. Nascono formati standard come Sigma (2017) per le regole di detection, il framework MITRE ATT&CK diventa il riferimento universale per mappare le tecniche degli avversari, e i primi team dedicati di Detection Engineering compaiono nelle organizzazioni più mature.

Fase 4: Detection-as-Code e Pipeline CI/CD (2022-oggi)

Oggi, le organizzazioni più avanzate trattano le detection esattamente come codice software. Le regole sono scritte in formati dichiarativi (Sigma, YAML), versionate in repository Git, testate automaticamente con dati simulati, distribuite tramite pipeline CI/CD e monitorate con dashboard dedicate. Secondo il SANS 2025 Detection Engineering Survey, il 60% delle organizzazioni mantiene team dedicati di Detection Engineering, con il 70% delle enterprise con oltre 5.000 dipendenti che hanno già stabilito team strutturati.

Il Ciclo di Vita di una Detection

Ogni detection segue un ciclo di vita ben definito che garantisce qualità, efficacia e manutenibilità nel tempo. Il ciclo si compone di sei fasi fondamentali, ciascuna con deliverable e criteri di qualità specifici.

1. Ipotesi (Hypothesis)

Tutto inizia con una ipotesi di minaccia. L'analista o il detection engineer identifica una tecnica di attacco specifica (ad esempio, "Un attaccante potrebbe usare PowerShell per scaricare ed eseguire payload malevoli") e formula un'ipotesi su come questa attivita si manifesterebbe nei log disponibili. Le fonti per le ipotesi includono:

• Threat Intelligence - Report su campagne attive, TTPs osservati
• MITRE ATT&CK - Tecniche mappate per tactic specifiche
• Incident post-mortem - Lezioni apprese da incidenti precedenti
• Red Team findings - Risultati di penetration test e purple teaming
• Gap analysis - Tecniche ATT&CK senza copertura di detection

2. Sviluppo (Development)

Con l'ipotesi definita, il detection engineer scrive la regola di rilevamento. Questo comporta la scelta del formato (Sigma, query nativa SIEM, script Python), la definizione dei log source necessari, la logica di selezione e filtraggio, e la documentazione dei metadati (autore, severita, mapping ATT&CK, false positive noti).

3. Test e Validazione (Testing)

Prima del deployment, la detection deve essere validata contro dati reali e simulati. Il testing include: true positive testing (la regola rileva l'attacco simulato?), false positive testing (la regola genera allarmi su attivita legittime?), e performance testing (la regola e sufficientemente performante sui volumi di log di produzione?).

4. Deployment

Il deployment avviene attraverso pipeline automatizzate che convertono la regola nel formato nativo del SIEM target, la distribuiscono all'ambiente di produzione e ne verificano il corretto funzionamento. In ambienti maturi, questo processo e completamente automatizzato tramite CI/CD.

5. Monitoraggio e Metriche

Una volta in produzione, la detection viene monitorata costantemente. Le metriche chiave includono il volume di alert generati, il rapporto true/false positive, il tempo medio di rilevamento (MTTD), e l'impatto sul carico degli analisti SOC.

6. Tuning e Manutenzione

Sulla base dei dati raccolti in produzione, la detection viene continuamente affinata. Il tuning può includere l'aggiunta di eccezioni per false positive ricorrenti, l'ampliamento della logica per coprire varianti della tecnica, o la deprecazione della regola se non più rilevante.

Tipi di Detection: dall'IOC al Comportamento

Le detection possono essere classificate in base alla logica di rilevamento utilizzata. Ogni tipo ha vantaggi e limiti specifici, e un programma di detection maturo li combina tutti in modo stratificato.

1. Signature-Based Detection

Il rilevamento basato su firme cerca pattern esatti nei dati: hash di file noti, stringhe specifiche nei comandi, indirizzi IP o domini malevoli noti (IOC - Indicators of Compromise). E il tipo più semplice e veloce, con bassissimo tasso di false positive, ma completamente inefficace contro minacce nuove o varianti.

title: Emotet Loader Hash Detection
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: Detects known Emotet loader by file hash
author: Detection Engineering Team
date: 2025/10/15
references:
  - https://attack.mitre.org/software/S0367/
logsource:
  category: file_event
  product: windows
detection:
  selection:
    Hashes|contains:
      - 'SHA256=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
      - 'SHA256=a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a'
      - 'MD5=d41d8cd98f00b204e9800998ecf8427e'
  condition: selection
falsepositives:
  - Unlikely, known malicious hashes
level: critical
tags:
  - attack.execution
  - attack.t1204.002

2. Behavioral Detection

Le detection comportamentali cercano sequenze di azioni o pattern di comportamento che indicano attivita sospetta, indipendentemente dagli specifici IOC. Ad esempio, invece di cercare un hash specifico di Mimikatz, una detection comportamentale potrebbe cercare qualsiasi processo che accede alla memoria di LSASS per estrarre credenziali. Questo approccio e molto più resistente all'evasione, perchè gli attaccanti possono cambiare i propri strumenti ma difficilmente possono cambiare la tecnica sottostante.

title: Suspicious LSASS Process Access - Credential Dumping
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: |
  Detects process access to LSASS memory, a common technique
  for credential dumping (T1003.001). Focuses on behavior
  rather than specific tool signatures.
author: Federico Calo
date: 2025/11/20
references:
  - https://attack.mitre.org/techniques/T1003/001/
logsource:
  category: process_access
  product: windows
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'    # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
      - '0x1038'    # Read memory access
      - '0x1FFFFF'  # PROCESS_ALL_ACCESS
  filter_legitimate:
    SourceImage|endswith:
      - '\MsMpEng.exe'          # Windows Defender
      - '\csrss.exe'            # Client Server Runtime
      - '\wmiprvse.exe'         # WMI Provider
      - '\svchost.exe'          # Service Host
  filter_system:
    SourceUser|contains: 'SYSTEM'
    SourceImage|startswith: 'C:\Windows\System32\'
  condition: selection and not filter_legitimate and not filter_system
falsepositives:
  - Legitimate security tools performing memory scanning
  - EDR solutions with high-privilege access
level: high
tags:
  - attack.credential_access
  - attack.t1003.001

3. Anomaly-Based Detection

Le detection basate su anomalie stabiliscono un baseline di normalita e segnalano le deviazioni significative. Ad esempio, se un utente accede tipicamente da una sede in Italia durante l'orario lavorativo, un login dalla Cina alle 3 di notte sarebbe un'anomalia. Questo approccio può rilevare minacce completamente sconosciute (zero-day), ma tende a generare più false positive, specialmente in ambienti dinamici.

4. Threat Hunting

Il Threat Hunting e un processo proattivo e guidato da ipotesi in cui gli analisti cercano attivamente minacce che potrebbero essere sfuggite alle detection automatiche. A differenza delle detection automatizzate, il threat hunting e esplorativo e spesso produce nuove detection che vengono poi codificate e automatizzate.

Metriche di qualità per le Detection

Una detection non e utile se non e misurabile. Le metriche di qualità permettono di valutare l'efficacia delle regole di rilevamento, guidare il processo di tuning e giustificare gli investimenti nel programma di Detection Engineering.

Metriche Operative Fondamentali

Calcolo del Detection Score

Un approccio pratico per valutare la qualità complessiva del programma di detection e il Detection Maturity Score, che combina diverse metriche in un punteggio normalizzato. Ecco un esempio di calcolo in Python:

from dataclasses import dataclass
from typing import List

@dataclass(frozen=True)
class DetectionMetrics:
    """Immutable snapshot of detection performance metrics."""
    rule_id: str
    true_positives: int
    false_positives: int
    false_negatives: int
    total_alerts: int
    avg_detection_time_minutes: float  # MTTD
    avg_response_time_minutes: float   # MTTR

    @property
    def precision(self) -> float:
        """TP / (TP + FP) - How many alerts are real threats."""
        denominator = self.true_positives + self.false_positives
        return self.true_positives / denominator if denominator > 0 else 0.0

    @property
    def recall(self) -> float:
        """TP / (TP + FN) - How many real threats are caught."""
        denominator = self.true_positives + self.false_negatives
        return self.true_positives / denominator if denominator > 0 else 0.0

    @property
    def f1_score(self) -> float:
        """Harmonic mean of precision and recall."""
        p, r = self.precision, self.recall
        return 2 * (p * r) / (p + r) if (p + r) > 0 else 0.0


def calculate_maturity_score(metrics_list: List[DetectionMetrics]) -> dict:
    """Calculate overall detection program maturity score.

    Returns an immutable dict with aggregated metrics.
    """
    if not metrics_list:
        return {"score": 0, "grade": "F", "details": {}}

    avg_precision = sum(m.precision for m in metrics_list) / len(metrics_list)
    avg_recall = sum(m.recall for m in metrics_list) / len(metrics_list)
    avg_f1 = sum(m.f1_score for m in metrics_list) / len(metrics_list)
    avg_mttd = sum(m.avg_detection_time_minutes for m in metrics_list) / len(metrics_list)
    avg_mttr = sum(m.avg_response_time_minutes for m in metrics_list) / len(metrics_list)

    # Weighted maturity score (0-100)
    precision_score = avg_precision * 25        # 25% weight
    recall_score = avg_recall * 25              # 25% weight
    f1_component = avg_f1 * 20                  # 20% weight
    mttd_score = max(0, (240 - avg_mttd) / 240) * 15  # 15% weight (240min = 4h target)
    mttr_score = max(0, (240 - avg_mttr) / 240) * 15  # 15% weight

    total_score = (precision_score + recall_score + f1_component
                   + mttd_score + mttr_score) * 100

    grade_thresholds = [
        (90, "A"), (80, "B"), (70, "C"), (60, "D")
    ]
    grade = next(
        (g for threshold, g in grade_thresholds if total_score >= threshold),
        "F"
    )

    return {
        "score": round(total_score, 1),
        "grade": grade,
        "details": {
            "avg_precision": round(avg_precision, 3),
            "avg_recall": round(avg_recall, 3),
            "avg_f1": round(avg_f1, 3),
            "avg_mttd_minutes": round(avg_mttd, 1),
            "avg_mttr_minutes": round(avg_mttr, 1),
            "total_rules_evaluated": len(metrics_list),
        },
    }


# Esempio di utilizzo
sample_metrics = [
    DetectionMetrics("SIGMA-001", 45, 5, 2, 50, 15.0, 35.0),
    DetectionMetrics("SIGMA-002", 120, 30, 8, 150, 8.5, 22.0),
    DetectionMetrics("SIGMA-003", 200, 15, 5, 215, 3.2, 12.0),
]

result = calculate_maturity_score(sample_metrics)
print(f"Detection Maturity Score: {result['score']} ({result['grade']})")
print(f"Details: {result['details']}")

L'Ecosistema SIEM/SOAR

Il SIEM (Security Information and Event Management) e il cuore dell'infrastruttura di Detection Engineering. E la piattaforma che raccoglie, normalizza, correla e analizza i log provenienti da tutte le sorgenti dell'organizzazione. Il SOAR (Security Orchestration, Automation and Response) complementa il SIEM automatizzando le risposte agli alert tramite playbook predefiniti.

Panoramica delle Piattaforme SIEM Principali

Sorgenti Dati Fondamentali

La qualità delle detection dipende direttamente dalla qualità e completezza dei dati disponibili. Ecco le sorgenti dati fondamentali per un programma di detection efficace:

• Endpoint Telemetry - Log di processo, file system events, registry changes, network connections. Fonti: EDR (CrowdStrike, SentinelOne, Microsoft Defender), Sysmon
• Network Telemetry - NetFlow, DNS queries, HTTP/TLS metadata, PCAP selettivi. Fonti: firewall, IDS/IPS, proxy, DNS resolver
• Identity & Access - Authentication events, privilege escalation, group membership changes. Fonti: Active Directory, Entra ID, Okta, CyberArk
• Cloud Audit Logs - API calls, configuration changes, resource creation. Fonti: AWS CloudTrail, Azure Activity Log, GCP Audit Logs
• Application Logs - Web server access logs, application errors, WAF events. Fonti: Nginx, Apache, CloudFront, applicazioni custom
• Email Security - Phishing attempts, malicious attachments, BEC detection. Fonti: Microsoft Defender for O365, Proofpoint, Mimecast

Detection-as-Code: il Paradigma Moderno

Detection-as-Code (DaC) e l'approccio che applica le pratiche di sviluppo software alla gestione delle regole di detection. Invece di creare e modificare regole tramite l'interfaccia grafica del SIEM, le detection vengono scritte come codice, versionate in repository Git, sottoposte a code review tramite pull request, testate automaticamente e distribuite attraverso pipeline CI/CD.

Vantaggi del Detection-as-Code

Struttura di un Repository Detection-as-Code

detections/
  rules/
    credential_access/
      lsass_memory_access.yml
      brute_force_login.yml
      kerberoasting.yml
    execution/
      powershell_encoded_command.yml
      suspicious_wmi_execution.yml
    lateral_movement/
      psexec_usage.yml
      rdp_from_unusual_source.yml
    persistence/
      scheduled_task_creation.yml
      registry_run_key.yml
  tests/
    credential_access/
      lsass_memory_access_test.json
      brute_force_login_test.json
    execution/
      powershell_encoded_command_test.json
  config/
    sigma_config.yml
    siem_mappings.yml
    exclusions.yml
  pipelines/
    ci.yml
    cd.yml
  docs/
    CONTRIBUTING.md
    STYLE_GUIDE.md
    REVIEW_CHECKLIST.md
  README.md

Pipeline CI/CD per le Detection

La pipeline CI/CD per le detection automatizza l'intero processo dal commit alla produzione. Ecco un esempio di configurazione per GitHub Actions:

name: Detection CI/CD Pipeline

on:
  pull_request:
    paths: ['rules/**', 'tests/**']
  push:
    branches: [main]
    paths: ['rules/**']

jobs:
  validate:
    name: Validate Sigma Rules
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install sigma-cli
        run: pip install sigma-cli pySigma-backend-splunk pySigma-backend-elasticsearch

      - name: Lint Sigma Rules
        run: |
          sigma check rules/ --validation-config config/sigma_config.yml
          echo "All rules pass validation"

      - name: Verify ATT&CK Mapping
        run: |
          python scripts/verify_attack_tags.py rules/
          echo "All rules have valid ATT&CK mappings"

  test:
    name: Test Detection Logic
    needs: validate
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run True Positive Tests
        run: |
          python scripts/run_tests.py \
            --rules-dir rules/ \
            --tests-dir tests/ \
            --test-type true_positive

      - name: Run False Positive Tests
        run: |
          python scripts/run_tests.py \
            --rules-dir rules/ \
            --tests-dir tests/ \
            --test-type false_positive

      - name: Generate Coverage Report
        run: python scripts/coverage_report.py --output reports/coverage.json

  deploy:
    name: Deploy to SIEM
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - name: Convert Sigma to Splunk SPL
        run: |
          sigma convert \
            --target splunk \
            --pipeline splunk_windows \
            rules/ \
            --output converted/splunk/

      - name: Deploy to Splunk via API
        env:
          SPLUNK_TOKEN: ${{ secrets.SPLUNK_API_TOKEN }}
          SPLUNK_URL: ${{ secrets.SPLUNK_URL }}
        run: |
          python scripts/deploy_splunk.py \
            --rules-dir converted/splunk/ \
            --splunk-url "$SPLUNK_URL" \
            --token "$SPLUNK_TOKEN"

      - name: Update ATT&CK Coverage Map
        run: python scripts/update_attack_coverage.py

Scrivere Detection Efficaci: Principi e Pattern

La differenza tra una detection mediocre e una eccellente risiede nella profondità della comprensione della tecnica di attacco, nella qualità del filtraggio dei false positive e nella completezza della documentazione. Ecco i principi fondamentali.

Principio 1: Parti dalla Tecnica, Non dallo Strumento

Non scrivere una detection per "Mimikatz" - scrivi una detection per la tecnica di credential dumping via LSASS memory access (T1003.001). Questo approccio copre automaticamente tutti gli strumenti che implementano la stessa tecnica, inclusi quelli futuri non ancora noti.

Principio 2: Stratifica le Detection (Detection Pyramid)

Implementa detection a più livelli per la stessa tecnica. Una detection basata su hash (trivialmente evadibile) può comunque catturare attaccanti poco sofisticati, mentre una detection comportamentale cattura quelli più avanzati. Questo approccio stratificato e noto come Detection in Depth.

Principio 3: Documenta Sempre il Contesto

Ogni detection deve includere: la motivazione (perchè questa detection esiste), il mapping ATT&CK (quale tecnica copre), i false positive noti (quali attivita legittime possono triggherare la regola), e il playbook di risposta (cosa deve fare l'analista quando la detection scatta).

Esempio Completo: Detection con Log Analysis Python

"""
Brute Force Detection Module
MITRE ATT&CK: T1110.001 - Brute Force: Password Guessing
Detects multiple failed login attempts followed by a success.
"""
from dataclasses import dataclass, field
from datetime import datetime, timedelta
from collections import defaultdict
from typing import Optional


@dataclass(frozen=True)
class LoginEvent:
    """Immutable representation of a login event."""
    timestamp: datetime
    username: str
    source_ip: str
    success: bool
    service: str  # 'ssh', 'rdp', 'web', 'vpn'


@dataclass(frozen=True)
class BruteForceAlert:
    """Immutable alert generated by the detector."""
    username: str
    source_ip: str
    failed_count: int
    time_window_minutes: int
    first_attempt: datetime
    last_attempt: datetime
    successful_login: bool
    severity: str  # 'medium', 'high', 'critical'
    mitre_technique: str = "T1110.001"


@dataclass(frozen=True)
class DetectionConfig:
    """Immutable configuration for brute force detection."""
    failed_threshold: int = 5
    time_window_minutes: int = 10
    lockout_threshold: int = 20
    whitelist_ips: tuple = ()
    monitored_services: tuple = ('ssh', 'rdp', 'web', 'vpn')


class BruteForceDetector:
    """Stateless brute force detection engine.

    Analyzes login events and produces alerts when
    brute force patterns are detected.
    """

    def __init__(self, config: Optional[DetectionConfig] = None):
        self._config = config or DetectionConfig()

    def analyze(self, events: list[LoginEvent]) -> list[BruteForceAlert]:
        """Analyze a batch of login events for brute force patterns.

        Returns a new list of alerts (no mutation of input).
        """
        # Group events by (source_ip, username)
        grouped = defaultdict(list)
        for event in events:
            if (event.service in self._config.monitored_services
                    and event.source_ip not in self._config.whitelist_ips):
                key = (event.source_ip, event.username)
                grouped[key].append(event)

        alerts = []
        for (source_ip, username), user_events in grouped.items():
            sorted_events = sorted(user_events, key=lambda e: e.timestamp)
            alert = self._check_brute_force(source_ip, username, sorted_events)
            if alert is not None:
                alerts.append(alert)

        return alerts

    def _check_brute_force(
        self, source_ip: str, username: str, events: list[LoginEvent]
    ) -> Optional[BruteForceAlert]:
        """Check if events match a brute force pattern."""
        window = timedelta(minutes=self._config.time_window_minutes)
        failed_events = [e for e in events if not e.success]

        if len(failed_events) < self._config.failed_threshold:
            return None

        # Check if failures cluster within the time window
        for i, start_event in enumerate(failed_events):
            window_end = start_event.timestamp + window
            window_failures = [
                e for e in failed_events[i:]
                if e.timestamp <= window_end
            ]

            if len(window_failures) >= self._config.failed_threshold:
                # Check for subsequent successful login
                success_after = any(
                    e.success and e.timestamp >= start_event.timestamp
                    for e in events
                )

                severity = self._calculate_severity(
                    len(window_failures), success_after
                )

                return BruteForceAlert(
                    username=username,
                    source_ip=source_ip,
                    failed_count=len(window_failures),
                    time_window_minutes=self._config.time_window_minutes,
                    first_attempt=window_failures[0].timestamp,
                    last_attempt=window_failures[-1].timestamp,
                    successful_login=success_after,
                    severity=severity,
                )
        return None

    def _calculate_severity(self, failed_count: int, success: bool) -> str:
        """Determine alert severity based on pattern characteristics."""
        if success and failed_count >= self._config.lockout_threshold:
            return "critical"  # Many failures + success = likely compromised
        if success:
            return "high"      # Fewer failures + success = suspicious
        if failed_count >= self._config.lockout_threshold:
            return "high"      # Many failures = active attack
        return "medium"        # Moderate failures = possible attack

MITRE ATT&CK: il Framework di Riferimento

Il framework MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) e il riferimento universale per mappare e classificare le tecniche degli avversari. Per la Detection Engineering, ATT&CK fornisce un linguaggio comune per descrivere cosa cerchiamo e una matrice per misurare la copertura delle nostre detection.

Come Usare ATT&CK per la Detection Engineering

1. Prioritizzazione - Non tutte le tecniche ATT&CK sono ugualmente rilevanti per la tua organizzazione. Identifica le tecniche più usate dagli avversari nel tuo settore (threat intelligence) e concentra le risorse su quelle.
2. Gap Analysis - Mappa le detection esistenti sulle tecniche ATT&CK per visualizzare le aree scoperte. Usa il ATT&CK Navigator per creare heatmap che mostrano la copertura attuale.
3. Tagging - Ogni regola Sigma e detection deve includere i tag ATT&CK corrispondenti (es. attack.t1003.001). Questo permette di aggregare le metriche per tecnica e tactic.
4. Misurazione - Traccia la percentuale di tecniche coperte per ogni tactic (Initial Access, Execution, Persistence, etc.) e definisci obiettivi di copertura realistici.

Struttura del Team e Ruoli

Un programma di Detection Engineering efficace richiede una combinazione di competenze che raramente si trovano in un'unica persona. La struttura del team varia in base alla dimensione dell'organizzazione, ma i ruoli chiave sono ben definiti.

Ruoli Chiave

• Detection Engineer - Il ruolo centrale. Scrive, testa e mantiene le regole di detection. Richiede competenze in threat intelligence, linguaggi di query SIEM, scripting (Python), e familiarita con i log delle piattaforme target. Secondo il SANS Survey 2025, il 60% delle organizzazioni ha almeno un detection engineer dedicato.
• Threat Intelligence Analyst - Fornisce il contesto sulle minacce: quali gruppi APT sono attivi, quali tecniche usano, quali indicatori cercare. Alimenta le ipotesi di detection con intelligence actionable.
• Data Engineer / Log Architect - Si occupa della qualità e disponibilità dei dati: onboarding di nuove sorgenti log, normalizzazione, parsing, e gestione dell'infrastruttura di raccolta.
• SOC Analyst - L'utente finale delle detection. Fornisce feedback fondamentale sulla qualità degli alert: troppi false positive? Alert non actionable? Informazioni di contesto mancanti?
• Red Team / Purple Team - Simula le tecniche degli avversari per validare le detection. Il feedback del red team e il meccanismo più efficace per migliorare la copertura e la fedelta delle regole.

Caso Reale: dall'Incidente alla Detection Pipeline

Per rendere concreti i concetti discussi, vediamo un esempio realistico che illustra l'intero percorso dalla scoperta di una lacuna alla detection in produzione.

Scenario: Compromissione via PowerShell Encoded Command

Durante un esercizio di purple teaming, il Red Team riesce a eseguire un payload malevolo utilizzando PowerShell con un comando codificato in Base64 (-EncodedCommand). L'attacco non viene rilevato dalle detection esistenti perchè queste cercavano solo specifiche stringhe di comandi PowerShell noti, non il pattern generico dell'encoding.

Step 1: Ipotesi e Analisi

Il detection engineer formula l'ipotesi: "Qualsiasi uso di PowerShell -EncodedCommand in un ambiente enterprise dovrebbe essere considerato sospetto, perchè il software legittimo raramente necessità di codificare i propri comandi." L'analisi dei log degli ultimi 30 giorni conferma: su 50.000 esecuzioni PowerShell, solo 12 usano -EncodedCommand, e tutte sono attribuibili a uno script di automazione IT noto.

Step 2: Regola Sigma

title: Suspicious PowerShell Encoded Command Execution
id: f4a3b2c1-d5e6-7890-abcd-ef0123456789
status: test
description: |
  Detects execution of PowerShell with encoded commands (-enc,
  -EncodedCommand). Legitimate use is rare in enterprise environments.
  Attackers commonly use this to obfuscate malicious payloads.
author: Federico Calo
date: 2025/12/01
modified: 2025/12/15
references:
  - https://attack.mitre.org/techniques/T1059/001/
  - https://attack.mitre.org/techniques/T1027/010/
logsource:
  category: process_creation
  product: windows
detection:
  selection_powershell:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_encoded:
    CommandLine|contains:
      - '-enc '
      - '-EncodedCommand'
      - '-encodedcommand'
      - '-ec '
  filter_known_automation:
    ParentImage|endswith: '\sccm_agent.exe'
    User|contains: 'SVC_AUTOMATION'
  condition: selection_powershell and selection_encoded and not filter_known_automation
falsepositives:
  - SCCM automation scripts (filtered)
  - Custom IT automation using encoded commands (add to filter)
level: high
tags:
  - attack.execution
  - attack.t1059.001
  - attack.defense_evasion
  - attack.t1027.010

Step 3: Test, Deploy e Risultati

La regola viene testata con 5 scenari true positive (varianti di encoded command) e 20 scenari false negative (esecuzioni PowerShell legittime). Dopo il deploy tramite pipeline CI/CD, nei primi 30 giorni la detection genera 8 alert: 6 true positive (script sospetti da analizzare), 1 false positive (nuovo script di automazione da aggiungere al filtro) e 1 true positive critico che porta alla scoperta di un accesso non autorizzato.

Conclusioni e Prossimi Passi

La Detection Engineering rappresenta un cambio di paradigma fondamentale nella sicurezza operativa. Non si tratta semplicemente di scrivere regole migliori nel SIEM, ma di costruire un processo ingegneristico completo che abbraccia l'intero ciclo di vita delle detection: dall'ipotesi di minaccia alla validazione in produzione.

I punti chiave da ricordare:

• La qualità batte la quantità - 50 detection ad alta fedelta sono infinitamente più utili di 5.000 regole che generano alert noise.
• Tratta le detection come codice - Versionamento, code review, test automatizzati e pipeline CI/CD non sono optional, sono fondamentali.
• Misura tutto - MTTD, MTTR, precision, recall, copertura ATT&CK. Senza metriche, il miglioramento continuo e impossibile.
• Parti dalla tecnica - Mappa le detection su MITRE ATT&CK e concentra le risorse sulle tecniche più rilevanti per la tua organizzazione.
• Investi nella qualità dei dati - Una detection perfetta e inutile senza i dati su cui operare. La normalizzazione e l'onboarding delle sorgenti log sono il fondamento invisibile di tutto il programma.