Risultati
34 risultati
-
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
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
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
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
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
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
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
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
-
AGID