Creare, testare e gestire i Custom Parser di Sophos SIEM

Un Custom Parser associa i campi di un messaggio di log agli schemi di eventi standardizzati di Sophos XDR. È utile quando una sorgente integrata non viene normalizzata correttamente. Si lavora in Security Operations > Integrations > Custom Parsers: creare il parser, provare diversi messaggi singoli, controllare la mappatura effettiva e soltanto dopo attivarlo. Sono necessari una sottoscrizione Next-Gen SIEM e il ruolo Admin o Super Admin; gli altri ruoli possono solo visualizzare l’elenco dei parser configurati.

Il parser non configura il trasporto dei log. La sorgente deve prima inviare dati; la panoramica SIEM distingue acquisizione, normalizzazione e rilevamento. Per un’integrazione già supportata, ottenere prima il formato sorgente previsto, anziché sostituire prematuramente la logica del parser globale.

Preparare sorgente, schema e ripristino

Prima di iniziare, annotare prodotto sorgente, formato, tipi di evento, riferimento temporale e analisi desiderata. Sophos supporta CEF, LEEF, JSON, XML e messaggi non strutturati. Ogni variante rilevante richiede un esempio ripulito: accessi riusciti e falliti, campi facoltativi mancanti e valori diversi di utente o indirizzo. Rimuovere i segreti conservando la struttura necessaria al parsing.

Lo schema di destinazione descrive il tipo di evento. Un accesso può corrispondere ad Auth, una connessione di rete a Netflow e una richiesta DNS a DNS. I Custom Parser supportano solo una parte degli schemi XDR. In Data Lake Search > Schema Library, verificare schemi e campi ricercabili; la documentazione di normalizzazione elenca anche campi del parser e tipi di dati corrispondenti. Il nome di un campo non dimostra che la sorgente ne fornisca il valore.

Documentare nome del parser, responsabile, formato sorgente, campi di destinazione, messaggi di test ed elaborazione precedente. Per un parser esistente, salvare lo script precedente in un’area ad accesso limitato. Predisporre un ripristino senza eliminazione: mantenere inizialmente disattivati i nuovi parser, disattivarli di nuovo in caso di problemi o ripristinare in modo controllato lo script salvato. Sophos non mantiene né aggiorna i Custom Parser; la responsabilità resta all’operatore.

Scegliere Standalone, Parent o Child

• Standalone è adatto a una sorgente con esattamente un tipo di messaggio e uno schema di destinazione.
• Parent identifica la sorgente e prepara valori comuni. Sophos consiglia scwx.generic come schema di destinazione. I Child Parser associati normalizzano i singoli tipi di evento.
• Child richiede un Parent e lo schema finale corretto. Variabili e campi del Parent sono disponibili al Child.

Un firewall può fornire accessi, connessioni di rete ed eventi HTTP. Un Parent riconosce il formato comune; tre Children gestiscono i diversi contenuti. I Child Parser personalizzati non possono avere ulteriori Child Parser. Una singola sorgente semplice non richiede automaticamente questa suddivisione.

Creare il parser e riconoscere la sorgente con precisione

1. Aprire Security Operations > Integrations > Custom Parsers e scegliere Add Custom Parser.
2. Assegnare un nome descrittivo, per esempio EXAMPLE_APP_JSON_AUTH. È un esempio liberamente scelto; prodotto, formato e scopo devono essere riconoscibili.
3. Scegliere Parent, Child o Standalone. Per Child selezionare il Parent corretto, quindi formato sorgente e schema di destinazione.
4. Aprire l’editor con Create. Il codice di base generato include la funzione di suddivisione adatta al formato scelto.

La Confirm String determina se un messaggio corrisponde al parser. !CONFIRMWITH=PATTERN seleziona un’espressione regolare compatibile Go; !CONFIRMWITH=EXPRESSION una condizione con risultato vero o falso. In entrambi i casi l’espressione effettiva si trova in !CONFIRMSTRING, nel blocco di dichiarazioni dello script. Deve identificare con precisione sufficiente la sorgente ed eventualmente il tipo di evento. Una parola generica come “network” è solitamente troppo ampia. Il modello completo nell’esempio pratico HTTP/parser collegato sotto mostra insieme modalità e matcher; il suo ristretto formato di laboratorio non è intercambiabile con il seguente frammento example-auth.

