Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

MISURE DI SICUREZZA

Security Operation Center: linee guida per la progettazione e la gestione di un SOC

La capacità di monitorare e rilevare un incidente rappresenta una misura di sicurezza fondamentale, ottenibile con una opportuna configurazione e un’appropriata gestione del sistema di rilevamento delle minacce. Ecco le linee guida per progettare e gestire al meglio un Security Operation Center

25 Mar 2019
R
Claudia Rapisarda

Legal Consultant P4I - Partners4Innovation

R
Pasquale Marco Rizzi

Information & Cyber Security Advisor P4I - Partners4Innovation


La specifica ETSI GS ISI 007, pubblicata lo scorso dicembre, presenta le linee guida per la progettazione e la gestione di un Security Operation Center (SOC), con un particolare riferimento al servizio di rilevamento degli incidenti.

La capacità di monitorare e rilevare un incidente rappresenta, infatti, una misura di sicurezza fondamentale, propedeutica alla corretta gestione della catena della sicurezza. Tanto più quando i servizi da proteggere sono essenziali per la società e l’economia in settori di pubblica utilità, come sanità, energia, trasporti, finanza e servizi digitali. Basti pensare a quali potrebbero essere gli effetti dell’indisponibilità per un tempo più o meno lungo di un servizio come la distribuzione dell’acqua potabile o di una rete di telecomunicazioni.

Scenari di questo tipo, di cui è già disponibile uno storico (WannaCry del 2017 in Europa, l’attacco alla rete di distribuzione dell’energia in Ucraina nel 2015, solo per citarne alcuni), sono considerati così potenzialmente rischiosi da spingere i legislatori a legiferare in tema di protezione e sicurezza. È il caso della Direttiva Europea UE 2016/1148, più nota ai più come Direttiva NIS, pubblicata nel 2016 e recepita nell’ordinamento italiano con Decreto Legislativo 18 maggio 2018 n. 65.

Un’opportuna configurazione e un’appropriata gestione del sistema di rilevamento delle minacce rappresentano misure fondamentali per prevenire incidenti di sicurezza, diminuendone la probabilità di accadimento, o limitarne gli impatti, attraverso una pronta ed efficace risposta di contenimento.

Nelle intenzioni, la specifica ETSI GS ISI 007 si pone come base per l’implementazione degli articoli 14 e 16 della Direttiva NIS menzionata sopra, e più specificatamente si propone di indicare le modalità per la rilevazione delle minacce e degli incidenti di sicurezza. In assenza di obblighi legati alla direttiva, la stessa specifica può essere usata come riferimento per la definizione di best practices relativamente alla sicurezza delle Operations nei SOC.

La Direttiva NIS e il suo recepimento in Italia

Come anticipato, in data 6 luglio 2016 è stata emanata la “Direttiva (UE) 2016/1148 del Parlamento Europeo e del Consiglio, recante misure per un livello comune elevato di sicurezza delle reti e dei sistemi informativi nell’Unione”, (di seguito “Direttiva NIS” o semplicemente “Direttiva”).

La Direttiva si pone l’obiettivo di incrementare i livelli di sicurezza e resilienza di reti e sistemi informativi a supporto dell’erogazione di servizi essenziali all’interno dell’Unione Europea.

Destinatari della Direttiva

Come indicato ai sensi dell’art. 1, paragrafo 2, lett. d., la Direttiva NIS “stabilisce obblighi di sicurezza e di notifica per gli operatori di servizi essenziali e per i fornitori di servizi digitali”.

L’Operatore di Servizi Essenziali (OSE), ai sensi dell’art. 4, paragrafo 4, della Direttiva, è un “soggetto pubblico o privato, di un tipo di cui all’allegato II, che soddisfa i criteri di cui all’articolo 5, paragrafo 2”.

La disposizione in esame, in altri termini, sancisce l’obbligo per gli Stati membri di identificare tali soggetti, sulla base dei settori e dei criteri individuati nella Direttiva, entro il 9 novembre 2018.

I settori individuati dalla Direttiva sono: il settore sanitario, dell’energia, dei trasporti, bancario, delle infrastrutture dei mercati finanziari, della fornitura e distribuzione di acqua potabile e delle infrastrutture digitali.

I criteri per l’identificazione degli Operatori di Servizi Essenziali, individuati ai sensi dell’art. 5, paragrafo 2, sono:

  • un soggetto fornisce un servizio che è essenziale per il mantenimento di attività sociali e/o economiche fondamentali;
  • la fornitura di tale servizio dipende dalla rete e dai sistemi informativi;
  • un incidente avrebbe effetti negativi rilevanti sulla fornitura di tale servizio”.

