Inviare Syslog da Sophos Firewall a un SIEM in sicurezza

Con Syslog, Sophos Firewall invia gli eventi a un server di log esterno, un SIEM o un SOC. Affinché l’integrazione sia realmente utile, quattro elementi devono essere coerenti: trasporto, selezione dei log, formato e parser. Questo articolo inizia quindi direttamente dalla configurazione e mostra poi come individuare log mancanti o interpretati in modo errato.

Il Log viewer locale rimane importante per l’analisi in tempo reale. Central Firewall Reporting è adatto ai report di Sophos Fusion (in precedenza Sophos Central); Syslog è la scelta corretta per una conservazione autonoma, la correlazione tra prodotti di diversi fornitori e il rilevamento tramite SIEM.

Configurare il server Syslog

Occorre prima definire l’IP di destinazione o il FQDN, la porta, il formato di log previsto e un parser adeguato. Il firewall deve disporre di una route verso il Collector ed entrambi i sistemi devono avere una sorgente oraria funzionante. SFOS utilizza normalmente UDP 514 per Syslog. La schermata non offre una selezione separata del trasporto: Secure log transmission attiva o disattiva la trasmissione cifrata TLS. Nell’esempio TLS ufficiale di Sophos per syslog-ng viene utilizzata la porta 6514; porta e listener devono sempre corrispondere al proprio Collector.

Aprire System services > Log settings.
Selezionare Add.
Assegnare un nome univoco, ad esempio siem-primary.
Inserire il Collector in IP address/domain.
Selezionare Port, Facility, Severity level e Format in base al sistema di destinazione.
Attivare Secure log transmission se il Collector TLS è stato preparato.
Salvare.
In Log settings, attivare i tipi di log desiderati nella colonna di questo server Syslog.

SFOS supporta fino a cinque server Syslog esterni. Più destinazioni hanno senso se svolgono compiti diversi, ad esempio un archivio locale e un Collector MDR. Inviare indiscriminatamente tutti i log a ogni destinazione aumenta invece volume, costi e rischi per la privacy.

Facility, severità e formato

Facility: Le opzioni includono DAEMON, KERNEL, USER e da LOCAL0 a LOCAL7. Ad esempio, si possono assegnare LOCAL1 e LOCAL2 a due firewall. L’assegnazione deve rimanere coerente nel Collector e nella documentazione operativa.
Severity level: La selezione indica la severità minima. Error invia anche Critical, Alert ed Emergency, ma non gli eventi Information o Notice. Debug include tutti i livelli. Una soglia troppo alta può quindi nascondere accessi ed eventi operativi ordinari.
Format: Sono disponibili Standard syslog protocol e Device standard format (legacy). È determinante il formato previsto dal parser del SIEM. Una modifica successiva può interrompere ricerche, dashboard e regole di rilevamento.

Le Facility identificano l’origine di un log: DAEMON indica processi eseguiti come servizi, KERNEL processi del kernel e USER processi avviati da utenti connessi. Da LOCAL0 a LOCAL7 sono possibili assegnazioni personalizzate. Per la severità, Alert è più grave di Critical e richiede un intervento immediato. Standard syslog protocol si chiamava prima Central Reporting Format; Central Reporting usa esclusivamente questo formato. In Device standard format (legacy), il numero di campi varia in base al modulo.

Secure log transmission

TLS è consigliabile per le connessioni produttive attraverso reti non sicure o condivise, perché i log possono contenere indirizzi interni, nomi utente, URL ed eventi di sicurezza. Tuttavia, non basta attivare l’opzione: il Collector deve accettare TLS sulla porta scelta ed entrambi i lati devono poter verificare i certificati.

Per la connessione Secure Syslog documentata da Sophos si applicano queste condizioni:

Il certificato server del Collector e la relativa catena di certificati devono essere considerati attendibili dal firewall.
Il FQDN configurato deve corrispondere al certificato. Senza LINCE, SFOS verifica il Common Name; con LINCE può corrispondere il Common Name o il Subject Alternative Name.
In Certificates > Certificate authorities viene scaricata la CA Sophos Default. Il Collector deve considerare attendibile il file Default.pem estratto da questa CA, perché Sophos la utilizza per il proprio lato della connessione.
Solo a questo punto si attiva Secure log transmission con la porta TLS preparata.

