Sophos SIEM: collegare bucket S3 propri o gestiti

Sophos Next-Gen SIEM offre tre trasporti S3: bucket nel proprio account AWS oppure destinazione Sophos con o senza token di proprietà. La scelta dipende dall’esportatore e dal modello operativo. Un bucket da solo non crea eventi XDR normalizzati e utilizzabili.

Servono subscription Next-Gen SIEM, accesso alla configurazione e permessi AWS/fornitore specifici del metodo. La scelta dei trasporti illustra le alternative. Trasferire solo log autorizzati e mantenere le destinazioni esistenti fino alla verifica.

Variante e responsabilità

Customer-Managed S3 mantiene i file nel bucket del proprio account AWS. L’operatore fornisce bucket, risorse CloudFormation/Lambda e trigger, con responsabilità dei costi e modello IAM verificato.

Con Sophos-Managed S3, Sophos gestisce la destinazione. La sorgente richiede alias, percorso ed eventuali parametri del ruolo. Se il fornitore esige un file/token che provi la proprietà prima dell’export, scegliere with token; altrimenti without token. Il token non è una credenziale API generale né prova la completezza dei log successivi.

Prima del pilot documentare sorgente, account/regione AWS, prefisso, formato, identità e responsabili. ARN IAM e token reali provengono dalla configurazione propria del fornitore/AWS; non copiare esempi altrui. Proteggere segreti e parametri che consentono accesso.

Bucket proprio: integrazione e Lambda

1. Preparare Sophos Fusion

1. Aprire Security Operations > Integrations > Marketplace > Custom.
2. Sotto Customer-Managed S3, scegliere Set Up.
3. Leggere le informazioni S3, scegliere Next, assegnare un nome univoco e terminare con Done.
4. Scaricare e proteggere il template CloudFormation generato per Lambda. Appartiene a questa integrazione, non a un collector o NDR.

2. Eseguire CloudFormation nell’account corretto

Il bucket deve già contenere i log da acquisire. Distribuire nella stessa regione, con diritti CloudFormation, Lambda, IAM e sulle altre risorse dichiarate. Prima dell’esecuzione verificare template, sicurezza e costi.

1. Nella regione corretta aprire CloudFormation > Create stack; dalla lista scegliere With new resources (standard).
2. In Prepare template selezionare un modello esistente e caricare il file YAML in Specify template. In alternativa usare l’URL S3 approvato; non occorre rendere pubblico alcun bucket.
3. Inserire un nome senza spazi. Scegliere IntegrationType adatto; per tipi multipli o mappatura incerta Sophos indica generic, senza implicare supporto alle detection.
4. In NotificationBucket inserire solo il nome del bucket, non URL/URI S3. Se si usa intenzionalmente SNS al posto delle notifiche S3, mettere l’ARN in SNSNotificationarn. Modificare altro solo per requisiti verificati del template.
5. Verificare risorse IAM, confermarne esplicitamente la creazione e, controllati i parametri, avviare con Submit.
6. Controllare eventi e infine CREATE_COMPLETE. Uno stack completato non dimostra correttezza del trigger o utilità degli eventi.

Il percorso standard colloca bucket, stack e Lambda nello stesso account e regione; non autorizza deduzioni su altre architetture.

3. Collegare il bucket come trigger

1. In Lambda aprire la funzione effettivamente creata. Il modello indicato da Sophos è {STACKNAME}-sophos-xdr-lambda-{INTEGRATIONTYPE}.
2. Aprire Function overview > Add Trigger > S3. L’alternativa SNS richiede un topic preparato separatamente.
3. Scegliere il bucket e All Object Create Events in Event Type.
4. Inserire in Prefix solo il prefisso previsto, oppure lasciarlo vuoto se assente. Lasciare Suffix vuoto. Un prefisso troppo stretto esclude file; uno ampio può acquisire dati indesiderati e aumentare i costi.
5. Valutare l’avviso sui costi Lambda, scegliere Add e verificare associazione e un nuovo oggetto di test.

Il trigger Object Create non dimostra l’acquisizione retroattiva di tutto il contenuto. Confermare la storia desiderata separatamente senza riscrivere indiscriminatamente file esistenti.

Destinazione Sophos senza token

1. Aprire Security Operations > Integrations > Marketplace > Custom, poi Set Up per S3 Ingest – Sophos-Managed (without Ownership token).
2. Scegliere l’identità richiesta dal fornitore: IAM User, Canonical User ID o IAM Role; inserire il relativo valore e creare con Done.
3. Aprire integrazione e Details, conservando i parametri in modo protetto.
4. Nell’esportatore usare AccessPointAlias come bucket, LogFolderPath come percorso e AWSRegion se richiesta. L’identità deve corrispondere a quella iniziale. Con un ruolo usare anche IAMAssumeRole come ARN da assumere lato sorgente.
5. Avviare con un nuovo evento e verificare l’ingestione. Non si aggiunge una challenge di proprietà a questo percorso.

Destinazione Sophos con token

Usare lo stesso ingresso scegliendo S3 Ingest – Sophos-Managed (with token). Dopo Set Up, indicare tipo d’identità e valore del fornitore; aprire quindi Details.

La sorgente usa AccessPointAlias, AWSRegion, LogFolderPath e l’identità corretta; per IAM Role anche IAMAssumeRole. Usare inoltre OwnershipToken seguendo la verifica del fornitore.

Possono servire più passaggi: il fornitore scrive una challenge o oggetto equivalente nella destinazione. Ricaricare Details in Sophos, recuperare il nuovo OwnershipToken e fornirlo al vendor per completare la verifica. Seguire il suo processo, senza token inventati o oggetti improvvisati. Solo dopo verificare i log.

Accettazione e rimozione per tutte le varianti

L’integrazione compare in Configured integrations. Verificare un nuovo evento innocuo alla fonte e poi tenant, sorgente, ora e campi in Sophos. Con S3 proprio controllare anche oggetto, trigger ed errori Lambda/stack; con S3 gestito prima identità, alias, percorso e verifica di proprietà, se richiesta.

Custom S3 garantisce inizialmente il trasporto. I tipi supportati seguono la normalizzazione della propria integrazione; altri possono finire in generic. La guida SIEM distingue trasporto, parser e detection. Uno stato verde o un file scritto non dimostrano l’acquisizione completa dei dati storici né una detection.

Per rimuovere, fermare prima export o trigger dedicato e verificare il vecchio percorso necessario. Non eliminare indiscriminatamente bucket, identità IAM, topic o dipendenze Lambda condivisi. Prima di rimuovere integrazione/risorse chiarire conservazione, costi residui, dipendenze e procedura supportata. La cancellazione dell’integrazione non prova eliminazione dello storico SIEM né fine di tutti i costi AWS.