Il “Fornitore di Servizio Digitale” (FSD), ai sensi dell’art. 4, paragrafo 6, della Direttiva NIS è “qualsiasi persona giuridica che fornisce un servizio digitale”. Possono intendersi ricompresi in tale categoria le persone giuridiche che forniscono servizi di e-commerce, cloud computing o motori di ricerca.

Soggetti nei confronti dei quali la Direttiva NIS non trova applicazione

La Direttiva NIS non trova applicazione nei confronti di alcune categorie di OSE e FSD, in quanto soggetti ad obblighi di sicurezza previsti in altre normative specifiche.

Il Considerando 7, infatti, prevede che “(…) È opportuno tuttavia che gli obblighi imposti agli operatori di servizi essenziali e ai fornitori di servizi digitali non si applichino alle imprese che forniscono reti pubbliche di comunicazioni o servizi di comunicazione elettronica accessibili al pubblico, ai sensi della direttiva 2002/21/CE del Parlamento europeo e del Consiglio ( 1 ), perché tali imprese sono soggette a specifici obblighi di sicurezza e integrità previsti da detta direttiva; i suddetti obblighi non dovrebbero inoltre applicarsi ai prestatori di servizi fiduciari ai sensi del regolamento (UE) n. 910/2014 del Parlamento europeo e del Consiglio ( 2 ), che sono soggetti agli obblighi di sicurezza previsti in tale regolamento”.

Gli obblighi previsti per gli FSD non si applicano, inoltre, alle imprese che la normativa europea definisce “piccole” e “micro”, quelle cioè che hanno meno di cinquanta dipendenti e un fatturato o bilancio annuo non superiore a dieci milioni di euro.

Si segnala, infine, che alcuni settori quali, ad esempio, i settori finanziario e nucleare civile, sono esentati da determinati aspetti della Direttiva, nel caso in cui siano regolamentati da una normativa di settore che preveda disposizioni “almeno equivalenti a quelle specificate nella Direttiva”

Coinvolgimento delle autorità competenti

La Direttiva NIS prevede che gli Stati Membri provvedano alla designazione di “Autorità Nazionali Competenti, Punti di Contatto Unici e CSIRT con compiti connessi alla sicurezza della rete e dei sistemi informativi”.

Recepimento della Direttiva NIS

La Direttiva NIS, essendo un atto legislativo che definisce gli obiettivi da raggiungere per gli Stati Membri nell’ambito della sicurezza delle informazioni, non è, di per sé direttamente vincolante, ma necessita di una legge nazionale di recepimento. L’art. 25 della Direttiva NIS, infatti, dispone che “Gli Stati membri adottano e pubblicano, entro il 9 maggio 2018, le disposizioni legislative, regolamentari e amministrative necessarie per conformarsi alla presente direttiva. (…)”.

Il Decreto Legislativo n. 65/2018

La Direttiva NIS, nel nostro ordinamento, è stata recepita dal Decreto Legislativo 18 maggio 2018, n. 65 (di seguito “Decreto attuativo” o semplicemente “Decreto”).

I destinatari del Decreto sono i soggetti identificati nella Direttiva, ovvero gli Operatori di Servizi Essenziali e i Fornitori di Servizi Digitali (FSD).

Per quanto riguarda l’identificazione degli Operatori di Servizi Essenziali, il decreto di recepimento recepisce i settori ed i criteri individuati dalla Direttiva. Il legislatore nazionale, tuttavia, fa una precisazione volta a garantire un’applicazione armonizzata delle Direttiva ed un trattamento uniforme di quei soggetti che operano in più Stati membri, prevedendo che nell’individuazione degli OSE, le Autorità Competenti dovranno tenere conto delle indicazioni del Gruppo di Cooperazione, istituito dall’Articolo 11 della Direttiva (composto da rappresentati degli Stati membri, della Commissione europea e dell’ENISA, European Union for Network and Information Security Agency).

L’elenco nazionale degli OSE è istituito presso il Ministero dello sviluppo economico e viene aggiornato, almeno ogni due anni, a cura delle Autorità competenti NIS.

Gli OSE e gli FSD sono tenuti a:

  • adottare misure tecniche e organizzative adeguate e proporzionate alla gestione dei rischi e a prevenire e minimizzare l’impatto degli incidenti a carico della sicurezza delle reti e dei sistemi informativi, al fine di assicurare la continuità del servizio;
  • notificare, senza ingiustificato ritardo, gli incidenti che hanno un impatto rilevante, rispettivamente sulla continuità e sulla fornitura del servizio, al Computer Security Incident Response Team (CSIRT) italiano, informandone anche l’Autorità Competente NIS di riferimento.

I soggetti giuridici non identificati come OSE e che non rientrano nella categoria degli FSD possono inoltrare al CSIRT notifiche volontarie degli incidenti che abbiano un impatto rilevante sulla continuità dei servizi da loro erogati. La ratio della Direttiva NIS e del relativo Decreto attuativo, infatti, è quella di favorire una maggiore consapevolezza in materia di cyber security e, conseguentemente, un accrescimento dei livelli di sicurezza, anche attraverso un maggiore scambio di informazioni.

