Sicurezza CC dei prodotti ICT: cos’è e perché è importante il calcolo del potenziale di attacco

Uno degli aspetti più importanti per i vendor di prodotti ICT è eliminare dai propri prodotti le vulnerabilità che possono essere sfruttate da un hacker per portare un attacco al prodotto.

In tale ambito, lo standard Common Criteria (in seguito indicato come CC) utilizzato per le valutazioni della sicurezza dei prodotti ha predisposto una metodologia (la Common Evaluation Methodology – CEM) per esaminare le funzionalità di sicurezza del prodotto ICT oggetto di valutazione e garantire che il prodotto non sia affetto da alcuna vulnerabilità che possa essere sfruttata per perpetuare un attacco verso di esso.

Esaminiamo il processo e le metodologie che i valutatori seguono quando conducono una valutazione delle vulnerabilità ai sensi dello standard Common Criteria.

Va ricordato che la fase di valutazione delle vulnerabilità (detta Assurance Vulnerability Analysis Class – AVA) nell’ambito delle valutazioni di sicurezza CC è condotta in maniera indipendente da valutatori accreditati.

Cosa è il Vulnerability Assessment in ambito valutazioni CC

In una valutazione di sicurezza CC di un prodotto ICT, il valutatore esamina il prodotto e la documentazione a corredo al fine di valutare se le funzionalità di sicurezza sono state correttamente implementate e se il prodotto presenta o meno delle vulnerabilità.

Come è noto, nel mercato esistono diverse servizi per l’analisi delle vulnerabilità di un prodotto ICT e le metodologie e la qualità dei risultati variano a seconda del fornitore che eroga il servizio. Nei CC, invece, la metodologia di valutazione è stata stabilita in modo tale che i risultati ottenuti siano gli stessi e siano indipendenti dal valutatore che ha effettuato l’analisi nell’ambito dello schema nazionale presso il quale è accreditato.

Pertanto, la valutazione della vulnerabilità in ambito valutazioni CC presenta alcune differenze significative rispetto ai tipici servizi di vulnerability assessment:

• Documentazione a corredo del prodotto: nei tipici servizi di vulnerability assessment, i test sono generalmente “black box”, ovvero sono condotti principalmente sulla base delle informazioni già note sulle vulnerabilità, ma non conoscendo il prodotto e come esso è implementato. Nelle valutazioni CC, invece, il valutatore, in aggiunta alle informazioni sulle vulnerabilità note, esamina la documentazione fornita dal vendor (es. Security Target, documenti di design, guide utente, guide di configurazione, architettura di sicurezza,..), prima di selezionare le vulnerabilità che i prodotti potrebbero avere, per poi confermarle eventualmente durante i test. La documentazione che il vendor deve presentare al valutatore è definita specifica dallo standard ed è incrementale sulla base dei livelli (maggiore è il livello, più documentazione dovrà essere fornita dal vendor). A titolo esemplificativo, in una valutazione EAL1 sono richiesti solo il security target, le specifiche funzionali delle interfacce e le guide utente e di configurazione, mentre in una valutazione EAL2, oltre alla documentazione richiesta al livello EAL1, viene richiesto in aggiunta anche la descrizione dell’architettura del prodotto e il documento di design del prodotto. Per i livelli da EAL4 in su, viene richiesta anche la disponibilità dei codici sorgente.
• Potenziale di attacco richiesto: come è noto, le valutazioni di sicurezza CC dei prodotti CC sono chiamate “attack based”, ovvero valutano il grado di resistenza delle funzionalità di sicurezza del prodotto verso gli attacchi noti sulla base di come il prodotto è utilizzato. Per tale ragione, l’analisi che il valutatore effettua sulle vulnerabilità riscontrate sul prodotto tiene conto della “difficoltà” che le vulnerabilità siano sfruttate per attacchi reali e tiene conto anche dei requisiti che sono richiesti per il personale addetto alla gestione del prodotto. Più specificamente, i CC prescrivono i potenziali di attacco a cui il prodotto valutato deve essere resistente sulla base del livello (EAL) al quale viene valutato Ad esempio, anche se il prodotto valutato presenta una vulnerabilità, può superare la valutazione del CC se il potenziale di attacco richiesto a un aggressore per riuscire a sfruttarla supera il valore del potenziale di attacco definito per l’EAL al quale il prodotto viene valutato. Questo certifica che il prodotto è resistente agli attacchi che possono essere sferrati con il potenziale indicato.
• L’ambiente operativo: nei CC vengono prese in considerazione le ipotesi relative all’ambiente operativo dove opera il prodotto oggetto di valutazione (queste ipotesi sono specificate nel Security Target della valutazione). Ad esempio, anche se il prodotto valutato presenta un problema che può essere tecnicamente considerato una vulnerabilità, il prodotto può superare la valutazione CC a condizione che gli attacchi che sfruttano il problema possano essere evitati mediante misure conformi alle ipotesi specificate.
• Limitazioni nelle vulnerabilità: nei CC, per vulnerabilità si intende la compromissione delle funzionalità di sicurezza del prodotto in valutazione (anche queste sono specificate nel Security Target della valutazione). Ad esempio, anche se il prodotto valutato presenta un problema che può causare un denial-of-service, il problema non sarà considerato una vulnerabilità nella valutazione CC, purché non comprometta le funzionalità di sicurezza specificate nel Security Target.

