Per gentile concessione dell’Istituto Superiore delle Comunicazioni e delle Tecnologie dell’Informazione pubblichiamo un altro paragrafo della nuova linea guida sulle certificazioni di sicurezza i cui contenuto ci sono stati anticipati dall’ ing. Luisa Franchina, Direttore Generale di ISCOM. Si tratta del paragrafo che affronta il tema della certificazione secondo i Common Criteria (CC). In questa seconda parte dell’articolo si analizzeranno vantaggi e svantaggi dell’utilizzo dei CC mentre nella prima parte sono state presentate le caratteristiche generale dei CC. Ricordiamo che sono stati già pubblicati sia l'indice completo della linea guida sia il paragrafo relativo alle certificazioni delle competenze del personale.

3.2 Valutazione e Certificazione di sistema/prodotto secondo lo standard ISO 15408 (Common Criteria)

3.2.1 Generalità sui Common Criteria

Pubblicato nella prima parte

3.2.2 Vantaggi e svantaggi dei Common Criteria

In questo paragrafo verranno descritti i principali vantaggi e svantaggi derivanti dall’applicazione dei CC. In realtà, come apparirà più chiaro nel seguito, gran parte di essi possono essere considerati comuni a tutte le raccolte di criteri di valutazione fin qui sviluppate.
Per quanto riguarda i vantaggi si possono citare:

1. la verifica, eseguita da una terza parte per la quale viene riconosciuto il possesso di conoscenze specialistiche, che le funzionalità di sicurezza del sistema/prodotto ICT, affiancate alle contromisure non tecniche previste, siano adeguate al soddisfacimento degli obiettivi di sicurezza;
2. lo svolgimento di un azione di contrasto preventivo degli incidenti di sicurezza ICT;
3. le maggiori garanzie che i CC offrono rispetto ad altri strumenti di contrasto di tipo preventivo;
4. la disponibilità di vasti cataloghi relativamente alle funzionalità di sicurezza ICT e ai requisiti di assurance adottabili;
5. la possibilità di esprimere in forma standardizzata requisiti di sicurezza per sistemi e prodotti ICT.

