Risultati
93 risultati
-
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
12. Modelli di analisi e valutazione dei risultati raggiunti
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) ...
-
AGID
3. Indicazioni per AGID
Presidiare la tematica della sicurezza significa anche verificare che siano costantemente disponibili, per le amministrazioni, adeguati (e sicuri) strumenti di acquisizione di prodotti e servizi ICT. A tale scopo, AGID propone di tener conto anche di questo obiettivo nel pianificare, di concerto con la Consip, la tempistica delle gare che interessano sistemi e progetti critici sotto l’aspetto della sicurezza, evitando ad esempio situazioni in cui convenzioni e/o accordi quadro siano esauriti e i successivi non siano ancora disponibili perché le relative gare sono ancora da aggiudicare ...
-
AGID
1. Premessa
DR-1. ISO 22317 - Linee guida per Business Impact Analysis. https://www.iso.org/standard/50054.html. DR-2. ISO 27001 - Sistema di Gestione della Sicurezza delle Informazioni. https://www.iso.org/isoiec-27001-information-security.html. DR-3. ISO 31000 Risk Management. https://www.iso.org/iso-31000-risk-management.html. DR-4. Linee guida sviluppo software sicuro. https://www.agid.gov.it/it/sicurezza/cert-pa/linee-guida-sviluppo-del-software-sicuro. DR-5. Misure minime di sicurezza AGID. https://www.agid.gov.it/it/sicurezza/misure-minime-sicurezza-ict. DR-6. ISO 15408 Standard Common Criteria. https://www.iso.org/standard/50341.html ...
-
AGID
Linee guida sicurezza nel procurement ICT
La consultazione pubblica relativa al presente documento è attiva dal 14 maggio al 13 giugno 2019. Questo documento raccoglie il testo delle Linee guida sicurezza nel procurement ICT, disponibile per la consultazione pubblica ...
-
AGID
5. Appendice A – Requisiti di sicurezza eleggibili
Nelle tabelle che seguono sono elencati alcuni requisiti di sicurezza che le amministrazioni possono inserire nei propri capitolati di gara. L’elenco non è esaustivo, ha solo lo scopo di offrire alcuni esempi significativi e di favorire un lessico comune nell’esprimere requisiti di sicurezza. Per ragioni di sintesi, il testo di alcuni requisiti (ad esempio di R1) è stato generalizzato in modo da renderlo un modello per una “famiglia di requisiti”, da declinare ed eventualmente suddividere in più requisiti elementari, a seconda del contesto della singola acquisizione. R1. Il fornitore deve adottare al proprio interno le procedure e politiche di sicurezza definite dall’amministrazione committente, con particolare riferimento alle modalità di accesso ai sistemi dell’amministrazione, all’hardening (esempio installazione di soluzioni di end point security) dei dispositivi utilizzati dal fornitore, alla gestione dei dati dell’amministrazione. R2. Il fornitore deve possedere la certificazione ISO/IEC 27001 e mantenerla per tutta la durata della fornitura. R3. (alternativo al precedente) Anche se il fornitore non è certificato ISO/IEC 27001, almeno deve usare un Sistema di Gestione della Sicurezza delle Informazioni (SGSI) aggiornato nel tempo. R4. Il fornitore deve far eseguire annualmente un audit sul proprio sistema di sicurezza, a proprie spese e da una società specializzata scelta previa approvazione della stazione appaltante. NB: Qualora applicabile, tale attività si incrocia con il requisito R2 (le verifiche dell’Ente Certificatore hanno cadenza pressoché annuale). R5. L’amministrazione può, con un preavviso di 20 giorni solari, richiedere ulteriori attività di auditing secondo modalità concordate con il fornitore. Le risultanze di tali audit verranno comunicate all’amministrazione. R6. L’amministrazione, direttamente o tramite terzi incaricati, può eseguire verifiche relative alla conformità della prestazione dei servizi rispetto a quanto stabilito nel capitolato tecnico oltre che nell’offerta tecnica se migliorativa. R7. Il personale del fornitore che presta supporto operativo nell’ambito dei servizi di sicurezza dovrà possedere certificazione su specifici aspetti della sicurezza. R8. Il fornitore deve disporre di una struttura per la prevenzione e gestione degli incidenti informatici con il compito d’interfacciarsi con le analoghe strutture dell’amministrazione e con le strutture centrali a livello governativo. R9. Il fornitore deve dotarsi delle misure minime di sicurezza per limitare il rischio di attacchi informatici (riferimento DR-5). R10. Il SOC del fornitore deve sovrintendere alla gestione operativa e continuativa degli incidenti informatici sui servizi erogati nell’ambito della fornitura. R11. Il fornitore deve garantire il rispetto di quanto richiesto dalla normativa vigente in materia di sicurezza cibernetica, anche in riferimento ai contenuti del GDPR. R12. Sulle reti messe a disposizione dal fornitore devono essere presenti di dispositivi di sicurezza perimetrale con funzioni di sicurezza (ad esempio Firewall e sistemi di Network Detection ed Event & Log Monitoring, SIEM, ecc.) necessari a rilevare e contenere eventuali incidenti di sicurezza ICT e in grado di gestire gli IoC (Indicator of Compromise). R13. Il fornitore deve usare protocolli cifrati e meccanismi di autenticazione nell’ambito dei servizi erogati. R14. Qualora il fornitore subisca un attacco, in conseguenza del quale vengano compromessi sistemi del committente da lui gestiti, deve farsi carico delle bonifiche del caso, e riportare i sistemi in uno stato di assenza di vulnerabilità. R15. Il fornitore si impegna a trattare, trasferire e conservare le eventuali repliche dei dati oggetto di fornitura, ove autorizzate dalle amministrazioni, sempre all’interno del territorio dell’UE. R16. Il fornitore deve dare disponibilità a far parte di un Comitato di Direzione Tecnica, eventualmente aperto anche a soggetti terzi, che tratti il tema della sicurezza, sia nell’ottica di favorire la risoluzione di temi aperti sia per introdurre eventuali varianti al contratto per fronteggiare nuove minacce o altro. R17. Il fornitore deve condividere le informazioni necessarie al fine di garantire il corretto monitoraggio della qualità e della sicurezza, eventualmente pubblicando le stesse nel portale della fornitura. R18. Il fornitore si impegna a sottoscrivere una clausola di non divulgazione (NDA) sui dati e sulle informazioni dell’amministrazione. R19. Le soluzioni e i servizi di sicurezza proposti dal fornitore devono essere aggiornati dal punto di vista tecnologico, con riferimento all’evoluzione degli standard e del mercato; devono essere conformi alle normative e agli standard di riferimento applicabili; devono venire adeguati nel corso del contratto, senza oneri aggiuntivi, alle normative che l’UE o l’Italia rilasceranno in merito a servizi analoghi. R20. Il fornitore deve attenersi alla politica di sicurezza dell’amministrazione committente, con particolare riferimento all’accesso ai dati dell’amministrazione, che avverrà esclusivamente sui sistemi di sviluppo e test. R21. In fase di analisi, il fornitore deve definire le specifiche di sicurezza (non funzionali) a partire dai requisiti espressi dall’amministrazione. R22. In fase di progettazione codifica, il fornitore deve implementare le specifiche di sicurezza nel codice e nella struttura della basedati. R23. Al termine del progetto, il fornitore deve rilasciare tutta la documentazione necessaria all’amministrazione per gestire correttamente quanto rilasciato anche sotto l’aspetto della sicurezza. R24. Supporto di protocolli sicuri e cifrati (HTTPS, SSH v2, ecc.). R25. Filtraggio di indirizzi IP. R26. Supporto di protocolli di autenticazione (ad esempio RADIUS, IEEE 802.1X, ecc.). R27. Gestione di più profili con privilegi diversi. R28. Funzionalità di “richiesta creazione o cambio della password al primo accesso”. R29. Blocco dell’utenza dopo un numero definito (fisso o variabile) di tentativi falliti di accesso. R30. Gli accessi degli utenti devono essere registrati su un archivio (log) non cancellabile con il reset. R31. Gestione dei log di sistema (accessi, allarmi, ecc.). R32. Il fornitore (anche in collaborazione con il produttore della tecnologia) deve offrire processi, unità organizzative e strumenti dedicati alla gestione di vulnerabilità scoperte sui prodotti oggetto della fornitura. R33. Per gli apparati proposti deve essere disponibile documentazione tecnica (schede tecniche, manuali, guide operative) relativa alla corretta configurazione e gestione degli aspetti di sicurezza. R34. I meccanismi di autenticazione devono essere basati su meccanismi di crittografia asimmetrica, a chiave pubblica; la lunghezza delle chiavi va impostata sulla base della criticità della comunicazione da cifrare (ad esempio 256 bit per le meno critiche, 512 bit per le più critiche). La gestione e distribuzione delle chiavi e dei certificati è a carico del fornitore. R35. Autorizzazione: sulla base delle credenziali fornite dall’utente, si devono individuare i diritti e le autorizzazioni che l’utente possiede e permetterne l’accesso alle risorse limitatamente a tali autorizzazioni. R36. Confidenzialità nella trasmissione dei dati: le comunicazioni tra la componente di gestione remota centralizzata e la componente locale installata presso la sede dell’amministrazione devono essere cifrate. R37. Fornire meccanismi che permettano di garantire l’integrità di quanto trasmesso (ad esempio meccanismi di hashing). R38. Il fornitore deve descrivere nel dettaglio le soluzioni tecniche utilizzate (dispositivi hardware e software impiegato, modalità operative, politiche di sicurezza, …) per soddisfare i requisiti di sicurezza dell’amministrazione committente. R39. In fase di attivazione del servizio, il fornitore deve concordare con l’amministrazione le modalità operative e le politiche di sicurezza, i livelli di gravità degli incidenti, le attività e le contromisure che dovranno essere svolte per contrastare le minacce. R40. Il fornitore dovrà attenersi alle politiche di sicurezza definite dalla committente, con particolare riferimento alla definizione di ruoli e utenze per l’accesso ai sistemi gestiti. R41. In caso di necessità, da parte degli operatori, di accesso a Internet, il fornitore deve utilizzare un proxy centralizzato e dotato di configurazione coerente con la politica di sicurezza definita dall’amministrazione. R42. In caso di rilevazione di un incidente di gravità elevata (con scala da definire a inizio fornitura), il fornitore deve dare immediata notifica, tramite canali concordati con l’amministrazione, dell’incidente rilevato e delle azioni da intraprendere, al Responsabile della Sicurezza indicato dall’amministrazione e al CERT-PA. R43. Per ogni incidente di sicurezza, il fornitore s’impegna a consegnare all’amministrazione, entro il giorno successivo, un report che descriva la tipologia di attacco subito, le vulnerabilità sfruttate, la sequenza temporale degli eventi e le contromisure adottate. R44. Su richiesta dell’amministrazione, il fornitore deve consegnare i log di sistema generati dai dispositivi di sicurezza utilizzati, almeno in formato CSV o TXT. Tali log dovranno essere inviati all’amministrazione entro il giorno successivo a quello in cui è avvenuta la richiesta. R45. Il fornitore deve monitorare la pubblicazione di upgrade/patch/hotfix necessari a risolvere eventuali vulnerabilità presenti nei dispositivi utilizzati per erogare i servizi e nelle infrastrutture gestite. Entro il giorno successivo al rilascio dell’upgrade/patch/hotfix, il fornitore deve avviare una valutazione, da rilasciarsi entro un numero giorni da stabilirsi, propedeutica all’installazione delle stesse sui dispositivi di sicurezza, che ad esempio identifichi la possibilità di applicare la patch immediatamente, o la necessità di apportare MEV o integrazioni prima di procedere alle installazioni ...
-
AGID
4. Indicazioni per le centrali di committenza
Si premette che le indicazioni elencate nei paragrafi precedenti si applicano, in generale, anche alle centrali di committenza. In particolare, le azioni AP2, AP3 e AP4 sono da ritenersi obbligatorie, per le centrali di committenza, quando queste svolgano iniziative di acquisizione ICT nell’interesse di Ministeri, Enti centrali, Regioni e città metropolitane. In aggiunta, si ritiene che le centrali di committenza, per il ruolo che hanno nelle acquisizioni pubbliche di beni e servizi, possono fungere da enti attuatori di miglioramenti/evoluzioni per gli aspetti di sicurezza delle forniture ICT. Anche sulla base dei risultati della rilevazione citata al paragrafo precedente, si propone alle centrali di committenza di:. inserire clausole di compliance alle indicazioni in materia di sicurezza sulle gare in corso che passi attraverso anche i comitati di governo (per le gare che li prevedono);. prevedere, per le gare che comprendono gestione di sistemi o fornitura di servizi di sicurezza, non solo flussi informativi sugli eventi critici verso l’amministrazione contraente, ma anche verso il CERT-PA e gli altri organismi a presidio della sicurezza cibernetica;. per le gare che prevedono centri servizi o servizi web, qualora si ritenga applicabile la misura, verificare la sicurezza tramite vulnerability assessment e penetration test. Il governo di queste verifiche potrebbe essere a cura di un organismo centrale (CVCN, CERT-PA, altri) in collaborazione col comitato di governo della fornitura;. sensibilizzare i fornitori al fine di anticipare le tendenze e le possibili problematiche di sicurezza che possono presentarsi (consultazioni di mercato mirate alla sicurezza);. costruire, in accordo con ANAC, un elevato livello di cultura e formazione delle Commissioni di valutazione delle gare in ambito sicurezza (vedi paragrafo 2.2.4);. svolgere un ruolo di omogeneizzatore/armonizzatore degli approcci di sicurezza e delle tecnologie di sicurezza erogati nell’ambito delle forniture della PA ...
-
AGID
10. Risorse
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) ...
-
AGID
6. Modello organizzativo
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 ...
-
AGID
3. Definizioni e Acronimi
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 ...
-
AGID
4. Contesto
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
5. Introduzione ai CERT
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 ...