Le fasi del processo di Vulnerability Assessment nelle valutazioni CC

La figura riportata qui di seguito mostra le fasi del processo di vulnerability assessment nell’ambito di una valutazione CC.

Le attività componenti le varie fasi del processo di vulnerability assessment sono le seguenti:

• Identificazione Aree di Interesse: per “area di interesse” si intende una o più componenti del prodotto dove il valutatore riconosce la necessità di indagare in dettaglio, soprattutto sulla progettazione e sviluppo delle stesse, in quanto possono essere presenti delle vulnerabilità. Il valutatore esamina la documentazione fornita dal vendor per identificare le potenziali operazioni in cui possono verificarsi problemi di sicurezza da cui derivare le “aree di interesse” citate prima per successive analisi sulle potenziali vulnerabilità esistenti.
• Ricerca Vulnerabilità: questa è la fase cruciale del processo di vulnerability assessment nelle valutazioni CC perché la principale finalità di identificare tutte le vulnerabilità potenzialmente applicabili al prodotto e verificare se il prodotto ne è affetto o no. La prima fase della ricerca è l’identificazione delle vulnerabilità di pubblico dominio note globalmente e individuabili con motori di ricerca su internet. Tra le principali sorgenti di informazione utilizzate ci sono i Common Vulnerabilities and Exposures (CVE) database contenenti tutte le vulnerabilità (pubblicate) trovate all’interno dei prodotti analizzati in passato. I criteri con cui vengono ricercate le vulnerabilità di pubblico dominio sono definiti dalla CEM e illustrati in dettaglio più avanti. La seconda fase della ricerca delle vulnerabilità è effettuata analizzando la documentazione fornita dal vendor indagando in particolare nelle aree di interesse identificate al punto precedente. Anche in questo caso, la CEM fornisce delle indicazioni che il valutatore deve seguire.
• Applicazione delle Assunzioni: il valutatore determina l’applicabilità delle vulnerabilità individuate tenendo in considerazione le assunzioni dell’ambiente operativo (OE). L’ambiente operativo rappresenta tutto ciò che circonda la parte del prodotto in valutazione (detto Target of Evaluation – TOE). Le vulnerabilità che non si verificheranno nell’ambiente operativo in cui sono soddisfatte le assunzioni descritte nel Security target sono escluse dall’obiettivo dell’analisi, anche se tecnicamente potrebbero esistere nel prodotto. Il resto delle vulnerabilità diventa l’obiettivo dell’analisi successiva.
• Pianificazione Scenari di Attacco e Calcolo Potenziale d’Attacco: per le vulnerabilità identificate come applicabili al prodotto, il valutatore pianifica degli scenari di attacco che sfruttano tali vulnerabilità e calcola il “potenziale di attacco” dell’attaccante necessario per eseguire tali scenari di attacco. Gli scenari di attacco saranno confermati nel successivo Penetration Test. Si noti che non è necessario condurre i Penetration Test quando il potenziale di attacco richiesto per sfruttare le vulnerabilità supera il valore di riferimento prescritto per ciascuno dei livelli (EAL) definiti.
• Penetration Testing: il valutatore effettua penetration testing sul prodotto sulla base degli scenari d’attacco pianificati. In questo modo viene determinato se le vulnerabilità identificate nelle fasi precedenti sono effettivamente presenti nel prodotto.
• Verdetto Positivo/Negativo: il prodotto supererà la valutazione Common Criteria quando esso non registra vulnerabilità applicabili sotto le assunzioni dell’ambiente operativo (OE) o quando il penetration testing fallisce. Il successo del penetration test sul prodotto valutato implica che le vulnerabilità ipotizzate sono presenti sul prodotto. Il superamento o il fallimento della valutazione CC in questo caso sarà determinato dal confronto tra il valore del “potenziale di attacco” richiesto per sfruttare le vulnerabilità e il valore di riferimento prescritto per il livello di valutazione (EAL) al quale si effettua la valutazione. Il valutatore ricalcola il valore del potenziale d’attacco alla luce dell’effort necessario per effettuare il penetration test ed emette il verdetto (pass o fail) sulla base delle considerazioni espresse sopra.

