AGGIORNAMENTO: Il presente articolo, originariamente pubblicato su 12 febbraio 2021, è stato aggiornato per riflettere lo stato attuale del PICERL, dei quadri normativi in materia di sicurezza informatica e del panorama delle minacce in rapida evoluzione.
Nel panorama in continua evoluzione delle minacce digitali, comprendere e attuare piani di risposta agli incidenti di tipo “ ” (IR ) è fondamentale per qualsiasi organizzazione che intenda rafforzare le proprie difese in materia di sicurezza informatica e rispondere in modo efficace agli incidenti. Una di queste metodologie è PICERL, un quadro di riferimento per la sicurezza informatica che le organizzazioni possono adottare per aumentare la propria capacità di reagire agli incidenti di sicurezza odierni e per rafforzare le proprie difese contro gli incidenti che potrebbero verificarsi in futuro.
La gestione di un incidente di sicurezza informatica, che si tratti di una violazione dei dati, di un attacco ransomware o di qualsiasi altro tipo di attacco informatico, può compromettere in modo significativo le normali operazioni aziendali di un’organizzazione.
In assenza di una risposta efficace agli incidenti, questi ultimi possono minare la fiducia del pubblico, erodere il valore del marchio e comportare una significativa riduzione del fatturato.
In questo blog approfondiamo tutti gli aspetti relativi al modello PICERL, compresa una breve storia delle sue origini; confrontiamo il PICERL con altri modelli comuni di sicurezza informatica e forniamo approfondimenti pratici sulla gestione degli incidenti che possono contribuire a garantire il successo dell’implementazione di un processo come il PICERL o di altri framework di sicurezza “ ” all’interno della vostra organizzazione.
Che cos’è il PICERL nel campo della sicurezza informatica?
PICERL è un processo di risposta agli incidenti articolato in sei fasi: P (), repare ( ), I (), dentify ( ), C (), ontain ( ), E (), radicate ( ), R () ecover ( ) e L ().
Ideato da SANS, un’organizzazione privata fondata nel 1989 con l’obiettivo di fornire attività di ricerca e formazione in materia di sicurezza, il modello PICERL è diventato uno standard di settore per la risposta agli incidenti. Molti ritengono che il PICERL sia un quadro di riferimento efficace poiché offre un approccio strutturato ed esaustivo alla gestione degli incidenti di sicurezza.
L’adozione del modello PICERL garantisce che le organizzazioni siano adeguatamente preparate ad affrontare gli incidenti (Preparazione), siano in grado di identificarli rapidamente (Identificazione), contengano la minaccia per prevenire ulteriori danni (Contenimento), eliminino la minaccia dal sistema (Eliminazione), ripristinino il normale funzionamento dopo l’incidente (Ripristino) e traggano insegnamenti dall’incidente per migliorare le risposte future (Lezioni apprese).
Esaminiamo più approfonditamente le fasi del modello PICERL, evidenziando al contempo alcuni spunti concreti che potrete mettere in pratica fin da oggi per ridurre al minimo l’impatto degli incidenti e rafforzare il livello di sicurezza complessivo della vostra organizzazione.
Fase 1. Prepararsi
La preparazione garantisce che siano coinvolte le persone giuste, provenienti dai team appropriati, che comprendano i propri ruoli e sappiano come comportarsi quando si verifica un incidente.
La fase di preparazione dovrebbe portare all’elaborazione di un piano che i membri del team di risposta agli incidenti possano utilizzare per esercitarsi, proprio come le organizzazioni si esercitano nelle proprie procedure di backup e di ripristino dei dati (DR).
IR I piani devono essere simulati regolarmente per individuare ed eliminare eventuali punti deboli. Le esercitazioni simulate di “ IR ” infondono ai membri del team la sicurezza necessaria per agire con efficacia sotto la pressione di un incidente reale.
IR I gruppi che partecipano alle esercitazioni simulate dovrebbero essere in grado di rispondere a domande quali:
- Chi informa il team addetto alle relazioni pubbliche (PR)?
- Chi provvede a informare l’ufficio legale?
- Chi provvede a informare l’ufficio finanziario?
- In quali casi è necessario informare le forze dell’ordine o le autorità di regolamentazione?
La fase di preparazione serve anche a verificare se si dispone degli strumenti adeguati. In caso contrario, dispone dei fondi necessari per acquistarli e garantire la formazione dei membri del team? È importante che, una volta elaborato un piano di risposta agli incidenti, la dirigenza lo esamini e lo approvi, compreso il bilancio necessario a sostenerlo.
Fase 2. Identificare
Una volta stabilito che si tratta di un incidente, la fase di identificazione consiste nel procedere alla valutazione iniziale rispondendo a domande quali:
- Quando è iniziato e come si è verificato?
- Qual è stato il punto di ingresso?
- Si trattava forse di una vulnerabilità non corretta di ?
- Chi l’ha trovato e come l’abbiamo trovato?
- Ne conosciamo la portata? Si tratta di un fenomeno limitato a una o due persone o a uno o due beni, oppure è diffuso?
- Possiamo continuare a collaborare?
- Le misure che adotteremo avranno ripercussioni su una delle nostre linee di attività?
Molto spesso, le credenziali compromesse costituiscono il punto di accesso. Da quel momento in poi, la situazione degenera e i malintenzionati sfruttano ogni opportunità presente nel Suo ambiente.
Tanium si avvale di analisi approfondite dei vostri endpoint per indagare in modo approfondito sulle minacce
Per migliorare l’efficacia nell’individuazione delle minacce, le organizzazioni hanno iniziato a ricorrere alla gamification nella preparazione e nella verifica delle proprie procedure di risposta. Ad esempio, potete assegnare dei premi alla squadra che individua l’e-mail di phishing o che porta a termine il proprio piano di controllo nel modo più rapido e chiaro possibile. La gamification risulta particolarmente utile per i professionisti della sicurezza alle prime armi.
Fase 3. Contenere
Una volta dichiarato un incidente, il contenimento consiste nell’attuare il proprio piano per impedire che il comportamento indesiderato si diffonda. Esistono due correnti di pensiero diffuse in merito alle metodologie di contenimento, ciascuna delle quali presenta vantaggi e svantaggi:
Una strategia di contenimento a breve termine potrebbe consistere semplicemente nell’emettere un comando di quarantena per impedire ai sistemi, alle risorse o alle applicazioni compromesse di comunicare con qualsiasi entità diversa da uno strumento di sicurezza. Ciò comporta l’adozione di misure rapide quali l’isolamento dei sistemi colpiti, il blocco del traffico dannoso o la disattivazione degli account compromessi, al fine di prevenire ulteriori danni mentre si elabora una soluzione più definitiva.
Disporre di una strategia di contenimento a breve termine rappresenta un passo fondamentale per limitare l’impatto immediato di un incidente di sicurezza. Contribuisce a garantire la continuità delle operazioni aziendali e a ridurre al minimo le interruzioni durante le fasi iniziali della gestione degli incidenti.
[Leggi anche: Che cos’è la gestione dell’ Asset e informatico? [Spiegazione dell’ITAM]
La misura di contenimento a lungo termine è una soluzione implementata a livello aziendale, ma potrebbe essere considerata insufficiente ai fini della completa risoluzione della causa alla radice dell’incidente. Una strategia di contenimento a lungo termine nell’ambito della risposta agli incidenti è concepita per fornire una soluzione sostenibile alle violazioni della sicurezza, garantendo che la minaccia non solo venga temporaneamente controllata, ma che se ne impedisca anche il ripetersi. Ciò può comportare aggiornamenti di sistema, gestione delle patch, segmentazione della rete o l’implementazione di protocolli di sicurezza avanzati.
Ad esempio, esistono vulnerabilità non corrette relative a un incidente? In tal caso, l’accelerazione del programma di aggiornamento del software in questione — sia esso un’applicazione o un sistema operativo — dovrebbe essere inclusa come parte integrante di una strategia di contenimento a lungo termine.
Un altro compito fondamentale da includere nel processo di contenimento consiste nel riesaminare quali utenti dispongano di accesso amministrativo e a quali sistemi, ad esempio:
- Qual è la Sua superficie di attacco rispetto a Active Directory?
- Ha attivato l'autenticazione a più fattori?
È consigliabile disporre di strategie di contenimento a lungo termine integrate nei sistemi di backup e ripristino dei dati, poiché ciò può contribuire ad aumentare la probabilità che i dati siano stati correttamente duplicati e siano facilmente ripristinabili allo stato precedente al verificarsi dell’incidente.
Fase 4. Sradicare
Ora state cercando di eliminare la causa della violazione — alla radice, come si suol dire. Cosa significa? Ciò significa, ad esempio, che nel caso di un malware che avete individuato, potrete rimuovere in modo sicuro ogni sua istanza che riuscite a identificare. Avete rafforzato la sicurezza e applicato le patch ai sistemi, ove necessario. Avete reinstallato i sistemi che non è possibile rendere più sicuri. Ha aggiornato le informazioni sulle minacce per assicurarsi di poter identificare gli elementi correlati alla violazione.
Man mano che il processo di gestione dell’incidente procede, l’ambito dei Suoi interventi potrebbe subire variazioni. A seguito di un attacco ransomware, ad esempio, potreste ritrovarvi con numerosi sistemi che devono essere reinstallati e ripristinati a partire dall’ultimo backup valido conosciuto. E se non individuate tutti gli elementi correlati all’attacco o non avete risolto la vulnerabilità sfruttata per ottenere l’accesso, potreste subire un nuovo attacco.
La chiave per l'eradicazione sta nella meticolosità. La domanda fondamentale è se Lei abbia trovato tutto — qualunque cosa “quello” sia. Spesso un partner o un soggetto terzo dotato di competenze specialistiche può fornire assistenza nelle operazioni di bonifica.
Fase 5. Recuperare
Passare dall’eradicazione alla ripresa è come uscire da un intervento chirurgico. Il danno è ormai fatto, ed è giunto il momento di concentrarsi sulla guarigione.
Dal punto di vista della risposta agli incidenti, è giunto il momento di essere molto onesti con se stessi rispondendo a quanto segue:
- Quando potrete riportare in produzione i sistemi interessati?
- Ha applicato le patch, rafforzato la sicurezza e testato tali sistemi?
- Ha utilizzato il Suo team di simulazione degli attacchi interni per eseguire un attacco simulato contro questi sistemi utilizzando le stesse tecniche degli aggressori?
Il recupero si misura in base alla rapidità con cui è possibile riportare i sistemi e i processi interessati alle funzionalità che avevano prima della violazione. Il ripristino comporta anche la definizione delle modalità con cui modificherà l'ambito del monitoraggio a seguito dell'incidente. Stabilisca per quanto tempo intende monitorare l’attività che ha causato la violazione (ad esempio, 30 giorni, tre mesi o sei mesi) e definisca con precisione ciò che sta cercando.
Anche in questo caso, i test effettuati dal team rosso e gli elementi raccolti durante la fase di contenimento saranno di grande aiuto. Al termine della fase di ripristino, vorrete poter affermare: «Abbiamo risolto le vulnerabilità, ed ecco la prova».
Tra i professionisti della sicurezza si registra una forte tendenza a ridurre il tempo medio di riparazione (MTTR), ovvero il tempo necessario per completare le fasi di identificazione, contenimento ed eliminazione. Man mano che i piani di " IR " si perfezionano e i team acquisiscono maggiore dimestichezza nell’attuazione dei propri piani di " IR", l’MTTR e il " ", ovvero il tempo medio necessario per la " Detect " (MTTD) , dovrebbero diminuire. Monitorare questi indicatori nel tempo può aiutarLa a comprendere se il framework PICERL rappresenti un modello efficace di risposta agli incidenti per la Sua organizzazione.
Fase 6. Insegnamenti tratti
Questa fase dovrebbe iniziare con una riunione di analisi post-evento alla quale partecipino tutti i membri del team di risposta agli incidenti e dei dipartimenti coinvolti, quali sicurezza informatica, conformità, ufficio legale, relazioni pubbliche, ecc. In questa sezione potrete esaminare e documentare quanto avete appreso in merito all’incidente, ad esempio:
- Quale aspetto del Suo piano “ IR ” ha funzionato bene? Cosa non ha funzionato?
- Vi erano delle lacune che richiedevano l’impiego di personale aggiuntivo? Era necessario rivolgersi a una terza parte o a un team interno non presente nel nostro elenco di risorse?
- Alla luce di quanto accaduto, è necessario modificare il nostro modo di operare?
- Stavamo utilizzando in modo efficace gli strumenti a nostra disposizione? Sono stati configurati correttamente?
- Com'è stata la comunicazione tra i team? Si potrebbe migliorare?
- La violazione ha comportato un coinvolgimento dei dipendenti, ad esempio un attacco di ingegneria sociale del tipo “ ” o una gestione impropria dei dati? È possibile risolvere questo problema con la formazione?
- La vulnerabilità sfruttata era specifica di un settore aziendale o diffusa in tutta l’organizzazione?
- Potremmo risolvere tale vulnerabilità ricorrendo a una struttura operativa o a un processo diverso?
Più il piano di gestione degli incidenti ( IR ) è flessibile, più imparerete da un incidente quando si verifica. Pertanto, tutto ciò che imparate dovrebbe confluire nella vostra fase di preparazione, al fine di essere perfezionato e migliorato.
Il PICERL è diverso dall’ NIST?
PICERL e NIST Cybersecurity Framework sono metodologie diffuse per la risposta agli incidenti, ma differiscono per struttura e orientamento.
[Read also: Operationalizing the NIST Cybersecurity Framework 2,0 with Tanium]
PICERL propone un approccio sequenziale alla gestione di un incidente di sicurezza articolato in sei fasi. Al contrario, il modello “ NIST ” rappresenta un insieme di linee guida più ampio e flessibile, strutturato attorno a cinque funzioni fondamentali (Identificazione, Protezione, Rilevamento, Risposta e Ripristino) volte ad aiutare le organizzazioni a gestire i rischi legati alla sicurezza informatica.
PICERL è un manuale dettagliato per la risposta agli incidenti, mentre il quadro di riferimento “ NIST” costituisce una guida più completa per la gestione complessiva dei rischi di sicurezza informatica nell’ambito dell’ . Tuttavia, il quadro di riferimento “ NIST ” è generalmente considerato non prescrittivo e offre solo una tassonomia dei risultati di alto livello in materia di sicurezza informatica, oltre a collegamenti a risorse utili per il raggiungimento di tali risultati.
Cosa comporta tutto ciò per il Suo piano di risposta agli incidenti? Le organizzazioni utilizzano solitamente il PICERL per la risposta agli incidenti nel contesto più ampio del quadro di riferimento “ NIST ”, al fine di gestire efficacemente i rischi legati alla sicurezza informatica.
PICERL rappresenta il miglior modello di risposta agli incidenti?
PICERL offre un approccio dettagliato e strutturato alla gestione degli incidenti, che può rivelarsi vantaggioso per le organizzazioni di maggiori dimensioni o per quelle dotate di ambienti IT più complessi. Tuttavia, il quadro PICERL può anche comportare alcune difficoltà, quali la necessità di una preparazione approfondita, la potenziale complessità nell’identificare e contenere gli incidenti e la necessità di garantire che tutto il personale sia adeguatamente formato.
Tali sfide hanno aperto la strada a modelli emergenti di risposta agli incidenti, concepiti per offrire approcci più flessibili rispetto a quadri di riferimento basati su processi agili come il PICERL, e rappresentano un punto di svolta fondamentale nel modo in cui le organizzazioni devono ripensare le strategie necessarie per garantire una risposta efficace agli incidenti.
Uno di questi modelli è il SOAR, ovvero “ Security Orchestration”, “ Automation” e “ Response”. SOAR si concentra sull’automazione delle risposte e può rivelarsi particolarmente utile per le organizzazioni con risorse limitate nel gestire gli incidenti che richiedono un intervento immediato.
Analogamente, l’approccio “ ” (DAIR), o “ ” (D)“ynamic” ( ) “A”“pproach” ( ) “I”“ncident” ( ) “R”“esponse”, sta acquisendo popolarità poiché pone l’accento sull’adozione di un approccio alla risposta agli incidenti basato su “waypoint”, ovvero tappe fondamentali, che non devono necessariamente verificarsi in ordine sequenziale come nel modello PICERL. Il modello DAIR La guida a concentrarsi sui risultati e sulle attività che contribuiscono al raggiungimento di tali risultati, anziché seguire un approccio per fasi.
Data la natura caotica delle minacce informatiche, la capacità di affrontare rapidamente attacchi sempre più sofisticati implica che i moderni piani di risposta agli incidenti e gli strumenti utilizzati a loro supporto debbano essere in grado di adattarsi e risolvere le minacce in tempi rapidi, pur operando con budget più limitati e in presenza di carenze di personale qualificato nel settore informatico .
Poiché gli incidenti di sicurezza odierni non seguono schemi prestabiliti, perché dovrebbe farlo il vostro piano di risposta agli incidenti?
Come scegliere un quadro di riferimento per la risposta agli incidenti
In questo articolo abbiamo appreso come PICERL si sia tradizionalmente distinto nel panorama dei modelli di sicurezza, offrendo una roadmap dettagliata per la risposta agli incidenti. Tuttavia, ogni modello di risposta agli incidenti presenta i propri punti di forza e le proprie difficoltà.
In definitiva, i piani di risposta agli incidenti adottati dalla vostra organizzazione devono essere adattati alle specifiche problematiche di sicurezza informatica del vostro settore. Affinché i piani di “ IR ” siano efficaci, devono inoltre sfruttare in modo efficiente le risorse, gli strumenti e il personale disponibili, dimostrandosi al contempo applicabili in scenari reali e adattabili per contrastare le nuove minacce man mano che emergono.
Il miglioramento e l’evoluzione costanti del Suo piano di risposta agli incidenti sono fondamentali per mantenere un vantaggio competitivo nel campo della sicurezza informatica. Che si tratti di PICERL, DAIR o di un altro modello appositamente studiato per soddisfare le esigenze della vostra organizzazione, l’elemento fondamentale è elaborare un piano che risponda alle attuali esigenze di sicurezza e metta la vostra organizzazione in grado di affrontare con fiducia le future minacce informatiche.
Tanium offre un supporto senza pari in materia di sicurezza informatica per tutti i framework grazie a , Tanium Incident Responsee , che sostituiscono gli strumenti puntuali e disgiunti con una soluzione unificata che consente alle organizzazioni di identificare, gestire e correggere rapidamente le vulnerabilità.
Tanium potenzia le funzionalità dei Suoi attuali strumenti SIEM e EDR , trasformando le attività di rilevamento delle minacce e di risposta agli incidenti in misure di difesa proattive che garantiscono un impatto minimo sulla produttività degli utenti e rafforzano la Sua resilienza informatica.
Sfruttando la visibilità in tempo reale e i dati completi di endpoint , insieme a , Tanium e Automate — la nostra tecnologia all’avanguardia progettata per automatizzare attività complesse su larga scala che richiedono competenze di programmazione minime o nulle — i team di qualsiasi dimensione e livello di competenza possono diventare più efficaci, produttivi ed efficienti.
Prenoti una demo personalizzata in tempo reale all'indirizzo per vedere Tanium nel Suo ambiente.