Anche un parser sintatticamente valido può acquisire messaggi di altre sorgenti. Sophos non garantisce un ordine fisso per tutte le collisioni possibili. Provare almeno un messaggio simile che non debba corrispondere. Nell’extractor path verificare poi quali Parent e Child siano stati effettivamente usati.

Mappare i campi e verificare i timestamp

Lo script distingue variabili locali da campi del parser che terminano con $. Solo i campi compatibili con lo schema vengono normalizzati; un nome arbitrario con $ non crea un nuovo campo dello schema. I campi dello schema usano spesso snake_case, quelli del parser camelCase. Controllare la grafia esatta nello schema scelto.

Questo JSON fittizio è un piccolo punto di partenza per una mappatura Auth:

{"product":"example-auth","user":"pilot-user","src_ip":"192.0.2.25","time":"2026-10-27T10:15:00Z","result":"success"}

192.0.2.25 è un indirizzo di documentazione, non una destinazione di produzione. Un frammento di script JSON può estrarre utente e indirizzo sorgente così:

json = JSON(originalData$)
sourceUserName$ = json["$.user"]
sourceAddress$ = json["$.src_ip"]

Un modello completo per un formato sintetico rigorosamente definito, con timestamp, mappatura degli enum e accettazione tramite ricerca, è disponibile nell’esempio pratico HTTP/parser.

Il frammento non è una definizione completa di parser. Mancano volutamente Confirm String, schema, timestamp, azione di autenticazione ed esito, da adattare al formato reale. In particolare, non copiare senza verifica il testo success in un campo enum numerico. Lo schema Auth definisce, ad esempio, SUCCESS e FAILED per action_result; verificarne esplicitamente la mappatura nel parser.

Per il timestamp confrontare valore originale, fuso orario ed event_time_usec normalizzato. La funzione DATETIME() usa i modelli temporali Go. Un fuso errato può produrre un’analisi tecnicamente riuscita ma temporalmente sbagliata. Controllare anche i valori comuni estratti dal Root Parser rispetto alla sorgente.

Campi ripetuti come più allegati, indicatori o record di metadati richiedono elenchi di oggetti compatibili con lo schema. Una stringa separata da virgole non sostituisce tale struttura. ADDFIELD() può combinare array in oggetti ripetuti; negli array JSON le posizioni corrispondenti devono restare allineate. Un valore mancante non deve, ad esempio, associare un hash al tipo di file errato.

Testare messaggi singoli e leggere i risultati

Se la sorgente invia già dati, cercare messaggi originali adatti in Data Lake Search con FROM generic WHERE sensor_id='[my data source]'. Sostituire il segnaposto con l’identificativo sorgente verificato negli eventi reali. Nei dettagli dell’evento scegliere Original Data > Copy Original Data e incollare in Sample Message nell’editor. In alternativa usare una sola riga di log ripulita, non un file intero.

1. Controllare prima la suddivisione con Parse Message. Parsed Source Message mostra coppie chiave/valore dei formati strutturati o parti indicizzate dei messaggi non strutturati.
2. In Source Destination Mapping, verificare dove finiscono i valori sorgente. Confrontare singolarmente utente, indirizzi sorgente/destinazione, ora, azione ed esito con il messaggio originale.
3. Verificare l’extractor path. Deve mostrare il percorso previsto. Un avviso relativo a un altro parser non è un dettaglio estetico.
4. Aggiungere altri messaggi rappresentativi e volutamente non corrispondenti. Per Parent/Child verificare sia il riconoscimento comune sia la scelta del Child.
5. Eseguire Run Test per tutti gli esempi salvati e confrontare schema, valori e percorso. Sophos consiglia test ripetuti, circa 12–15 esecuzioni, per individuare corrispondenze errate variabili. Un numero specifico non garantisce l’elaborazione corretta di tutti i messaggi futuri.