Con riferimento al punto 1) si può osservare che, qualora non si utilizzino i CC, qualcosa di simile può essere ottenuto mediante consulenze di sicurezza svolte da soggetti di comprovata capacità nel campo della sicurezza ICT che selezionino opportunamente le contromisure tecniche e non tecniche da adottare nell’ambito di un opportuno processo di analisi e gestione dei rischi ICT.
Per quanto concerne invece il punto 2) può essere utile evidenziare che strutture quali i CERT (Computer Emergency Response Team) hanno la caratteristica di svolgere una funzione preventiva solo rispetto alla ripetizione di attacchi a sistemi ICT che siano già stati eseguiti e che risultino quindi già noti.
Tramite la valutazione compiuta avvalendosi dei CC, invece, non ci si limita a verificare che il sistema/prodotto ICT sia in grado di contrastare gli attacchi di tipo noto che potrebbero minacciarlo (ad esempio controllando, con l eventuale ausilio di strumenti automatizzati quali i vulnerability scanners, che siano state installate le patch a tale scopo sviluppate), ma ci si preoccupa anche di ottenere adeguate garanzie circa il fatto che non sia possibile violare le funzionalità di sicurezza del sistema/prodotto ICT secondo modalità non ancora conosciute.
Per quanto riguarda tali garanzie si può inoltre affermare, arrivando così a trattare il punto c), che risultano maggiori di quelle ottenibili con altri strumenti che potrebbero essere impiegati.
Utilizzando infatti i CC, soprattutto quando il livello di valutazione è elevato, si dispone di informazioni che non sono altrimenti accessibili (ad esempio i valutatori possono avere accesso al codice sorgente di un prodotto commerciale). Conseguentemente eventuali tentativi di violazione, messi in atto a scopo preventivo dall’organizzazione utilizzando risorse specializzate interne o esterne (i cosiddetti tiger-team), avrebbero minori probabilità di successo rispetto alle stesse attività eseguite nel contesto di una valutazione (ciò assumendo, naturalmente, che il livello di specializzazione dei valutatori non sia inferiore a quello delle risorse citate).
Relativamente al punto 4) si può affermare che i cataloghi funzionali e di assurance messi a disposizione dai CC possono avere un utilità considerevole anche fuori del contesto di una valutazione, ad esempio nella fase di progettazione della sicurezza di un sistema/prodotto ICT sicuro. Infine si può osservare, per quanto riguarda il punto e), che l’utilizzazione dei cataloghi sopra citati prevista dai CC ai fini della specificazione dei requisiti di sicurezza di un sistema/prodotto ICT da valutare, può anche trovare applicazione nella stesura di capitolati per l acquisizione di sistemi/prodotti ICT di sicurezza (esempi di tale tipo di utilizzazione possono essere trovati nel settore della pubblica amministrazione statunitense con lo sviluppo di un certo numero di Protection Profile per varie tipologie di prodotti ICT), indipendentemente dal fatto che sia poi pianificata una loro valutazione.
Inoltre la descrizione in forma standardizzata dei requisiti di sicurezza consente un più agevole confronto di sistemi/prodotti ICT certificati, sia dal punto di vista funzionale sia dal punto di vista del rigore della valutazione (requisiti di assurance).
Detto questo riguardo ai vantaggi che l’applicazione dei CC può portare, vediamo ora quelli che sono comunemente considerati gli svantaggi.
Essi derivano essenzialmente da come è stata utilizzata fino ad ora la certificazione CC. Nel prossimo paragrafo vedremo che questi svantaggi possono essere fortemente mitigati, se non addirittura annullati, utilizzando una diversa strategia di applicazione dei CC.
I principali svantaggi della certificazione secondo i CC potrebbero essere:

1. i lunghi tempi di esecuzione del processo di valutazione/ certificazione;
2. il costo elevato del processo;
3. la perdita della certificazione non appena ci si discosta anche lievemente dalla configurazione certificata.

