Anomaly detection per cybersecurity PMI: guida 2021

Il contesto 2021: ransomware industriale, PMI sotto attacco

Il 2021 è un anno spartiacque per la cybersecurity italiana. Tra gennaio e settembre 2021 il CSIRT Italia e il Clusit hanno registrato un aumento del 24% degli attacchi gravi rispetto allo stesso periodo del 2020, con il ransomware in cima alla classifica per impatto economico. Tre episodi simbolici hanno cambiato la percezione del rischio anche per la PMI: il 1 agosto 2021 il data center della Regione Lazio è stato cifrato dal gruppo RansomEXX bloccando per giorni il sistema di prenotazione vaccinale; a fine luglio 2021 il pastificio Conor ha subito un attacco con riscatto di centinaia di migliaia di euro; il 13 settembre 2021 è toccato a San Carlo, marchio storico delle patatine, con esfiltrazione di dati e doppia estorsione da parte del gruppo Conti.

Il problema operativo per la PMI italiana è netto. Il titolare medio sotto i 250 dipendenti non ha un SOC (Security Operations Center) interno, non si può permettere una licenza enterprise di Splunk da 30-50k euro/anno, e la sua sicurezza spesso si ferma a firewall perimetrale + antivirus endpoint. Quando un attacco oltrepassa il perimetro, nessuno se ne accorge prima delle 8 ore canoniche che separano la kill chain dall’impatto reale. Eppure, nel 2021 esistono tecnologie di anomaly detection basate su machine learning realmente accessibili: Wazuh è gratuito, Elastic Security ha tier free, Microsoft Sentinel si paga a consumo, scikit-learn mette a disposizione modelli pronti come Isolation Forest e LocalOutlierFactor.

Questa guida risponde a quattro domande pratiche: che cos’è l’anomaly detection e quanti tipi esistono?, quali tool nel 2021 sono davvero adatti a una PMI italiana?, come si imposta una baseline e si addestra il primo modello senza un PhD in matematica?, quanto costa in soldi e tempo arrivare a un MTTD inferiore a 30 minuti?. Ci sono anche un caso reale di una PMI fintech veneta, lo schema HowTo della roadmap 90 giorni e gli errori da non commettere al primo giro.

Cosa è anomaly detection: definizione e tre tipi di anomalie

L’anomaly detection (rilevamento anomalie) è una famiglia di tecniche — statistiche o basate su machine learning — che identifica osservazioni significativamente diverse dal comportamento atteso. Nel contesto cybersecurity le osservazioni sono eventi: login, connessioni di rete, chiamate API, accessi a file, comandi shell. La “normalità” è la baseline appresa da uno storico di log puliti.

La letteratura accademica e i playbook operativi di SOC moderni distinguono tre categorie di anomalie, con implicazioni diverse sul tipo di modello da usare.

Point anomaly (anomalia puntuale)

Un singolo evento devia dal pattern atteso. Esempio classico: un utente che normalmente trasferisce 10 MB al giorno fa improvvisamente un upload da 50 GB verso un IP esterno mai visto. È il caso più semplice e si gestisce con modelli univariati (z-score, IQR) o multivariati come Isolation Forest. La point anomaly è tipica per esfiltrazione dati, escalation di privilegi, brute force massivo.

Contextual anomaly (anomalia contestuale)

L’evento è “normale” in assoluto ma anomalo nel contesto. Esempio: un login da Roma alle 03:00 di domenica per un utente che si collega solo nei giorni feriali dalle 9 alle 18. Il login da Roma di per sé non è sospetto, lo è rispetto al pattern temporale dell’utente. Servono modelli che incorporano feature contestuali (ora, giorno, geolocalizzazione, device). Elastic ML ha job population e rare specificamente per questo. Splunk UBA è costruito attorno alle contextual anomaly del comportamento utente.

Collective anomaly (anomalia collettiva)

Una sequenza di eventi che presi singolarmente sono normali ma insieme formano un pattern sospetto. Esempio: 50 tentativi di login da 50 IP diversi verso 50 account diversi in 30 secondi — ogni singolo login fallito è banale, la sequenza è credential stuffing. O ancora: un attaccante che fa lateral movement con tante connessioni SMB interne, ognuna legittima ma il pattern di propagazione è anomalo. Richiede modelli sequenziali (LSTM, Hidden Markov Model) o algoritmi di clustering temporale.

La distinzione è cruciale perché ogni tipo richiede strumenti diversi. Un PoC sbagliato è quello che addestra un Isolation Forest per intercettare credential stuffing (problema collettivo): non funziona, e si finisce per concludere che “il ML non rileva attacchi”, quando in realtà lo strumento era sbagliato per il problema.

