Van blauwdruk tot auditgereed: applicatiebeveiligingsvereisten beheersen voor ISO 27001, DORA en NIS2

De spanning voorafgaand aan de audit was tastbaar. Voor Maria, CISO van een middelgrote fintechonderneming, voelde de aanstaande DORA-compliancebeoordeling minder als een reguliere review en meer als een afrekening. Haar team was deskundig, haar infrastructuur gehard, maar één hardnekkige kwetsbaarheid hield haar ’s nachts wakker: de uitgestrekte, chaotische wereld van hun applicaties.

De nieuwste zorg was een nieuw klantgericht betaalportaal, dat onder tijdsdruk was gelanceerd om kwartaaldoelstellingen te halen. Het ontwikkelteam, werkend binnen een strak agile model, had alle functionele vereisten afgevinkt. Maar toen Maria’s team een eerste scan uitvoerde, bevestigden de resultaten haar zorgen.

Het portaal had geen robuuste regels voor sessietime-outs, de invoervelden waren gevoelig voor eenvoudige injectieaanvallen en foutmeldingen lekten gevoelige systeeminformatie. Dit waren geen geavanceerde zero-day-exploits, maar fundamentele ontwerpfouten. De oorzaak was pijnlijk duidelijk. Beveiligingsvereisten waren nooit formeel gedefinieerd, gedocumenteerd of geïntegreerd in de ontwikkelsprints. Het team had een vaag mandaat om “het veilig te maken”, maar zonder concrete blauwdruk bleef beveiliging een ambigu en vaak genegeerd sluitstuk.

Dit scenario staat niet op zichzelf. Het laat de kritieke kloof zien waarmee veel CISO’s en complianceverantwoordelijken worden geconfronteerd: de intentie “wij doen aan beveiliging” omzetten in expliciete, testbare applicatiebeveiligingsvereisten die aansluiten op fundamentele normen zoals ISO/IEC 27001:2022 en belangrijke regelgeving zoals NIS2, DORA en GDPR.

De hoge kosten van ambiguïteit: wat compliance daadwerkelijk verwacht

De kern van Maria’s probleem ligt in een veelvoorkomend organisatorisch falen: beveiliging behandelen als een kwaliteitskenmerk in plaats van als een set niet-onderhandelbare vereisten. Een effectieve beveiligingsvereiste is specifiek, meetbaar en testbaar. “De applicatie moet veilig zijn” is een wens. “De applicatie moet sessies na 15 minuten inactiviteit beëindigen, alle gebruikersinvoer valideren tegen een vooraf gedefinieerde tekenset en alle gegevens tijdens transport versleutelen met TLS 1.3” is een vereiste. Die duidelijkheid is wat auditors zoeken en wat ontwikkelaars nodig hebben om veilige software te bouwen.

Zonder die duidelijkheid ontstaat een keten van tekortkomingen:

• Inconsistente implementatie: Verschillende ontwikkelaars interpreteren “veilig” verschillend, waardoor een lappendeken van beheersmaatregelen ontstaat met onvoorspelbare hiaten.
• Hogere herstelkosten: Het vinden en herstellen van een ontwerpfout in productie is exponentieel duurder dan het aanpakken ervan in de ontwerpfase.
• Audit-non-conformiteiten: Auditors signaleren snel het ontbreken van een gestructureerd proces voor het definiëren van beveiligingsvereisten, wat leidt tot belangrijke bevindingen.
• Bedrijfsrisico: Elke niet-gedefinieerde vereiste is een potentiële aanvalsvector en stelt de organisatie bloot aan datalekken, financieel verlies en reputatieschade.

Binnen moderne normen is de verwachting consistent: beveiliging moet vroegtijdig als vereisten worden gedefinieerd en worden gekoppeld aan risico en wetgeving. De richtlijnen van ISO/IEC 27002:2022 voor beheersmaatregel 8.26, Application security requirements, verwachten dat organisaties beveiligingsvereisten systematisch bepalen, documenteren en goedkeuren op basis van formele risicobeoordeling en wettelijke eisen.

Dit ene principe is de spil voor een breed scala aan complianceverplichtingen. Clarysec’s cross-compliance mapping binnen Zenith Controls: The Cross-Compliance Guide Zenith Controls laat zien hoe dit concept overal terugkomt:

• GDPR Articles 25 en 32 verwachten “data protection by design” en “security of processing”.
• NIS2 Article 21(2)(d)-(e) benadrukt veilige ontwikkeling en beveiliging van de toeleveringsketen.
• DORA Articles 6(4), 8, 10 en 11 vereisen ICT-risicobeheer en security by design voor financiële entiteiten.
• NIST SP 800-53 Rev.5 vereist in beheersmaatregelen SA-4 en SA-15 gedefinieerde systeembeveiligingsvereisten en veilige ontwikkelpraktijken.
• COBIT 2019 vereist in processen BAI03 en DSS05 dat beveiligingsgerelateerde vereisten worden afgestemd op bedrijfs- en compliancedoelstellingen voordat een oplossing wordt gebouwd.

Het doel is om, in de woorden van Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, “te definiëren wat beveiliging voor uw applicaties betekent, voordat er ook maar één regel code is geschreven.”

Waarom traditionele benaderingen falen: checklists, late tests en security theatre

De meeste organisaties doen al iets aan applicatiebeveiliging. Het probleem is dat dit zelden zodanig is gestructureerd dat het standhoudt bij ISO/IEC 27001:2022-certificering of toetsing door toezichthouders.

Veelvoorkomende faalpatronen zijn:

1. Generieke checklists: Teams hergebruiken voor elk project een één pagina tellende “secure coding checklist”. Deze is niet gekoppeld aan de specifieke risico’s, gegevensgevoeligheid of regelgevingscontext van de applicatie. Wanneer een auditor vraagt hoe de checklist aansluit op GDPR Article 25, is er geen duidelijk antwoord.
2. Beveiliging als late gate: Beveiligingsvereisten zijn niet ingebed in ontwerp of user stories. Ze verschijnen aan het einde als verzoek om een penetratietest. De Zenith Blueprint waarschuwt dat “vertrouwen op een beveiligingschecklist aan het einde van het project niet werkt; die vereisten moeten vanaf dag één de architectuur vormgeven, bibliotheekkeuzes beïnvloeden en prioritering van functionaliteit sturen.”
3. Geen traceerbaarheid van vereiste naar test: Er kan een vereiste bestaan om “gegevens tijdens transport te versleutelen”, maar er is geen gekoppelde testcase die afdwinging van de TLS-versie, certificaatgeldigheid en ciphersterkte verifieert. De Zenith Blueprint stelt dat verwachtingen meetbaar en testbaar moeten zijn, waarbij beveiligingstests rechtstreeks aan de bijbehorende vereisten worden gekoppeld.
4. Ad-hocafhandeling van code van derden: Moderne applicaties worden vaak “samengesteld uit interne code, bibliotheken van derden, API’s en cloud-native diensten”, zoals vermeld in de Zenith Blueprint. Zonder expliciete vereisten voor leveranciers en opensourcecomponenten blijft risico in de toeleveringsketen een grote, onbeheerde blinde vlek.

Het resultaat is security theatre: documenten bestaan en tests worden uitgevoerd, maar wanneer een serieuze auditor of toezichthouder zoekt naar een samenhangend verhaal over vereisten, valt het hele proces uiteen.

De basis leggen: van beleid naar praktijk

Een gedisciplineerde aanpak van applicatiebeveiliging begint met duidelijke governance. Beleid is niet slechts bureaucratie; het is de formele bron van waarheid die teams mandateert en auditors een duidelijke intentieverklaring biedt. Bij Clarysec ontwerpen we beleidsdocumenten die zowel gezaghebbend als praktisch zijn.

Ons Beleid voor applicatiebeveiligingsvereisten Beleid voor applicatiebeveiligingsvereisten stelt niet-onderhandelbare basisregels vast. Clausule 5.2 onder ‘Governancevereisten’ schrijft bijvoorbeeld voor:

Alle applicaties moeten tijdens planning of inkoop een validatie van beveiligingsvereisten ondergaan, met gedocumenteerde goedkeuring van het applicatiebeveiligingsteam.

Deze eenvoudige bepaling voorkomt de mentaliteit van “eerst bouwen, later beveiligen”. Het beleid wijst ook duidelijke verantwoordingsplicht toe. Clausule 4.3.1 onder ‘Rollen en verantwoordelijkheden’ stelt dat ontwikkelaars:

Applicaties implementeren in overeenstemming met gedefinieerde beveiligingsvereisten en standaarden.

Daarmee verschuift de verantwoordelijkheid voor beveiliging van een afzonderlijk, vaak als tegenpartij ervaren beveiligingsteam naar de makers van de software zelf. Bovendien verbindt het beleid verschillende beveiligingsdomeinen met elkaar. Clausule 10.2 verwijst naar de integratie met andere belangrijke beheersmaatregelen:

P4 – Beleid voor toegangsbeheer. Definieert de standaarden voor identiteits- en sessiebeheer die door alle applicaties moeten worden afgedwongen, inclusief sterke authenticatie, het principe van minimale privileges en vereisten voor toegangsrechtenbeoordelingen.

Voor kleinere organisaties zorgt een toegesneden beleid zoals ons Beleid voor applicatiebeveiligingsvereisten - mkb Beleid voor applicatiebeveiligingsvereisten - mkb ervoor dat deze principes schaalbaar zijn. Het erkent dat de risico’s vergelijkbaar zijn, maar dat de implementatie pragmatisch moet zijn. Beide versies streven uiteindelijk hetzelfde resultaat na: applicatiebeveiliging volledig integreren in het ISMS en gereed maken voor audits.

Een praktische roadmap: auditgerede applicatiebeveiligingsvereisten opbouwen

Beleid bepaalt het “wat” en “waarom”, maar ontwikkelaars en projectmanagers hebben het “hoe” nodig. Een gestructureerde implementatiegids is onmisbaar om beheersmaatregelen op hoofdlijnen te vertalen naar uitvoerbare stappen. Stap 21 van de Zenith Blueprint, gericht op ISO/IEC 27002:2022-beheersmaatregel 8.26, biedt een duidelijke methodiek in zes stappen.

Laten we dit proces doorlopen aan de hand van Maria’s betaalportaal.

Stap 1: Begin bij risico en regelgevingscontext

Met behulp van uitkomsten van de risicobeoordeling die zijn afgestemd op ISO/IEC 27005:2024 (risicobehandeling), bepaalt u eerst de context:

• Applicatie: Selfservicebetaalportaal voor klanten.
• Gegevens: persoonsgegevens, inloggegevens, betalingstokens.
• Jurisdicties: EU, financiële dienstverlening, gehost in de cloud.
• Regelgeving: GDPR, DORA, PCI DSS.

Op basis van de richtlijnen voor beheersmaatregel 8.26 in Zenith Controls en de gerelateerde ISO-normen (27034-1, 27017, 27701) moeten uw initiële categorieën van vereisten ten minste identificatie en authenticatie, autorisatie, gegevensclassificatie, invoervalidatie, logging en gegevensbescherming tijdens transport en in rust omvatten.

Stap 2: Maak of adopteer een template voor beveiligingsvereisten

De Zenith Blueprint beveelt aan een gestandaardiseerd template te maken zodat elk project dezelfde fundamentele beveiligingsvragen beantwoordt. Dit document moet onderdeel worden van uw toolkit voor de projectstart.

Minimale onderdelen zijn:

• Applicatienaam, eigenaar en criticaliteit.
• Gegevenscategorieën en gevoeligheidsniveaus.
• Toepasselijke wettelijke en contractuele verplichtingen (GDPR, DORA, enz.).
• Input over het dreigingslandschap (afgeleid uit beheersmaatregel 5.7 Threat Intelligence).
• Specifieke beveiligingsvereisten per categorie (authenticatie, logging, enz.).
• Koppelingen naar user stories en acceptatiecriteria.
• Koppelingen naar testcases (functioneel, beveiliging, penetratie).
• Vereisten voor leveranciers en componenten van derden.

Stap 3: Veranker vereisten in agile artefacten

Beveiligingsvereisten moeten rechtstreeks worden ingebed in user stories en acceptatiecriteria. Voor de epic “klantregistratie” in Maria’s portaalproject betekent dit dat een eenvoudige functionele story wordt omgezet in een beveiligingsbewuste story.

• Oorspronkelijke user story: “Als nieuwe gebruiker kan ik een account aanmaken.”
• Veilige user story: “Als nieuwe klant wil ik een beveiligd account aanmaken zodat mijn betaalinformatie wordt beschermd.”
• Acceptatiecriteria (met ingebedde beveiliging):
  • Het systeem moet een sterk wachtwoordbeleid afdwingen in lijn met het P4 – Beleid voor toegangsbeheer.
  • Het systeem moet e-mailverificatie via een eenmalige link vereisen voordat het account wordt geactiveerd.
  • Het formulier voor accountcreatie moet door CAPTCHA worden beschermd om botaanvallen te voorkomen.
  • Alle registratiepogingen moeten worden gelogd met bron-IP en apparaatfingerprint.
  • Alle via het formulier ingediende gegevens moeten worden opgeschoond om cross-site scripting (XSS) te voorkomen.

Dit zijn geen afzonderlijke beveiligingstaken; ze vormen een integraal onderdeel van de definitie van “done” voor de functionaliteit.

Stap 4: Koppel vereisten aan beveiligingstesten

Met behulp van beheersmaatregel 8.29 Security testing uit Zenith Controls zorgt u ervoor dat elke vereiste een bijbehorende testcase heeft. Daarmee sluit u de kringloop en levert u auditbewijsmateriaal over de doeltreffendheid van beheersmaatregelen.

• Vereiste: Encryptie tijdens transport met TLS 1.3. → Test: Geautomatiseerde scan om TLS-afdwinging, certificaatgeldigheid en goedgekeurde cipher suites te verifiëren.
• Vereiste: Invoervalidatie om SQL-injectie te voorkomen. → Test: Geautomatiseerde SAST/DAST-scanning en handmatige fuzzing tijdens QA.
• Vereiste: Sessietime-out na 15 minuten inactiviteit. → Test: Geautomatiseerde en handmatige tests om te bevestigen dat sessies na 15 minuten inactiviteit serverzijdig ongeldig worden gemaakt.

Stap 5: Breid vereisten uit naar de toeleveringsketen

Omdat ISO-beheersmaatregel 8.26 in Zenith Controls is gekoppeld aan leveranciersbeveiliging (5.19, 5.20) en uitbestede ontwikkeling (8.30), moet uw proces rekening houden met code van derden. Voor mkb-organisaties die sterk afhankelijk zijn van externe bibliotheken is de beleidsclausule uit het Beleid voor applicatiebeveiligingsvereisten - mkb cruciaal:

Elke tool, plug-in of externe codebibliotheek van derden die in een applicatie wordt gebruikt, moet worden geregistreerd en jaarlijks worden beoordeeld op beveiligingsimpact en patchstatus.

Deze eenvoudige, pragmatische vereiste dwingt een software bill of materials (SBOM)-aanpak af, wat een belangrijke verwachting is onder regelgeving zoals NIS2. Voor grote leveranciers moeten dezelfde applicatiebeveiligingsvereisten in contracten worden opgenomen, met verwijzing naar ISO/IEC 27036-1 (ICT supply chain security).

Stap 6: Voer periodieke herbeoordeling in

Naarmate applicaties veranderen, veranderen ook hun risico’s. De richtlijnen van de Zenith Blueprint voor periodieke herbeoordeling zijn daarom cruciaal. Wanneer u een nieuwe API integreert of overstapt op een andere clouddienst, verandert de risicocontext. Dit moet een beoordeling van de bestaande beveiligingsvereisten activeren om te waarborgen dat deze nog steeds toereikend zijn. Dit sluit aan op ISO/IEC 27005:2024 (doorlopende risicobehandeling) en maakt van applicatiebeveiliging een continu proces, geen eenmalig project.

Het ecosysteem van beheersmaatregelen ontleden

Een ISO-beheersmaatregel staat nooit op zichzelf. Effectieve beveiliging berust op een onderling verbonden geheel van maatregelen. De werkelijke kracht van beheersmaatregel 8.26 komt vrij wanneer u de relatie met andere beheersmaatregelen begrijpt, een perspectief dat in Zenith Controls uitgebreid wordt beschreven.

Beheersmaatregel 8.26 is geclassificeerd als een preventieve beheersmaatregel, maar fungeert als centraal knooppunt voor het hele veilige ontwikkelproces en verbindt met:

• 8.25 - Secure development life cycle: Dit is het overkoepelende kader. Beheersmaatregel 8.26 levert het specifieke wat (de vereisten) dat moet worden geïntegreerd in het hoe (het SDLC-proces).
• 8.27 - Secure system architecture and engineering principles: Vereisten sturen architectuurbeslissingen en zorgen dat beveiliging fundamenteel wordt ingebouwd.
• 8.28 - Secure coding: Zodra vereisten zijn gedefinieerd (bijv. “voorkom SQL-injectie”), bieden standaarden voor veilige programmeerpraktijken ontwikkelaars de technieken om aan die vereiste te voldoen.
• 8.29 - Security testing in development and acceptance: Deze beheersmaatregel valideert dat de in 8.26 gedefinieerde vereisten correct zijn geïmplementeerd.
• 5.34 - Privacy and protection of PII: Wanneer een applicatie persoonsgegevens verwerkt, moeten de vereisten uit 8.26 de principes van privacy by design bevatten.
• 5.19 & 5.20 - Information security in supplier relationships: Voor ingekochte of uitbestede applicaties bepaalt beheersmaatregel 8.26 dat uw beveiligingsvereisten moeten doorwerken in de toeleveringsketen.

Door deze beheersmaatregelen als ecosysteem te zien in plaats van als checklist, bouwt u een gelaagde, verdedigbare beveiligingspositie op.

De blik van de auditor: voorbereiden op toetsing

Auditors denken in termen van bewijsmateriaal. Om u voor te bereiden, moet u begrijpen welke verschillende invalshoeken een auditor kan meenemen. De auditmethodieksectie in Zenith Controls anticipeert op deze uiteenlopende benaderingen.

Door deze invalshoeken te begrijpen, kunt u een volledig bewijsportfolio voorbereiden dat een levend, werkend proces aantoont dat in uw organisatie is verankerd.

Het cross-compliancekompas: één proces, veel raamwerken

Voor een organisatie als die van Maria is voldoen aan DORA, GDPR en NIS2 verplicht. Handmatige mapping van beheersmaatregelen leidt snel tot dubbel werk en compliancehiaten. Een gecentraliseerde cross-complianceaanpak levert grote waarde op. Het definiëren van applicatiebeveiligingsvereisten is de praktische implementatie van het security-by-designprincipe dat aan al deze moderne regelgeving ten grondslag ligt.

Door een robuust proces voor applicatiebeveiligingsvereisten te implementeren op basis van ISO/IEC 27002:2022, bouwt u tegelijk bewijsmateriaal op om aan een aanzienlijk deel van deze andere regelgeving te voldoen. U doet niet alleen “ISO”; u bouwt een universeel compliancegericht beveiligingsprogramma.

Van chaos naar beheersing: uw route vooruit

Maria’s verhaal heeft een positieve uitkomst. Ze gebruikte het incident met het betaalportaal als katalysator voor verandering. Gewapend met een duidelijk beleidskader van Clarysec en een praktische implementatiegids bracht ze haar ontwikkel-, security- en productteams samen. Ze gebruikten de methodiek van de Zenith Blueprint om achteraf vereisten voor het portaal te definiëren en herstelmaatregelen op basis van risico te prioriteren.

Belangrijker nog: ze voerden een nieuwe werkwijze in. De “beveiligingschecklist” werd vervangen door gezamenlijke ontwerpsessies. Toen de DORA-auditors kwamen, kon Maria niet alleen een veilige applicatie laten zien, maar ook een volwassen, herhaalbaar proces aantonen waarmee alle toekomstige applicaties op een beveiligde basis worden gebouwd.

Het transformeren van uw applicatiebeveiligingspositie begint met één gestructureerde stap. Uw route vooruit is duidelijk:

1. Richt governance in: Implementeer een formeel beleid voor het definiëren van applicatiebeveiligingsvereisten. Onze templates, zoals het Beleid voor applicatiebeveiligingsvereisten, bieden een auditgereed startpunt.
2. Adopteer een praktisch raamwerk: Gebruik de Zenith Blueprint om beveiligingsvereisten rechtstreeks in uw ontwikkelingslevenscyclus te integreren, zodat ze uitvoerbaar, testbaar en traceerbaar worden.
3. Begrijp de volledige context: Gebruik Zenith Controls om te zien hoe deze kritieke beheersmaatregel aansluit op het bredere beveiligingsecosysteem en hoe deze wordt gemapt op DORA, NIS2, GDPR en meer.
4. Schaal naar uw portfolio: Zodra de aanpak voor één applicatie werkt, schaalt u deze uit over uw portfolio door uw template voor beveiligingsvereisten te integreren in standaard projectstartchecklists, agile templates en inkoopprocessen.

Als u deze transformatie wilt versnellen, biedt Clarysec vooraf gebouwde beleidsdocumenten, implementatieroadmaps en cross-compliance mappings om u van gefragmenteerde inspanningen naar een aantoonbaar volwassen en auditgereed programma te brengen. Behandel applicatiebeveiliging niet langer als een eindcontrole. Bouw het vanaf nu in de blauwdruk van alles wat u maakt.