Nell’esempio ufficiale di syslog-ng, Default.pem e la CA esterna si trovano nella directory delle CA del Collector; peer_verify(required-trusted) impone la verifica del certificato. Altri prodotti Collector utilizzano Trust Store propri. Un FQDN presente solo nel SAN non funziona senza LINCE e un indirizzo IP configurato non corrisponde a un certificato contenente esclusivamente un nome DNS.

Prima di attivare LINCE a questo scopo, verificare il limite di certificazione, gli algoritmi consentiti e il riavvio SSH della modalità LINCE. La modalità non è un semplice interruttore syslog e non deve essere attivata senza un accesso amministrativo indipendente.

Se un SIEM cloud non supporta direttamente questa procedura, il firewall può inviare internamente i log a un Collector locale, che li inoltra in forma cifrata. Un tratto non cifrato deve essere breve, segmentato e documentato.

Preparare un Collector TLS con syslog-ng

Questo esempio richiede un Collector Linux con syslog-ng, supporto TLS attivo e un certificato server emesso da una CA esterna. Il firewall è il client che invia i log. ExternalCertificate.pem è il certificato server, ExternalPrivateKey.key la sua chiave privata e ExternalCA.pem la CA emittente. Sono nomi di esempio; adattare percorsi e certificati al proprio Collector. La chiave privata rimane protetta sul Collector; non serve la chiave privata della CA del firewall.

Controllare la CA esistente in Certificates > Certificate authorities > Default. Il nome non può essere modificato. Country name, State e Locality name descrivono paese, regione e città; Organization name e Organization unit name, titolare e reparto. Common name contiene un nome o FQDN e Email address un contatto. Private key password permette di cambiare una password CA esistente. Key type offre RSA o Elliptic curve: scegliere Key length per RSA o Curve name per Elliptic curve; Secure hash imposta l’algoritmo hash. Key length è la lunghezza della chiave RSA in bit; chiavi più grandi offrono un margine di sicurezza maggiore, ma richiedono più elaborazione. Esempi di identità CA sono Example AG, IT Security e fw01.example.com; sostituirli con titolare, reparto e convenzione di denominazione approvata del proprio ambiente. Questi attributi CA non sono il certificato server del Collector e non sostituiscono il suo FQDN corrispondente.

Proteggere la CA esistente: Non modificare o rigenerare la CA Default solo per Syslog. Pianificare ogni modifica necessaria con backup, finestra di manutenzione e verifica dei servizi dipendenti; rinnovare la CA Default spiega le conseguenze. Aggiornare le impostazioni con Save rigenera automaticamente la CA Default e cambia l’ancora di trust. Salvare solo modifiche approvate nella finestra di manutenzione pianificata. Quindi scaricare l’archivio tar.gz tramite il pulsante di download ed estrarre il certificato CA pubblico Default.pem.

Sul Collector, collocare Default.pem e ExternalCA.pem in /etc/syslog-ng/ca.d/; ExternalCertificate.pem e ExternalPrivateKey.key in /etc/syslog-ng/cert.d/. Controllare prima directory e file esistenti; non sovrascrivere certificati senza pianificazione. Solo il servizio responsabile e gli amministratori autorizzati devono poter leggere la chiave privata.

Eseguire questi comandi sul Collector Linux, non nella SFOS Device Console. Il primo legge il certificato. Il secondo crea un link simbolico nella directory CA e richiede permessi di scrittura:

cd /etc/syslog-ng/ca.d/
openssl x509 -noout -hash -in Default.pem

Usare l’hash effettivamente restituito, non copiare ciecamente 52412b66. Per l’output di esempio 52412b66, il comando è:

ln -s Default.pem 52412b66.0

Se una voce .0 esiste già, controllarne la destinazione invece di sovrascriverla. Dopo un cambio di certificato, verificare nuovamente hash e associazione.

Questo esempio di syslog-ng.conf mostra un listener TLS e due output locali. @version: 3.15 è la dichiarazione di versione dell’esempio documentato, non un consiglio di installare una release obsoleta. Verificare sintassi, moduli e dichiarazione rispetto alla versione installata prima dell’uso. Integrare l’esempio nella configurazione esistente senza sostituirne le altre sorgenti e destinazioni.

