Software kan eenvoudig veiliger

Hoewel de slechte kwaliteit van software de oorzaak is van vrijwel alle beveiligings­problemen, wordt nog maar weinig gekozen voor secure coding. Wie daar wel voor kiest, kan gebruik maken van een groot aantal methodes, checklists en frameworks. “Denk niet alleen over de use-cases, maar ook over de abuse-cases.”

“Software is het meest complexe product dat we als mens in elkaar hebben geknutseld”, zegt dr. ir. Erik Poll, universitair hoofddocent digital security aan de Radboud Universiteit. “Er zijn heel veel regels code en heel veel combinaties in die code. Dat kun je niet meer overzien. Toch is pas sinds 2000 enigszins het besef gekomen dat bijna alle beveiligingsproblemen hun oorzaak vinden in de kwaliteit van de software. Menselijke factoren zijn een belangrijke oorzaak, maar voor software geldt dat nog sterker. Toen zag je de boeken over softwarebeveiliging komen en pakten bedrijven als Microsoft de beveiliging veel serieuzer aan.”

Dat de fouten die gemaakt worden makkelijk voorkomen hadden worden, blijkt overduidelijk uit de OWASP Top 10, de tien meest kritische beveiligingsproblemen voor webapplicaties. Al jaren staan injecties en cross site scripting bovenaan deze ranglijst. Poll: “SQL-injecties vormen een heel triest voorbeeld. Er is een heel goede standaard manier om die te voorkomen, maar die wordt vrijwel niet toegepast. Men heeft er gewoon het geld niet voor over. Bij software is ook moeilijk te kwantificeren hoe groot de schade is die door lekken kan worden veroorzaakt. In de fysieke wereld is het veel makkelijker in te schatten dat een hek om een gebouw nodig is en hoeveel dat kost. Wat dat betreft hebben banken een voordeel; die kunnen heel goed de schade van een lek voorspellen, wat de beveiliging moet kosten en wat die oplevert.”

 

Goed begin

Secure coding is de oplossing. Hierbij wordt software ontwikkeld rekening houdend met de veel gemaakte fouten – om die dan uiteraard te voorkomen. Er zijn zeer veel methodes voor secure coding voorhanden en Poll kan niet één favoriete methode aanwijzen. Een globale werkwijze kan hij wel geven. “Zoek eerst goed uit wat veel gemaakte fouten zijn bij het coderen van de software die jij aan het maken bent en van het platform waarop dit gebeurt. Het maakt verschil of het om een webapplicatie gaat, systeemsoftware, mobiele apps of Scada-achtige systemen, en in welke taal of voor welk OS je ontwikkelt. Daarvoor is tegenwoordig veel informatie voorhanden, denk aan de lijsten van OWASP en SANS, en boeken als 24 Deadly Sins of Software Security en Building Secure Software van Gary McGraw. Ook probeert Microsoft met de software development lifecycle systematiek aan te brengen in secure coding.”

De lijstjes met standaard secure coding-problemen zijn nuttig, vindt Poll. “Ze vormen een goed begin, maar je moet je wel realiseren dat als je die lijsten hebt afgewerkt, je nog verder moet kijken. Bovendien, waterdicht maak je het er niet mee. Zeker in grote en complexe programma’s zal dat niet lukken. Daar kunnen heel subtiele typefoutjes in zitten en die kun je niet van tevoren vinden.

Daarbij komt dat je niet alleen fouten in het coderen kunt maken – die zijn er in theorie wel uit te halen – maar er kunnen ook fouten in het ontwerp sluipen, en die haal je er niet uit. Een besturingssysteem is zo complex; het heeft een interface met zeer veel interacties. Het is niet van tevoren te zien dat een bepaalde interactie ongewenste effecten heeft.

Mijn advies is daarom dat je niet alleen over de use-cases moet nadenken, maar ook over de abuse-cases. Voorkomen is beter dan genezen. Sony, bijvoorbeeld, had misschien moeten overwegen aan het eind van het jaar zijn e-mails te wissen.”

 

