Le definizioni precedentemente fornite sono state individuate a partire dall’analisi delle seguenti fonti:. AGID, Linee Guida per il Disaster Recovery delle Pubbliche Amministrazioni. AGID, Linee Guida per la razionalizzazione dei CED delle Pubbliche Amministrazioni. AGID, Linee Guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della Pubblica Amministrazione. Codice in materia di protezione dei dati personali (Codice «Privacy»). Codice in materia di protezione dei dati personali (Codice «Privacy»), Allegato «B». Cyber Security Report La Sapienza. ENISA, Un approccio graduale alla creazione di un CSIRT, Documento WP2006/5.1(CERT-D1/D2). FIRST. Garante per la protezione dei dati personali. Glossario CERT-Nazionale. Glossario CERT-PA. Glossario ENISA. Glossario OWASP. ISACA, Cybersecurity Fundamentals Glossary. ISO 22300:2012, Security and resilience – Vocabulary. ISO 31000:2018, Risk management – Guidelines. ISO/IEC 20000-1:2011, Part 1: Service management system requirements. ISO/IEC 27000:2018, Information security management systems – Overview and vocabulary. ISO/IEC 27032:2012, Guidelines for cybersecurity. ISO/IEC 27035-1:2016, Information security incident management – Part 1: Principles of incident management. NIST SP 800-145, The NIST Definition of Cloud Computing. NIST SP 800-150, Guide to cyber threat information sharing. NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems. NISTIR 7298 Revision 2, Glossary of Key Information Security Terms. Quadro strategico nazionale per la sicurezza dello spazio cibernetico. Regolamento generale per la protezione dei dati personali n. 2016/679 (General Data Protection Regulation o GDPR). SANS Glossary of Security Terms. The Institute of Risk Management. The MITRE Corporation. US Department of Homeland Security, NICCS - National Initiative for Cybersecurity Careers and Studies ...

Volume di informazioni prodotte dal CERT (avvisi, bollettini, rapporti). Numero di accessi alle informazioni fornite dal CERT. Numero di richieste raccolte dalla constituency. Quantità di informazioni presentate alla propria constituency su tematiche di cyber security o sulle attività in corso. Perdite monetarie totali derivanti da attacchi cyber subite dalla constituency servita dal CERT (normalizzate rispetto alle dimensioni della constituency). Capacità di offrire servizi in termini di numero e/o qualità rispetto ai propri peer (ciò può essere misurato sia effettuando la valutazione rispetto a standard o best practice di settore, sia effettuando una misurazione comparativa dei risultati dei peer in situazioni analoghe). Disponibilità di finanziamenti sufficienti. Numero totale di membri dello staff. Assegnazione tra i membri dello staff di esperti legali e di comunicazione specializzati. Assegnazione di personale specializzato in discipline tecniche (analisi del codice, analisi forense, ecc.). Livelli di istruzione / formazione dei membri dello staff. Frequenza e qualità della formazione interna su aspetti tecnici specialistici. Numero di esercitazioni cyber condotte dal CERT internamente. Livello di conformità dei processi e delle procedure del CERT a standard e specifiche normative (può essere determinato attraverso l’ottenimento di certificazioni o attività di audit). Capacità di proteggere la confidenzialità dei dati e delle informazioni durante le proprie operazioni (ad esempio durante il processo di gestione di un incidente). Livello di utilizzo delle risorse del CERT rispetto alla sua effettiva capacità (si noti come un elevato utilizzo delle risorse possa portare da un lato a tempi di risposta migliori e/o indicare una migliore allocazione, mentre dall’altro il pieno utilizzo potrebbe essere un indicatore del raggiungimento della capacità massima con possibili ripercussioni nella capacità di erogare altri servizi). Capacità del CERT di stabilire canali di comunicazione che permettono una trasmissione efficiente dei dati e delle informazioni (sia verso l’interno che verso l’esterno). Livello di soddisfazione della constituency (customer satisfaction), determinabile attraverso survey e questionari. Capacità del CERT di effettuare le proprie operazioni senza necessità di supporto esterno (un eccessivo ricorso a capacità esterne potrebbe essere un indicatore di risorse inadeguate o insufficienti a supporto dei servizi) ...

Le facilities sono un sottoinsieme del patrimonio fisico dell’organizzazione che viene utilizzato per eseguire i servizi. Sono centri di attività in cui si intersecano molti servizi dell’organizzazione, come edifici per uffici e locali tecnici. Possono essere di proprietà dell’organizzazione ma spesso vengono noleggiate da un fornitore esterno. Le persone, le informazioni e le risorse tecnologiche «vivono» all’interno delle facilities: forniscono lo spazio fisico per le azioni delle persone (le persone lavorano negli uffici), l’uso e la memorizzazione delle informazioni (file, server) e l’operazione di componenti tecnologici (come nei data center e nelle server farm). Proprio per tale ragione è cruciale l’adozione di requisiti di sicurezza fisica ed ambientale idonei a consentire la protezione delle informazioni (si veda il Cap. 12) ...

Ogni entità del campus è indipendente dal CERT e da tutti le altre entità che compongono la constituency. Questo modello prevede che il CERT, pur essendo distaccato, impieghi, oltre al personale assegnato in modo permanente, le risorse che le altre organizzazioni appartenenti alla constituency sono in grado di metterle a disposizione (ad esempio perché dotati di un proprio SOC) tra i membri della constituency. Il CERT erogherà i suoi servizi sia verso gli enti che forniscono le risorse, sia verso tutti gli altri membri della constituency. Fig. 6.4 Modello campus. Il modello campus è quello più adottato nei CERT di settore, tra i quali rientrano anche i CERT accademici/di ricerca e quelli militari, in quanto consente di bilanciare ottimamente le necessità di coordinamento centrale con quelle di autorità locale, come nel caso di utenti singoli o consorziati riconducibili ad uno stesso ambito professionale o caratterizzati da interessi comuni (ad esempio salute, trasporti, ecc.). Di contro, si possono considerare il modello indipendente ed incorporato come assetti più indicati per un CERT territoriale, anche in presenza di constituency caratterizzate da distribuzioni geografiche particolarmente estese, che può operare in maniera efficace sotto la supervisione dell’ente che lo ha istituito ...

Nel Glossario è riportato un elenco esaustivo di nozioni e termini utili per una corretta comprensione dei contenuti presentati all’interno di questo documento. Acronimo. Descrizione. AGID. Agenzia per l’Italia Digitale. CERT. Computer Emergency Response Team. CERT/CC. CERT/CC – CERT Coordination Center CMU-SEI. CMU-SEI. Carnegie Mellon University - Software Engineering Institute. CNAIPIC. Centro Nazionale Anticrimine Informatico per la Protezione delle Infrastrutture Critiche. CSIRT. Computer Security Incident Response Team. ENISA. Agenzia Europea per la sicurezza delle reti e dell’informazione. FIRST. Forum of Incident Response and Security Teams. IOC. Indicators of Compromise. IRPA. Incident Response Pubblica Amministrazione. ISAC. Information Sharing and Analysis Center. NATO. North Atlantic Treaty Organization. ONU. Organizzazione delle Nazioni Unite. OSCE. Organizzazione per la Sicurezza e la Cooperazione in Europa. PP.AA. Pubbliche Amministrazioni. PAC. Pubbliche Amministrazioni Centrali. PAL. Pubbliche Amministrazioni Locali. SOC. Security Operation Center. TI. Trusted Introducer ...

