Veilige of foutvrije programmacode: utopie of haalbaar?

Bewapeningswedloop in cybersecurity vraagt om beveiliging aan de bron

Veilige of foutvrije programmacode: utopie of haalbaar?

Veilige programmacode - bestaat die eigenlijk? Het lijkt een beetje op de vraag of er foutvrije software bestaat. Bij het Nederlands Instituut voor de Software Industrie (NISI) zijn ze van mening dat het maken van software geen exacte wetenschap is. De enorme vrijheidsgraad in het programmeren van code maakt het te complex en lastig om veiligheidsgaranties te geven voor software. Er doen zich altijd omstandigheden voor waar je vooraf geen rekening mee hebt kunnen houden. Programmatuur bevindt zich nooit in een status quo; de code ondergaat continu aanpassing. Inmiddels dreigt de bewapeningswedloop in cybersecurity onbetaalbaar te worden en zijn we gedwongen na te denken over beveiliging aan de bron: de code. Anders gezegd: al bij het ingeven van de eerste regels code moet de focus gericht zijn op beveiliging.

“Elke ontwikkelaar behoort veiligheid van de code integraal in zijn werk mee te nemen”, aldus dr. Jan Vlietland. Hij is verbonden aan het Nederlands Instituut voor de Software Industrie (NISI), een instelling gehuisvest op het terrein van de Universiteit van Utrecht. NISI biedt een cursusblok aan over ’secure design’ als onderdeel van de omvangrijke leergang cloud software engineering. Vlietland: “Op de architectuurstack met bovenin de bedrijfsprocessen en onderin de hardware kun je drie verschillende cloudniveau’s plotten: infrastructure as a service, platform as a service en software as a service. Welke van de niveaus je ook afneemt van de provider, verwacht niet dat het automatisch veilig is. Dat hangt sterk af van wat je precies aanklikt. Kies je bijvoorbeeld als PaaS een Linuxplatform, dan krijg je automatisch een reeks voorgeconfigureerde firewallpoorten.”

“Kies je een Apachewebserver, dan moet je de firewall van de web engine zelf configureren. Bij alle software die je gebruikt, moet je de vraag stellen of die wel veilig is. Zo is het bijvoorbeeld van groot belang om bij een invoerveld van een website in een Linuxomgeving na te gaan wat er wordt ingegeven en hierop controleren.”

Een prachtige manier om hiermee zelf te experimenteren, noemt Vlietland de ’damn vulnerable web application’. “Op deze Linuxinstance krijgt de programmeur met een configuratiescherm de mogelijkheid om het securityniveau in te stellen. Is die ’low’, dan kun je via het invoerveld allerlei commando’s aan de Linuxinstance doorgeven, waarop je een file met alle gebruikte wachtwoorden kan terugkrijgen. Dit maakt inzichtelijk hoe belangrijk validaties op dit soort invoervelden zijn.”

“En als we het toch over wachtwoorden hebben”, zo vervolgt Vlietland, ”dan verwijs ik naar het bericht van enige tijd geleden waarin stond dat Facebook de wachtwoorden onbeveiligd en onversleuteld had opgeslagen. Echter, je kan het wachtwoord opslaan na het versleutelen met een algoritme. Die versleuteling voer je ook uit met het ingegeven wachtwoord, waarna je het vergelijkt met het versleutelde wachtwoord in de database. Je hoeft dus wachtwoorden helemaal niet als blanke tekst op te

‘Elke developer behoort veiligheid van de code integraal in zijn werk mee te nemen’

slaan. Een ander voorbeeld is encryptie. In welke laag in de architectuurstack pas je encryptie toe? Met name bij services in de cloud is het belangrijk om goed te kijken welk verkeer encrypted is en welk verkeer niet. Bij machine naar machinecommunicatie zal de ontwikkelaar moeten nagaan hoe de data over de lijn gaat. KPN kan zeggen dat ze voorziet in encryptieboxen, maar die bereiken alleen de onderste lagen in de stack. Alle functionaliteit daarboven is niet versleuteld.”

Individuen bepalen uitrol Linux-kernel

Terwijl de softwarecode van Microsoft door het omvangrijke gebruik voor hackers een aantrekkelijk jachtterrein vormt, is deze naar de mening van Vlietland niet per definitie onveiliger dan bijvoorbeeld open source code, zoals Linux. “Het hangt sterk af van de situatie, zoals de ontwikkelaar, het testtraject en wie er allemaal naar de code heeft gekeken. Ik zie Linux een steeds grotere rol spelen in de serverwereld. Ook in de Microsoft Azurecloud groeit Linux als kool. Ik ben zelf een