Niet alleen OWASP Top 10

Ook Rob van der Veer, security principal bij SIG, pleit ervoor dat security vanaf het begin van het ontwikkelproces wordt meegenomen en niet pas achteraf. Methodes en lijsten die bruikbaar zijn voor secure coding zijn er genoeg. Van der Veer adviseert daarbij om niet te volstaan met de alom bekende OWASP Top 10. “Dat is wel een goed vertrekpunt, maar de OWASP Top 10 beschrijft fouten alleen globaal. Dan krijg je iets als: gevoelige gegevens mogen niet gelekt worden. Wat er wél moet gebeuren, is niet duidelijk en daar kun je je leverancier dan ook niet op afrekenen. Een stuk beter is de ASVS-lijst van OWASP. Die gaat dieper, is grondiger en biedt best practices. Een groot deel van de security-opdrachtgevers kent deze lijst niet.”

Martin Knobloch, lid van het Nederlandse chapter van OWASP, raadt evenmin aan de top 10 van OWASP als een checklist te gebruiken voor secure coding. “De OWASP Top 10 heeft voor naamsbekendheid van OWASP gezorgd, maar wordt vaak verkeerd gebruikt. Het is een awareness-document, bedoeld om de aandacht voor software security te verhogen en de impact van de risico’s voor de business zichtbaar te maken. Het was nooit bedoeld als een checklist.” Hij raadt aan naar de andere – gratis – producten van OWASP te kijken.

Andere lijsten zijn bijvoorbeeld de richtlijnen voor webapplicaties van het NCSC en de daarop gebaseerde beveiligingsnormen van het CIP. SIG heeft in een onderzoek samen met de Radboud Universiteit alle gangbare lijsten gebundeld in een securitymodel waarbij voor vijf verschillende niveaus wordt aangegeven welke maatregelen nodig zijn. Een vijf-sterren systeem past integraal alle relevante best practices toe. Daar kan vervolgens op worden gecertificeerd.

 

Comply or explain

Wie naar zo’n lijst grijpt, kan dat het beste combineren met een beleid van ‘comply or explain’, vindt Van der Veer. “Er zijn altijd zaken die niet volgens de regels kunnen. De ontwikkelaar moet dat uitleggen aan de opdrachtgever en die moet dat ook accepteren bij een goede uitleg.”

De oorzaak daarvan ligt niet alleen bij de leveranciers of ontwikkelafdelingen, de opdrachtgever heeft vaak ook geen inzicht in wat er mis kan gaan. Van der Veer: “Als de opdrachtgever meer en beter communiceert maak dat een ontwikkelaar beter bewust van de problemen die mogelijk zijn. We zien wel dat men risico-analyses maakt, maar die worden dan vervolgens niet altijd gecommuniceerd naar de leverancier van de software. Een opdrachtgever zou moeten aangeven hoe sterk iets beveiligd moet worden, zodat de ontwikkelaar daar rekening mee kan houden. Maar zowel leveranciers als opdrachtgevers zijn hierin nog niet zo specifiek en compleet.”

Daarbij komt dat veel opdrachtgevers er vanuit gaan dat een leverancier sowieso veilig bouwt. Maar als de druk hoger wordt, gaat een leverancier zich houden aan contracten en daar staat juist vaak onvoldoende in. Van der Veer: “Een opdrachtgever moet expliciet zijn, maar ook weer niet te veel op de stoel van de ontwikkelaar gaan zitten. Dat kan storend zijn en onnodig beperkend. Dus niet: gebruik methode X voor het opslaan van wachtwoorden, maar geef het niveau van beveiliging aan dat gewenst is. Wil een leverancier toch methode Y gebruiken, dan moet hij dat uitleggen – comply or explain. Ga uit van de professionaliteit van de leverancier.”

Hij raadt aan het niveau van een leverancier vooraf te toetsen. “Eis daarvoor inzage in relevante aspecten van het ontwikkelproces, zoals de coding guidelines. Kijk goed welke adequaat zijn – en doe dat al bij de aanbesteding.”

 