Un CERT, nell’organizzazione dei propri processi ed attività, può prendere come riferimento alcuni framework e linee guida rilasciate a livello nazionale ed internazionale nell’ambito della cyber security, e standard tecnici e di processo necessari per poter interagire in modo efficace ed efficiente con la propria constituency e con la comunità di riferimento. 4.4.1. Framework e Linee Guida. ISO/IEC 27001. Lo standard ISO/IEC 27001 è una norma internazionale che definisce i requisiti per impostare e gestire un sistema di gestione della sicurezza delle informazioni (SGSI o ISMS, dall’inglese Information Security Management System), ed include aspetti relativi alla sicurezza logica, fisica ed organizzativa. L’obiettivo principale è quello di stabilire un sistema per la gestione del rischio e la protezione delle informazioni e degli asset informatici da minacce di diverso tipo, al fine di assicurarne l’integrità, la riservatezza e la disponibilità, e fornire i requisiti per adottare un adeguato sistema di gestione della sicurezza delle informazioni. La norma è applicabile a tutte le imprese private o pubbliche, in quanto prescinde da uno specifico settore o dall’organizzazione dell’azienda. I requisiti proposti dallo standard sono di due tipi:. requisiti di sistema, quali quello di stabilire le politiche e gli obiettivi, condurre il processo di risk assessment e pianificare il trattamento del rischio, gestire la documentazione e le registrazioni, ecc., e presentati dai capitoli 4 e 8 della norma;. controlli di sicurezza, di tipo tecnico, amministrativo e gestionale (35 obiettivi di controllo e 114 controlli in totale) riportati all’interno dell’Annex A, ed approfonditi separatamente dalla linea guida ISO/IEC 27002, che presenta delle best practices per la loro implementazione. Con riferimento ai controlli, alcune sezioni possono essere di specifico interesse per un CERT, quali a titolo esemplificativo – ma non esaustivo:. controlli legati al processo di gestione degli incidenti, volti a favorire l’adozione di un approccio coerente ed efficace alla gestione degli stessi e per la loro comunicazione verso tutte le parti interessate;. controlli legati al personale, volti ad assicurare che i dipendenti e tutte le terze parti gli appaltatori comprendano le proprie responsabilità e siano idonei rispetto ai ruoli per i quali sono considerati (si pensi alle abilitazioni di sicurezza richieste per poter trattare informazioni classificate, quali il Nulla Osta di Sicurezza, NOS). ISO/IEC 27032. La Linea Guida ISO/IEC 27032 «Information technology – Security techniques – Guidelines for cybersecurity» fornisce indicazioni per migliorare il proprio stato di cyber security (o “cyberspace security” [44]). Delinea gli aspetti peculiari di tale attività e propone buone pratiche di sicurezza per operare nel cyberspace. In particolare, all’interno della linea guida sono forniti i seguenti contributi:. panoramica generale sulla Cybersecurity;. spiegazione della relazione tra Cybersecurity e gli altri domini di sicurezza, quali la sicurezza delle informazioni, la sicurezza delle applicazioni, la sicurezza della rete e la sicurezza dei servizi esposti su Internet;. definizione delle parti interessate e una descrizione dei loro ruoli per la Cybersecurity;. guida per affrontare problemi comuni di Cybersecurity;. quadro di riferimento per consentire alle parti interessate di collaborare alla risoluzione dei problemi di sicurezza informatica. [44]. La cyberspace security è definita come la protezione della riservatezza, dell’integrità e della disponibilità dell’informazione nel cyberspace, ovvero il complesso ambiente risultante dall’interazione tra persone, software e servizi su internet attraverso i dispositivi tecnologici e le reti ad essa collegati. ISO 31000. La norma ISO 31000 «Risk management - Principles and guidelines”, è una guida che fornisce principi e linee guida generali per la gestione del rischio. È stata pubblicata per la prima volta il 3 novembre 2009, ma è stata rivista e riaggiornata in una nuova versione a febbraio 2018. Può essere utilizzata da qualsiasi organizzazione e non è specifica per industria o settore. La ISO 31000 può essere applicata nel corso dell’intero ciclo di vita di un’organizzazione, ed essere adottata per molte attività come la definizione di strategie e decisioni, operazioni, processi, funzioni, progetti, prodotti, servizi e beni. Può inoltre essere applicata a qualsiasi tipo di rischio, sia per conseguenze di tipo positivo che negativo. Il modello gestionale di gestione del rischio proposto dalla norma si basa sulla relazione tra:. Principi su cui si fonda il modello di risk management per creare valore nell’organizzazione e garantire l’adeguato livello di protezione, tra cui la governance, gli aspetti umani e culturali, la tempestività, il coinvolgimento di tutte le parti interessate, ecc. Struttura, ovvero le componenti del framework di risk management, rappresentate dall’integrazione, dalla progettazione, dall’implementazione, dalla valutazione e dal miglioramento continuo, che sono coordinate dal top management, che deve garantire leadership ed impegno. Processo di gestione dei rischi, che deve essere una disciplina di uso quotidiano, comprensibile sia alla Direzione sia al personale operativo su tutti i livelli. È articolato nelle fasi di identificazione, analisi, valutazione e trattamento dei rischi [45]. [45]. A tal proposito è opportuno citare la linea guida ISO 31010 – Risk Management-Risk Assessment Techniques, che fornisce diverse tecniche per la valutazione dei rischi in diversi ambiti. ISO 15408. Lo standard internazionale ISO 15408 [46] recepisce i cosiddetti“Common Criteria”, ovvero l’insieme dei criteri e dei principi generali per la valutare l’affidabilità di un prodotto informatico dal punto di vista delle misure di sicurezza implementate. In particolare, l’adozione dei Common Criteria garantisce che il processo di specificazione, implementazione e valutazione di un prodotto informatico dal punto di vista della sicurezza sia stato condotto in modo rigoroso, standard e ripetibile ad un livello commisurato all’ambiente di destinazione per l’uso. [46]. Per ulteriori informazioni consultare: www.commoncriteriaportal.org/cc. Lo standard prevede sette livelli di garanzia crescenti, da EAL1 (Evaluation Assurance Level) a EAL7, dipendenti dall’estensione e formalità della documentazione usata in fase di analisi e sviluppo, nonché dalle modalità seguite nello sviluppo. Per avere prodotti rispetto ai quali avere un buon livello di fiducia, questi dovrebbero essere valutati almeno a livello EAL4 (quello a partire dal quale i valutatori iniziano ad analizzare il codice). Livelli superiori sono ovviamente migliori ma, data la complessità, i costi crescono notevolmente e sono giustificati solo se opportune analisi del rischio lo suggeriscono. Sono previsti ulteriori 3 livelli, utilizzati esclusivamente per prodotti che integrano prodotti diversi denominati CAP (Composed Assurance Level) dal livello A al C, validi solo ed esclusivamente per prodotti già certificati e non sottoposti a ulteriori sviluppi per la loro integrazione. I prodotti e sistemi da certificare sono detti Oggetto di Valutazione oppure Target of Evaluation (TOE). I requisiti di sicurezza per una tipologia di prodotto o sistema sono descritti nel documento denominato Protection Profile (PP) o Profilo di Protezione (PP). In Italia l’OCSI [47] (Organismo di Certificazione della Sicurezza Informatica) gestisce lo Schema Nazionale per la valutazione e certificazione della sicurezza di sistemi e prodotti nel settore della tecnologia dell’informazione, istituito con il DPCM del 30 ottobre 2003 (G.U. n.98 del 27 aprile 2004). L’ISCOM (Istituto Superiore delle Comunicazioni e delle Tecnologie dell’Informazione) del Ministero dello Sviluppo Economico è, per decreto, l’Organismo di Certificazione della Sicurezza Informatica nel settore della tecnologia dell’informazione. [47]. Fonte: http://www.ocsi.isticom.it/. Oltre ad aver predisposto le Linee Guida per la conduzione dei processi di valutazione e certificazione, l’OCSI gestisce l’accreditamento, la sospensione e la revoca dell’accreditamento dei Laboratori per la Valutazione della Sicurezza (LVS) e degli Assistenti di Sicurezza. ISO/IEC 27035 [48]. [48]. Fonte: https://www.iso.org/standard/44379.html. Lo standard ISO/IEC 27035:2011 dal titolo “Information security incident management” fornisce delle linee guida per l’implementazione di procedure e controlli al fine di creare un approccio strutturato per la gestione degli incidenti informatici. Tale standard ha come obiettivo la minimizzazione degli impatti negativi che un incidente informatico può avere sul business aziendale, attraverso il contenimento dell’incidente, la rimozione della causa scatenante, l’analisi delle conseguenze e il successivo controllo di non occorrenza. Per poter garantire il raggiungimento degli obiettivi appena descritti il processo di gestione degli incidenti viene suddiviso in cinque fasi, ciascuna contenente determinate attività, incluse in un ciclo che dall’ultima ritorna poi alla prima:. Pianificazione e preparazione:. politiche di gestione degli incidenti di sicurezza;. politiche di gestione della sicurezza e dei rischi;. sistema di gestione degli incidenti di sicurezza;. formazione del CERT/CSIRT/IRT;. supporto (tecnico e di altro tipo);. formazione sulla consapevolezza nella gestione degli incidenti di sicurezza;. test del sistema di gestione degli incidenti di sicurezza. Scoperta e notifica: scoperta di un incidente e notifica alle appropriate funzioni aziendali. Valutazione e decisione: valutazione dell’evento e decisione di classificarlo come evento di sicurezza o meno. Risposta:. risposte agli incidenti di sicurezza informatica, ivi incluse operazioni di analisi forense;. riprendersi da un incidente di sicurezza informatica;. eventuali attività di investigazione, ove necessario. Lessons learnt:. analisi forensi più approfondite (se necessario);. identificazione della lezione appresa;. identificazione e attuazione dei miglioramenti al sistema di sicurezza;. identificazione e attuazione dei miglioramenti alle valutazioni dei rischi di sicurezza;. identificazione e attuazione dei miglioramenti al sistema di gestione degli incidenti di sicurezza. ISO 27005 [49]. [49]. Fonte: https://www.iso.org/standard/75281.html. Lo standard ISO 27005 dal titolo “Information technology – Security techniques – Information security risk management”, aggiornato nel 2018, fornisce le linee guida per la gestione dei rischi relativi alla sicurezza delle informazioni e supporta i concetti generali specificati nello standard ISO/IEC 27001, con il quale si integra, con l’obiettivo di aiutare le organizzazioni nella tutela della sicurezza delle informazioni mediante un corretto approccio alla gestione del rischio. Seguendo lo schema, il contenuto della ISO/IEC 27005 è suddiviso in 6 capitoli (quelli dal 7 al 12):. stabilire il contesto;. valutare il rischio (a sua volta suddiviso nelle tre sezioni relative all’identificazione, analisi e ponderazione del rischio);. trattare il rischio;. accettare il rischio;. comunicare il rischio e consultare le parti interessate;. monitorare e riesaminare il rischio. Promuove un approccio alla valutazione del rischio basato sull’identificazione di asset, minacce e vulnerabilità, peculiare per la l’analisi dei rischi di sicurezza delle informazioni. Propone in appendice utili strumenti a supporto delle attività operative che approfondiscono ulteriormente alcuni aspetti della gestione del rischio (es. lista di minacce; tecniche di analisi dei rischi; ecc.). ISO 29147 [50]. [50]. Fonte: https://www.iso.org/standard/72311.html. Lo standard ISO/IEC 29147:2018 dal titolo “Information Technology – Security Techniques – Vulnerability Disclosure” delinea le modalità con cui fornitori di hardware e software e qualsiasi altra organizzazione che fornisce strumenti e/o applicazioni possono integrare il processo di gestione della divulgazione delle vulnerabilità nei loro normali processi aziendali. In particolare fornisce delle linee guida su:. su come ricevere informazioni relative a potenziale vulnerabilità nei prodotti o servizi online;. su come divulgare le informazioni sulla risoluzione delle stesse;. gli elementi informativi che dovrebbero essere prodotti attraverso l’implementazione del processo di divulgazione delle vulnerabilità e esempi di contenuto che dovrebbero essere inclusi negli elementi informativi. ISO 27037 [51]. [51]. Fonte: https://www.iso.org/standard/44381.html. Lo standard ISO 27037:2012 dal titolo “Guidelines for identification, collection, acquisition, and preservation of digital evidence”, fornisce delle linee guida relative alla gestione delle potenziali prove digitali, concentrandosi in particolar modo sulle fasi di identificazione (ispezione), raccolta (sequestro), acquisizione (sequestro virtuale) e preservazione (conservazione e sigillo). Per ogni fase vengono indicate le best practices riconosciute per permettere che la potenziale prova possa essere utilizzata efficacemente in sede processuale, tenendo conto delle possibili (e più comuni) situazioni che l’investigatore può trovarsi a dover affrontare, come ad esempio:. attività di base e aggiuntive relative a raccolta di sistemi digitali che vengono trovati accesi;. attività di base e aggiuntive relative ad acquisizione di sistemi digitali che vengono trovati accesi;. attività di base e aggiuntive relative a raccolta di sistemi digitali che vengono trovati spenti;. attività di base e aggiuntive relative ad acquisizione di sistemi digitali che vengono trovati spenti;. attività di raccolta o acquisizione di sistemi collegati in rete. Vengono inoltre definite tre figure chiave, che si occupano e sono responsabili degli aspetti di gestione della prova digitale menzionati sopra:. il DEFR o Digital Evidence First Responder è un soggetto autorizzato, formato e qualificato ad agire per primo sulla scena di un incidente per eseguire attività di raccolta ed acquisizione delle prove avendone inoltre la responsabilità di corretta gestione; è l’operatore che si approccia per primo ai sistemi (supporti di memorizzazione e dati) di potenziale interesse. il DES o Digital Evidence Specialist è un soggetto che ha le capacità di eseguire le stesse attività eseguite da un DEFR ed in più possiede conoscenze specialistiche ed è in grado di gestire una moltitudine di problematiche tecniche, ad esempio è in grado di portare a termine attività quali acquisizione di rete, di memoria RAM ed ha ampia conoscenza di sistemi operativi e/o Mainframe;. l’Incident Response Specialist, che normalmente è una figura professionale interna all’azienda che si occupa del primo intervento post incidente informatico. Questa figura coincide spesso, in contesto aziendale, con l’amministratore dei sistemi informativi. La sua principale attività consiste nel mantenere operativi i sistemi informativi, per cui spesso, dopo il verificarsi di un incidente informatico, la sua attività va contro quella di un DEFR o DES poiché il ripristino dell’operatività dei sistemi può portare facilmente alla perdita di potenziali prove. Sia DEFR che DES hanno il compito di portare a termine il lavoro nel miglior modo possibile, utilizzando al meglio le linee guida fornite dallo standard, che vanno comunque integrate con le normative in vigore all’interno dello Stato in cui essi operano, dato che gli standard di questa serie hanno carattere generale e quindi non sono legati ad uno specifico ordinamento giuridico.Le modalità con cui procedere alle successive attività di analisi e interpretazione delle prove digitali e di comunicazione dei risultati sono definite nello standard ISO 27042:2015 “Information technology – Security techniques – Guidelines for the analysis and interpretation of digital evidence” [52]. [52]. Fonte: https://www.iso.org/standard/44406.html. 4.4.2. Standard tecnici. Nonostante i numerosi protocolli definiti negli ultimi anni per la condivisione delle informazioni utilizzate nell’analisi e nella risoluzione di un incidente, pochi sono attualmente divenuti gli standard de facto. Si raccomanda dunque ai CERT la conoscenza di tali protocolli per la corretta interpretazione e gestione delle informazioni ricevute. In questo paragrafo saranno descritti i principali standard utilizzati per la classificazione e condivisione di informazioni da e verso il CERT. Protocollo TLP. Le informazioni da condividere devono essere classificate in base al loro livello di sensibilità e, qualunque sia il metodo, dovrebbe poter essere utilizzato da entrambi i settori pubblico e privato senza la necessità di rimandi ai loro schemi di classificazione delle informazioni. Per essere univoci ed avere una base comune nel processo di condivisione delle informazioni spesso si utilizza un codice-colore abbinato alle informazioni di incidente, chiamato Traffic Light Protocol (TLP) [53], che prevede un insieme di requisiti per far sì che ogni informazione condivisa sia distribuita solo ai destinatari corretti. [53]. Fonte: https://www.first.org/tlp/. Il protocollo TLP viene utilizzato in molti processi di condivisione delle informazioni. L’informazione viene classificata secondo quattro livelli (tag) - White, Green, Amber o Red (in ordine di crescente gravità) - che indicano le prescrizioni di confidenzialità e condivisibilità dell’informazione relativa all’incidente che i riceventi dovranno adottare nel gestirla:. WHITE – Illimitato: deve essere adottato nel caso di comunicazioni che contengono informazioni che possono essere diffuse pubblicamente, in quanto irrilevanti ai fini dei rischi di sicurezza per l’organizzazione. Tali informazioni possono dunque essere liberamente condivise dai destinatari con soggetti terzi, nel rispetto delle norme a tutela dei diritti di proprietà intellettuali e con gli altri termini di legge. GREEN - A livello di comunità: le informazioni in questa categoria possono essere ampiamente diffuse all’interno di una particolare comunità o organizzazione, in quanto utili ai fini della sensibilizzazione. Tuttavia, tali informazioni non dovrebbero essere pubblicate o rese di dominio pubblico su Internet, né rilasciate al di fuori della comunità. AMBER - Distribuzione limitata: i destinatari possono condividere questo tipo di informazioni con altri all’interno della propria organizzazione per finalità operative. Tali comunicazioni contengono infatti tipicamente informazioni che potrebbero essere sfruttate per causare impatti in termini di privacy e reputazione o deterioramento della normale operatività, se condivise all’esterno dell’organizzazione. Ci si può aspettare che il mittente specifichi i limiti previsti di tale condivisione, nel rispetto del principio del “need-to-know”. RED - Personale solo per i destinatari specificati: la condivisione all’esterno del gruppo dei destinatari non è legittimata e l’utilizzo di tali informazioni al di fuori degli stessi può determinare seri impatti in termini legali, reputazionali o di interruzione della normale operatività dell’organizzazione. Questo tipo di informazioni può essere utilizzato dai soli Destinatari, anche nelle comunicazioni tra loro, e non possono essere divulgate neppure all’interno della propria organizzazione, adottando la massima riservatezza. Nel contesto di una riunione faccia a faccia, ad esempio, la distribuzione delle informazioni RED è limitata ai soli presenti alla riunione. Questo metodo di classificazione delle informazioni è ampiamente utilizzato poiché è molto semplice da comprendere e implementare, e può essere facilmente adottato anche in altri settori o al di fuori del territorio nazionale. Nella maggior parte dei casi, il mittente delle informazioni da condividere determinerà il suo colore di classificazione, ma talvolta i CERT possono decidere di elevarlo se ritengono che il livello definito sia troppo basso. L’applicazione di tale protocollo si rende auspicabile anche per gestire il problema dell’anonimizzazione della sorgente di informazione, che si presenta, inevitabilmente, quando un’organizzazione partecipante non desidera essere identificata come vittima di un attacco (magari andato a buon fine) o come coinvolta in altro evento di sicurezza. Il CERT si impegna a garantire che questa richiesta di anonimato sia rispettata, assicurando che, anche omettendo l’identità dell’originatore, le informazioni trasmesse non contengano indizi o metadati aggiuntivi che potrebbero in alcun modo rivelare, portare a dedurre, suggerire o identificare l’originatore. STIX. STIX (Structured Threat Information eXpression) [54] è un linguaggio di programmazione XML standardizzato per la specifica, l’acquisizione, la caratterizzazione e la comunicazione di informazioni relative a minacce cyber in un linguaggio comune che può essere facilmente compreso sia dagli individui che dalle tecnologie di sicurezza. STIX, originariamente sponsorizzato dall’ufficio di Cybersecurity and Communications del Dipartimento di Homeland Security degli Stati Uniti (DHS), è stato trasferito ad OASIS, un consorzio senza scopo di lucro che mira a promuovere lo sviluppo, la convergenza e l’adozione di standard aperti per la rete. Rappresenta dunque uno sforzo collaborativo teso a sviluppare un linguaggio standardizzato e strutturato, che identifichi le informazioni concernenti le minacce cibernetiche. I membri della community STIX contribuiscono allo sviluppo e alla gestione del linguaggio, ma in generale tutti i membri della comunità informatica sono invitati a dare il loro apporto. [54]. Per ulteriori informazioni consultare: https://stixproject.github.io/. Il linguaggio STIX trasmette l’intera gamma di potenziali informazioni sulle minacce informatiche e si pone per essere pienamente espressivo, flessibile, estensibile, automatizzabile e leggibile. L’obiettivo di STIX è quello di specificare, caratterizzare e acquisire informazioni. STIX affronta una gamma completa di casi d’uso delle minacce, tra cui analisi, acquisizione e specifica degli indicatori, gestione delle attività di risposta e condivisione delle informazioni, per migliorare la coerenza, l’efficienza, l’interoperabilità e la consapevolezza generale della situazione. STIX è un modello di dati grafico basato su nodi ed edge. I nodi sono STIX Data Objects (SDO), mentre gli edge sono STIX Relationship Objects (SRO). Gli SDO includono informazioni come Metodi di attacco, Identità, Dati osservati, Threat actor, Vulnerabilità, ecc. Gli SRO sono pensati per connettere gli SDO in modo che, nel tempo, gli utenti saranno in grado di sviluppare una conoscenza approfondita degli attori delle minacce e delle loro tecniche. Il formato STIX 2.0 definisce 12 STIX domain Objects (SDOs). Il modello STIX è costituito almeno dalle seguenti entità:. Indicatori e Osservabili: un attacco specifico di solito coinvolge schemi che ne consentono la caratterizzazione. Questi modelli possono essere artefatti e / o comportamenti di interesse all’interno di un contesto di sicurezza informatica e sono specificati in STIX da Observables che agiscono come indicatori per un attacco;. Incidenti: si tratta di attacchi riusciti che dettagliano le informazioni sull’origine e sul target. I relativi Indicatori e Osservabili della minaccia forniscono informazioni su come tale attacco potrebbe essere rilevato;. Obiettivi di exploit: vulnerabilità o punti deboli che consentono all’attaccante di attaccare con successo un target. Tattiche, Tecniche, procedure (TTP): termine preso in prestito dall’ambito militare per rappresentare il comportamento o il modus operandi dell’avversario quando esegue l’attacco. Un TTP può contenere informazioni su quali siano le vittime dell’attore di minaccia, quali modelli di attacco e malware vengono utilizzati, e quali risorse (infrastrutture, strumenti, persone) vengono sfruttate;. Attori di minaccia: una caratterizzazione dell’identità, della sospetta motivazione e dei presunti effetti intenzionali degli attaccanti;. Campagna: rappresenta un insieme di attività e comportamenti che gli attori della minaccia eseguono per ottenere l’effetto desiderato in un periodo di tempo. CourseOfActions (COA): sono misure specifiche da adottare in risposta ad un attacco o come misura preventiva prima di un attacco. TAXII. Nato per soddisfare le esigenze di condivisione delle informazioni tra diversi settori di infrastrutture critiche, TAXII (Trusted Automated eXchange of Intelligence Information) [55] è un’iniziativa della comunità internazionale per standardizzare lo scambio affidabile e automatizzato di informazioni sulle minacce informatiche. Come per STIX, DHS ne ha affidato lo sviluppo e la manutenzione a consorzio OASIS. Si tratta di un protocollo applicativo basato su HTTPS. Definisce un insieme di servizi e scambi di messaggi che, una volta implementati, consentono la condivisione di informazioni sulle minacce informatiche utilizzabili attraverso i confini dell’organizzazione e dei prodotti / servizi per l’individuazione, la prevenzione e la mitigazione delle minacce informatiche. [55]. Per ulteriori informazioni consultare: https://taxiiproject.github.io/. Considerata la scelta del linguaggio STIX per la definizione delle minacce cyber ed il protocollo TAXII come meccanismo di trasporto per la condivisione delle stesse tra enti/organizzazioni differenti, l’obiettivo è quello di creare una rete efficace ed efficiente (community) in cui il semplice indicatore scambiato (IP, URL, SHA, etc.) diventi, dopo la sua qualificazione, un’informazione. TAXII definisce due servizi primari per supportare una varietà di modelli di condivisione comuni:. Collection: un’interfaccia per un repository logico di dati di cyber threat intelligence fornito da un server TAXII, che consente al mittente di ospitare dati che possono essere richiesti dal destinatario. I Client e server TAXII scambiano informazioni in un modello request/response. Channel: un canale mantenuto da un server TAXII consente ai mittenti di inviare dati a molti destinatari e a questi ultimi di ricevere dati da molti mittenti. I client TAXII scambiano informazioni con altri client TAXII in un modello asincrono di tipo publish/subscribe. OpenIOC. L’Open Indicators of Compromise (OpenIoC) è un linguaggio XLM-based volto a raggruppare e comunicare informazioni. Esso permette di descrivere caratteristiche tecniche che identificano una minaccia nota, una metodologia di attacco, o altri indicatori di compromissione. Si concentra su artefatti malevoli, indicatori di compromissione e TTP specifiche. OpenIOC stabilisce uno standard per la registrazione, la definizione e la condivisione di informazioni sia internamente che esternamente in un formato strutturato. Per finalità di analisi forense, lo strumento consente ad un investigatore di descrivere indicatori di compromissione in un formato standardizzato che può essere esportato e interpretato in maniera consistente. Inoltre OpenIOC specifica un formato di base estensibile per ospitare eventuali diversi tipi di IOC rispetto a quelli nativamente definiti. Tra le caratteristiche principali vanno citati il supporto a query semplici e avanzate, la ricerca tramite hash di un file o specifici registri di windows, la combinazione di filtri riguardanti artefatti malevoli, autori, hostname e/o altri dati riguardanti un particolare evento malevolo. Attualmente esistono diversi applicativi utilizzabili anche per la conversione da OpenIOC a STIX. RFC 2350. La specifica RFC (Request for Comments) 2350 [56] stabilisce alcune linee guida circa l’organizzazione e le modalità di comunicazione di un CERT/CSIRT. Attraverso la formalizzazione di tale specifica, il CERT rende noto alla propria consitituency in primo luogo quali sono le proprie aree di competenza e le proprie capacità, in secondo luogo le politiche e procedure operative adottate. Uno degli obiettivi della RFC2350 è proprio quello di definire un modello standard per la diffusione delle informazioni tra i CERT e il resto della comunità. Infatti, affinché vi sia una corretta interazione tra i CERT e i rispettivi constituent, all’intera comunità devono essere ben chiare le politiche e procedure dei response team, i loro rapporti con altri team o terze parti, quali canali di comunicazione utilizzano e come provvedono a renderli sicuri. [56]. Per ulteriori informazioni consultare: http://www.rfc-base.org/txt/rfc-2350.txt. A seguire si riportano le principali informazioni che devono essere pubblicate da un CERT ai sensi del template RFC 2350 (tipicamente sul proprio sito web):. Informazioni sul documento, quali data dell’ultimo aggiornamento, la lista di distribuzione per le notifiche, i luoghi (gli indirizzi) in cui la versione più recente del documento può essere trovato, ovvero tutte quelle informazioni utili alla constituency per poter accedere allo stesso ed ai suoi aggiornamenti;. Informazioni di contatto: denominazione ufficiale del CERT, indirizzo, contatti telefonici/fax, indirizzo mail, chiavi pubbliche e tecniche crittografiche, membri del team, ecc. Charter, ovvero le informazioni sulla missione che si è prefissa il CERT e sulle autorità da cui dipende. Dovrebbe includere almeno quattro elementi:. mission statement: obiettivi e finalità del CERT;. constituency: soggetti/entità cui sono rivolti i servizi offerti dal CERT (ciò determina conseguentemente il perimetro di lavoro del CERT stesso);. sponsorship / affiliation: indicazione degli organismi che supportano e finanziano le attività del CERT;. authority: linea di riporto del CERT;. Politiche e procedure, tra cui:. tipologie di incidente che il CERT è in grado di affrontare ed i livelli di supporto che offre durante la gestione;. cooperazione ed interazione con i soggetti con cui il CERT opera abitualmente (non solo per le attività di risposta agli incidenti), tra cui altri CERT, forze dell’ordine, organi di stampa, fornitori, ecc.;. comunicazione e autenticazione, ovvero indicazioni sulle modalità con cui il CERT assicura la sicurezza delle comunicazioni tra loro e la constituency (es. tecniche crittografiche utilizzate, condivisione delle le chiavi pubbliche, indicazione delle firme digitali, ecc.);. Servizi offerti;. Modalità e canali per le segnalazioni di incidenti e vulnerabilità. SIM3 [57]. [57]. Fonte: https://www.trusted-introducer.org/SIM3-Reference-Model.pdf. SIM3 (Security Incident Management) è un modello per valutare la maturità della gestione degli incidenti di sicurezza. Il modello di maturità è costruito su tre elementi base:. Parametri di maturità;. Quadranti di maturità;. Livelli di maturità. I Parametri sono le quantità misurate in termini di maturità (sono previsti più di 40 parametri), ed appartengono individualmente a uno dei quattro quadranti, ovvero O – Organisation, H – Human, T – Tools, P – Processes. Nell’ambito del modello devono essere misurati i livelli di maturità per ciascun parametro, secondo una scala a 5 livelli da 0 a 4. Sono fornite indicazioni per stabilire le condizioni per passare da un livello ad un altro. Tale modello è alla base dello schema di accreditamento definito da Trusted Introducer ma può essere impiegato anche per processi di autovalutazione. eCSIRT.net Incident Taxonomy [58]. [58]. Fonte: http://www.ecsirt.net/cec/service/documents/wp4-clearinghouse-policy-v12.html#HEAD6. Si tratta di una tassonomia per la classificazione degli incidenti di sicurezza molto diffusa presso i CERT e le organizzazioni di sicurezza. Ne è incoraggiato l’utilizzo anche per favorire attività di comparazione e statistiche sugli incidenti rilevati. Propone uno schema di classificazione degli incidenti fornendo esempi dettagliati utili a favorirne la tipizzazione. CCoP - CSIRT Code of Practice [59]. [59]. Fonte: https://www.trusted-introducer.org/TI-CCoP.pdf. Un codice di condotta è un insieme di regole o linee guida per i membri di un CERT su come comportarsi professionalmente, potenzialmente anche al di fuori del lavoro. Un esempio è quello sviluppato da Trusted Introducer, promosso oggi da ENISA come buona prassi per favorire lo sviluppo dell’etica professionale nella comunità professionale e aumentare complessivamente la maturità dei team ...

