Dalla progettazione alla preparazione all'audit: governare i requisiti di sicurezza delle applicazioni per ISO 27001, DORA e NIS2

La tensione prima dell’audit era palpabile. Per Maria, CISO di una società fintech di medie dimensioni, l’imminente valutazione di conformità DORA sembrava meno un riesame e più una resa dei conti. Il suo team era competente, l’infrastruttura rafforzata, ma una vulnerabilità persistente continuava a tenerla sveglia la notte: l’universo ampio e caotico delle loro applicazioni.

L’ultima preoccupazione riguardava un nuovo portale di pagamento rivolto ai clienti, portato rapidamente sul mercato per rispettare gli obiettivi trimestrali. Il team di sviluppo, sotto la pressione di un modello Agile molto serrato, aveva soddisfatto tutti i requisiti funzionali. Ma quando il team di Maria eseguì una scansione preliminare, i risultati confermarono i suoi timori.

Il portale non disponeva di regole robuste per il timeout di sessione, i campi di input erano vulnerabili ad attacchi di injection di base e i messaggi di errore divulgavano informazioni sensibili sul sistema. Non si trattava di exploit zero-day sofisticati, ma di difetti fondamentali di progettazione. La causa radice era dolorosamente chiara: i requisiti di sicurezza non erano mai stati formalmente definiti, documentati o integrati negli sprint di sviluppo. Il team aveva ricevuto un mandato generico a “renderlo sicuro”, ma senza un progetto concreto la sicurezza restava un aspetto ambiguo e spesso ignorato, affrontato solo a posteriori.

Questo scenario non è isolato. Evidenzia una lacuna critica che molti CISO e responsabili della conformità devono affrontare: trasformare l’intenzione di “facciamo sicurezza” in requisiti di sicurezza delle applicazioni espliciti e testabili, allineati a standard fondamentali come ISO/IEC 27001:2022 e a normative rilevanti come NIS2, DORA e GDPR.

L’alto costo dell’ambiguità: cosa richiede davvero la conformità

Il problema di Maria nasce da un errore organizzativo frequente: trattare la sicurezza come un attributo di qualità anziché come un insieme di requisiti non negoziabili. Un requisito di sicurezza efficace è specifico, misurabile e testabile. “L’applicazione deve essere sicura” è un auspicio. “L’applicazione deve applicare il timeout di sessione dopo 15 minuti di inattività, validare tutti gli input forniti dagli utenti rispetto a un set di caratteri predefinito e cifrare tutti i dati in transito utilizzando TLS 1.3” è un requisito. Questa chiarezza è ciò che gli auditor cercano e ciò di cui gli sviluppatori hanno bisogno per realizzare software sicuro.

Senza questa chiarezza, si innesca una cascata di problemi:

• Attuazione incoerente: sviluppatori diversi interpretano “sicuro” in modo diverso, producendo un mosaico di controlli con lacune imprevedibili.
• Aumento dei costi di correzione: individuare e correggere un difetto di progettazione in produzione è esponenzialmente più costoso che affrontarlo nella fase di progettazione.
• Non conformità in audit: gli auditor individuano rapidamente l’assenza di un processo strutturato per la definizione dei requisiti di sicurezza, con conseguenti rilievi significativi.
• Rischio aziendale: ogni requisito non definito è un potenziale vettore di attacco, che espone l’organizzazione a violazioni dei dati, perdite finanziarie e danno reputazionale.

Negli standard moderni, l’aspettativa è coerente: la sicurezza deve essere definita come requisiti, fin dall’inizio, e collegata al rischio e agli obblighi di legge. Le linee guida di ISO/IEC 27002:2022 sul controllo 8.26, Requisiti di sicurezza delle applicazioni, richiedono alle organizzazioni di determinare, documentare e approvare sistematicamente i requisiti di sicurezza sulla base di una valutazione del rischio formale e dei requisiti normativi.

Questo singolo principio è il cardine di un ampio insieme di obblighi di conformità. La mappatura trasversale della conformità di Clarysec all’interno di Zenith Controls: The Cross-Compliance Guide Zenith Controls mostra come questo concetto ricorra ovunque:

• GDPR Articles 25 e 32 richiedono “protezione dei dati fin dalla progettazione” e “sicurezza del trattamento”.
• NIS2 Article 21(2)(d)-(e) pone l’accento sullo sviluppo sicuro e sulla sicurezza della catena di fornitura.
• DORA Articles 6(4), 8, 10 e 11 richiedono la gestione dei rischi ICT e la sicurezza fin dalla progettazione per le entità finanziarie.
• NIST SP 800-53 Rev.5, nei controlli SA-4 e SA-15, richiede requisiti di sicurezza dei sistemi definiti e pratiche di sviluppo sicuro.
• COBIT 2019, nei processi BAI03 e DSS05, richiede che i requisiti connessi alla sicurezza siano allineati agli obiettivi aziendali e alla conformità prima che una soluzione venga realizzata.

L’obiettivo è definire, nelle parole di Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, “che cosa significa sicurezza per le tue applicazioni, prima che venga scritta una sola riga di codice.”

Perché gli approcci tradizionali falliscono: checklist, test tardivi e sicurezza di facciata

La maggior parte delle organizzazioni svolge già qualche forma di sicurezza delle applicazioni. Il problema è che raramente è strutturata in modo da reggere a una certificazione ISO/IEC 27001:2022 o a un esame regolatorio.

I modelli di fallimento più comuni includono:

1. Checklist generiche: i team riutilizzano una “checklist di sviluppo sicuro del codice” di una pagina per ogni progetto. Non è collegata ai rischi specifici dell’applicazione, alla sensibilità dei dati o al contesto normativo. Quando un auditor chiede come la checklist si mappi sull’Article 25 del GDPR, non esiste una risposta chiara.
2. Sicurezza come gate finale: i requisiti di sicurezza non sono integrati nella progettazione o nelle user story. Compaiono alla fine come richiesta di un penetration test. Zenith Blueprint avverte che “fare affidamento su una checklist di sicurezza alla fine del progetto non funziona: quei requisiti devono modellare l’architettura, influenzare le scelte delle librerie e guidare la prioritizzazione delle funzionalità dal primo giorno.”
3. Assenza di tracciabilità dal requisito al test: può esistere un requisito per “cifrare i dati in transito”, ma non un caso di test collegato che verifichi l’applicazione della versione TLS, la validità del certificato e la robustezza delle suite crittografiche. Zenith Blueprint insiste sul fatto che le aspettative devono essere misurabili e testabili, con test di sicurezza mappati direttamente ai requisiti corrispondenti.
4. Gestione ad hoc del codice di terze parti: le applicazioni moderne sono spesso “assemblate a partire da codice interno, librerie di terze parti, API e servizi cloud-native”, come evidenziato in Zenith Blueprint. Senza requisiti espliciti per fornitori e componenti open source, il rischio della catena di fornitura resta un’area cieca ampia e non controllata.

Il risultato è una sicurezza di facciata: i documenti esistono e i test vengono eseguiti, ma quando un auditor o un’autorità di regolamentazione esamina la coerenza della catena dei requisiti, l’intero processo si sfalda.

Costruire le basi: dalla policy alla pratica

Un approccio disciplinato alla sicurezza delle applicazioni inizia da una governance chiara. La policy non è semplice burocrazia: è la fonte ufficiale della verità che abilita i team e fornisce agli auditor una chiara dichiarazione di intenti. In Clarysec progettiamo policy autorevoli e al tempo stesso pratiche.

La nostra Politica sui requisiti di sicurezza delle applicazioni Politica sui requisiti di sicurezza delle applicazioni stabilisce regole di base non negoziabili. Ad esempio, la clausola 5.2 nella sezione “Requisiti di governance” prescrive:

Tutte le applicazioni devono essere sottoposte a convalida dei requisiti di sicurezza durante la pianificazione o l’approvvigionamento, con approvazione documentata da parte del team di sicurezza applicativa.

Questa semplice prescrizione impedisce la mentalità “costruisci prima, metti in sicurezza dopo”. La policy assegna inoltre responsabilità chiare. La clausola 4.3.1 nella sezione “Ruoli e responsabilità” stabilisce che gli sviluppatori sono tenuti a:

Realizzare le applicazioni in conformità ai requisiti e agli standard di sicurezza definiti.

Questo sposta l’onere della sicurezza da un team di sicurezza separato, spesso percepito come controparte, ai creatori stessi del software. Inoltre, la policy collega tra loro i diversi domini di sicurezza. La clausola 10.2 richiama l’integrazione con altri controlli chiave:

P4 – Politica di controllo degli accessi. Definisce gli standard di gestione dell’identità e delle sessioni che devono essere applicati da tutte le applicazioni, inclusi autenticazione forte, principio del privilegio minimo e requisiti di riesame degli accessi.

Per le organizzazioni più piccole, una policy adattata come la nostra Politica sui requisiti di sicurezza delle applicazioni - PMI Politica sui requisiti di sicurezza delle applicazioni - PMI rende questi principi scalabili. Riconosce che, pur essendo i rischi simili, l’attuazione deve essere pragmatica. Entrambe le versioni mirano allo stesso risultato: assicurare che la sicurezza delle applicazioni sia pienamente integrata nel SGSI e pronta per l’audit.

Una roadmap pratica: costruire requisiti di sicurezza delle applicazioni pronti per l’audit

La policy definisce il “cosa” e il “perché”, ma sviluppatori e responsabili di progetto hanno bisogno del “come”. Una guida strutturata di attuazione è indispensabile per tradurre controlli di alto livello in azioni operative. La fase 21 di Zenith Blueprint, dedicata al controllo 8.26 di ISO/IEC 27002:2022, fornisce una metodologia chiara in sei fasi.

Esaminiamo il processo usando il portale di pagamento di Maria come esempio.

Fase 1: partire dal rischio e dal contesto normativo

Utilizzando gli esiti della valutazione del rischio allineata a ISO/IEC 27005:2024 (trattamento del rischio), si identifica innanzitutto il contesto:

• Applicazione: portale di pagamento self-service per clienti.
• Dati: dati personali identificabili, credenziali, token di pagamento.
• Giurisdizioni: UE, servizi finanziari, ospitato nel cloud.
• Normative: GDPR, DORA, PCI DSS.

Sulla base delle indicazioni per il controllo 8.26 in Zenith Controls e dei relativi standard ISO (27034-1, 27017, 27701), le categorie iniziali di requisiti devono includere identificazione e autenticazione, autorizzazione, classificazione dei dati, validazione degli input, registrazione degli eventi e protezione dei dati in transito e a riposo.

Fase 2: creare o adottare un modello di requisiti di sicurezza

Zenith Blueprint raccomanda di creare un modello standardizzato per garantire che ogni progetto risponda alle stesse domande fondamentali di sicurezza. Questo documento deve diventare parte del toolkit di avvio dei progetti.

Le sezioni minime dovrebbero includere:

• Nome dell’applicazione, proprietario e criticità.
• Categorie di dati e livelli di sensibilità.
• Obblighi normativi e contrattuali applicabili (GDPR, DORA, ecc.).
• Input sul panorama delle minacce (derivati dal controllo 5.7 Threat intelligence).
• Requisiti di sicurezza specifici per categoria (autenticazione, registrazione degli eventi, ecc.).
• Collegamenti alle user story e ai criteri di accettazione.
• Collegamenti ai casi di test (funzionali, di sicurezza, di penetrazione).
• Requisiti per fornitori e componenti di terze parti.

Fase 3: integrare i requisiti negli artefatti Agile

I requisiti di sicurezza devono essere integrati direttamente nelle user story e nei criteri di accettazione. Per l’epica “registrazione cliente” del progetto del portale di Maria, questo significa trasformare una semplice user story funzionale in una user story consapevole della sicurezza.

• User story originale: “Come nuovo utente, posso creare un account.”
• User story sicura: “Come nuovo cliente, voglio creare un account sicuro affinché le mie informazioni di pagamento siano protette.”
• Criteri di accettazione (con sicurezza integrata):
  • Il sistema deve applicare una politica di password robuste in linea con la P4 – Politica di controllo degli accessi.
  • Il sistema deve richiedere la verifica e-mail tramite link monouso prima dell’attivazione dell’account.
  • Il modulo di creazione dell’account deve essere protetto da CAPTCHA per prevenire attacchi bot.
  • Tutti i tentativi di registrazione devono essere registrati con IP sorgente e impronta del dispositivo.
  • Tutti i dati inviati tramite il modulo devono essere sanificati per prevenire cross-site scripting (XSS).