Autorità Competenti NIS

Come si è visto, la Direttiva NIS sancisce l’obbligo per gli Stati Membri di designare “Autorità Nazionali Competenti, Punti di Contatto Unici e CSIRT”.

L’art. 7 del Decreto attuativo prevede la designazione, dei Ministeri indicati di seguito, quali “Autorità competenti NIS” per il nostro ordinamento, ciascuno responsabile per i settori rientrati nelle proprie aree di competenza:

  • Ministero dello sviluppo economico;
  • Ministero delle infrastrutture e dei trasporti;
  • Ministero dell’economia e delle finanze;
  • Ministero della salute;
  • Ministero dell’ambiente e della tutela del territorio e del mare e le Regioni e le Province autonome di Trento e di Bolzano.

Tali Autorità, in quanto responsabili dell’attuazione del decreto:

  • vigilano sulla applicazione del medesimo ed esercitano le relative potestà ispettive e sanzionatorie, fatte salve le attribuzioni e le competenze degli organi preposti alla tutela dell’ordine e della sicurezza pubblica;
  • procedono ad identificare gli OSE entro il 9 novembre 2018 (consultando, laddove necessario, le Autorità competenti NIS degli altri Stati Membri), individuando anche le soglie in ragione delle quali un incidente è da considerarsi pregiudizievole per la sicurezza delle reti e dei sistemi informativi;
  • possono predisporre linee guida per la notifica degli incidenti e dettare specifiche misure di sicurezza, sentiti gli OSE.

L’art. 7, al paragrafo 3, designa quale Punto di Contatto Unico in materia di sicurezza delle reti e dei sistemi informativi, il Dipartimento delle Informazioni per la Sicurezza (DIS), in ragione del ruolo svolto nell’architettura cyber nazionale.

Il Punto di Contatto Unico, ai sensi del Decreto attuativo:

“svolge una funzione di collegamento per garantire la cooperazione transfrontaliera delle autorità competenti NIS con le autorità competenti degli altri Stati membri, nonche’ con il gruppo di cooperazione di cui all’articolo 10 e la rete di CSIRT di cui all’articolo 11”;

“collabora nel gruppo di cooperazione in modo effettivo, efficiente e sicuro con i rappresentanti designati

dagli altri Stati”.

L’Art. 8, infine, istituisce, presso la Presidenza del Consiglio dei ministri il CSIRT italiano. Tale organo:

  • definisce le procedure per la prevenzione e la gestione degli incidenti informatici;
  • riceve le notifiche di incidente, informandone il DIS, quale punto di contatto unico e per le attività di prevenzione e preparazione a eventuali situazioni di crisi e di attivazione delle procedure di allertamento affidate al Nucleo per la Sicurezza Cibernetica;
  • fornisce al soggetto che ha effettuato la notifica le informazioni che possono facilitare la gestione efficace dell’evento;
  • informa gli altri Stati membri dell’UE eventualmente coinvolti dall’incidente, tutelando la sicurezza e gli interessi commerciali dell’OSE o del FSD nonché la riservatezza delle informazioni fornite;
  • garantisce la collaborazione nella rete di CSIRT, attraverso l’individuazione di forme di cooperazione operativa, lo scambio di informazioni e la condivisione di best practices.

Tutti i dettagli della specifica ETSI

La sezione principale della specifica è dedicata all’elencazione dei requisiti che un service provider di servizi SOC dovrebbe soddisfare per erogare un servizio sicuro.

Tra questi sono contemplati requisiti di carattere generale inclusi adempimenti legali, evidenze sulla professionalità del servizio erogato, garanzie sulla affidabilità economica-finanziaria, parametri per la qualificazione dei servizi (SLA), processi e procedure che regolamentino i rapporti e le comunicazioni tra le parti.

Sono descritte, nel dettaglio, le attività (o processi) fondamentali associati al servizio di rilevazione degli incidenti.

Il primo processo è relativo alla Gestione degli Incidenti. Gli aspetti fondamentali da prendere in considerazione includono:

  • l’approccio basato sul rischio al definire il punto di partenza per la definizione della strategia di sicurezza che il SOC service provider si appresta a implementare;
  • la corretta valutazione della tassonomia degli incidenti e relativi impatti; a tal proposito la specifica rimanda ad alcune fonti autorevoli come ISO (27035) e la stessa ETSI (GS ISI 001 e GS ISI 002);
  • i criteri (detection rules) attraverso i quali cliente e service provider concordano modalità di rilevazione con cui ciascun incidente può essere potenzialmente identificato, sulla base di analisi di comportamento e di threat intelligence. Ogni regola di detection deve essere corredata dalla vulnerabilità associate, dalle potenziali minacce, dalle operazioni tecniche da eseguire per ciascun caso specifico, insieme al dettaglio della documentazione associata.

