Threat Monitoring — Avvisi per Parola Chiave
Sorveglianza ricorrente per termini sull’archivio che la piattaforma raccoglie: Telegram, WhatsApp, forum, social network, siti .onion, paste site, repository di codice, feed di IOC, banche dati di credenziali e log di infostealer. Un monitoraggio descrive ciò che interessa; la raccolta gira su una propria pianificazione e ciò che corrisponde diventa un avviso da sottoporre a triage.
Panoramica
Ogni monitoraggio ha un nome univoco all’interno dell’organizzazione, una categoria (dodici opzioni, dal rilevamento delle minacce alla protezione degli executive), un team responsabile (SOC, CSIRT, Threat Intelligence, DevSecOps, Compliance, Risk, Antifrode, Protezione dei Dati), una priorità e uno stato.
La frequenza va da 1 minuto a 30 giorni. Il tempo massimo di esecuzione arriva a 2 ore e il numero di nuovi tentativi in caso di errore è configurabile fino a dieci. L’esecuzione è orchestrata da Airflow: l’avvio manuale accoda il DAG e lo storico conserva ogni esecuzione con durata, esito e andamento.
I termini restano crittografati a riposo. Parole chiave, elenco dei termini, comandi di ricerca e descrizione del monitoraggio sono salvati in campi cifrati. Ciò che un’organizzazione sorveglia è, di per sé, un’informazione sensibile: rivela quale asset, quale dirigente e quale marchio sono a rischio.
Come viene costruita la ricerca
I termini diventano clausole di frase obbligatorie su quattro campi dell’avviso — titolo, descrizione, dato grezzo e fonte. Ai termini si aggiungono gli operatori:
- AND aggiunge termini obbligatori;
- OR crea un gruppo in cui almeno un termine deve comparire;
- NOT esclude il documento che contenga uno qualsiasi dei termini.
Dopo l’interrogazione c’è un secondo passaggio di filtraggio su ciò che è tornato. Tratta il termine singolo con il confine di parola e l’espressione con lo spazio come sottostringa — è quello che impedisce a bin di corrispondere dentro binario e che, allo stesso tempo, consente di far corrispondere “carta di credito” come frase intera. I due stadi esistono perché la sola esclusione in fase di interrogazione non basta a gestire la negazione su campi annidati.
Triage, non un’inondazione
Un avviso nasce in attesa. L’analista lo contrassegna come valido oppure ignorato, e questa decisione resta registrata con autore, data, gravità assegnata e l’eventuale marcatura di falso positivo. Le tre code si consultano separatamente, con filtri per titolo, gravità, parola che ha corrisposto, famiglia di stealer e presenza di dati di carte di pagamento.
Nel frattempo uno strato di espressioni regolari etichetta l’avviso in dieci categorie — credenziali, frode, fuga di dati, abuso del marchio, phishing, dark web, malware, executive, infrastruttura e social network. L’etichetta orienta la coda; non decide nulla.
Il monitoraggio accetta anche una configurazione di triage dichiarativa: ambito, entità monitorate, livelli di parola chiave per criticità, parole negative, pattern di validazione e di scarto automatico, fonti benigne note, finestra di deduplicazione in ore e soglia di punteggio. È il modo per dire “ignora le menzioni in contesto accademico” senza riscrivere l’interrogazione.
Funzionalità
- 112 fonti di raccolta mappate su indici dedicati
- Sintesi IA facoltativa per avviso, con schema chiuso dei tipi di minaccia — e filtro per vedere solo gli avvisi con o senza sintesi
- Incrocio con l’archivio delle fughe di dati (combolist) e con i pacchetti di infostealer, incluso il filtro per famiglia di stealer
- Gli avvisi diventano voci di un incidente o di un report, singolarmente o in blocco
- Esportazione degli avvisi in XLSX
- Soft delete con autore e data, versionamento della configurazione e storico di otto tipi di modifica
- Dizionario degli asset dell’organizzazione con 41 categorie in dieci gruppi, che alimenta i termini del monitoraggio
Casi d’uso
- Seguire le menzioni del marchio e dei dirigenti su forum e canali chiusi
- Rilevare credenziali aziendali nei pacchetti di infostealer, con la famiglia identificata
- Sorvegliare la campagna di un attore specifico combinando termini positivi e negativi
- Alimentare la coda del SOC con avvisi già categorizzati e prioritizzati
Ciò che il modulo non fa
- I canali di avviso sono e-mail, Slack e webhook. Non esiste una consegna nativa su Microsoft Teams né su Discord — per quelli si usa il webhook.
- La sintesi IA non decide se l’avviso è valido. La validazione spetta all’analista, ed è quella che resta registrata.
- La categorizzazione automatica è lessicale, basata su pattern di testo. Non è un classificatore addestrato e non ha un tasso di accuratezza pubblicato.
- Non esiste un riprocessamento retroattivo automatico dello storico quando si aggiunge un nuovo termine al monitoraggio.
Integrazioni
- Slack, e-mail e webhook personalizzati
- Airflow (orchestrazione delle esecuzioni) e OpenSearch (archivio della raccolta)
- OODA Leaks, OODA Incident, OODA Reports e l’API REST della piattaforma
SLA e garanzie
Frequenza da 1 minuto a 30 giorni · termini crittografati a riposo · ogni validazione di avviso è firmata