Risultati
201 risultati
-
AGID
7. Modello amministrativo
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 ...
-
AGID
8. Servizi
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 ...
-
AGID
Glossario
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 ...
-
AGID
Linee guida per lo sviluppo e la definizione del modello nazionale di riferimento per i CERT regionali
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 ...
-
AGID
2. Indicazioni per le amministrazioni
Nella tabella che segue, le azioni illustrate nei paragrafi precedenti sono classificate in base all’impatto e alla “onerosità” delle stesse per le amministrazioni, vale a dire in base a quanto l’amministrazione deve investire, in impegno e risorse, per effettuarle. NB: i valori riportati nella colonna 2 della tabella sono tipici, nel senso che rappresentano - statisticamente - la situazione della grande maggioranza delle amministrazioni: non è tuttavia da escludere la possibilità che, in casi particolari, il livello di impatto effettivo di una o più azioni sia più alto o più basso del valore di colonna 2. Ad esempio, ove il personale di un’amministrazione sia già formato sui temi della sicurezza, l’azione AG1 potrà avere un livello di impatto basso; allo stesso modo, in situazioni ove ci sia un uso massiccio e poco disciplinato di dispositivi di proprietà del fornitore, l’azione A2 potrebbe avere livello di impatto medio o anche alto. Tabella 2.7 Impatto delle azioni per le amministrazioni. Azione. Livello di impatto. Note. AG1. Medio. Comporta attività di formazione. AG2. Basso. Solo modifiche organizzative. AG3. Basso. Solo modifiche organizzative, e una tantum. AG4. Alto. Comporta un assessment, potrebbe essere oneroso ove il patrimonio ICT dell’amministrazione sia esteso e le informazioni su di esso siano obsolete. AG5. Alto. Comporta attività di BIA e di RA. Possibile rivolgersi a società esterne. AG6. Basso. Azione una tantum. AG7. Basso. Azione una tantum. AP1. Basso. L’azione può essere facilitata usando strumenti come la tabella 3. AP2. Basso. L’azione può essere facilitata seguendo un processo di scelta strutturato come in figura 1. AP3. Basso. L’azione può essere facilitata usando le tabelle dell’Appendice A. AP4. Medio. Può comportare attività di formazione. A1. Basso. Modifiche organizzative e strutturazione di processi già presenti. A2. Basso. Essenzialmente modifiche organizzative. A3. Basso. Essenzialmente modifiche organizzative. A4. Basso. Essenzialmente modifiche organizzative. A5. Basso. Essenzialmente modifiche organizzative. A6. Basso. Modifiche organizzative e strutturazione di processi già presenti. A7. Basso. Modifiche organizzative e strutturazione di processi già presenti. A8. Medio. Prevede verifica di documenti, pertanto il livello d’impatto dipende dalla complessità di questi ultimi. A9. Basso. Essenzialmente modifiche organizzative. A10. Medio. Vedi note per AG4 e AG5. A11. Medio. Possibile l’uso di strumenti specifici. A12. Alto. Sono possibili costi aggiuntivi per manutenzione e aggiornamento di prodotti. A13. Alto. Può comportare l’acquisizione di servizi esterni. Come si nota dalla tabella, la maggior parte delle azioni sono di “basso impatto”, in quanto esse si configurano come semplici mutamenti organizzativi o strutturazione di processi già presenti. Dato il basso impatto, non si ravvisano motivi per cui le amministrazioni non possano attrezzarsi da subito per svolgere tale azioni. Potrebbero, al più, costituire eccezione P.A. di dimensioni estremamente ridotte, ad esempio piccolissimi comuni con personale minimo, che peraltro difficilmente intraprendono acquisizioni ICT critiche sotto l’aspetto della sicurezza. Le azioni di “medio impatto” prevedono investimenti sulle risorse interne dell’amministrazione, e potrebbero determinare necessità di incentivi, straordinari o meccanismi premianti per il personale. Pertanto le amministrazioni devono strutturarsi per svolgere queste azioni nei tempi e nelle modalità compatibili con il budget a disposizione, considerando comunque che i costi da sostenere sono interni, riguardando il personale, e non sono necessariamente da imputare alla spesa per l’informatica. Le azioni di “alto impatto” potrebbero coinvolgere risorse esterne all’amministrazioni (ad esempio monitori), per cui potrebbero determinare costi aggiuntivi (esterni, da imputare prevalentemente al settore informatico) per l’amministrazione stessa. Non si ritiene pertanto di poter imporre alle amministrazioni, di qualunque grandezza e tipologia, di svolgere obbligatoriamente da subito queste azioni. Le P.A. dovranno valutare tempi e modi per la loro progressiva adozione, ad esempio effettuandole in occasione di un’acquisizione ICT effettivamente critica, tenendo comunque conto che i costi esterni sostenuti rappresentano un investimento, che verrà ripagato già nel breve periodo dall’innalzamento della sicurezza complessiva e dunque dal minore rischio per l’amministrazione stessa. Le P.A. devono inoltre tener presente che, sebbene alcune azioni vadano ripetute nel tempo, l’impatto maggiore si ha la prima volta che esse vengono eseguite, mentre le successive (aggiornamento) il loro impatto è nettamente inferiore ...
-
AGID
13. Modelli di finanziamento
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 ...
-
AGID
11. Sicurezza
Se da un lato la sicurezza fisica rappresenta un primo livello di protezione dei dati, dall’altro la sicurezza logica costituisce uno strato indispensabile per la difesa di sistemi e reti informatiche. Infatti, in ragione della natura delle informazioni trattate dal CERT in caso di vulnerabilità ed incidenti, oltre alle misure di sicurezza per i canali di comunicazione, dovrebbero essere implementati controlli logici di sicurezza per proteggere la riservatezza e l’integrità delle informazioni. Una base di partenza può essere validamente rappresentata, nel contesto nazionale italiano, dalle Misure minime di Sicurezza ICT per la PA [76], ovvero quell’insieme di controlli volti a garantire una sicurezza di base a tutte le organizzazioni esposte alle minacce di tipo cyber. [76]. AGID “Misure minime di sicurezza ICT per le pubbliche amministrazioni” (2017). I suddetti controlli possono essere raccolti nei seguenti ambiti di sicurezza:. Inventario dispositivi e software: individuare i sistemi (hardware, software), i servizi e le risorse che gestiscono i dati informatici trattati da proteggere. Governance: identificare e rispettare le leggi e/o i regolamenti con rilevanza in tema di cyber security applicabili al contesto. Protezione da malware: i dispositivi in perimetro quando possibile devono utilizzare software di protezione, ad esempio antivirus / anti-malware, regolarmente aggiornato. Gestione password e account: assicurare una complessità adeguata delle password e gestire le utenze secondo i principi di need to know e least privilege. Formazione e consapevolezza: sensibilizzare il personale sui rischi di cyber security e sulle pratiche da adottare per l’impiego sicuro degli strumenti aziendali. Protezione dei dati: i sistemi devono essere configurati tramite procedure di hardening e backup periodici devono essere effettuati. Protezione delle reti: le reti e i sistemi devono essere protetti da accessi non autorizzati attraverso componenti hardware / software. Prevenzione e mitigazione: i software utilizzati vanno mantenuti aggiornati o dismessi in caso risultino obsoleti e non più aggiornabili. Nel caso di un incidente informatico devono essere informati i responsabili di sicurezza che seguiranno il processo di gestione degli incidenti interno ...
-
AGID
2. Riferimenti
ENISA, “Un approccio graduale alla creazione di un CSIRT”, Documento WP2006/5.1(CERT-D1/D2) (2006). ENISA, “Baseline capabilities for National / Governmental CERTs, Part 1”, Version 1.0 (2009). ENISA, “Baseline capabilities for National / Governmental CERTs, Part 2, Policy Recommendations”, Version 1.0 (2010). ENISA, “ENISA’s recommendations on baseline capabilities”, Update, December 2014 (2014). ENISA, “NIS Directive and national CSIRTs”, Info Note, February 2016 (2016). ENISA, “CERT Operational Gaps and Overlaps”, Report, December 2011 (2011). CMU-SEI, “Handbook for Computer Security Incident Response Teams”, (2003). CMU-SEI, “Organizational Models for CSIRTs”, (2003). FIRST, “Computer Security Incident Response Team Services Framework”, Version 1.1 (2017) ...
-
AGID
1. Premessa
Le Tecnologie dell’Informazione e della Comunicazione (Information and Communication Technology, ICT) sono in rapida espansione e condizionano ormai completamente un numero crescente di settori vitali dell’economia e di servizi offerti dalle Pubbliche Amministrazioni. L’ampliamento dei settori coinvolti e delle conoscenze richieste è una conseguenza della digitalizzazione dell’economia e della dipendenza di numerose attività dai servizi digitali; molte azioni quotidiane si svolgono infatti nel cosiddetto spazio cibernetico o cyberspace [1]. In prospettiva la crescita dell’internet delle cose (Internet of Things, IoT), ossia l’insieme di dispositivi connessi in grado di svolgere operazioni nel mondo fisico, aprirà sia le attività domestiche alla dimensione cibernetica, in modo qualitativamente diverso rispetto a quanto accade attualmente. Alle nuove tecnologie si accompagnano tuttavia nuovi e crescenti rischi; tra questi particolarmente rilevante è quello cibernetico (cyber risk). I dispositivi, il software e le connessioni di rete che compongono lo spazio cibernetico presentano vulnerabilità tecnologiche e organizzative che possono essere sfruttate in modo malevolo, come dimostra il moltiplicarsi degli attacchi informatici che riguardano ormai i vari settori della società. Uno spazio cibernetico non sicuro costituisce una debolezza grave in una società digitalizzata, non solo per i danni diretti che gli attacchi possono arrecare alle strutture colpite, ma anche perché una diffusa percezione di insicurezza può minare il funzionamento di quei settori che si basano sulla disponibilità, sull’integrità e sulla riservatezza di dati digitali. Il cyberspace è definito come «l’insieme delle infrastrutture informatiche interconnesse, comprensivo di hardware, software, dati ed utenti nonché delle relazioni logiche, comunque stabilite, tra di essi. Include tra l’altro internet, reti di comunicazione, sistemi attuatori di processo ed apparecchiature mobili dotate di connessione di rete», cfr. Presidenza del Consiglio dei Ministri (2013a). Il rischio cibernetico non è nuovo. Nelle fasi iniziali del processo di digitalizzazione tuttavia erano in numero limitato sia le potenziali vittime sia gli attori della minaccia. Solo i settori informatizzati (come la difesa e le telecomunicazioni) costituivano un target sufficientemente appetibile per gli attacchi cibernetici; inoltre le conoscenze e le risorse necessarie per progettare e sferrare tali aggressioni esistevano quasi esclusivamente in ambito militare e in alcuni centri di ricerca. Negli anni l’uso di dispositivi informatici e l’accesso alle reti telematiche si sono enormemente estesi, moltiplicando il numero di obiettivi. Inoltre le competenze necessarie per programmare codici malevoli sono ormai a disposizione di molte organizzazioni criminali, che sviluppano strumenti offensivi e talvolta li offrono a basso costo a un’ampia platea di clienti ed utenti. Anche ormai il cittadino e i suoi rapporti con la Pubblica Amministrazione sono divenuti nel tempo oggetto di attenzione per gli attacchi cibernetici, con la finalità di colpire e compromettere il legame di fiducia esistente tra gli stessi. La sicurezza cibernetica dei sistemi informativi delle organizzazioni e della relativa rete di interconnessione viene assicurata dall’azione, e dal relativo coordinamento, di diverse strutture di gestione della cyber security operanti nei diversi ambiti di competenza, tra cui i Computer Emergency Response Team (CERT [2]). Nel nostro ordinamento, come evidenziato più in dettaglio nelle successive sezioni del documento, l’attuale quadro legislativo ha determinato l’allocazione delle funzioni e dei compiti aventi rilievo per la sicurezza cibernetica a livello nazionale ad una molteplicità di attori istituzionali. In particolare, tale assetto è oggi in corso di evoluzione in risposta alle disposizioni provenienti dall’Unione Europea e che hanno portato alla costituzione del CSIRT Italia, che accoglierà al proprio interno le responsabilità e le competenze fino ad oggi ripartite tra CERT-PA e CERT Nazionale. Per ragioni di comodità espositiva si farà utilizzo nel resto del documento della denominazione CERT in luogo di altre con significati del tutto analoghi quali CSIRT (Computer Security Incident Response Team), IRT (Incident Response Team), CIRT (Computer Incident Response Team) o SERT (Security Emergency Response Team). Si precisa tuttavia che l’utilizzo della denominazione CERT dovrebbe considerare i seguenti criteri di base: (i) l’acronimo CERT è un marchio registrato della CMU-SEI e pertanto l’utilizzo dello stesso deve essere autorizzato da tale organizzazione; (ii) la mission primaria del CERT, secondo le convenzioni internazionali associate all’utilizzo di questo acronimo, deve essere fondata sulla gestione degli incidenti di Cyber Security, anche se focalizzata su aspetti di coordinamento e supervisione. In accordo con gli indirizzi strategici nazionali [3], devono quindi essere create le condizioni per sviluppare un’azione integrata che metta a fattor comune le diverse attribuzioni istituzionali delineate, anche al fine di avere un maggior presidio ed assicurare una maggiore efficacia delle azioni sul territorio e nel rispetto delle esigenze delle relative constituency. In quest’ottica si inserisce l’esigenza di definire un modello organizzativo ed operativo per la costituzione e l’avvio di CERT regionali nell’ambito della Pubblica Amministrazione italiana, che possa delineare uno standard nazionale rispetto al quale basare ogni implementazione degli stessi su base locale, tenendo in considerazione ed indirizzando al meglio le esigenze dei singoli settori, dell’industria ed i vincoli specifici delle singole amministrazioni. Indirizzo Operativo 5 “Operatività delle strutture nazionali, di incident prevention, response e remediation”, Piano Nazionale per la protezione cibernetica e la sicurezza informatica, Marzo 2017. All’interno del presente documento sono illustrati gli aspetti significativi da considerare per poter avviare ed operare un CERT e che potranno essere presi a riferimento per la costituzione di CERT regionali. Tali aspetti riguardano:. struttura amministrativa ed organizzativa;. catalogo dei servizi da erogare;. carta dei processi e matrice delle responsabilità;. risorse necessarie, in termini di personale, informazioni (modello dati), modelli tecnologici e applicativi e facilities;. requisiti di sicurezza fisica e logica da implementare;. modalità di analisi e valutazione dei risultati raggiunti;. opportunità di finanziamento per iniziative nel nostro Paese;. piano di attuazione. Nella definizione del modello sono state prese in considerazione le indicazioni e Best Practice fornite dalle organizzazioni internazionali di riferimento del settore (ENISA - Agenzia Europea per la sicurezza delle reti e dell’informazione; CERT/CC – CERT Coordination Center della Carnegie Mellon University - Software Engineering Institute; FIRST - Forum of Incident Response and Security Teams; TI - Trusted Introducer) e le pratiche attuate dal CERT-PA [4]. Si rimanda ai par. 2.2 e 2.3 per un elenco più dettagliato dei riferimenti considerati. Il documento è organizzato nelle seguenti sezioni:. Sezione 2 - Cosa fa un CERT regionale: descrizione del modello funzionale di riferimento per un CERT regionale, con presentazione degli elementi costitutivi dello stesso in termini di servizi, processi e risorse necessarie; vengono inoltre illustrati alcuni modelli per l’analisi delle performance (metriche e indicatori) (Cap. 8-12);. Sezione 3 - Come avviare un CERT regionale: vengono inoltre forniti una panoramica sui fondi disponibili per finanziare la costituzione e l’esercizio di un CERT regionale e un possibile piano di attuazione (Cap. 13-14);. Appendici: Glossario dei termini ...
-
AGID
9. Processo di gestione degli incidenti di sicurezza
Si riporta di seguito la matrice delle responsabilità relativa al processo di gestione incidenti della PA, indicando per ciascuna attività sopra descritta, l’attore coinvolto ed il grado di coinvolgimento, secondo la convenzione:. A. Analizza. R. Riceve. V. Valida/Verifica. E. Effettua. S. Supervisiona. I. Viene Informato. U. Supporta. Tabella 9.3 Matrice delle responsabilità. Id. Attività. Referente Sicurezza Informatica PA. CERT Regionale. CERT-PA. 1. Monitoraggi o degli eventi di sicurezza. E. 2. Analisi e classificazione. E. 3. Trattamento falsi positivi. E. 4. Gestione evento anomalo. U. E. 5. Gestione Incidenti Livello 0 (Non Rilevante) – Livello 1 (Informativo). 5.1. Definizione delle attività di gestione. E. 5.2. Trattamento incidente. E. I. 5.3. Chiusura incidente. E. 5.4. Comunicazio ne incidente Liv.1 al CERT Regionale. E. R. 6. Gestione Incidenti Livello 2 (Attenzione). 6.1. Coinvolgimento CERT Regionale. E. 6.2. Analisi e riclassifi cazione incidente. I. E. 6.3. De-classificazione per falso positivo. I. E. 6.4. Coinvolgimento PAL interessate. I. E. 6.5. Analisi segnalazione. E. I. 6.6. Supporto risposta incidente. R. E. 6.7. Coordinamento risposta incidente sistemico PA. R. E. 6.8. Trattamento incidente. E. I, S. 6.9. Rientro stato ordinario. I. E. 7. Gestione Incidenti Livello 3 (Critico). 7.1. Coinvolgimento CERT Regionale. E. 7.2. Analisi e ri-classificazione incidente. I. E. 7.3. De-classificazione per falso positivo. I. E. 7.4. Coinvolgimento CERT-PA. U. E. V. 7.5. Coinvolgimento PA interessate. I. E. 7.6. Analisi segnalazione. E. I. 7.7. Aggiornamen to CERT-PA. U. E. V. 7.8. Supporto attività di gestione. R. E. 7.9. Coordinamento e supporto attività di gestione. R. E. 7.10. Supporto risposta incidente. R. E. I. 7.11. Coordinamento risposta incidente sistemico PAL. R. E. I. 7.12. Trattamento incidente. E. I, S. I. 7.13. Rientro stato ordinario. I. E. 8. Ripristino e analisi post- incidente. 8.1. Analisi post-incidente e follow-up. U. E. 8.2. Supporto pianificazione attività di ripristino. U. E. 8.3. Attuazione piano di ripristino. E. I. 8.4. Monitoraggio ripristino. I, U. E. 8.5. Chiusura ripristino. R. E ...
-
AGID
14. Ipotesi di piano di attuazione
In questa sezione del documento viene rappresentato un possibile piano di attuazione di un CERT regionale, fornendo indicazione delle fasi da seguire, le macro-azioni necessarie e un’ipotesi di tempistiche. Tale piano è da ritenersi puramente indicativo e basato sull’esperienza pregressa di AGID e sul confronto con analoghe organizzazione. In tal senso, deve essere considerato come un’ipotesi a partire dalla quale costruire un piano di attuazione effettivo basato su una puntuale analisi del contesto in cui agirà il CERT regionale e degli specifici fabbisogni della constituency e degli ulteriori stakeholder. Pianificazione. Fase 1: Identificazione degli stakeholder e degli attori coinvolti nel piano. Identificare la constituency del CERT regionale. Identificare soggetti/interni ed esterni con cui il CERT dovrà interagire. Individuare uno sponsor per l’attuazione dell’iniziativa ed ottenerne il supporto. Fase 2: Ottenere la sponsorship dell’iniziativa. Definire un business case sui benefici derivanti dall’avvio del CERT regionale. Presentare il business case allo sponsor dell’iniziativa ed ottenerne il supporto. Fase 3: Sviluppare il piano di progetto operativo. Assegnare ruoli e responsabilità. Definire il macro-piano di progetto. Definire il piano di progetto di dettaglio, incluso il piano di comunicazione finale. Progettazione. Fase 4: Definizione della constituency. Identificare le aspettative della constituency e degli altri stakeholder. Definire l’approccio comunicativo verso la constituency. Determinare la constituency (iniziale) di riferimento per il CERT regionale. Fase 5: Dichiarare la missione del CERT regionale. Comunicare la missione alla constituency e al resto della community di riferimento. Fase 6: Determinare il modello finanziario. Determinare il modello di finanziamento/ricavo. Ottenere il finanziamento iniziale. Fase 7: Definizione del catalogo dei servizi. Determinare le modalità di erogazione dei servizi ai membri della constituency. Definire i livelli di servizio. Fase 8: Definizione del modello organizzativo. Determinare la struttura amministrativa. Determinare l’assetto organizzativo e il sistema di ruoli e reponsabilità. Fase 9: Definizione dei fabbisogni (personale, tecnologie, facilities). Personale: definire le job description. Tecnologie: definire l’infrastruttura di rete ed e le applicazioni a supporto dei servizi. Facilities: individuare gli spazi fisici (uffici, data center, ecc.). Fase 10: Definire il modello di information sharing con la constituency. Definire i flussi informativi da gestire e i metodi di collaborazione e comunicazione con tutte le parti coinvolte. Fase 11: Definire policy, processi e procedure. Documentare i flussi di lavoro e relativi ruoli e responsabilità. Formalizzare le procedure operative a supporto dei processi. Fase 12: Definizione dei modelli di valutazione delle prestazioni del CERT. Definire i livelli target/obiettivo. Costruire gli indicatori. Definire modalità di rilevazione e misurazione. Implementazione. Fase 13: Avviare il processo di acquisizione/potenziamento delle risorse individuate. Personale: avviare i processi di selezione interni/esterni. Tecnologie: acquisire le componenti infrastrutturali e applicative. Facilities: installare gli equipaggiamenti presso gli spazi fisici individuati. Fase 14: Rendere operativo il CERT regionale. Formare il personale. Implementare gli strumenti tecnologici presso i locali del CERT. Fase 15: Promuovere l’operatività del CERT presso la community. Attuare il piano di comunicazione per l’avvio del CERT (promozione online, organizzazione di eventi, workshop, ecc.) ...
-
AGID
9. Processo di gestione degli incidenti di sicurezza
Si riporta di seguito la matrice delle responsabilità relativa al processo di gestione incidenti della PA, indicando per ciascuna attività sopra descritta, l’attore coinvolto ed il grado di coinvolgimento, secondo la convenzione:. A. Analizza. R. Riceve. V. Valida/Verifica. E. Effettua. S. Supervisiona. I. Viene Informato. U. Supporta. Tabella 9.3 Matrice delle responsabilità. Id. Attività. Referente Sicurezza Informatica PA. CERT Regionale. CERT-PA. 1. Monitoraggi o degli eventi di sicurezza. E. 2. Analisi e classificazione. E. 3. Trattamento falsi positivi. E. 4. Gestione evento anomalo. U. E. 5. Gestione Incidenti Livello 0 (Non Rilevante) – Livello 1 (Informativo). 5.1. Definizione delle attività di gestione. E. 5.2. Trattamento incidente. E. I. 5.3. Chiusura incidente. E. 5.4. Comunicazio ne incidente Liv.1 al CERT Regionale. E. R. 6. Gestione Incidenti Livello 2 (Attenzione). 6.1. Coinvolgimento CERT Regionale. E. 6.2. Analisi e riclassifi cazione incidente. I. E. 6.3. De-classificazione per falso positivo. I. E. 6.4. Coinvolgimento PAL interessate. I. E. 6.5. Analisi segnalazione. E. I. 6.6. Supporto risposta incidente. R. E. 6.7. Coordinamento risposta incidente sistemico PA. R. E. 6.8. Trattamento incidente. E. I, S. 6.9. Rientro stato ordinario. I. E. 7. Gestione Incidenti Livello 3 (Critico). 7.1. Coinvolgimento CERT Regionale. E. 7.2. Analisi e ri-classificazione incidente. I. E. 7.3. De-classificazione per falso positivo. I. E. 7.4. Coinvolgimento CERT-PA. U. E. V. 7.5. Coinvolgimento PA interessate. I. E. 7.6. Analisi segnalazione. E. I. 7.7. Aggiornamen to CERT-PA. U. E. V. 7.8. Supporto attività di gestione. R. E. 7.9. Coordinamento e supporto attività di gestione. R. E. 7.10. Supporto risposta incidente. R. E. I. 7.11. Coordinamento risposta incidente sistemico PAL. R. E. I. 7.12. Trattamento incidente. E. I, S. I. 7.13. Rientro stato ordinario. I. E. 8. Ripristino e analisi post- incidente. 8.1. Analisi post-incidente e follow-up. U. E. 8.2. Supporto pianificazione attività di ripristino. U. E. 8.3. Attuazione piano di ripristino. E. I. 8.4. Monitoraggio ripristino. I, U. E. 8.5. Chiusura ripristino. R. E ...