Gli strumenti verificano il contenuto attuale dell’editor senza salvarlo. Un parser non valido disattivato può essere salvato; il salvataggio da solo non è quindi un collaudo funzionale. Se mancano campi, verificare prima contenuto sorgente, tipo di dati, nomi esatti e suddivisione del messaggio.

Salvare e attivare in modo controllato

Per un parser nuovo, Save and Continue salva la bozza. I nuovi parser sono disattivati per impostazione predefinita. Dopo i test uscire con Exit, scegliere l’icona Play in Actions nell’elenco e confermare con Enable. Attivare il Parent prima dei Children.

Dopo l’attivazione generare un evento sorgente innocuo autorizzato o correlare chiaramente un evento già atteso. Cercare i risultati normalizzati per sorgente, ora, schema e campi previsti. Sophos indica, ad esempio, WHERE sensor_type=[your_sensor_type]; il segnaposto rappresenta il tipo effettivo e non una query completa pronta da copiare.

L’elaborazione verso schemi aggiuntivi avviene parallelamente agli eventi generici. Un risultato dimostra inizialmente solo la normalizzazione verificata. I detector automatici non sono garantiti per ogni sorgente personalizzata. I percorsi documentati comprendono DGA e Domain Watchlist tramite DNS query_name, e IP Watchlist tramite indirizzi sorgente/destinazione in NIDS o Netflow. Collaudare separatamente la detection desiderata; un normale evento di test non deve necessariamente generare un allarme.

Regole del cliente e responsabilità MDR

is_custom_alert, oppure vendor_alert_details.is_custom_alert per Email, identifica l’origine di una regola di allarme. Secondo la documentazione degli schemi, le detection così marcate Custom Alert con true sono inviate direttamente al tenant per gestione autonoma e non entrano nella coda del servizio MDR; la gravità resta invariata. Non impostare il flag in modo da far sembrare un allarme del cliente una detection del fornitore non modificata.

Non significa che ogni messaggio normalizzato da un Custom Parser rientri automaticamente nella stessa esclusione. Evento sorgente, detection risultante e responsabilità del caso restano aspetti distinti. L’articolo Cases e Rules spiega il limite esistente dei Self-managed Cases generati da regole del cliente.

Risolvere problemi e tornare indietro in sicurezza

Parser errato nell’extractor path: Confrontare le Confirm String coinvolte. Per una collisione con un parser globale, chiedere a Sophos Support di rivedere la specificità invece di sovrapporre altri override troppo ampi.

Messaggio solo in generic: Verificare trasporto e messaggio originale, poi Confirm String, parser attivo e schema. La sola assenza di un risultato normalizzato non dimostra un guasto del trasporto.

Script valido, valori sbagliati: Confrontare messaggio e mappatura campo per campo, soprattutto ora ed enum. Su un parser attivo, ripristinare controllatamente la versione salvata dopo una modifica errata e verificare di nuovo.

Disattivare un nuovo parser difettoso con l’icona Pause e Disable. In una gerarchia tutti i Children devono essere disattivati o eliminati prima di disattivare il Parent. La normalizzazione aggiuntiva termina subito; gli eventi generici continuano a essere creati. Il ripristino non corregge automaticamente dati storici già normalizzati male o detection risultanti.

La cancellazione con l’icona cestino e Delete è irreversibile. Per un primo ripristino basta normalmente disattivare. Decidere la rimozione definitiva dopo aver salvato configurazione, chiarito dipendenze e completato il collaudo.

I parser globali non si possono modificare direttamente. Un Override sostituisce la loro elaborazione per il caso specifico, un’Extension aggiunge tipi di evento non ancora normalizzati. Entrambi richiedono la corretta associazione al Parent globale e manutenzione propria. Senza nome univoco e mappatura verificata, mantenere il percorso globale; non correggere in produzione un fuso o nuovo formato con un Override non testato.