Il ruolo chiave del security target nelle valutazioni di sicurezza Common Criteria

Nelle valutazioni di sicurezza ai sensi dello standard Common Criteria (CC), il documento denominato Security Target (ST) è il principale documento del processo di certificazione in quanto specifica “cosa deve essere valutato” descrivendo le principali caratteristiche del Target of Evaluation (TOE), ovvero il prodotto oggetto della valutazione, e del contesto in cui è posto, ovvero l’ambiente operativo (OE).

Il Security Target, insieme al Piano di Valutazione predisposto dal laboratorio, è un documento che tutti gli schemi nazionali di certificazione richiedono quando uno sponsor o un vendor di prodotto ICT richiede di effettuare la valutazione presso di loro e già in questa fase il Certification Body valuta la qualità del Security Target, prevalentemente in termini di completezza, e può non accettare la richiesta di certificazione quando lo stesso non viene valutato adeguato ed esaustivo.

Contenuto e struttura di un Security Target

La figura riportata qui seguito mostra i contenuti che devono obbligatoriamente essere presenti nel Security Target, così come richiesto dallo standard Common Criteria.

Nel seguito, si descriveranno la finalità di ogni sezione e i principali contenuti previsti.

Il ruolo del Security Target nelle valutazioni di sicurezza

L’introduzione del Security target contiene gli elementi per identificare il Security Target stesso (titolo, versione e data di pubblicazione) e il Target of Evaluation a cui esso si riferisce.

In particolare la descrizione del TOE è effettuata in maniera narrativa su tre diversi livelli di astrazione:

• TOE Reference che contiene i riferimenti del TOE, ovvero il nome dello sviluppatore, il nome del prodotto e la sua versione.
• TOE Overview che mira ad offrire ai potenziali acquirenti del prodotto una descrizione delle sue modalità di utilizzo e delle principali funzionalità di sicurezza in un linguaggio che essi possano comprendere. I consumatori possono fare riferimento a questa sezione del Security Target per scegliere il prodotto che più si addice alle loro esigenze di sicurezza
• TOE Description che contiene una descrizione narrativa del TOE che si può articolare su più pagine. La TOE Description deve fornire ai valutatori e ai potenziali acquirenti una descrizione del prodotto più dettagliata rispetto alla TOE Overview. Oltre a descrivere le funzionalità di sicurezza del prodotto, viene definito l’ambiente operativo (Operational Environment) in cui si pone, delineando in modo preciso i confini fisici e logici del TOE. È di fondamentale importanza che il valutatore non abbia alcun dubbio su quali elementi facciano parte del TOE e quali invece appartengano all’ambiente operativo anche perché, molto spesso, i TOE sono spesso parte di un’architettura di prodotto più grande e complessa.

Dichiarazioni di Conformità

Le Dichiarazioni di Conformità (Conformance Claims) indicano il modo in cui il Security Target aderisce allo standard Common Criteria. Viene quindi specificata la versione dello standard CC seguita e in che modo il Security Target cui si conforma alla parte 2 e alla parte 3 dello standard, ovvero viene dichiarata l’esatta conformità a tali parti o se sono incluse anche delle estensioni. Sempre in questa sezione, viene dichiarato il livello di assurance alla quale verrà effettuata la valutazione.

Opzionalmente, si può dichiarare conformità a un Protection Profile o a una PP-Configuration che, come noto, sono dei documenti che definiscono le caratteristiche di sicurezza relative ad una categoria di prodotti. In questo caso, il Security target eredita i security requirements contemplati del PP cui si fa riferimento.

Anche in quest’ultimo caso, viene dichiarata la conformità al PP/PP-configuration che potrà essere:

• Conformità Stretta (Strict conformance): in tale modello di conformità esiste una relazione gerarchica tra il PP e il Security target (ST), ovvero ilSecurity Targetdeve contenere tutte le dichiarazioni del PP, ma può includerne altre aggiuntive o gerarchicamente più forti. Questo modello di conformità è ideale per introdurre requisiti di sicurezza più stringenti rispetto al PP che devono essere implementati in maniera rigorosa e univoca.
• Conformità Dimostrabile (Demonstrable conformance): in tale modello di conformità l’idea è che ilSecurity Targetfornisca una soluzione che risolva un generico problema di sicurezza definito nel PP. Il PP e ilSecurity Targetpossono contenere dichiarazioni completamente diverse che riguardano entità diverse, utilizzano concetti diversi e così via, ma la cosa importante è che ilSecurity Targetdimostri perché il requisito introdotto è equivalente o più restrittivo del PP. Questo modello di conformità è ideale per un prodotto ICT che vuole dichiarare la propria conformità a PP simili ed esistenti contemporaneamente.
• Conformità Esatta (Exact conformance): la conformità esatta è utilizzata prevalentemente nei PP e nei moduli PP approvati dal NIAP. Per definizione, la conformità esatta è un sottoinsieme della conformità stretta. La conformità esatta può essere considerata un approccio basato sulle specifiche o su un metodo di valutazione specifico del prodotto ICT. Le regole sono che ilSecurity Targetdeve trarre tutti i requisiti e l’ambito da un PP o da un PP-Configuration in maniera appunto esatta.

