De Column: Walter Belgers - September 2016

Update 28 - de Column - September 2016

In iedere Madison Gurkha Update vindt u een leuke en informatieve column, die de lezer een verfrissende kijk biedt op een uit eenlopende onderwerpen rondom IT-beveiliging. Deze keer laten we Walter Belgers aan het woord

DE COLUMN

Je hebt ‘makers’ en ‘brekers’



Onlangs had ik een discussie met een klant over het uitvoeren van beveiligingstests. Er werd binnen dat bedrijf zoveel software geschreven, dat er te weinig capaciteit was om dat allemaal getest te krijgen. De vraag was in hoeverre je de ontwikkelaars dat werk kunt laten doen. Dat is een interessante vraag, waar ik niet direct een antwoord op had.

Zonder twijfel kunnen ontwikkelaars bijdragen aan het beveiligen van hun software, bijvoorbeeld als ze getraind worden in het schrijven van veilige software. Maar ik merk dat er over het algemeen nog weinig aandacht is voor veilig programmeren in opleidingen. Door de software van ontwikkelaars op beveiliging te testen en deze te gebruiken als basis voor een opleiding veilig programmeren, kun je de kwaliteit al behoorlijk verbeteren.

Als alle ontwikkelaars zo’n opleiding achter de rug hebben, heb je echter nog geen duidelijke indicatie van hoe de software erbij staat. Er kunnen allerlei redenen zijn waarom beveiliging ondergeschikt raakt. En het probleem met beveiliging is dat als het ontbreekt, je dat niet direct merkt. Je zult dus op de een of andere manier toch moeten testen.

Je kunt die tests integreren in het ontwikkelproces. De ontwikkelaars maken toch al ‘use cases’ die automatisch bij elke release uitgevoerd worden. Je kunt daarnaast ook ‘abuse cases’ maken. Je test dan bijvoorbeeld of je na het klikken op ‘uitloggen’ inderdaad uitgelogd bent. Op deze wijze kun je problemen in de beveiliging in een vroeg stadium detecteren en oplossen.

Ik raad aan om inderdaad ontwikkelaars (additioneel) op te leiden in het schrijven van veilige code en het maken van abuse cases. Het maken van abuse cases en uitvoeren van tests hierop zal in het ontwikkelproces moeten worden ingebed.

Terugkomend op de originele vraag: is dit voldoende? Kunnen verdere beveiligingstests achterwege blijven? Mijn antwoord zal niet als een verrassing komen: nee, dat is niet voldoende.

In mijn loopbaan ben ik in contact gekomen met veel security consultants en veel ontwikkelaars. Als wij security consultants aannemen, kijken we naast de hoeveelheid kennis en kunde, ook naar de persoonskenmerken van de kandidaten. Om goed beveiliging te kunnen testen, is een bepaalde aanpak nodig, waarbij je creatief nadenkt over mogelijke aanvalsvectoren.

(Ethische) hackers zijn mensen die dit tot levenswijze hebben gepromoveerd. Een hacker is iemand die bijzonder veel interesse heeft in hoe techniek werkt en vooral ook hoe je met die techniek iets kunt doen wat de ontwikkelaar niet voor ogen had. Hackers zien een draadloos toetsenbord en stellen zichzelf meteen de vraag hoe je berichten kunt afluisteren of injecteren. Vervolgens gebruiken ze SDR (Software Defined Radio) om de signalen op te vangen. Als SDR-apparaat gebruiken ze misschien een USB TV-dongle, waarvan andere hackers al hebben uitgevonden hoe je daar een goedkope universele ontvanger van kunt maken.

Bij het zien van een stuk software gaat een hacker automatisch nadenken over hoe je het iets kunt laten doen wat niet de bedoeling is. Om een randgeval te verzinnen waar de ontwikkelaar niet aan gedacht had. Software-ontwikkelaars hebben vaak niet die ‘drive’ om alle aandacht te richten op wat juist niet de bedoeling is. Zij richten zich op het zo goed mogelijk implementeren van wat juist wel de bedoeling is. Ik noem de ontwikkelaars ook wel gekscherend ‘makers’ en hackers ‘brekers’.

Daarmee komen we bij het antwoord op de originele vraag. Ik denk dat je ontwikkelaars heel goed kunt opleiden om veilig te programmeren en om abuse cases te ontwikkelen. Het is niet eenvoudig om een ontwikkelaar om te vormen van iemand die graag software maakt naar iemand die graag software kapot maakt (de fouten vindt). Gelukkig zijn er wel uitzonderingen die de regel bevestigen en een aantal daarvan werken bij Madison Gurkha.

Wil je de fouten oplossen die je vindt door onverwachte randgevallen op te speuren, dan ontkom je uiteindelijk niet aan het (ook) inzetten van professionals die daarin getraind zijn en meer kunnen doen dan de standaard tests die geautomatiseerde tools doen. Het uitgangspunt blijft nog steeds om zo vroeg mogelijk in het ontwikkeltraject fouten te vinden en op te lossen. Met dat inzicht wens ik u veel leesplezier.


Walter Belgers
Partner, principal security consultant

@Secura 2018
Webdesign Studio HB / webdevelopment Medusa