La sostenibilità per TIM

Bilancio di Sostenibilità 2023

Vogliamo contribuire ad accelerare la crescita sostenibile dell’economia e della società portando valore e benessere alle persone, alle aziende, alle istituzioni. Approfondisci

Ultimi Comunicati Stampa

Redazione ufficio stampa

Leggi gli ultimi comunicati stampa e naviga nell'archivio dell'Ufficio Stampa del Gruppo TIM. Leggi i comunicati

Una delle prime cose che si imparano lavorando in un SOC è non dare nulla per scontato. Spesso, infatti, un alert apparentemente insignificante può portare alla identificazione di una compromissione su larga scala. Il successo (o l’insuccesso) nell’identificazione di quanto realmente interessante in un tempo finito deriva da un insieme di fattori, il primo in assoluto è rappresentato dalle persone, dalle loro competenze e dalla sinergia del gruppo. Le persone ovviamente devono essere coadiuvate da strumenti software e hardware di qualità e da processi solidi, snelli e resilienti all’errore umano.

Scarica il PDF

Down

Incident Handling...

341 KB

Da Alert a Incidente

Strumenti a supporto
La selezione degli strumenti da utilizza­re è una fase molto importante, a parti­re da ciò verranno infatti impattate sia la capacità di identif icazione e reazione alle minacce che la velocità di gestione. Nell’ultimo periodo i vendor stanno indi­rizzando il mercato verso:

  • prodotti SaaS e Agent based, che semplificano notevolmente la gestio­ne in quanto il software è ospitato su macchine offerte e manutenute dal vendor stesso. Ciò permette di con­centrarsi su quanto realmente impor­tante, gli alert. Se la funzionalità del prodotto si presta, inoltre, fanno uso di agent installati sulle macchine ve­locizzando e delocalizzando le attivi­tà di detection e risposta;
  • prodotti basati su modelli compor­tamentali, che sono spesso molto eff icaci e, dopo una prima fase di training, permettono di evidenziare anomalie rispetto al comportamento standard di un utente/sistema. Non è comunque consigliabile basare la propria strategia di detection solo su software di questo tipo.

Il singolo prodotto può essere valido per una realtà e meno per una altra, è quindi necessario valutare di caso in caso. Sicu­ramente quanto non può mancare è un EDR (Endpoint Detection&Response), un software agent based che permette di tracciare le attività svolte dagli endpoint (telemetria), meglio se con funzionalità di blocco, invio telemetria in cloud e re­tention dei log di almeno 90 giorni. È fondamentale anche un correlatore di eventi (SIEM o applicazione big data), anche in questo caso è bene seleziona­re un prodotto che garantisca tempi di ricerca adeguati su grandi moli di dati, ciò consente di aumentare la retention senza penalizzare le analisi. Una terza cosa che non può assoluta­mente mancare è un software di trac­ciamento mediante il quale è possibile mantenere evidenza di tutte le azioni ef­fettuate per la singola gestione. Spesso una scelta errata o l’imposizione di sof­tware già in uso porta a enormi problemi e sprechi di tempo. A partire dal set base di prodotti citati è poi necessario inte­grare in base al proprio business e alla conformazione della propria infrastrut­tura IT.

Processi
I processi sono le fondamenta della atti­vità di gestione incidenti, più sono stabili maggiore sarà il beneficio che potranno apportare. Osservando l’attività dall’esterno, proba­bilmente ciò non traspare. Nell’immagina­rio collettivo l’analista di sicurezza è spes­so visto come una figura mitica che risolve i problemi schiacciando pochi tasti. Nella realtà invece, gli analisti devono attener­si a regole ferree e tracciare ogni attività svolta, altresì quanto effettuato potrebbe diventare inutilizzabile. In questo ambito si innestano i processi, che hanno il compito di aiutare gli analisti a seguire la giusta via, ridurre i tempi di gestione e standardizzare le attività. Per garantire efficacia ed efficienza un pro­cesso deve essere:

  • conosciuto, gli analisti devono essere a conoscenza dell’esistenza e devono sapere dove reperire le informazioni all’occorrenza;
  • concreto, deve essere completo, preci­so, chiaro, deve riportare nel dettaglio le azioni minime da fare e non deve su­bire variazioni basate su dettagli a con­torno. Devono inoltre essere previsti in­dicatori di verifica che ne garantiscano l’applicazione;
  • aggiornato, devono essere previsti mo­menti di revisione periodici e l’aggiorna­mento costante e tempestivo del pro­cesso a seguito della comparsa di nuove casistiche.