Approcci 2021: statistici, supervised, unsupervised, deep learning

Il panorama degli algoritmi di anomaly detection nel 2021 è maturo. Vediamo i quattro filoni con i casi d’uso tipici, partendo dal più semplice.

Statistici classici

Le tecniche statistiche restano il primo step nei progetti reali. Il z-score calcola di quanto un valore si discosta dalla media in numero di deviazioni standard: oltre ±3 è comunemente considerato anomalo. L’IQR (Interquartile Range) marca come outlier i valori fuori dall’intervallo Q1 – 1,5•IQR e Q3 + 1,5•IQR, ed è più robusto del z-score in presenza di code spesse. Per serie temporali si usa il moving average + bande di Bollinger. Pro: zero setup, computazionalmente leggeri, spiegabili al management. Contro: assumono distribuzione approssimativamente normale, non gestiscono correlazioni tra feature, esplodono in false positive su log eterogenei.

Supervised ML

Quando si ha un dataset etichettato (eventi marcati come “benigno” o “malevolo”), si addestrano classificatori. XGBoost, Random Forest, Gradient Boosting sono lo standard. Pro: accuracy molto alta quando l’etichettatura è corretta, modelli spiegabili con SHAP. Contro: richiedono un dataset etichettato pulito e bilanciato. Nel cybersecurity reale gli attacchi sono rari (1 su 10.000 eventi), quindi il dataset è sbilanciatissimo e serve oversampling (SMOTE) o cost-sensitive learning. Inoltre il modello impara solo gli attacchi visti, non quelli zero-day.

Unsupervised ML

È l’approccio più usato nella pratica SOC: nessuna etichetta, il modello impara la baseline dai dati normali e marca come anomalia tutto ciò che si discosta. I quattro algoritmi must-know nel 2021 sono:

• Isolation Forest (Liu, Ting, Zhou 2008): costruisce alberi che isolano gli outlier con pochi split. Velocissimo, scala su milioni di righe, gestisce feature numeriche e categoriche. Disponibile in scikit-learn come IsolationForest. È la prima scelta per un PoC PMI.
• One-Class SVM: addestra una hyperplane che racchiude i dati normali; tutto fuori è anomalia. Buono su dataset di dimensioni medie ma scala male oltre 10k campioni. Sensibile alla scelta di kernel e nu.
• LocalOutlierFactor (LOF): valuta la densità locale di ogni punto rispetto ai vicini. Eccellente per anomalie locali in spazi a bassa dimensionalità.
• DBSCAN e HDBSCAN: clustering basato su densità; i punti non assegnati a nessun cluster sono outlier.

La libreria PyOD (Python Outlier Detection) sviluppata da Yue Zhao raccoglie 30+ algoritmi sotto un’API uniforme ed è ormai la scelta standard per benchmarking 2021.

Deep learning

Per problemi complessi e dataset grandi entrano in scena le reti neurali. L’Autoencoder è il modello più usato in anomaly detection: si addestra a comprimere e ricostruire eventi normali; quando un evento è anomalo l’errore di ricostruzione è alto. Funziona benissimo su log strutturati di access (utente, ora, IP, URL, status). La LSTM (Long Short-Term Memory) gestisce sequenze temporali ed è lo strumento per collective anomaly: tracking di kill chain, lateral movement, command-and-control beaconing. Frameworks: TensorFlow 2.5, Keras, PyTorch 1.9. Pro: state-of-the-art su problemi non lineari. Contro: richiedono GPU per training, sono black box (XAI a parte), il debugging del modello può richiedere settimane.

Per orientarsi su quale modello scegliere a seconda del caso d’uso, è utile partire dal panorama dei casi d’uso machine learning per PMI nel 2021 che inquadra l’ecosistema lato scientifico e industriale.

Tool enterprise 2021: Splunk, Elastic, Sentinel, Darktrace, Vectra, Stealthwatch

Il segmento enterprise della cybersecurity analytics nel 2021 è dominato da sei piattaforme che includono nativamente moduli di anomaly detection. Le elenchiamo con il modello commerciale e l’idoneità per una PMI con 30-250 dipendenti.

Splunk + Splunk UBA

