Un incident response plan è un processo ben formalizzato che segue precise metodologie perché, oggi più che mai, la cyber security non è un aspetto da sottovalutare.
Purtroppo, gli attacchi alla sicurezza informatica sono un’eventualità sempre più frequente e diventano più sofisticati e mirati ogni giorno che passa. Così, fin troppo spesso le aziende si ritrovano nei guai senza sapere cosa fare.
Con l’IRP sono stabiliti chiaramente i ruoli e le responsabilità, le linee guida su come documentare l’incidente e le sue conseguenze, e dettaglia le azioni necessarie per ridurre il danno e prevenire futuri danni.
Inoltre, la preparazione e la pianificazione sono fondamentali per un efficace incident response plan, che deve essere regolarmente testato e aggiornato per far fronte alle emergenti minacce informatiche.
Ma come strutturare in modo efficace l’incident response plan? Ce lo spiega Roberto Veca, responsabile per la cyber security in Cyberoo.
Incident response plan: difende ogni entità aziendale
“Per impostare un incident response plan è innanzitutto necessario capire cosa si vuole proteggere, cosa si vuole mettere in sicurezza” afferma Veca. “Bisogna suddividere il sistema azienda in infrastrutture, servizi e applicazioni e, quindi, stabilire come difendere ogni singola entità. A tal fine, si devono attribuire differenti livelli di importanza: per esempio, il server documentale non può essere offline più di un giorno, mentre gli applicativi del sito web possono esserlo al massimo per una sera. Questa classificazione permette di capire come indirizzare le minacce sui target da proteggere”.
“È molto importante formalizzare tutti gli step – aggiunge Veca – e si deve considerare l’intero elenco delle possibili minacce, applicarlo a tutte le infrastrutture, ai sistemi e ai servizi. In pratica, a tutto ciò che è ritenuto di valore e, in quanto tale, deve essere oggetto dell’incident response plan”. Completata questa fase, rimane un ultimo passaggio: valutare la probabilità di accadimento.
“Come si può ipotizzare se avverrà o meno un attacco? Questo è uno dei passaggi più difficili” precisa Veca. “Si può ottenere una stima abbastanza affidabile ricorrendo ad alcuni metodi. Prima di tutto, analizzando i dati storici: è già successo? Non è mai successo? La risposta a queste domande fornisce una prima evidenza. Si possono, poi, effettuare alcuni assessment, come identificare possibili vulnerabilità, stabilire se il sistema è aggiornato e ogni quanto viene aggiornato. Agendo in questo modo si raccolgono i dati necessari a ipotizzare una probabilità di accadimento. Con le adeguate competenze, si ottiene un’indicazione ragionevole, che può spaziare da assolutamente impossibile a probabilissimo, passando per probabilità bassa, media o alta”.
IRP: identificare le metodologie di mitigazione
Stabilita la probabilità di accadimento – e con in mano la lista delle vulnerabilità – non resta che attivarsi. Muovendosi in funzione del livello di criticità o della minaccia applicata al target, si identificano le metodologie di mitigazione. “Possono essere tecnologiche” precisa Veca. “Se, per esempio, non si ha un firewall e i sistemi sono esposti in Internet, la probabilità di attacco è altissima e l’impatto altrettanto perché i sistemi sono critici. È, quindi, necessario implementare uno strumento di protezione”.
Tuttavia, la mitigazione può essere anche di processo. Per esempio, è indispensabile definire in anticipo come reagire in caso di incidenti, come lo spegnimento di un sistema. Sapere immediatamente chi chiamare, quali siano gli SLA e a chi affidare i vari compiti consente di ottenere un vantaggio strategico nella response.
C’è, infine, la possibilità di mettere in atto una mitigazione editativa, ossia si fa in modo di spegnere un sistema o di spostarlo affinché il problema non esista più. Solitamente si segue questa via quando è l’unico modo di approcciare un problema.
Quando accettare il rischio di un eventuale attacco cyber
Si sa che il “rischio zero” non esiste; tuttavia, in alcune situazioni lo si può accettare, come quando si ha una probabilità di incidente e di impatto basse. Può essere, per esempio, il caso di un sistema non critico che, se anche dovesse essere compromesso, non inciderebbe sull’attività lavorativa. “Si è certi di questa situazione perché è stato fatto un assessment e, alla fine, proteggere quel sistema costerebbe più di quanto di spenderebbe per rimetterlo in sesto se attaccato” sottolinea Veca.
“A quel punto si può accettare il rischio. Solitamente questa decisione si prende quando, tutto sommato, il rischio tra impatto e probabilità è molto basso. Però è anche vero che spesso non si può proteggere tutto in azienda o il costo per farlo sarebbe altissimo”.
Su un sito web vetrina, che non è il core business aziendale e che è poco visitato, si può quindi decidere di non implementare sistemi anti DDoS, web application firewall o sistemi avanzatissimi per la protezione. La logica è semplice: se anche il sito venisse bloccato e venisse ripristinato anche in tempi lunghi, non sarebbe un problema.
Sicurezza informatica della supply chain
C’è un ultimo aspetto da considerare che, per certi versi, può far parte dell’incident response plan: la sicurezza della supply chain, che sempre più spesso è il vettore prescelto per attaccare la grande azienda.
In un contesto sempre più digitalizzato e interconnesso, la catena di fornitura può rappresentare un punto debole per la sicurezza delle informazioni. I fornitori, infatti, potrebbero non avere gli stessi livelli di sicurezza dell’azienda principale, rendendosi così potenziali vettori di attacchi informatici.
Per questo motivo, è fondamentale valutare attentamente la sicurezza dei fornitori e stabilire protocolli di protezione adeguati. Questi possono includere audit di sicurezza regolari, implementazione di standard di sicurezza comuni, formazione sulla sicurezza per i dipendenti dei fornitori e la creazione di piani di risposta ad incidenti specifici per la supply chain.
Inoltre, l’organizzazione dovrebbe avere un piano di backup nel caso uno dei fornitori subisca un incidente di sicurezza che potrebbe interrompere la catena di fornitura. Questo potrebbe includere l’identificazione di fornitori alternativi o la possibilità di aumentare la produzione interna per compensare la mancanza di fornitura.
In questo caso, il suggerimento di Roberto Veca è stabilire dei requisiti minimi di sicurezza che i fornitori devono rispettare. In tal modo, si consente al CISO di stilare una lista del livello di rischio che può essere attribuito a ogni fornitore e, quindi, di prendere le dovute precauzioni.
“Soprattutto, si deve assicurare la continuità del business senza intaccare l’efficienza” evidenzia Veca. “In pratica, si dovrebbe agire in modo da far decadere la probabilità di attacco o di compromissione tramite data breach. Per esempio, nel momento in cui si devono fornire dei dati alla supply chain, tale risultato lo si può ottenere non operando via mail, ma usando un server dedicato”.
In questa ipotesi, il server a cui i fornitori possono accedere tramite l’inserimento di username e password e di una multifactor authentication, dovrebbe essere impostato in modalità “sola lettura”. In questo modo, si mantiene il controllo indirizzando anche le necessità del business.
IRP: una procedura lunga e impegnativa ma che fa risparmiare
Creare un incident response plan è un’attività che tutte le aziende dovrebbero considerare, perché cautela nei confronti di un attacco che ha raggiunto l’obiettivo. “Questa attività – conclude Roberto Veca – se è avviata partendo da zero, nel caso di una società media, ma anche medio-piccola, solitamente richiede mesi di lavoro solo per definire il piano, tra interviste, preparazione, documentazione e analisi. Definito il piano, si devono effettuare le attività mitigative e poi, nel caso di incidente, seguire alla lettera quanto stabilito”.
Insomma: una procedura lunga e impegnativa, ma che permette di evitare di spendere ingenti somme nel caso si debba ripristinare l’attività dopo essere stati attaccati.
Articolo originariamente pubblicato il 04 Lug 2022