Approccio reattivo contro Approccio proattivo
Uno degli inneschi standard del processo di gestione incidenti sono gli alert, ovve­ro la notifica di anomalie da parte di uno strumento. In questo specifico caso si sta utilizzando un approccio reattivo. Ne­gli ultimi anni gli attaccanti spesso uti­lizzano tecniche atte alla evasione degli strumenti di sicurezza. Ciò porta ad avere alert in minor numero o di minore entità, aumentando il tempo a disposizione per portare a termine l’attacco. Diventa quin­di fondamentale coadiuvare l’approccio reattivo con attività di tipo proattivo, che in gergo vengono definite “Hunting”. L’attività si basa sulla ricerca manuale di comportamenti malevoli all’interno di log ed eventi, con la finalità di identifi­care pattern non riconosciuti o riconosci­bili dagli strumenti. L’attività può essere effettuata su qualsiasi tipo di fonte, per garantirne il successo si consiglia però di assegnarla a personale con forti com­petenze tecniche e buona conoscenza dell’infrastruttura.

Gestione falsi positivi e alert fatigue
Il maggiore problema di un approccio re­attivo è dato dalla quantità di alert rice­vuti. Il rischio è di non riuscire a valutarne portata e impatti, sia per la mancanza di tempo che per un riflesso inconscio de­gli analisti: “se così tanti alert sono falsi positivi lo sarà anche questo”. Purtroppo, ad oggi, il problema è mol­to diffuso e non sono presenti soluzioni univoche.
È però possibile limitarne gli impatti at­tuando delle azioni come:

  • dedicare una o più persone alla ge­stione degli strumenti, al tuning pro­attivo, alla creazione di alert e all’ap­profondimento dei comportamenti anomali;
  • creare un flusso di revisione degli alert in “anello chiuso”, ovvero ogni falso positivo o problema deve essere segnalato e gestito tempestivamente, interfacciandosi con l’IT ove necessa­rio per capirne le cause scatenanti;
  • affiancare analisti esperti ad anali­sti di minore esperienza in modo da garantire supporto ed evitare tempi di gestione eccessivi.

Incidente

In letteratura la gestione di un incidente di sicurezza viene modellizzata median­te fasi. Nella realtà, in base alla tipolo­gia di incidente, ogni fase potrà essere più o meno corposa, potrà sovrapporsi o unirsi e potrà essere ripetuta più volte durante l’intero processo. Si riporta di seguito un compendio di quanto propo­sto dal SANS Institute.

Preparazione
Tipicamente corrisponde ad un momen­to di “pace” per gli analisti di sicurezza, ovvero un momento in cui non sono pre­senti incidenti. Ogni gruppo lavora con l’obiettivo di preparare quanto neces­sario per le future gestioni, ottimizza­re quanto già in essere ed approfondire nuove tematiche.

Identificazione e scoping
A valle della identificazione di un in­cidente si cerca di capire l’estensione della compromissione, il perimetro e gli asset coinvolti. Per incidenti di grandi dimensioni le attività di scoping si ri­petono ogni qualvolta si identifichi una nuova evidenza. È di fondamentale im­portanza procedere con cura, precisione e metodo in quanto, altresì, si rischia di non identificare l’intero perimetro.

Contenimento
Terminato lo scoping si procede al con­tenimento, ovvero a bloccare qualsiasi possibilità di espansione del perimetro. Ciò potrebbe prevedere l’isolamento di una o più macchine, il blocco delle uten­ze impattate, la creazione di regole fire­wall.
Molte delle misure applicate nella pre­sente fase sono temporanee.

Eradicazione e bonifica
È la fase in cui i sistemi compromessi vengono bonificati, in base alle eviden­ze reperite dalle analisi potrebbe esse­re necessario rifare completamente una macchina o solo rimuovere una serie di artefatti.

Recupero
A valle della bonifica dei sistemi si pro­cede ad applicare eventuali ulteriori mi­sure di hardening o patch specifiche. È infine possibile riportare l’applicazione in “produzione”. È necessario considerare con la massi­ma attenzione ogni alert derivante dai sistemi. Qualora una delle precedenti fasi non fosse stata effettuata nel modo corretto l’attaccante potrebbe guadagnare nuo­vamente accesso al sistema.

Lesson learned
Ultima fase, prevede un monitoraggio dedicato delle attività svolte dalla piat­taforma oggetto di incidente per un pe­riodo arbitrario di tempo. Prevede inoltre la revisione di quanto individuato ed ef­fettuato durante la gestione, la valuta­zione della bontà dei metodi utilizzati e dei risultati ottenuti. Ogni errore commesso in fase di gestio­ne va rivisto, commentato e scongiurato nelle successive gestioni.