Cosa è il potenziale di attacco, come si calcola e come si usa

Il potenziale di attacco è un valore numerico che esprime il potenziale che un attaccante dovrebbe avere per realizzare uno scenario d’attacco sfruttando una vulnerabilità nota. Il potenziale di attacco è un valore numerico espresso come la somma dei fattori indicati in tabella valorizzati numericamente con i criteri indicati sempre in tabella.

I dettagli su come calcolare il potenziale di attacco sono indicati nella CEM all’Annex B.4 Calculating attack potential.

Ad ogni livello di assurance (EAL) è associato il potenziale di attacco degli attacchi ai quali il prodotto valutato deve essere resistente.

In particolare:

• Per i livelli da EAL 1 a EAL3, il potenziale d’attacco è “basic”, ovvero valori da 0 a 9;
• Per il livello EAL 4, il potenziale d’attacco è “enhanced-basic”, ovvero valori da 10 a 13;
• Per il livello EAL 5, il potenziale d’attacco è “moderate”, ovvero valori da 14 a 19;
• Per i livelli EAL 6 e EAL7, il potenziale d’attacco è “high”, ovvero valori superiori 20.

Il verdetto di pass/fail della valutazione della vulnerabilità in ambito CC viene determinato confrontando il potenziale di attacco richiesto per sfruttare le vulnerabilità rilevate nella valutazione CC con il valore di riferimento prescritto per ciascuno degli EAL.

In pratica.

• quando il potenziale di attacco richiesto per lo sfruttamento della vulnerabilità supera il valore di riferimento dell’EAL, significa che è difficile per gli aggressori riuscire ad attaccare sfruttando quella vulnerabilità. Pertanto, anche quando tali vulnerabilità vengono rilevate in un prodotto, il prodotto può superare la valutazione CC nonostante l’esistenza delle vulnerabilità nel prodotto, perché il valore di riferimento a cui il prodotto deve essere resistente è stato soddisfatto (verdetto PASS). In questo caso, le vulnerabilità vengono considerate residue.
• Quando il potenziale di attacco richiesto per lo sfruttamento delle vulnerabilità è inferiore al valore di riferimento, significa che è facile riuscire a portare a termine gli attacchi. Se in un prodotto vengono rilevate tali vulnerabilità, il prodotto non supera la valutazione CC, perché il valore di riferimento a cui il prodotto deve essere resistente non è stato soddisfatto (verdetto FAIL).

Nel calcolo del potenziale di attacco, il valutatore deve considerare e valutare i seguenti aspetti:

• disponibilità di informazioni e strumenti di attacco: la difficoltà o facilità di riuscita di un attacco varia in modo significativo a seconda che le informazioni sugli strumenti di attacco e i metodi e le procedure concrete per sfruttare le vulnerabilità siano disponibili o meno su Internet, indipendentemente dal fatto che lo strumento stesso utilizzi un metodo sofisticato o meno. Pertanto, il valutatore deve calcolare il potenziale di attacco dopo aver controllato accuratamente la disponibilità di informazioni pubbliche e di strumenti di attacco su Internet applicabili al prodotto.
• Valutazione di più scenari di attacco per una singola vulnerabilità: quando esistono più metodi di attacco per sfruttare una vulnerabilità, il valore del potenziale di attacco varia perché i pesi assegnati a ciascuno dei fattori del potenziale di attacco sono diversi a seconda degli scenari di attacco utilizzati. Pertanto, il valutatore deve calcolare i potenziali di attacco richiesti per l’esecuzione di ciascuno degli scenari di attacco identificati (ovvero tutti gli scenari che sfruttano la vulnerabilità) e determinare un verdetto di Pass/Fail solo se il prodotto valutato ha la resistenza richiesta verso tutti gli scenari di attacco considerati.
• Utilizzo di informazioni aggiornate: il potenziale di attacco richiesto per sfruttare le vulnerabilità può variare nel tempo. Ad esempio, il potenziale di attacco richiesto diminuirà quando “il miglioramento delle prestazioni dell’hardware ha ridotto il tempo necessario per l’attacco” o quando “è stato reso disponibile un nuovo strumento di attacco”. Pertanto, anche se il valutatore ha già avuto un’esperienza di valutazione simile in passato, deve condurre una valutazione sulla base di informazioni aggiornate al momento della valutazione, piuttosto che sulla base dell’esperienza passata.

Criteri per effettuare una efficace ricerca delle vulnerabilità

Come indicato in precedenza, l’obiettivo finale di una valutazione CC è garantire che il prodotto valutato non presenti vulnerabilità che possano essere sfruttate alla data della valutazione.

A tal fine, lo standard e la metodologia richiedono di effettuare i seguenti metodi di ricerca delle vulnerabilità:

• ricerca di vulnerabilità di pubblico dominio: il valutatore deve cercare le vulnerabilità generalmente note sulla base dell’area del prodotto e delle “aree di interesse” identificate.
• Ricerca delle vulnerabilità attraverso l’analisi della documentazione del prodotto: il valutatore deve analizzare le informazioni sulla progettazione del prodotto al fine di ipotizzare le possibili vulnerabilità che possono afferire al prodotto. Con questo metodo il valutatore può rilevare non solo le vulnerabilità già conosciute, ma anche quelle che dipendono dalla progettazione o dall’implementazione specifica del prodotto. In quest’ambito è anche inclusa, per i livelli dall’EAL4 in su, anche l’analisi del codice sorgente del prodotto.

Relativamente al primo metodo di ricerca (vulnerabilità pubbliche) lo standard CC e la metodologia CEM forniscono delle linee guida precise su come effettuare la ricerca in modo da avere un insieme di vulnerabilità il più possibile completo.

A titolo esemplificativo e non esaustivo, i principali suggerimenti dati sono:

• utilizzare per la ricerca il maggior numero di fonti quali i principali motori di ricerca su internet, i siti dei vendor dove sono indicate le vulnerabilità sui propri prodotti, i siti dove vengono indicate le principali vulnerabilità indipendentemente dai prodotti, i siti utilizzati dagli hacker e così via;
• cercare le vulnerabilità utilizzando delle parole chiave che sono inerenti all’area di mercato dove appartiene il prodotto, alla tipologia del prodotto, a prodotti simili, a prodotti che sono inclusi/utilizzati nel prodotto stesso, alla tecnologia utilizzata e così via;
• cercare vulnerabilità nelle “aree di interesse” che il valutatore ha identificato analizzando la documentazione del prodotto.

Per aumentare l’affidabilità delle sue ricerche, il valutatore dovrebbe ripetere più volte la ricerca affinando le parole chiave con cui effettua le ricerche sulla base dei risultati delle ricerche effettuate al fine di avere ricerche più mirate e risultati più specifici e affidabili.