Queste non sono attività di sicurezza separate: sono parte integrante della definizione di “completato” della funzionalità.

Fase 4: collegare i requisiti ai test di sicurezza

Utilizzando il controllo 8.29 Test di sicurezza di Zenith Controls, si assicura che ogni requisito abbia un caso di test associato. Questo chiude il ciclo e fornisce evidenze verificabili in audit dell’efficacia dei controlli.

• Requisito: cifratura in transito con TLS 1.3. → Test: scansione automatizzata per verificare l’applicazione di TLS, la validità del certificato e le suite crittografiche approvate.
• Requisito: validazione degli input per prevenire SQL injection. → Test: scansioni automatizzate SAST/DAST e fuzzing manuale durante la QA.
• Requisito: timeout di sessione dopo 15 minuti di inattività. → Test: test automatizzati e manuali per confermare l’invalidazione della sessione lato server dopo 15 minuti di inattività.

Fase 5: estendere i requisiti alla catena di fornitura

Poiché il controllo ISO 8.26 è collegato alla sicurezza dei fornitori (5.19, 5.20) e allo sviluppo esternalizzato (8.30) in Zenith Controls, il processo deve considerare il codice di terze parti. Per le PMI che dipendono fortemente da librerie esterne, la clausola della Politica sui requisiti di sicurezza delle applicazioni - PMI è fondamentale:

Qualsiasi strumento di terze parti, plugin o libreria di codice esterna utilizzata in un’applicazione deve essere registrata e riesaminata annualmente per valutarne l’impatto sulla sicurezza e lo stato delle patch.

Questo requisito semplice e pragmatico impone una mentalità da software bill of materials (SBOM), che è un’aspettativa chiave in normative come NIS2. Per i fornitori principali, gli stessi requisiti di sicurezza delle applicazioni devono essere inclusi nei contratti, facendo riferimento a ISO/IEC 27036-1 (sicurezza della catena di fornitura ICT).

Fase 6: istituire un riesame periodico

Con l’evoluzione delle applicazioni, evolvono anche i rischi. Le indicazioni di Zenith Blueprint sul riesame periodico sono cruciali. Quando si integra una nuova API o si passa a un servizio cloud diverso, il contesto di rischio cambia. Questo deve attivare un riesame dei requisiti di sicurezza esistenti per assicurare che restino adeguati. Ciò si allinea a ISO/IEC 27005:2024 (trattamento continuo del rischio) e trasforma la sicurezza delle applicazioni in una pratica continua, non in un progetto una tantum.

Scomporre l’ecosistema dei controlli

Un controllo ISO non esiste mai nel vuoto. Una sicurezza efficace si basa su una rete interconnessa di misure. Il vero valore del controllo 8.26 si esprime quando se ne comprende la relazione con gli altri controlli, una prospettiva descritta in dettaglio in Zenith Controls.

Il controllo 8.26 è classificato come controllo preventivo, ma agisce come nodo centrale dell’intero processo di sviluppo sicuro, collegandosi a:

• 8.25 - Ciclo di vita dello sviluppo sicuro: è il quadro di riferimento complessivo. Il controllo 8.26 fornisce il cosa specifico (i requisiti) che deve essere integrato nel come (il processo SDLC).
• 8.27 - Architettura di sistema sicura e principi di ingegneria: i requisiti guidano le decisioni architetturali, assicurando che la sicurezza sia fondativa.
• 8.28 - Sviluppo sicuro del codice: una volta definiti i requisiti, ad esempio “prevenire SQL injection”, gli standard di sviluppo sicuro del codice forniscono agli sviluppatori le tecniche per soddisfarli.
• 8.29 - Test di sicurezza nello sviluppo e nell’accettazione: questo controllo convalida che i requisiti definiti in 8.26 siano stati correttamente implementati.
• 5.34 - Privacy e protezione dei dati personali identificabili: quando un’applicazione tratta dati personali, i requisiti derivati da 8.26 devono incorporare i principi di privacy by design.
• 5.19 & 5.20 - Sicurezza delle informazioni nei rapporti con i fornitori: per applicazioni acquisite o esternalizzate, il controllo 8.26 stabilisce che i requisiti di sicurezza devono estendersi alla catena di fornitura.