Ruoli & Persone

Analista di sicurezza
È il cuore pulsante di un SOC, si occupa dell’analisi degli alert e della gestione degli incidenti. Tipicamente è una per­sona con un profilo fortemente tecnico. In un ambiente medio/grande sono in genere previsti più livelli:

  • L1, effettuano la prima scrematura degli alert, elevando quanto di inte­resse ad incidente. Possono essere interni od esterni all’azienda e pos­sono lavorare anche su turni in modo da garantire un monitoraggio H24;
  • L2, si occupano della gestione di quanto segnalato da L1, fornendo analisi di maggiore dettaglio e veri­ficando con maggiore profondità gli eventi;
  • L3 che possono essere definiti CERT (Computer Emergency Response Team). Il loro compito è quello di ge­stire incidenti critici, complessi e di­stribuiti. In ambienti medio/piccoli è possibile che tale figura sia deman­data a società esterne.

Ogni livello deve avere anche il compito di fornire supporto al livello sottostante garantendone così la crescita professio­nale e rafforzando i rapporti interperso­nali.

Alert engineer e On-boarding specialist
Sono figure che non procedono alla ge­stione diretta degli incidenti. Il ruolo di “Alert engineer” è ricoperto da persone che si occupano di tuning degli strumen­ti, con un profilo fortemente tecnico e possibilmente un passato nel campo della gestione incidenti. Il compito è di fondamentale importanza per garantire il corretto bilanciamento tra capacità di detection e numero di falsi positivi. Il ruolo di “On-boarding specialist” è invece assegnato a persone che si oc­cupano di interagire con l’IT per l’inte­grazione logica di nuove fonti log, stu­diarne la composizione e manutenere le informazioni inerenti quanto già in essere. Non è fondamentale un profilo fortemente tecnico, ma è consigliata una formazione informatica. Il gruppo ha l’obiettivo di procurare in anticipo le informazioni di cui necessi­tano gli analisti, velocizzando le attività di gestione e garantendo una migliore contestualizzazione degli eventi.

Processi, procedure e standard
Il gruppo indicato si occupa della fase di redazione e aggiornamento di processi e procedure. Negli ultimi anni, inoltre, sono nati numerosi standard che indica­no le “best practices” in materia di ge­stione incidenti, come ad esempio ISO 27001 ed ISO 27035. Ottenere una delle certificazioni indicate è motivo di presti­gio e garanzia che le attività siano alli­neate ai più moderni standard di setto­re. I membri del suddetto gruppo hanno il compito di coordinare i restanti gruppi in modo che quanto indicato dalle nor­me sia assimilato e rispettato. Il profilo richiesto non è necessariamente tecnico ma è necessario possedere i concetti di base per poter comprendere le norme e garantirne il beneficio massimo.

Comunicazione e contatti esterni
Il gruppo si interfaccia con entità ester­ne, quali ad esempio l’ufficio legale e, nei casi peggiori con chi si occupa di co­municazione in azienda. Per garantire una comunicazione effica­ce e limitare al minimo le incomprensio­ni è bene avere persone con un profilo ibrido, ovvero che possano capire al me­glio entrambe le parti e fare da tramite. Non è pertanto richiesto un profilo ver­ticale, ma è necessario possedere i con­cetti base delle discipline affrontate.

Conclusioni

In conclusione, negli ultimi anni l’attivi­tà di monitoraggio e gestione incidenti di sicurezza ha subito grandi modifiche. È passata dall’essere marginale e de­strutturata ad essere una componente aziendale fondamentale e fortemente strutturata. Grazie anche alla pubblicità involontaria derivante dalle grandi com­promissioni si sta piano piano creando una maggiore consapevolezza, stanno aumentando gli investimenti e soprat­tutto sta mediamente aumentando l’at­tenzione rivolta al tema. L’aumento di consapevolezza ed investimenti ha por­tato benefici anche nella disponibili­tà di materiale di studio, software sia open source che proprietari, linee gui­da e informazioni. Ciò ha portato alla necessità di creare nuovi ruoli e nuove professionalità che hanno come unico obiettivo agevolare e migliorare capaci­tà e tempistiche di analisi. In sostanza sia dal punto di vista manageriale che dal punto di vista tecnico l’attività è in continuo divenire permettendo alle per­sone che vi lavorano di affrontare ogni giorno nuove stimolanti sfide.

Acronimi

EDR    Endpoint Detection & Response

IOC     Indicatore di compromissione

SaaS   Software as a Service

SIEM   Security information and event management

SOC    Security operation center