AGID [62], tramite le attività operative in carico al CERT-PA, supporta le PA nella prevenzione e nella risposta agli incidenti di sicurezza informatica che avvengono nel dominio costituito dalle stesse. Il CERT-PA è infatti la struttura responsabile per la conduzione e gestione delle attività operative e per il monitoraggio dello spazio cibernetico delle PA, anche tramite l’attivazione di specifiche collaborazioni con le comunità di riferimento nazionali ed internazionali. [62]. Riferimento: Art. 20, c. 3 lett. b) del Decreto Legge 22 giugno 2012, n. 83. Ai fini dell’efficacia del modello di interazione tra CERT-PA e PAL, si rende opportuna una decentralizzazione delle attività operative oggi in carico al CERT-PA, fondamentale per raggiungere in modo capillare tutte le amministrazioni del territorio nazionale. Infatti, l’attuale modello, basato su un unico CERT-PA centrale, risulta essere insufficiente rispetto alla nuova complessità del sistema, che ha visto un significativo aumento delle entità appartenenti alla Constituency [63]. Per operare efficacemente la sicurezza cibernetica a livello delle strutture locali della PA è dunque auspicabile la creazione di una rete nazionale di CERT periferici (CERT Regionali), supplementari al CERT-PA, i quali possano garantire, sulla base di un modello di interazione definito, un primo supporto diretto alle PAL, attivando un processo di escalation verso il CERT-PA in caso di necessità. [63]. La Constituency originaria del CERT-PA nel 2015 comprendeva solo PAC, Regioni, Città metropolitane, per un totale di circa 70 Amministrazioni. La Constituency attuale comprende anche la PAL e tutte le Amministrazioni sul dominio *.gov.it (~22.600 Amministrazioni). I CERT Regionali dovranno essere costituiti dunque con l’obiettivo di facilitare le attività di prevenzione e monitoraggio del CERT-PA, agendo come unità locali in grado di esercitare un controllo più diretto sul territorio, e di gestire tutti quegli incidenti di Cyber Security per i quali il CERT-PA non deve essere necessariamente coinvolto in maniera diretta, in quanto:. sono limitati ad un singolo ente locale o ad un numero limitato di PAL;. producono limitate implicazioni di sicurezza in termini di impatto su asset ed informazioni e sono pertanto gestibili nell’ambito delle normali attività operative della PAL stessa e/o di organismi periferici, quali i CERT Regionali;. sono relativi a PAL che non hanno aderito al processo di accreditamento al CERT-PA. Le PAL cercano da tempo di sviluppare maggiori competenze e servizi specialistici per contrastare le minacce cibernetiche che crescono in numero e sofisticatezza, ma non tutte possiedono dimensioni, risorse umane, tecniche ed economiche sufficienti per raggiungere tale risultato. La possibilità di accedere ad infrastrutture e risorse specializzate – messe a disposizione dai CERT regionali - costituisce un elemento chiave per l’innalzamento dei livelli di sicurezza di tali enti. Nel modello unificato di CERT su scala nazionale, i CERT regionali rappresenteranno entità più vicine alle PAL in senso geografico, operando, da un lato, come strutture di supporto verso le stesse e, dall’altro, fungendo da elemento di raccordo fra periferia e centro (CERT-PA). Per garantire omogeneità di comportamento e interoperabilità sia orizzontale che verticale è necessario che tutti i CERT della rete regionale operino secondo un modello organizzativo ed operativo comune, che individui e definisca struttura, organizzazione, risorse, servizi e processi e meccanismi di interazione con le PAL. Il modello proposto nel documento definisce una serie di elementi e di aspetti chiave alla base della costituzione e dell’avvio dei CERT regionali, come di seguito illustrato:. definizione della mission dei CERT regionali, ovvero la funzione di base che ha determinato la costituzione degli stessi, in termini di obiettivi ed attività fornite alla propria comunità di riferimento;. definizione della Constituency da servire, ovvero la comunità di soggetti ed entità che potranno accedere ai servizi offerti dai CERT regionali e/o che si potranno mettere in contatto ed attuare relazioni di mutuo scambio di informazioni con gli stessi (es. altri CERT nazionali e governativi), e definizione delle relative modalità di ingaggio, di cooperazione e di affiliazione;. sviluppo del catalogo dei servizi offerti dai CERT regionali, supplementare a quello offerto dal CERT-PA, determinando i benefici e le aspettative connesse a ciascun servizio;. definizione del modello organizzativo ed amministrativo, del sistema di ruoli e responsabilità e dei livelli di delega, in accordo con gli indirizzi strategici nazionali e con le pratiche attuate dal CERT-PA;. definizione dei processi operativi a supporto dell’erogazione dei servizi ed in particolare quelli di gestione degli incidenti, di escalation verso il CERT-PA e di comunicazione verso altri enti locali e/o centrali;. formalizzazione delle responsabilità definite nell’ambito dei processi operativi;. sviluppo delle capacità, in termini di Risorse, Tecnologie ed Infrastrutture, da implementare e/o migliorare per il funzionamento dei CERT regionali;. definizione dei requisiti di sicurezza fisica e logica per la protezione degli spazi di lavoro, degli asset informatici e delle informazioni impiegati dai CERT regionali;. definizione dei meccanismi di interazione e cooperazione, inclusa l’identificazione del modello di affiliazione e/o accreditamento più appropriato in funzione dei servizi offerti;. definizione di una roadmap al fine di prioritizzare il rilascio dei servizi e delle capacità connesse sulla base del loro rapporto costi/benefici, valutando, al contempo, la possibilità di ricevere finanziamenti di tipo governativo sia livello nazionale che sovranazionale (i.e. europeo). 5.5.1. Mission dei CERT regionali. Come precedentemente illustrato, i CERT regionali si pongono come strutture istituite e operanti sul territorio con il ruolo di coordinare, supportare e monitorare le attività di prevenzione, risposta e ripristino degli incidenti critici di tipo cyber nell’ambito del dominio costituito dalle PAL. Tenuto conto degli ambiti di responsabilità e di relativa specializzazione del CERT-PA e degli altri organismi centrali istituiti nell’ambito della strategia nazionale per la sicurezza cibernetica [64], le attività critiche dei CERT regionali dovrebbero comprendere:. [64]. Si veda Par. 4.1. fornire supporto ed assistenza specialistica alle PAL nell’analisi dei dati relativi alle minacce informatiche emergenti e nella risoluzione degli incidenti di cyber security;. agevolare la diffusione di informazioni tempestive e immediatamente utilizzabili su nuovi scenari di rischio, attacchi in corso, trend di fenomeni cyber indirizzati a specifici settori e possibili impatti per le PAL e la loro utenza;. incentivare a livello locale l’applicazione dei processi di gestione della sicurezza, delle metodologie e delle metriche valutative per il governo della sicurezza cibernetica definite a livello nazionale;. facilitare le attività di prevenzione e monitoraggio del CERT-PA sul territorio, agendo come unità capaci di esercitare un controllo più diretto a livello locale, mediante azioni di aggregazione delle PAL;. collaborare e cooperare con le altre organizzazioni nazionali ed internazionali nel potenziamento e miglioramento della capacità difensiva delle PAL in materia di cyber security;. accrescere le competenze specialistiche degli addetti alla sicurezza cibernetica e migliorare le attività di sensibilizzazione su questi temi. 5.5.2. Constituency dei CERT Regionali. La Constituency dei CERT regionali è rappresentata dalla comunità delle PAL [65] che possono accedere e beneficiare dei servizi da questi erogati. Una lista, non esaustiva, delle categorie di PAL che possono essere serviti in linea di principio dai CERT regionali è fornita a seguire:. Province. Comuni. Comunità montane e isolane. Forme associative tra enti locali, ovvero enti territoriali che sperimentano la gestione associata dei servizi e delle funzioni, tra cui: le Unioni di Comuni, Centri Servizi Territoriali, consorzi intercomunali, ecc. Enti economici locali, quali aziende municipalizzate, le società in-house e le società miste. Aziende sanitarie e ospedaliere locali, inclusi gli istituti di ricovero e cura pubblici a carattere scientifico, ed altri enti di supporto al Sistema Sanitario Nazionale. Camere di commercio. Università ed Istituti di istruzione universitaria. Altri enti locali, quali Agenzie regionali, Consorzi di bonifica, Fondazioni, Istituti regionali, Musei, ecc. [65]. Un elenco aggiornato delle PAL è pubblicato in: http://www.indicepa.gov.it/public-services/docs-read-service.php?dstype=FS&filename=Categorie_ Amministrazioni.pdf. Dalle province al più piccolo degli enti locali, le PAL rappresentano i principali terminali dei servizi pubblici a cittadini ed imprese, nell’ambito di territori che presentano numerose specificità e differenze. Tali servizi coprono una pluralità di fabbisogni per la cittadinanza quali, a titolo puramente esemplificativo e non esaustivo:. Servizi informativi (Ufficio Relazioni con il Pubblico, siti internet, ecc.). Servizi socio-assistenziali e sanitari. Rilascio di certificati e documenti. Servizi alle persone ed alle imprese per l’impiego. Rilascio di autorizzazioni per l’avvio di attività commerciali e produttive sul territorio. Accertamento e riscossione di tributi locali. Servizi per l’infanzia e per l’istruzione. Pubblica Sicurezza sul territorio. Tali servizi a carico delle Pubbliche Amministrazioni determinano la raccolta e il trattamento di un enorme volume di dati di tipo riservato (personali, sensibili, ecc.) e di altre informazioni di tipo cogente, rendendole di fatto un bersaglio estremamente appetibile nello spazio cibernetico, con potenziali rischi legati alla sottrazione, alterazione e distruzione di informazioni, al blocco ed all’alterazione di servizi, ecc. Tale situazione è ulteriormente accentuata considerando che gran parte dei servizi precedentemente elencati sono oggi offerti sul territorio tramite il web o l’utilizzo di dispositivi mobili. Sono invece da ritenersi escluse dalla Constituency dei CERT regionali tutte le PAC e le relative articolazioni che continuano ad aderire al servizio di accreditamento offerto dal CERT-PA. Nel caso delle Regioni sono i CERT regionali, laddove costituiti, ad accreditarsi verso il CERT-PA, e l’ente “Regione” a beneficiare in maniera diretta dei servizi offerti da quest’ultimi. Va comunque sottolineato che tutte le PA, centrali e locali, in assenza della costituzione di un CERT regionale competente per il territorio, sono da ritenersi parte della Constituency complessiva del CERT-PA. Le PAL potranno accedere ai servizi offerti dai CERT regionali a valle di un processo di accreditamento, tramite il quale:. le PAL aderenti possono richiedere il coinvolgimento del CERT regionali per la gestione degli incidenti di sicurezza informatica sulla base di modalità attuative regolamentate da protocolli di comunicazione e da procedure operative di risoluzione ed escalation;. i CERT regionali possono raccogliere in modo ufficiale tutte le informazioni tecniche ed organizzative per la gestione dell’incidente. Potranno essere previsti più livelli di accreditamento rispetto ai quali profilare la Constituency, che si differenziano dal punto di vista della comunicazione e dell’interazione attesa tra il CERT regionale e la PAL e del livello di partecipazione attiva attesa di ciascun membro verso la comunità. In linea generale è possibile considerare almeno due livelli di accreditamento:. Livello Base, caratterizzato da un’interazione puramente informativa, che richiede la registrazione della PAL sul portale del CERT regionale, attraverso il quale le sarà consentito di accedere ad un’area riservata ed ottenere informazioni (es. bollettini informativi, statistiche di settore, ecc.);. Livello Avanzato, nell’ambito del quale potranno essere identificati enti che, per maturità dei presidi di sicurezza e di competenze specialistiche sviluppate al proprio interno, potrebbero essere in grado di fornire, ove ritenuto necessario, un contributo attivo all’erogazione dei servizi del CERT e/o al miglioramento dei servizi stessi ...