Per quando riguarda la ricerca delle vulnerabilità attraverso l’analisi della documentazione del prodotto, il valutatore deve seguire quanto indicato dalla CEM nell’Annex B.2.1 Generic vulnerability guidance.

In pratica, dall’analisi della documentazione fornita dal vendor, il valutatore dovrebbe verificare quanto segue:

• se un attaccante può bypassare le funzionalità di sicurezza o accedere a dei dati confidenziali (Bypassing);
• se un attaccante può eseguire un’elaborazione non prevista in origine o sospendere le funzioni di sicurezza modificando i codici eseguibili o i dati delle funzioni di sicurezza (Tampering);
• se un attaccante attacca direttamente un meccanismo di autenticazione della password, ad esempio con tentativi ripetuti o un metodo simile (Direct Attacks);
• se un attaccante monitora i comportamenti del prodotto o i dati trasmessi e ricevuti per ottenere informazioni riservate protette dal prodotto (Monitoring);
• se gli utenti non possono gestire o utilizzare il prodotto in modo sicuro perché la guida utente del prodotto non è descritta correttamente o richiede una gestione operativa significativamente onerosa per mantenere la sicurezza (Misuse).

Inoltre, per valutazioni di livello EAL 2 o superiori, il valutatore deve analizzare tra la documentazione fornita dal vendor anche l’architettura di sicurezza la quale descrive come le funzioni di sicurezza del un prodotto possono essere protette per evitare che siano aggirate o manomesse. Queste informazioni sono molto importanti per identificare le potenziali vulnerabilità applicabili al prodotto.

L’analisi del codice sorgente, richiesta per le valutazioni dal livello EAL4 in su, usa la stessa logica della ricerca delle vulnerabilità basta sull’analisi della documentazione del prodotto.

In pratica, il valutatore analizza il codice sorgente del prodotto andando a verificare aspetti di rilievo presenti nel codice, quali, a titolo esemplificativo:

• i dati e le elaborazioni dai quali dipendono le funzionalità di sicurezza;
• l’applicabilità di vulnerabilità del software note (es. Buffer overflow, Integer overflow, Unauthorized use of memory, Race condition, …);
• vulnerabilità connesse al compilatore (es. il compilatore potrebbe generare un codice diverso da quello predisposto dallo sviluppatore);
• funzioni o opzioni nascoste che non sono descritte nei documenti di progettazione o nei manuali utente;
• parti del codice sorgente complicati e difficili da capire. In questi casi, il valutatore può ipotizzare che ci sono delle vulnerabilità difficili da comprendere solo con un’analisi del codice e quindi prevedere dei test specifici.

Una volta identificate le vulnerabilità che potenzialmente sono applicabili al prodotto in valutazione, il valutatore verifica che il prodotto ne sia esente attraverso delle attività di Penetration Testing mirate.

Conclusioni

L’analisi delle vulnerabilità nell’ambito delle valutazioni Common Criteria è una fase molto articolata e rigorosa in quanto deve certificare che il prodotto, al momento della certificazione, sia esente da vulnerabilità note.

È di fatto una metodologia “white-box” in quanto il valutatore ha a disposizione tutta la documentazione del prodotto, incluso il codice sorgente per valutazioni di livello alto.

La metodologia CEM è molto dettagliata e rigorosa e richiede che i valutatori limitino al massimo le “considerazioni soggettive” e documentino con evidenze esaustive l’analisi fatta in modo che la valutazione sia oggettiva e ripetibile, ovvero se effettuata da altro valutatore, deve riproporre gli stessi risultati.

In tale ambito, la valutazione del potenziale di attacco riveste un’importanza cruciale perché consente di non bloccare la certificazione del prodotto quando si riscontra una vulnerabilità con potenziale di attacco superiore a quello richiesto dal livello al quale viene effettuata la valutazione.

Ovviamente i vendor non amano molto avere indicazione sul certificato che esistono delle vulnerabilità sul prodotto, anche se valutate residue.

D’altro canto, però, la risoluzione della vulnerabilità potrebbe comportare il cambio della release del prodotto e quindi l’obbligo di ripetere tutto il processo di valutazione allungando in maniera significativa i tempi e aumentando i costi della valutazione.