Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Manuel Roccon : 21 Novembre 2024 10:21
A cura di Manuel Roccon e Matteo Brandi
Se i criminali informatici non dormono mai, anche le normative sulle sicurezza informatica si muovono. Ormai la direttiva NIS2, recepita con il Decreto Legislativo 138 del 4 settembre 2024, si è messa in moto. Con la NIS2, la nuova direttiva europea per la sicurezza informatica, le aziende devono prendere sul serio la protezione dei dati e garantire la business continuity e rispetto alla NIS questa si estende anche alla loro supplychain.
Noi con elmetto e piccone (sicurezza first!) abbiamo scavato a fondo nella NIS2 per portarvi solo le pepite d’oro: quei punti che riteniamo fondamentali per proteggere la tua azienda contro i criminali informatici applicando la norma.
Acquista il corso Dark Web & Cyber Threat Intelligence (e-learning version)
Il Dark Web e la Cyber Threat Intelligence rappresentano aree critiche per comprendere le minacce informatiche moderne. Tra ransomware, data breach e attività illecite, le organizzazioni devono affrontare sfide sempre più complesse per proteggere i propri dati e le infrastrutture. Il nostro corso “Dark Web & Cyber Threat Intelligence” ti guiderà attraverso i meccanismi e le strategie utilizzate dai criminali informatici, fornendoti competenze pratiche per monitorare, analizzare e anticipare le minacce.
Accedi alla pagina del corso condotto dall'Prof. Pietro Melillo sulla nostra Academy e segui l'anteprima gratuita.
Per un periodo limitato, potrai utilizzare il COUPON CTI-16253 che ti darà diritto ad uno sconto del 20% sul prezzo di copertina del corso
Per ulteriori informazioni, scrivici ad [email protected] oppure scrivici su Whatsapp al 379 163 8765
Supporta RHC attraverso:
Caro lettore, due avvertimenti però:
Per una applicazione pratica della NIS2, il pilastro principale è l’articolo è l’art.21, in particolare nel paragrafo 2, i cui concetti sono riportati anche nell’art.24 del decreto di recepimento (DLGS 138 del 4 Settembre 2024).
Abbiamo diviso questo articolo in due parti, in questo pezzo ci dedicheremo ad approfondire fino al punto e del art. 21 del NIS2.
https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX%3A32022L2555
https://www.gazzettaufficiale.it/eli/id/2024/10/01/24G00155/SG
Andiamo a vederli nel dettaglio:
Pensare che la protezione dei sistemi aziendali consista solo in firewall e antivirus potrebbe essere l’errore numero uno. Certo, fanno parte del quadro, ma non sono la soluzione completa. Le politiche di sicurezza informatica vanno molto più in profondità: devono valutare tutti i punti deboli di un’azienda e aggiornarsi costantemente.
Ad esempio, hai mai considerato che un dipendente non formato può diventare il miglior alleato dei criminali informatici? Basta una email di phishing cliccata senza pensarci troppo.
Inoltre quanto sono importanti i tuoi dati se finissero in mani sbagliate? Molto importanti anche i sistemi DLP che monitorano e mitigano la esfiltrazione dei dati, come il blocco delle chiavette o altri supporti di memorizzazione esterni così da evitare che vengano copiati dati e portati via e/o dimenticati in giro. Possono essere create anche regole per tipologia di documento o contenuto, in modo da bloccare questi quando vengono caricati anche in internet (es. un impiegato infedele che esegue upload su qualche drive online).
È per questo che l’analisi dei rischi è fondamentale: significa mappare ogni vulnerabilità, anticipare possibili scenari e sapere come reagire. Una buona analisi dei rischi non solo individua i punti critici ma ti aiuta a distribuire meglio le risorse per la difesa, concentrando l’attenzione dove serve di più.
Sembra un foschia impenetrabile? Un faro c’è e si chiama ISO 27001. L’ISO 27001 è il sistema di gestione della sicurezza informatica che mette ordine nella tua azienda, stabilendo standard chiari su come proteggere i dati e minimizzare i rischi di attacchi informatici. Con un approccio strutturato e una protezione continua, questo strumento potente ti aiuta a chiudere le porte ai criminali informatici.
Quando i criminali informatici colpiscono, non c’è tempo per tentennamenti o “la prossima volta andrà meglio”. La tua azienda è sotto attacco e senza un piano solido, rischi di vedere tutto andare in fumo. La gestione degli incidenti informatici è la tua unica ancora di salvezza: un set di strategie per reagire all’impatto devastante di attacchi, violazioni e perdite di dati.
Quanti piani servono? Fondamentalmente due: il Disaster Recovery Plan ed il Response Plan. Vediamoli.
Un disaster recovery plan non è solo un elenco di cose da fare, ma una strategia solida che garantisce che ogni dato, file o sistema critico sia protetto e ripristinabile.
Il piano deve prevedere eventi come:
Un piano di ripristino da disastro deve avere come minimo queste informazioni:
Ovviamente non deve rimanere “lettera morta”, deve essere testato, corretto e ti devi assicurare tutti abbiamo compreso quale è il proprio ruolo.
La strategia comunicativa non è un punto da sottovalutare. In base a quello che si dice e come lo si comunica, la situazione, che già non è rosea, peggiora drammaticamente se lo si fa in modo errato. Avere comunicati studiati e preparati in anticipo, è il modo per non fare ulteriori danni.
Se ti serve un template lo trovi qui: https://www.microfocus.com/media/unspecified/disaster_recovery_planning_template_revised.pdf
Il response plan è il fratello del disaster recovery, ma più immediato, pronto all’azione. Serve quando un criminale informatico fa il primo passo e sei già nel pieno dell’incidente. Questo piano ha un obiettivo semplice: contenere, limitare i danni e, se possibile, bloccare l’attacco. I punti cardine sono:
Preparazione: tanto banale quanto fondamentale ma anche disattesa: essere preparati. Tutto qui.
Identificazione: riconoscere l’evento che dovrebbe essere classificato come incidente informatico.
Contenimento: isolare l’incidente e non consentire che si propaghi.
Eradicazione: risolvere il problema.
Ripristino: Riparare i sistemi compromessi, recuperare i dati e far ripartire le attività interrotte durante l’incidente.
Lezione appresa: È la parte più importante. È un documento dove si descrive l’accaduto, le procedure adottate, quello che ha funzionato ma soprattutto quello che non ha funzionato.
Se non tieni traccia del passato, è difficile pianificare il futuro.
Il punto focale della normativa è la continuità operativa. La norma prevede di minimizzare e ridurre il più possibile gli effetti di un Cyber attacco nella business continuity sia sulla tua attività che sulla catena di fornitura.
Cosa di più importante di un backup per ripristinare i dati in caso di compromissione? In particolare che sia certo di riuscire a ripristinarli in tempo accettabile, anzi mi fermerei prima di riuscire a ripristinarli.
E’ di fondamentale importanza valutare bene che i nostri backup siano robusti, affidabili e inattaccabili dalle minacce informatiche e possano essere ripristinati in tempi certi e accettabili compatibili con il proprio business e quello dei nostri processi aziendali.
Come ad esempio eseguire la regola del 3-2-1 in cui utilizzare 3 copie su 2 tipologie di supporto di diverso, di cui uno offsite, che di recente, con l’aiuto delle nuove tecnologie, si è evoluto in 3-2-1-1-0, aggiungendo l’immutabilità del dato. Lo 0 finale poi sta a significare che il sistema riesca a verificare che ci siano 0 errori, così da essere sicuro che quando servono i backup, siano usabili al 100%.
Ma la tecnologia non basta. Occorre una valutazione dei tempi di RTO e RPO per valutare bene la quantità accettabile di dati che possa essere persa dall’ultimo backup ed i tempi di ripristino che siano allineati con il business dell’azienda. Considerare inoltre di tenere un numero sufficientemente di backup per non rischiare che quelli creati non siano tutti compromessi da un infezione presente sui sistemi da molto tempo!
Molti non lo considerano, ma un backup incrementale tradizionale compresso e cifrato di qualche TB in una rete, potrebbe essere ripristinabile in 1 o 2 giornate, ma per comprendere bene questo tempo è necessario fare dei test di cui parleremo tra poco…
Parliamo dei famosi backup in cloud.
Ok tutto bello e magari anche vero, ma quanto tempo ci vuole per ripristinarlo con la tua linea da 10mb/s Tera e Tera di dati? Forse è meglio pensare di andare a prenderli in bicicletta… il tuo provider ti permette di far avere i dati in tempi accettabili? Una tecnologia iperconvergente (HCI), per esempio, impiegherebbe poche decine di minuti per ripristinare i dati nel virtual storage di un’intera organizzazione.
Quindi la domanda è: le tue tecnologie attuali sono corrette e soddisfacenti per soddisfare la tua business continuity? Smarcato il piano tecnico, inoltre, sono fondamentali le esercitazioni e i test di ripristino periodici per verificare nel piano pratico che tutto funzioni. E’ necessario scrivere un documento che evidenzi cosa fare in caso di disastro, cosa iniziare a ripristinare prima in accordo con il business.
Piano che dovrebbe essere già presente per i guasti hardware, da integrare per quelli cyber, inserendo anche quelli di natura cyber.
Finché facciamo i test interni in totale tranquillità andrà sempre tutto bene, pensiamo a un Lunedì mattina quando scopriamo che i sistemi siano totalmente offline e oltre a ripristino dei sistemi dobbiamo coordinare i vari fornitori, i clienti, la comunicazione con l’esterno, i vari reparti per arrivare al DPO in conformità alle normative vigenti in caso di data breach.
Tanto per la legge di Murphy queste cose succedono o il Venerdì sera con la variante del Sabato oppure il Lunedì mattina. In queste situazioni senza una linea da adottare ben definita il panico è assicurato e così anche la capacità di prendere scelte lucide e ponderate è seriamente compromessa.
Per cui è necessario aver già definito i possibili scenari e tutti gli step per arrivare al ripristino totale, a istituire un unità di crisi con delle persone ben identificate assieme a procedure e checklist ben definite. Nulla deve essere lasciato al caso in queste situazioni. Ne abbiamo già parlato in “Gestione degli incidenti” ma…repetita juvant!
Nella NIS 2 aspetti relativi alla sicurezza non riguardano solo soggetti direttamente impattati, ma si estende anche alla catena di fornitura. Una particolarità: il soggetto coinvolto è responsabile (pecuniariamente) di verificare che la NIS2 venga applicata nella sua catena (situazione un po’ complicata). In poche parole i fornitori di soggetti che entrano nella NIS2, devo aver messo in pratica le raccomandazioni principali per non impattare sui clienti in caso di incidente informatico.
Questo per due motivi. Il primo è che la compromissione di un fornitore possa impattare il suo diretto cliente e bloccarne operatività. Pensiamo a un fornitore IT con i dati di accesso dei clienti che viene compromesso: il passaggio ai propri clienti potrebbe essere molto rapido. L’altro aspetto riguarda la continuità operativa: un blocco di un fornitore potrebbe impattare sull’operatività dei propri clienti con conseguente blocco della produzione.
Possiamo avere un quadro più chiaro leggendo il regolamento di esecuzione della Commissione Europea della normativa al punto 5.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AL_202402690
Il testo spiega che dovresti accertarti di verificare che la tua catena di fornitura abbia adottato i requisiti minimi per difendere se stessa e i suoi clienti.
Leggendo il decreto attuativo della Commissione Europea per la direttiva 2022/2555 (NIS2), che risulta ancora in consultazione pubblica, si intravede la possibilità che nel caso in cui il fornitore non riesca a dare garanzie sulla propria sicurezza informatica, questa possa essere gestita dal cliente stesso.
Vi è mai capitato di trovare delle vulnerabilità sui software che un fornitore vi sviluppa o fornisce? Succede spesso trovarsi di fronte a un muro di gomma quando chiediamo di riconoscere la vulnerabilità sistemarla oppure chiedere delle ulteriori misure di sicurezza non previste, esempio l’implementazione del MFA. Cose sicuramente che ai fornitori costa tempo e denaro implementare….
Quindi si pone l’opzione di revisione dei contratti con i fornitori (come suggerito dal punto 5.1.4) aggiungendo per esempio delle SLA sulla risoluzione di segnalazioni incluse anche penali o rescissione del contratto. Potrebbe essere necessario verificare il background di fornitori (hanno già subito databreach in passato?) e i suoi dipendenti oltre ad obblighi di far pervenire delle prove di audit, come penetration test o vulnerability assessment fatti regolarmente sui sistemi e software dei fornitori.
Un ulteriore approfondimento di Sandro Sana qui (https://www.redhotcyber.com/post/enisa-avvia-la-consultazione-pubblica-guida-tecnica-per-rafforzare-le-misure-di-cybersicurezza-delle-organizzazioni-europee/)
Sicuramente il legislatore vuole software più sicuri. Come? I casi sono così tanti che non se ne può fare un elenco. Devono essere più sicuri.
Inoltre il decreto legislativo di recepimento il quale all’art.27 al comma 1 recita: “L’Autorità nazionale competente NIS,[…], può imporre ai soggetti essenziali e ai soggetti importanti di utilizzare categorie di prodotti TIC, servizi TIC e processi TIC, di cui, rispettivamente, all’articolo 2, comma 1, lettere ff), gg) e hh), sviluppati dal soggetto essenziale o importante o acquistati da terze parti, che siano certificati nell’ambito dei sistemi europei di certificazione della cybersicurezza di cui all’articolo 49 del regolamento (UE)”
Mentre il citato articolo 49 del regolamento UE 2019/881 dice: “Strategie efficaci in materia di cibersicurezza dovrebbero essere basate su buoni metodi di valutazione dei rischi, sia nel settore pubblico che in quello privato. I metodi di valutazione dei rischi sono utilizzati a diversi livelli, e non esiste una prassi comune per quanto riguarda le modalità per una loro applicazione efficiente. […]”
Ma allora??
Ci illumina il comma 2 dell’art.27 del decreto di recepimento: “Nelle more dell’adozione di pertinenti sistemi europei di certificazione della cybersicurezza di cui all’articolo 49 del regolamento (UE) 2019/881, l’Autorità nazionale competente NIS, secondo le modalita’ di cui all’articolo 40, comma 5, puo’ imporre ai soggetti essenziali e ai soggetti importanti di utilizzare categorie di prodotti TIC, servizi TIC e processi TIC, sviluppati dal soggetto essenziale o importante o acquistati da terze parti, che siano certificati nell’ambito di schemi di certificazione riconosciuti a livello nazionale o europeo.”
Qui ci viene in soccorso l’art. 58 della NIS2 che cita le ISO/IEC 30111 e ISO/IEC 29147 che “forniscono orientamenti sulla gestione delle vulnerabilità e sulla divulgazione delle vulnerabilità” mentre l’art.79 “[…] Le misure di gestione dei rischi di cibersicurezza dovrebbero pertanto affrontare anche la sicurezza fisica e dell’ambiente dei sistemi informatici e di rete includendo misure volte a proteggere detti sistemi da guasti del sistema, errori umani, azioni malevole o fenomeni naturali, in linea con le norme europee e internazionali, come quelle di cui alla serie ISO/IEC 27000”
Prima di aprire il portafoglio per l’acquisto di un software, ti dovrai sincerare sia su come viene gestita la sicurezza dello stesso che sulle clausole contrattuali per la gestione e la risoluzione delle vulnerabilità scoperte lungo il cammino. Per chi sviluppa software poi, diventa una pratica molto consigliabile quella di far fare i test di sicurezza a soggetti che non abbiano preso parte allo sviluppo: quasi sempre più guardi il codice e meno vedi. Un paio di occhi freschi spesso sono la soluzione.
Speriamo che fin qui questi spunti ti siano stati utili, nel prossimo articolo tratteremo i rimanenti punti del art. 21 f, g, h, i, j della direttiva.
Manuel Roccon
