Security by design, beter voorkomen dan genezen

Cqure in gesprek met Rob van der Veer van de Software Improvement Group (SIG)

Security is soms net een wedstrijd. Als we ons vandaag de dag willen beschermen tegen de verschillende bedreigingen is het belangrijk dat we geen kansen weggeven aan de andere partij. De ‘tegenpartij’ ziet momenteel veel kansen door te penetreren in systemen en applicaties, vaak doordat fouten zijn gemaakt tijdens het ontwerp en de ontwikkeling ervan. Wil je die wedstrijd eerlijk beginnen met gelijke stand en kansen, dan is het dus in de basis belangrijk dat je code van een goede kwaliteit is. Zo voorkom je problemen in plaats van dat je ze moet genezen. Security by design!

Een relatie van Cqure is de Software Improvement Group (SIG). Als onderdeel van hun dienstverlening kijken zij naar de kwaliteit van broncode om te adviseren over kosten en risico’s op het vlak van onder meer onderhoudbaarheid, betrouwbaarheid en security. Zij lichten jaarlijks zo’n 600 softwaresystemen door.

Op het kantoor van SIG, kijkend over heel Amsterdam stelden wij een aantal vragen aan Rob van der Veer, die verantwoordelijk is voor de security practice van SIG.

Rob, wat is volgens jou Security by design?

Je kunt bij software en applicaties spreken van Security by design als er goed is nagedacht over de beveiliging bij het ontwerp en tijdens de bouw. De security is dan intrinsiek verweven in de software. Een ketting is zo sterk als de zwakste schakel dus je wilt structureel maatregelen nemen. Wat heeft het voor zin om van een bankgebouw alle ramen en deuren te vergrendelen als binnen de sleutel gewoon in de kluis zit? Vroeg of laat komt er toch iemand binnen.

Security by design is dus de oplossing voor veilige software, maar wat is eigenlijk het bijbehorende probleem?

Bijna alle organisaties maken gebruik van firewalls en voeren regelmatig penetratietesten uit. Desondanks is er een sterke groei van het aantal security-incidenten. Dit laat zien dat organisaties nog niet genoeg vat hebben op dit probleem. Het blijkt dat 75% van die incidenten wordt veroorzaakt door onnodige fouten tijdens het bouwen van software. Toch wordt er zelden gekeken of het goed in elkaar is gezet. In plaats daarvan wordt de gebouwde applicatie getest middels een aantal inbraakpogingen. Deze aanpak komt dan te laat en vangt onvoldoende af, getuige de explosieve toename van het aantal incidenten.

Hoe zorg je dan dat security is ingebouwd?

Om te beginnen door er niet vanuit te gaan dat dit vanzelf gebeurt. Wij zien in de praktijk dat de meeste leveranciers (of interne ontwikkelafdelingen) uit zichzelf geen Security by design toepassen. Dat wordt al beter als opdrachtgevers eisen gaan stellen, maar zelfs dán zien we dat leveranciers het laten liggen omdat hun werk niet of nauwelijks inhoudelijk getoetst wordt. Het is dan vaak wachten op een penetratietest (áls die al wordt uitgevoerd) om te zien welke lekken nog moeten worden gedicht. Van structurele security is dan geen sprake. Het is daarom belangrijk om reviews te doen, bij voorkeur vroeg in het ontwikkelproces. Reviews van het ontwerp en reviews van de code: laat experts naar de software kijken om te zien of er sprake is van Security by design. Wordt er voldaan aan de eisen? Worden de geldende best practices toegepast? Zo kun je meteen zien waar de gaten zitten in de verdediging en welke voorzieningen er ontbreken.

Hoe voeren jullie die reviews dan uit?

Wij praten allereerst met onze opdrachtgever over de doelen en de pijnpunten met betrekking tot de software. Vervolgens hebben we interviews met ontwikkelaars en beheerders en dan gaat ons laboratorium aan de slag met de broncode. Door een mix aan tooling en expertkennis lichten we de broncode door. Bij security passen we typisch twee eigen modellen toe: één voor onderhoudbaarheid en één voor security. Daarbij baseren we ons op ISO25010 als raamwerk en bij de beoordeling maken we gebruik van het werk van met name NCSC, CWE/SANS en OWASP. Dit alles naast onze diepgaande expertise op het gebied van software. Voor security kijken we naar uiteenlopende systeemeigenschappen zoals logging, gegevensoverdracht, sessiebeheer, gegevensopslag en invoer/uitvoervalidatie. Bij gegevensoverdracht kijken we bijvoorbeeld naar een aspect als caching: wordt communicatie ergens gecached op een schijf en wordt deze informatie daarna dan ook netjes opgeruimd. We beoordelen de implementatie volgens de geldende best practices en dat leidt per eigenschap tot een score die we afbeelden op de onderliggende ISO25010 securitykarakteristieken. Uiteindelijk resulteert dat in een totaalscore van het systeem uitgedrukt tussen één en vijf sterren. Op managementniveau is die meetbaarheid zeer gewenst. Bij dat eindoordeel hoort natuurlijk de lijst met bevindingen die we vervolgens koppelen aan de risico's in de context van de software. Op die manier maken we inzichtelijk wat er kan gebeuren, samen met een schatting van kans en impact zodat maatregelen geprioriteerd kunnen worden. In overleg met de klant stellen we dan een stappenplan op om de security naar een hoger niveau te tillen.

Dit is veel techniek. Hoe zit het met de processen?

Uiteraard zijn de processen ook belangrijk. De zaken die wij in de techniek zien, koppelen we in onze onderzoeken terug naar de oorzaak in de processen. Vaak zien we dat ontwikkelaars niet op de hoogte zijn van een risico-analyse. Of we zien dat er wel eisen zijn, maar dat er geen relevante selectie is gemaakt van eisen, gegeven de opdracht, waardoor de leverancier ze niet serieus neemt. Behalve een technische roadmap stellen we daarom ook een organisatorische roadmap op om die oorzaken weg te nemen.

Je had het over onderhoudbaarheid. Waarom speelt dat een rol?

Onderhoudbaarheid is van belang omdat je wil voorkomen dat nieuwe fouten ontstaan als software wordt aangepast. Daarbij gaat het niet alleen om fouten die tot nieuwe kwetsbaarheden leiden, maar ook om fouten die zorgen dat data lekt, dus zonder dat een systeem gehackt wordt heb je dan al een securityprobleem. Wat je eigenlijk wil is software waarmee iedere programmeur goed uit de voeten kan. Dus ook programmeurs zonder diepe securitykennis, die niet 100% van de tijd alert zijn op kwetsbaarheden. Die softwarekwaliteit bereik je als je de programmeur ontzorgt door de zaken structureel te regelen: zoals gebruik maken van standaard securityvoorzieningen, overzichtelijke toegangsregeling, scheiden van functies in de architectuur en centrale invoervalidatie. Security by design dus!

Wat zijn jullie plannen om Security by design beter op de kaart te krijgen?

Allereerst door steeds meer klanten te helpen met het zichtbaar maken van security, als meetinstrument om op te kunnen sturen. Daarnaast hebben we samen met het CIP (een samenwerking van overheidsorganisaties) een methode opgesteld genaamd 'Grip op secure software development' voor opdrachtgevers om risico-analyses te doen, eisen te stellen en in dialoog te blijven met de leverancier over het structureel inbouwen van security. We leggen nu de laatste hand aan die methode die in januari breed zal worden gelanceerd.