d3sre/intelligentprocesslifecycleIl ciclo di vita intelligente del processo dei difensori cyber attivi
Il ciclo di vita intelligente del processo dei difensori informatici attivi
Questa repository GitHub ospita i file relativi al poster delle categorie di falsi positivi ed errori nei servizi di security operation. L'obiettivo è definire uno standard di reporting open source per i report dei Security Operation Center. I KPI qui pubblicati sono focalizzati sulla creazione di statistiche rilevanti per il miglioramento continuo delle attività operative di cyber difesa.
Queste informazioni sono state presentate per la prima volta al FIRST 2020 insieme a Eireann Leverett(che ha apportato la sua esperienza in materia di gestione del rischio); il video è disponibile qui: https://www.youtube.com/watch?v=pR02cZlPakU L'articolo sottoposto a revisione paritaria creato per questo contenuto può essere trovato qui: https://dl.acm.org/doi/10.1145/3499427
La registrazione dell'intervento che ho tenuto a SwissCyberStorm 2021 sulla tassonomia per l'integrità e il monitoraggio della configurazione di conformità può essere trovata qui: https://www.youtube.com/watch?v=ra4LZouxIyk
La registrazione dell'intervento che ho tenuto ad Area41 2022 sui problemi nella gestione delle vulnerabilità può essere trovata qui: https://www.youtube.com/watch?v=qdgY6aAfUAk
| Disciplina: | Monitoraggio della Sicurezza | Anomalie di Configurazione | Gestione delle Vulnerabilità |
|---|---|---|---|
| Validazione tramite: | Casi d'uso SIEM, log EDR/AV, IDS/IPS, log NDR | Monitoraggio dell'integrità, monitoraggio della configurazione di conformità | Scan delle vulnerabilità, verifica delle patch |
| Articolo pubblicato: | Versione sottoposta a revisione paritaria | Articolo autopubblicato | Articolo sottoposto a revisione paritaria |
| Link alla presentazione: | Hack.Lu 2019 Youtube | SwissCyberStorm 2021 Youtube | Area41 2022 Youtube |
| Slide: | Slide Hack.Lu 2019 | Slide SwissCyberStorm 2021 | Slide Area41 |
| File JSON della tassonomia: | File JSON MISP Security Monitoring | File JSON MISP per il monitoraggio di integrità e conformità | File JSON MISP per la gestione delle vulnerabilità & file JSON MISP per i guasti di rilevamento |
Le seguenti metriche suggerite sono maggiormente correlate ai valori del team responsabile del sistema o al tipo di sistemi sorgente. I valori target sono in confronto al numero totale di eventi generati da questo servizio per unità di tempo (mese, settimana, trimestre, ecc.).
Le seguenti metriche suggerite sono maggiormente correlate ai valori del team responsabile del sistema o al tipo di sistemi sorgente. I valori target sono in confronto al numero totale di eventi generati da questo servizio per unità di tempo (mese, settimana, trimestre, ecc.).
Le seguenti metriche suggerite sono maggiormente correlate ai valori del team responsabile del sistema o al tipo di sistemi sorgente. I valori target sono in confronto al numero totale di eventi generati da questo servizio per unità di tempo (mese, settimana, trimestre, ecc.).
Gli altri miei KPI di miglioramento continuo per il security monitoring sono disponibili qui: https://github.com/d3sre/Use_Case_Applicability
Questo poster è stato creato da Desiree Sacher con sponsorizzazione per l'opera grafica da parte di layer9solutions.de
Questo poster è stato pubblicato sotto licenza Creative Commons BY: https://creativecommons.org/licenses/by/4.0/
| KPI | Spiegazione | Valore target | Owner | Tipo di rischio | Impatto sul business | Esempio illustrativo |
|---|
| Numero di 'violazioni legittime autorizzate da change' | Questo valore riflette eventi che di solito sono classici falsi positivi, in cui tutti i processi di change ufficiali sono stati seguiti correttamente ma il SOC non è stato incluso nel processo e quindi non ha potuto prevenire il falso allarme | < 10 % | Compliance | Endogeno | Rischio di governance | Una modifica approvata ufficialmente ad Apache cambia il formato di configurazione e gli strumenti di rilevamento generano un alert sulla modifica. |
| Numero di 'errori di configurazione nella baseline' | Questo valore riflette quali configurazioni di sistema (o persino modelli di configurazione) necessitano di miglioramento. | < 10 % | Compliance/Operational | Endogeno | Rischio di gestione delle modifiche e della conformità | Le baseline per i modelli di configurazione sono state tratte dagli ambienti di sviluppo invece che da quelli di produzione. |
| Numero di 'limitazioni nei prodotti di verifica' riscontrate | Se troppi di questi eventi vengono generati dalle configurazioni, lo strumento che li causa dovrebbe essere messo in discussione. | < 5 % | Compliance/Operational | Endogeno | Rischio operativo del SOC | Le regole Snort non possono essere limitate con precisione per rilevare il cambiamento che ci interessa, ma se hanno uno scope più ampio producono falsi positivi. |
| Numero di 'attività senza necessità di change' | Sembra esserci una discrepanza tra lo scope di sicurezza definito e quello verificato. Le lacune dovrebbero essere verificate. | < 5 % | Policy | Endogeno | Disallineamento policy-operatività che porta a un SOC sovraccarico | Il sysadmin pulisce i file di log per risparmiare spazio, il che non richiede approvazione, ma genera un alert nel SOC. |
| Numero di 'modifiche non autorizzate senza causa legittima' | Numeri molto alti → L'integrazione tra processo di sicurezza e processo IT richiede una rielaborazione; Numeri molto bassi → Le configurazioni non rilevano oppure siete al sicuro | dipende :) | Policy | Endogeno | Potenziale intrusione/Prioritizzare l'indagine | Un server IIS ha aggiunto un utente e l'amministratore nega di essere a conoscenza dell'evento. |
| Numero di modifiche senza documentazione formale | Il numero di violazioni legittime con documentazione di change mancante evidenzia sia i casi in cui il SOC non ha avuto possibilità di automatizzare i falsi allarmi, sia i casi in cui i dipendenti non rispettano i processi formali. | <5% | Policy/Compliance | Endogeno | Rischio di amministrazione Shadow IT | Un sysadmin modifica la configurazione del server Apache senza documentazione formale di change management (anche se sarebbe stata approvata). |
| KPI | Spiegazione | Valore target | Owner | Tipo di rischio | Impatto sul business | Esempio illustrativo |
|---|
| Numero di ritardi dovuti a SLA irragionevoli/'SLA scadente' | Se questo valore è molto spesso elevato, in correlazione con le applicazioni che esegui, potresti essere in grado di influenzare i documenti SLA o le policy | 0 | Operational/Contractual | Esogeno | I team di Risk Appetite e Contractual Management devono allineare le aspettative | Gli switch di rete hanno solo due finestre di change all'anno e non vengono patchati, ma i contratti penalizzano comunque la controparte per i sistemi non patchati. |
| Numero di ritardi dovuti a 'problemi di risorse' o numero medio di giorni di ritardo dovuti a 'problemi di risorse' | Se ciò accade troppo spesso, può illustrare come la gestione del personale incida sulla qualità dei servizi di sicurezza. Se si verifica troppo spesso, è importante inserire una voce di rischio | 0 | Contractual | Endogeno/Esogeno | Gestione del rischio operativo | Problemi di risorse del personale in alcuni team ritardano l'applicazione delle patch |
| Numero di patch installate in tempo | Questo è l'obiettivo. Se non può essere raggiunto troppo spesso, le policy o le ragioni degli insuccessi dovrebbero essere riviste | >80% | Counter-Party/Contractual | Esogeno | L'aspettativa di cyber risk non viene soddisfatta | 99 computer Windows su 100 vengono patchati in tempo, ma 1 è considerato ad alto rischio per la patch. |
| Conteggio dei 'contesti di sfruttabilità non forniti' | Numeri molto alti → Potresti non ricevere risposte oneste oppure il tuo processo di identificazione delle minacce è difettoso | dipende :) | Counter-Party/Contractual | Esogeno | Potenziali pratiche scadenti di accettazione del rischio | Il team di ingegneria tecnica rimanda ogni patch classificandola come non sfruttabile per evitare di impiegare risorse. |
| KPI | Spiegazione | Valore target | Owner | Tipo di rischio | Impatto sul business | Esempio illustrativo |
|---|
| Numero di 'punti ciechi identificati' | Ogni volta che non è possibile creare un rilevamento, questo dovrebbe essere tracciato, possibilmente creando voci di rischio. | < 5% | Operational/Contractual | Endogeno/Esogeno | Nessuna visibilità nel registro dei rischi operativi | I log di Active Directory non possono essere acquisiti dal SOC perché il team di identity management non ha risorse sufficienti. |
