Al di là degli obblighi normativi in caso di data breach e quindi di notifica da effettuare al Garante della Protezione del Dati, è necessario comprendere come si risponde ad un incidente informatico.
La natura di un data breach
In questo sito è stato spiegato più volte: un data breach è una violazione di sicurezza informatica che può avere natura colposa quando è accidentale, dolosa quando è intenzionale e, stando alla ISO 27005, anche ambientale. In sintesi possiamo suddividere i data breach come segue.
- Natura accidentale (colposa): ad esempio quando un dipendente, per sbaglio, rovescia un bicchiere di acqua sul computer dell’organizzazione.
- Natura intenzionale (dolosa): ad esempio quando un attore malevolo attacca il sistema informatico dell’organizzazione con un virus.
- Natura ambientale (colposa): legato a fenomeni climatici, sismici, vulcanici, meteorologici. Per maggiori informazioni fare riferimento a questo articolo.
Queste sono le basi della natura di una violazione di sicurezza inforamatica e valgono in qualsiasi condizione d’incidente. Di conseguenza l’individuazione della natura è fondamentale e deve essere fatto in modo puntuale e tempestivo.
Rispondere ad un data breach
La risposta al data breach, ossia alla violazione di sicurezza (sia essa colposa o dolosa), richiede alcuni aspetti procedurali essenziali che sono ben riassunti all’interno dei Critical Security Controls (CSC) 8. Proviamo quindi a rispondere alla domanda come è necessario rispondere ad un data breach?
| DESCRIZIONE | Descrizione |
|---|---|
| Designare il Personale incaricato per la gestione degli incidenti. Salvaguardia 17.1 | Designare una persona chiave e almeno un sostituto che dirigerà la procedura di gestione degli incidenti. Il personale di gestione è responsabile del coordinamento e della documentazione delle attività di risposta e agli incidenti e relativo ripristino; ci si può avvalere di dipendenti interni, terzi o scegliendo una soluzione ibrida. Se si utilizza un fornitore di terze parti, designare almeno una persona interna all’azienda per supervisionarne il lavoro. Rivedere annualmente o quando si verificano cambiamenti aziendali significativi che potrebbero avere un impatto su questa Salvaguardia. |
| Stabilire e mantenere le informazioni di contatto per la segnalazione degli incidenti di sicurezza Salvaguardia 17.2 | Stabilire e mantenere l’elenco delle figure che devono essere informate degli incidenti di sicurezza. I contatti possono includere personale interno, fornitori di terze parti, forze dell’ordine, compagnie di assicurazione informatica, agenzie governative, partner del Centro di Condivisione e Analisi delle Informazioni (ISAC) o altre parti interessate. Verificare i contatti annualmente per garantire che le informazioni siano aggiornate. |
| Stabilire e Mantenere una Procedura Aziendale di Segnalazione degli Incidenti Salvaguardia 17.3 | Stabilire e mantenere una procedura per il personale aziendale per segnalare gli incidenti di sicurezza. Sono inclusi i tempi di segnalazione, il personale di riferimento, il meccanismo di segnalazione e le informazioni minime da riportare. Assicurare che il procedimento sia disponibile pubblicamente per tutto il personale. Rivedere annualmente o quando si verificano cambiamenti aziendali significativi che potrebbero avere un impatto su questa Salvaguardia. |
| Stabilire e Mantenere una Procedura di Risposta agli Incidenti Salvaguardia 17.4 | Stabilire e mantenere una procedura di risposta agli incidenti che preveda ruoli e responsabilità, requisiti di conformità e un piano di comunicazione. Rivedere annualmente o quando si verificano cambiamenti aziendali significativi che potrebbero avere un impatto su questa Salvaguardia. |
| Assegnare ruoli chiave e responsabilità Salvaguardia 17.5 | Assegnare ruoli chiave e responsabilità per la risposta agli incidenti, incluso il personale legale, IT, sicurezza delle informazioni, strutture, pubbliche relazioni, risorse umane, referenti di incidenti e analisti, se possibile. Rivedere annualmente o quando si verificano cambiamenti aziendali significativi che potrebbero avere un impatto su questa Salvaguardia |
| Definire i meccanismi di comunicazione durante la risposta agli incidenti Salvaguardia 17.6 | Determinare quali modalità primarie e secondarie verranno utilizzati per comunicare e segnalare durante un incidente di sicurezza. I meccanismi possono includere telefonate, e-mail o lettere. Tenere presente che determinati meccanismi, come le e-mail, potrebbero non funzionare in seguito ad un incidente di sicurezza. Rivedere annualmente o quando si verificano cambiamenti aziendali significativi che potrebbero avere un impatto su questa Salvaguardia. |
| Condurre Esercizi di Routine in Risposta agli Incidenti Salvaguardia 17.7 | Pianificare e condurre esercizi di routine e scenari in risposta agli incidenti per il personale chiave coinvolto nella procedura per prepararlo a fronteggiare l’eventualità in casi reali. Gli esercizi devono testare i canali di comunicazione, il processo decisionale e i flussi di lavoro. Effettuare test almeno su base annuale. |
| Effettuare revisioni post-incidente Salvaguardia 17.8 | Le revisioni post-incidente aiutano a prevenire il ripetersi di incidenti attraverso l’identificazione delle lezioni apprese e l’azione di follow-up. |
| Stabilire e mantenere i livelli per gli incidenti di sicurezza Salvaguardia 17.9 | Stabilire e mantenere i livelli per gli incidenti di sicurezza, inclusa, come minimo, la differenziazione tra un incidente e un evento. Gli esempi possono includere: attività anomale, vulnerabilità della sicurezza, debolezza della sicurezza, violazione dei dati, incidente di privacy, ecc. Rivedere annualmente o quando si verificano cambiamenti aziendali significativi che potrebbero avere un impatto su questa Salvaguardia. |
Per maggiori informazioni sul rapporto tra violazione di sicurezza, risposte e CSC si raccomanda la lettura del seguente articolo.
Gli esercizi di routine e la manleva tra CSC e ISO27001
La salvaguardia 17.7 prevede che siano condotti “esercizi” di routine e scenari in risposta agli incidenti. La realizzazione di queste simulazioni è fondamentale e ha lo scopo di garantire il mantenimento del controllo durante l’incidente reale. Le simulazioni sono essenziali per ricordare a tutte le parti coinvolte chi deve fare cosa, ma soprattutto in che modo e con quali tempi. È importante capire che gli esercizi di routine non coincidono direttamente con i penetration test, potrebbero essere semplicemente incentrati a valutare sotto-procedure o aspetti minori che afferiscono alla gestione dell’incidente. Bisogna distingue tra esercizi di routine e scenari.
L’esercizio di routine è la simulazione pratica di un processo specifico atto a raggiungere uno specifico scopo. Ad esempio la modalità di comunicazione tempestiva tra reparti, durante un data breach.
La simulazione di scenari è la ricostruzione di un incidente informatico, nella sua interezza e complessità, atto a valutare la competenza di gestione di tutti gli attori coinvolti.
La manleva è un argomento molto interessante sia in merito ai penetration test sia per le routine e la simulazione degli scenari. Non sempre, infatti, l’organizzazione può offrire ai tester un ambiente dedicato su cui effettuare le simulazioni e, quando questo accade, è necessario impiegare una parte dell’ambiente di produzione per poter istituire le simulazioni. Tuttavia l’ambiente di produzione è delicato: esso ospita tutti i dati “reali” e la loro manomissione, perdita, corruzione, comporterebbe un serio problema per l’organizzazione.
È altresì chiaro che il test viene precedentemente preparato offrendo garanzie in merito alla tutela e salvaguardia dei dati ma è prassi normale che il tester faccia firmare una manleva in merito a potenziali problematiche che potrebbero sorgere. In tal senso è molto interessante andare ad esaminare quanto prescritto nel controllo di sicurezza 8.34 della ISO 27001:2022
| ID | Titolo | Descrizione |
|---|---|---|
| 8.32 | Protection of information systems during audit testing Protezione dei sistemi informativi durante le prove di audit | Audit tests and other assurance activities involving assessment of operational systems shall be planned and agreed between the tester and appropriate management. Le prove di audit e le altre attività di garanzia che comportano la valutazione dei sistemi operativi devono essere pianificate e concordate tra il collaudatore e la direzione competente. |
È quindi prevista uno specifico controllo di sicurezza che avverte le organizzazioni di salvaguardare i propri dati prima dell’esecuzione dei test.
Il CREST
Forse non tutti conoscono il CREST (Council of Registered Ethical Security Testers), sul loro sito si legge:
CREST è un organismo internazionale senza scopo di lucro che rappresenta il settore globale della sicurezza informatica. Dal 2006 guidiamo la comunità della sicurezza informatica per innalzare collettivamente gli standard dei fornitori di servizi informatici e dei professionisti, garantendo la qualità del settore e, a sua volta, fornendo fiducia alla comunità degli acquirenti, al governo e agli enti di regolamentazione.
Fonte: CREST (Link)
In Italia, ad esempio, ci sono alcune emanazioni del CREST deputate a svolgere numerosi compiti interessanti quali, a mero titolo di esempio:
- Ethical Hacking (Offensive Security/Pen Test)
- Crisis Response
- SOC Solutions
- Security Architectures
Il CREST è citato all’interno delle CSCv8 perché ha contribuito a definire le salvaguardie di cui sopra.
