Sophos SIEM: scegliere il trasporto e configurare HTTP Ingest

HTTP Ingest riceve messaggi di log attraverso un endpoint HTTPS fornito da Sophos. La sorgente deve supportare HTTP POST verso webhook o endpoint HTTP con autenticazione tramite token Bearer. Serve una subscription Sophos Next-Gen SIEM; la sola licenza XDR esistente non basta.

Le attività sono distinte: scegliere il trasporto, collegare la sorgente, verificare gli eventi effettivi. Creare correttamente il connettore non dimostra normalizzazione o rilevamento corretti. Prima del pilot consultare quindi fondamenti SIEM e verifica delle licenze.

Quale trasporto scegliere?

Custom riguarda sorgenti senza un’integrazione Sophos ottimizzata adeguata. Verificare prima nel Marketplace l’integrazione del prodotto e le categorie effettivamente supportate. Un nome noto non implica supporto per tutti i suoi log.

Sono disponibili sei percorsi:

• HTTP Ingest: invio HTTPS POST diretto con Bearer, senza infrastruttura cloud da gestire.
• Customer-Managed S3: log nel proprio bucket AWS, inoltrati dalla configurazione Lambda/CloudFormation fornita.
• S3 Ingest – Sophos-Managed (with token): destinazione gestita da Sophos con prova di proprietà richiesta dal fornitore.
• S3 Ingest – Sophos-Managed (without token): stesso modello senza tale verifica.
• Azure Event Hubs: flusso di eventi in un hub raggiungibile.
• Azure Storage Account: file in Blob Storage, inoltrati tramite Azure Function.

La guida S3 distingue i tre bucket; la guida Azure separa Event Hubs da Storage/Function. Un dispositivo syslog può invece richiedere un XDR Data Collector; il suo IP non sostituisce l’endpoint HTTP Ingest.

Preparare pilot e credenziali

Documentare tenant, entitlement SIEM, sorgente, categoria e responsabile. La configurazione generale richiede un ruolo Admin o Super Admin adeguato e accesso all’esportazione della sorgente. La relativa guida deve spiegare URL, Bearer, formato e comportamento di trasmissione; qui non si presuppone un JSON universale.

Scegliere una sorgente di test autorizzata e un evento innocuo riconoscibile. Annotare ora e fuso della sorgente, identificativo e campi attesi. Conservare i percorsi precedenti fino all’accettazione; l’inoltro aggiuntivo non deve creare duplicati involontari né trasferire dati personali non autorizzati.

Integration Key e URL compaiono una sola volta. Predisporre prima il secret store approvato. Non lasciare chiavi in screenshot, ticket, repository pubblici o comandi conservati nella cronologia shell. Documentare proprietario e rotazione controllata. L’Integration Credential Manager supporta solo determinati tipi, non ogni chiave di ingestione.

Creare HTTP Ingest in Sophos Fusion

1. Aprire Security Operations > Integrations > Marketplace > Custom.
2. In HTTP Ingest, scegliere Set Up.
3. Inserire un nome univoco, ad esempio Applicazione-Test-HTTP, e Done. È un’etichetta libera che deve identificare sorgente e ambiente.
4. Salvare subito Integration Key e URL nel secret store: non verranno mostrate nuovamente. Se non sono state custodite, sospendere il collegamento e chiarire il percorso di sostituzione supportato; non si promette un recupero successivo.
5. Configurare l’export HTTPS documentato usando esattamente tali valori. Verificare Bearer, formato e eventuali retry/buffer secondo la guida sorgente. Non usare payload inventati o modelli di altre API.
6. Trovare la connessione in Configured integrations sulla pagina Custom; inviare l’evento previsto e verificarne separatamente l’ingestione.

L’esempio pratico HTTP/parser descrive una fonte sintetica dedicata, con modello completo del parser e query di ricerca. Verificare nel tenant i risultati attesi di ogni passaggio prima di usare una fonte reale.

Verificare trasporto, normalizzazione e analisi

Una Custom Integration assicura inizialmente il trasporto in XDR. Sophos normalizza i tipi già supportati; formati propri o non supportati possono finire nello schema generic. Il modello dei parser nella guida SIEM spiega perché possono servire parser personalizzato e campi obbligatori adeguati.

Per il collaudo, aprire Security Operations > Integrations > Configured Data Sources e selezionare la propria sorgente. Nei dettagli della sorgente, Advanced Search mostra una ricerca predisposta per il relativo ID sensore nelle ultime 24 ore. Restringere l’intervallo al momento del test e confrontare tenant, identificativo della sorgente, ora dell’evento, azione e campi richiesti con l’evento inviato. Collaudare le integrazioni illustra il punto di accesso, mentre Data Lake Search spiega come affinare la ricerca.

Il verde indica connettività, non completezza o schema corretto. Un risultato come testo grezzo generic non prova che il detector desiderato possa usarlo. L’assenza di risultati nella ricerca semplice non esclude dati generic.

Approvare il pilot solo quando trasporto, mappatura utilizzabile e ricerca sono dimostrati separatamente. Provare una detection solo se per la sorgente è prevista una logica adeguata e supportata. Un normale evento di audit o accesso non deve necessariamente generare un allarme.

Errori e rimozione controllata

Se mancano dati, verificare prima invio reale, endpoint e uso della chiave come Bearer richiesto. Poi errori sorgente, rete, intervallo temporale e stato. Un HTTP riuscito non sostituisce il riscontro dell’evento. Se i dati sono mal mappati, esaminare formato/parser invece di creare preventivamente un secondo connettore.

Per una pausa fermare l’export con il metodo documentato della sorgente. Prima della rimozione chiarire dipendenze, prove storiche e conservazione. Arrestare solo questo inoltro e verificare il vecchio percorso ancora necessario. Eliminazione dell’integrazione, revoca della chiave e cancellazione dei dati storici sono operazioni distinte, senza un interruttore universale promesso. Per chiavi perse o compromesse chiarire con Sophos la sostituzione/revoca supportata, senza improvvisare rotazioni mai provate.