actieve participant in de Linuxgemeenschap, maar zie ook dat met die grote verzameling kleine communities met verschillende belangen de uitrol van nieuwe, stabielere productieversies van de kernel een proces is dat sterk afhangt van individuen. Op zich geweldig natuurlijk, maar de vraag is wel wie nu precies verantwoordelijkheid neemt.”

Als voorbeeld van een veiligheidsrisico onder Linux komt Vlietland met Heartbleed, de hack in de populaire open source OpenSSL cryptografische softwarebibliotheek. Het protocol schreef een controlemethodiek voor met een ‘ping’ vanuit de client naar een server, waar het bericht werd gekopieerd en teruggestuurd. De client kon de lengte van het bericht aangeven met een variabele. Maar binnen deze component had de schrijver van de software niet gecheckt of die variabele wel het daadwerkelijk meegestuurde aantal te kopiëren bytes aangaf. Vlietland heeft de gewraakte in C ontwikkelde code bekeken en begrijpt waarom niemand in de open source gemeenschap de kwetsbaarheid eerder had opgemerkt.

Andere opzet compiler voor veilige broncode

Hij verwacht ook niet dat partijen die de kernel gebruiken en distribueren, zoals Red Hat, Suse, Mint en Ubuntu, de software uit den treure testen alvorens deze voor productie vrij te geven. Dat is simpelweg niet meer te doen door de schaal waarop de Linuxkernel overal in embedded systemen met een mix van pluriforme componenten is geconfigureerd. Dat varieert van apparaten voor industriële toepassingen of medische applicaties tot aan mediaspelers voor thuisgebruik.

Toch hamert Vlietland erop dat overal en altijd in de leveringspijplijn van software de betrokkenen zich committeren aan de veilige code, bijvoorbeeld door met OWASP 10 (Open Web Application Security Project) de kwaliteit en veiligheid te testen, zoals statische en dynamische codeanalyses of het afvangen van verkeerde code door bijvoorbeeld een fout XMLbericht naar een API te sturen en te kijken wat er wordt teruggegeven.

Er zijn partijen die zich daar wel mee bezighouden. Hij weet te vertellen dat onder Kali Linux er 600 penetratietools worden gedistribueerd, die voor de verschillende lagen van het OSImodel pentesten activeren. Daaronder valt ook een ’sniffer’ onder de naam Wireshark voor het loggen en traceren van TCP/ IPverkeer. Jan Vlietland denkt niet dat het heel sterk inperken van de vrijheden van programmeurs invloed heeft op de veiligheid van softwarecode. Wie vroeger in assembler programmeerde, had op machineniveau meer instructies tot zijn beschikking dan een Cprogrammeur of tegenwoordig een Java of .Netontwikkelaar. De productiviteit is met de hogere programmeertalen inmiddels wel sterk toegenomen, omdat standaard aspecten als het opzetten van arrays en pointers goed zijn geregeld. Maar omdat daardoor de gerealiseerde programmacode meer complexe systemen aanstuurt, is de software er naar de mening van de NISIdocent niet veiliger op geworden. “We zijn nu meer afhankelijk van de compilers. Qua opzet zijn die van nature niet gemaakt om per se veilige code te maken. Ik vind het wel een interessante gedachte om vanuit een andere opzet van de compilers programmatuur veiliger te maken. Daarvoor moet je dan wel de hele stack herzien.”

Authenticode op embedded software

Nu is het overgrote deel van de gebruikte software bij veel bedrijven niet meer in eigen beheer ontwikkeld. Standaard pakketsoftware geniet al heel lang de voorkeur. Bij softwareselectie is het voor de afnemers in alle geledingen van een onderneming vanwege het gebrek aan kennis over het programmeren van code in eigen huis, heel lastig om de programmatuur te kwalificeren op security. Voor de bestuurlijk administratieve omgeving heeft de Stichting Zeker Online dat wel gedaan voor een reeks financiële applicaties.

Op de fabrieksvloer in de OTomgeving wil men nog wel eens de eigen plc’s programmeren, maar voor het overgrote deel zijn ook daar buitenstaanders verantwoordelijk voor de bouw, implementatie en technische ondersteuning van software voor de ICS/ SCADAvoorzieningen. Bij de meeste productiemachines wordt die software niet apart geladen vanaf een server, maar is die ingebouwd in de hardware. Het is gebruikelijk dat de ontwikkelaar de veiligheid van embedded softwarecode garandeert door middel van een elektronische handtekening of waarborg, een zogeheten private key.

‘In Duitsland vertrouwen veel machinebouwers op het beveiligingsmechanisme van WibuSystems, zeker nu hun producten dankzij Industrie 4.0 onderhevig zijn aan de gevaren van cybercriminaliteit’

