Opdrachtgever kan software veilig krijgen

Marcel Koers is CISO (chief information security officer) bij UWV

Software moet veilig zijn, maar hoe zorg je daar als opdrachtgever voor en hoe spreek je de ontwikkelaars/leveranciers erop aan? Het levert menige (overheids-)organisatie al jaren hoofdbrekens op. “Die leveranciers blijken er heel verschillend in te zitten”, zegt Marcel Koers van het UWV tijdens de sessie ‘Receptuur voor veilige softwareontwikkeling’ op het iBestuur Congres. “Het varieert van ‘je moet ons vertrouwen’ tot ‘we hebben duidelijkheid nodig’.” Afspraken over hoe veilig software moet zijn en hoe je die vertaalt in een product blijken vaak simpelweg niet expliciet genoeg, met kwetsbaarheden als gevolg.

Als CISO (chief information security officer) bij het UWV kent Koers het belang van het veilig krijgen en houden van software. Daarop grip krijgen kan alleen door voortdurend ‘in contact te zijn met het bouwproces’, stelt hij. Grip op SSD, waaraan Koers namens zijn organisatie meewerkte, biedt een handreiking om dat te realiseren.

In het kort komt het volgens hem hierop neer: weten hoe belangrijk een systeem is en wat de grootste bedreigingen zijn, standaard beveiligingseisen stellen aan leveranciers (maar toegespitst op de specifieke situatie), contactmomenten organiseren (bij risicoanalyse, code reviews, testen en toetsen, penetratietesten, risicoacceptatie) en processen inrichten voor het gezamenlijk bewaken van dat alles (de governance).

Koers laat het in ieder geval simpel klinken: “Je stelt beveiligingseisen voor alle IV-projecten en gedurende het traject kijk je of de software daaraan voldoet. Je verwacht van de leverancier rapportages. De testen en toetsen hou je goed bij en als de implementatie gedaan is hou je een penetratietest. En je doet uitspraken over welke risico’s je accepteert bij de software.”

Maar als opdrachtgever beveiligingseisen stellen is niet iets wat je zomaar doet. “Je moet weten hoe belangrijk een systeem is en wat de belangrijkste bedreigingen zijn. Als je de risicoanalyse begint met ‘laten we eens wat bedenken’, dan bedenk je niet de goede dingen. Hou die afwegingen voor alle applicaties bij. Je kunt vervolgens de verantwoordelijke managers aanspreken op de kwaliteit.”
‘Sturen op volwassenheid’ en ‘de organisatie opvoeden’ zijn vervolgens belangrijk. “Steeds meer afdelingen ga je erop wijzen dat ze aan de eisen moeten voldoen. Voed de organisatie in geleidelijke stapjes op en houd alles bij op een dashboard om het inzichtelijk te maken.”

De principes uit Grip op SSD zijn ook prima toepasbaar op standaardsoftware, stelt Koers. “Je kunt nog steeds je zwakheden beoordelen, ook als je de code niet ziet. Bij het UWV regelen we het nu al met de bestaande leveranciers. En bij een nieuwe aanbesteding moet je het vanaf het begin regelen. Die eisen moet je in een zo vroeg mogelijk stadium meegeven, op een laag niveau. Dán word je gesprekspartner van elkaar. Je moet dus wel eerst je risico-analyse hebben gedaan, voordat je naar de markt gaat.”

Grip op Secure Software Development is geschreven in opdracht van het Centrum Informatiebeveiliging en Privacybescherming (CIP), in de vorm van twee publicaties één over het proces zelf en één over de SIVA Beveiligingseisen voor (web)applicaties.

Miscommunicatie over veiligheid

Wat is nu eigenlijk veilige software? Rob van der Veer, senior consultant bij de Software Improvement Group, ervaart regelmatig hoeveel moeite leveranciers en opdrachtgevers hebben om het daarover eens te worden, er goed over te communiceren en de feitelijke risico’s te onderkennen. “In de praktijk zien we daardoor heel veel onveilige software.”
In die miscommunicatie spelen enkele factoren een rol: beveiligingseisen zijn onduidelijk en niet op maat. (De opdrachtgever verwacht deskundigheid, terwijl de leverancier precieze specificaties verwacht.), er wordt niet of laat getoetst, de opdrachtgever heeft weinig risico-overzicht en bestaande standaarden bieden weinig houvast.

Met een aantal quotes uit projecten die SIG heeft gedaan illustreert hij hoe het mis kan gaan:

• ‘Wij gaan ervan uit dat de leverancier weet hoe je veilige software maakt.’
“Maar wat is veilig? Je moet op zijn minst definiëren wat jij als opdrachtgever als veilig beschouwt.” Plus: als de leverancier onder druk staat, en er zijn harde requirements over functionaliteit en geen harde requirements over veiligheid, dan weet je wel wat er gebeurt.”

• ‘Ja maar onze leverancier is toch ISO gecertificeerd?’
“Er zal veel goed geregeld zijn, maar dat dat zegt niets over de kwaliteit van de software die de leverancier produceert.”

• ‘O, leidt dat tot reputatieschade?’
“Een fout leidde tot allerlei meldingen en gaf privacy-problemen en persaandacht. De opdrachtgever had in dit geval een hele mooie risicoanalyse gemaakt, maar die was nooit op het bureau van de ontwikkelaar terecht gekomen. En soms doen opdrachtgevers niet eens een risicoanalyse.”

• ‘We doen al een penetratietest, dus.’
“Heel mooi als je een penetratietest doet en een hacker inhuurt. Maar dat kan pas als het systeem klaar is en het dus duur wordt om het alsnog aan te passen. Daarnaast is zo’n pentest beperkt; er zijn morgen weer nieuwe aanvallen.”