Het is een bekende tv-spot: bij het ene stel is ingebroken en een ander stel meldt dat het onheil voorkomen had kunnen worden als ze maar camera’s hadden gehad. Camera’s voorkomen helaas niet alles, maar de spotjes – hoe irritant ook – maken wel iets anders duidelijk. Een inbraak is zo gebeurd. Althans, zo lijkt het. De praktijk is vaak dat een inbreker vaak al enige tijd van tevoren doelwitten in de gaten houdt.
De inbreker zal doorgaans eerst verkennen waar de zwakke punten zitten in bijvoorbeeld hang- en sluitwerk. Misschien houdt hij het huis en de bewoners een tijdje in de gaten om te weten wanneer het huis verlaten is. Daarop baseert hij zijn plan. Met andere woorden: een crimineel kijkt vaak al veel langer mee met bepaald gedrag en heeft objecten al goed bestudeerd zodat hij de kwetsbaarheden kent.
Ditzelfde gedrag zien we bij cybercriminelen: verkennen, plannen, toeslaan. Zonder deze bewustwording is elk model en elke tool bij voorbaat kansloos. Zelfs camera’s aan de gevel. Hier is zeker een parallel te maken met software- en applicatieontwikkeling.
Snelheid – staying ahead of the criminal game
Vraag een CIO, CDO of IT-manager naar de grootste uitdaging in het veld en het antwoord zal hoogstwaarschijnlijk zijn: security. Da’s niet zo raar. De bedreigingen en de aanvallen op IT-omgevingen van organisaties worden steeds talrijker en vooral ook vindingrijker. Juist die creativiteit in het bedenken van manieren om ergens achter de deur te komen, is zorgwekkend. Om nog maar te zwijgen over de snelheid waarmee criminelen deze creativiteit aan de dag leggen. Menig organisatie zou haar vingers erbij aflikken als ze eenzelfde snelheid konden ontwikkelen in het bedenken en ontwikkelen van nieuwe producten en services.
Organisaties proberen dat wel: die snelheid evenaren als het gaat om ontwikkelen. Daarvoor hebben we ooit zaken als agile en DevOps bedacht. Juist door development en IT operations nauw met elkaar samen te laten werken, is er minder ‘snijverlies’ in het ontwikkelproces omdat er – althans, dat is de theorie – geen echte overdracht plaatsvindt. Nog mooier: we kunnen de processen tot op het bot automatiseren en daarmee de kans op fouten minimaliseren. Nogmaals: dat is de theorie.
Scannen is niet voldoende
De praktijk is dat organisaties in dit hele proces van DevOps en automatiseren security ineens een ondergeschoven kindje maken. Pas als de applicatie technisch is getest en akkoord bevonden, worden er nog securitychecks gedaan. Vaak reiken die checks niet verder dan statische checks van code. Dat laatste heet SAST in vaktermen: Static Application Security Testing. Een SAST-tool scant de broncode van applicaties en de bijbehorende componenten om potentiële kwetsbaarheden te herkennen. Probleem: deze tools vangen in de praktijk ongeveer vijftig procent van bestaande kwetsbaarheden.
Naast SAST hebben we ook DAST: Dynamic Application Security Testing. DAST-tools scannen actief naar kwetsbaarheden in webapplicaties met behulp van penetratietesten. Probleem: deze scans zijn tijdrovend en de exacte locatie van een kwetsbaarheid wordt (doorgaans) niet gevonden. Zijn deze scans dus voldoende? De vraag stellen is deze beantwoorden: nee.
Maturity Model – op weg naar een volwassen security
Om een beeld te krijgen van een gedegen DevSecOps implementatie, kunnen we het beste kijken naar het DevSecOps Maturity Model (DSOMM) van OWASP. De meeste organisaties zullen het eerste level van dit model wel halen, al vereist level 1 al vergaande maatregelen zoals applicatie hardening, geïsoleerde infra en encryptie op diverse niveaus. Level 4 zou het einddoel moeten zijn van elke organisatie die met DevOps bezig is – op weg naar DevSecOps. Op dit niveau praten we dan over toepassing van blue/green deployment, chaos monkey en diepgaande testen.
Met blue/green deployment worden twee afzonderlijke, maar identieke omgevingen gemaakt. Eén omgeving (blue) voor bestaande functionaliteit in productie en één omgeving (green) de nieuwe toepassingen, volledig afgescheiden van productie. Chaos monkey is een techniek waarbij willekeurig virtual machines of containers worden uitgezet of zelfs verwijderd om te zien wat de impact is op een productieomgeving. Het is een van de vele testen die worden uitgevoerd in DevSecOps, ook om te zien wat er gebeurt als omgevingen door hackers worden aangevallen. Door met maatregelen als deze de security als integraal onderdeel van het ontwikkel- en beheerproces naar een hoger plan te brengen, blijft het mogelijk om criminelen voor te blijven. We willen immers allemaal veilig zijn in ons huis of ons kantoor!
Moeten we dit allemaal doen? Kort en goed: ja. Maar het belangrijkste is en blijft bewustwording. Het besef dat criminelen al heel vroeg mee kunnen en zullen kijken als je je beveiliging door de hele ontwikkelketen niet op orde hebt. Zoals de inbreker ’s avonds laat door de straten rijdt om te zien wanneer mensen al dan niet thuis zijn. En waar die camera’s hangen zodat ze die kunnen omzeilen.
DSOMM zelf bestuderen? Kijk dan op https://dsomm.timo-pagel.de/. Advies en hulp nodig om uw organisatie te helpen in implementeren en beheren van DevSecOps? Neem dan graag contact met mij op: Jeroen Mulder, Principal Consultant Fujitsu (jeroen.mulder@fujitsu.com, Jeroen Mulder | LinkedIn)
In de praktijk zie je vaak dat autoatiseringsprojecten uit planning en daarmee ook uit budget lopen tijdens de ontwikkel fase, terwijl de opleverdatum gefixeerd blijft.
De integratietesten en de functionele testfase worden dan vaak afgeslankt.
De kwaliteit van de software kan dan niet meer worden gewaarborgd.
De security testen worden daarna helemaal geminimaliseerd en daarmee komen kwetsbaarheden in de productieomgeving terecht.
Herstellen van de imagoschade en financiële gevolgen kosten vaak vele malen meer dan het opnieuw plannen van het ontwikkel en testtrajecten.
Er is geen enkele ontwikkelmethodiek die kan waarborgen dat deze geaccepteerde risico’s kunnen voorkomen.