Verificare Sophos XDR Data Lake Search ed export

Data Lake Search, in Security Operations > Data Lake Search, interroga eventi e detections acquisiti nel tenant. Prima della prima query si definiscono domanda d’indagine, fonte necessaria e finestra temporale. Un risultato vuoto è significativo soltanto dopo aver verificato acquisizione, schema e filtri.

Questa guida descrive l’interfaccia Security Operations attuale. Live Discover e Live Endpoint Search distinguono dati storici e query dirette sui dispositivi e conservano le differenti procedure Classic. Adattare gli esempi QL allo schema, al periodo e ai valori sorgente effettivi.

Scegliere fonte e metodo di ricerca

Prima della ricerca verificare in Integrations > Configured Data Sources che la fonte prevista fornisca dati recenti associati allo schema necessario. Una connessione verde non basta. L’accettazione delle integrazioni spiega questa distinzione.

Data Lake Search offre AI Search, Query Builder e Query Editor. AI Search genera un suggerimento da una domanda in linguaggio naturale. Schema, condizioni e intervallo vanno verificati prima dell’uso; l’IA non sostituisce l’accettazione della fonte. Query Builder rappresenta visivamente le condizioni; Query Editor usa Advanced Search Query Language. L’icona a puntina permette di impostare il metodo preferito come predefinito.

Iniziare con una piccola fonte nota e un periodo breve. In Query Builder scegliere prima Detections oppure Events, poi il tipo di evento per Events. In Query Editor, FROM stabilisce lo schema. Non mescolare detections ed eventi nella stessa query.

Comprendere Schema Library e campi logici

Uno schema è una categoria strutturata di eventi, per esempio auth, process o netflow. Schema Library mostra schemi, campi ricercabili e Logical Types. Non ogni campo popolato dal parser è necessariamente disponibile nella ricerca. Verificare il mapping sui campi realmente ricercabili, non solo su un campo del produttore dal nome simile.

I campi logici con @, come @ip o @user, riuniscono campi appropriati di schemi diversi. Una ricerca multischema unisce risultati per schema; una condizione agisce solo sugli schemi che possiedono il campo. Non è un join relazionale. Per filtrare campi evento in una ricerca di detections serve il prefisso dello schema corrispondente, come process.commandline.

Il modello innocuo seguente mostra una breve ricerca nello schema di autenticazione. example-user è un segnaposto arbitrario da sostituire con un’identità autorizzata per l’indagine:

FROM auth WHERE @user CONTAINS 'example-user' earliest=-1h

CONTAINS cerca sottostringhe, senza garantire una corrispondenza esatta d’identità. Se serve identificare inequivocabilmente un account, verificare campo reale, operatore di confronto e fonte. Account locali e di dominio con lo stesso nome non vanno aggregati senza controllo.

Distinguere periodo, conservazione e limite Raw

Per gli Events normalizzati, la guida agli schemi del 2 ottobre 2026 permette al massimo 31 giorni per query. La data iniziale può essere qualsiasi data entro i dati effettivamente conservati. Per indagini più lunghe usare finestre coordinate con confini documentati. Le detections sono ricercabili per qualunque periodo; storico disponibile e autorizzazioni vanno comunque verificati.

Questi 31 giorni non sono un periodo di conservazione. Next-Gen SIEM può offrire una retention più lunga senza consentire una singola query illimitata.

Per @raw e original_data, la guida SQL-QL del 15 settembre 2026 descrive un accesso separato agli ultimi 20 giorni. Una richiesta Raw esterna a questo ambito viene rifiutata, non ridotta silenziosamente. La precedente pagina Query Language cita anche incrementi di 20 giorni. Non garantisce che dividere le richieste renda accessibili dati grezzi più vecchi. Prima di promettere prove Raw storiche oltre l’ambito documentato serve un percorso prodotto confermato. Questo non è né una retention generale di 20 giorni né una prova di cancellazione fisica.

Considerare limiti QL e insidie del confronto

