Van risicoanalyse tot implementatie: zo bouw je een veilig applicatieframework

You can read the English version of this blog by clicking here.

——-

Het ontwerpen en implementeren van framework(s) voor applicatiebeveiliging is essentieel om systemen vanaf het eerste ontwerp tot aan het dagelijks beheer veilig te houden. In deze blog bespreken we hoe organisaties en ontwikkelteams een gestructureerde aanpak kunnen volgen, waarbij risico’s, requirements en beveiligingsprincipes vanaf het begin worden meegenomen. We bespreken de belangrijkste kernprincipes, hoe theoretische modellen en frameworks praktisch worden toegepast, en hoe een continue verbetercyclus bijdraagt aan betere en veiligere applicaties.

Deze blog is overigens ook zeer bruikbaar voor mensen die AI-applicaties ontwikkelen. Bij AI-systemen is het extra belangrijk om een applicatiebeveiligingsframework al in de ontwerpfase te implementeren, voordat het systeem überhaupt wordt gemaakt en data wordt gebruikt. AI-modellen zijn afhankelijk van grote hoeveelheden data en vaak gevoelige informatie, waardoor risico’s zoals datalekken, ongeautoriseerde toegang en misbruik snel kunnen optreden. Door vroegtijdig beveiliging in te bouwen volgens een framework, worden de basisprincipes van vertrouwelijkheid, integriteit en beschikbaarheid gewaarborgd, waardoor zowel het systeem als de data veilig kunnen worden gebruikt.

Lees indien gewenst ook deze blog om te ontdekken hoe je systemen het beste kunt ontwikkelen waarin gebruikerslogins nodig zijn.

Wat betekent een framework voor applicatiebeveiliging eigenlijk?

Wanneer organisaties zeggen dat een applicatie “volgens een security framework” gebouwd moet worden, bedoelen ze daar meestal mee dat beveiliging geen sluitpost mag zijn. Het mag dus niet iets zijn wat je pas controleert als alles al gebouwd is. Beveiliging moet vanaf het eerste idee tot en met het dagelijks beheer bewust worden meegenomen in keuzes en besluitvorming. Concreet betekent dit dat je bij elke stap nadenkt over risico’s en over hoe je die beheerst.

Een framework voor applicatiebeveiliging is dan ook geen losse tool of simpele checklist, maar een samenhangend geheel van principes, processen en meetpunten dat richting geeft aan veilig ontwerpen, bouwen en beheren. Het helpt organisaties om gestructureerd naar risico’s te kijken en om daar passende maatregelen bij te kiezen.

In de literatuur over secure software engineering wordt dit gezien als een verschuiving van reactief naar proactief werken (OWASP, z.d.). In plaats van te wachten tot een kwetsbaarheid wordt ontdekt, probeer je vooraf te bedenken waar het mis kan gaan en hoe je dat voorkomt. Bekende modellen zoals het Secure Software Development Framework van NIST (https://csrc.nist.gov/publications/detail/sp/800-218/final) en volwassenheidsmodellen van OWASP (https://owasp.org/www-project-samm/) laten zien dat veiligheid niet alleen technisch is, maar ook organisatorisch moet worden ingebed. Het uitgangspunt daarbij is dat fouten en kwetsbaarheden veel duurder worden als je ze pas laat ontdekt. Dat idee wordt al lang ondersteund in diverse beschikbare literatuur.

Simpel dus kortom gezegd: hoe eerder je een probleem voorkomt, hoe minder schade het veroorzaakt. Dit kan dus door vanaf het begin een plan te maken waarin risicoanalyse en beveiligingsprincipes integraal onderdeel zijn van het ontwikkelproces.

Theoretische fundamenten van secure software engineering

Applicatiebeveiliging is niet zomaar een verzameling best practices, het is gebaseerd op duidelijke theorieën. Een belangrijke basis is risicomanagement, zoals beschreven in ISO 31000 van ISO (https://www.iso.org/standard/65694.html) (ISO, 2018). Risico wordt daarin gezien als een combinatie van kans en impact. Je kijkt dus niet alleen of iets kan gebeuren, maar ook wat de gevolgen zijn als het gebeurt.

Daarnaast is er het principe van “defense in depth”. Dat betekent dat je meerdere beveiligingslagen aanbrengt. Als één maatregel faalt, is er altijd nog een andere laag die bescherming biedt. Dit principe is afkomstig uit militaire strategie en werd in de IT-context geformaliseerd door de National Security Agency (NSA) als een gestructureerde benadering van gelaagde informatiebeveiliging, waarbij fysieke, technische en administratieve beschermingslagen samen een robuust geheel vormen.

Ook klassieke ontwerpprincipes spelen een grote rol. Saltzer en Schroeder (1975) formuleerden in de jaren zeventig principes zoals “least privilege” en “fail secure”.

“Least privilege” houdt in dat gebruikers en systemen nooit meer rechten krijgen dan strikt noodzakelijk is. “Fail-safe defaults” betekent dat toegangsbeslissingen altijd gebaseerd zijn op expliciete toestemming in plaats van op uitsluiting: de standaardsituatie is géén toegang, tenzij toegang uitdrukkelijk is verleend. Als er een ontwerp- of implementatiefout optreedt in een mechanisme dat expliciet toestemming verleent, zal dat mechanisme veilig falen door toegang te weigeren, een situatie die snel dus dan zal worden opgemerkt.

Voorbeelden van applicatiebeveiligingsframeworks voor Least privilege zijn bijvoorbeeld:

• IAM, inclusief meervoudige authenticatie;
• RBAC/ABAC, rolgebaseerde toegangscontrole en
• Tokenbeheer, als een afzonderlijk en kritisch architectuuronderdeel, niet slechts als een uitvloeisel van een principe

Bovengenoemde principes vormen nog steeds de basis van veilige architectuur en secure coding. Een applicatie beveiligingsframework vertaalt deze theoretische principes naar concrete acties, zoals het uitvoeren van een risicoanalyse, het toepassen van gelaagde beveiliging en het zorgvuldig ontwerpen van autorisatiemodellen.

Concreet betekent bovenstaande dat de organisaties dus al bij het ontwerpen van systemen altijd meerdere beschermingslagen moeten inbouwen en dat toegangsrechten strikt worden beperkt tot wat nodig is.

Security by Design als kernprincipe

Security by Design is altijd erg belangrijk, dit betekent dat beveiliging vanaf het allereerste moment wordt meegenomen in het ontwerp van een systeem. Het tegenovergestelde is het traditionele model waarbij eerst functionaliteit wordt gebouwd en beveiliging pas later wordt toegevoegd. In de literatuur wordt dit ook wel “shift left” genoemd, omdat beveiligingsactiviteiten eerder in het ontwikkelproces plaatsvinden.

In de praktijk betekent dit dat je al bij het opstellen van requirements nadenkt over vertrouwelijkheid, integriteit en beschikbaarheid, de bekende CIA-triad uit de informatiebeveiliging (ISO, 2018). Ook zaken als het bewust ontwerpen van gegevensminimalisatie, bewaartermijnen en doelbinding zijn hierbij vaak harde ontwerpeisen.

Juist in deze vroege fase is het cruciaal dat requirements niet globaal of abstract blijven, maar scherp, toetsbaar en volledig zijn uitgewerkt. Onduidelijke of impliciete eisen leiden vrijwel altijd tot ontwerpkeuzes die later moeilijk of kostbaar te corrigeren zijn, zeker wanneer het gaat om autorisatiemodellen, dataclassificatie of integraties met externe systemen. Wat niet helder is vastgelegd, wordt verschillend geïnterpreteerd, en dat zorgt voor fouten.

Je moet dus altijd vooraf bepalen welke data gevoelig is, welke dreigingen realistisch zijn en welke beveiligingsmaatregelen passend zijn. Het helder afbakenen van het beoogde effect van de applicatie wat moet zij exact bereiken, voor welke gebruikersgroepen en binnen welke grenzen voorkomt dat functionaliteit onbedoeld wordt uitgebreid op een manier die het aanvalsoppervlak vergroot. Een goed geoperationaliseerd requirement beschrijft bovendien niet alleen het doel, maar ook meetbare criteria waaraan kan worden vastgesteld of het doel veilig is gerealiseerd.

Vaak wordt hiervoor threat modeling gebruikt, bijvoorbeeld met methodieken zoals STRIDE, een aanpak die oorspronkelijk door Microsoft is ontwikkeld en inmiddels breed is beschreven en toegepast in de industrie (OWASP, z.d.). Daarmee kijk je systematisch naar mogelijke dreigingen zoals spoofing of privilege escalation. Door dit vooraf te doen, voorkom je dat je pas na livegang ontdekt waar de zwakke plekken zitten. Beveiliging wordt dan net zo’n vaste kwaliteitseis als performance of gebruiksvriendelijkheid.

In de literatuur wordt daarnaast vaak Application Security Verification Standard (ASVS) aangehaald als concreet verificatie-instrument. ASVS biedt gestandaardiseerde acceptatiecriteria waarmee kan worden vastgesteld of beveiligingseisen daadwerkelijk zijn gerealiseerd in het ontwerp en de implementatie. Dit sluit direct aan bij het belang van toetsbare en meetbare requirements dat eerder hierboven is al benadrukt: ASVS is in de praktijk precies het instrument dat die toetsbaarheid operationaliseert.

Kortom, het essentieel is om vanaf het begin duidelijke, toetsbare beveiligingseisen op te stellen en mogelijke dreigingen systematisch in kaart te brengen.

Hoe Security by Design in de praktijk werkt

In de praktijk begint Security by Design met het expliciet formuleren van security requirements naast functionele eisen. Je beschrijft dus niet alleen wat het systeem moet doen, maar ook hoe het veilig moet blijven. Wanneer requirements in dit stadium onvoldoende zijn uitgewerkt, ontstaat het risico dat ontwikkelteams aannames doen over bijvoorbeeld toegangsrechten, bewaartermijnen van data of vertrouwelijkheidsniveaus. Zulke aannames worden later zelden volledig teruggedraaid en kunnen structurele kwetsbaarheden veroorzaken. Daarom moeten requirements specifiek, meetbaar en herleidbaar zijn naar bedrijfsdoelen en risicoanalyses.

Daarna volgt de ontwerpfase, waarin beveiligingsprincipes zoals segmentatie, sterke authenticatie en versleuteling standaard worden meegenomen.

Tijdens de ontwikkeling werken programmeurs volgens secure coding richtlijnen, bijvoorbeeld gebaseerd op kennisbanken van OWASP (https://owasp.org/) (OWASP, z.d.). Daarbij is er aandacht voor zaken als inputvalidatie, veilige foutafhandeling en correct gebruik van cryptografie.

Testen gaat verder dan alleen functionele tests. Er worden ook beveiligingsscans uitgevoerd, zoals statische en dynamische code-analyse, en soms penetratietesten. Na oplevering stopt het niet: monitoring, logging en patchmanagement blijven noodzakelijk. Security by Design is dus geen eenmalige actie, maar een continu proces. Het is kortom erg belangrijk dat organisaties beveiliging voortdurend gaan monitoren en verbeteren, ook na de livegang.

Waarom dit organisatorisch verschil maakt

Een security framework invoeren heeft niet alleen technische gevolgen, maar ook altijd organisatorische. Beveiliging wordt een gezamenlijke verantwoordelijkheid. In praktijk betekent dit ook dat er veel aandacht besteed moet worden aan rollen, verantwoordelijkheden en meetbare doelstellingen. En dat ook data management belangrijk blijft. Dat zorgt ervoor dat beveiliging niet afhankelijk is van één specialist, maar structureel is ingebed.

Security by Design vraagt ook om transparante besluitvorming over risico’s en actieve betrokkenheid van het management. Een organisatie die haar requirements in de beginfase scherp definieert en operationaliseert, en vervolgens dit ook vertaald naar een bruikbare integrale aanpak (of framework), creëert bovendien bestuurlijke grip: men kan daarmee later ook makkelijker aantonen welke risico’s bewust zijn geaccepteerd en welke maatregelen doelgericht zijn getroffen. Dit versterkt niet alleen de beveiliging, maar ook de auditability en compliance-positie van de organisatie.

Beveiliging verschuift daarmee van een puur IT-vraagstuk naar een strategisch thema. Organisaties die dit goed aanpakken merken vaak dat beveiliging geen belemmering is, maar juist vertrouwen creëert bij klanten en stakeholders.

In een tijd waarin technologie zich exponentieel ontwikkelt en kunstmatige intelligentie in hoog tempo bedrijfsmodellen, processen en besluitvorming verandert, helpt het bovendien altijd om grondig literatuuronderzoek te doen naar bestaande theorieën, standaarden en best practices. Door verschillende oplossingsrichtingen systematisch in kaart te brengen, ontstaat inzicht in onderliggende aannames, sterke en zwakke punten en contextuele toepasbaarheid. Het combineren van meerdere invalshoeken en bestaande modellen vervolgens tot een samenhangend, nieuw of aangepast framework maakt het mogelijk om beter aan te sluiten bij de specifieke strategische en technologische realiteit van een organisatie. Dit is belangrijk omdat geen enkel standaardmodel één-op-één past op elke context, maatwerk op basis van gefundeerde kennis vergroot zowel effectiviteit als legitimiteit van het gekozen beveiligingsraamwerk.

Een van de manieren om tot een beter ontwerp te komen, is om in het beveiligingsframework ook de afhankelijkheden van externe componenten, bibliotheken en leveranciers structureel te adresseren. Externe afhankelijkheden kunnen namelijk kwetsbaarheden, onbekende risico’s of zelfs kwaadaardige code introduceren die buiten de directe controle van de eigen organisatie vallen, en die daarmee het aanvalsoppervlak significant kunnen vergroten.

Daarnaast is het goed om op te merken dat KPI’s en metrics een onmisbaar onderdeel vaak zijn bij het ontwerpen van een beveiligingsframework. Zonder expliciete meetbare indicatoren, zoals mean time to detect (MTTD), het percentage gepatchte systemen of de resultaten van security audits, is een framework niet aantoonbaar effectief en biedt het onvoldoende bestuurlijke grip. En juist voor auditability en compliance zijn dergelijke meetbare indicatoren onmisbaar.

Van theorie naar proces: kort samengevat in stappen

Als je het proces samenvat, zie je een aantal logische stappen. Eerst voer je een risicoanalyse uit om inzicht te krijgen in assets, dreigingen en kwetsbaarheden. Op basis daarvan stel je vervolgens prioriteiten. Parallel hieraan worden de beoogde effecten van de applicatie expliciet gemaakt en vertaald naar concreet geoperationaliseerde requirements. Dit houdt in dat elk doel wordt gekoppeld aan duidelijke acceptatiecriteria en beveiligings randvoorwaarden, zodat er geen ruimte blijft voor interpretatieverschillen tussen business, architecten en ontwikkelaars. Daarnaast moet ook duidelijk zijn wat de minimale eisen zijn die een framework voor applicatiebeveiliging moet bevatten. Een handig hulpmiddel hiervoor is om deze eisen (oftewel requirements) te onderverdelen naar ontwerpcriteria zoals haalbaarheid, wenselijkheid en levensvatbaarheid. Op deze manier wordt het later eenvoudiger om aan te tonen dat de gewenste doelen en eisen zijn gerealiseerd.

Vervolgens werk je concrete security requirements uit en ontwerp je de architectuur volgens principes als least privilege en defense in depth, aangevuld met bruikbare literatuur en lessons learned uit andere bewezen modellen. Daarna test je het gemaakte framework (oftewel je prototype), voer je een aantal iteraties uit om het framework te verbeteren en implementeer je hierin secure coding standaarden. Voor livegang vindt een security review plaats. Daarna volgt de beheerfase, waarin monitoring en periodieke herbeoordeling van risico’s centraal staan. Samen vormen deze stappen een continue verbetercyclus, vergelijkbaar met PDCA, maar dan specifiek gericht op beveiliging.

Kort samengevat: organisaties en bedrijven moeten altijd een duidelijke, stapsgewijze cyclus volgen van risicoanalyse, ontwerp, testen van het prototype, implementatie, hernieuwd testen, iteraties waar nodig en monitoring doorlopen, om zo tot betere resultaten te komen.

Samenvatting, klik hieronder om de afbeelding te vergroten.

Referenties

• International Organization for Standardization. (2018). ISO 31000:2018 Risk management Guidelines. https://www.iso.org/standard/65694.html
• National Institute of Standards and Technology. (2022). Secure Software Development Framework (SSDF) Version 1.1 (SP 800-218). https://csrc.nist.gov/publications/detail/sp/800-218/final
• OWASP Foundation. (z.d.). OWASP Software Assurance Maturity Model (SAMM). https://owasp.org/www-project-samm/
• Saltzer, J. H., & Schroeder, M. D. (1975). The protection of information in computer systems. Proceedings of the IEEE, 63(9), 1278–1308. https://ieeexplore.ieee.org/document/1451869