Splunk Enterprise è il SIEM enterprise per eccellenza; il modulo Splunk UBA (User Behavior Analytics) aggiunge profilazione comportamentale con modelli unsupervised. Splunk indicizza log di qualunque sorgente e correla eventi via il linguaggio SPL. Costo 2021: la licenza Enterprise parte da 1.800 dollari/GB/anno con sconti volume; un PoC realistico per PMI 50 dipendenti significa 75-150 GB/giorno e finisce a 60-120k euro/anno. Per la PMI media è over-budget, salvo settori regolati (banking, healthcare).

Elastic Security + Elastic ML

Elastic Security è la suite costruita su Elasticsearch 7.x, Kibana e Beats. Include Elastic ML con job preconfezionati per rare, high distinct count, time of week, population analysis. Tier free supporta deployment self-hosted e Detection Engine; tier Platinum (per ML jobs) parte da 95 dollari/nodo/mese. Per la PMI è la scelta migliore in termini di rapporto costo/potenza nel 2021. La guida alla sicurezza informatica per PMI 2021 dettaglia l’architettura ELK self-hosted.

Microsoft Sentinel

Microsoft Sentinel (rinominato da Azure Sentinel a fine 2021) è il SIEM cloud-native di Microsoft, lanciato in GA nel 2019. Pricing a consumo: circa 2,30 euro per GB ingerito + storage. Include detection ML pre-built, Fusion per correlazione multi-stage, Notebooks Jupyter per data scientist. Vantaggio per le PMI già su Microsoft 365 E5: ingestione gratuita dei log Microsoft 365 (Azure AD, Office, EDR Defender). Per una PMI con 80 endpoint Microsoft 365 si può partire con 800-1.500 euro/mese di Sentinel su un volume realistico di 25-40 GB/giorno.

Darktrace + Darktrace Antigena

Darktrace usa unsupervised ML per costruire un “pattern of life” della rete in 7 giorni e poi alertare anomalie. Darktrace Antigena aggiunge risposta automatica (rate limiting, blocco connessioni). Vantaggi: time-to-value bassissimo, riduce sensibilmente l’alert fatigue. Pricing opaco con quotazioni 25-80k euro/anno per PMI. Per organizzazioni che vogliono una soluzione “black box” che gira da sola è valida.

Vectra AI

Vectra AI è focalizzata su network detection & response (NDR) con detection di lateral movement, command-and-control, data exfiltration. Modello SaaS che ingerisce metadati di rete (non payload), copre cloud AWS/Azure/GCP e on-prem. Pricing per host monitorato. Posizionamento simile a Darktrace ma più orientata a contesti ibridi multi-cloud.

Cisco Stealthwatch (Secure Network Analytics)

Cisco Stealthwatch (oggi rinominata Secure Network Analytics) sfrutta NetFlow/IPFIX dagli apparati Cisco esistenti per fare profilazione comportamentale. Vantaggio per le PMI con LAN Cisco: appliance virtuale e modulo Flow Sensor che si integrano senza nuovi probe. Pricing per Flow Collector e telemetria gestita.

Tool open source 2021: Wazuh, ELK, Suricata, Zeek, MISP, Apache Spot, Falco

Sul fronte open source la dotazione disponibile a costo zero (escluso staff) è sorprendentemente completa nel 2021. Un’architettura PMI realistica combina tre o quattro di questi tool.

Wazuh

Wazuh è un fork open source di OSSEC che è diventato il XDR/SIEM open source più adottato. Include HIDS (Host Intrusion Detection), file integrity monitoring (FIM), rilevamento vulnerabilità, log analysis, compliance (PCI DSS, GDPR, HIPAA), e nelle release 4.x del 2021 ha aggiunto integrazione con MITRE ATT&CK e detection ML via dashboard Kibana/OpenSearch. Architettura: agent su endpoint -> manager Wazuh -> Elasticsearch -> Kibana. Per una PMI con 50 endpoint il deployment richiede 2 VM (manager + Elastic) e 8-16 ore di setup.

ELK Stack + Elastic ML free

Lo stack Elasticsearch + Logstash + Kibana (ELK 7.x nel 2021) è ormai standard per log aggregation. La parte ML è nel tier a pagamento ma per anomaly detection unsupervised semplici si può usare Elastic Alerting con threshold dinamici. Combinato con Beats (Filebeat, Auditbeat, Packetbeat) copre l’ingestione di log da OS, app, rete.

Suricata IDS

Suricata è un IDS/IPS open source ad alte prestazioni multi-threaded, capace di ispezionare traffico fino a 10 Gbit/s con ruleset Emerging Threats. Per la PMI è lo strumento principale per detection signature-based su perimetro. Si integra come fonte log per Wazuh o ELK. Disponibile come pacchetto in OPNsense, pfSense, Securonix.