Een onafhankelijke, betrouwbare partij verbindt de identiteit van de ontwikkelaar aan een goedkeuringsverklaring, een certificaat via een public key. Op die manier kan de gebruiker de betrouwbaarheid van de software verifiëren. Zo bevat Windows functionaliteit (Authenticode) om een computergebruiker erop te wijzen dat hij of zij software activeert van onbekende oorsprong, dus niet voorzien van de

certificaatkenmerken. Dit authenticatiemechanisme met certificaten, private keys en public keys wordt door het van oorsprong Duitse WibuSystems toegepast bij een als CodeMeter aangeduid platform voor het beveiligen en tevens in licentie uitgeven van software. Wie geld wil verdienen met het leveren van software, wil er zeker van zijn dat degene die deze gebruikt er ook voor betaalt. Met de controle daarop voorkom je niet alleen ongeoorloofd gebruik, maar bescherm je de software ook tegen hacken.

Wie de private en public key niet gecombineerd kan overleggen, zoals vastgelegd in bijvoorbeeld een certificaat, komt er eenvoudigweg niet in. Dus al zou je software gratis willen verstrekken, dan is het nog handig om er een licentiebeveiligingsmodel omheen te bouwen, want dan weet je zeker dat ook niemand de code kan misbruiken of stelen. CodeMeter kan onder meer broncode afschermen, door deze onder te brengen in een encrypted omgeving: een container. Die kan bestaan uit een chip, apart geplaatst van CPU en het werkgeheugen, een zogeheten Trusted Platform Module (TPM) of in de vorm van aanvullende hardware, een externe USBdongle. Via binding met de unieke kenmerken van de betreffende computer is het laadproces van de uitvoerbare softwarecode alleen op te starten vanuit een dongle, corresponderend met het betreffende computersysteem.

Broncode encrypten via hash-codes

Beveiliging aan de bron impliceert dat softwareontwikkelaars met behulp van een CodeMeterSDK ook hun broncode kunnen beveiligen door het encrypten van vitale delen. Het proces onderscheidt de volgende stappen:

• calculatie van de hashwaarden van de originele software code • de ondertekening van de hashwaarde met de private key van de software leverancier • encryptie van de originele software volgens een sleutel, gegenereerd uit de ‘seed value’ (pseudorandom nummergenerator) van de oorspronkelijke software; aanmaken van een geheime sleutel van de leverancier, gecombineerd met parameters geselecteerd door de software uitgever • hechting van het publieke deel van het handtekeningcertificaat aan de versleutelde software.

Tussen de diverse lagen vanaf de hardware of bootloader, operating

system, applicatie runtime en de geconfigureerde applicatie vinden er voortdurend controlechecks plaats met ofwel een dongle als extern referentiepunt naar de geldige licentiewaarden van de software ofwel een referentie met de recent aangekondigde CodeMeter cloudvariant.

In Duitsland vertrouwen veel machinebouwers op het WibuSystems beveiligingsmechanisme. Zeker nu hun producten in de stroom van Industrie 4.0 in toenemende mate onderhevig zijn aan de gevaren van cybercriminaliteit. Al veel langer deden deze fabrikanten hun voordeel met deze technologie bij de export van hun producten met afscherming van intellectual property (IP) naar vooral Aziatische afnemers.

Ook in Nederland zijn er diverse internationaal opererende bedrijven die op deze manier hun digitaal vastgelegde gedachtegoed beschermen tegen ongeoorloofd kopiëren door partijen in landen, waar ze copyrights zien als het recht om ongeremd te kopiëren. Het blijft raadselachtig waarom ze bij ASML deze of een soortgelijke methode niet hebben toegepast om hun intellectuele eigendomsrechten beter te beschermen tegen diefstal.

Het Outsystems-platform omvat een voortdurend aangroeiende lijst van cyberrisico’s en controlemechanismen op de beveiliging daartegen

Low-code elimineert foute code

“Veiligheid wordt vaak door ontwikkelaars ‘vergeten’, aangezien ze veel meer met de functionaliteit van de op te leveren applicaties bezig zijn”, aldus RobertJan de Roos, directeur marketing & business development bij Phact. Deze in Venray gevestigde ITdienstverlener richt zich vooral op de logistieke bedrijfstak. Daarbij bedienen de systeembouwers van Phact zich veelvuldige van het populaire lowcode platform van Outsystems.