Da un punto di vista amministrativo, i CERT possono adottare assetti differenti a seconda del fatto che:. siano inseriti in una società in-house, già esistente o costituita ad-hoc, nella forma di soggetto giuridico il cui capitale è detenuto in toto o in parte, direttamente o indirettamente, da un’organizzazione che affida l’erogazione dei servizi. ci si affidi ad un’organizzazione esterna per la fornitura del servizio CERT, anche attraverso meccanismi di outsourcing. Il primo scenario è caratterizzato da una minore complessità amministrativa in fase di start-up (adempimenti societari, gestione del personale, ecc.), dalla possibile riduzione dei tempi di avvio, legata al punto precedente, e da una maggiore efficienza operativa derivante dalle possibili sinergie con il resto dell’organizzazione. Di contro si evidenzia tuttavia che tale assetto può comportare la necessità di istituire pratiche e processi definiti a garanzia della separazione dei ruoli e delle responsabilità e volti ad impedire una possibile sovrapposizione degli stessi rispetto alle attività caratteristiche dell’ente che ospita il CERT. Il ricorso ad un soggetto giuridico distinto rappresenterebbe, da un lato, una garanzia di unicità di scopo ed autonomia gestionale intrinseca, ma comporterebbe dall’altro una maggiore complessità amministrativa, soprattutto in fase di start-up, con evidenti tempi di avvio più lunghi nonché costi di gestione più elevati con potenziale duplicazione degli incarichi apicali. Una soluzione percorribile per i CERT di una rete nazionale, e già percorsa ad esempio da alcune realtà territoriali nel nostro Paese, è quella di costituire dei gruppi di lavoro estesi ai quali potrebbero partecipare i diversi rappresentanti della constituency (imprese, enti territoriali, società in-house, ecc.) e i rappresentati dei settori di interesse. I vantaggi di questo approccio sono molteplici:. le competenze presenti sul territorio – o costituite secondo necessità – diventano un patrimonio comune di tutti i soggetti interessati, scoraggiando anche un potenziale turn over delle stesse tra i diversi CERT;. il patrimonio informativo di conoscenze viene condiviso tra tutti i soggetti, favorendo una più pronta risposta ad eventuali incidenti grazie anche alla possibilità di coordinare i vari soggetti da un un’unica regia. Un’ulteriore possibilità per implementare le capacità necessarie a garantire l’operatività della struttura, consiste nel ricorrere a competenze esterne reperibili nel settore privato per interi ambiti di servizio o per singole aree di intervento ad elevato tasso di specializzazione. I CERT dovrebbero poter disporre di staff con competenze ed esperienze su tutti i sistemi, le piattaforme e le infrastrutture informatiche impiegate dalla comunità servita. Nell’ambito del contesto nazionale, in considerazione della ampia e variegata constituency identificata, e in assenza di un censimento completo degli asset tecnologici in uso presso gli utenti coinvolti, risulta tuttavia poco realistico e difficilmente percorribile nell’immediato poter disporre all’interno del singolo CERT di tutte le esperienze, conoscenze e competenze necessarie. Alcuni dei principali benefici che possono portare un’organizzazione ad acquisire risorse e competenze esterne possono essere:. possibilità di rispondere in tempi rapidi all’innovazione tecnologica, in determinati ambiti, spesso inattuabile a livello di singole organizzazioni locali che potrebbero operare in condizioni di risorse limitate;. definizione di un corrispettivo contrattuale verso il service provider, vincolato ad un risultato o alle prestazioni;. raccolta di indicazioni che emergono attraverso il confronto ed il benchmarking con altre esperienze e la scelta di riprodurre all’interno del CERT buone pratiche e casi di successo ...