Zeek (ex Bro)

Zeek (rinominato da Bro a Zeek alla release 3.0 nel 2018) è un network analyzer che produce log strutturati di altissima qualità per ogni protocollo: connessioni TCP/UDP, DNS, HTTP, SSL/TLS, SMB, SSH, file transfer. Non è un IDS classico, è un framework di scripting con cui scrivere policy custom. Per anomaly detection baseline su DNS tunneling, beaconing, exfiltration via DNS è lo strumento di scelta. Output Zeek + ingestione in Elastic = pipeline standard per detection avanzata.

MISP

MISP (Malware Information Sharing Platform) è la piattaforma open source per condivisione di IOC (Indicators of Compromise) e TTP (Tactics, Techniques, Procedures) tra organizzazioni. Sviluppata da CIRCL. Si integra con SIEM via API e arricchisce le detection con threat intelligence aggiornata da community. Nel 2021 la community italiana CSIRT-Italia e CERT-AGID partecipano attivamente.

Apache Spot

Apache Spot (originato da Open Network Insight di Intel) è un framework open source per security analytics su big data che combina flow, DNS e proxy log con modelli di topic modeling LDA per identificare anomalie. Più complesso da deployare (Hadoop, Kafka, Spark) ma utile in contesti con volumi log enormi. Nel 2021 il progetto è in stato Apache Attic ma resta tecnicamente solido.

Falco (CNCF)

Falco è il runtime security tool per container diventato progetto CNCF Incubating a gennaio 2020 e promosso Graduated nel 2021. Intercetta system call dei container Linux e applica regole per detection (es. shell aperta dentro container, scrittura su /etc, connessione verso IP non whitelisted). Per una PMI con Kubernetes è il primo livello di runtime security.

Use case PMI: brute force, exfiltration, lateral movement, credential stuffing, DDoS

I cinque casi d’uso operativi che ogni PMI dovrebbe coprire nel 2021, con il modello di anomaly detection consigliato.

Brute force login detection

Obiettivo: rilevare tentativi massivi di password su VPN, RDP, app web, SSH. Dataset: log di autenticazione (Windows Event ID 4625, sshd /var/log/auth.log, log app). Approccio: z-score sul conteggio login falliti per IP/utente in finestre di 5 minuti; alternativamente Isolation Forest con feature [n_failed, n_unique_users, n_unique_passwords, hour]. Wazuh ha regole preconfezionate.

Data exfiltration

Obiettivo: rilevare upload massivi verso destinazioni esterne. Dataset: NetFlow/IPFIX, proxy log, cloud egress. Approccio: Autoencoder su feature [bytes_out, bytes_in, dst_country, dst_asn, protocol, hour, day_of_week] con baseline per utente. Soglia errore ricostruzione al 99,5° percentile. Vectra e Darktrace hanno detection out-of-the-box.

Lateral movement

Obiettivo: rilevare propagazione dell’attaccante dentro la rete dopo compromissione iniziale. Dataset: log SMB, RDP, WinRM, autenticazione Kerberos. Approccio: graph analytics o LSTM su sequenze di connessioni interne. Pattern tipici: pass-the-hash, over-pass-the-hash, Kerberoasting. Zeek per logging strutturato di SMB/Kerberos è abilitatore chiave.

Credential stuffing

Obiettivo: rilevare attacchi automatizzati che provano combinazioni user/password rubate da altri leak. Dataset: log applicativi di login. Approccio: collective anomaly via clustering temporale + reputation IP. CAPTCHA + rate limiting + monitoring fail-rate per AS sorgente. Threat feed da MISP per IP noti.

DDoS sopra threshold

Obiettivo: rilevare attacchi volumetrici o applicativi prima che saturino i servizi. Dataset: NetFlow al perimetro, log webserver. Approccio: baseline traffico per ora del giorno con moving average + IQR; alert quando si supera la banda. Mitigazione lato CDN/Cloudflare/Akamai.

Dataset 2021 per training e benchmarking

Sviluppare un modello di anomaly detection richiede dati. Quattro dataset pubblici sono lo standard 2021 per training, testing e benchmark di algoritmi.

KDD Cup 99

Il KDD Cup 99 è il dataset storico (preso da DARPA 1998) con 4,9 milioni di connessioni di rete etichettate (normale + 4 famiglie attacco: DoS, Probe, R2L, U2R). Estremamente vecchio e con duplicati noti, ma resta il benchmark di riferimento per confrontarsi con letteratura. NSL-KDD è la versione ripulita (rimossi duplicati, ribilanciata).

