Qualunque azienda deve dotarsi di un piano di risposta agli incidenti o incident response plan, che le consenta di far fronte efficacemente a situazioni di questo tipo. Nessuna organizzazione, grande o piccola, che disponga di una rete informatica (più o meno complessa) connessa ad Internet, infatti, può sentirsi al sicuro di fronte al rischio di attacchi informatici e diventa quindi necessario che si prepari in modo tale da rilevarli prima possibile, rimuoverne le cause, contenere gli effetti e ripristinare i sistemi allo stato originario.
Al giorno d’oggi, infatti, sono sempre più frequenti gli attacchi informatici perpetrati ai danni di aziende, istituzioni ed enti pubblici. Tali attacchi sono diventati molto sofisticati e spesso impiegano diverse tecniche combinate per raggiungere il loro obiettivo: ad esempio sfruttamento di vulnerabilità zero-day (per le quali non esiste ancora una patch di sicurezza), spear phishing, malware fileless (residente solo nella memoria RAM), ransomware, per citarne solo alcune.
Questa tipologia di attacchi, oltre ad essere tecnicamente avanzata, è anche in genere condotta da gruppi organizzati (a volte finanziati e supportati da alcuni governi) che agiscono con scopi ben precisi e in modo molto determinato e coordinato. La loro azione può protrarsi per tempi lunghi (mesi o anche anni) prima di essere scoperta dall’organizzazione vittima. È stato coniato un termine apposito per descrivere questa classe di attacchi, ossia APT (Advanced Persistent Threat).
Indice degli argomenti
Incident response plan: piano di sicurezza per le aziende
Mettere a punto un piano di incident response è dunque fondamentale non solo per limitare i danni e preservare il business e/o la mission dell’organizzazione, ma anche per ottemperare alle disposizioni di legge in materia di sicurezza informatica e protezione dei dati, in primo luogo l’ormai celebre GDPR (General Data Protection Regulation), come vedremo in seguito nell’articolo.
Oltre a questo, ci sono standard specifici a cui aziende e organizzazioni operanti in determinati settori devono conformarsi; ad esempio, le aziende che processano transazioni con carte di pagamento devono attenersi al Payment Card Industry Data Security Standard (PCI DSS).
Che cos’è l’incident response?
L’incident response può essere definito come un insieme di procedure e risorse utilizzate per reagire ad incidenti informatici.
La prima questione che si pone è cosa si intenda per incidente informatico. Dal punto di vista della sicurezza informatica, un incidente è un evento (o serie di eventi) che viola le politiche di sicurezza definite dall’organizzazione e che viene causato con la deliberata intenzione di procurarsi un vantaggio e/o causare un danno.
Un incidente informatico può essere causato da un attaccante esterno così come da un appartenente alla stessa organizzazione (insider threat o minaccia interna).
Spesso un incidente informatico è associato ad una violazione di dati personali (data breach), ossia ad accesso, copia ed utilizzo non autorizzato dei dati da parte dell’attaccante. I dati sono infatti molto appetibili perché costituiscono “l’oro digitale” dell’economia online; possono essere dati segreti militari, governativi o industriali, dati anagrafici personali e dati sensibili, numeri di carte di credito e così via.
Gli strumenti per identificare un incidente informatico
Un incidente informatico, soprattutto nelle organizzazioni medio-grandi, è in genere individuato tramite strumenti automatizzati di monitoraggio della rete e rilevamento di intrusioni, quali IDS (Intrusion detection system), SIEM (Security Information Event Management) e NGAV (Next Generation Antivirus).Questi software raccolgono e analizzano (utilizzando anche algoritmi di Intelligenza Artificiale) i dati provenienti dai sistemi e dalla rete (log, connessioni di rete, processi in esecuzione, chiamate di sistema, modifiche al file system ecc.) per individuare eventuali anomalie, discostamenti dalla norma ed i cosiddetti IOC (Indicators of compromise), che possono appunto rivelare un’intrusione nella rete od un’infezione da malware.
Una volta rilevato un incidente, l’organizzazione deve saper reagire ad esso prontamente e per questo è necessario che abbia già predisposto un programma di risposta agli incidenti.
La risposta all’incidente può essere gestita internamente all’organizzazione oppure affidata ad un’azienda esterna specializzata in questo settore (MSSP o Managed Security Service Provider). Infatti, un’organizzazione potrebbe non avere le risorse e le competenze per condurre internamente una risposta ad un incidente, ma deve comunque essere preparata per l’evenienza e sapere a priori a quale partner esterno affidarsi, in modo da minimizzare i tempi di risposta.
CSIRT: il team indispensabile per rispondere agli incidenti informatici
Per creare un efficace piano di risposta agli incidenti, è consigliabile utilizzare un framework come quello definito nella guida “Computer Security Incident Handling Guide” del NIST (National Institute of Standards and Technology), pubblicata alcuni anni fa ma che ancora rappresenta un ottimo riferimento in materia.
Il framework specifica le linee guida per costituire la squadra di persone che si occuperà della gestione degli incidenti o CSIRT (Computer Security Incident Response Team) e le policies, procedure e linee guida da seguire per rispondere efficacemente ad un incidente.
Il team dovrebbe essere diretto da una persona esperta nel campo dell’incident response, idealmente con un’ottima preparazione tecnica e con buone doti manageriali e comunicative. Il responsabile del CSIRT deve infatti stabilire le priorità e le azioni da intraprendere, e coordinare il lavoro di tutti i membri del team.
Inoltre il CSIRT deve spesso necessariamente interagire con gli staff di altre unità o dipartimenti interni od esterni all’organizzazione, come ad esempio il management, l’ufficio legale, gli amministratori di rete e di sistema oppure consulenti e società esterne eventualmente chiamate ad intervenire nella gestione dell’incidente. Quindi il responsabile ed i membri del CSIRT, oltre alle indispensabili abilità tecniche ed organizzative, dovrebbero anche potersi relazionare e comunicare in maniera adeguata tra di loro e con i membri di altri team.
Le attività e procedure che il CSIRT ha il compito di svolgere sono essenzialmente suddivise in tre fasi:
- Risposta iniziale all’incidente
- Investigazione
- Ripristino dei sistemi compromessi
Nella fase di risposta iniziale, il CSIRT determina il tipo di incidente ed il suo potenziale impatto, parlando con chi ha rilevato l’incidente, revisionando i relativi log di rete e/o sistema e documentando tutte le informazioni raccolte in merito.
Nella successiva fase investigativa, si indaga per ricostruire le cause e la dinamica dell’incidente, in particolare per determinare:
- Il vettore d’attacco iniziale
- I sistemi e le reti impattate e in che modo
- Se è stato utilizzato malware
- Gli obiettivi raggiunti dall’attaccante; se si è verificato un data breach, quali dati sono stati violati, i soggetti coinvolti ad altre informazioni rilevanti al riguardo
- Il periodo temporale in cui l’incidente è avvenuto e se è ancora in corso
In questa fase entra in gioco la digital forensics, l’analisi forense dei cosiddetti artifacts (ossia artefatti digitali) della rete e dei sistemi coinvolti nell’incidente, in particolare quelli associati agli IOCs (Indicator of Compromise, gli indicatori di compromissione): connessioni di rete ed indirizzi IP associati, login, signatures e hashes di malware, processi e spazi di memoria RAM associati, file e directories creati e modificati ecc.
Live forensics: cos’è e a cosa serve nell’incident response
Nell’incident response assume quindi un’importanza rilevante la cosiddetta live forensics, cioè l’acquisizione e l’analisi di dati volatili da sistemi in esecuzione. In seconda battuta, per approfondire l’analisi, si può utilizzare anche la post-mortem forensics, l’acquisizione e l’analisi di immagini di hard disk e altri dispositivi di storage. Questi dispositivi possono avere capacità molto grandi e spesso è necessario parecchio tempo per acquisirne le immagini e analizzarle. Dunque l’analisi post-mortem viene eseguita solo se strettamente necessario ai fini dell’investigazione dell’incidente.
D’altra parte, un errore che talvolta viene fatto è quello di saltare troppo velocemente alle conclusioni e alla fase successiva, perdendo così informazioni importanti per una completa comprensione dell’incidente e per un ottimale ripristino successivo.
Ripristino della rete e dei sistemi: un passaggio delicato
Una volta ricostruito il quadro completo dell’incidente, la fase successiva è quella di ripristino della rete e dei sistemi allo stato originale precedente all’incidente. In realtà, la programmazione di questa fase di solito inizia già prima, di pari passo con la fase investigativa. Se l’incidente è ancora in corso, vengono messe in atto tutte le misure per rimuovere i vettori d’attacco (come malware e backdoor) e contenere l’impatto dell’incidente, bloccando per esempio le connessioni di rete utilizzate, gli account compromessi, terminando l’esecuzione dei processi e rimuovendo i file e i meccanismi di persistenza associati al malware.
Quando si è ragionevolmente sicuri di aver bloccato l’attacco e rimosso le cause, si può procedere al ripristino dei sistemi compromessi.
Incident response e GDPR: un connubio indissolubile
Il General Data Protection Regulation (in seguito GDPR) è il regolamento europeo nr. 679 del 2016, entrato in vigore lo scorso 25 maggio.
Incentrato sulla protezione dei dati personali e della privacy dei cittadini europei, ha anche lo scopo di fornire loro un maggior controllo sui propri dati personali utilizzati da aziende e istituzioni, inclusi i diritti alla portabilità dei dati e all’oblio rafforzati rispetto alle precedenti normative in materia.
Il GDPR da un lato aumenta i diritti dei cittadini e dall’altro aumenta gli obblighi ed i requisiti per le organizzazioni che processano i loro dati. Il nuovo regolamento vale non solo per le organizzazioni europee ma anche per tutte quelle che trattano i dati di cittadini europei e rappresenta quindi una normativa di riferimento a livello mondiale.
Tra gli obblighi più importanti introdotti dal GDPR ci sono la definizione della figura di DPO (Data Protection Officer), responsabile della protezione dei dati e della conformità ai requisiti specificati dal regolamento all’interno dell’organizzazione (art. 37 del GDPR) e le comunicazioni da effettuare in caso di violazione dei dati (data breach).
L’articolo 33 del regolamento stabilisce infatti l’obbligo per l’organizzazione di comunicare, all’autorità di controllo competente, l’avvenuta violazione di dati personali entro un termine di 72 ore dalla sua scoperta, qualora si ritenga che ciò rappresenti una minaccia concreta per i diritti e le libertà delle persone a cui i dati si riferiscono. In Italia l’autorità competente è il Garante per la protezione dei dati personali.
Se l’organizzazione effettua la comunicazione oltre il termine di 72 ore, deve fornire valide motivazioni per il ritardo.
La notifica all’autorità di supervisione deve fornire una descrizione della natura del data breach, includendo il numero approssimato e le categorie dei record di dati personali e dei soggetti a cui si riferiscono. Inoltre dovrebbe descrivere le probabili conseguenze della violazione e le misure proposte per rimediare all’incidente.
Il DPO assume un ruolo centrale anche in questo caso, poiché è necessario comunicare il suo nome ed i suoi contatti nel caso l’autorità richiedesse maggiori informazioni sul data breach.
L’articolo 34 stabilisce inoltre l’obbligo di comunicare alle persone interessate l’avvenuto data breach, nel caso che ci sia un rischio elevato per i loro diritti e libertà. L’obbligo decade se:
- l’organizzazione ha messo in atto misure di protezione dei dati oggetto della violazione, in particolare la cifratura
- Ha adottato successivamente misure per scongiurare tale rischio
- La comunicazione comporterebbe sforzi sproporzionati; in tal caso è sufficiente una comunicazione pubblica
La mancata osservanza delle disposizioni contenute in queste articoli ed in generale nel GDPR, potrebbe comportare per l’organizzazione sanzioni amministrative molto pesanti, previste dall’art. 83 (addirittura fino a 20 milioni o fino al 4% del fatturato annuo globale dell’impresa) e sanzioni penali come previsto dalla legislazione vigente nello stato in cui l’organizzazione ha sede legale.
Nonostante il GDPR non prescriva espressamente di creare un CSIRT ed implementare un programma di incident response, è evidente che per garantire la conformità all’articolo 33 del regolamento, un’organizzazione non può proprio farne a meno! Come abbiamo visto nel corso dell’articolo, è infatti necessario per rispondere velocemente ad un data breach, notificarlo entro le 72 ore e mettere in atto tutte le misure per il ripristino dei dati e la riduzione del rischio associato alla violazione.