Considerare questi controlli come un ecosistema, e non come una checklist, consente di costruire una postura di sicurezza multilivello e difendibile.

La prospettiva dell’auditor: prepararsi all’esame

Gli auditor ragionano in termini di evidenze. Per prepararsi, è necessario comprendere le diverse prospettive che un auditor può adottare. La sezione sulla metodologia di audit in Zenith Controls anticipa questi approcci differenziati.

Comprendere queste prospettive consente di preparare un portfolio di evidenze completo, capace di dimostrare un processo vivo e integrato nell’organizzazione.

La bussola della conformità trasversale: un processo, molti quadri di riferimento

Per un’azienda come quella di Maria, soddisfare DORA, GDPR e NIS2 è obbligatorio. Mappare manualmente i controlli è una ricetta per duplicare gli sforzi e creare lacune di conformità. Un approccio centralizzato e trasversale alla conformità offre un valore rilevante. Definire i requisiti di sicurezza delle applicazioni è l’attuazione pratica del principio di sicurezza fin dalla progettazione su cui si fondano tutte queste normative moderne.

Implementando un processo robusto per i requisiti di sicurezza delle applicazioni basato su ISO/IEC 27002:2022, si costruiscono contemporaneamente evidenze utili a soddisfare una parte significativa di queste altre normative. Non si sta semplicemente “facendo ISO”: si sta costruendo un programma di sicurezza conforme in modo trasversale.

Dal caos al controllo: il percorso da seguire

La storia di Maria ha un esito positivo. Ha usato l’incidente del portale di pagamento come catalizzatore del cambiamento. Forte di un chiaro quadro di policy di Clarysec e di una guida pratica di attuazione, ha riunito i team di sviluppo, sicurezza e prodotto. Hanno utilizzato la metodologia Zenith Blueprint per definire retrospettivamente i requisiti del portale, assegnando priorità agli interventi di correzione in base al rischio.

Soprattutto, hanno stabilito un nuovo modo di lavorare. La “checklist di sicurezza” è stata sostituita da sessioni collaborative di progettazione. Quando gli auditor DORA sono arrivati, Maria non ha potuto mostrare solo un’applicazione sicura, ma anche dimostrare un processo maturo e ripetibile per garantire che tutte le applicazioni future fossero costruite su fondamenta di sicurezza.

Trasformare la postura di sicurezza delle applicazioni inizia da un singolo passo strutturato. Il percorso è chiaro:

1. Stabilire la governance: implementa una policy formale per definire i requisiti di sicurezza delle applicazioni. I nostri modelli, come la Politica sui requisiti di sicurezza delle applicazioni, offrono un punto di partenza pronto per l’audit.
2. Adottare un quadro di riferimento pratico: usa Zenith Blueprint per integrare i requisiti di sicurezza direttamente nel ciclo di vita dello sviluppo, rendendoli azionabili, testabili e tracciabili.
3. Comprendere il contesto completo: sfrutta Zenith Controls per capire come questo controllo critico si collega al più ampio ecosistema di sicurezza e si mappa su DORA, NIS2, GDPR e altro ancora.
4. Scalare al portafoglio applicativo: una volta che l’approccio funziona per una singola applicazione, estendilo a tutto il portafoglio integrando il modello dei requisiti di sicurezza nelle checklist standard di avvio progetto, nei modelli Agile e nei processi di approvvigionamento.

Se vuoi accelerare questa trasformazione, Clarysec fornisce policy predefinite, roadmap di attuazione e mappature di conformità trasversale per passare da iniziative frammentate a un programma dimostrabilmente maturo e pronto per l’audit. Smetti di trattare la sicurezza delle applicazioni come un’ispezione finale. Inizia a incorporarla nel blueprint di tutto ciò che crei.