L’incident response plan per un sistema di sicurezza strutturato ed efficace: come realizzarlo

pittogramma Zerouno

Sponsored Story

L’incident response plan per un sistema di sicurezza strutturato ed efficace: come realizzarlo

Gli attacchi che raggiungono l’obiettivo sono sempre di più e i costi per ripartire possono essere ingenti. Perciò, è importante essere preparati qualora si dovesse essere colpiti. Roberto Veca, responsabile per la cyber security di Cyberoo, spiega come creare un efficace incident response plan

04 Lug 2022

di Redazione

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 sono un’eventualità sempre più frequente e diventano più sofisticati e mirati ogni giorno che passa. Così, fin troppo spesso ci si ritrova nei guai senza sapere cosa fare. Per questo motivo, è bene dotarsi di un incident response plan che cauteli l’organizzazione nel caso di un attacco sfortunatamente ben riuscito.

Ma come strutturarlo in modo efficace? Ce lo spiega Roberto Veca, responsabile per la cyber security in Cyberoo.

Cosa mettere in sicurezza

“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”.

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.

WP: Cybersecurity Strumento di business

Quando si può accettare il rischio

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.

Non sottovalutate la 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 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à “solal lettura”. In questo modo, si mantiene il controllo indirizzando anche le necessità del business.

Una procedura lunga e impegnativa

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 evita di spendere ingenti somme nel caso si debba ripristinare l’attività dopo essere stati attaccati.

R

Redazione

Nel corso degli anni ZeroUno ha esteso la sua originaria focalizzazione editoriale, sviluppata attraverso la rivista storica, in un più ampio sistema di comunicazione oggi strutturato in un portale, www.zerounoweb.it, una linea di incontri con gli utenti e numerose altre iniziative orientate a creare un proficuo matching tra domanda e offerta.

Argomenti trattati

Aziende

C
Cyberoo

Articolo 1 di 4