Lo svantaggio citato al punto 1) deriva dall’obbligo per chi richiede la valutazione di predisporre una notevole mole di documentazione e dal tempo necessario ai valutatori per analizzare tale documentazione ed eseguire tutte le numerose e complesse azioni che i criteri pongono a loro carico. Conseguenza di questo stato di cose è che non di rado quando il processo termina è già disponibile una nuova versione del sistema/prodotto ICT.
Inoltre possono nascere difficoltà relativamente all’utilizzazione di prodotti certificati nelle architetture hw/sw più recenti.
Per quanto riguarda il punto 2) si può dire che il costo elevato risulta una diretta conseguenza, oltre che dei lunghi tempi di esecuzione, anche delle risorse non trascurabili dal punto di vista sia qualitativo sia quantitativo che durante l’esecuzione del processo è necessario impegnare.
Il fattore costo ha fatto sì che finora i criteri di valutazione in generale, ed i CC in particolare, siano stati prevalentemente impiegati nel campo della sicurezza nazionale (i budget sono in questo caso piuttosto elevati ed inoltre in vari paesi è obbligatoria in tale campo la certificazione di sistema/prodotto), oppure per la valutazione di sistemi/prodotti ICT per i quali sia ipotizzabile un fatturato particolarmente elevato (o perché è elevato il costo unitario del sistema/prodotto ICT, o perché se ne prevede la vendita in un elevato numero di esemplari, come è il caso, ad esempio, dei sistemi operativi dei computer).
E evidente che i limiti descritti ai punti 1) e 2) diventano meno marcati quando risulti adeguato utilizzare livelli di valutazione bassi.
Al riguardo si può peraltro ricordare che proprio con i CC è stato aggiunto un livello iniziale di valutazione che non trova corrispondenze nei precedenti criteri di valutazione e che è caratterizzato da tempi e costi alquanto contenuti.
Questa considerazione sarà meglio sviluppata nel paragrafo successivo, quando verrà descritta la strategia di approccio alla certificazione CC in corso di attuazione da parte dell’OCSI.
Riguardo al punto 3) è opportuno invece sottolineare che una delle implicazioni più dirette che crea notevoli difficoltà è l’impossibilità di installare patch senza prevedere una nuova certificazione del sistema/prodotto ICT.
Quest’ultima può essere però resa relativamente veloce e non troppo costosa seguendo le indicazioni che i criteri stessi forniscono relativamente al mantenimento nel tempo della certificazione nell’apposita classe di assurance denominata Maintenance of assurance.
In taluni casi, peraltro, ossia quando mediante una opportuna analisi si sia potuto stabilire che gli aggiornamenti hw/sw non possono compromettere il buon funzionamento delle parti più critiche del sistema/prodotto ICT, può essere sufficiente una integrazione della documentazione di valutazione, piuttosto che una riesecuzione di attività da parte dei valutatori.
Proprio la classe Maintenance of assurance, a dimostrazione dell’importanza che riveste, è stata quella maggiormente studiata dopo l’emanazione della prima versione dei CC.
A completamento di quanto esposto per il punto 3) può essere interessante osservare che l’esigenza di aggiornare i sistemi/ prodotti ICT pur mantenendo valide le garanzie relative al livello di sicurezza che sono in grado di offrire può essere parzialmente soddisfatta con approcci alternativi a quello della certificazione, ottenendo in tali casi vantaggi e svantaggi. Ad esempio si potrebbe prevedere che, dopo aver scelto alcune fonti di riferimento (tipicamente i cosiddetti CERT Computer Emergency Response Team, che raccolgono le segnalazioni relative agli incidenti di sicurezza e le divulgano unitamente alle eventuali contromisure utilizzabili per evitarli) dalle quali acquisire informazioni relative alle nuove vulnerabilità scoperte e alle patch eventualmente disponibili per ridurle o eliminarle, si proceda direttamente all’installazione delle patch stesse.
Tale approccio si baserebbe in pratica sulla filosofia di attribuire un maggior peso alla riduzione o eliminazione di vulnerabilità già note rispetto alla possibilità che proprio la patch produca anche, come effetto indesiderato, la creazione di nuove, ed eventualmente anche più gravi, vulnerabilità (ovviamente non ancora note nel momento in cui la patch viene resa disponibile).
Un simile approccio, peraltro, qualora si desideri che almeno per alcuni aspetti dia garanzie analoghe a quelle della certificazione, dovrebbe anche prevedere che un soggetto interno o esterno all’organizzazione verifichi l avvenuta installazione delle patch di sicurezza sui prodotti/sistemi ICT.
È evidente che il vantaggio principale dell’approccio descritto consisterebbe nei ridotti tempi con i quali si provvederebbe a dotare i sistemi/prodotti ICT delle contromisure in grado di contrastare nuove modalità di attacco utilizzate in almeno un incidente di sicurezza che sia stato segnalato alla comunità dei CERT.
Lo svantaggio è invece quello, già anticipato, di non prevedere una accurata analisi della modifica del sistema/prodotto ICT, analisi che tenda a verificare l’assenza di elementi sfruttabili per realizzare con successo attacchi diversi da quelli contrastati dalla modifica stessa.

3.2.3 La strategia dell’OCSI per la certificazione CC

