Pianificare la migrazione a Microsoft Sentinel
I team del centro operazioni per la sicurezza (SOC) usano soluzioni centralizzate SIEM (Security Information and Event Management) e SOAR (Security Orchestration, Automation, and Response) per proteggere il patrimonio digitale sempre più decentralizzato. Anche se le soluzioni SIEM legacy possono mantenere una buona copertura degli asset locali, le architetture locali potrebbero avere una copertura insufficiente per gli asset cloud, ad esempio in Azure, Microsoft 365, AWS o Google Cloud Platform (GCP). Al contrario, Microsoft Sentinel può inserire dati sia da asset locali che da asset cloud, garantendo la copertura sull'intero patrimonio.
Questo articolo tratta dei motivi per la migrazione da una soluzione SIEM legacy e spiega come pianificare le diverse fasi della migrazione.
Passaggi per la migrazione
In questa guida si apprenderà come eseguire la migrazione di una soluzione SIEM legacy a Microsoft Sentinel. Seguire il processo di migrazione tramite questa serie di articoli in cui si apprenderà come esplorare i diversi passaggi del processo.
Nota
Per un processo di migrazione guidato, partecipare al programma di migrazione e modernizzazione di Microsoft Sentinel. Il programma consente di semplificare e accelerare la migrazione, e include indicazioni sulle procedure consigliate, risorse e assistenza di esperti in ogni fase. Per altre informazioni, contattare il team dell'account.
Che cos'è Microsoft Azure Sentinel?
Microsoft Sentinel è una soluzione di tipo SIEM (Security Information and Event Management) e SOAR (Security Orchestration, Automation and Response) scalabile e nativa del cloud. Microsoft Sentinel offre funzionalità intelligenti estese all'intera azienda per l'analisi della sicurezza e l'intelligence sulle minacce. Microsoft Sentinel fornisce una singola soluzione per il rilevamento di attacchi, visibilità delle minacce, rilevazione proattiva delle minacce informatiche e risposta alle minacce. Altre informazioni su Microsoft Sentinel.
Perché eseguire la migrazione da una soluzione SIEM legacy?
I team SOC affrontano una serie di sfide per la gestione di una soluzione SIEM legacy:
- Risposta lenta alle minacce. Le soluzioni SIEM legacy usano regole di correlazione, difficili da gestire e inefficaci nell'identificazione delle minacce emergenti. Inoltre, gli analisti SOC devono gestire grandi quantità di falsi positivi, molti avvisi provenienti da molti componenti di sicurezza diversi e volumi di log sempre più elevati. L'analisi di questi dati rallenta i team SOC impegnati a rispondere alle minacce critiche nell'ambiente.
- Problemi di ridimensionamento. Man mano che aumentano i tassi di inserimento dei dati, i team SOC hanno difficoltà a ridimensionare il sistema SIEM. Invece di concentrarsi sulla protezione dell'organizzazione, i team SOC devono investire nella configurazione e nella manutenzione dell'infrastruttura, e sono vincolati da limiti di query o archiviazione.
- Analisi e risposta manuale. I team SOC necessitano di analisti altamente qualificati per elaborare manualmente grandi quantità di avvisi. I team SOC sono sovraccaricati ed è difficile trovare nuovi analisti.
- Gestione complessa e inefficiente. I team SOC generalmente sovrintendono l'orchestrazione e l'infrastruttura, gestiscono le connessioni tra la soluzione SIEM e varie origini dati ed eseguono aggiornamenti e patch. Queste attività sono spesso a scapito della valutazione critica e dell'analisi.
Una soluzione SIEM nativa del cloud risolve queste sfide. Microsoft Sentinel raccoglie i dati automaticamente e su larga scala, rileva minacce sconosciute, analizza le minacce con l'intelligenza artificiale e risponde rapidamente agli incidenti con l'automazione integrata.
Pianificare la migrazione
Durante la fase di pianificazione, si identificano i componenti SIEM esistenti, i processi SOC esistenti e si progettano e si pianificano nuovi casi d'uso. Una pianificazione approfondita consente di mantenere la protezione per gli asset basati sul cloud — Microsoft Azure, AWS o GCP — e le soluzioni SaaS, ad esempio Microsoft Office 365.
Questo diagramma descrive le fasi di alto livello incluse in una tipica migrazione. Ogni fase include obiettivi chiari, attività chiave e risultati, risultati specificati e risultati finali.
Le fasi in questo diagramma sono linee guida per completare una tipica procedura di migrazione. Una migrazione effettiva potrebbe non includere alcune fasi o potrebbe includere più fasi. Invece di esaminare l'intera serie di fasi, gli articoli di questa guida esaminano attività e passaggi specifici che sono particolarmente importanti per una migrazione di Microsoft Sentinel.
Considerazioni
Esaminare queste considerazioni chiave per ogni fase.
| Fase | Considerazioni |
|---|---|
| Rilevazione | Identificare i casi d'uso e le priorità di migrazione come parte di questa fase. |
| Progettazione | Definire una progettazione dettagliata e un'architettura per l'implementazione di Microsoft Sentinel. Queste informazioni verranno usate per ottenere l'approvazione dagli stakeholder pertinenti prima di iniziare la fase di implementazione. |
| Implementazione | Quando si implementano i componenti di Microsoft Sentinel in base alla fase di progettazione e prima di convertire l'intera infrastruttura, valutare se è possibile usare il contenuto predefinito di Microsoft Sentinel anziché eseguire la migrazione di tutti i componenti. È possibile iniziare a usare gradualmente Microsoft Sentinel, a partire da un prodotto minimo fattibile (MVP) per diversi casi d'uso. Quando si aggiungono altri casi d'uso, è possibile usare questa istanza di Microsoft Sentinel come ambiente di test di accettazione utente (UAT) per convalidare i casi d'uso. |
| Operatività | Viene eseguita la migrazione del contenuto e dei processi SOC per assicurarsi che l'esperienza di analista esistente non venga interrotta. |
Identificare le priorità di migrazione
Usare queste domande per definire le priorità di migrazione:
- Quali sono i componenti dell'infrastruttura, i sistemi, le app e i dati più critici nell'azienda?
- Chi sono gli interessati alla migrazione? È probabile che la migrazione SIEM tocchi molte aree dell'azienda.
- Quali sono le priorità? Ad esempio il maggior rischio aziendale, requisiti di conformità, priorità aziendali e così via.
- Qual è la scalabilità e la sequenza temporale della migrazione? Quali fattori influiscono sulle date e sulle scadenze. Si sta eseguendo la migrazione di un intero sistema legacy?
- Si dispone delle competenze necessarie? Il personale addetto alla sicurezza è stato addestrato e pronto per la migrazione?
- Esistono blocchi specifici nell'organizzazione? Eventuali problemi influiscono sulla pianificazione e sulla pianificazione della migrazione? Ad esempio, problemi come il personale e i requisiti di formazione, date delle licenze, interruzioni inevitabili, esigenze aziendali specifiche e così via.
Prima di iniziare la migrazione, identificare i casi d'uso chiave, le regole di rilevamento, i dati e l'automazione nella soluzione SIEM attuale. Adottare un approccio alla migrazione come processo graduale. Riflettere con attenzione sulle prime risorse di cui eseguire la migrazione, sulle risorse le cui priorità vengono ridotte e sulle risorse che in realtà non richiedono la migrazione. Nella soluzione SIEM attuale, il carico di rilevamenti e casi d'uso in esecuzione potrebbe essere eccessivo per il team. Prima di iniziare la migrazione, decidere ciò che è realmente utile per l'azienda.
Identificare i casi d'uso
Quando si pianifica la fase di individuazione, usare le indicazioni seguenti per identificare i casi d'uso.
- Identificare e analizzare i casi d'uso correnti in base a minacce, sistema operativo, prodotto e così via.
- Qual è l'ambito? Eseguire la migrazione di tutti i casi d'uso o usare alcuni criteri di definizione delle priorità?
- Identificare gli asset di sicurezza più critici per la migrazione.
- Quali casi d'uso sono efficaci? Un buon punto di partenza consiste nell'esaminare quali rilevamenti hanno prodotto risultati nell'ultimo anno (falsi positivi rispetto a tassi positivi).
- Quali sono le priorità aziendali che influiscono sulla migrazione dei casi d'uso? Quali sono i principali rischi per l'azienda? Quali tipi di problemi comportano il maggior rischio per l'azienda?
- Definire le priorità in base alle caratteristiche dei casi d'uso.
- Valutare la possibilità di definire priorità più basse e più alte. È consigliabile concentrarsi su rilevamenti che imporrebbero il 90% di veri positivi nei feed di avvisi. I casi d'uso che causano un elevato tasso di falsi positivi potrebbero avere una priorità più bassa per l'azienda.
- Selezionare i casi d'uso che giustificano la migrazione delle regole in termini di efficienza e priorità aziendale.
- Esaminare le regole che non hanno attivato alcun avviso negli ultimi 6-12 mesi.
- Eliminare le minacce o gli avvisi di basso livello che normalmente si ignorano.
- Processo un processo di convalida. Definire scenari di test e compilare uno script di test.
- È possibile applicare una metodologia per assegnare le priorità ai casi d'uso? È possibile seguire una metodologia come MoSCoW per assegnare le priorità a una serie più snella di casi d'uso per la migrazione.
Passaggio successivo
In questo articolo si è appreso come pianificare e preparare la migrazione.