ISO 17789: scope, deliverable e retest per il penetration test cloud

Definire scope, deliverable e retest in modo coerente con ISO 17789 (Cloud Computing – Reference Architecture) è il passaggio che trasforma un penetration test generico in uno strumento utile per cloud architect, governance e auditor.

Senza questo allineamento, il test produce un PDF poco usabile fuori dal team tecnico: finding scollegati dall’architettura reale, nessuna evidenza spendibile in audit e un retest che non verifica le criticità che contano davvero per control plane, API e piani di servizio.

Cosa conta davvero per ISO 17789

Per rendere il penetration test davvero utile a ISO 17789, occorre definire uno scope realistico, collegare i finding al rischio di business e architetturale, pretendere deliverable riutilizzabili e chiudere il ciclo con remediation e retest. Senza questo allineamento, il test non aiuta l’architecture team a identificare i gap sull’architettura cloud né a dimostrare che i controlli reggono sulla topologia reale del servizio.

Problemi pratici che questa guida aiuta a risolvere

Questa guida è utile per:

• Definire uno scope coerente con i layer architetturali cloud e i componenti rilevanti per l’architettura di riferimento ISO 17789;
• 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

• Inventario aggiornato dei componenti architetturali cloud, interfacce e servizi in scope per ISO 17789;
• Mappa chiara di componenti funzionali, piani di servizio, ruoli e integrazioni;
• Owner tecnici e referenti di business;
• Ambienti inclusi ed esclusi;
• Mappa ruoli, profili e privilegi;
• Endpoint e integrazioni rilevanti;
• Identificazione esplicita dei trust boundary tra provider, customer e partner;
• 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
Piano di remediation	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 architetturale	Elenca vulnerabilità senza contesto
Distingue cosa è stato testato e cosa no	Scope ambiguo o incompleto
Dà priorità di remediation allineata ai layer architetturali cloud e ai componenti critici	Lascia solo output tecnici senza contesto architetturale
Include retest o percorso di chiusura	Non verifica le correzioni
È leggibile da cloud architect, governance e auditor	Resta confinato al team tecnico senza collegamento all’architettura cloud

Errori comuni

• Scope costruito su un solo componente quando il servizio reale è più ampio;
• Esclusione di API, ruoli privilegiati o integrazioni rilevanti;
• Nessun legame esplicito con componenti e trust boundary dell’architettura;
• Assenza di executive summary;
• Finding scollegati dal rischio di business o architetturale;
• Remediation non tracciata;
• Nessun retest finale.

Come interviene ISGroup

ISGroup può strutturare un percorso più efficace combinando Secure Architecture Review, Cloud Security Assessment, Web Application Penetration Testing ed eventualmente Virtual CISO, in modo da integrare il risultato nel ciclo di revisione architetturale e renderlo utile per cloud architect e governance secondo ISO 17789.

Domande frequenti su ISO 17789 e penetration test

• Cosa deve contenere un report utile anche per il management?
• Per un provider cloud che adotta il Reference Architecture ISO 17789, il management deve vedere quali componenti architetturali — portali utente, layer di orchestrazione, storage, networking — sono stati testati, quali finding mostrano dove il modello architetturale non è implementato correttamente in termini di sicurezza, e se le correzioni sono state chiuse. Il report deve aiutare l’architect a capire i gap tra design e realtà.
• Quanto conta il retest in un percorso legato a ISO 17789?
• In un’architettura cloud basata su ISO 17789, le componenti interagiscono attraverso interfacce standardizzate. Il retest verifica che le correzioni applicate a un componente non abbiano esposto interfacce adiacenti a nuovi rischi, e che il modello architetturale dichiarato corrisponda all’implementazione reale dopo ogni modifica.
• Un vulnerability assessment può sostituire questo tipo di test?
• ISO 17789 definisce le componenti funzionali e i layer dell’architettura cloud: un vulnerability assessment scansiona le superfici ma non verifica se i confini tra componenti architetturali sono rispettati, se un layer espone funzioni non previste o se l’orchestrazione è sfruttabile per escalation di privilegi tra tenant. Sono queste le verifiche che distinguono un test architetturalmente consapevole da uno generico.

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

Approfondimenti correlati

• La guida principale su ISO 17789 e penetration test offre il quadro completo di riferimento per impostare il percorso di compliance;
• L’articolo su quando il penetration test conta davvero per ISO 17789 aiuta a valutare se e quando attivare il test in relazione allo standard;
• La sezione dedicata ad audit e vendor assessment per ISO 17789 approfondisce quali evidenze produrre per audit e valutazioni di fornitori.