Nel caso di dichiarazione di conformità al un PP/PP-configuration, il livello di assurance al quale verrà effettuata la valutazione sarà automaticamente determinato dal PP/PP-configuration al quale ilSecurity Targetsi conforma.

Definizione del problema di sicurezza

Nella sezione Security Problem Definition (SPD) sono definiti i problemi di sicurezza che il prodotto ICT in valutazione deve affrontare.

In particolare:

• le minacce che devono essere contrastate dal TOE, dal suo ambiente operativo o da una combinazione dei due. Una minaccia viene descritta come un’azione dannosa eseguita da un soggetto (threat agent) su una risorsa del TOE.
• Le Organizational Security Policies (OSP), ovvero le regole, procedure o linee guida di sicurezza imposte nell’ambiente operativo. Le OSP possono essere stabilite da un’organizzazione che controlla l’ambiente operativo del TOE oppure direttamente da organismi legislativi e/o normativi.
• Le assunzioni che vengono fatte sull’ambiente operativo senza le quali il TOE potrebbe non essere in grado di fornire le sue funzionalità di sicurezza. Queste ipotesi, considerate vere durante la valutazione, possono riguardare l’ambiente fisico in cui è posto il prodotto, il comportamento del personale che ne fa uso e la connettività disponibile.

Tale sezione è strategica per tutta la valutazione perchè da quanto definito in essa derivano gli obiettivi e i requisiti di sicurezza che devono essere applicati. Per tale ragione deve essere completa, esaustiva e coerente con tutte le sezioni che compongono il ST.

Obiettivi di sicurezza

Gli obiettivi di sicurezza sono una dichiarazione concisa della soluzione prevista per il problema della sicurezza. Il ruolo di questa sezione è triplice:

• fornire una soluzione high-level, in linguaggio naturale, del problema con un livello di astrazione tale da risultare chiara e comprensibile per potenziali consumatori con un buon livello di conoscenza.
• dividere questa soluzione in due soluzioni parziali, che riflettono i ruoli del TOE e del suo ambiente operativo nell’affrontare ciascuna parte del problema.
• dimostrare che queste soluzioni parziali costituiscono una soluzione completa del problema.

IlSecurity Targetcontiene anche una tabella (Security Objectives Rationale) che mostra come gli obiettivi di sicurezza sono riconducibili alle minacce, alle OSP e alle assunzioni descritte nella definizione del problema di sicurezza. È richiesto che il Security Objectives Rationale abbia le seguenti caratteristiche:

• ogni obiettivo di sicurezza deve essere riconducibile ad almeno una minaccia, OSP o ipotesi, ovvero non ci deve essere nessun obiettivo spurio (obiettivo senza connessioni o correlazioni);
• ogni minaccia, OSP e ipotesi ha almeno un obiettivo di sicurezza che gli corrisponde;
• le assunzioni sono sempre relative all’ambiente operativo e quindi gli obiettivi di sicurezza per il TOE non sono connessi alle assunzioni.

Nella figura riportata qui di seguito sono indicate le correlazioni ammesse tra gli elementi dell’SPD e gli obiettivi di sicurezza.

Definizione dei componenti estesi

In molti casi i requisiti di sicurezza (si veda il paragrafo successivo) di unSecurity Targetsono basati sui componenti definiti nello standard CC. Tuttavia, in alcuni casi in unSecurity Targetpossono essere presenti requisiti che non si basano sui componenti della Parte 2 o Parte 3 dello standard. In questo caso, sono necessari nuovi componenti chiamati appunto componenti estesi.

Requisiti di sicurezza

I requisiti di sicurezza sono una parte fondamentale del Security Target in quanto stabiliscono con chiarezza, tramite un linguaggio standardizzato, gli obiettivi di sicurezza che il TOE deve raggiungere per essere considerato sicuro. Questi requisiti possono essere applicati in modo uniforme a diversi prodotti e sistemi. Questo permette una valutazione più oggettiva e comparabile. I requisiti di sicurezza servono inoltre come base per la verifica e la convalida delle funzioni di sicurezza del sistema poiché definiscono in dettaglio il procedimento che il valutatore deve seguire per metterle in atto.

I requisiti di sicurezza si dividono in due gruppi:

• i security functional requirements (SFRs): una traduzione degli obiettivi sicurezza in un linguaggio standardizzato;
• i security assurance requirements (SARs): una descrizione del procedimento da seguire per ottenere la garanzia che il TOE soddisfi le SFR;

Le SFR fungono da traduzione per gli obiettivi di sicurezza per il TOE definiti nel capitolo “Definizione del Problema di Sicurezza”. Inoltre, un insieme di SAR è definito per dimostrare che il TOE soddisfa le SFR. Se tutte le SFR e SAR sono soddisfatte allora si ha la garanzia che il problema di sicurezza sia risolto, ovvero che tutte le minacce sono contrastate, tutte le OSP sono rispettate e tutte le assunzioni sono sostenute.

