É«¶à¶àÊÓƵ

A seguito della pandemia di COVID-19, è emersa ancora di più la necessità delle organizzazioni di predisporre una pronta risposta alle situazioni di crisi. Mentre le organizzazioni hanno adottato il modello del lavoro a distanza - destinato probabilmente a consolidarsi - la loro capacità di pianificare una risposta agli incidenti avrebbe dovuto adeguarsi a questa nuova realtà. Questa pianificazione include anche l'attenzione ai nuovi rischi che tale realtà comporta. Un grave incidente di sicurezza informatica rappresenta una vera situazione di crisi per qualsiasi ente e le organizzazioni lungimiranti dovrebbero farsi trovare opportunamente preparate.

Sono stati sviluppati molti modelli per guidare le organizzazioni in questa pianificazione, compresi quelli presentati dal National Institute of Standards and Technology (NIST), dal SysAdmin, Audit, Network, Security (SANS) e dal Community Emergency Response Team (CERT). Pur nella loro diversità, questi schemi sono simili nei principi fondamentali. Riteniamo che il modello del NIST sia particolarmente semplice da attuare e che articoli in modo chiaro tutte le fasi del ciclo di risposta agli incidenti. Di seguito viene descritto, passo dopo passo, il ciclo di vita della risposta agli incidenti secondo il modello del NIST.

Utilizzeremo questi passaggi per esaminare il ciclo di vita della risposta agli incidenti e dimostrare come una pianificazione approntata molto tempo prima che si verifichi un incidente può fare la differenza tra un disastro aziendale e una reazione metodica in grado di gestire il caos.

1 PREPARAZIONE

1.1 I principi fondamentali

In molti casi, la fortuna aiuta chi si è preparato piuttosto che gli audaci. Inevitabilmente, arriverà il momento in cui si materializzerà un rischio e si verificherà un incidente informatico. La preparazione costituisce il fondamento su cui si basa qualsiasi processo di risposta futura. In questa fase, è necessario adottare un approccio alla sicurezza informatica basato sui rischi, investendo del tempo per:

• comprendere il contesto tecnologico e imprenditoriale della propria organizzazione;
• individuare e monitorare le minacce;
• documentare i rischi della propria organizzazione.

Una volta definiti i rischi e individuati i beni a rischio, è necessario implementare un piano operativo che permetta ai propri team di gestire gli incidenti, qualora si verifichino. Un incidente informatico grave mette di fronte a una sfida importante. Normalmente comporta un notevole carico di stress e caos per i team interni coinvolti e interessa molti soggetti interni ed esterni.

Il momento peggiore per pianificare la risposta a un incidente è proprio quando questo si verifica. Tuttavia, un adeguato piano di risposta agli incidenti, quando viene regolarmente simulato e testato, genererà alcuni automatismi nel flusso di risposta del team.< /p>

Ciò permette al team di essere più efficace.

Il piano specifico, seppure nella sua genericità, deve:

• contenere un flusso di risposta attuabile: il lettore deve essere in grado di seguire l'ordine cronologico della risposta in passaggi concreti e attuabili. Includere un diagramma di flusso e liste di cose da fare fornisce chiarezza e impedisce di fare passi falsi nel bel mezzo dell'incidente.
• Descrivere come devono essere classificati gli incidenti: devono essere previsti criteri chiari per la classificazione degli incidenti. La gravità degli incidenti viene comunemente classificata come critica, elevata, moderata o bassa. Non tutti gli incidenti richiedono la stessa attenzione, allocazione di risorse o team dedicati . Non di rado gli incidenti di bassa e moderata gravità possono essere gestiti dai team informatici ricorrendo a manuali operativi, mentre gli incidenti di gravità più elevata spesso richiedono competenze più ampie, allocazione di risorse aggiuntive, una gestione più incisiva e, in molti casi, un supporto esterno.
• Stabilire canali di comunicazione chiari: i piani di risposta agli incidenti devono prevedere chiaramente quali informazioni inoltrare alle altre funzioni ed ai soggetti interessati e quando e come trasmettergliele. La comunicazione formale consente a tutti di essere allineati e riduce i malintesi durante il processo di risposta. Piccoli fraintendimenti possono esacerbare una situazione già difficile fino a farla degenerare in un completo disastro.
• Assegnare e descrivere ruoli e responsabilità: durante un incidente, tutti i soggetti interessati devono essere consapevoli dei propri ruoli e delle proprie responsabilità. La formalizzazione di ruoli e responsabilità deve essere definita in modo chiaro in una sezione specifica del piano di risposta agli incidenti. Deve riguardare non solo il team tecnico di base, ma tutti i soggetti coinvolti nel processo di risposta. Questi soggetti possono comprendere persone delle aree legale, marketing, relazioni pubbliche, produzione e risorse umane.
• Coinvolgere i soggetti esterni: possono essere forze dell'ordine o enti di regolamentazione, compagnie di assicurazione, consulenti legali esterni tra cui esperti in violazioni, consulenti in relazioni pubbliche e studi di informatica forense.
• Sviluppare manuali più prescrittivi: individuare gli incidenti più comuni o quelli legati ai propri rischi critici e definire manuali attuabili che possano guidare nella risposta legata a tali rischi. Questi manuali devono contenere passaggi più prescrittivi rispetto a quelli previsti dal flusso di risposta principale. Per esempio, per un grosso rivenditore potrebbe essere utile un manuale per le fughe di informazioni di pagamento, mentre un produttore potrebbe avere necessità di manuali sugli scenari ransomware per limitare al minimo i tempi di fermo.
• Prendere in considerazione altre forme di pianificazione: i piani di risposta agli incidenti attingono e si allargano ad altre forme di pianificazione aziendale. È necessario che qualsiasi piano di risposta agli incidenti faccia riferimento e sia collegato ai piani di sicurezza informatica per la continuità operativa e di disaster recovery, nonché ai piani di gestione delle crisi. Qualsiasi fattore di attivazione (trigger) di questi piani deve essere previsto e definito chiaramente per permettere una risposta alle crisi più integrata.