@version: 3.15
@include "scl.conf"
source s_src {
    network(ip(0.0.0.0) port(6514)
        transport("tls")
        tls( key-file("/etc/syslog-ng/cert.d/ExternalPrivateKey.key")
             cert-file("/etc/syslog-ng/cert.d/ExternalCertificate.pem")
             ca-dir("/etc/syslog-ng/ca.d")
             peer_verify(required-trusted))
    ); };
destination d_local {
    file("/var/log/messages");
    file("/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3));
};
log { source(s_src);
    destination(d_local);
};

0.0.0.0 associa tutte le interfacce IPv4 del Collector. In produzione, preferire l’indirizzo di ricezione previsto e limitare TCP 6514 ai firewall mittenti tramite il firewall dell’host. La porta 6514 deve coincidere con la voce SFOS. key-file e cert-file indicano l’identità server e ca-dir i due certificati CA; non disattivare peer_verify(required-trusted) per aggirare errori. Le destinazioni su file offrono log grezzi e un output chiave-valore aggiuntivo con precisione al millisecondo; adattare percorsi, permessi, rotazione e spazio di archiviazione.

Prima dell’avvio, controllare la configurazione con la funzione di validazione della versione installata. Avviare il servizio o applicare le modifiche in modo controllato in una finestra approvata; in caso di problemi, tornare alla configurazione salvata. In SFOS, impostare quindi Collector, porta 6514 e Secure log transmission in System services > Log settings > Add, poi premere Save. Selezionare i moduli necessari nella colonna del server. Il successo richiede una connessione TLS senza errori di trust, un evento firewall generato intenzionalmente nei file di output e campi correttamente interpretati nel SIEM.

Definire i tipi di log e la visibilità

La destinazione viene attivata in due fasi:

La regola o la funzione corrispondente deve generare l’evento. Le regole firewall richiedono Log firewall traffic, mentre le regole di SSL/TLS Inspection richiedono Log connections.
In System services > Log settings, il tipo di log corrispondente deve essere selezionato nella colonna del server Syslog.

Se manca una delle due fasi, il Collector non può ricevere l’evento. Per un progetto pilota è sufficiente iniziare con un set ridotto e selezionato consapevolmente:

Firewall ed Events: eventi delle regole, attività di amministratori e utenti, nonché eventi di autenticazione, VPN, DHCP e DNS.
IPS, Content filtering, Web server protection e Zero-day protection: decisioni di sicurezza e delle policy.
Active threat response: corrispondenze di MDR, NDR Essentials, Sophos X-Ops e Third-Party Threat Feeds.
System health, Wireless, Heartbeat e SD-WAN: stato operativo aggiuntivo quando vengono utilizzati questi moduli.

Altri moduli vanno aggiunti solo quando esiste uno scopo di ricerca, allarme o audit. Se vengono analizzati eventi DoS, occorre verificare anche la configurazione di Spoof Protection e DoS. Per i Third-Party Threat Feeds e NDR e Active Threat Response, oltre al trasporto dei log sono necessarie ricerche e allarmi specifici.

Ambito di ATR: Abilitare la registrazione delle sorgenti remote solo per combinazioni di modulo e percorso del traffico il cui supporto è accertato. Il testo ATR di Sophos e la matrice SVG del traffico sono in contraddizione sulle direzioni di corrispondenza di X-Ops; il conflitto rimane irrisolto. Le indicazioni su MDR, NDR o feed di terze parti non dimostrano un supporto equivalente da parte di X-Ops. Mantenere controlli restrittivi di firewall, DNAT/WAF e Device Access indipendenti dal comportamento controverso del feed. I casi controversi richiedono una verifica autorizzata e controllata del modulo, della direzione di corrispondenza, dei log e dell’effetto reale, oltre a un chiarimento attendibile; nel frattempo, la protezione non deve dipendere da tale comportamento. NDR e Active Threat Response illustra il contesto sicuro.

API XML: distinguere Collector, selezione dei log e soppressione

Chi gestisce Syslog tramite API XML deve trattare separatamente questi tre livelli. Gli esempi di aggiunta e aggiornamento per SFOS 22.0 e SFOS 23.0 distinguono:

Impostazioni del Collector: indirizzo di destinazione, porta, TLS, Facility, severità e formato determinano il destinatario e la trasmissione. Un Collector creato o selezionato non attiva automaticamente tutti i log.
Invio per gruppo e sottomodulo: all’interno di LogSettings, SendLogs rappresenta il livello di gruppo; i singoli sottomoduli possono sovrascrivere questa selezione. L’esempio avverte esplicitamente di non specificare SendLogs quando sono elencati tutti i sottomoduli. Non assimilare quindi queste forme a un’attivazione generalizzata. Per PolicyRules, il commento dell’esempio indica Disable come valore predefinito; questo non implica l’abilitazione automatica di tutti gli eventi delle regole. Rimane inoltre necessario il logging nella rispettiva regola.
Soppressione: nell’esempio, Log_suppress è indicato separatamente dall’invio. Il raggruppamento degli eventi ripetuti non equivale alla selezione del loro destinatario o di un filtro di severità.

La tabella dei parametri riporta Name due volte e descrive la seconda riga come stato della soppressione; inoltre, vi compare letteralmente uiui come valore predefinito. Questo non costituisce una base attendibile per un valore predefinito operativo o per una ridenominazione implicita del campo. Non ricavarne un payload completo per la soppressione; chiarire prima i campi API ambigui consultando la guida della build specifica o il supporto Sophos. Prima e dopo una modifica approvata, generare gli stessi eventi rappresentativi e confrontare i log grezzi sul Collector, i campi del parser nel SIEM, nonché i tipi di log previsti e log_occurrence. La sola presenza di una connessione non dimostra la corretta selezione dei log.

Problemi comuni di visibilità

Log Suppression: SFOS può raggruppare eventi firewall identici e consecutivi. Questo influisce su Log Viewer, Sophos Fusion e Syslog. Il parser e il rilevamento devono quindi considerare anche log_occurrence.
Active Threat Response: Remote Source Match per il traffico DNAT o WAF in ingresso non è attivo per impostazione predefinita. Senza questa selezione mancano le relative corrispondenze della sorgente per moduli e percorsi del traffico supportati. Rispettare l’ambito di ATR descritto sopra anche quando si indaga sui tipi di corrispondenza mancanti; selezionare l’opzione non dimostra il supporto delle direzioni controverse di X-Ops.
Wireless: I log degli Access Point e degli SSID non sono disponibili nel Log Viewer locale. Devono essere inviati in modo mirato a Sophos Fusion o Syslog e verificati nella destinazione.
Content filtering e SSL/TLS: Il tipo di log selezionato non sostituisce il logging nella relativa regola firewall o di Inspection.
Web Proxy: Per il traffico web sulle porte 80 o 443, il log Firewall può indicare Allowed mentre Web Filter blocca la stessa richiesta. Per determinare la decisione effettiva della policy, occorre correlare gli eventi Firewall e Web Filter.

Verificare formato e parser

Un test del parser non deve limitarsi a dimostrare che arriva del testo. I valori principali devono essere ricercabili come campi separati. Questo esempio abbreviato e anonimizzato corrisponde allo Standard syslog protocol per un evento di una regola firewall:

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

Il formato legacy utilizza invece, tra gli altri, device, date, time, timezone, device_id e priority. Campi come status, user_name, nat_rule_id o log_occurrence dipendono inoltre dal tipo di log e dall’evento. Non devono essere considerati obbligatori per ogni evento in formato standard. L’elenco seguente è una lista di controllo dipendente dal caso d’uso, non uno schema obbligatorio universale. Definire separatamente i campi richiesti per ciascun tipo di log abilitato, usando lo schema della versione corrispondente e un evento reale rappresentativo. I campi di regola e NAT si applicano solo ai tipi di evento corrispondenti confermati; valutare i campi di connessione e utente e log_occurrence solo quando vengono forniti. L’assenza di campi non applicabili al tipo di evento non deve causare lo scarto di eventi validi né essere classificata come errore del parser.

Per l’accettazione sono particolarmente importanti, a seconda del caso d’uso:

Identità: device_name, device_model, device_serial_id
Classificazione: log_id, log_type, log_component, log_subtype, severity
Policy: fw_rule_id, fw_rule_name, nat_rule_id
Connessione: src_ip, dst_ip, porte, protocollo e utente
Ora e frequenza: timestamp, fuso orario e log_occurrence

log_id contiene tipo di log, componente, sottotipo, severità e Message ID. Le regole di rilevamento risultano quindi più stabili rispetto alle ricerche di testo libero. Occorre comunque verificare i campi forniti da ogni modulo mediante un evento reale del relativo tipo di log.

I dodici caratteri hanno posizioni fisse: i caratteri 1 e 2 formano il Log Type ID, 3 e 4 il Component ID, 5 e 6 il Subtype ID, il carattere 7 il Priority ID e i caratteri da 8 a 12 il Message ID. 010101600001 si legge quindi come 01 / 01 / 01 / 6 / 00001. Il parser deve conservare gli zeri iniziali e le larghezze fisse dei campi; come controllo aggiuntivo vanno valutati anche log_type, log_component, log_subtype e severity.

Il modulo Syslog Events non è identico a configuration-audit.log. I valori precedenti e successivi sono disponibili solo per gli oggetti chiave supportati, come regole firewall, interfacce e IP host, non per ogni modifica della configurazione. Ambito e analisi sono descritti nell’articolo sugli Audit Trail Logs.

Nell’esempio documentato 010101600001, il primo 01 significa Security policy, il secondo 01, Firewall rule, il terzo 01, Allowed, 6, Information, e 00001, Firewall traffic allowed. Gli ID a posizione fissa e i campi di testo emessi svolgono ruoli diversi; non ricavare i campi di testo da un ID numerico senza verifica. Per altri Message IDs serve un catalogo di riferimento Syslog adatto alla versione SFOS utilizzata; questa scomposizione non spiega tutti i tipi di evento.

Più firewall e HA

In un ambiente con più appliance, ogni evento deve poter essere attribuito chiaramente a firewall, sede, cliente e cluster HA. Hostname, numero di serie, modello e Facility devono quindi essere documentati e utilizzabili come filtri nel SIEM. Da SFOS 22.0, device_name identifica l’hostname del firewall che ha prodotto il log. Dopo un upgrade, verificare che il parser acquisisca questo campo invece di continuare a usare soltanto device_serial_id o l’header Syslog come chiave dell’asset.

Dopo un failover HA, un restore o una sostituzione hardware, occorre verificare se gli eventi continuano a essere assegnati all’asset esistente oppure se compaiono come un sistema nuovo o duplicato. Lo stesso vale dopo una modifica dell’hostname o del formato Syslog.

Testare l’integrazione con eventi reali

Un Collector con stato verde non dimostra né la corretta selezione dei log né il funzionamento del parser. Per l’accettazione:

Documentare un firewall pilota e lo stato iniziale: nome del server, destinazione, porta, TLS, Facility, Severity, Format e tutti i tipi di log attivi nella colonna del server.
Inviare inizialmente Firewall ed Events alla destinazione.
Generare traffico che attivi una regola di test con logging e Source, Destination e Service definiti.
Verificare nel SIEM dispositivo, ora, tipo di log, azione, Rule ID, Source e Destination.
Generare un drop definito e stabilire e chiudere una connessione VPN.
Testare almeno un evento di sicurezza di IPS, Content filtering o Active threat response, se il modulo viene utilizzato in produzione.
Attivare quindi altri tipi di log gradualmente e osservare il volume e il risultato del parser.

Per il test delle regole è utile la guida a Log Viewer, Policy Test e Packet Capture. È importante anche un test negativo: una connessione prevista viene bloccata deliberatamente e deve apparire come drop con la regola corretta.

Nei progetti HA o di migrazione, l’accettazione deve includere un test di failover, restore o sostituzione hardware. In seguito, il SOC deve continuare a riconoscere quale dispositivo e quale sede hanno generato l’evento.

Annullare una modifica senza creare interruzioni nei dati

Non modificare contemporaneamente formato, severità minima e selezione dei log. Se uno dei cinque slot server è libero, per la migrazione del parser o del Collector si aggiunge una seconda destinazione e inizialmente si mantengono entrambe in parallelo. In questo modo è possibile confrontare dati grezzi, campi valorizzati, timestamp e volume senza toccare la destinazione funzionante.

Solo dopo l’accettazione si disattivano i tipi di log nella colonna della vecchia destinazione. La relativa voce server rimane disponibile per un periodo di osservazione concordato. Se mancano eventi, il parsing non riesce o il volume è inatteso, si riattivano lì esattamente i tipi di log documentati in precedenza e si annulla la selezione sulla nuova destinazione. Se non vi sono slot liberi, registrare i valori esistenti prima di ogni singola modifica e ripristinarli integralmente in caso di errore; non eliminare la voce né cambiare contemporaneamente il parser.

L’eliminazione tramite API non equivale a disattivare la colonna dei log: le tabelle Delete per SFOS 22.0 e SFOS 23.0 riportano soltanto Name come non obbligatorio, ma lo descrivono come stato della soppressione e non mostrano alcun selettore dell’elemento da eliminare. Questa tabella contraddittoria non dimostra né una selezione sicura dell’elemento da eliminare quando il nome viene omesso, né l’equivalenza tra l’eliminazione del Collector e la disattivazione dei suoi tipi di log. Mantenere il Collector funzionante durante la migrazione. Prima di un’eliminazione tramite API, devono essere chiarite l’identità univoca e approvata della voce da rimuovere e la sintassi di eliminazione, consultando la guida API della build specifica o il supporto Sophos; non dedurre un selettore per tentativi.

Funzionamento, conservazione e guasti

Un’integrazione Syslog richiede un Owner, una durata di conservazione definita e una risposta agli allarmi. Deve inoltre essere chiaro chi valuta i falsi positivi e adatta le regole di rilevamento. I log del firewall possono contenere dati personali, indirizzi interni, nomi utente, URL e attività VPN. Diritti di accesso, termini di cancellazione, separazione dei tenant e costi del SIEM devono quindi essere chiariti prima di un rollout esteso.

Il funzionamento deve rilevare non solo gli attacchi, ma anche l’assenza di dati:

monitorare un’attività minima prevista per ogni firewall;
verificare separatamente che tipi di log importanti come Firewall, Events, IPS o Active threat response siano aggiornati;
monitorare i campi centrali del parser per individuare valori vuoti o rinominati in modo imprevisto;
generare allarmi per la scadenza dei certificati e lo stato del Collector;
generare nuovamente eventi di test dopo aggiornamenti di firmware, parser o certificati.

Anche il monitoraggio stesso deve essere testato: se un tipo di log previsto o un firewall smettono deliberatamente di inviare dati, deve scattare l’allarme di assenza definito.

Anche i dati grezzi privi di campi interpretati rappresentano un guasto. Un aggiornamento del parser può lasciare intatto il trasporto mentre dashboard e regole di rilevamento non producono più risultati.

Syslog non sostituisce i Service Logs locali né un archivio di troubleshooting per il supporto. Per i record v5 provenienti da regole firewall con logging attivo in modo mirato è adatto NetFlow, mentre per i campioni di interfaccia e i modelli di traffico è adatto sFlow. Lo stato dell’hardware e delle interfacce può essere monitorato anche tramite SNMP.

Isolare gli errori in modo mirato

Non arriva alcun log: Controllare destinazione, porta, trasporto, routing e firewall sul lato opposto. Verificare quindi se il tipo di log desiderato è attivo nella colonna Syslog. Se il Collector si trova dietro una VPN o in una rete di management, considerare anche route, SD-WAN Policy e Source NAT.

Mancano solo determinati eventi: Controllare prima il logging nella regola firewall o di Inspection interessata, quindi il tipo di log in Log settings. Per ATR verificare inoltre il Match Type necessario.

Accertare prima che il modulo e il percorso del traffico siano supportati. Rispettare l’ambito di ATR descritto sopra: l’assenza di log non risolve il conflitto X-Ops e le direzioni controverse non giustificano la semplice attivazione di altri tipi di corrispondenza.

Arrivano log grezzi, ma mancano i campi: Confrontare il formato configurato, la versione del parser e la versione del firmware. I campi standard e legacy non devono essere previsti nello stesso profilo parser.

TLS non si connette: Controllare la porta TLS e il servizio server, quindi catena di certificati, FQDN, Common Name, SAN e modalità LINCE. Il Collector deve inoltre considerare attendibile la CA Sophos Default.pem. In caso di cambio dei certificati, verificare entrambi i Trust Store e il processo di rinnovo.

I timestamp non corrispondono: Controllare NTP sul firewall e sul Collector, il fuso orario del SIEM e la normalizzazione del parser. Orari errati impediscono una correlazione affidabile con i log di Endpoint, server e identità.

Troppi log o troppo rumore: Non disattivare tutto indiscriminatamente. Valutare prima i tipi di log inutilizzati, le regole inutilmente rumorose, i casi d’uso del SIEM e log_occurrence; quindi ridurre la selezione in modo mirato.