Minder datalekken? Begin bij het Begin!

Om tot de situatie te komen waarin software minder lekken vertoont, is het niet meer voldoende om te vertrouwen op een pentest aan het einde van een ontwikkelcyclus.. Maar hoe komen we er dan wel?

Trends
Gartner toont in zijn hype cycle een aantal trends in software ontwikkeling. Zo gaan steeds meer bedrijven helemaal over op het agile werken, verschijnen er steeds meer devops teams en implementeren steeds meer bedrijven continuous-delivery. Waarom? dit alles heeft verschillende voordelen: concepten kunnen eerder getest en bijgesteld worden, het eindproduct kan sneller live en de kosten omlaag.

Tegelijkertijd is er een hier al eerder benoemde trend zichtbaar (dankjewel @Remco Bakker ): bedrijven willen graag voldoen aan de gebruikelijke voorschriften en ze willen eigenlijk niet verder gaan dan de standaarden. Dit is ook iets wat vaak terug komt in software ontwikkelingstrajecten: functionaliteiten eerst, beveiliging later. Aan het einde van een lijstje requirements komt security aan de beurt in de vorm van de opmerking: “Oh, voor ik het vergeet: het moet wel veilig zijn”.... Maar daar laten organisaties het dan ook bij; de verificatie van deze wens is vaak gebrekkig. Uit een study van het (ISC)2 blijkt dat veel bedrijven voornamelijk aan het einde van het ontwikkeltraject een pentest uitvoeren of zelfs dat niet. Ook blijkt dat er sprake is van een gebrek aan security kennis bij veel van de ondervraagde bedrijven.

Het grootste nadeel van het inzetten van een pentest als belangrijkste security control is dat het Minimal Viable Product een week eerder af moet zijn: dan kunnen de pen-testers er nog mee aan de gang. De wat meer volwassen teams hebben soms nog 1 of 2 aanvullende controle momenten gedurende het ontwikkelproces voordat het MVP af is. Er zijn vraagtekens te zetten bij deze scoping en de bijbehorende doorlooptijd. Vaak wordt alleen het laaghangend fruit gevonden zodat het product niet direct op dag 1 op zwart gaat, maar verder evalueren blijft vaak uit tot een incident of een volgende release.

Niet zomaar “veilig”
Laat ik even teruggaan naar het begin, want eerlijk is eerlijk; uiteindelijk willen we allemaal een veilig product toch? Veilig zou zich hier moeten vertalen naar een product wat een acceptabel risico met zich mee draagt. Een product dat informatie van klanten voldoende beschermd en waar de klanten vertrouwen in kunnen hebben.

Leren van de tester
Er zijn veel zaken waar rekening mee gehouden moet worden om hiertoe te komen. Voor nu wil ik vooral inzoomen op continuous integration, mogelijk gemaakt door verregaande test automation. Het is nu de developer die zijn eigen code test. Testers focussen zich nu steeds meer op de kwaliteit van de software. Ze helpen daarbij de developer vanaf het begin om tot betere testgevallen te komen, terwijl de developer steeds meer het basis testwerk goed op pakt. Defecten worden daardoor al in een vroeg stadium gevonden. Maar wat nu als we hetzelfde doen met software beveiliging en risico beheersing?

De secure dev-ops teams van de toekomst
De “full-stack”-developer van de toekomst zal ook een basis moeten hebben in security. Hier ligt een mooie taak voor trainingsinstituten, de IT-opleidingen en initiatieven zoals OWASP. Security is echter niet alleen een taak van de developer; ook security officers, risk managers, product owners en (pen-)testers hebben een verantwoordelijkheid.

Product owners moeten de backlog als uitgangspunt nemen in agile risk management. Op die manier kan iedereen veel sneller nadenken over wat “veilig” genoeg is, zonder een “big design” up front. Per feature op de backlog moet door alle stakeholders worden nagedacht over het belang van de data: wat als deze uitlekt, aangepast wordt of verdwijnt?. De secure devOps teams kunnen dat weer als uitgangspunt gebruiken om na te denken over (Evil) user stories en andere controls. Op deze manier kan de business eerder een concept toetsen en risico’s tijdig identificeren.

Helaas zijn veel teams zijn nog niet zo ver. Goed risico’s inschatten is moeilijk en het is belangrijk om te waken voor papieren tijgers.

Op basis van de backlog kunnen secure dev-ops teams iteratief werken naar een product wat ‘secure by design’ is in plaats van te wachten op de resultaten van een pen-test. In plaats daarvan kunnen de pentesters iedere sprint direct een bijdrage leveren en developers samen met ops-engineers ook leren waar ze op moeten letten. Als security specialisten teams leren om security testen uit te voeren, defensive coding toe te passen en de teams helpen om op de juiste manieren security controls op te nemen in het minimal viable product, dan voorkomen we de haast-klus aan het einde. De “haast-klus” aan het einde kan dan juist een iteratieve stap worden in de continuous delivery pipeline als laatste vangnet.

Onze functie
Worden security specialisten dan overbodig als teams verantwoordelijk gaan worden voor de security van producten? Het antwoord is gelukkig ‘Nee’. Ook testers zijn niet overbodig geworden, maar hebben zichzelf opnieuw uitgevonden door te helpen in test-automatisering en te zoeken naar die gevallen waar een developer misschien niet aan denkt. Op een vergelijkbare manier moeten een pentester, een risk-manager en een security officer hun rol in DevOps teams claimen en een complementaire accelerator worden in plaats van slechts een controlerende eenheid.

Jeroen Willemsen, Secure software developer & consultant bij Xebia in samenwerking met kennisplatform cqure.nl