CICIDS 2017

Il dataset CICIDS 2017 del Canadian Institute for Cybersecurity contiene traffico realistico generato in 5 giorni con attacchi etichettati (DoS, DDoS, Heartbleed, Web Attack, Infiltration, Botnet, PortScan, Brute Force). 80+ feature estratte con CICFlowMeter. È il dataset moderno preferito per evaluation di modelli ML su network anomaly detection.

UNSW-NB15

UNSW-NB15 dell’Università di New South Wales aggiunge famiglie di attacco moderne (Fuzzers, Backdoor, Exploits, Generic, Reconnaissance, Shellcode, Worms) su traffico reale catturato. 49 feature, ~2,5 milioni di record. Spesso usato in combinazione con CICIDS per modelli più robusti.

HDFS log e BGL

Per log-based anomaly detection sono standard i dataset HDFS (Hadoop Distributed File System) di LogPAI e BGL (Blue Gene/L) di Los Alamos. Utili per testare LSTM e Autoencoder sequenziali. L’esperienza accumulata su NLP per sentiment analysis nel 2021 è trasferibile al log parsing, dove il template extraction usa tecniche simili.

Stack Python 2021: scikit-learn, PyOD, TensorFlow, Pandas

Costruire un PoC di anomaly detection nel 2021 con Python è questione di 200 righe di codice. Lo stack standard è consolidato.

scikit-learn 0.24+

scikit-learn 0.24 (uscita dicembre 2020) include implementazioni production-ready di IsolationForest, OneClassSVM, LocalOutlierFactor, EllipticEnvelope. API uniforme con fit/predict/decision_function. Sklearn 1.0 esce a settembre 2021 con miglioramenti su stabilità API e nuove feature.

PyOD 0.9+

PyOD (Python Outlier Detection) di Yue Zhao è la libreria specializzata. 30+ algoritmi sotto API unificata, da quelli classici (LOF, Isolation Forest) a moderni (DeepSVDD, AutoEncoder). Indispensabile per fare benchmarking veloce di più modelli sullo stesso dataset. Documentazione molto curata e referenze accademiche.

TensorFlow 2.5 + Keras

TensorFlow 2.5 (maggio 2021) è il framework di scelta per Autoencoder e LSTM. API Keras semplifica drasticamente il setup di reti neurali. Per anomaly detection con autoencoder: input layer -> bottleneck (es. 8 neuroni) -> output layer, loss MSE, training su soli dati normali. PyTorch 1.9 è l’alternativa con maggiore controllo dinamico.

Pandas + NumPy + Joblib

Per pre-processing log si usa Pandas 1.3 per data wrangling, NumPy 1.20 per operazioni vettoriali, Joblib per parallelizzare training su più CPU. Per serie temporali statsmodels 0.13 fornisce SARIMA, Holt-Winters, decomposizione stagionale.

Esempio minimale Isolation Forest in produzione

from sklearn.ensemble import IsolationForest
import pandas as pd
import joblib

# 1. Caricamento e feature engineering log auth
df = pd.read_csv("auth_logs.csv")
features = df[["n_failed_login", "n_unique_user",
               "hour", "src_asn_rep", "is_weekend"]]

# 2. Training su 30 giorni di log "puliti"
model = IsolationForest(
    n_estimators=200,
    contamination=0.01,
    random_state=42
)
model.fit(features)
joblib.dump(model, "iforest_auth.pkl")

# 3. Scoring real-time su nuovi eventi
scores = model.decision_function(new_events)
new_events["anomaly_score"] = scores
alerts = new_events[scores < -0.15]  # soglia tunata

Lo stesso pattern si applica con PyOD per comparare 5-10 algoritmi su un singolo dataset e scegliere il vincitore. Per chi vuole automatizzare la pipeline di estrazione log da SIEM verso modelli Python, l’integrazione tipica passa da API REST con autenticazione robusta verso il SIEM stesso o da un connettore Kafka.

Integrazione con SIEM esistente e ticket auto-generation

Un modello di detection senza integrazione operativa è un esercizio accademico. Le anomalie rilevate devono entrare nel workflow del team IT/security via SIEM, ticketing, paging.

SIEM come hub

Il SIEM (Splunk, Elastic, Sentinel, Wazuh) rimane il punto di aggregazione: l’output del modello Python pubblica eventi in un indice dedicato (es. ml-alerts-* su Elastic) via API o syslog. Il SIEM applica regole di correlazione tra alert ML e altri eventi (IDS, log auth, EDR) per produrre incident consolidati. Vantaggio: visualizzazione centralizzata, retention compliance, link con threat intel da MISP.

