Esaminare i dati NDR locali nell'Investigation Console

La NDR Investigation Console rende disponibili i dati locali dei sensori NDR assegnati, non soltanto quelli trasferiti nel Sophos Data Lake. Questo runbook descrive il percorso da un’ipotesi in Dashboard > Overview a una query ClickHouse mirata in Query. Tutte le query descritte sono di sola lettura.

L’Investigation Console non è intercambiabile con questi percorsi di interrogazione:

Un risultato dell’Investigation Console non costituisce ancora un incidente confermato. Trasmetti i riscontri sospetti secondo il processo SOC, XDR o MDR applicabile. Le misure di risposta non rientrano in questo runbook.

Accesso, ruoli e incarico dell’indagine

Usa un account personale con le autorizzazioni necessarie per l’incarico. L’account locale dell’Investigation Console è distinto dai ruoli in Sophos Fusion. Se manca Query, uno schema necessario o un pulsante, chiedi all’amministratore responsabile di verificare l’account locale e la console selezionata. Se manca già il punto di accesso da Sophos Fusion o un successivo pivot nel cloud, verifica separatamente la licenza, il ruolo Fusion e, per i Custom Roles, l’ambito del prodotto. Non ampliare un ruolo senza una ragione verificata.

Prima dell’indagine devono essere definiti questi elementi:

• un’ipotesi concreta, per esempio la comunicazione di un IP di destinazione autorizzato tramite protocolli inattesi;
• il sensore o il segmento di rete interessato e i sistemi di origine o destinazione previsti;
• l’inizio, la fine e il fuso orario dell’evento;
• un ticket o un Case in cui annotare le informazioni e la persona che prenderà in carico un riscontro sospetto;
• le modalità consentite di trattamento di indirizzi IP, nomi host e risultati esportati.

La console deve essere raggiungibile e ricevere dati da almeno una NDR Integration Appliance. Il solo fatto che l’accesso riesca non dimostra né che i dati dei sensori siano aggiornati né che la copertura del traffico replicato sia completa.

1. Restringere l’intervallo temporale e i sensori interessati nella dashboard

Dopo l’accesso, la console apre Dashboard > Overview. La pagina mostra Total Indicators, Network Traffic, Total Indicators By Severity, Total Indicators By Type, Geolocation Map e Recent flow detections. Back riporta a Sophos Fusion. This Appliance mostra i dettagli del sistema e non è necessario per questa indagine.

1. In Filters, apri prima Time Range. L’impostazione predefinita è Last 1 hour.
2. Per un incidente noto, seleziona Absolute time range e inserisci l’ora di inizio e di fine, includendo un margine di contesto sufficiente prima e dopo l’evento. Per una prima panoramica può bastare un quick range come Last 7 days. Conferma con Apply time range.
3. Tieni presente il limite dei dati: la console rende disponibili soltanto gli ultimi 30 giorni. Un intervallo più lungo non restituisce ulteriori dati locali. L’assenza di una corrispondenza meno recente non costituisce quindi una conferma negativa.
4. In Filters, seleziona una colonna del database disponibile, l’operatore appropriato e un valore. Sophos indica come esempio MasterProtocol, Equals e HTTP. Per le colonne numeriche sono disponibili operatori come =, < o >=.
5. Aggiungi soltanto i criteri pertinenti all’ipotesi. Dopo aver configurato ciascun criterio, fai clic prima su Add per includerlo nel filtro e poi su Apply. Verifica che i grafici e la tabella riflettano ora l’intervallo temporale e i filtri selezionati.
6. Usa Save As soltanto per un filtro stabile e con un nome comprensibile. L’icona di salvataggio sovrascrive un filtro esistente. Con Clear rimuovi le impostazioni attuali dei filtri.

Annota i filtri, l’intervallo temporale e il fuso orario. Confronta quindi almeno due rappresentazioni indipendenti:

• Total Indicators mostra gli IoC di tipo DGA, IDS, EPA e SRA. Facendo clic su un tipo lo visualizzi o lo nascondi nel grafico a barre. Passando il puntatore su una barra vengono mostrati l’ora e il valore.
• Network Traffic mostra la velocità dei dati in Mbit/s, i pacchetti al secondo e i flussi al secondo. Passando il puntatore sul grafico puoi vedere il volume dei dati inviati e ricevuti in gigabyte.
• Total Indicators By Severity raggruppa i dati in Critical, High, Medium, Low e Info. Total Indicators By Type mostra gli stessi tipi di IoC in un grafico ad anello.
• Geolocation Map si basa su raggruppamenti di indirizzi IP. Una regione offre un punto di partenza per l’indagine, ma non dimostra né la posizione effettiva né la natura malevola di un host.
• Recent flow detections mostra i flussi di rete sospetti. Esamina i dettagli disponibili dei flussi e verifica nomi e significato dei campi rispetto allo schema corrente, anziché basarti soltanto su un picco nel grafico.