L'individuazione della suddetta strategia deve necessariamente tenere in conto le esperienze recenti in materia di certificazione di sicurezza, al fine di individuare sia gli errori commessi, sia la possibilità di attuare possibili migliorie.
Nel seguito, si effettueranno le due analisi e, alla fine, si descriveranno alcune direttrici di sviluppo della certificazione di sicurezza che verrà attuata dall’OCSI.
Gli standard internazionali prevedono che la certificazione e la valutazione di sicurezza possa essere effettuata a vari livelli di garanzia: nel caso dei Common Criteria, sono previsti sette livelli di garanzia denominati EALx, essendo EAL1[16] il livello a garanzia più bassa, EAL7 quello a garanzia più elevata.
Al crescere del livello di garanzia crescono sia i controlli e le verifiche di sicurezza effettuati, sia gli oneri economici e tecnici a carico del Fornitore.
È opportuno evidenziare, che già il livello EAL1, pur essendo il più basso livello di garanzia previsto dai Common Criteria, garantisce l’assenza di vulnerabilità note e sfruttabili nel sistema/prodotto certificato.
Tale garanzia è già da considerarsi molto apprezzabile, almeno nei sistemi e prodotti ICT destinati alle applicazioni commerciali, soprattutto rispetto alla diffusa situazione attuale in cui molti sistemi/prodotti sono vulnerabili ad attacchi informatici già noti da tempo[17].
Analizzando la tipologia delle certificazioni fino ad ora effettuate dagli Schemi esteri, emergono alcune considerazioni, che possono essere riassunte come descritto nel seguito. E prevalentemente utilizzata la certificazione di prodotto a livelli di garanzia medi ed elevati (da EAL4 in su), mentre sono raramente eseguite le certificazioni di sistema (se non nell’ambito della sicurezza nazionale) e le certificazioni a bassi livelli di garanzia (EAL1 e EAL2).
Tale situazione è essenzialmente favorita dalle politiche commerciali dei Fornitori, che ritengono svantaggioso proporre agli utenti prodotti certificati con bassi livelli di garanzia.
Essendo in generale le certificazioni a livelli medio alti di garanzia, molto costose e richiedendo tempi lunghi rispetto al ciclo di vita del prodotto, la diffusione della certificazione di sicurezza risulta alquanto limitata.
Si osserva, in particolare, che le certificazioni eseguite all’estero hanno riguardato prevalentemente prodotti quali, ad esempio, smart card e dispositivi impiegati per la protezione perimetrale delle reti. Sono abbastanza diffuse le certificazioni dei documenti denominati Profili di Protezione (PP)[18].
Si possono individuare diverse applicazioni di PP certificati.
A titolo di esempio, negli USA, i PP vengono utilizzati come riferimento per definire i capitolati di approvvigionamento delle dotazioni di sicurezza ICT delle Agenzie Federali: storicamente, i primi PP certificati hanno riguardato soprattutto i firewall. Nella UE, sono stati predisposti alcuni PP riguardanti i dispositivi sicuri da utilizzare per i servizi di firma elettronica[19]: questi documenti costituiscono evidentemente un riferimento per i fornitori che intendono certificare prodotti appartenenti a tale categoria di prodotti.
Non sono per nulla diffuse le procedure di mantenimento nel tempo dei certificati di sicurezza.
In assenza di una procedura di mantenimento, formalmente il Certificato ha valore solo nel momento in cui viene emesso e, di fatto, le garanzie che può offrire vengono meno non appena si rilevino nuove vulnerabilità o vengano rilasciate nuove patch di sicurezza o nuove versioni del prodotto.
È evidente che, a tutela dell’utilizzatore finale del prodotto/sistema certificato, sarebbe opportuno che l’Organismo di Certificazione vigilasse sull’eventuale uso a fini promozionali della certificazione soprattutto nei casi in cui le garanzie da essa offerte siano effettivamente venute meno.
D’altra parte, analizzando la situazione attuale della sicurezza ICT, sembra opportuno esplicitare le seguenti considerazioni.
Innanzitutto, dalle statistiche disponibili sugli incidenti informatici e dall'esperienza pratica risulta che il maggior numero di incidenti deriva dallo sfruttamento di vulnerabilità note per le quali spesso esistono le patch (cioè gli aggiornamenti del software che risolvono la vulnerabilità stessa). Per migliorare tale situazione sembrerebbe logico, quindi, attuare una politica di utilizzo dei prodotti che ponga la giusta attenzione all'aspetto di disponibilità nella generazione delle patch da parte del fornitore e di test e inserimento delle patch stesse nelle applicazioni e nei sistemi software.
La seconda considerazione è che non ha molto senso utilizzare prodotti molto sicuri in sistemi complessivamente molto vulnerabili o in organizzazioni in cui non si sia provveduto a certificare l'intero processo organizzativo che ruota attorno all'uso del prodotto ICT certificato.
Queste considerazioni portano a dedurre che è preferibile una uniformità di attenzioni alla sicurezza, eventualmente anche a bassi livelli di garanzia, ma estesa ai vari ambiti che caratterizzano un “processo completo” (cioè, il sistema/ prodotto, l'ambiente, i ruoli del personale, le procedure di amministrazione e gestione della sicurezza, etc.) piuttosto che utilizzare un prodotto certificato ad alti livelli di garanzia e lacune di sicurezza in tutti gli altri ambiti.
La suddetta uniformità di sicurezza garantita si ottiene innanzitutto favorendo la certificazione secondo i Common Criteria di sistemi completi, piuttosto che il semplice assemblaggio di prodotti certificati e di prodotti non certificati [20].
Inoltre, sarebbe opportuno superare l’attuale conflittualità tra la certificazione di prodotto/sistema effettuata secondo i Common Criteria e la certificazione di processo aziendale secondo lo standard BS7799: i due tipi di certificazione, pur mantenendo le loro specificità, dovrebbero essere maggiormente integrati e coordinati, al fine di raggiungere un miglioramento complessivo della sicurezza dei sistemi ICT.
Inoltre, attualmente l'utente finale non risulta essere un soggetto fondamentale nella richiesta di certificazione, almeno non tanto quanto lo è il fornitore. Infatti, le certificazioni risultano essere richieste in modo pressoché esclusivo dai fornitori per i loro prodotti, ma non esiste ancora la cultura della Certificazione del Sistema, a cui dovrebbero essere molto più interessati sia l acquirente del sistema certificato, sia l’utente finale dei servizi erogati con sistemi certificati.
A titolo di esempio, consideriamo una applicazione di e-banking: in questo caso, da una parte dovrebbe essere interesse della banca certificare i sistemi acquistati dal fornitore, al fine di avere garanzie che le funzionalità di sicurezza desiderate (e acquistate) siano affidabili[21], dall’altra il cliente della banca che vuole utilizzare i servizi di e-banking dovrebbe pretendere che i sistemi utilizzati dalla banca stessa siano certificati da una parte terza rispetto sia alla banca, sia al fornitore del sistema.
Considerando quanto accaduto negli altri Paesi (come brevemente descritto in precedenza), bisogna riconoscere che la certificazione non ha avuto la diffusione che ci si sarebbe potuto attendere, sia per gli elevati costi, sia per i lunghi tempi di valutazione, sia per il fatto che la stragrande maggioranza degli Organismi esteri non vigilano sufficientemente sull’utilizzo di certificati non più validi sia formalmente, sia praticamente.
Come conseguenza di questo approccio, il certificato emesso perde rapidamente la sua reale utilità per l utente finale a causa, ad esempio, del presentarsi sistematico di nuove vulnerabilità che non sono contrastate dal sistema/prodotto nella versione in cui è stato certificato.
Nel contempo, quasi nessun fornitore intraprende autonomamente[22] il percorso del mantenimento della certificazione, con azioni che, sotto la verifica dell'Organismo, garantirebbero una elevata tempestività nel contrastare le nuove minacce e gli eventuali malfunzionamenti che influenzino la sicurezza del sistema-prodotto.
Infine, un ultimo elemento che è bene tenere presente è legato alla peculiarità del mercato italiano per i fornitori di prodotti e sistemi ICT. Infatti, l'Italia è caratterizzata da una molteplicità di aziende medie e piccole che si occupano, con ottimi risultati sul piano nazionale e internazionale, principalmente dell'integrazione del software e dell’hardware esistente, piuttosto che della loro produzione (le aziende produttrici sono concentrate tipicamente negli USA).
Questo scenario fa si che, di fatto, potrebbe non esserci un mercato in Italia per la Certificazione di Prodotti agli alti livelli di garanzia (EAL3 e 4 tipicamente) come negli USA, ma che esista un potenziale mercato molto ampio per la certificazione di sistemi, che eventualmente integrino prodotti già certificati.
Tale certificazione potrebbe risultare molto appetibile soprattutto se eseguita in modo tale da fornire garanzie circa l assenza di vulnerabilità note sfruttabili nei sistemi stessi (ciò può essere ottenuto già con una certificazione al primo livello di garanzia EAL1 e aderendo a un processo di mantenimento del certificato).
Alla luce delle analisi sopra delineate, l'OCSI ha intenzione di intraprendere una azione di comunicazione e di operatività incentrata sui seguenti punti:

1. promozione della certificazione ai primi livelli di garanzia (EAL1 e EAL2);
2. promozione della certificazione di interi sistemi ICT;
3. promozione del mantenimento sistematico dei certificati;
4. stimolo della domanda di sistemi certificati agendo anche (e soprattutto) sugli utilizzatori finali dei servizi;
5. diffusione della certificazione di sistema a bassi livelli di garanzia nella Pubblica Amministrazione, al fine di innescare il meccanismo virtuoso conosciuto come government by example ;
6. utilizzazione della certificazione di Profili di Protezione che possano essere utilizzati come capitolati nella fornitura di sistemi/prodotti con specifiche funzionalità di sicurezza; tali capitolati potranno essere utilizzati sia dalla PA, sia dalle imprese private;
7. diffusione, congiuntamente alla certificazione secondo i Common Criteria, della certificazione di tipo BS7799/ISO27001 almeno per ciò che concerne i processi di gestione della sicurezza direttamente correlati con l’operatività dei sistemi certificati secondo i CC.

In particolare, per quanto riguarda i punti 1), 2) e 3) si può affermare che per il caso dei livelli di garanzia EAL1 e EAL2: la valutazione di sicurezza si può condurre in modo relativamente semplice sull'intero sistema ICT, riducendo, tra l altro, gli oneri tecnici a carico del Fornitore (ad esempio, produzione di una complessa documentazione di corredo al prodotto da certificare); i tempi di valutazione risultano mediamente dell'ordine di alcune settimane, garantendo un adeguato “time to market” per il prodotto-sistema; in considerazione dei tempi rapidi, la valutazione e il processo di mantenimento del certificato dovrebbero risultare sufficientemente economici, così da poter essere affrontati anche nelle situazioni di bassi budget di produzione del sistema/prodotto; per quanto riguarda la diffusione del processo di mantenimento della certificazione si può osservare che tale processo potrebbe costituire una interessante opportunità di lavoro per un vasto numero di professionisti della sicurezza, per i quali risulterebbe alquanto agevole ricoprire ruoli riconosciuti dall’OCSI, come, ad esempio, quello di Assistente[23]