Vroeg code toetsen

Een professionele opdrachtgever moet ook op de juiste manier de opgeleverde code toetsen, benadrukt Van der Veer. “Pentesten is zeker nuttig, maar niet genoeg. Dat doe je pas als het klaar is. Niet alleen is het dan vaak al een drukke tijd waardoor het in de verdrukking kan komen, achteraf herstellen is moeilijk. Doe het dus liever eerder.” Daarbij komt dat het een illusie is dat je met pentesten secure coding zou kunnen afdwingen. “Je kijkt waar de gaten zitten en daar plaats je een hek voor. Pentesten is kijken naar wat je van buitenaf kunt doen. Vergelijk dat met de beveiliging van een bankgebouw. De pentest kijkt naar de ramen en de deuren aan de buitenkant. Een inspecteur kijkt binnen, naar wat voor sloten gebruikt zijn en of de kluis misschien open staat. Het moet allebei gebeuren.”

Code review is daarom volgens Van der Veer essentieel. Belangrijk daarbij is dat ook gecontroleerd wordt of de aanbevelingen zijn opgevolgd. “Review van de broncode is makkelijker herhaalbaar te maken. We hebben een methode ontwikkeld die security van software zichtbaar maakt en kijkt naar veranderingen ten opzichte van de vorige versie zodat niet steeds de volledige code op zijn kop moet. Het is niet goedkoop, want het blijft mensenwerk. Dat geldt ook voor goede pentesting. Een grondige Code Review is duurder, hoewel dat weer relatief goedkoper wordt als het herhaald wordt.”

Er is ook goede tooling beschikbaar voor automatische code reviewing, zoals van HP en IBM. Die checken bijvoorbeeld of bepaalde functies niet op een zwarte lijst staan. Van der Veer tekent daarbij aan: “Zulke tools zijn zeker nuttig, maar ze kunnen de werking van software maar tot op zekere hoogte interpreteren. Zo’n tool ziet niet welke denkfouten zijn gemaakt. Het komt er toch op neer dat specialisten de broncode moeten uitpluizen en dat moet met gevoel voor de context gebeuren.”

Hun bevindingen moeten vertaald worden naar prioriteiten. “Software bevat vaak honderden kwetsbaarheden maar daarvan zijn er dan enkele echt belangrijk. Dan moet een diagnose volgen van die bevindingen. Zo vind je de oorzaak en daarmee kun je de organisatie uiteindelijk verbeteren."

 

Raamwerk voor certificering

Een van de meer recente initiatieven die het opleveren van veilig ontwikkelde software willen bevorderen, is het Framework Secure Software. Het framework is een initiatief van iComply uit Woerden dat zich specialiseert in advies op het gebied van veilig software ontwikkelen. iComply heeft het raamwerk ondergebracht in een aparte organisatie, de Secure Software Foundation. Dit framework moet een kader bieden voor het ontwikkelen van veilige software. Het is onafhankelijk van de gebruikte programmeertaal, het type applicatie en de gebruikte ontwikkelmethodiek. Ontwikkelaars kunnen voor hun software een certificaat krijgen, als ze aan de eisen voldoen. Bij de ontwikkeling van het framework is samengewerkt met onder meer het ministerie van Economische Zaken, ECP, TNO, NCTV en NCSC. “Centrale vraag daarbij was of we een framework konden definiëren dat diende als basis voor zowel het ontwikkelen van veilige software als het auditen ervan. Die pilots zijn deels door EZ gefinancierd en op basis daarvan hebben wij samen met EZ een ‘Normenkader/Framework Secure Software’ ontwikkeld”, zegt Fred Hendriks, ad interim voorzitter van de Secure Software Foundation en directeur van iComply.

Het framework beschrijft wat een ontwikkelaar moet doen in de vier fasen van softwareontwikkeling: requirements, architecture, coding en testing. De ontwikkelaar moet dit aantoonbaar gedaan hebben. Op basis van het framework kunnen auditors op termijn toetsen of de software inderdaad veilig is ontwikkeld. Dat levert dan een Secure Software Certificate op.