Ticket auto-generation

Per la PMI il workflow tipico nel 2021 è: alert SIEM -> webhook verso ticketing -> assegnazione automatica per categoria. Strumenti diffusi:

• PagerDuty: gestione incident con escalation e on-call schedule. Integration con Splunk, Sentinel, Elastic out-of-the-box.
• OpsGenie (Atlassian): alternativa con integration con Jira Service Management.
• Jira Service Management: per ticket dettagliati con SLA e workflow custom.
• ServiceNow: per organizzazioni ITSM strutturate; spesso integrato con Splunk Phantom o IBM Resilient per orchestrazione.

La regola d’oro è: ogni alert deve avere un severity, un playbook di risposta e un responsabile assegnato. Senza queste tre cose il sistema produce solo rumore. Una pipeline di automazione ben fatta riprende i principi di automazione processi aziendali per PMI 2021 applicandoli al ciclo di vita dell’incident.

SOAR (Security Orchestration, Automation, Response)

Per organizzazioni con volumi alti di alert le piattaforme SOAR orchestrano risposte automatiche: isolamento endpoint via EDR, blocco IP su firewall, disabilitazione utente AD, snapshot per forensics. Soluzioni 2021: Splunk Phantom, Palo Alto Cortex XSOAR, IBM Resilient. Per la PMI con budget contenuto si possono ottenere automazioni di base con script Python attivati da webhook.

Compliance 2021: GDPR Art. 32, NIS Direttiva 2016/1148, ISO 27001

L’anomaly detection non è solo good practice tecnica: aiuta a dimostrare conformità a vari obblighi normativi che insistono su PMI italiane nel 2021.

GDPR Art. 32 – Misure tecniche e organizzative

Il GDPR all’art. 32 impone al titolare di adottare misure tecniche e organizzative adeguate al rischio per garantire riservatezza, integrità, disponibilità e resilienza dei sistemi. Tra le misure raccomandate dal Garante Privacy italiano: monitoraggio degli accessi, log analysis, incident detection. Un sistema di anomaly detection ben documentato è evidenza diretta di compliance, utile in caso di ispezione o audit post-breach. La guida GDPR aziendale per PMI 2021 elenca le 18 misure tecniche più richieste in audit.

NIS Direttiva 2016/1148 – D.Lgs. 65/2018

La NIS Direttiva (UE 2016/1148, recepita in Italia con il D.Lgs. 65/2018) impone obblighi di sicurezza e notifica incidenti a operatori di servizi essenziali (energia, trasporti, sanità, finanza) e a fornitori di servizi digitali. Una PMI che fornisce servizi cloud, marketplace online o motori di ricerca rientra nella categoria DSP. La NIS richiede misure di rilevamento incidenti e notifica al CSIRT Italia entro 24 ore. Anomaly detection facilita il rilevamento tempestivo. Per approfondimenti operativi vedi la guida NIS Direttiva cybersecurity 2021.

ISO 27001:2013 e ISO 27035

La ISO 27001:2013 al controllo A.12.4 “Logging and monitoring” richiede event logging, monitoring activities, protezione log, log amministratori. Lo standard ISO 27035 (Information Security Incident Management) dettaglia il ciclo di vita dell’incident: planning, detection, assessment, response, lessons learned. Un sistema di anomaly detection fornisce evidenze concrete per certificazione ISO 27001 e per soddisfare A.12.4.

CSIRT Italia, CERT-AGID, GARR-CERT

Nel 2021 il panorama italiano della incident response è consolidato: il CSIRT Italia (operativo da maggio 2020 presso ACN/DIS) è il punto nazionale di notifica per soggetti NIS; CERT-AGID serve la PA; GARR-CERT serve il mondo accademico e ricerca. Tutti pubblicano feed di IOC che si integrano via MISP.

Errori comuni: baseline sbagliata, alert fatigue, false positive ignorati

Cinque errori ricorrenti nei primi sei mesi di adozione di anomaly detection, raccolti da progetti PMI italiane nel 2021.

1. Baseline troppo corta o “sporca”

Addestrare il modello su 7 giorni di log è troppo poco: si perdono variazioni settimanali e mensili. Addestrare su 90 giorni che includono già un attacco (non noto) significa che il modello considera l’attacco “normale”. Buona prassi: 30-60 giorni di log puliti certificati, escluse finestre di anomalia note.

2. Alert fatigue

