Passaggio 5. Sviluppare e testare casi d'uso
Si applica a:
- Microsoft Defender XDR
I metodi consigliati per distribuire Microsoft Defender XDR nel Centro operazioni di sicurezza (SOC) dipendono dal set corrente di strumenti, processi e set di competenze del team SOC. Mantenere l'igiene informatica tra le piattaforme può essere difficile a causa della grande quantità di dati provenienti da decine se non centinaia di origini di sicurezza.
Gli strumenti di sicurezza sono correlati. L'attivazione di una funzionalità in una tecnologia di sicurezza o la modifica di un processo può a sua volta interrompere un'altra funzionalità. Per questo motivo, Microsoft consiglia al team soc di formalizzare un metodo per definire e assegnare priorità ai casi d'uso. I casi d'uso consentono di definire i requisiti e i processi di test per le operazioni SOC in vari team. Crea una metodologia per l'acquisizione delle metriche per determinare se i ruoli e la combinazione di attività corretti sono allineati al team corretto con il set di competenze corretto.
Sviluppare e formalizzare il processo dei casi d'uso
Il SOC deve definire uno standard e un processo di alto livello per lo sviluppo di casi d'uso, che sarebbero regolati dal team di supervisione soc. Il team di supervisione SOC deve collaborare con l'azienda, l'IT, legale, le risorse umane e altri gruppi per assegnare priorità ai casi d'uso per il SOC che alla fine si faranno strada nei runbook e nei playbook del team SOC. La priorità dei casi d'uso si basa sugli obiettivi, ad esempio la conformità o la privacy.
Le attività di supervisione SOC correlate allo sviluppo di casi d'uso includono:
- Requisiti
- Esigenze di personale o formazione
- Licenze software
- Contratto fornitore
- Gestione del piano
- Gestione del registro dei casi d'uso
- Gestione/aggiornamento dei modelli
Per facilitare i processi di creazione di runbook e playbook, creare un albero delle decisioni sui casi d'uso. Questa figura illustra un esempio.
Dopo aver definito e approvato uno standard di casi d'uso di alto livello, il passaggio successivo consiste nel creare e testare un caso d'uso effettivo. Le sezioni seguenti usano gli scenari di analisi delle minacce e delle vulnerabilità e anti-phishing come esempi.
Esempio di caso d'uso 1: nuova variante di phishing
Il primo passaggio nella creazione di un caso d'uso consiste nel delineare il flusso di lavoro usando una bacheca. Ecco un esempio di una bacheca di alto livello per una nuova notifica di exploit di phishing a un team di Intelligence per le minacce.
Richiamare il flusso di lavoro del caso d'uso, ad esempio 1
Dopo l'approvazione della bacheca, il passaggio successivo consiste nel richiamare il flusso di lavoro del caso d'uso. Ecco un processo di esempio per una campagna anti-phishing.
Esempio di caso d'uso 2: Analisi delle minacce e delle vulnerabilità
Un altro scenario in cui è possibile usare un caso d'uso è l'analisi delle minacce e delle vulnerabilità. In questo esempio, il SOC richiede che le minacce e le vulnerabilità vengano corrette rispetto agli asset tramite processi approvati che includono l'analisi degli asset.
Ecco un esempio di storyboard di alto livello per la Gestione delle vulnerabilità di Microsoft Defender di asset.
Richiamare il flusso di lavoro del caso d'uso, ad esempio 2
Ecco un processo di esempio per l'analisi delle minacce e delle vulnerabilità.
Analizzare l'output del caso d'uso e le lezioni apprese
Dopo che un caso d'uso è stato approvato e testato, è necessario identificare le lacune tra i team di sicurezza, insieme a persone, processi e tecnologie Microsoft Defender XDR coinvolte. Microsoft Defender XDR tecnologie devono essere analizzate per determinare se sono in grado di raggiungere i risultati desiderati. Questi elementi possono essere rilevati tramite un elenco di controllo o una matrice.
Ad esempio, nell'esempio di scenario anti-phishing, i team SOC potrebbero aver effettuato le individuazioni in questa tabella.
| Team SOC | Requisito | Persone soddisfare i requisiti | Processo per soddisfare i requisiti | Tecnologia pertinente | Gap identificato | Log delle modifiche dei casi d'uso | Esente (Y/N) |
|---|---|---|---|---|---|---|---|
| Team di intelligence e analisi delle minacce | Le origini dati alimentano correttamente i motori di intelligence sulle minacce. | Analista/ingegnere di Intelligence per le minacce | Requisiti del feed di dati stabiliti, trigger di intelligence sulle minacce da origini approvate | Microsoft Defender per identità, Microsoft Defender per endpoint | Il team di Intelligence per le minacce non ha usato lo script di automazione per collegare Microsoft Defender XDR'API con i motori intel per le minacce | Aggiungere Microsoft Defender XDR come origini dati ai motori di minacce Aggiornare l'run book dei casi d'uso |
N |
| Team di monitoraggio | Le origini dati alimentano correttamente i dashboard di monitoraggio | Avvisi di & di analista SOC di livello 1,2 | Flusso di lavoro per la segnalazione del punteggio di sicurezza del Centro conformità & sicurezza | Analizzare gli avvisi in Microsoft Defender XDR Monitoraggio del punteggio di sicurezza |
Nessun meccanismo per gli analisti SOC per segnalare il corretto rilevamento di nuove varianti di phishing per migliorare il punteggio di sicurezza Visualizzare i report di sicurezza della posta elettronica nel portale di Microsoft Defender |
Aggiungere un processo per tenere traccia del miglioramento del punteggio di sicurezza nei flussi di lavoro di report | N |
| Engineering e SecOps Team | Gli aggiornamenti del controllo delle modifiche vengono eseguiti nei runbook del team SOC | Tecnico SOC di livello 2 | Procedura di notifica di controllo delle modifiche per i runbook del team SOC | Modifiche approvate ai dispositivi di sicurezza | Le modifiche alla connettività Microsoft Defender XDR alla tecnologia di sicurezza SOC richiedono l'approvazione | Aggiungere Microsoft Defender for Cloud Apps, Defender per identità, Defender per endpoint, Security & Compliance Center ai runbook SOC | Y |
Inoltre, i team soc avrebbero potuto effettuare le individuazioni descritte nella tabella seguente per quanto riguarda lo scenario di Gestione vulnerabilità di Defender descritto in precedenza:
| Team SOC | Requisito | Persone soddisfare i requisiti | Processo per soddisfare i requisiti | Tecnologia pertinente | Gap identificato | Log delle modifiche dei casi d'uso | Esente (Y/N) |
|---|---|---|---|---|---|---|---|
| Supervisione SOC | Tutti gli asset connessi alle reti approvate vengono identificati e categorizzati | Supervisione SOC, proprietari di BU, proprietari di applicazioni, proprietari di asset IT e così via. | Sistema centralizzato di gestione degli asset per individuare ed elencare la categoria di asset e gli attributi in base al rischio. | ServiceNow o altri asset. Inventario dei dispositivi di Microsoft 365 |
Solo il 70% degli asset è stato individuato. Microsoft Defender XDR il rilevamento della correzione è efficace solo per gli asset noti | Servizi di gestione del ciclo di vita degli asset maturi per garantire che Microsoft Defender XDR abbia una copertura del 100% | N |
| Engineering & SecOps Teams | L'impatto elevato e le vulnerabilità critiche negli asset vengono corretti in base ai criteri | Tecnici secOps, analisti SOC: conformità & vulnerabilità, progettazione della sicurezza | Processo definito per la categorizzazione di vulnerabilità ad alto rischio e critiche | dashboard Gestione delle vulnerabilità di Microsoft Defender | Defender per endpoint ha identificato dispositivi con impatto elevato e avvisi elevati senza piano di correzione o implementazione dell'attività consigliata da Microsoft | Aggiungere un flusso di lavoro per notificare i proprietari di asset quando è necessaria un'attività di correzione entro 30 giorni per criterio; Implementare un sistema di ticketing per notificare ai proprietari degli asset i passaggi di correzione. | N |
| Monitoraggio di Teams | Lo stato di minaccia e vulnerabilità viene segnalato tramite il portale Intranet aziendale | Analista SOC di livello 2 | Report generati automaticamente da Microsoft Defender XDR che mostrano lo stato di correzione degli asset | Analizzare gli avvisi in Microsoft Defender XDR Monitoraggio del punteggio di sicurezza |
Nessuna visualizzazione o report del dashboard comunicati ai proprietari di asset in merito allo stato di minaccia e vulnerabilità degli asset. | Create script di automazione per popolare lo stato di correzione della vulnerabilità degli asset ad alto rischio e critico per l'organizzazione. | N |
In questi casi d'uso di esempio, il test ha rivelato diverse lacune nei requisiti del team SOC che sono state stabilite come baseline per le responsabilità di ogni team. L'elenco di controllo dei casi d'uso può essere completo in base alle esigenze per garantire che il team soc sia preparato per l'integrazione Microsoft Defender XDR con requisiti SOC nuovi o esistenti. Poiché si tratta di un processo iterativo, il processo di sviluppo dei casi d'uso e il contenuto di output del caso d'uso servono naturalmente ad aggiornare e maturare i runbook del SOC con le lezioni apprese.
Aggiornare runbook e playbook di produzione
Dopo che il test dei casi d'uso è stato risolto per tutte le lacune, le lezioni apprese e le metriche raccolte in essi possono essere incorporate nei runbook di produzione (processi operativi) del team SOC e nei playbook (risposte agli eventi imprevisti e procedure di escalation).
La manutenzione dei runbook e dei playbook del team SOC può essere organizzata in molti modi. Ogni team soc può essere responsabile per il proprio, o può essere presente una singola versione centralizzata per tutti i team da condividere in un repository centrale. La gestione di runbook e playbook per le singole organizzazioni si basa su dimensioni, set di competenze, ruoli e separazione dei compiti. Dopo che un runbook è stato aggiornato, il processo di aggiornamento del playbook deve essere seguito.
Usare un framework standard per l'escalation
I playbook sono i passaggi che i team soc devono seguire quando si verifica un evento reale, in base alla corretta integrazione e test del caso d'uso. Pertanto, è fondamentale che il SOC segua un approccio formalizzato alla risposta agli eventi imprevisti, ad esempio il NIST Incident Response Standard che è diventato uno degli standard leader del settore per la risposta agli eventi imprevisti.
Il processo di risposta agli eventi imprevisti in quattro passaggi del NIST include quattro fasi:
- Preparazione
- Rilevamento e analisi
- Contenimento, eliminazione e ripristino
- Attività post-evento imprevisto
Esempio: Monitoraggio dell'attività della fase di preparazione
Una delle basi principali di un playbook di escalation è garantire che ci sia poca ambiguità su ciò che ogni team SOC dovrebbe fare prima, durante e dopo un evento o un evento imprevisto. È quindi consigliabile elencare le istruzioni dettagliate.
Ad esempio, la fase di preparazione può includere una matrice if/then o XoR di attività. Nel caso del caso d'uso del nuovo esempio di variante di phishing, una matrice di questo tipo potrebbe essere simile alla seguente:
| Perché l'escalation è garantita? | Passaggio successivo |
|---|---|
| Avviso nel monitoraggio SOC valutato come critico attivato >500/ora | Vai al Playbook A, Sezione 2, Attività 5 (con un collegamento alla sezione playbook) |
| ECommerce ha segnalato un potenziale attacco DDoS | Richiamare playbook B-Section C, Activity 19 (con un collegamento alla sezione playbook) |
| Executive ha segnalato un messaggio di posta elettronica sospetto come tentativo di spear phishing | Vai a Playbook 5, Sezione 2, Attività 5 (con un collegamento alla sezione playbook) |
Dopo aver eseguito la fase di preparazione, le organizzazioni devono richiamare le fasi rimanenti, come descritto da NIST:
- Rilevamento e analisi
- Contenimento, eliminazione e ripristino
- Attività post-evento imprevisto
Passaggio successivo
Passaggio 6. Identificare le attività di manutenzione soc
Consiglio
Per saperne di più, Engage con la community Microsoft Security nella community tech: Microsoft Defender XDR Tech Community.