Sei grandi agenzie mondiali di cyber security hanno lavorato assieme per elaborare una serie di guide riferite alle piattaforme di Security Information and Event Management (SIEM) e Security Orchestration, Automation, and Response (SOAR).
Sono il Centro per la cyber security (ACSC) dell’Australian Signals Directorate (Australia), l’Agenzia per la cybersecurity e delle infrastrutture (CISA – USA), l’Agenzia per la sicurezza nazionale (NSA – USA), l’FBI (Federal Bureau Investigation- USA); il Centro nazionale per la cybers ecurity (NCSC – UK; il Centro canadese per la cyber security (CCCS – Canada).
Si tratta di tre guide, pubblicate lo scorso 27 maggio 2025. Vediamo di che cosa si tratta:
- Implementing SIEM and SOAR Platforms – Executive Guidance. La guida descrive in che modo i responsabili della sicurezza possono potenziare il quadro di cyber security della propria organizzazione implementando queste tecnologie per migliorare la visibilità delle attività di rete, consentendo un rilevamento e una risposta rapidi alle minacce informatiche.
- Implementing SIEM and SOAR Platforms – Practitioner Guidance. La guida si concentra su come i professionisti possono identificare e rispondere rapidamente a potenziali minacce alla cybersecurity e sfruttare queste tecnologie per semplificare i processi di risposta agli incidenti automatizzando azioni predefinite in base alle anomalie rilevate.
- Priority Logs for SIEM Ingestion – Practitioner Guidance. La guida offre spunti per stabilire le priorità nell’inserimento dei log in un SIEM, garantendo che le fonti di dati critici vengano raccolte e analizzate in modo efficace per migliorare le capacità di rilevamento delle minacce e di risposta agli incidenti su misura per le organizzazioni.
Di seguito un dettaglio dei contenuti delle tre guide.
Indice degli argomenti
Implementing SIEM and SOAR platforms – Executive Guidance
È necessario evidenziare che le piattaforme SIEM e SOAR si convertono in componenti della strategia di logging e di visibilità delle organizzazioni.
Di fatto, la visibilità è fondamentale per il rilevamento di attività informatiche dannose ed è fondamentale per una strategia di cyber security olistica efficace, dato che queste piattaforme possono migliorare:
- La visibilità generale di ciò che accade sulla rete dell’organizzazione, raccogliendo, centralizzando e analizzando dati importanti e qualificati sugli eventi che, altrimenti, sarebbero estremamente complessi e sparsi da raccogliere.
- Il rilevamento di eventi e incidenti di cyber security da parte dell’organizzazione, generando avvisi rapidi su attività sospette, oltre ad impedire ai cyber criminali di modificare/eliminare determinati dati per mantenere il loro accesso alla rete.
- La risposta dell’organizzazione agli eventi e agli incidenti di cyber security, sollecitando un intervento tempestivo tramite avvisi, oltre ad assicurare che gli addetti alla risposta agli incidenti abbiano accesso ai dati che registrano quanto accaduto. Nel caso di un SOAR, è possibile migliorare la risposta agli eventi/incidenti, automatizzando determinate azioni di risposta, oltre a ridurre il tempo medio di risposta.
Di fatto, queste piattaforme possono contribuire a garantire il funzionamento dei sistemi e dei servizi dell’organizzazione, oltre a proteggere i dati da accessi non autorizzati, modifiche e furti.
È doveroso evidenziare che tali vantaggi si verificano solo se il SIEM e/o il SOAR vengono implementati correttamente.
Come funzionano queste piattaforme?
La rete di una singola organizzazione può essere estremamente complessa e contenere molteplici dispositivi, applicazioni, sistemi operativi e servizi cloud.
Inoltre, ciascuna di queste fonti all’interno della rete può anche generare dati di log, ovvero informazioni specifiche su ciò che accade al suo interno (ad esempio, l’attività dell’utente su un dispositivo).
Di seguito, la descrizione delle caratteristiche di una piattaforma SIEM e SOAR.
SIEM
È un tipo di piattaforma software che raccoglie, centralizza ed analizza i dati di log complessi e dispersi in tutta la rete e li consolida in report e dashboard semplificati.
Inoltre, SIEM analizza tali dati applicando regole e filtri per rilevare attività di rete anomale che potrebbero rappresentare un evento o un incidente di cyber security.
Ancora, molti prodotti SIEM migliorano le analisi, integrando informazioni aggiornate sulle minacce informatiche provenienti da fonti esterne e, se rilevano un evento/incidente, generano degli avvisi, sollecitando il team di sicurezza dell’organizzazione a indagare e ad intervenire di conseguenza.
SOAR
È un tipo di piattaforma software che si basa sulla raccolta, sulla centralizzazione e sull’analisi dei dati di log.
Alcune piattaforme SOAR svolgono queste funzioni autonomamente, mentre altre si integrano con un SIEM esistente e ne sfruttano la raccolta, la centralizzazione e l’analisi dei log.
In entrambi i casi, un SOAR automatizza alcune delle risposte agli eventi e agli incidenti di cyber security rilevati, applicando “playbook” predefiniti che stabiliscono determinate azioni da intraprendere al verificarsi di eventi specifici.
È doveroso evidenziare che tali azioni automatizzate non sostituiscono gli operatori umani addetti alla risposta agli incidenti, ma possono integrarli.
Le principali sfide nell’implementazione delle piattaforme SIEM & SOAR
Le piattaforme SIEM e SOAR non devono essere considerate come strumenti “imposta e dimentica”, dato che sottendono un processo articolato e continuo che richiede personale altamente qualificato e che deve essere in grado di gestire due sfide tecniche fondamentali. E, precisamente:
Sfida 1 – Si tratta di garantire che il SIEM emetta avvisi solo quando si verificano eventi e incidenti di cyber security. A tal fine, il personale deve identificare le tipologie e le quantità corrette di dati di log che il SIEM deve acquisire, nonché le regole e i filtri appropriati da applicare a tali dati.
Ciò include lo sviluppo di un modello di minaccia che definisca gli eventi di interesse che possono attivare avvisi correlati a tale modello, al fine di promuovere un sistema di allerta accurato ed evitare che i team di sicurezza potrebbero essere sopraffatti operativamente da falsi allarmi provenienti dal SIEM o non rilevare eventi/incidenti reali a causa dell’assenza di allarmi.
Sfida 2 – È fondamentale garantire che il SOAR adotti misure appropriate solo in risposta a incidenti/cyber security effettivi e non intervenga contro la normale attività di rete o che ostacoli gli interventi umani di risposta agli incidenti. Pertanto, il SOAR, se non si adottano misure accurate, potrebbe compromettere significativamente l’erogazione del servizio.
A fronte di quanto sopra, il personale deve configurare attentamente il SIEM e/o il SOAR per la rete e per l’organizzazione in cui viene utilizzato, adattandolo e testandone costantemente l’efficacia, in linea con l’evoluzione della rete, della tecnologia e del panorama delle minacce informatiche. Tale lavoro continuo può essere svolto internamente, oppure, da un fornitore di servizi esterno o tramite una combinazione dei due.
L’implementazione corretta di un SIEM e/o di un SOAR comporta quindi costi significativi, quali:
- Costi di licenza e/o di utilizzo dei dati della piattaforma.
- Costi di assunzione e mantenimento di personale con competenze specialistiche richieste nell’implementazione di un SIEM e/o SOAR.
- Costi di aggiornamento del personale esistente, nonché costi sostenuti di formazione continua necessaria per consentire loro di mantenere la piattaforma mentre la tecnologia, la rete e il panorama delle minacce cambiano.
- Costi di servizio (se l’implementazione è esternalizzata).
Raccomandazioni per l’implementazione
Di seguito sono riportate raccomandazioni strategiche di alto livello per i responsabili della sicurezza che stano valutando se e come implementare un sistema SIEM e/o SOAR. E, precisamente:
Valutare la necessità e la possibilità di implementare la piattaforma internamente. L’organizzazione – qualora gestisca informazioni sensibili o fornisca servizi critici – potrebbe necessitare di implementare la piattaforma internamente.
È doveroso evidenziare che un vantaggio fondamentale dell’implementazione interna di un sistema SIEM e/o SOAR è che il personale avrà generalmente una maggiore conoscenza della rete e dei processi aziendali specifici dell’organizzazione, nonché l’autorità di interrogare gli utenti su comportamenti insoliti e avviare azioni di risposta agli incidenti. L’outsourcing, invece, può generare lacune di visibilità, duplicazione del lavoro e difficoltà di comunicazione.
I responsabili della sicurezza devono essere consapevoli che l’implementazione e la gestione di soluzioni SIEM e/o SOAR richiedono l’impiego di un numero significativo di risorse a tempo pieno. Sviluppare e mantenere una capacità interna rappresenta una sfida impegnativa, in quanto richiede competenze specialistiche e un notevole investimento di tempo ed energie.
Inoltre, l’operatività su queste piattaforme può comportare periodi prolungati di lavoro ad alto carico e stress, rendendo necessario prevedere adeguate misure di supporto per il personale coinvolto. Pertanto, qualora l’organizzazione esternalizzasse parte o tutta l’implementazione, le agenzie di cyber security che hanno redatto la guida, raccomandano di verificare se i diversi fornitori di servizi siano in grado di:
- Fornire un servizio di monitoraggio e di risposta agli incidenti di alta qualità, 24 ore su 24, 7 giorni su 7.
- Avere una buona postura in materia di cyber security.
- Specificare se hanno sede in una nazione straniera o hanno uffici in nazioni straniere.
Si dovrebbe, inoltre, prestare particolare attenzione alle disposizioni contrattuali in termini di:
- Come verrà verificata e garantita l’efficacia del servizio.
- Come il fornitore di servizi verificherà la propria conformità ai requisiti legislativi, normativi e interni applicabili all’organizzazione.
- Livello di competenza del fornitore del servizio.
- Servizi da erogare, incluso l’uso di standard, formazione e feedback dell’utente finale.
- Grado di visibilità che il fornitore di servizi fornirà alla tua organizzazione.
- Ripartizione delle responsabilità per l’individuazione e la risposta agli incidenti di cyber security.
Individuare potenziali costi nascosti nei diversi prodotti. La guida raccomanda di esaminare attentamente i costi dei diversi prodotti SIEM e/o SOAR. La maggior parte dei modelli di prezzo SIEM si basa sulla quantità di dati che il SIEM acquisisce. Alcuni prodotti limitano l’acquisizione in base a un importo pre-acquistato; mentre, per i prodotti che non lo prevedono, l’organizzazione deve essere consapevole del potenziale rischio di sostenere costi molto significativi se l’acquisizione non viene gestita con attenzione.
Pianificare i costi correnti dell’implementazione, in particolare i costi di formazione. L’implementazione corretta di un sistema SIEM e/o SOAR comporta significativi costi iniziali. Pertanto, si consiglia alle organizzazioni di consultare la documentazione del fornitore per determinare se opzioni di logging alternative possano ridurre tali costi. Inoltre, per le organizzazioni che sviluppano una capacità interna, si raccomanda di prevedere una allocazioni di costi per la formazione continua del personale nel tempo.
Implementare correttamente un SIEM. In generale, è necessario implementare correttamente un SIEM e assicurarsi la segnalazione accurata degli eventi e degli incidenti di cyber security, prima di implementare un SOAR.
Assicurarsi che le prestazioni della/e piattaforma/e siano testate. È essenziale stabilire processi e procedure interne per verificare se la piattaforma funzioni in modo efficace in termini di avvisi di eventi e incidenti di cybersecurity, poiché i continui cambiamenti nelle reti, nelle tecnologie e nel panorama delle minacce informatiche influiranno sulle prestazioni.
Una volta consolidata la capacità SIEM e/o SOAR, si raccomanda di testare le prestazioni, utilizzando un servizio professionale esterno, quale il penetration test. Inoltre, si consiglia di individuare diversi fornitori SIEM e/o SOAR che meglio soddisfano le esigenze della propria organizzazione.
Implementing SIEM and SOAR platforms – Practitioner guidance
La guida è rivolta principalmente ai professionisti di organizzazioni governative e di infrastrutture critiche. Tuttavia, essa può essere utilizzata anche dai professionisti di qualsiasi organizzazione interessata o che utilizzi già piattaforme SIEM e/o SOAR.
È doveroso evidenziare che le raccomandazioni contenute nella guida devono essere considerate consigli generici: ogni organizzazione dovrebbe adattare la raccolta, la centralizzazione e l’analisi dei registri al proprio specifico ambiente e profilo di rischio.
Sfide per i professionisti nell’implementazione delle piattaforme SIEM e/o SOAR
La sfida principale per qualsiasi piattaforma SIEM è di garantire che i dati vengano correttamente acquisiti dalle fonti di log e di impostare meccanismi di rilevamento efficaci. Mentre, la sfida principale per le piattaforme SOAR è di adattare una risposta automatizzata efficace a eventi specifici.
Ma vediamo in dettaglio di che si tratta.
- Normalizzazione dei dati. Un SIEM raccoglie, elabora ed analizza dati provenienti da diverse fonti all’interno di una rete o di un sistema (i.e. firewall, sistemi di rilevamento/prevenzione delle intrusioni -IDS/IPS, endpoint e applicazioni). Ciò crea una sfida per l’analisi dei log, poiché ogni fonte può avere un formato di log diverso. Pertanto, le organizzazioni dovranno affrontare i seguenti aspetti per implementare efficacemente un SIEM: analisi corretta dei dati provenienti da log sia non strutturati sia strutturati; standardizzazione delle terminologie in tutti i log raccolti (ad esempio ‘src_ip’ e ‘sourceAddress’); sincronizzazione temporale per i log raccolti in fusi orari diversi.
- Raccolta dei dati di log in tutto l’ambiente dell’organizzazione. L’acquisizione dei dati di log dovrebbe anche considerare la copertura dell’ambiente dell’organizzazione e la priorità di valutazione del rischio.
- Centralizzazione dei log vs. analisi dei log. Un consumo di log elevato è più probabile se la piattaforma SIEM viene utilizzata principalmente come centralizzatore di log. Di fatto, un SIEM non dovrebbe essere utilizzato per questo scopo, dato che le organizzazioni possono avvalersi di una varietà di altri strumenti se il loro obiettivo principale è la centralizzazione dei log a fini di conformità o auditing. Tali strumenti – quali i data lake e i meccanismi di archiviazione alternativi – dovrebbero essere utilizzati per centralizzare i log che non hanno valore in termini di identificazione di potenziali eventi, minacce o incidenti di sicurezza informatica. Si tratta della soluzione più economica e può consentire ai team di sicurezza di raccogliere solo i log di cui hanno bisogno tramite il SIEM, senza dover filtrare i log meno utili.
- Ottenere un’analisi efficace dei log. La piattaforma SIEM, per ottenere un’analisi dei log efficace, deve essere attentamente configurata per l’ambiente IT e i requisiti aziendali specifici dell’organizzazione. L’analisi è efficace quando la piattaforma SIEM produce sia i veri positivi (avvisi quando si verificano eventi o incidenti) sia i veri negativi (nessun avviso quando non si verificano eventi o incidenti). Ciò richiede personale umano per garantire che il SIEM raccolga e centralizzi i tipi e la quantità appropriati di dati di log, nonché le regole e i filtri corretti. Si tratta di un impegno significativo e continuo. Ovvero, il SIEM deve essere costantemente configurato e ottimizzato nel tempo, in base all’evoluzione continua dell’ambiente, delle funzionalità della piattaforma e del panorama delle minacce.
Al contrario, una piattaforma SIEM alimentata da dati incompleti o incoerenti, o configurata con regole e filtri poco sensibili, rischia di generare falsi negativi, compromettendo la capacità di rilevare e rispondere tempestivamente alle minacce. Ciò è particolarmente critico poiché i team di sicurezza tendono a fare affidamento sugli avvisi generati dalla piattaforma.
D’altro canto, un SIEM configurato per elaborare grandi volumi di log e applicare regole troppo generiche o troppo sensibili può produrre un elevato numero di falsi positivi. Tale sovraccarico informativo può portare alla cosiddetta alert fatigue, ossia una saturazione degli operatori che riduce la loro capacità di reagire prontamente a eventi reali.
Questo tipo di squilibrio è piuttosto comune, in particolare quando i team di sicurezza tendono a raccogliere e centralizzare un volume eccessivo di dati, rendendo più complessa l’elaborazione di regole e filtri davvero efficaci.
È importante sottolineare che una configurazione inefficace del SIEM, soprattutto in termini di analisi dei log, può compromettere anche il funzionamento di una piattaforma SOAR eventualmente integrata. In tali casi, l’impatto può essere significativo, con potenziali ritardi o errori nelle attività di orchestrazione e risposta automatizzata agli incidenti.
I rischi dell’automazione delle risposte
Le piattaforme SOAR devono essere attentamente configurate per l’ambiente specifico dell’organizzazione e richiede personale con competenze specialistiche, tra cui:
- Professionisti della sicurezza per identificare quali parti della risposta dovrebbero essere automatizzate.
- Ingegneri di piattaforma per progettare l’automazione.
- Sviluppatori per determinare in che modo l’automazione delle risposte può influenzare i prodotti o i servizi sviluppati internamente/su misura.
- Consulenti legali o esperti di governance, rischi e conformità, per determinare eventuali rischi e conseguenze normative derivanti dall’automazione delle risposte.
È giusto evidenziare che – se la funzionalità di risposta del SOAR non è configurata e gestita correttamente – la piattaforma SOAR potrebbe identificare erroneamente un comportamento normale dell’utente o del sistema come un evento o un incidente e adottare misure automatiche per isolarlo e intervenire. Ciò può causare interruzioni di vario grado nell’erogazione del servizio.
Inoltre, se il personale è scettico nei confronti dell’automazione delle risposte o non dispone delle competenze necessarie per implementare correttamente una piattaforma SOAR nel tempo, esiste il rischio che quest’ultima resti inutilizzata, nonostante i costi spesso elevati sostenuti per l’acquisto.
Per questo motivo, le soluzioni SOAR non sono generalmente indicate per contesti organizzativi ancora immaturi, ad esempio privi di una piattaforma SIEM preesistente, dotati solo di una capacità SIEM appena avviata, o sprovvisti di un team di sicurezza con esperienza.
In questi casi, la priorità dovrebbe essere data all’implementazione corretta del SIEM e alla capacità di ottenere un’analisi dei log efficace, prerequisiti fondamentali per poter successivamente trarre reale beneficio dall’integrazione di una piattaforma SOAR.
Costi di implementazione
L’implementazione corretta di una piattaforma SIEM e/o SOAR comporta costi significativi e continuativi. Questi possono includere:
- Costi iniziali di licenza e/o di utilizzo dei dati della piattaforma.
- Costi di assunzione e mantenimento di personale con competenze specialistiche (difficile da trovare) nell’implementazione SIEM e/o SOAR.
- Costi iniziali di aggiornamento del personale esistente per garantire che abbia le competenze per configurare la piattaforma.
- Costi significativi per la formazione continua del personale per garantire che sia in grado di mantenere la piattaforma e farla maturare nel tempo.
- Costi sostenuti per la governance del personale e la manutenzione della piattaforma.
- Costi di servizio iniziali significativi se l’organizzazione esternalizza la configurazione, l’implementazione e la manutenzione della piattaforma.
La guida raccomanda alle organizzazioni – che trattano informazioni sensibili o offrono servizi critici o distintivi – di sviluppare competenze interne, sia per adempiere agli obblighi normativi sia per garantire capacità affidabili e su misura. Il personale interno, infatti, possiede spesso una conoscenza più approfondita della rete e può riconoscere più facilmente comportamenti anomali o sospetti.
Di fatto, se da un lato alcuni eventi palesemente anomali potessero essere individuati anche da fornitori esterni, dall’altro lato, attività più sofisticate o ambigue potrebbero invece sfuggire senza una comprensione dettagliata dell’ambiente operativo.
I team di sicurezza devono anche disporre dell’autorità necessaria per interrogare gli utenti in merito alle loro attività sulla rete, allo scopo di prevenire minacce interne o indagare su eventuali furti di credenziali.
L’esternalizzazione, inoltre, può comportare criticità come lacune nella visibilità, sovrapposizioni operative e difficoltà nella comunicazione. Qualora si opti per l’outsourcing, si raccomanda di valutare attentamente più fornitori SIEM e/o SOAR, al fine di individuare quelli più adatti alle esigenze specifiche dell’organizzazione.
Le organizzazioni che scelgono di non esternalizzare la configurazione e la gestione delle piattaforme SIEM e/o SOAR dovrebbero prevedere l’impiego di un numero maggiore di risorse dedicate a tempo pieno.
È inoltre fondamentale considerare che la gestione di un SIEM può richiedere lunghi periodi di lavoro ad alta intensità e stress, per cui è probabile che il personale coinvolto abbia bisogno di un adeguato supporto.
Implementazione di una piattaforma SIEM e/o SOAR: 11 principi di best practice
La guida fornisce n. 11 principi di buone pratiche a cui i professionisti della sicurezza possono fare riferimento in ogni fase di implementazione di una piattaforma SIEM e/o SOAR in termini di approvvigionamento, set up e manutenzione.
Approvvigionamento
- Definire l’ambito di implementazione per la propria organizzazione.
- Considerare un prodotto SIEM che abbia incorporato un’architettura data lake.
- Considerare un prodotto SIEM in grado di correlare dati provenienti da più fonti.
- Individuare i costi nascosti dei diversi prodotti.
- Investire nella formazione, non solo nella tecnologia.
Setup
- Stabilire una base di riferimento per le attività ordinarie sulla rete.
- Sviluppare uno standard per la raccolta dei log.
- Integrare il SIEM nell’architettura aziendale dell’organizzazione.
Manutenzione
- Valutare il rilevamento delle minacce
- Ridurre l’inserimento dei log tramite la pre-elaborazione.
- Mettere alla prova le prestazioni del tuo SIEM e/o SOAR.
La guida consiglia alle organizzazioni che implementano un SIEM di considerare la seguente tabella di acquisizione dati per i requisiti iniziali di licenza e di archiviazione/elaborazione.
La corretta implementazione del SIEM
Inoltre, la guida è dotata di due allegati e, precisamente: “Allegato A – Modelli di architettura SIEM” e “Allegato B – Metodi di pre-elaborazione”. Segue un’estrapolazione dei contenuti principali dei due allegati.
ALLEGATO A – Modelli di architettura SIEM
L’ allegato specifica che il termine “repository di log” si riferisce a una posizione generica per la centralizzazione dei log, i.e. un data lake o un bucket S3.
Il termine “sorgente”, invece, si riferisce a una fonte dati all’interno dell’ambiente. Il termine “attuale” si riferisce a un repository o feed di log recenti, mentre il termine “vecchio” si riferisce a un repository o feed di log meno recenti.
Di seguito alcuni esempi di architetture comuni per le piattaforme SIEM e raccomandate dalla guida:
Approccio data lake o repository-first. Esso prevede che le fonti dati inviino prima i log al repository dei log, anziché direttamente al SIEM. In questa architettura tutti i log vengono replicati in un repository dei log e il SIEM attinge ai log recenti per la ricerca e l’elaborazione dal repository corrente, anziché ricevere un proprio feed.
Replica duale del log tra repository del log e SIEM. Tutte le sorgenti dati replicano e indirizzano i log sia al SIEM sia al repository dei log. Inoltre, la gestione dei log inseriti nel SIEM viene effettuata utilizzando i repository attuali e precedenti, che sono, a loro volta, gestiti tramite il SIEM. Tale gestione include qualsiasi attività di conservazione ed eliminazione, indipendente dal repository dei log principale.
La guida evidenzia che tale architettura potrebbe essere utilizzata quando tutte le sorgenti dati identificate per l’inserimento sono considerate rilevanti per i requisiti di sicurezza del SIEM e l’utilità dei feed contribuisce alla gestione del volume di dati. Inoltre, l’architettura potrebbe essere utile per le organizzazioni con SIEM preesistenti che, per motivi aziendali, non possono essere facilmente riprogettate per un approccio data lake-first.
Feed di log indipendenti in base ai requisiti. L’architettura si differenzia dalle precedenti poiché alcune fonti dati sono configurate per indirizzare log specifici solo per il repository dei log, mentre altre continuano a replicare i log sia per il repository dei log sia per il SIEM. Si tratta di un’architettura che può essere utile per le organizzazioni con requisiti di governance o che necessitano di archiviare log che potrebbero non contenere informazioni di sicurezza rilevanti.
Architettura SIEM-first. Le agenzie di sicurezza che hanno redatto la guida e contribuito allo sviluppo dell’architettura ne sconsigliano l’adozione. In un approccio SIEM-first, infatti, i log vengono inizialmente raccolti e centralizzati dal SIEM, per poi essere replicati in un repository separato.
Tale processo può risultare inefficiente dal punto di vista delle prestazioni e comportare rischi per l’integrità dei log, soprattutto in caso di malfunzionamenti o di errori durante l’elaborazione.
Una conseguenza critica di questo approccio è che il repository conterrà solo i log già elaborati e non quelli originali, rendendo più complesse e meno affidabili le attività di analisi forense e di investigazione degli incidenti.
Protezione delle informazioni personali identificabili (PII – Personal Identifiable Information). Per le organizzazioni con requisiti specifici in materia di protezione delle informazioni personali identificabili dei propri dipendenti, il diagramma seguente illustra come il SIEM può essere progettato per limitare l’accesso degli utenti SIEM.
Di fatto, i dati del SIEM possono essere configurati e indicizzati in modo segmentato per limitare l’accesso degli utenti SIEM alle fonti dati, oltre all’applicazione dei controlli di accesso basati sui ruoli (RBAC – Role-Based Access Control). Come si evince dal diagramma, l’utente A ha solo accesso limitato, mentre l’utente B ha accesso completo.
Esistono alcune piattaforme SIEM che abilitano in modo nativo questo tipo di architettura, consentendo l’inserimento delle fonti di log in sottoinsiemi specifici di dati in posizioni separate all’interno della piattaforma SIEM, che possono essere ulteriormente configurate con una serie di meccanismi restrittivi di controllo degli accessi, per limitare l’accesso degli utenti.
ALLEGATO B – Metodi di pre-elaborazione
La pre-elaborazione dei log direttamente alle fonti consente di ridurre il volume di dati inviati alla fase successiva di raccolta e centralizzazione, soprattutto quando il SIEM acquisisce i dati direttamente da tali fonti.
Tale processo permette di filtrare le informazioni non rilevanti, alleggerendo il carico di rete, ottimizzando lo spazio di archiviazione, favorendo la standardizzazione dei formati, oltre a migliorare l’efficacia dell’analisi condotta dal SIEM.
Di seguito vengono presentati alcuni approcci comuni alla pre-elaborazione dei log.
Separazione del registro sorgente. La sorgente dati (o dispositivo host) è configurata per generare e per separare i propri log in diverse tipologie in base a specifiche caratteristiche. Solo alcuni tipi di log – nel diagramma a destra, Log 1 – vengono quindi inoltrati al SIEM per l’elaborazione, tramite un metodo di “replica” (i.e. forwarder), in aggiunta o tramite il repository dei log. Inoltre, i log “indesiderati” (i.e. i log 2 e 3) rimangono nell’origine per il periodo di tempo specificato nei criteri di conservazione dei log.
Pre-elaborazione del punto di replica. L’origine dati (o dispositivo host) è configurata per generare e separare i propri log in diverse tipologie in base a determinate caratteristiche. A differenza dell’esempio precedente, tutti e tre i tipi di log interagiscono con l’inoltro o il punto di replica. Log 1 e Log 2 sono indirizzati al SIEM e/o al repository dei log.
Inoltre, il componente di replica o forwarder, oltre a inoltrare i log di tipo 1 e 2, viene utilizzato anche per acquisire ulteriori fonti di log — come quelli di tipo 3 — e replicarle in una destinazione secondaria distinta dal SIEM. I log di tipo 3 vengono solitamente archiviati in un’area di conservazione dedicata o in un data lake.
La pre-elaborazione a livello del punto di replica è una pratica comune per gestire registri complessi, come quelli di PowerShell. Tali log sono estremamente utili nelle attività di indagine, ma possono risultare problematici per i SIEM tradizionali, sia per l’elevato volume di dati sia per la complessità del loro formato.
SIEM ingestion. In questo approccio, tutte le sorgenti di log (come log 1, log 2 e log 3) vengono replicate dalla sorgente dati al sistema SIEM, dove vengono elaborate. Il SIEM può essere configurato in modo da inviare avvisi solo per uno di questi tipi di log, ad esempio il log 2.
Gli altri tipi di log, come il log 1 e il log 3, invece, vengono conservati in un meccanismo di archiviazione chiamato “cold storage”. Ciò significa che, se il SIEM ha bisogno di ulteriori dettagli o informazioni da altri tipi di log, può recuperare i file o gli eventi dal cold storage e reinserirli nel sistema per continuare l’elaborazione.
Priority logs for SIEM ingestion – Practitioner guidance
La guida fornisce raccomandazioni dettagliate sui log che dovrebbero essere considerati prioritari per la SIEM ingestion.
la guida suggerisce che ogni organizzazione dovrebbe personalizzare il modo in cui raccoglie, centralizza e analizza i log, tenendo conto del proprio ambiente e del livello di rischio. È importante adottare un approccio graduale, aumentando progressivamente il numero e le tipologie di fonti di dati che vengono inserite nel SIEM, invece di cercare di aggiungerle tutte in una volta sola.
La guida raccomanda di fare riferimento alle linee guida specifiche del fornitore, ove disponibili, per informazioni specifiche per ciascun sistema operativo, oltre ad evidenziare come tutte le piattaforme SIEM dispongano di una funzione di acquisizione dei log.
Inoltre, anche alcune piattaforme SOA svolgono questa funzione o dispongono di un SIEM integrato.
Considerazioni sui rischi
È bene ricordare che le decisioni relative al logging dovrebbero basarsi sull’ambiente specifico e sul profilo di rischio dell’organizzazione. Inoltre, è fondamentale che le organizzazioni modellino le proprie minacce, i propri rischi e selezionino le fonti di dati più pertinenti al proprio profilo di rischio.
L’organizzazione, per ciascuna fonte di dati, dovrebbe valutare:
- Scopo o caso d’uso, evitando di effettuare una registrazione fine a sé stessa.
- Priorità, considerando che le fonti dati con priorità più elevata dovrebbero essere integrate per prime nelle nuove implementazioni SIEM e il loro stato di integrità dovrebbe essere controllato regolarmente.
- Volume dei log generati, dato che il volume dei log del firewall o del Domain Name System (DNS) potrebbe mettere in ombra l’importanza delle informazioni ricevute.
- Valore analitico, considerando che è possibile interrogare fonti di dati ad alto volume sia per individuare anomalie temporali sia per individuare correlazioni con altre fonti di dati.
L’architettura
L’architettura di logging prevede un processo in due fasi, ovvero:
Fase 1 – Creazione, raccolta e trasferimento dei log a un punto di centralizzazione
Fase 2 – Acquisizione di tali log da parte del SIEM, direttamente dalla fonte o dal punto di centralizzazione.
La guida sconsiglia vivamente di utilizzare un SIEM come repository centrale per tutti i log dato che dovrebbe essere utilizzato solo per la centralizzazione di specifici log di sicurezza, in base al profilo di rischio dell’organizzazione.
Elenco di log prioritari – Si tratta di un documento che fornisce tabelle di eventi di logging secondo un ordine di priorità per categoria di origine dati. La guida raccomanda alle organizzazioni di considerare l’elenco di log prioritari come punto di partenza per un tipico ambiente di rete aziendale.
Inoltre, le organizzazioni potrebbero dover tenere conto dell’affidabilità, della visibilità offerta da ciascun log o tipo di log, del potenziale impatto sulle prestazioni dell’acquisizione e dei costi organizzativi di manutenzione e analisi di questi dati, oltre a dover adattare la priorità in base alle proprie minacce, alla capacità ed alle esigenze specifiche.
Guida dettagliata ai log
Si rimanda alla guida per un maggior dettaglio di:
- Log di rilevamento e risposta degli endpoint (EDR)
- Log dei dispositivi di rete
- Controller di dominio Microsoft
- Log di sicurezza di Active Directory (AD) e del servizio di dominio
- Log degli endpoint di Microsoft Windows
- Log di sistema di virtualizzazione
- Log della tecnologia operativa (OT – Operational Technology)
- Log della piattaforma cloud
- Log dei container
- Log del database
- Gestione dei dispositivi mobili
- Log eventi analitici del server DNS di Windows
- Log di controllo degli endpoint Linux
- Log degli endpoint Apple MacOS
Inoltre, la guida fornisce un “Allegato di riferimento e risorse”, sottoforma di tabelle, che fornisce: modifiche ai criteri di gruppo del controller di domini; modifiche ai criteri di gruppo di Active Directory; modifiche ai criteri di gruppo di Windows Endpoint.