Un modello tarato male produce 500+ alert/giorno e il team smette di guardarli. Il risultato è peggio del non avere il sistema (false sense of security). Tuning della soglia, raggruppamento alert correlati, scoring di priorità: tutto necessario. Target realistico: 10-30 alert/giorno di cui >70% azionabili.

3. Ignorare i false positive

Marcare manualmente i FP è faticoso e nessuno lo fa. Risultato: nessun feedback per ri-tarare il modello, e nel tempo l’accuracy degrada (concept drift). Buona prassi: integrare il labeling FP/TP dentro il ticketing e fare retraining mensile.

4. Modello senza spiegabilità

Un alert “Autoencoder con score 0,89” non è azionabile. Il SOC analyst deve sapere quali feature hanno contribuito. SHAP, LIME o approccio shadow tree forniscono spiegazione. Per Isolation Forest esiste IsolationForestExplainer.

5. Mancanza di playbook di risposta

Rilevare un’anomalia è il 30% del lavoro. Il 70% è rispondere bene. Senza un playbook per ogni categoria di alert (es. “data exfiltration sospetta: isolare host, dump RAM, raccogliere log proxy/EDR ultimi 7 giorni, notifica DPO”) la detection non porta valore concreto.

Caso reale: PMI veneta fintech, MTTD da 8 ore a 12 minuti con Autoencoder

Una PMI fintech del Vicentino che fornisce gestione cassa e tesoreria a 400 PMI italiane ha avviato a febbraio 2021 un progetto di anomaly detection per ridurre il rischio di esfiltrazione dati. Il contesto: 35 dipendenti, 6 nel team IT (nessuno SOC analyst dedicato), regolamentazione PSD2/Banca d’Italia. Lo stack pre-progetto era firewall Fortinet + AV Sophos + log raccolti in Wazuh ma poco analizzati.

Pain point iniziale

Una simulazione interna di marzo 2021 (penetration test commissionato) aveva mostrato che un attaccante con accesso a un endpoint impiegava in media 8 ore a esfiltrare 50 GB di dati cliente senza essere rilevato. MTTD = 8 ore = troppo per restare conformi alle aspettative PSD2 in caso di reale incidente.

Soluzione implementata

Architettura scelta: Wazuh + Elastic 7.14 + un servizio Python custom con TensorFlow 2.5. Il modello: un Autoencoder con 5 layer (input 24 feature -> 12 -> 6 -> 12 -> 24, MSE loss) addestrato su 45 giorni di access log puliti (3,2 milioni di eventi). Feature: utente, ora, IP sorgente, ASN, dimensione upload, dimensione download, protocollo, dst country, dst port, rep IP, flag working hours, device fingerprint, conteggio rolling 1h, 24h, 7d, ratio bytes_in/out. Output: anomaly score = errore ricostruzione normalizzato.

Risultato dopo 4 mesi

Il modello in produzione produce circa 18 alert/giorno con ~74% azionabili. MTTD medio sceso a 12 minuti per scenari simulati di data exfiltration. Il momento clou: a luglio 2021 il sistema ha intercettato un tentativo reale di esfiltrazione (account interno compromesso con phishing): l’Autoencoder ha alertato alla terza connessione anomala verso un IP romeno mai visto, con upload di 1,2 GB su un totale stimato di 30 GB. Il team IT ha isolato l’endpoint, revocato credenziali, notificato DPO e CSIRT, completando contenimento in 38 minuti. Senza il sistema, l’attaccante avrebbe completato l’esfiltrazione di 30 GB di dati cliente.

Investimento e ROI

Setup totale: 4.800 euro di consulenza esterna per architettura e training modello + 22 giornate interne IT. Costo run rate: 380 euro/mese (cloud + 1 manday/mese manutenzione). ROI calcolato sulla riduzione del rischio: una sola violazione evitata con esfiltrazione 30 GB di dati cliente avrebbe esposto la PMI a sanzioni GDPR fino al 2% del fatturato (circa 180.000 euro) più danno reputazionale incalcolabile. Payback effettivo: meno di 6 mesi.

Roadmap operativa 90 giorni: dalla baseline al primo alert reale

La traduzione operativa della checklist HowTo per una PMI tipica 50-150 dipendenti.

Mese 1 (giorni 1-30): foundation

Settimana 1: assessment sorgenti log (Active Directory, server Windows/Linux, firewall Fortinet/Sophos/SonicWall, switch, app web, endpoint). Settimana 2: deploy Wazuh manager + agent su tutti i server e 80% degli endpoint. Settimana 3: configurazione Suricata al perimetro + Zeek su SPAN port per network metadata. Settimana 4: 7 giorni di raccolta log + verifica completezza, hash di integrità, retention 90 giorni.