È fondamentale segnalare che la specifica fa continuamente riferimento a un processo di comunicazione costante tra cliente e service provider lungo tutto il processo di gestione dell’incidente.

Il secondo processo identificato è la Gestione degli Eventi. Gli aspetti da considerare includono, tra gli altri:

  • l’inventario dettagliato documentato delle sorgenti e delle modalità di raccolta e acquisizione degli eventi, inclusi la definizione delle tipologie di evento, i protocolli e gli applicativi usati per l’acquisizione, la frequenza di acquisizione. La specifica fornisce spunti per la compilazione di questo inventario proponendo una lista minima di apparati da inventariare;
  • le caratteristiche associate all’evento;
  • la definizione di un indicatore di qualità specifico relativo al tempo massimo tra l’interruzione del servizio di acquisizione di eventi e la notifica da parte del service provider al cliente;
  • la necessità di implementare un servizio o una funzionalità di Capacity Management, al fine di poter prevenire il rischio di interruzione del servizio di acquisizione.

L’ultimo processo descritto è la Gestione del reporting. Gli aspetti da considerare includono, tra gli altri, i canali di comunicazione e interazione tra SOC provider e committente; i formati, i contenuti e le tempistiche di comunicazione degli eventi da parte del SOC provider verso il committente.

La specifica organizza tutti i requisiti secondo due livelli di compliance: parziale (basic level) e completa (advanced level), anche se non fornisce indicazioni sulla loro applicabilità. È lasciato alle parti valutare e cosa implementare e con quale priorità.

Sono inoltre definiti i requisiti legati alla sicurezza del servizio erogato, che ripercorrono le tematiche tipiche dei programmi di sicurezza: politiche di sicurezza del sistema informativo, metodologie e livelli di classificazione, territorialità del servizio, programmi di project management, sicurezza fisica, business continuity, programmi di audit e indicatori di livello di servizio.

La specifica prevede la segregazione del sistema di rilevamento degli incidenti in diverse zone di sicurezza, all’interno delle quali trovano posto i diversi sistemi; nello specifico sono previste le seguenti aree (zone):

  • area di acquisizione, destinata ai dispositivi incaricati si raccogliere i log (collector);
  • area di analisi, destinata ai sistemi incaricati di analizzare gli eventi e fare correlazioni;
  • area di reporting, destinata a produrre e gestire i risultati e le analisi degli eventi;
  • area di scambio delle informazioni tra cliente e SOC service provider, destinata a gestire le comunicazioni tra le parti;
  • area di amministrazione dei sistemi, destinata ai sistemi di amministrazione del SOC;
  • area di operation dei sistemi, destinata agli operatori del SOC;
  • area di gestione degli aggiornamenti delle configurazioni, destinata alla gestione di aggiornamenti e messa in produzione dei sistemi nuovi e\o aggiornati.

La specifica include anche:

  • i ruoli (job description) delle risorse dei SOC, con relativi skill e competenze; sono identificate le seguenti figure: analista, amministratore di infrastruttura, architetto, analista di log, esperto di rilevazione incidenti, amministratore dei diritti di accesso;
  • nella seconda parte vengono elencate le attività che il committente dovrebbe eseguire sia nella fase di selezione e scelta del SOC provider, sia durante l’esercizio e l’uso del servizio.

Conclusioni

A conclusione dell’articolo, alcune considerazioni in merito all’utilità e all’usabilità della norma.

Il primo aspetto da segnalare è legato all’accountability: a prescindere dalla completezza e validità tecnica organizzativa dei contenuti, il riferimento a questa norma può rappresentare una evidenza di accountability nella realizzazione o nell’uso di un servizio SOC, nel caso di obblighi di adempimento alla direttiva, ma anche nel caso del solo riferimento a una best practice.

La specifica può anche essere usata come checklist di funzionalità per l’attività di confronto e selezione di un SOC service provider da parte di un committente. Non solo i requisiti, ma anche le modalità di implementazione delle singole funzioni possono essere visti facilmente come criteri di confronto.

Strettamente legate al punto precedente, la lista di funzionalità può essere usata come piano di implementazione di un SOC, nel quale possono essere identificate priorità e associate risorse in termini di costi e capitale umano (una sorta di maturity model).

La descrizione dettagliata delle funzioni può aiutare nella definizione e nel disegno di processi e procedure associate all’erogazione dei servizi.

Ultimo, ma non ultimo, la specifica rimanda ad altre fonti, standard e best practice specifiche da cui attingere per ulteriori contenuti informativi relativi a specifiche tematiche.

@RIPRODUZIONE RISERVATA

Articolo 1 di 5