Passaggio 5. Sviluppare e testare casi d'uso

Articolo
04/26/2024

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.

Share via