Note

[16] Si prevede che la nuova versione dei Common Criteria modificherà la definizione del livello EAL1 introducendo verifiche di sicurezza aggiuntive che miglioreranno significativamente il livello di sicurezza garantito rispetto a quanto previsto dalla attuale versione dello standard.

[17] Potrebbe apparire che il livelli di garanzia previsti nei Common Criteria siano stati “mal progettati”, in quanto sono fortemente sbilanciati a favore di una elevata sicurezza garantita. Tale situazione, che effettivamente esiste, è però motivata, almeno in parte, dal fatto che la certificazione di sicurezza è stata inizialmente introdotta e utilizzata per molti anni quasi esclusivamente per sistemi/prodotti destinati ad essere utilizzati nell’ambito della sicurezza nazionale. Anche nell’ambito della sicurezza nazionale, comunque, i livelli di garanzia EAL6 e EAL7 sono utilizzati in rarissimi casi, in quanto molto onerosi. Con il diffondersi della certificazione di sicurezza anche nell’ambito commerciale tale sbilanciamento è divenuto più evidente, senza però nulla togliere all’efficacia e alla utilità degli standard.

[18] Il Profilo di Protezione (PP) è un documento che descrive gli obiettivi di sicurezza, le minacce, l’ambiente ed i requisiti funzionali e di fiducia per una certa categoria di prodotto/sistema ed in modo indipendente dalla realizzazione. Un PP può essere utilizzato, ad esempio, per definire un insieme standard di requisiti di sicurezza ai quali uno o più prodotti possono dichiarare la conformità, o che devono essere soddisfatti dai sistemi usati per uno scopo particolare all’interno di un’organizzazione

