Informatiebeveiligers maken tropenjaren door. Het ene grote lek volgt op het andere en we kijken inmiddels bijna nergens meer van op. Er lijkt bijna geen kruid gewassen tegen al die security breaches. Langzaam maar zeker dringt het tot ons door dat we het probleem bij de wortel moeten aanpakken: bij de brakke software. Die moeten we opsporen en vervangen. De grote vraag is alleen: hoe doe je dat? Hoe maak je software safe?
In oktober 2014 werd bekend dat hackers 1,2 miljard inloggegevens van websites hadden bemachtigd. Het was het zoveelste mega-incident in een alsmaar langer wordende rij van incidenten. Hoe kan dit? Er is op het gebied van de cybersecurity de afgelopen twintig jaar toch enorm veel afweer ontwikkeld, zou je zeggen. Er is een complete industrie ontstaan met antiviruspakketten, firewalls, anti intrusion devices, encryptietools, hardware tokens, ethical hackers en wat allemaal niet meer. Toch lekt het nog steeds dat het een aard heeft, ondanks al die digitale zandzakken (en miljardeninvesteringen door bedrijven!). Waarom is dat? Het antwoord op die vraag is even simpel als schokkend: veel van onze software rammelt. Veel is slordig ontworpen. Er is in de loop der tijd van alles uitgeknipt en aangeplakt en de documentatie van al die wijzigingen is vaak gebrekkig of ontbreekt zelfs geheel. Gevolg: er zitten overal kieren in de muur. Pleisteren helpt niet meer. We moeten de muur zelf onder handen nemen.
Kwetsbaarheden
Deze kieren in onze digitale muren worden kwetsbaarheden genoemd, vulnerabilities op z’n Engels. In persoonlijke relaties is kwetsbaarheid juist een kwaliteit. Zijn we niet allemaal kwetsbaar en maakt dat je niet juist geloofwaardig? Nou dan! Alleen is er in de wereld van de code niks aaibaars aan kwetsbaarheid. Het begrip kwetsbaarheid is een eufemisme en het is hoog tijd dit beestje nu maar eens bij zijn ware naam te noemen: het is een programmeerfout. De kwetsbaarheid van de software (en daarmee van de organisatie) is het gevolg van een fout.
Een voorbeeld van zo’n gevaarlijke programmeerfout zijn de antwoordformulieren op veel websites, met onderaan een vrij veld voor opmerkingen. Prima, want dat geeft de bezoeker die nog iets extra’s kwijt wil de ruimte. Zo’n veld dient echter wel beschermd te worden door het aantal in te typen karakters in de code van de website aan een maximum te binden. Doe je dat niet dan kan een kwaadwillende de website platleggen door miljoenen regels tekst op dit veld af te vuren. Of neem de manier waarop de Troonrede van 2012 werd gehackt. Simpelweg door achter de url van de Troonrede van een jaar eerder het jaar 2012 in te typen. In de software van de site had daartegen een beveiliging ingebouwd moeten zijn, maar die ontbrak.
Het Open Web Application Security Project (OWASP) heeft een top-10 opgesteld van programmeerfouten in web-applicaties . Een leerzaam lijstje, en niet alleen voor webapplicaties, want veel van de beschreven fouten komen ook voor in andere typen software. Maar liefst driekwart van alle beveiligingslekken is terug te voeren op programmeerfouten. Dat zijn snoeiharde feiten en het illustreert hoe enorm belangrijk het is om dit probleem aan de bron aan te pakken. Hoe? Door ervoor te zorgen dat nieuwe software veel minder fouten bevat dat en bestaande software over een breed front wordt ‘opgeschoond’.
Overzicht ontwikkelen
Er liggen diverse vragen voor ieder managementteam. Welke software hebben we allemaal in huis, en welke gebruiken we online? Welke security-kwaliteit heeft die? Welke risico’s lopen we met al die software van al die verschillende kwaliteiten? En natuurlijk de hamvraag: wat gaan we daartegen ondernemen? Het begint dus met het ontwikkelen van overzicht.
Organisaties hebben in principe drie typen software in gebruik:
a) Applicaties die in eigen huis en met eigen personeel zijn ontwikkeld en gebouwd.
b) Applicaties die in opdracht van de organisatie door derden zijn ontwikkeld en gebouwd (it-dienstverleners, zzp’ers).
c) Pakketsoftware die is aangeschaft of online software die wordt gehuurd.
In het eerste geval (a) is het aan te raden om vanaf nu als eis aan alle nieuwe software te stellen dat deze volgens de uitgangspunten van Secure Software Development (SSD, zie kader) wordt ontworpen, gebouwd en onderhouden. Alle reeds bestaande applicaties kunnen met behulp van deze uitgangspunten alsnog tegen het licht worden gehouden: waar voldoen zij niet aan deze eisen, en wat is er nodig om ze aan te passen? Prioritering kan door middel van een risicoanalyse en een business impact analyse plaatsvinden. Dus daar waar het risico voor de business het grootst is, wordt het eerst actie ondernomen en zo verder totdat het hele applicatielandschap is omgeploegd. Dit kan een enorme taak zijn, waar jarenlang herstelwerk mee is gemoeid, maar het is zeer belangrijk om daar nu een begin mee te maken. De reden daarvoor is simpel: we gebruiken steeds meer software en er worden steeds meer kwetsbaarheden ontdekt. Met andere woorden: het risico neemt toe. Hoe meer je nu repareert, hoe beter je je huidige en toekomstige risico’s afdekt.
Een goed gesprek
In het tweede geval (b) heb je minder zelf in de hand, maar kun je het gesprek aangaan met de bouwer van de software. In hoeverre heeft deze in het verleden de principes van SSD toegepast? Waar zitten eventuele lacunes? Wat komt er bij kijken om die te verhelpen? In de praktijk blijkt dat hier veel misverstanden over bestaan. Opdrachtgevers voor softwareontwikkeling gaan ervan uit dat de uitvoerder van de opdracht wel zorg zal dragen voor de veiligheid van de applicatie. Dat wordt als logisch voorondersteld. Maar de opdrachtnemer kijkt naar de formulering van de vereisten (de specificaties) die in de offerte en in het contract staan. Staat het niet in de specs? Dan is daar dus geen opdracht voor gegeven. Dat is heel vaak de stellingname van de bouwer. Het dient geen enkel doel om hier nu ruzie over maken. Daar is de security van de organisatie in geen geval bij gebaat. Veel effectiever is het te erkennen dat er een grijs gebied is ontstaan en dat dit weg moet in de toekomst.
Nog weer wat lastiger wordt de situatie met software van derden (c), vaak bij kleinere organisaties het leeuwendeel van hun software. Daar heb je als klant nog minder grip op dat in geval (b). Softwareleveranciers daarentegen zullen beseffen dat ze een heel groot risico lopen als er door onvolkomenheden in hun producten grote security breaches ontstaan. Dat kan ze hun licence to operate kosten, zoals gebeurde bij het inmiddels failliete DigiNotar, de onderneming achter DigiD. Organisaties kunnen druk uitoefenen op hun leveranciers door om duidelijkheid te vragen. In hoeverre passen zij security by design toe op hun producten? Hoe clean is hun code? Hoe testen zij de kwaliteit van die code? Een goed hulpmiddel hierbij is de methode Grip op SSD die in 2013 is ontwikkeld onder auspiciën van het CIP (Centrum voor Informatiebeveiliging en Privacybescherming) en met ondersteuning vanuit het Nationaal Cyber Security Centrum (NCSC). Dit is een set van richtlijnen en best practices waarmee het mogelijk is om software van de grond af aan veilig in te richten.
UWV maakt schoon schip
Eén van de koplopers in de toepassing van Secure Software Development is het UWV, dat ook de ontwikkeling van deze beveiligingsmethodiek betrokken was. Rob Roukens, Enterprise Security Architect en projectmanager Grip op Informatiebeveiliging bij het UWV vertelt dat zijn organisatie gebruikmaakt van zo’n vijf- tot zeshonderd applicaties. “We passen de methodiek en het nieuwe kader toe op al onze applicaties. Zo’n honderd tot tweehonderd daarvan zijn bedrijfskritisch. Daar richten we ons in eerste instantie op. De meeste daarvan zijn in onze opdracht gebouwd door leveranciers als CGI, Capgemini, Pink Roccade, Atos en Unisys. Eind 2013 zijn we met hen om tafel gegaan en hebben we ze verteld dat software vanaf 1 januari 2014 compliant moet zijn aan SSD. Hier vallen uiteraard ook alle aanpassingen aan bestaande applicaties onder. Van deze leveranciers verwachten we verder dat ze deze software voor oplevering volgens de nieuwe normen testen en ons een testrapport overhandigen. Daarna doen we zelf nog aanvullende tests in ons Test Service Centrum en soms ook nog aanvullende penetratietesten bij onze afdeling IT Security.”
Het UWV legde aan deze leveranciers vervolgens ook de vraag voor hoe compliant de software is die zij vóór 1 januari 2014 hebben geleverd en wat het gaat kosten om deze alsnog compliant te maken. “Het zal duidelijk zijn dat dit tot onderhandelingen leidde,” licht Roukens toe. “Wij stellen ons op het standpunt dat de software die wij afnemen veilig moet zijn. Als blijkt dat dit niet het geval is, moet de leverancier dat oplossen. Aan de andere kant snappen we ook wel dat er voortschrijdend inzicht is en dat je nieuwe eisen niet zonder meer met terugwerkende kracht van toepassing kunt laten zijn. In de praktijk komen we ergens in het midden uit.” Hij schat de kosten van deze hersteloperatie op zo’n 5 tot 10 procent van de eerder aan de projecten gedane uitgaven. Dit vertegenwoordigt een aanzienlijk bedrag, omdat er in het geval van kernapplicaties vaak jarenlange bouwactiviteiten zijn geweest.
Met de opschoning van dit ‘historische’ applicatielandschap wordt bij het UWV nu begonnen. Er is een dashboard gemaakt waarop de SSD-vorderingen met rode en groene kleuren worden weergegeven.
Strenge eisen aan de cloud
Hoe zit het met pakketsoftware, die niet in opdracht van het UWV is geschreven, maar kant-en-klaar is gekocht van een softwareleverancier? “Daar ligt het wat eenvoudiger,” reageert Roukens, “want de markt pikt dit zelf al op. Bovendien kun je in de configuratie meestal zelf ook wel voldoende security inbouwen.” Dit levert volgens hem in veel gevallen een ‘basale beveiliging’ op, waardoor het risico van deze software beperkt is. Anders ligt dat bij cloud-oplossingen. “Daar bestaat een aanzienlijk hoger risico. Hier stellen we strenge eisen aan. Om te beginnen een security-overeenkomst. Daarin verplicht de leverancier zich om tal van zaken goed te regelen. Dat loopt van de inrichting van het beheer tot en met de screening van zijn personeel. Als tweede eis stellen we het voldoen aan de voorwaarden van de methode Grip op SSD. En als derde dat we penetratietesten mogen doen op de cloud-omgeving die we van een leverancier afnemen.”
Het UWV concentreert zich op de sleutelapplicaties, maar onderneemt tegelijkertijd ook actie waar het de overige applicaties in het portfolio betreft. In de loop van 2014 zijn daarom ook al deze ‘overige’ leveranciers benaderd met eenzelfde boodschap, Einddoel is dat het totale landschap groen is gekleurd. Rest de vraag of SSD na verloop van tijd niet weer verouderd is. Hoe zorg je dat je bij blijft met nieuwe ontwikkelingen op het gebied van de informatiebeveiliging? Roukens: “SSD zal zich ook verder ontwikkelen met nieuwe, aangepaste versies. We nemen dat mee in het overleg dat we periodiek met onze leveranciers voeren om het contract te evalueren en waar nodig aan te passen.”
Bij het UWV is het kwartje gevallen. De verantwoordelijken daar beseffen dat de beste afweer tegen cybercrime hoogwaardige software is. Dat is software waar geen speld tussen te krijgen is. Die uit en te na is getest, zowel door de leverancier als door de afnemer. Die goed gedocumenteerd is en regelmatig een opfrisbeurt krijgt. Het slechte nieuws is dat nog maar heel weinig van dergelijke hoogwaardige software is. Hackers leven daarom nog altijd in een luilekkerland. Het goede nieuws is dat er snel verbeteringen mogelijk zijn als softwareleveranciers en bedrijven zich samen sterk maken en investeren in software van hoge kwaliteit.
Grip op SSD
Onder auspiciën van het CIP (Centrum voor Informatiebeveiliging en Privacybescherming) is de methode Grip op SSD ontwikkeld. Dit is een set van richtlijnen en best practices waarmee het mogelijk is om software vanaf de grond af aan veilig in te richten. Basis van Secure Software Development (SSD) is security by design. Dit uitgangspunt is vrij nieuw voor de software-industrie, maar wordt in de automative sector en in de luchtvaart al veel langer toegepast. Met de methode Grip op SSD kan het management aan alle nieuwe software de eis stellen dat deze aan essentiële veiligheidsvereisten voldoet. Daarnaast stelt het organisaties in staat om hun totale, historisch gegroeide applicatielandschap tegen het licht houden en op te schonen. Grip op SSD fungeert dan als een meetlat.
De methode omvat de volgende vijf stadia:
- Het opstellen van de specifieke beveiligingseisen. Zo wordt aan leveranciers en hosting partijen duidelijk gemaakt welk niveau van beveiliging de organisatie verwacht.
- Code reviews. Tussendoor of achteraf wordt geverifieerd of de juiste maatregelen worden getroffen.
- Testen en toetsen. De leveranciers laat via het testen bevestigen dat de software voldoet aan de opgelegde specificaties, inclusief de beveiligingseisen en legt de testresultaten voor aan de opdrachtgever.
- Risicoacceptatie. Als wordt besloten dat de dienstverlener niet wil of kan voldoen aan een bepaalde beveiligingseis, moet dit besluit door de opdrachtgever worden bevestigd via een expliciete risicoacceptatie.
- Penetratietesten tijdens de implementatie en de gebruiksfase. Hiermee wordt geverifieerd dat de risico’s van openstaande verbindingen, standaard wachtwoorden of achterblijvende onderhoudsniveaus zijn afgedekt.
Onderdeel van deze methode is een set van 31 beveiligingseisen voor web-applicaties. SSD-4 bijvoorbeeld luidt als volgt: de applicatie past encryptie toe op de communicatie van vertrouwelijke gegevens over niet-veilige netwerken. En SSD-6: (web)applicaties stellen de identiteit van interne gebruikers vast op basis van een mechanisme voor identificatie en authenticatie, waarbij de authenticatie- en autorisatiegegevens in een geconsolideerde authenticatie- en autorisatievoorziening worden beheerd. En SSD-9: de (web)applicatie registreert mislukte login-pogingen.
Elk van deze 31 eisen is van een gedetailleerde toelichting voorzien, inclusief verwijzing naar corresponderende onderdelen binnen ISO 27001 en andere standaarden voor informatiebeveiliging.
Download en lees de documentatie van Grip op SSD
Wie is verantwoordelijk?
In de documentatie van Grip op SSD is het onderstaande schema opgenomen voor de afbakening van verantwoordelijkheden tijdens de bouw van webapplicaties. Handig, want zo voorkom je grijze gebieden (en zwartepieten als er iets verkeerd loopt):
De primaire verantwoordelijkheid voor het implementeren van de beschreven eis, aldus de opstellers van Grip op SSD, ligt bij de interne of externe softwareleverancier. Verder stelt het: “Als onderdeel van de oplevering van een release, die klaar is voor productie, dient deze leverancier te rapporteren over de wijze waarop aan de gestelde eisen is voldaan. De controle en toezicht op de werking en implementatie van de gestelde beveiligingseisen is belegd bij de leverancier, de hostingpartij en de opdrachtgever. In de praktijk zijn bij de opdrachtgever een testteam en een securityteam verantwoordelijk voor de controle en het toezicht.”
