Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
I team del Centro operativo di sicurezza (SOC) usano soluzioni centralizzate di gestione delle informazioni di sicurezza e degli eventi (SIEM) e soluzioni di orchestrazione, automazione e risposta di sicurezza (SOAR) per proteggere il patrimonio digitale sempre più decentralizzato. Anche se i 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ò acquisire dati sia da risorse on-premises che cloud, garantendo una copertura dell'intero ambiente.
Questo articolo illustra i motivi della migrazione da un SIEM legacy e descrive come pianificare le diverse fasi della migrazione.
processo di migrazione di Microsoft Sentinel
In questa guida si apprenderà come eseguire la migrazione del 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 Microsoft Sentinel. Il programma consente di semplificare e accelerare la migrazione, incluse indicazioni sulle procedure consigliate, risorse e assistenza di esperti in ogni fase. Per saperne di più, contatta il team del tuo account.
Che cos'è Microsoft Sentinel?
Microsoft Sentinel è una soluzione scalabile, nativa del cloud, siem (Security Information and Event Management) e di orchestrazione della sicurezza, automazione e risposta (SOAR). Microsoft Sentinel offre analisi intelligente della sicurezza e intelligence sulle minacce in tutta l'azienda. Microsoft Sentinel offre un'unica soluzione per il rilevamento degli attacchi, la visibilità delle minacce, la ricerca proattiva e la risposta alle minacce. Altre informazioni su Microsoft Sentinel.
Perché eseguire la migrazione da un SIEM legacy?
I team SOC devono affrontare una serie di sfide durante la gestione di un SIEM legacy:
- Risposta lenta alle minacce. I SIEM legacy usano regole di correlazione difficili da mantenere e inefficaci per identificare le minacce emergenti. Inoltre, gli analisti soc si trovano di fronte a grandi quantità di falsi positivi, molti avvisi provenienti da molti componenti di sicurezza diversi e volumi sempre più elevati di log. L'analisi di questi dati rallenta le attività dei team SOC per rispondere alle minacce critiche nell'ambiente.
- Problemi di ridimensionamento. Man mano che i tassi di inserimento dei dati aumentano, i team SOC sono sfidati a ridimensionare il proprio SIEM. Invece di concentrarsi sulla protezione dell'organizzazione, i team SOC devono investire nell'implementazione e nella manutenzione dell'infrastruttura e sono vincolati da limiti di archiviazione o di interrogazione.
- Analisi manuale e risposta. I team SOC hanno bisogno di analisti altamente qualificati per elaborare manualmente grandi quantità di avvisi. I team SOC sono sovraccaricati e i nuovi analisti sono difficili da trovare.
- Gestione complessa e inefficiente. I team SOC in genere supervisionano l'orchestrazione e l'infrastruttura, gestiscono le connessioni tra siem e varie origini dati ed eseguono aggiornamenti e patch. Queste attività sono spesso a scapito della valutazione e dell'analisi critiche.
Un SIEM nativo del cloud risolve questi problemi. Microsoft Sentinel raccoglie i dati automaticamente e su larga scala, rileva minacce sconosciute, analizza le minacce con intelligenza artificiale e risponde rapidamente agli eventi imprevisti con l'automazione predefinita.
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 completa consente di mantenere la protezione sia per gli asset basati sul cloud, ovvero Microsoft Azure, AWS o GCP, sia per le soluzioni SaaS, ad esempio Microsoft Office 365.
Questo diagramma descrive le fasi generali incluse in una migrazione tipica. Ogni fase include obiettivi chiari, attività chiave e risultati e risultati finali specificati.
Le fasi di questo diagramma sono una linea guida per il completamento di una procedura di migrazione tipica. Una migrazione effettiva potrebbe non includere alcune fasi o includere più fasi. Invece di esaminare il set completo di fasi, le attività di migrazione Microsoft Sentinel e i passaggi esaminano attività e passaggi specifici particolarmente importanti per una migrazione Microsoft Sentinel.
Considerazioni sulla pianificazione della migrazione
Esaminare queste considerazioni chiave per ogni fase.
| Fase | Considerazione |
|---|---|
| Scopri | 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 Microsoft Sentinel. Queste informazioni verranno usate per ottenere l'approvazione dagli stakeholder pertinenti prima di iniziare la fase di implementazione. |
| Implementare | Quando si implementano componenti Microsoft Sentinel in base alla fase di progettazione e prima di convertire l'intera infrastruttura, valutare se è possibile usare Microsoft Sentinel contenuto predefinito anziché eseguire la migrazione di tutti i componenti. È possibile iniziare a usare Microsoft Sentinel gradualmente, a partire da un prodotto minimo valido (MVP) per diversi casi d'uso. Quando si aggiungono altri casi d'uso, è possibile usare questa istanza di Microsoft Sentinel come ambiente UAT (User Acceptance Testing) per convalidare i casi d'uso. |
| Operazionalizza | È necessario migrare i contenuti e i processi SOC per garantire che l'attuale esperienza degli analisti non venga interrotta. |
Identificare le priorità di migrazione
Usa queste domande per individuare con precisione le tue priorità di migrazione:
- Quali sono i componenti dell'infrastruttura, i sistemi, le app e i dati più critici dell'azienda?
- Chi sono gli stakeholder nella migrazione? È probabile che la migrazione SIEM tocchi molte aree dell'azienda.
- Cosa guida le tue priorità? Ad esempio, il rischio aziendale più elevato, i requisiti di conformità, le priorità aziendali e così via.
- Quali sono la portata e le tempistiche della migrazione? Quali fattori influiscono sulle date e sulle scadenze. Si esegue la migrazione di un intero sistema legacy?
- Hai le competenze necessarie? Il personale addetto alla sicurezza è formato e pronto per la migrazione?
- Sono presenti blocchi specifici nell'organizzazione? Eventuali problemi influiscono sulla pianificazione e sulla programmazione della migrazione? Ad esempio, questioni come esigenze di personale e formazione, date delle licenze, blocchi obbligatori, esigenze aziendali specifiche e così via.
Prima di iniziare la migrazione, identificare i casi d'uso principali, le regole di rilevamento, i dati e l'automazione nel SIEM corrente. Affrontare la migrazione come processo graduale. Siate intenzionali e riflettete attentamente su cosa migrare per primo, a cosa assegnare una priorità inferiore e cosa, in realtà, non è affatto necessario migrare. Il team potrebbe avere un numero eccessivo di rilevamenti e casi d'uso in esecuzione nel SIEM corrente. Prima di iniziare la migrazione, decidere quali sono attivamente utili 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ù importanti per la migrazione.
- Quali casi d'uso sono efficaci? Un buon punto di partenza è quello di esaminare quali rilevamenti hanno prodotto risultati nell'ultimo anno (falsi positivi rispetto al tasso positivo).
- Quali sono le priorità aziendali che influiscono sulla migrazione dei casi d'uso? Quali sono i maggiori rischi per la tua azienda? Quali tipi di problemi mettono maggiormente a rischio l'azienda?
- Assegnare priorità alle caratteristiche dei casi d'uso.
- Prendere in considerazione l'impostazione di priorità più basse e superiori. Ti consigliamo di concentrarti sui rilevamenti che garantiscano un tasso di veri positivi del 90% nei feed di avvisi. I casi d'uso che causano un tasso elevato di falsi positivi potrebbero essere una priorità inferiore per l'azienda.
- Selezionare i casi d'uso che giustificano la migrazione delle regole in termini di priorità aziendale ed efficacia:
- Esaminare le regole che non hanno attivato avvisi negli ultimi 6-12 mesi.
- Eliminare le minacce o gli avvisi di basso livello ignorati di routine.
- Preparare un processo di convalida. Definire scenari di test e compilare uno script di test.
- È possibile applicare una metodologia per assegnare priorità ai casi d'uso? È possibile seguire una metodologia come MoSCoW per assegnare priorità a un set più snello di casi d'uso per la migrazione.
Passaggio successivo
In questo articolo si è appreso come pianificare e preparare la migrazione.