1.2 Consapevolezza

Un piano di risposta ben concepito è essenziale, ma non efficace in termini pratici se coloro i quali potrebbero essere chiamati in causa non sono opportunamente sensibilizzati al riguardo. Il metodo utilizzato per sensibilizzare la risposta agli incidenti può variare. Per i team tecnici, che sono il fulcro del processo di risposta, un esame completo del piano, una serie di sessioni di domande e risposte ed esercitazioni pratiche basate su scenari sono verosimilmente i metodi migliori. Per i team direttivi, materiale aggiuntivo di riferimento rapido che definisca ruoli, responsabilità e attività previste può essere una risorsa preziosissima per la preparazione alla risposta agli incidenti.

1.3 La pratica rende (i test) perfetti!

Il piano dà il massimo valore se testato periodicamente e aggiornato con miglioramenti continui. Una volta completato l'addestramento, il piano deve essere messo alla prova tramite esercitazioni di simulazione.

Per i piani di più recente elaborazione, queste esercitazioni possono essere meno complesse: per esempio, ci si può limitare ad applicare il piano in base a diversi scenari e a riesaminarne completezza e flusso.

Per i programmi più elaborati, è possibile sviluppare esercitazioni più complesse. In questo caso, il processo decisionale, le conoscenze e la comunicazione del team di risposta vengono testate mediante una serie di input che modificano la situazione via via che questa si sviluppa. Entrambi gli approcci possono essere migliorati ricorrendo a soggetti terzi per l'ideazione e la gestione dell'esercitazione. Il soggetto terzo può apportare ulteriori competenze in termini di realismo degli scenari e stimolare la partecipazione dei membri del team piuttosto che facilitare la sessione.

Di importanza altrettanto cruciale sono i test funzionali sulle soluzioni tecnologiche che consentono una risposta efficace, come il ripristino dei backup. Questi test possono assumere la forma di interruzioni parallele. In questo caso, viene creato e testato un secondo sistema infrastrutturale in modo da non interrompere la regolare operatività dell'organizzazione. Nel caso di un test a interruzione totale, viene testata l'infrastruttura principale dell'organizzazione. I test a interruzione totale sono per loro natura più penalizzanti, ma offrono il feedback più utile sui piani di ripristino.

2 RILEVAMENTO E ANALISI

2.1 Metodi di rilevamento

La fase di rilevamento si avvale di controlli di sicurezza tecnica o amministrativa per individuare attività dannose nell'ambiente. Alcune delle attività comuni in questa fase sono descritte di seguito.

• Monitoraggio della rete: dai controlli di base - come l'uso di firewall - alle soluzioni più avanzate - come l'implementazione di sistemi antintrusione (IDS) - il monitoraggio dell'attività di dispositivi e utenti sulla rete è essenziale. L'avvento della tracciatura comportamentale supportata dall'apprendimento automatico (machine learning ) ha reso la generazione di di allarmi da parte di queste soluzioni più semplice, più intelligente e più agile che mai. Tuttavia, tale sistema ha i suoi limiti. Basti pensare al massiccio spostamento verso i modelli del lavoro remoto a seguito della pandemia di COVID-19. Molti di questi controlli di monitoraggio della rete si sono rivelati vani perché gran parte dell'attività in rete in grado di generare avvisi ha luogo ora al di fuori del raggio d'azione delle soluzioni di sicurezza on-premise.
• Monitoraggio endpoint: le soluzioni antivirus tradizionali, così come le soluzioni comportamentali più avanzate, possono avvisare della presenza di infezioni su specifici dispositivi. Poiché non si basano sulla presenza del dispositivo in una rete aziendale, possono in parte colmare la lacuna di visibilità determinata dal lavoro da remoto.
• Monitoraggio del Dark Web: si tratta solitamente di soggetti esterni che forniscono questo servizio come metodo di rilevamento di violazioni, cercando nel Dark Web e in altri mercati clandestini informazioni aziendali trafugate e avvisando l'azienda vittima se e quando queste informazioni vengono ritrovate. Questo tipo di monitoraggio può rivelarsi essenziale perché serve come ultima linea di difesa nel rilevare un incidente prima che venga pubblicamente riconosciuto.