[19] CWA 14167-2 Cryptographic Module for CSP Signing Operations – Protection Profile (CMCSO-PP);
CWA 14167-3 Cryptographic Module for CSP Key Generation Services – Protection Profile (CMCKG-PP);
CWA 14167-4: Security requirements for trustworthy systems managing certificates for electronic signatures - part 4 : cryptographic module for CSP signing operations - protection profile (CMCSO-PP).

[20] Ovviamente, la certificazione di sistema è generalmente più onerosa della certificazione, allo stesso livello di garanzia, dei singoli prodotti costituenti il sistema. A questa circostanza si può ovviare abbassando il livello di garanzia desiderato, eventualmente anche fino al livello EAL1 che, come detto in precedenza, è già da considerarsi largamente sufficiente in molte applicazioni commerciali

[21] Tali garanzie potrebbero consentire alla banca sia di incrementare il numero di clienti che si avvalgono del servizio di e-banking, sia di attenuare le proprie responsabilità nei confronti dei clienti a seguito del verificarsi di incidenti informatici.

[22] Il fornitore, d’altronde, potrebbe non avere alcun interesse economico e commerciale ad intraprendere un percorso di mantenimento del certificato, una volta che il suo uso a fini pubblicitari non venga, di fatto, impedito.

[23] L’Assistente è una persona abilitata a fornire assistenza al Committente della valutazione, al Fornitore o a un Laboratorio per la Valutazione della Sicurezza (LVS) nella fase di stesura della documentazione per la valutazione di un sistema/prodotto/PP. Inoltre, l’Assistente può curare la fase di gestione/mantenimento del Certificato. L’Assistente deve garantire l’imparzialità, l’indipendenza, la riservatezza e l’obiettività nello svolgimento del proprio ruolo, nonché la capacità di mantenere nel tempo i requisiti in virtù dei quali è stato abilitato

IsacaRoma link

ISCOM

• Intervista a Luisa Franchina Direttore Generale dell’Istituto Superiore delle Comunicazioni e della Tecnologia dell’Informazione
• Centro di formazione dei dipendenti della PA nel campo della sicurezza ICT
• ISCOM - L'analisi e la gestione del rischio: principi e metodi
• "Futuro Semplice": una nuova iniziativa di ISCOM
• L’OCSI e la certificazione della sicurezza ICT
• Fattori critici per lo sviluppo delle certificazioni di sicurezza secondo i Common Criteria
• ISCOM: Anteprima sulle nuove linee guida sulla sicurezza e la qualità dei servizi - prima parte e seconda parte

Nuova linea guida sulla “Certificazione della Sicurezza ICT”

• Anteprima della linea guida sulla "Certificazione della Sicurezza ICT": l’indice del volume
• Anteprima della linea guida sulla “Certificazione della Sicurezza ICT”: le certificazioni del personale
• ISCOM – Anteprima della linea guida sulla “Certificazione della Sicurezza ICT”: ISO 15408 Common Criteria – prima parte e seconda parte