La guida Query Language indica 100 Query Units in esecuzione contemporanea per tenant e un limite di scansione di 10 TB per query. Una ricerca può occupare più Query Units; cento utenti non ricevono ciascuno cento ricerche parallele. Restringere quindi ricerche logiche ampie e periodi lunghi. Una ricerca fallita o limitata non va interpretata come zero eventi.

Le espressioni regolari per gli eventi usano un motore compatibile Java; le ricerche di detections usano un motore basato su Lucene. Non copiare alla cieca un’espressione salvata fra i due percorsi. Anche la risoluzione hostname è particolare, con confronto letterale case-sensitive e operatori limitati.

Negli array, le condizioni possono corrispondere a elementi diversi dello stesso evento. Una corrispondenza su nome e valore di header non prova, ad esempio, che appartengano allo stesso elemento. Se questa relazione è determinante per il risultato, verificare individualmente i dati sottostanti.

Verificare risultati e salvare la ricerca

Dopo aver scelto il periodo, eseguire con Search o Shift + Enter. Full Screen amplia la vista. Il menu dell’intestazione di colonna permette di filtrare, mostrare/nascondere, fissare o ridimensionare i campi; le colonne si riordinano trascinandole.

Per risultati affidabili controllare su righe rappresentative tenant corretto, fonte, ora con fuso, identità e azione. Il numero di righe visibili o una detection positiva non sostituisce il controllo dei campi. Per un test fonte confrontare l’evento con la prova originale.

In AI Search e Query Editor, Save Query apre il salvataggio. In Query Builder scegliere prima Save Search. Inserire poi nome, categoria e descrizione facoltativa e confermare con Save Query; Bookmark this Query aggiunge la ricerca ai preferiti personali. Un nome utile indica scopo e fonte senza segreti o dati grezzi personali. Le ricerche sono registrate nello storico del tenant. Il testo di una query salvata non è un archivio permanente dei risultati.

Conservare export completi prima della scadenza

Dal menu Actions sopra i risultati esportare l’intero insieme o un sottoinsieme selezionato intenzionalmente. Aprire quindi Security Operations > Data Exports. Il suo stato si verifica separatamente dalla riuscita della ricerca:

• Processing: esportazione ancora in corso.
• Completed: file pronto per il download.
• Errored: analizzare l’errore e usare Retry nel menu a tre punti se appropriato alla causa.
• Cancelled: esportazione annullata, nessuna prova completa.

I file sono limitati a 100.000 righe per file. Per quantità maggiori suddividere opportunamente periodi, filtri o parametri e documentare più richieste. Numero e copertura dei file parziali devono corrispondere complessivamente all’indagine desiderata. Un file scaricato non dimostra la completezza di una ricerca più ampia.

File Expiration indica la scadenza del file. Prima di quel momento salvarlo con Download nella posizione approvata. Non ricavare un TTL fisso universale da un esempio. Cancel interrompe un export in corso; Delete lo elimina irreversibilmente. Nessuna delle due azioni conferma la cancellazione della telemetria originale dal Data Lake.

La prova di esportazione comprende query, limiti temporali espliciti e fuso, fonti/schemi, ambito, stato, numero di righe e conservazione nel sistema destinatario. Definire prima accesso e condivisione della telemetria sensibile. Per un client proprio completamente paginato, il runbook Search GraphQL spiega Search-URN, errori parziali, cursori e scadenza.

Analizzare risultati inattesi

Se mancano corrispondenze, controllare prima tenant, fonte, schema, finestra e condizioni. Dopo un errore Raw, non presumere disponibilità più vecchia tentando continuamente nuove finestre. In caso di limite di scansione o concorrenza, ridurre la richiesta e documentare la suddivisione invece di avviare ripetizioni incontrollate.

Se l’anteprima è corretta ma una regola attiva di detection o suppression si comporta diversamente, verificare la gestione attuale delle regole. I motori di streaming e suppression trattano i dati in momenti e con limiti diversi rispetto a una ricerca storica.