Esistono altri controlli che possono essere implementati e le misure intraprese durante la fase di preparazione devono consentire all'organizzazione di stabilire a quali di questi controlli assegnare la priorità.

2.2 Processi di allertamento

Un adeguato piano di risposta agli incidenti abbinato a una forza lavoro ben addestrata aumenta considerevolmente le probabilità che, dopo aver rilevato un'attività dannosa, i team siano in grado di riconoscerla, smistarla correttamente e sapere come allertare il resto dell'organizzazione. In questi casi, il personale è in grado di seguire processi documentati per stabilire la gravità dell'incidente, quali team devono essere chiamati in causa e quali soggetti esterni devono essere avvisati.

Per esempio, gli avvisi generati dai servizi di monitoraggio che segnalano che è in corso un incidente ransomware possono provocare il panico. Tuttavia, la presenza di un team capace di implementare il piano di risposta aumenta le probabilità che il panico sia superato e che vengano intraprese azioni efficaci. L'organizzazione non potrà che beneficiare della capacità di affrontare il problema adottando misure sviluppate in un momento di maggiore calma.

Avvalersi di soggetti esterni come esperti nel campo delle violazioni o studi di informatica forense può fornire ulteriori capacità di analisi ed esperienza.

3 CONTENIMENTO, ELIMINAZIONE E RIPRISTINO

Come si può vedere nel flusso del modello di risposta NIST precedentemente analizzato, il rilevamento affluisce nel contenimento, nell'eliminazione e nel ripristino e ciascuna di queste fasi può essere ripetuta più volte nel corso di un determinato incidente. L'intento è rendere consapevoli della probabilità che, durante il processo di risposta, emergano e si debbano affrontare nuovi problemi.

Consideriamo lo stesso incidente ransomware descritto in precedenza. Nel nostro esempio, immaginiamo che il rilevamento iniziale dell'infezione, il contenimento della sua diffusione, gli sforzi per eliminare il ransomware e il ripristino da backup siano tutti in azione. Mentre è in corso l'incidente, l'indagine con metodi scientifici potrebbe rivelare che l'aggressore ha accesso anche ad altri sistemi, il che rappresenta un nuovo rilevamento e implica che il processo ricominci da capo. Senza una pianificazione preventiva, il nuovo flusso di azioni intrapresepotrebbe perdersi negli ingranaggi delle azioni già in atto, non essere affrontata in tempo e sfociare in nuovi incidenti.

La segnalazione e la comunicazione sono di vitale importanza in questa fase. Grazie a metodi e frequenze di comunicazione già noti e stabiliti nel piano di risposta agli incidenti, i dirigenti e gli altri soggetti interessati possono essere tenuti al corrente della situazione. Ciò consente loro di prendere decisioni informate con un impatto minimo dell'attività del team che si sta occupando della risposta.

Attività post-incidente

Una volta ripristinata la piena operatività dell'organizzazione, si può essere tentati di lasciarsi alle spalle l'incidente. Tuttavia, tale atteggiamento è dannoso per la crescita dell'organizzazione, oltre che per la sua prontezza nell'affrontare incidenti simili in futuro. Capire le cause dell'incidente, esaminare come il proprio programma può essere migliorato e apportare i perfezionamenti necessari costituiscono un essenziale circuito di retroazione. Questo circuito di retroazione deve essere formalizzato nel piano di risposta.

Avvalersi di soggetti esterni come esperti nel campo delle violazioni o studi di informatica forense può fornire ulteriori capacità di analisi ed esperienza. Le competenze legali offerte dagli esperti in violazioni possono aiutare a comprendere meglio il quadro giuridico in cui opera l'organizzazione e consentire di adattarne le prassi a tale contesto. Inoltre, gli studi di informatica forense dispongono di un vasto bagaglio di esperienze dal momento che si trovano ad affrontare quotidianamente incidenti nei settori più disparati. Sono quindi in condizione di fornire capacità di analisi dell'incidente specifico e consigli sulle migliori pratiche da adottare nella conseguente risposta. Gli spunti forniti devono essere integrati in qualsiasi esercitazione post-incidente per migliorare continuamente i piani, i processi e le procedure di risposta.

Conclusioni

Un incidente grave di sicurezza informatica può farvi vivere i giorni peggiori della vostra vita professionale. Tuttavia, con l'opportuna pianificazione e preparazione, la vostra organizzazione potrà rispondere in modo efficace e ripristinare la sua operatività. Un tale approccio rappresenta un passo enorme verso la minimizzazione dell'impatto dell'incidente e può fare la differenza tra un disastro aziendale e una storia di successo.