Een kritieke beveiligingsfout in je software is de nachtmerrie van iedere ondernemer of projectmanager. En toch zijn datalekken en compleet platgelegde bedrijfsprocessen aan de orde van de dag.
Veilige software bouwen is niet eenvoudig en ook steeds veeleisender. Het moet mooi en snel zijn, veilig én ook nog op tijd geleverd. Eén subtiele programmeerfout, ook wel bug, kan al een groot beveiligingslek veroorzaken. Een geluk bij een ongeluk is wel dat bugs vaak vrij eenvoudig zijn op te lossen.
Fouten
Dit geld niet voor flaws, een term die we gebruiken voor voor fouten in het ontwerp of de logica. Deze zijn vaak veel lastiger te corrigeren en vragen soms zelfs ingrijpend redesign.
Doodzonde, want flaws zijn vaak al van mijlenver, in een vroeg stadium zichtbaar maar komen vaak pas vijf voor twaalf aan het licht. Vaak komt dit doordat de enige security-test pas in het eind stadium, vlak voor oplevering, wordt uitgevoerd. Veel te laat, met regelmatig onaangename verrassingen en een fikse kans op “show stoppers” tot gevolg.
Wat kun je doen om dit soort verrassingen te voorkomen?
1. Vroege security-brainstorm
Bouw je een nieuwe applicatie dan moet je continue en goed nadenken over security, vooral in het begin. Vandaar deze tip voor teams die op het punt staan een nieuwe applicatie of feature te bouwen: organiseer een security-brainstormsessie zodra je helder hebt wat je wilt gaan bouwen en hoe je het ongeveer wilt gaan bouwen (qua frameworks, talen, etc.). Niet te vroeg, maar ook zeker niet te laat dus.
Hoe ga je bijvoorbeeld je login of het transactiesysteem beveiligen met een One Time Password (OTP)? Hoe bedenk je de password-reset functie, en hoe versleutel je gegevens? Zomaar een paar voorbeelden van onderdelen waar we nog geregeld grote conceptuele fouten in tegenkomen.
Meestal blijkt de oorzaak van flaws namelijk te liggen in het ontbreken van goed uitgedachte specificaties, waardoor de invulling wordt overgelaten aan de “dichterlijke vrijheid” van het ontwikkelteam. Wat uiteraard prima kan als de juiste kennis aanwezig is, maar dat blijkt helaas niet altijd het geval. Ontwikkelteams hebben hun handen vaak al vol aan duizend-en-een andere, ook belangrijke zaken. Geen verrassing dus dat een slechte voorbereiding en gebrekkige specificaties de belangrijkste oorzaken van flaws zijn.
Het belangrijkste is dat je ervoor zorgt dat een ervaren software security engineer de sessie leidt. Heb je die niet intern, betrek deze dan van buiten. Met een paar uurtjes kun je echt al heel veel bereiken. Dit hoeft dus niet veel te kosten en is de beste security investering die je kunt doen.
2. Werp een tussentijdse blik op de code
Ben je inmiddels al lekker op weg met de bouw, voer dan een tussentijdse security code-review uit. Flaws zijn namelijk uitstekend vroegtijdig te identificeren vanuit de code en des te vroeger je ze vangt, des te eenvoudiger er kan worden bijgestuurd.
Het ideale moment van een dergelijke tussentijdse check is zodra de (security) basis van je applicatie staat. Wat vaak al op 25-50% van je bouwtraject is. Voor een doorsnee applicatie is dat bijvoorbeeld zodra de volgende zaken (nagenoeg) gereed zijn: authenticatie en autorisatie, sessie-management, afhandeling van gebruikersinvoer, een aantal frontend-schermen en de database interactie.
Kortom, het is dus echt niet nodig om te wachten tot het laatste moment. Verifieer al vroegtijdig of er geen grote blunders in het fundament zitten. Dergelijke gerichte reviews zijn door een specialist vrij snel uit te voeren.
3. Vertrouw niet alleen op geautomatiseerde scantools
Waar sommige type bugs eventueel gedetecteerd zouden kunnen worden met een (geautomatiseerde) code-scanner, geldt dit absoluut niet voor flaws. Deze zijn compleet onzichtbaar voor deze tools. Net zoals mijn spell-checker bijvoorbeeld nooit zal kunnen vertellen of de zinsvolgorde van dit verhaal wel klopt, het inhoudelijk wel deugd en of er wellicht complete zinnen of onderwerpen ontbreken.
Pas op voor de security-fuik
Veel projecten mogen pas live op het moment dat ze aantoonbaar veilig zijn bevonden. Niet goed nadenken over security kan in een laat stadium veel tijd en geld kosten, terwijl het product al zo goed als af is. Het is eenvoudiger en goedkoper om in vroeg stadium flaws aan te pakken, het ontwikkelproces is nog in volle gang en de ontwikkelaars hoeven minder ver terug te grijpen. En in het beste geval voorkom je dus flaws voordat er een regel code is geschreven door goede specificaties.
Dit scheelt een hoop tijd achteraf en de nodige frustratie.
