EAD: scope, deliverable e retest per un penetration test utile

Per un penetration test davvero utile su sistemi EAD (Encoded Archival Description), lo scope deve seguire il modello operativo dell’archivio: finding aid, metadati, API di aggiornamento e workflow di accesso controllato.

Se scope, deliverable e retest restano generici, il test produce poco valore per integrità, continuità e fiducia nell’accesso strutturato alle descrizioni archivistiche.

Cosa conta davvero per EAD

Per rendere il penetration test utile su piattaforme EAD, lo scope va costruito attorno ai componenti che gestiscono finding aid, metadati, workflow di aggiornamento e integrazioni. I deliverable devono collegare i finding a integrità e disponibilità del servizio; remediation e retest chiudono il ciclo e producono evidenze utili per audit e governance.

Problemi pratici che questa guida aiuta a risolvere

Questa guida è utile quando occorre:

• Decidere quali componenti includere davvero nello scope;
• Evitare test superficiali concentrati solo sul front-end pubblico;
• Produrre output utili anche a management, audit e stakeholder esterni;
• Usare remediation e retest per rafforzare la fiducia nel servizio.

Checklist di preparazione

• Inventario di portali, API, pannelli amministrativi e backend coinvolti;
• Mappa dei ruoli che possono modificare finding aid e descrizioni;
• Integrazioni con sistemi esterni e dipendenze critiche documentate;
• Ambienti inclusi ed esclusi chiariti;
• Criteri di severità allineati a impatto su integrità e continuità;
• Owner tecnici e referenti di processo identificati;
• Piano di remediation e retest definito in anticipo.

Deliverable attesi

Output atteso	Perché serve	Chi lo usa
Executive summary	Rende leggibile il rischio per management e audit	Direzione, compliance, buyer
Scope dettagliato	Chiarisce cosa è stato verificato davvero	Auditor, security, stakeholder
Finding con impatto sul servizio	Collega vulnerabilità e fiducia nell’accesso archivistico	IT, engineering, governance
Piano di remediation	Ordina priorità, owner e tempi	Owner tecnici e management
Retest	Conferma la chiusura delle criticità rilevanti	Auditor, clienti, governance

Report utile e report debole a confronto

Report utile	Report debole
Include API, backend e funzioni di amministrazione	Si limita al solo sito pubblico
Collega finding a integrità e disponibilità delle descrizioni	Elenca problemi senza contesto
Spiega cosa è stato testato e cosa no	Lascia lo scope ambiguo
Aiuta a decidere remediation e priorità	Non orienta l’azione
Include retest	Si ferma alla prima fotografia

Errori comuni da evitare

• Escludere le API o i pannelli che gestiscono gli aggiornamenti EAD;
• Non coinvolgere chi conosce workflow e integrazioni reali;
• Parlare solo di vulnerabilità senza collegare impatto su fiducia e accesso;
• Produrre deliverable troppo tecnici per chi deve decidere;
• Saltare il retest e considerare il lavoro chiuso troppo presto.

Domande frequenti su EAD e penetration test

• Cosa deve contenere un report utile anche per il management?
• Per un archivio che usa EAD, il management deve vedere quali portali di ricerca, sistemi di gestione degli strumenti di ricerca e API di esposizione dei metadati archivistici sono stati testati, quali finding possono esporre inventari riservati o documenti non ancora pubblicati, e se le correzioni sono state chiuse. Un report che non distingue tra fondi pubblici e fondi con accesso controllato non è utile al responsabile dell’archivio.
• Quanto conta il retest in un percorso legato a EAD?
• Conta perché gli archivi hanno obblighi di accesso controllato su fondi sensibili — per motivi legali, di riservatezza o di tutela del patrimonio culturale. Il retest verifica che le restrizioni di accesso reimpostate dopo le correzioni reggano davvero, non solo che la patch sia stata applicata.
• Un vulnerability assessment può sostituire questo tipo di test?
• No. Un VA identifica le superfici vulnerabili ma non verifica se un utente può accedere a fondi ad accesso limitato, manipolare gli strumenti di ricerca o scaricare documenti non pubblicati. Per un archivio con EAD, queste sono le verifiche che determinano se il sistema è davvero affidabile per la tutela del patrimonio documentario.

ISGroup può combinare Code Review per analizzare backend e logiche di gestione, Web Application Penetration Testing per verificare le superfici esposte e Virtual CISO per trasformare i risultati in remediation e miglioramento continuativo.

Approfondimenti correlati

• La guida principale su EAD e penetration test offre il quadro completo di compliance e metodologia;
• L’articolo su quando il penetration test conta davvero per EAD aiuta a valutare se e quando avviare il test;
• La sezione su evidenze utili per audit e vendor assessment EAD completa il percorso con indicazioni su documentazione e governance.