Se la dashboard e la tabella non coincidono per lo stesso intervallo, riduci la finestra temporale e controlla i filtri attivi. Solo dopo avvia una query personalizzata.

2. Iniziare con una query predisposta

Apri Query e resta inizialmente nella scheda Library. Per questo runbook usa esclusivamente singole query SELECT di sola lettura. Per modificare le query o crearne di nuove sono necessarie conoscenze di ClickHouse SQL. Sono esclusi i comandi che modificano dati, tabelle, schemi, utenti, autorizzazioni o impostazioni del server.

Inizia con una query preconfigurata adatta alla tua ipotesi:

1. In Library, espandi la categoria appropriata e apri la query.
2. Leggi il testo completo. Verifica tabelle, campi, condizione temporale, raggruppamento, ordinamento ed eventuale limite dei risultati rispetto alla tua ipotesi.
3. Passa a Schema. Espandi il nome dello schema e conferma, per ogni tabella utilizzata, i nomi e i tipi dei campi. Non ricavare i nomi dei campi da esempi relativi al Data Lake o ad Appliance Manager.
4. In base allo schema corrente, limita la query SELECT all’intervallo necessario e, se possibile, a un singolo indicatore, host, IP di origine o di destinazione oppure protocollo. Modifica una condizione temporale preconfigurata soltanto se il campo e la sintassi ClickHouse sono inequivocabili.
5. Fai clic una sola volta su Run. I risultati vengono visualizzati sotto la query. Fare clic ripetutamente non accelera l’esecuzione e rende più difficile associarla alla voce corretta in History.
6. Amplia l’ambito dell’indagine soltanto quando la prima esecuzione è riuscita e il risultato è plausibile e gestibile.

Usare variabili ed esempi in modo sicuro

Se una query predisposta contiene una variabile come @DestIp, sulla sinistra compare un campo di immissione. Protocols For Destination IP è un esempio documentato. Usa questo campo e non modificare contemporaneamente la sostituzione della variabile, la tabella e la logica dei filtri.

Per un semplice controllo della sintassi o della procedura usa soltanto un indirizzo autorizzato a tale scopo. 192.0.2.10 appartiene a una rete riservata alla documentazione e qui serve esclusivamente come esempio di formato. Non è detto che restituisca risultati e non è un indicatore di produzione. Gli indirizzi IP, i domini e i nomi host reali devono provenire dal ticket autorizzato, non da esempi arbitrari.

Durante il salvataggio, la console può inserire il valore della variabile nel testo della query. Per esempio, @DestIp viene sostituito dall’indirizzo utilizzato. Controlla quindi il testo prima dell’esecuzione successiva. Salva una variante modificata con Save As, usando un nome che ne descriva finalità e ambito, e non sovrascrivere la query preconfigurata originale. Poiché le query salvate possono contenere indicatori riservati, si applica la classificazione locale dei dati.

Per creare una categoria, fai clic sull’icona più in alto a destra in Library, inserisci nome e descrizione e conferma con Create. Per una nuova query, inserisci a destra il testo SELECT verificato, provalo con Run e seleziona Save As. Scegli la categoria, inserisci un nome e conferma con Create. Salva soltanto query verificate e riutilizzabili.

La console condivide le risorse con l’archiviazione e la visualizzazione dei dati locali. Applica quindi fin dall’inizio un filtro temporale e uno relativo a un campo selettivo. Limita i risultati con un metodo già usato in Library e verificato per ClickHouse; durante il primo test non rimuovere un limite esistente. Prima di usare JOIN, sottoquery, raggruppamenti estesi o ordinamenti, controlla lo Schema corrente ed esegui una prova con una finestra temporale ridotta. Non copiare nella console una query Data Lake SQL. Prima di eseguire query provenienti da ticket, chat o esempi pubblici, leggile integralmente e confrontale con Schema.

3. Convalidare i risultati

Una query eseguita correttamente non è automaticamente corretta anche nei contenuti. Verifica il risultato in questo ordine:

1. Ambito dell’indagine: la finestra temporale, il fuso orario, i sensori interessati e i filtri corrispondono esattamente all’incarico? L’evento rientra nei 30 giorni disponibili localmente?
2. Schema: i tipi e il significato dei campi corrispondono a Schema? Verifica in particolare che gli indirizzi IP, i valori temporali e i conteggi siano interpretati correttamente.
3. Riscontro di controllo: cerca un flusso noto e atteso nello stesso intervallo ristretto. Se manca anche questo, un risultato vuoto non è attendibile.
4. Confronto con la dashboard: l’ordine di grandezza e l’andamento temporale sono coerenti con Network Traffic, gli IoC o Recent flow detections? I valori aggregati della dashboard e le singole righe non devono necessariamente coincidere, ma eventuali discrepanze richiedono una spiegazione.
5. Controprova: rimuovi esattamente un filtro restrittivo oppure sposta la finestra temporale in modo controllato. Una differenza plausibile dimostra che la condizione è efficace. Non modificare mai più condizioni contemporaneamente.
6. Documentazione: registra nel ticket il nome o il testo della query, le variabili, l’intervallo temporale con il fuso orario, l’ora di esecuzione, il numero di risultati e le righe pertinenti. Tratta i risultati come dati di rete potenzialmente sensibili.