TOE summary specification

L’obiettivo della TOE Summary Specification (TSS) è quello di fornire ai consumatori una descrizione di come il TOE soddisfa le SFR. Il livello di dettaglio adottato nella TSS deve essere sufficiente da far comprendere l’implementazione e la struttura generale del TOE.

La validazione di un Security Target: la classe Assurance Security Target Evaluation (ASE)

Come detto prima, il Security Target fornisce la base e il contesto per svolgere le attività di valutazione del TOE. Per questo motivo, prima di procedere con quest’ultima, è necessario verificare che il Security Target sia conforme a quanto richiede lo standard.

La metodologia per effettuare una valutazione di un Security Target è definita dalla classe Security Target Evaluation (classe ASE) dello standard Common Criteria ed è divisa in diverse parti, ognuna delle quali si focalizza su un capitolo del Security Target. Per ogni capitolo sono descritti in dettaglio i contenuti che esso deve presentare e i controlli che il valutatore deve effettuare.

Le attività che un valutatore deve svolgere, sono descritte in maniera dettagliata nel documento dello standard Common Criteria denominato “Common Methodology for Information Technology Security Evaluation” (CEM) che contiene tutta una serie di controlli (le cosiddette work unit) che il valutatore deve svolgere.

In particolare, il valutatore deve verificare che il Security Target sia:

• completo, ovvero tutte le sezioni del Security Target contengono le informazioni richieste dallo standard o dal PP/PP-configuration a cui dichiara di conformarsi;
• esaustivo, ovvero le informazioni contenuto nelle varie sezioni sono sufficienti e descritte in maniera adeguata all’obiettivo che si pone la sezione;
• consistente, ovvero le informazioni riportate nelle varie sezioni del Security Target sono corrette, logicamente correlate tra di loro quando afferiscono allo stesso ambito e rispecchiano quanto richiesto dallo standard o dal PP/PP-configuration cui si conforma.

Qualora la valutazione del Security Target fallisca, lo Sponsor o il vendor che ha richiesto la valutazione deve provvedere ad apportare i necessari cambiamenti e solo dopo l’esito positivo della classe ASE la valutazione può continuare con le altre classi di assurance.

Conclusioni

Come detto in precedenza, il Security Target è il principale documento su cui si basa una valutazione di sicurezza di un prodotto ICT ai sensi dello standard Common Criteria.

Il Security Target è strettamente correlato all’obiettivo che lo Sponsor/vendor si pone rispetto alla certificazione di sicurezza del proprio prodotto ICT. In particolare, è di fondamentale importanza per lo sponsor/vendor determinare in maniera corretta il perimetro del TOE perché questo ha un enorme influenza sulla valutazione: un TOE molto ristretto può vanificare la valutazione perché non considererebbe alcune componenti rilevanti del prodotto, mentre un TOE molto esteso potrebbe incrementare in maniera esponenziale i costi e i tempi della valutazione.

È successo in passato che prodotti simili appartenenti alla stessa categoria fossero valutati in maniera differente, in termini di perimetro di valutazione, dai diversi schemi nazionali creando confusione negli utilizzatori e consumatori di tali prodotti.

Per tale ragione, negli ultimi anni si è avuta una proliferazione dei Protection Profile che hanno come principale finalità quella di rendere confrontabili valutazioni di prodotti ICT simili e appartenenti alla stessa categoria di prodotti.

Alcuni schemi nazionali, come ad esempio il NIAP americano, richiede obbligatoriamente che le valutazioni di sicurezza dei prodotti ICT siano effettuate solo in accordo a PP da questi riconosciuti.

Tale approccio è stato in parte adottato anche per l’EUCC, nuovo schema europeo basato sui Common Criteria, il quale richiede che le valutazioni a livello “high” siano conformi a Domini Tecnici o PP riconosciuti dallo schema.

Altro aspetto rilevante è legato alla preparazione del Security Target. Predisporre un buon Security Target richiede, oltre ad un’approfondita conoscenza del prodotto di solito disponibile presso i vendor, anche una conoscenza molto elevata dello standard Common Criteria e, in particolare, dei controlli richiesti dalla CEM.

Per tale ragione, i vendor richiedono di solito la consulenza dei valutatori dei laboratori CC per predisporre il Security Target del proprio prodotto. Va osservato però che in questo caso i valutatori che hanno fornito consulenza non possono essere poi coinvolti nella valutazione in quanto deve essere garantito il principio di imparzialità.

Tale principio è richiesto dallo Standard ISO 17025 con cui vengono accreditati i laboratori e non tutte le Autorità nazionali adottano lo stesso approccio. Alcune infatti sono molto stringenti e vietano alla società cui appartiene il laboratorio di effettuare consulenza sui prodotti che poi valutano, mentre altre sono più flessibili e chiedono solo che sia dimostrato che i valutatori coinvolti nella valutazione non hanno effettuato alcuna attività di consulenza presso il vendor. I laboratori devono pertanto dimostrare che il principio di proporzionalità non è stato leso producendo anche un’analisi del rischio su tale aspetto.