Eisen die het framework stelt zijn bijvoorbeeld dat het gebruik van de Secure Coding Standard die voor de gebruikte taal geldt, wordt afgedwongen. Ook is threatmodelling van groot belang; dit houdt in dat de ontwikkelaar op voorhand zo veel mogelijk bedreigingen boven water haalt en vastlegt wat hij er aan kan en wil doen.

Het is zeker niet het eerste certificaat waarmee ontwikkelaars de kwaliteit van hun software kunnen aantonen. Bekende namen op dit terrein zijn de Software Improvement Group en het Duitse TüV. De Secure Software Foundation verschilt daarvan, stelt Hendriks. “Bij die partijen gaat het niet om een open framework. Zij bepalen zelf de criteria op basis waarvan ze testen, daar hebben andere partijen geen invloed op. Bij ons gaat het er juist om dat je die criteria vaststelt op basis van input uit het veld. Wij denken dat we met name daardoor een breed draagvlak voor ons framework zullen krijgen. Daarnaast is onze focus software security en niet de functionaliteit van de software, ook dat is een verschil.

Een ander verschil met bijvoorbeeld TüV is dat zij alleen aan het eind van een ontwikkeltraject testen, terwijl de insteek van de SSF is dat al in de ontwerpfase aandacht wordt besteedt aan security-aspecten.”

De belangstelling voor het Framework Secure Software is groot, stelt Hendriks. “We hebben 19 februari een formele presentie van onze plannen gegeven, op het ministerie van EZ en daar waren alle grote spelers uit de branche aanwezig, zowel aanbieders als afnemers. Namen als Shell, ING, Achmea, Ordina, Lloyds Register, KPN, De Belastingdienst, SQS, TomTom, beroepsverenigingen, zo kan ik nog wel even doorgaan. Die belangstelling onderstreept dat we met iets wezenlijks bezig zijn.”

Voor audits biedt het framework rond de 25 controls. De website van de Secure Software Foundation vermeldt nog geen auditors die gekwalificeerd zijn voor het controleren op deze punten. “We hebben ontdekt dat de meeste IT-auditors dit niet kunnen auditen, want het vereist kennis van software engineering. Daar moet dus nog aan gewerkt worden”, verklaart Hendriks.

 

TOOLS

Grip op Secure Software Development Een methode van het CIP in samenwerking met DIG en een twintigtal andere partijen zoals opdrachtgevers, leveranciers en specialisten. De tool is bestemd voor opdrachtgevers die hun leveranciers willen aansturen maar niet willen inbreken op de ontwikkelprocessen. Grip op SSD beschrijft standaard beveiligingseisen, geeft een overzicht van de vereiste contactmomenten en de processen voor onder meer toetsing en het bijhouden van risico’s. Ook biedt het een gemeenschappelijke taal zodat opdrachtgever en leverancier beter kunnen communiceren.

OWASP Cheat Sheets De Cheat Sheets beschrijven hoe men kwetsbaarheden kan vinden, wat het probleem daarvan is en hoe men de kwetsbaarheden kan voorkomen. Dit beschrijft de techniek, maar ook proces en design.

OWASP ASVS (Application Security Verification Standard Project) Dit is een raamwerk voor het ontwikkelen van veilige applicaties. Het gaat er niet van uit dat alles veilig moet zijn, maar bepaalt aan de hand van het risicoprofiel van de applicatie welke maatregelen in elk geval genomen moeten worden.

OWASP Testing Guide Deze beschrijft van intake tot rapportage hoe een (web)applicatie op veiligheid getest kan worden: pentesting.

SAMM, het Software Assurance Maturity Model Dit model is gericht op het management. Het biedt een raamwerk voor het verbeteren van de volwassenheid van het ontwikkelproces. Voor de gebieden beleid (governance), bouw (construction), verificatie (verification) en uitrollen (deployment) wordt in drie practices in drie niveaus onderscheiden wat men kan doen om het softwareontwikkelproces meetbaar te verbeteren.

Tag

SIG

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag