Il monitoraggio di tutti gli eventi in una rete aziendale è un'attività mastodontica. Tutti i fenomeni osservabili (da accessi a download, script, aggiornamenti, modifiche alle configurazioni e così via) che si verificano fra endpoint, server, router, switch e altre infrastrutture nella rete possono creare log di eventi che diventano rapidamente una mole inimmaginabile di dati da elaborare.
Inevitabilmente, una serie di eventi produce conseguenze negative per la sicurezza delle aziende. Un dipendente collega un pennino USB compromesso da un worm nel proprio dispositivo di lavoro e, improvvisamente, ecco un evento avverso. I sistemi in uso sono stati configurati per rilevare questi eventi? Una volta verificatosi un evento del genere, quale sarà la risposta?
Non tutti gli eventi avversi richiedono l'intervento dell'intero team di risposta agli incidenti. Le risposte automatizzate svolgono un ruolo cruciale nella gestione di risorse e tempi disponibili nella sicurezza IT. Spesso, i pericoli derivanti da un evento avverso possono essere gestiti in modo ottimale da un singolo amministratore IT e da strumenti di base.
Tuttavia, se l'analista di sicurezza rileva intenzioni e schemi più insidiosi dietro i singoli eventi o si verifica un guasto di sistema inspiegabile, forse l'incidente di sicurezza è abbastanza grave da richiedere l'intervento del proprio CSIRT (Computer Security Incident Response Team). Un piano di risposta agli incidenti ben congegnato consente ai CSIRT di affrontare con sicurezza qualsiasi attacco alla rete.
Le quattro fasi di risposta agli incidenti
Un importante standard per la verifica del proprio piano di risposta agli incidenti è rappresentato da una pubblicazione NIST, dal titolo Computer Security Incident Handling Guide (Guida alla gestione degli incidenti di sicurezza informatici) (SP 800-61). La guida illustra in dettaglio le quattro fasi di risposta agli incidenti: preparazione, rilevamento e analisi, contenimento, eliminazione e ripristino e attività post-incidente.
La gestione degli incidenti secondo questi quattro passaggi garantisce il corretto ritorno alle normali operazioni aziendali. Analizziamo gli elementi di ogni singolo passaggio.
1. Preparazione
Prima del verificarsi di un incidente, è importante predisporre controlli di sicurezza adeguati, in grado di ridurre al minimo i potenziali incidenti. In sostanza, occorre creare e mantenere una rete aziendale tenendo sempre conto della sicurezza.
Ciò comprende mantenere server, sistemi operativi e applicazioni aggiornati, configurati in modo opportuno e protetti dai malware. Inoltre, il perimetro di rete deve essere protetto adeguatamente tramite firewall e VPN. Tutto questo senza dimenticare il principale punto debole: gli ignari dipendenti nelle proprie postazioni. La formazione può essere utile per limitare il numero di incidenti provocati da comportamenti errati dei dipendenti.
Nella configurazione di una rete, è fondamentale verificare la presenza di tutti gli strumenti di monitoraggio e creazione di log necessari per raccogliere e analizzare gli eventi che si verificano nella stessa. La gamma di opzioni disponibili comprende strumenti di monitoraggio e gestione da remoto (Remote Monitoring and Management, RMM), strumenti di gestione di informazioni ed eventi di sicurezza (Security Information and Event Management, SIEM), strumenti di automazione e risposta dell'orchestrazione (Security Orchestration Automation and Response, SOAR), sistemi di rilevamento delle intrusioni (Intrusion Detection Systems, IDS), sistemi di prevenzione delle intrusioni (Intrusion prevention systems, IPS) e soluzioni di rilevamento e risposta per endpoint (Endpoint Detection and Response, EDR).
Le organizzazioni più suscettibili alle minacce, come banche ed enti governativi, sfruttano i feed di intelligence sulle minacce, come ESET Threat Intelligence Service, per fornire indicatori di compromissione che, se rilevati all'interno di un ambiente, potrebbero avviare il processo di risposta agli incidenti.
Individuare gli strumenti di monitoraggio e creazione di log adatti alla propria rete sarà cruciale per le attività di rilevamento e analisi del CSIRT, così come per le opzioni di risoluzione a loro disposizione.
Creazione di un team di risposta agli incidenti
Il passaggio successivo prevede la creazione e la costante formazione di un team di risposta agli incidenti. Per le organizzazioni più piccole basterà probabilmente un team temporaneo composto dagli amministratori IT già presenti. Le organizzazioni più grandi dovranno dotarsi di un CSIRT permanente che, di solito, comporta nuovi amministratori IT dall'azienda solo per interventi su attacchi specifici (ad es., amministratori dei database per l'analisi degli attacchi SQL injection).
Anche l'esternalizzazione delle risposte agli incidenti a un provider di servizi di sicurezza gestiti (Managed Security Service Provider, MSSP) è un'opzione, seppur costosa. Nel prendere in considerazione questa opzione, bisogna tenere conto dei prolungati tempi di risposta. La necessità di un sopralluogo in sede da parte di alcuni membri del team di risposta agli incidenti lascia la propria rete in balia delle minacce per molto più tempo.
Va sottolineato che ogni CSIRT deve avere al suo interno membri che conoscano la struttura della rete e gli eventi "normali" e inusuali al suo interno.
Anche la dirigenza deve svolgere un ruolo attivo, fornendo risorse, fondi e leadership necessari a garantire un operato efficiente del CSIRT. Ciò significa fornire strumenti, dispositivi e kit di emergenza necessari al CSIRT, nonché adottare decisioni aziendali critiche imposte dagli incidenti.
Proviamo a immaginare, ad esempio, che il CSIRT rilevi la compromissione del server di eCommerce aziendale e la necessità di metterlo offline. La dirigenza deve soppesare rapidamente l'impatto sull'azienda della disattivazione o dell'isolamento del server e comunicare la decisione finale al CSIRT.
Anche i team e gli altri membri del personale nell'organizzazione offrono un supporto essenziale al CSIRT. Il personale dell'assistenza IT può fornire supporto nell'arresto e nella sostituzione dei server, nel ripristino dei backup e nella pulizia, in base alle richieste del CSIRT. Anche i team di consulenza legale e pubbliche relazioni sono importanti nella gestione delle comunicazioni relative agli incidenti rivolte a media esterni, partner, clienti e/o forze dell'ordine.
2. Rilevamento e analisi
In questa fase, gli analisti di risposta agli incidenti sfruttano conoscenze, esperienza e pensiero logico per esaminare le molteplici forme di dati presenti in tutti i log e strumenti di monitoraggio per individuare i problemi nella rete e le possibili soluzioni.
Il compito dell'analista è correlare gli eventi in modo da ricreare le relative sequenze che conducono all'incidente. La capacità di identificare la causa alla radice è fondamentale per passare il prima possibile alle misure di contenimento della fase 3.
Tuttavia, come illustrato nello schema del ciclo di vita della risposta agli incidenti di NIST, le fasi 2 e 3 sono circolari, il che significa che i responsabili delle risposte agli incidenti possono tornare alla fase 2 per effettuare ulteriori analisi sulle cause alla radice. In questa struttura circolare, i risultati e l'analisi di alcuni dati nella fase 2 possono indicare la necessità di adottare particolari misure di mitigazione nella fase 3. L'adozione di queste misure può svelare la necessità di un'ulteriore analisi su altri dati, con conseguente adozione di misure di mitigazione e così via.
Le attività della fase 2 vengono drasticamente agevolate dalle soluzioni di rilevamento e risposta per endpoint, come ESET Enterprise Inspector, che segnalano in automatico gli eventi sospetti e salvano l'intera struttura dei processi per un'ulteriore analisi da parte dei responsabili delle risposte agli incidenti.3.
3. Contenimento, eliminazione e ripristino
Nella terza fase, il CSIRT individua un approccio per arrestare la diffusione delle minacce rilevate (ad es. l'arresto di un server, l'isolamento di un endpoint o l'interruzione di determinati servizi). La strategia di contenimento adottata deve tenere in considerazione la possibilità di ulteriori danni, la conservazione delle prove e la durata del contenimento. Di solito, la strategia prevede l'isolamento dei sistemi compromessi, la segmentazione delle parti della rete o l'inserimento dei computer interessati in una sandbox.
Un vantaggio delle sandbox è la possibilità di monitorare ulteriormente le minacce e raccogliere altre prove.
Tuttavia, gli host compromessi potrebbero subire ulteriori danni nelle sandbox.I consulenti legali possono richiedere al CSIRT di raccogliere e documentare quante più prove possibili. In questo caso, il trasferimento di prove da persona a persona deve essere meticolosamente registrato.Una volta contenuti, i malware rilevati devono essere rimossi dai sistemi compromessi. Potrebbe essere necessario disabilitare, chiudere o reimpostare gli account degli utenti. Occorre risolvere le vulnerabilità, ripristinare file e sistemi da backup sicuri, modificare le password, rafforzare le regole del firewall e così via.
A seconda dell'incidente, un ritorno completo alle normali operazioni aziendali può richiedere mesi. Nel breve termine, è necessario predisporre una creazione di log e un monitoraggio superiore o più preciso in modo che gli amministratori IT possano evitare il ripetersi dello stesso incidente. Nel lungo termine, modifiche più radicali alle infrastrutture potrebbero aumentare la sicurezza della rete.
4. Attività post-incidente
Il CSIRT deve documentare e fornire ricostruzione e tempistiche degli eventi. In questo modo, è possibile individuare la causa alla radice dell'incidente e le azioni da intraprendere per evitare incidenti simili o uguali.
Inoltre, in questa fase tutti i team devono analizzare l'efficienza di processi e procedure in atto, identificare le lacune nella comunicazione e gli ostacoli alla collaborazione e cercare opportunità per inserire efficienze all'interno dell'attuale piano di risposta agli incidenti.
Infine, la dirigenza deve stabilire la policy di conservazione delle prove raccolte durante l'incidente; pertanto, i dischi rigidi andranno cancellati solo dopo aver consultato l'ufficio legale.
La maggior parte delle organizzazioni archiviano i record sugli incidenti per due anni al fine di rispettare le normative.Per integrare funzioni avanzate di indagine ai propri kit di risposta agli incidenti, scaricare una prova gratuita di ESET Enterprise Inspector.