ISO IEC 15408 e Penetration Test per Verifica Sicurezza TOE

ISO/IEC 15408 (Common Criteria for Information Technology Security Evaluation) definisce come valutare in modo formale un prodotto o sistema IT attraverso il suo TOE (Target of Evaluation), il Security Target, i SFR (Security Functional Requirements) e i SAR (Security Assurance Requirements). Quando il prodotto viene distribuito, integrato, esposto via API o inserito in ambienti reali, la domanda non è solo se esista una certificazione: è se il comportamento concreto del sistema resti coerente con le promesse di sicurezza dichiarate.

Se scope, evidenze, remediation o retest non sono allineati al contesto dello standard, il valore dell’assurance formale si riduce e la fiducia di buyer, auditor e integratori ne risente direttamente.

In breve: Common Criteria e verifica tecnica reale

Il valore di una valutazione Common Criteria dipende dal fatto che il TOE sia definito bene, configurato correttamente e governato anche dopo la valutazione. Quando il perimetro include interfacce amministrative, API, moduli software, integrazioni, firmware o ambienti operativi complessi, il penetration test aiuta a verificare se le ipotesi dichiarate nel Security Target tengano davvero. Il suo contributo cresce quando collega finding tecnici, impatto sul TOE e rischio residuo fuori o dentro lo scope valutato.

A chi è utile questa guida

Il contenuto è rilevante per Product Security Manager, CISO, CTO, IT Manager e Compliance Manager; per team che devono collegare evaluation evidence e rischio tecnico reale; per vendor di prodotti security, appliance, software critico, embedded e piattaforme enterprise; per organizzazioni che affrontano audit, qualifiche cliente, procurement o vendor assessment.

Perché ISO/IEC 15408 conta anche sul piano tecnico

In un percorso ISO/IEC 15408, il rischio tecnico può incidere direttamente su elementi come:

• Definizione reale del TOE e confini tra componenti valutati e non valutati;
• Implementazione concreta dei SFR dichiarati nel Security Target;
• Ipotesi ambientali e dipendenze esterne su cui si regge la valutazione;
• Interfacce di amministrazione, aggiornamento, logica applicativa e canali di comunicazione;
• Differenza tra configurazione valutata in laboratorio e deployment reale presso cliente o integratore.

Per questo, anche se lo standard non equivale a un penetration test, una verifica offensiva mirata diventa spesso la prova più utile per capire se l’assurance formale regga anche nel mondo reale.

Dove il penetration test crea valore nel contesto Common Criteria

Il penetration test è utile soprattutto quando bisogna dimostrare che:

• Il perimetro esposto non presenti vulnerabilità facilmente sfruttabili;
• Ruoli, autorizzazioni e accessi non creino condizioni incompatibili con il Security Target;
• Applicazioni, API e componenti digitali reggano a scenari di abuso realistici;
• Remediation e retest producano una prova leggibile anche da auditor, buyer o management.

Nei test su prodotti in percorso ISO/IEC 15408, i finding più ricorrenti riguardano componenti fuori dal TOE formale che interagiscono con il prodotto e introducono rischi non considerati nell’evaluation, Security Functional Requirements non implementati coerentemente in tutti gli ambienti di deployment e assunzioni sull’ambiente operativo (Operational Environment Assumptions) che non reggono nella configurazione reale del cliente.

Cosa vogliono vedere buyer, auditor e stakeholder

Chi valuta un servizio o un processo legato a ISO/IEC 15408 tende a voler capire quale parte del prodotto rientri davvero nel TOE, quali vulnerabilità emergano dentro o appena fuori i confini valutati, come i finding impattino SFR, deployment assumptions e rischio residuo, come siano state prioritarizzate le correzioni e se esista un retest che confermi la chiusura delle criticità più rilevanti.

Mappatura tra aree di verifica, evidenze e attività

Area da validare	Evidenza utile	Attività ISGroup più adatta	Output atteso
Superficie applicativa	Vulnerabilità sfruttabili e impatto	Web Application Penetration Testing	Executive summary, finding, remediation
Confini del TOE, integrazioni e logiche di sicurezza	Abuse case, trust gap, errori di segregazione	Secure Architecture Review	Dettaglio tecnico e priorità
Rete o infrastruttura esposta	Pivoting, esposizione, hardening debole	Network Penetration Testing	Report tecnico e rischio operativo
Continuità e miglioramento	Roadmap, remediation, coordinamento	Virtual CISO	Piano di miglioramento e retest

Caso d’uso realistico

Uno scenario tipico è quello del vendor che dispone di documentazione Common Criteria o di un percorso di valutazione già impostato, ma deve rispondere a domande molto concrete da parte di cliente, integratore o assessor: qual è il vero TOE nel deployment? Le interfacce amministrative fuori scope possono essere usate per aggirare i controlli? Un’integrazione API indebolisce le ipotesi dichiarate? In quel momento il penetration test diventa utile per trasformare l’assurance formale in evidenza tecnica concreta. Un esempio applicato è il Web Application Penetration Test e Network Penetration Test per Coop Italia, che mostra come ISGroup traduca verifica tecnica, remediation e fiducia del cliente in un risultato leggibile anche fuori dal team security.

Errori comuni da evitare

• Pensare che lo standard renda opzionale la validazione tecnica;
• Confondere certificazione Common Criteria e sicurezza operativa continua;
• Limitare lo scope a un solo componente quando il deployment reale è più ampio;
• Produrre un report tecnico senza collegarlo a TOE, SFR e assunzioni ambientali;
• Chiudere l’attività senza retest.

Domande frequenti su ISO/IEC 15408 e penetration test

• ISO/IEC 15408 richiede obbligatoriamente un penetration test?
• Non sempre in modo letterale. Quando però il TOE o il suo deployment reale dipendono da applicazioni, API, interfacce amministrative o componenti esposti, il penetration test diventa una delle prove tecniche più utili per dimostrare l’efficacia dei controlli dichiarati nel Security Target.
• Qual è la differenza tra penetration test, vulnerability assessment e assessment architetturale?
• Il vulnerability assessment individua vulnerabilità note. Il penetration test ne verifica sfruttabilità e impatto reale. Un assessment architetturale analizza invece confini del TOE, trust boundary, deployment assumptions e coerenza dei controlli nel prodotto reale.
• Quali evidenze sono riusabili in audit o vendor assessment?
• Executive summary, scope chiaro, finding con severità, correlazione col rischio, remediation plan e retest sono i blocchi più utili da riusare in contesti decisionali.

Per collegare ISO/IEC 15408 a evidenze tecniche davvero spendibili, il primo passo utile è chiarire cosa rientri davvero nel TOE e quali superfici operative ne influenzino la sicurezza reale. È possibile partire da una Secure Architecture Review, affiancare Web Application Penetration Testing o Network Penetration Testing e coinvolgere un Virtual CISO per trasformare il lavoro in un percorso verificabile e convincente per buyer e auditor.

Approfondimenti correlati

• Per capire quando il penetration test serve davvero nel contesto ISO/IEC 15408, è disponibile l’approfondimento su quando il penetration test conta davvero;
• Per audit, vendor assessment e fiducia del buyer, è utile la guida sulle evidenze utili per audit e vendor assessment;
• Per scope, deliverable e retest, è disponibile la guida pratica su scope, deliverable e retest.