“Doordat binnen OutSystems security volledig is geïntegreerd, wordt voorkomen dat er mogelijke lekken ontstaan, zegt De Roos. ”Maar dit neemt niet weg dat onze ontwikkelaars nog steeds over security moeten nadenken. Met de standaard in het platform aanwezige integratie vermijden we de eerste risico’s. Dankzij het ontwikkelen in OutSystems leveren we ook code die vrij is van fouten. Een van de mogelijke ingangen voor hackers zijn ontwikkelfouten die makkelijk ’op straat’ komen te liggen. Het platform dwingt de ontwikkelaar om code te generen zonder fouten. Foute code laat zich gewoonweg niet publiceren.”

Lowcode platformen als Outsystems en Mendix bieden de middelen om heel snel applicaties te maken zonder echt te coderen. Anders dan bij het gebruik van een traditionele programmeertaal volstaat een visuele ontwikkelingsaanpak voor het in elkaar zetten van een toepassing, ook wel aangeduid als Rapid Application Development (RAD). De ontwikkelaar selecteert de benodigde functionele componenten uit een bibliotheek en sleept ze naar een visueel weergegeven workflow. Daarmee leent

de methode zich bij uitstek voor appontwikkeling door een grotere groep mensen dan alleen programmeurs. Met een grondige kennis van de te automatiseren materie moet dat lukken. In het algemeen komen toepassingen sneller en een stuk efficiënter tot stand.

Omdat ook niet professionele applicatiebouwers bedrijfskritische systemen kunnen opleveren, hebben de Portugese bedenkers van OutSystems security tot uitgangspunt van hun geesteskind gemaakt. Het platform omvat een voortdurend aangroeiende lijst van cyberrisico’s en controlemechanismen op de beveiliging daartegen. De makers van het lowcode platform claimen dat hun ingebouwde voorzieningen bescherming bieden tegen de OWASP 10 van ’Most Critical Web Application Security Risks’, en de OWASP 10 van mobiele bedreigingen.

En dat is niet gering als je beseft dat 48 procent van de ontwikkelaars het belang van security inziet, maar onvoldoende tijd heeft om er aandacht aan te schenken (cijfers uit het 2018 DevSecOpsrapport). Forrester boezemt nog meer angst in met de voorspelling dat belangrijke merknamen op de wereldmarkt in 2019 naar schatting 25 procent van hun waarde gaan verliezen als gevolg van cyberaanvallen.

Code herstellen met DevSecOps

Met de vermelding van het DevSecOpsrapport komen we terecht bij een ander fenomeen dat inmiddels een stempel drukt op de ontwikkeling van softwarecode. DevOps (Development and Operations) is het maken van software en het gelijktijdig testen daarvan in de conceptuele fase, zodat daarna via een iteratief proces aan de hand van functionele prioriteit direct de operationele oplevering plaatsvindt. Volgens Andre Sibov, country manager van het Beneluxkantoor van Eficode, kwam door het ontwikkelen van softwarecode via een infrastructurele agile werkwijze security veel eerder bovendrijven dan bij de oude watervalmethode, toegepast in een omgeving met organisatorische silo’s. “Tussen de fase van codeontwikkeling en het operationeel in gebruik nemen zit geen barrière meer. DevSecOps is een holistische benadering van een gedachtengoed waarbinnen security het fundament vormt voor alle vormen van software engineering”, zegt Sibov.

De Finse DevOpsspecialisten van Eficode voorzien in een product dat luistert naar de naam ROOT. Dit is een raamwerk van tools voor de automatische leveringspijplijn van software. Die elimineert zoveel mogelijk de fouten van de manuele ontwikkelmethode door het automatisch genereren, testen en uitrollen van programmacode. Andere automatische functies binnen ROOT richten zich op statische codeanalyse, afhankelijkheid scans (JFrog Xray of Sonatype NexusIQ) en infrastructuur als code.

Volgens de specialisten van Eficode leert de praktijk dat DevSecOps werkt. Zij citeren daarbij een observatie van CSO Magazine uit 2018. Zij geven aan dat een gemiddelde afnemer van tools voor softwareontwikkeling ongeveer 174 dagen nodig heeft om een zwakke plek te repareren in reeds operationele code. Dat gebeurt dan met behulp van dynamische analysegereedschap.

Bij die organisaties waar DevSecOps was geïmplementeerd nam de reparatie maar 92 dagen in beslag. In sommige gevallen duurde zonder DevSecOps het herstelwerk niet meer dan 10 dagen, maar dan betrof het slechts 15% van alle uiteindelijk te repareren zwakheden. Ook hier scoorden de DevSecOpsadepten beter, door binnen dezelfde 10 dagen maar liefst 53 procent van de risicodragende plekken in de code op te sporen en te versterken.

FRANS VAN DER GEEST is journalist