I servizi che un CERT Regionale può offrire sono molteplici. La selezione dell’insieme dei servizi da offrire costituisce una decisione di cruciale importanza per il raggiungimento degli obiettivi prefissati e lo sviluppo delle relative capacità operative. In primo luogo, i servizi offerti da un CERT Regionale dovranno essere determinati a partire dall’analisi delle necessità della propria constituency, identificando sin da subito i servizi minimi ed essenziali, o a maggior rilevanza per la comunità delle PAL interessate. Un approccio troppo ambizioso, volto all’erogazione di un numero di servizi eccessivo rispetto al reale fabbisogno della constituency o alla effettiva disponibilità di risorse del CERT, rischierebbe di minare in partenza la fattibilità realizzativa del costituendo CERT e, nel lungo periodo, la sua sostenibilità. L’attivazione di servizi specifici potrà avvenire progressivamente, potendo al termine di una fase pilota valutare eventualmente l’espansione del portafoglio di servizi offerti, aggiungendone di nuovi. Tale decisione sarà presa anche sulla base del riscontro dato dalla comunità di riferimento. In secondo luogo, il modello di servizio definito dai CERT Regionali dovrà essere supplementare rispetto a quello definito ed implementato dal CERT-PA. È auspicabile in tal senso che il CERT Regionale, almeno in una fase iniziale, si impegni ad attivare quei servizi (servizi di base/essenziali) per i quali una maggiore prossimità al territorio potrebbe determinare significativi miglioramenti dei livelli di efficacia garantiti nei confronti della constituency locale rispetto a quanto possibile realizzare attraverso un’unica azione centralizzata da parte del CERT-PA. Non si escludono comunque in linea di principio la possibilità e l’opportunità per i CERT Regionali di costruire ed attuare un percorso di crescita che passi attraverso il progressivo sviluppo di servizi caratterizzati da un maggiore livello di complessità tecnica e di contenuto. In tal senso, a fronte di livelli di maturità raggiunti più elevati, il CERT Regionale potrà valutare, in base alle risorse disponibili, quali ulteriori servizi offrire, basando tale valutazione, possibilmente, su un processo di valutazione dei rischi che identifichi le maggiori priorità per la constituency. I due fattori da prendere in considerazione per individuare i servizi essenziali che il CERT Regionale dovrà offrire sono il grado di complessità realizzativa del servizio abbinato alla sua rilevanza per la comunità di riferimento. Nei paragrafi successivi sono illustrati i servizi di base per il CERT Regionale, ovvero quei servizi che un CERT deve necessariamente fornire alla propria constituency, considerando però anche il livello di risorse necessario all’erogazione. 8.2.1. Accreditamento. L’Accreditamento è un servizio che, relativamente a un CERT regionale, che è una struttura intermedia tra il CERT-PA e le PAL, presenta due aspetti:. il CERT regionale si accredita nei confronti del CERT-PA entrando a far parte della sua constituency. la singola PAL si accredita nei confronti del CERT regionale entrando a far parte della sua constituency. Per quanto riguarda il primo punto, il CERT-PA mette a disposizione della propria constituency un portale dedicato attraverso il quale. ricevere aggiornamenti, in modo manuale e/o automatico [68], su nuove vulnerabilità/minacce. La modalità manuale comporta la distribuzione di News e Bollettini, blacklist e l’accesso al portale di Infosharing (https://infosec.cert-pa.it/). La modalità automatica fa uso di STIX/TAXII e MISP;. accedere a un’area riservata ove poter scaricare materiale rivolto ai membri della constituency e informazioni riservate (IOC, dump di username/password disponibili sul “mercato” hacker);. accedere ai servizi di Threat Intelligence. utilizzare un canale riservato e criptato GPG per la trasmissione di informazioni sensibili o potenziali malware;. partecipare ad eventuali eventi di formazioni organizzati dal CERT;. ricevere assistenza consulenziale dedicata. [68]. Maggiori dettagli su questa modalità nel seguito. Nel secondo caso, invece, un potenziale membro della constituency di un CERT Regionale (nel senso che rispetta i requisiti [69] necessari per poterne far parte) ne richiede effettivamente l’ingresso. Le motivazioni sono quelle già viste e cioè la possibilità di usufruire dei servizi che il CERT mette a disposizione alla propria utenza. Al momento della richiesta di Accreditamento, il Referente della sicurezza informatica della PAL provvede a contattare il CERT Regionale attraverso i canali preposti e, dopo essersi fatto adeguatamente riconoscere cioè dopo aver fornito la prova della propria identità e ruolo nell’ente, si impegna a fornire al CERT le informazioni richieste per una corretta trattazione degli incidenti di sicurezza e, in particolare:. Identificazione delle persone dell’ente in grado di intervenire in caso di incidente informatico e comunicazione delle relative modalità di contatto – le figure identificate devono essere in grado di poter gestire una crisi informatica in tutti i suoi aspetti con particolare riferimento al trattamento delle informazioni sensibili che possano essere state esfiltrate durante l’attacco cibernetico, alla comunicazione dell’incidente sia verso l’interno che verso l’esterno dell’organizzazione, al coordinamento di tutte le figure e le aree dell’organizzazione necessarie al contenimento del problema e al ripristino dell’operatività nonché alla raccolta di evidenze per eventuali prosecuzioni a livello processuale. Di tali figure dovrebbero essere forniti, oltre ai nominativi, il ruolo aziendale, le modalità di contatto (numero di telefono fisso, cellulare, e-mail e quant’altro necessario), la fascia oraria di contatto e, al di fuori di essa, degli eventuali sostituti. Tale elenco di informazioni deve essere assolutamente tenuto aggiornato nel tempo (a prova cioè di dimissioni, trasferimento di ruolo, pensionamento, trasferimento a altre sedi ecc.). Va tenuto presente che il Referente della sicurezza informatica della PAL, o la persona da lui preposta, è la prima persona che verrà avvertita in caso di un’eventuale crisi di sicurezza cibernetica e il fatto che non sia disponibile quando necessario può portare a un pericoloso ritardo nella gestione della crisi stessa. La presenza o meno di una procedura documentata per la gestione di incidenti di sicurezza – questa informazione serve al CERT per capire il livello di maturità dell’ente relativamente alla gestione dell’incidente e l’eventuale adozione di best practice al riguardo ma anche se l’ente è in grado di raccogliere le informazioni necessarie al trattamento dell’incidente. La presenza o meno di una documentazione di analisi del rischio e della classificazione di informazioni – questa informazione serve al CERT per capire se l’ente è conscio dell’eventuale effetto domino che un incidente di sicurezza può causare e, in particolare, se è in grado di valutarne l’impatto. L’elenco dei domini e degli indirizzi di rete che afferiscono all’ente. Un elenco dell’hardware e del software utilizzato – questo permette al CERT di comunicare in modo più efficace eventuali nuove vulnerabilità scoperte inviando solo le informazioni di pertinenza e riducendo quelle non necessarie. L’informazione trasmessa, quindi, ha già subito un’iniziale scrematura. [69]. Ad es. nel caso di un CERT regionale, che ha fondamentalmente giurisdizione territoriale, il fatto di avere la sede nel territorio di competenza. Più in generale, il CERT deve essere visto come un servizio “amico” e di supporto, un prezioso partner nella gestione degli incidenti di sicurezza con cui condividere tutte le informazioni necessarie, ovviamente nel rispetto di regolamenti e policies. D’altra parte, un CERT non può assolutamente sostituirsi alle best practice interne all’ente e alla corretta gestione “da buon padre di famiglia”. Un CERT deve avvertire, consigliare, aiutare (e tutto ciò in modalità best effort sulla base delle risorse assegnate) ma non può e non deve assolutamente coprire le mancanze nella gestione dell’ente facente parte della constituency e, in ultima analisi, non ha comunque responsabilità degli eventuali problemi interni all’ente causati da un incidente informatico. Una volta che la procedura di Accreditamento è andata a buon fine l’ente in generale potrà accedere a tutti i servizi che il CERT regionale mette a disposizione della propria constituency. 8.2.2. Informative. Il servizio di Informative è lo strumento che permette al CERT-Regionale di diffondere alle PAL accreditate, sotto forma di alert periodici, bollettini di sicurezza, generiche informative o segnalazioni di sicurezza, informazioni su:. nuovi scenari di rischio di tipo tecnologico, normativo ed organizzativo, che presentano un impatto rilevante per le PAL facenti parte della constituency;. insorgenza di nuove minacce o di nuove vulnerabilità ai danni di sistemi e applicazioni in uso presso tali PAL;. presenza di attacchi in corso ai danni di PAL, che possono determinare un certo grado di impatto per l’infrastruttura tecnologica gestita;. azioni sviluppate da altri soggetti operanti nella comunità delle PAL in risposta ad eventi e/o incidenti di sicurezza. Tale servizio è in grado di agevolare la diffusione di informazioni tempestive e immediatamente utilizzabili su nuovi scenari di rischio, attacchi in corso, trend di fenomeni cyber indirizzati a specifici settori e possibili impatti per le PAL e la loro utenza. Facilitando l’attività informativa di prevenzione sul territorio, i CERT Regionali possono quindi agire come unità capaci di esercitare un controllo più diretto a livello locale nei confronti della constituency e garantire in questo modo la divulgazione di informazioni mirate. 8.2.3. Formazione e Awareness. Il servizio di Formazione e Awareness è volto ad aumentare il livello di consapevolezza del personale delle PAL addetto alla gestione dei processi di sicurezza informatica su:. principi di gestione della sicurezza delle informazioni e di cyber security;. tematiche specifiche, quali risk management e gestione degli incidenti di sicurezza;. processi e procedure adottate nel dominio della PA per favorire l’interazione e la cooperazione tra enti locali e CERT Regionali. Tale servizio potrà essere attivato a fronte di richieste specifiche da parte delle PAL accreditate. Il servizio può prevedere corsi periodici di formazione in aula o da remoto (attraverso l’accesso a un sito di didattica remota), oppure essere realizzato attraverso iniziative di sensibilizzazione definite a tale scopo (workshop, eventi su base locale, ecc.). Inoltre, possono essere promosse campagne informative a livello territoriale rispetto ai rischi di sicurezza informatica affrontati dagli enti locali. 8.2.4. Ticketing. Il servizio di Ticketing costituisce il punto di ingresso per il processo di Incident Response ed ha il compito di tenere traccia di tutti i potenziali incidenti e delle informazioni ad essi correlate tramite l’ausilio di una piattaforma tecnologica di trouble ticketing. Utilizzando tale piattaforma:. gli utenti abilitati di ciascuna PAL accreditata può aprire direttamente o richiedere l’apertura di un ticket verso il CERT Regionale per la segnalazione di incidenti di sicurezza all’interno del proprio Ente;. gli analisti del CERT Regionale di riferimento aggiornano le informazioni contenute nei ticket attraverso l’inserimento dei risultati delle analisi effettuate in ciascuna fase del processo di gestione degli incidenti, allegando eventuale documentazione raccolta (mail scambiate con vendor, documenti analizzati, contenuto di eventuali comunicazioni verbali, ecc.). Tramite la piattaforma di ticketing, gli analisti del CERT Regionale possono aprire a loro volta ticket ad altre strutture e monitorare lo stato di avanzamento nella lavorazione di ciascun evento segnalato. Possono inoltre tenere traccia dello stato di lavorazione di ciascun incidente segnalato, semplificando le attività di monitoraggio dei livelli di servizio e di tutte le attività effettuate dagli attori coinvolti. Il servizio di ticketing offre inoltre l’opportunità di raccogliere e centralizzare tutte le informazioni relative agli incidenti, alimentando pertanto la knowledge base con la quale il CERT Regionale è in grado di effettuare tutte le analisi di propria competenza, correlando tra loro, ove necessario, segnalazioni provenienti da PAL distinte ed evidenziando eventi sospetti o schemi di attacco ripetuti. 8.2.5. Correlazione. Il servizio di Correlazione permette al CERT regionale di mettere in relazione le segnalazioni provenienti dal ticketing e le informazioni raccolte da altre fonti, tra cui il CERT-PA, per fornire al servizio di analisi dell’incidente una visione di insieme su ciascuna segnalazione pervenuta. In particolare, tramite la piattaforma di trouble ticketing e la knowledge base da essa alimentata, si cercano correlazioni tra ticket diversi, indice di:. pattern di attacco ripetuti nel tempo o verso target diversi;. eventuali eventi ad impatto sistemico o trasversale tra diverse PAL. 8.2.6. Analisi degli incidenti. Rispetto ad un incidente segnalato e classificato autonomamente da una PAL, il gruppo di analisti di sicurezza del CERT Regionale attiva il servizio di Analisi Incidente, per:. la verifica e l’analisi delle informazioni inviate dalla PAL e allegate al ticket;. la verifica della classificazione effettuata dalla PAL e l’eventuale ri-classificazione dell’evento stesso, valutandone l’impatto in un’ottica di tipo sistemico ed incrociando le informazioni ricevute con ulteriori indicazioni ad esso correlate, ricevute da altre PAL. 8.2.7. Triage & escalation. Con il servizio di Triage e Escalation il CERT Regionale effettua una normalizzazione degli incidenti segnalati, esprimendo la criticità dell’incidente secondo una scala ordinale su più livelli di impatto [70]. [70]. Si suggerisce in tal senso l’adozione di una scala ordinale a cinque livelli di impatto (livello 0 - livello 4) analoga a quella in uso presso il CERT-PA e che verrà descritta più avanti. Al termine della fase di triage il CERT Regionale può procedere con le seguenti azioni:. de-classifica dell’incidente in caso di falso positivo, inviando una comunicazione alla PAL coinvolta e chiudendo il ticket, nel quale viene allegato il risultato delle analisi effettuate. modifica del livello di classificazione precedentemente assegnato e comunicato dalla PAL segnalante;. avvio delle necessarie attività di trattamento dell’incidente, secondo le procedure operative condivise con le PAL in fase di accreditamento. In caso di incidenti distribuiti, che presentano quindi impatti di sicurezza su PAL distinte appartenenti alla propria constituency, il CERT Regionale invierà una segnalazione urgente alle PA coinvolte, coordinando tutte le seguenti attività di gestione incidente. In caso di incidenti di Livello massimo (es. livello 3 secondo la scala che verrà descritta più avanti), il CERT Regionale dovrà attivare lo stato di Emergenza ed effettuata un’escalation verso il CERT-PA, coordinandosi con lo stesso per tutte le seguenti attività di gestione incidente. 8.2.8. Supporto alle azioni di risposta. In fase di Supporto alle Azioni di Risposta il CERT Regionale supporta le PAL della propria constituency fornendo possibili soluzioni agli incidenti in termini di procedure, modalità ed eventualmente competenze sullo specifico attacco in caso l’Ente ne fosse sprovvisto. In particolare il CERT Regionale supporterà la PAL nella definizione del piano di trattamento dove vengono indicati:. i servizi e i sistemi coinvolti nell’attacco, con il relativo livello di classificazione;. le misure di contrasto e contenimento progettate per il trattamento dell’incidente ed il rientro nello stato ordinario;. i risultati attesi dall’applicazione delle suddette contromisure. Nel caso di incidenti a rilevanza sistemica, il CERT Regionale procede al coinvolgimento delle PAL interessate dall’incidente, inviando tutte le informazioni necessarie per il trattamento dell’incidente in corso. 8.2.9. Information Sharing. L’Information Sharing costituisce lo scheletro di funzionamento dei processi del CERT e di tutta la rete di CERT ed altre entità a livello nazionale ed internazionale con cui lo stesso può entrare in contatto, in quanto definisce le regole e le modalità di condivisione delle informazioni in ingresso ed in uscita con tutti gli interlocutori. L’Information Sharing deve assicurare la comunicazione tempestiva delle informazioni a tutte le parti interessate. Una corretta condivisione di informazioni deve consentire al CERT di raccogliere l’input, elaborare e processare l’output, mantenendo i livelli di classificazione previsti. La condivisione di informazioni – quali ad esempio quelle ricavate attraverso il processo di Cyber Threat Intelligence - con altre strutture permette inoltre di aumentare la capacità reattiva e proattiva di tutti gli attori coinvolti, accrescendo il livello di maturità dei partecipanti al processo di Information Sharing oltre ad arricchire l’informazione originaria in modo da consentire valutazioni sempre più precise. Condividere informazioni complesse in maniera non strutturata, non contestualizzata e in alcuni casi persino duplicata, non consente l’automazione necessaria ed utile a diminuire il caricamento e la relativa correlazione di quanto ricevuto. Le informazioni scambiate devono pertanto essere “actionable”, ovvero immediatamente utilizzabili in ambito operativo e possono riguardare:. minacce ed agenti di minaccia;. campagne in corso;. vulnerabilità;. exploit [71];. indicatori di compromissione (IOC). [71]. Ovvero programmi dannosi che contengono dati o codici eseguibili in grado di sfruttare una o più vulnerabilità di un software presente su un sistema. Le informazioni condivise provengono sia dalle attività di monitoraggio e analisi (Threat Intelligence) svolte dal CERT sia da scambi informativi con altri soggetti qualificati della comunità di riferimento. Alcuni dei principi alla base della condivisione delle informazioni sono:. fiducia nei confronti dei soggetti e delle entità con cui si coopera nello scambio delle informazioni;. adozione di schemi e modelli di classificazione delle informazioni. Molte iniziative di condivisione delle informazioni si basano ormai su schemi standard accettati dalla comunità professionale, come il Traffic Light Protocol (TLP, si veda successivamente per approfondimenti) per stabilire il modo in cui le informazioni da condividere devono essere gestite;. definizione del livello di accuratezza necessario per consentire un’efficace azione di contrasto sulle minacce in esame. Il grado di accuratezza necessario dovrà essere valutato in coerenza con le reali necessità; ad esempio, in una situazione di emergenza potrebbe essere comunque accettabile la condivisione di informazioni seppure parziali e in corso di perfezionamento se necessarie a contrastare per tempo una minaccia;. tempestività delle comunicazioni per contrastare adeguatamente l’azione di un attore malintenzionato;. possibilità di anonimizzare la fonte delle informazioni e la presenza di qualsiasi dato sensibile o che non è possibile/opportuno condividere con la constituency nella sua interezza. Le modalità di attuazione del processo di information sharing sono molteplici. In particolare si segnalano le seguenti come rilevanti con riferimento all’azione di un CERT:. Raccolta di informazioni da fonti multiple: un CERT può raccogliere informazioni relative a minacce e vulnerabilità sia dall’esterno della propria constituency, come ad esempio da fornitori di servizi di Threat Intelligence (nelle forme di rapporti, interazioni, ecc.) o CERT operanti anche in altri settori rispetto alla comunità di appartenenza, che all’interno, attraverso le segnalazioni ricevute dai membri della consitituency relativamente ad eventi o incidenti di sicurezza registrati. Distribuzione di alerts, bollettini, informative: un CERT può inviare informazioni alla propria constituency fornendo i dettagli descrittivi e tecnici su nuove vulnerabilità e minacce, nella forma di alert, bollettini o generiche informative. Comunicazioni periodiche: il CERT può organizzare incontri periodici, workshop o seminari per condividere informazioni verso la propria constituency e/o community. A seconda del livello di confidenzialità dei temi da discutere tali eventi possono essere limitati ad un numero ristretto di partecipanti. A fianco degli strumenti già descritti nel par 8.2.1 con cui può avvenire la condivisione di informazioni in modalità manuale (bollettini e Avvisi, portale di infosharing, mail, ecc.) è di fondamentale importanza stabilire anche strumenti e metodologie standard per la trasmissione automatizzata. Questo deve avvenire, in modo particolare, con le liste di IOC (Indicators of Compromise) da fornire in input a strumenti perimetrali come firewall, SIEM, IDS ecc. che possano così generare le opportune blacklist e gli allarmi relativi. L’obiettivo è quello di creare una rete di CERT collegati tra loro che, utilizzando magari scelte tecnologiche anche differenti, possano scambiarsi informazioni in tempo reale in modalità Producer-to-Consumer usando standard comuni e una tassonomia condivisa, cioè un insieme di dati e metadati per la descrizione di eventi di sicurezza, campagne cyber, malware e così via. CERT-PA in tal senso ha avviato da tempo una sperimentazione che ha coinvolto un gruppo di lavoro di attori pubblici e privati per la definizione di tali regole di trasmissione. Il risultato utilizza STIX 2.0 e TAXII per il trasporto. L’architettura usa anche Minemeld per aggregare, collezionare e processare i dati prima di inviarli al nodo di uscita. Lato Consumer, invece, è possibile utilizzare varie piattaforme compatibili con OpenTaxii tra cui MISP. A tal fine, CIRCL ( Computer Incident Response Center Luxembourg ) mette a disposizione una libreria per il pull dei dati da un Server TAXII locale o remoto. I dettagli tecnici sono oggetto di un documento separato che verrà pubblicato nei prossimi mesi da AGID CERT-PA e che invitiamo a consultare come riferimento qualora si desideri implementare la trasmissione condivisa automatica di informazioni con il CERT-PA ...

Le definizioni precedentemente fornite sono state individuate a partire dall’analisi delle seguenti fonti:. AGID, Linee Guida per il Disaster Recovery delle Pubbliche Amministrazioni. AGID, Linee Guida per la razionalizzazione dei CED delle Pubbliche Amministrazioni. AGID, Linee Guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei contratti della Pubblica Amministrazione. Codice in materia di protezione dei dati personali (Codice «Privacy»). Codice in materia di protezione dei dati personali (Codice «Privacy»), Allegato «B». Cyber Security Report La Sapienza. ENISA, Un approccio graduale alla creazione di un CSIRT, Documento WP2006/5.1(CERT-D1/D2). FIRST. Garante per la protezione dei dati personali. Glossario CERT-Nazionale. Glossario CERT-PA. Glossario ENISA. Glossario OWASP. ISACA, Cybersecurity Fundamentals Glossary. ISO 22300:2012, Security and resilience – Vocabulary. ISO 31000:2018, Risk management – Guidelines. ISO/IEC 20000-1:2011, Part 1: Service management system requirements. ISO/IEC 27000:2018, Information security management systems – Overview and vocabulary. ISO/IEC 27032:2012, Guidelines for cybersecurity. ISO/IEC 27035-1:2016, Information security incident management – Part 1: Principles of incident management. NIST SP 800-145, The NIST Definition of Cloud Computing. NIST SP 800-150, Guide to cyber threat information sharing. NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems. NISTIR 7298 Revision 2, Glossary of Key Information Security Terms. Quadro strategico nazionale per la sicurezza dello spazio cibernetico. Regolamento generale per la protezione dei dati personali n. 2016/679 (General Data Protection Regulation o GDPR). SANS Glossary of Security Terms. The Institute of Risk Management. The MITRE Corporation. US Department of Homeland Security, NICCS - National Initiative for Cybersecurity Careers and Studies ...

La consultazione pubblica relativa al presente documento è attiva dal 14 maggio al 13 giugno 2019. Questo documento raccoglie il testo delle Linee guida per lo sviluppo e la definizione del modello nazionale di riferimento per i CERT regionali, disponibile per la consultazione pubblica ...

13.2.1. Horizon 2020 Research and Innovation Framework Programme. Horizon 2020 (H2020) [81] è il programma europeo destinato alla ricerca e all’innovazione nel periodo 2014-2020, dotato di un budget totale di circa 80 miliardi di euro. H2020 persegue gli obiettivi della “Strategia Europa 2020”, ovvero una crescita intelligente, inclusiva e sostenibile, volta a incrementare la competitività globale dell’Europa. Lo scopo di H2020 è favorire lo sviluppo della ricerca scientifica di alto livello rimuovendo le barriere all’innovazione ed incoraggiando la costituzione di partnership fra i settori pubblico e privato ed il mondo accademico [82]. [81]. Per ulteriori informazioni consultare i siti: http://ec.europa.eu/programmes/horizon2020/ e http://www.guidaeuroprogettazione.eu/guida/guida-europrogettazione/programmi-comunitari/horizon2020/. [82]. A maggio 2018, la Commissione ha rinnovato l’impegno sul fronte Ricerca ed Innovazione lanciando il programma Horizon Europe (2020-2027) che avrà un budget di 114,8 milioni di euro e sarà fondato su tre pilastri, tra cui l’Open Innovation Pillar rafforzato dalla nascita del Consiglio Europeo sull’Innovazione (European Innovation Council). Inoltre, grazie a questo nuovo programma, ci sarà un incremento fino a 9,2 milioni destinati al Digital Europe Programme (https://ec.europa.eu/commission/sites/beta-political/files/budget-proposals-research-innovation-may2018_en.pdf). Sostenendo la ricerca e l’innovazione, H2020 si struttura su tre priorità:. eccellenza scientifica (Excellent Science), per consolidare ed estendere il sistema di ricerca e innovazione in Europa favorendone la competitività su scala globale, attraverso il rafforzamento dell’Area Europea di Ricerca;. leadership industriale (Industrial Leadership), azioni volte a rafforzare le capacità di sviluppo industriale e di business per le imprese così come le innovazioni ad alto potenziale di sviluppo tecnologico (Key Enabling Technologies) e le tecnologie dell’informazione e della comunicazione in generale;. sfide della società (Societal Challenges), come il filone delle “Società sicure”, per proteggere la libertà e la sicurezza dell’Europa e dei suoi cittadini. Durante il periodo 2014-2016, l’Unione Europea ha investito circa 160 milioni di euro in progetti di ricerca e innovazione in materia di cyber security [83] nell’ambito del Programma. Sono stati finanziati in particolare progetti in ambito di Crittografia e Security by Design, iniziative volte ad incorporare la sicurezza tra i requisiti per lo sviluppo delle nuove tecnologie (IoT, 5G, ecc.) e programmi di contrasto al crimine organizzato ed al terrorismo. Per il periodo 2017-2020 sono stati messi a disposizione fino a 450 milioni di Euro dei fondi stanziati per l’intero Programma sui temi di Cyber Security e Privacy [84]. [83]. http://ec.europa.eu/information_society/newsroom/image/document/2017-3/factsheet_cybersecurity_update_january_2017_41543.pdf. [84]. Nell’ambito degli stream “Secure societies – Protecting freedom and security of Europe and its citizens” (filoni Digital Security e Fighting crime and terrorism) e “Leadership in enabling and industrial technologies”. Le attività del programma H2020 e le opportunità di finanziamento sono delineate in programmi di lavoro (work programme) pluriennali predisposti dalla Commissione Europea all’interno del quadro legislativo di H2020 e gestiti dalla Direzione Generale per la Ricerca e l’Innovazione. I programmi di lavoro riportano, in allegato, gli obiettivi, le condizioni di partecipazione, i criteri di valutazione e di selezione per i bandi nel periodo di riferimento. Le proposte progettuali devono essere presentate tramite un apposito portale (Portale dei Partecipanti), dove gli inviti a presentare proposte (calls) sono suddivisi in tematiche più specifiche (topics). La procedura di presentazione della proposta può prevedere una o due fasi. Nel secondo caso i partecipanti devono inviare un primo schema di proposta (generalmente un abstract di 5-6 pagine) che viene valutata da un panel di esperti suddivisi per settore e area di esperienza. Solo in caso di esito positivo, viene richiesto ai partecipanti di inviare una proposta completa. Il Programma è aperto ad una pluralità di beneficiari, purché attivi nell’ambito della ricerca (in ogni campo), della scienza e dello sviluppo. Generalmente, sono ammesse proposte da organizzazioni avente sede nei paesi membri e nei paesi associati, con un consorzio di almeno tre persone giuridiche. Tra i soggetti ammissibili: enti di ricerca, università, organizzazioni non governative, imprese (incluse PMI). Poiché l’invio delle domande di finanziamento avviene solo attraverso il Portale dei partecipanti, tutti i beneficiari devono registrarsi ed avere un PIC (Participant Identification Code – codice identificativo dei partecipanti). Le Agenzie Nazionali, ma anche enti diversi come le Camere di Commercio, possono offrire consulenze e sostegno nella creazione di partenariati e presentazione delle proposte. Per quanto concerne i finanziamenti, in H2020 è previsto un unico tasso di finanziamento per tutti i beneficiari e tutte le attività: i finanziamenti comunitari coprono fino al 100 % di tutti i costi ammissibili per le azioni di ricerca e innovazione (ovvero per la ricerca ad ampio raggio), mentre il finanziamento copre generalmente il 70 % dei costi ammissibili per le azioni di innovazione (ovvero per la ricerca più vicina al mercato; la quota può raggiungere il 100 % per le organizzazioni senza scopo di lucro). Oltre ai costi diretti ammissibili (rimborsati sulla base della rendicontazione) viene rimborsata una quota fissa aggiuntiva forfettaria di “costi indiretti” (spese generali dell’organizzazione) corrispondente al 25 % dei costi diretti ammissibili. 13.2.2. Programma CEF Telecom. L’Agenzia Esecutiva INEA (Innovation And Networks Executive Agency) della Commissione Europea, mediante il Programma CEF Telecom Call [85] (Connecting Europe Facility, progetto per lo sviluppo, la costruzione e l’ammodernamento delle reti di telecomunicazione) finanzia progetti di interesse comune che contribuiscono ad aumentare l’interoperabilità, la connessione e lo sviluppo di infrastrutture digitali trans-europee che migliorino la qualità della vita dei cittadini, delle imprese e delle pubbliche amministrazioni, con l’obiettivo di promuovere il Mercato Unico Digitale. [85]. Ulteriori indicazioni utili sulle modalità con cui presentare le candidature sono illustrate alla pagina: https://ec.europa.eu/inea/en/connecting-europe-facility/cef-telecom/apply-funding/2018-cyber-security. Il Programma CEF Telecom Call fa parte di un set di inviti coordinati che coprono, oltre al settore delle telecomunicazioni, quello dei trasporti (CEF Transport) e dell’energia (CEF Energy). La Cyber Security è una delle aree supportate dal Programma, con uno stanziamento allocato nel 2018 di circa 13 milioni di Euro [86], per creare, mantenere o ampliare le capacità nazionali di svolgere una serie di servizi di sicurezza informatica, al fine di consentire agli Stati membri di partecipare in condizioni di parità ai meccanismi di cooperazione. [86]. Nel 2014-2016, l’UE ha investito circa 20 milioni di euro in tali progetti; nel 2017 sono stati stanziati fondi per 12 milioni di euro. All’interno dell’area Cyber Security, uno degli obiettivi definiti riguarda iniziative volte lo sviluppo delle capacità dei CSIRT) nazionali designate dagli stati membri dell’Unione Europea in conformità con quanto stabilito dalla Direttiva NIS. In particolare, sono finanziate in tale ambito le proposte finalizzate a rafforzare le competenze e le capabilities dei CSIRT governativi e/o settoriali, sia a livello tecnologico che organizzativo (es. le esercitazioni in ambito cyber). Anche in questo caso le opportunità di finanziamento sono presentate tramite un apposito portale, all’interno del sito della Commissione Europea (sezione Connecting European Facilities), e gli inviti sono suddivisi per settore (tra cui quello delle telecomunicazioni) e declinati in base ai singoli obiettivi definiti (Objectives). Nei work programme di riferimento sono dettagliati i criteri di idoneità ed ammissibilità, le modalità di presentazione delle proposte e le relative tempistiche. Con riferimento ai finanziamenti ottenibili, può essere stanziato dalla Commissione un contributo non superiore al 75% dei costi totali presentati per il progetto, che dovranno essere successivamente rendicontati su base periodica ...