Mese 2 (giorni 31-60): modeling

Settimana 5: data exploration con Jupyter, identificazione feature, pulizia dataset, esclusione finestre note di manutenzione/test. Settimana 6: training di Isolation Forest, LOF, One-Class SVM su access log; benchmark via PyOD. Settimana 7: training Autoencoder TensorFlow 2.5 con architettura 24-12-6-12-24. Settimana 8: red team interno con scenari brute force, data exfiltration sintetica, lateral movement; misura recall e false positive rate.

Mese 3 (giorni 61-90): operativo

Settimana 9: integrazione output modello con Elastic via Kafka/HTTP API, dashboard Kibana dedicata. Settimana 10: webhook verso ticketing (PagerDuty/Jira), severity mapping, definizione 5 playbook per le categorie di alert principali. Settimana 11: tabletop exercise con team IT, retest scenari, calibrazione soglie. Settimana 12: documentazione formale per audit ISO 27001 / NIS, training team, kickoff retraining mensile.

KPI di successo

• MTTD < 30 minuti su scenari simulati
• MTTR < 2 ore per incident di severità alta
• Alert volume < 30/giorno con > 65% azionabili
• False positive rate < 25% dopo tuning
• Coverage MITRE ATT&CK > 40% delle tecniche T1xxx più rilevanti per il settore

La maturità ML in produzione richiede infrastruttura adeguata: se il piano cloud non è ancora chiaro, vedi la guida cloud aziendale per PMI 2021.

FAQ — Domande frequenti su anomaly detection cybersecurity PMI

Quanto costa avviare un sistema di anomaly detection per una PMI nel 2021?

Con uno stack open source (Wazuh + Elastic 7.x tier free + script Python custom) il setup parte da 3.500 a 12.000 euro di consulenza/sviluppo + 600-1.500 euro/mese di gestione (cloud + manutenzione). Con Microsoft Sentinel SaaS si paga a consumo: per PMI 50-100 endpoint il TCO si attesta intorno a 1.000-2.000 euro/mese.

Serve avere un data scientist in azienda?

No nel 2021 per il livello PoC e prima produzione. Wazuh, Elastic ML e Microsoft Sentinel hanno modelli pre-confezionati che non richiedono coding ML. Per modelli custom Autoencoder o LSTM serve un consulente esterno per 15-25 giornate, sufficienti per avviare il sistema e formare un IT specialist interno alla manutenzione.

L’anomaly detection sostituisce antivirus, firewall e EDR?

No, si affianca. L’anomaly detection aggiunge un livello di rilevamento comportamentale che intercetta attacchi nuovi (zero-day) e minacce interne che le firme antivirus non vedono. Antivirus, firewall, EDR restano la prima linea di difesa basata su signature e regole; il ML rileva l’inatteso.

Quanti false positive sono accettabili?

Target realistico nel primo trimestre: < 30 alert/giorno con il 65-75% azionabili. Dopo 3-6 mesi di tuning si può arrivare a 10-15 alert/giorno con il 75-85% azionabili. Sopra il 25-30% di false positive il team perde fiducia nel sistema (alert fatigue).

Posso usare l’anomaly detection per dimostrare conformità GDPR?

Sì. L’art. 32 GDPR impone misure tecniche adeguate al rischio. Un sistema documentato di anomaly detection è evidenza concreta di “misura tecnica” da esibire in caso di audit Garante Privacy o nel quadro della valutazione d’impatto (DPIA). Stesso ragionamento per ISO 27001:2013 controllo A.12.4 e per la NIS Direttiva per soggetti DSP.

Quale algoritmo scegliere per partire?

Nel 2021 la prima scelta per un PoC PMI è Isolation Forest in scikit-learn: addestramento veloce, gestisce milioni di righe, parametri minimi da tarare, robust ai dati rumorosi. Si passa a Autoencoder TensorFlow quando si hanno > 1 milione di eventi/giorno e si vogliono catturare correlazioni non lineari complesse.

Cosa fare se l’attaccante è già nella baseline?

Se il dataset di training contiene attività dell’attaccante non rilevata, il modello la considererà “normale”. Mitigazioni: confrontare la baseline con feed di threat intelligence (MISP, CERT-AGID), cercare IOC noti nello storico, eseguire un assessment di compromissione (compromise assessment) prima di certificare la baseline come pulita.