ISO/IEC 15408: scope, deliverable e retest per Common Criteria

Per un percorso legato a ISO/IEC 15408 (Common Criteria for Information Technology Security Evaluation), il penetration test deve essere progettato per generare evidenze leggibili in chiave di assurance: scope coerente con il TOE, priorità chiare, output riusabili in audit e retest collegato alle criticità che contano davvero per SFR, deployment e rischio residuo.

Senza questo allineamento, il test non aiuta il team di valutazione a collegare i finding agli EAL dichiarati né a produrre evidenze spendibili per lo scheme di certificazione Common Criteria.

In breve: cosa serve per un test utile a Common Criteria

Per rendere il penetration test davvero utile a ISO/IEC 15408, occorre definire uno scope realistico, collegare i finding al rischio di business e di assurance, pretendere deliverable riutilizzabili e chiudere il ciclo con remediation e retest. Senza questo allineamento, il test non aiuta il team di valutazione a collegare i finding agli EAL dichiarati né a produrre evidenze spendibili per lo scheme di certificazione.

Problemi pratici che questa guida aiuta a risolvere

Questa guida è utile per chi deve:

• Definire uno scope coerente con il TOE (Target of Evaluation), i Security Objectives e il livello di assurance richiesto;
• Capire quali deliverable servono davvero a management, auditor e buyer;
• Evitare report tecnici poco riusabili;
• Collegare remediation e retest a evidenze davvero spendibili.

Checklist di preparazione al test

• Inventario aggiornato dei componenti TOE, interfacce e funzioni di sicurezza in scope per la valutazione Common Criteria;
• Chiara delimitazione tra TOE, componenti fuori scope e dipendenze ambientali;
• Owner tecnici e referenti di business;
• Ambienti inclusi ed esclusi;
• Mappa ruoli, profili e privilegi;
• Endpoint e integrazioni rilevanti;
• Configurazione reale del prodotto nel deployment target;
• Finestre temporali e vincoli operativi;
• Criteri di severità condivisi;
• Percorso di remediation e retest già previsto.

Deliverable attesi

Output atteso	Perché serve	Chi lo usa
Executive summary	Sintetizza rischio e priorità	Direzione, compliance, buyer
Dettaglio tecnico	Consente riproduzione e correzione	Team IT, Dev, Sec
Evidenza di sfruttabilità	Mostra che il rischio è concreto	Auditor, buyer, security lead
Remediation plan	Ordina tempi e priorità	Owner tecnici e management
Retest	Conferma la chiusura delle criticità	Auditor, clienti, governance

Report utile vs. report debole

Report utile	Report debole
Collega finding e rischio di business o di assurance	Elenca vulnerabilità senza contesto
Distingue cosa è stato testato e cosa no	Scope ambiguo o incompleto
Dà priorità di remediation allineata agli EAL e ai Security Objectives del TOE	Lascia solo output tecnici senza collegamento all’assurance richiesta
Include retest o percorso di chiusura	Non verifica le correzioni
È leggibile da evaluation team, auditor e scheme di certificazione	Resta confinato al team tecnico senza collegamento ai requisiti Common Criteria

Errori comuni da evitare

• Scope costruito su un solo componente quando il servizio reale è più ampio;
• Esclusione di API, ruoli privilegiati o integrazioni rilevanti;
• Nessun legame esplicito con TOE, SFR o deployment reale;
• Assenza di executive summary;
• Finding scollegati dal rischio di business o di assurance;
• Remediation non tracciata;
• Nessun retest finale.

Come ISGroup struttura il percorso

ISGroup può strutturare un percorso più efficace combinando Secure Architecture Review, Web Application Penetration Testing, Network Penetration Testing ed eventualmente Virtual CISO, in modo da produrre evidenze spendibili per lo scheme di certificazione Common Criteria e leggibili da evaluation team e auditor che verificano EAL e Security Objectives.

Domande frequenti su ISO/IEC 15408 e penetration test

• Cosa deve contenere un report utile anche per il management?
• Per un prodotto in percorso di valutazione ISO/IEC 15408, il management deve vedere quali Security Function del TOE sono state verificate in relazione agli SFR dichiarati nel Security Target, quali finding mostrano dove le security function non reggono sotto pressione tecnica, e se le correzioni sono state chiuse. Il report deve essere riusabile nel dossier di valutazione Common Criteria.
• Quanto conta il retest in un percorso Common Criteria?
• In Common Criteria le correzioni al TOE generano una nuova versione che deve essere rivalutata. Il retest verifica che le security function del TOE corretto mantengano il comportamento dichiarato nel Security Target e che l’EAL di partenza sia ancora sostenibile dopo la modifica.
• Un vulnerability assessment può sostituire questo tipo di test?
• No. Common Criteria richiede che le vulnerabilità siano valutate in relazione agli SFR e al contesto operativo del TOE. Un VA identifica vulnerabilità generiche; un penetration test CC-oriented verifica se quelle vulnerabilità compromettono una Security Function specifica dichiarata nel Security Target, producendo evidenze che un evaluator ITSEF può includere nel dossier di valutazione.

Per evitare un penetration test generico e ottenere evidenze davvero utili per ISO/IEC 15408, il primo passo è definire scope, deliverable e percorso di retest. Il percorso può partire da una Secure Architecture Review, proseguire con Web Application Penetration Testing e Network Penetration Testing, e usare il Virtual CISO per trasformare il lavoro in un presidio più continuativo.

Approfondimenti correlati

• La guida principale su ISO/IEC 15408 e penetration test offre il quadro completo dello standard e del suo rapporto con i test di sicurezza;
• L’articolo su quando il penetration test conta davvero per Common Criteria aiuta a capire in quali fasi del ciclo di valutazione il test produce valore reale;
• La sezione su evidenze utili per audit e vendor assessment secondo ISO/IEC 15408 completa il quadro con il punto di vista di auditor e acquirenti.