Apri quindi History. La console mostra il tipo di utente, la data e l’ora, il numero di risultati e lo stato successful o failed. Associa la voce alla tua esecuzione. History dimostra che la query è stata eseguita, ma non che sia completa o corretta.

Circoscrivere gli errori e ripristinare una condizione sicura

La dashboard è vuota

Controlla Time Range, i Saved Filters attivi e Filters. Seleziona un intervallo breve in cui è previsto traffico di rete e rimuovi i filtri con Clear. Se anche Network Traffic resta vuoto, il problema non dipende da una query personalizzata. Verifica di avere aperto la console corretta e che il sensore previsto o l’appliance responsabile stia fornendo dati. Lo stato verde di un’appliance non dimostra che la copertura del traffico replicato sia completa. Inoltra al processo operativo o di supporto l’intervallo temporale, il flusso atteso, la console e il sensore interessato, anziché estendere l’intervallo oltre 30 giorni.

La query restituisce zero righe

Conferma l’intervallo temporale e il fuso orario. In Schema, verifica che la tabella, il nome del campo e il tipo siano aggiornati. Rimuovi quindi esattamente il filtro funzionale più restrittivo ed esegui nuovamente la query una sola volta. Prova inoltre un valore noto e atteso nella stessa finestra temporale. Se neppure una query preconfigurata e non modificata restituisce i dati attesi, verifica il percorso dei dati e i sensori interessati. Un risultato vuoto non dimostra che l’attività sia assente.

La query risulta failed

Individua la voce corrispondente in History e annota lo stato, il testo della query e l’ora di esecuzione. Verifica la sintassi, i nomi e i tipi dei campi rispetto a Schema. Apri da Library l’ultima query non modificata che in precedenza funzionava, limita la relativa istruzione SELECT al più breve intervallo significativo e imposta un solo valore di variabile convalidato. Avvia esattamente una nuova esecuzione. Se la query preconfigurata risulta ancora failed, documenta l’errore ed esegui l’escalation. Non aggirarlo con comandi di scrittura, modifiche allo schema o impostazioni del server.

La query impiega un tempo insolitamente lungo o sovraccarica la console

Non fare nuovamente clic su Run. Annota l’ora di inizio, l’utente e il nome della query. Non avviare un’altra query estesa. Al termine, verifica in History se l’esecuzione è risultata successful o failed e quanti risultati ha prodotto. Se l’interfaccia rimane lenta, interrompi il lavoro sulle query e segnala l’osservazione al team che gestisce la console. Il riavvio o lo spegnimento non rientrano in questo runbook.

Tornare a una query funzionante

1. Interrompi le ulteriori esecuzioni della stessa variante. Non avviare rapidamente altri tentativi né un’altra query di controllo estesa.
2. Se l’interfaccia risponde, copia il testo della query e annota l’ora di inizio, i filtri, le variabili e la voce associata in History. Non salvare la variante difettosa come nuova query standard.
3. Riapri da Library la query preconfigurata originale. Verifica che non siano stati mantenuti valori delle variabili già inseriti o modifiche non salvate.
4. In base allo schema confermato, limita la query SELECT a un breve intervallo, a un valore convalidato e a una quantità ridotta di risultati. Verifica nuovamente tabelle e campi in Schema.
5. Esegui un’unica prova di lettura già completata con successo in precedenza. Controlla il risultato e History.
6. Se anche questa prova non riesce o la console resta compromessa, termina l’indagine ed esegui l’escalation con le informazioni raccolte. Non usare comandi di riparazione, eliminazione o smantellamento del database.

Conclusione e passaggio di consegne

Al termine documenta l’ipotesi, la console utilizzata, i sensori interessati, la finestra temporale con il fuso orario, i filtri della dashboard, la query eseguita, le variabili, lo stato in History e il numero di risultati. Trasmetti i riscontri positivi tramite il processo SOC, XDR o MDR esistente. Un risultato negativo significa soltanto che non è stato trovato nulla nell’ambito locale documentato dell’indagine. Non dimostra che l’attività sia assente dall’intera rete.

Rimuovi i valori di esempio sensibili da una definizione di query necessaria soltanto temporaneamente oppure chiariscine i termini di conservazione consentiti con la persona responsabile di Library.

Domande frequenti