Security by design biedt vele voordelen, maar staat nog in de kinderschoenen. Ik neem u graag mee door negen stappen om ermee aan de slag te gaan.
Security by design is de tegenhanger van security-after-the-fact: in plaats van achteraf testen of een systeem veilig is, wordt informatiebeveiliging ingebouwd vanaf het begin. Hiermee worden kosten en risico’s gereduceerd om de volgende redenen:
- Het oplossen van securitybevindingen aan het begin is vele malen goedkoper dan aan het eind (onderzoek toont een factor 100 aan). Bovendien is de druk op tijd en budget typisch groot aan het eind van een ontwikkeltraject: geen goed moment voor doordachte verbeteringen. Security by design leidt tot een bestendiger systeem doordat security wordt ingebouwd in plaats van dat het in de haast als reparaties wordt toegevoegd.
- Door de inzet van verschillende soorten maatregelen in security by design (bewustzijn, kennis, tools, controles) worden securityfouten effectiever verwijderd dan met een test aan het einde van de ontwikkeling.
- Door vroeg te ontdekken welke fouten precies worden gemaakt kan men de werkwijze aanpassen en het maken van nieuwe fouten voorkomen. Dit geldt bijvoorbeeld voor verbeteringen in de samenwerking tussen ontwikkelaars en de it-operatie. Als die samenwerking erg nauw en geautomatiseerd is wordt die ook wel DevOps genoemd en als security is ingebouwd: SecDevOps.
Kinderschoenen
Security by design klinkt heel verstandig. Maar helaas blijkt in de praktijk dat het nog in de kinderschoenen staat. We kunnen dagelijks in het nieuws lezen dat informatiebeveiliging te wensen over laat en in mijn werk als software-onderzoeker zie ik bij veel klanten steeds weer dezelfde security-fouten en een gebrek aan aandacht voor security.
Waarom is er nog onvoldoende aandacht voor het inbouwen van security? Zijn ontwikkelaars lui, slecht of onprofessioneel? Integendeel, over het algemeen zijn ze gemotiveerd en trots op hun werk. De sleutel zit in waar ze op worden afgerekend. Over het algemeen ligt daarbij de nadruk toch op het bouwen van nieuwe functies. Die hebben de meeste zichtbaarheid. Als de kwaliteit van het werk niet wordt getoetst en zichtbaar wordt gemaakt, dan is kwaliteit toch snel het eerste dat sneuvelt. Je krijgt wat je meet. Om ervoor te zorgen dat security aandacht krijgt moet het met ontwikkelaars worden afgesproken.
Security by design begint daarom met goede samenwerking tussen opdrachtgever en -nemer, met duidelijke en passende eisen en de voorwaarde dat broncode onderzocht kan worden om te toetsen of security goed is ingebouwd. Vanaf dat moment gaan softwarebouwers het proces ook zo inrichten dat security by design gebeurt. Voor goede handvaten in de dialoog tussen opdrachtgevers en softwarebouwers: zie het ‘Grip op SSD’-initiatief van het CIP. Een goede reden om eisen te stellen kan wet-en regelgeving zijn, zoals de GDPR, die security en privacy by design vereist als het om persoonsgegevens gaat.
Hoe krijg je security by design voor elkaar?
Bij het inrichten van security by design is het belangrijk te realiseren dat softwareontwikkeling mensenwerk is. Mensen maken fouten. De kunst is om zo realistisch mogelijk te kijken hoe je programmeurs in een situatie krijgt dat ze weinig fouten maken en de fouten die ze maken worden gevonden. Daarbij kan gebruik worden gemaakt van de volgende negen stappen:
1: Bouw op bewezen technologie: Security is moeilijk en je wil zoveel mogelijk al geregeld hebben door de technologie die je gebruikt. Moderne programmeeromgevingen nemen al een flink deel van beveiliging voor hun rekening – mits op de juiste manier gebruikt. Security by design begint bij de keuze van technologie en verdieping in het juiste gebruik ervan. Eén op de drie kwetsbaarheden die wij vinden is veroorzaakt door het zelf programmeren van iets dat al beschikbaar was. Het is wel belangrijk om op de hoogte te blijven van kwetsbaarheden in de gebruikte technologieën en libraries, en om op tijd te patchen. Library management, het bijhouden van externe code, zal een van de belangrijkste programmeertaken worden van de komende jaren.
2: Maak bewust: Maak ontwikkelaars bewust van wat geëist is en wat de typische dreigingen zijn voor de software die ze ontwikkelen. Voorbeelden en demonstraties werken goed. Door ontwikkelaars te betrekken in threat modeling ontstaat meer beleving.
3: Instrueer, maar beperkt: Securitykennis bij ontwikkelaars is prettig, maar je wil er niet afhankelijk van zijn dat ontwikkelaars op de juiste momenten de vereiste kennis paraat hebben. Dat is gewenst maar niet haalbaar. Mensen zijn niet in staat om boeken vol kennis continu te hanteren. In elk geval is het belangrijk om ontwikkelaars de principes van security by design bij te brengen. Owasp omschrijft er tien.
Soms zijn er toch richtlijnen waar het ontwikkelteam zich aan moet houden maar die niet automatisch kunnen worden afgevangen in technologiekeuze of tooling. De beste vorm van deze richtlijnen is dan referentiemateriaal dat geordend is op basis van herkenbare situaties – zogenaamde triggers. Vervolgens is het zaak dat het ontwikkelteam dergelijke triggers herkent (zoals bijvoorbeeld: ‘we verwerken nu gebruikersinvoer’).
4: Stuur op onderhoudbaarheid: Spaghetticode die moeilijk is aan te passen vergroot de kans op (security)fouten. Onderhoudbare broncode is een voorwaarde voor security. Stel daarom eisen aan onderhoudbaarheid en zorg voor tools die dit meten.
5: Automatiseer controles: Er komen steeds meer verificatietools beschikbaar om automatisch op bepaalde securitykwetsbaarheden te toetsen, door gedrag te testen of door broncode te scannen. Onderschat de moeite niet die het kost om goed met deze nuttige tools om te gaan.
6: Controleer ook handmatig: Handmatige controles zijn belangrijk want automatische verificatietools zijn in staat om slechts een deel van de kwetsbaarheden te vinden. Controles kunnen worden uitgevoerd door teamgenoten, door specialisten van binnen de organisatie of door specialisten van buiten. Daarbij is het belangrijk om de specialist niet te beperken tot de opgegeven security-eisen, die altijd incompleet zullen zijn. Onderschat niet het uitvoeren van een handmatige penetratietest of een handmatige codereview. Het is een vak apart, want het vereist creativiteit, ervaring, systematiek, herhaalbaarheid en idealiter ook het vermogen om ontwikkelaars te adviseren hoe ze hun werk structureel kunnen verbeteren.
7: Breid uit met privacy: Privacy by design gaat over goede omgang met persoonsgegevens (inclusief de beveiliging ervan). Het gaat om bewustzijn, om het kennen van de principes, om specifieke controles. Een security by design-programma laat zich daarom goed uitbreiden met dit onderwerp.
8: Verbeter gaandeweg: Maak een plan hoe ontwikkeling steeds beter wordt. Gebruik daar een volwassen raamwerk voor, zoals bijvoorbeeld Owasp SAMM.
9: Vergeet bestaande systemen niet: Security by design is niet alleen voor nieuwe ontwikkeling. Juist als systemen nooit ontwikkeld zijn met security by design is het aan te raden de controles uit te voeren om kwetsbaarheden te vinden. Het zijn immers ook de miljarden bestaande coderegels waar we de komende jaren nog van te vrezen hebben.
