De infrastructuurkant van je bedrijf is top beveiligd. Je leunt voldaan achterover om je behaalde ISO-certificeringen te bekijken die je zojuist in een mooi lijstje gestopt hebt. Maar wat je niet weet, is dat er een paar dagen eerder een nieuwe website 'live' is gegaan waarin een grote kwetsbaarheid zit. Het duurt niet lang voordat deze kwetsbaarheid door kwaadwillenden ontdekt is. Als gevolg kan het zijn dat privacygevoelige informatie op straat komt te liggen. Opeens loop je achter de feiten aan, is er een kans op grote boetes en heeft de reputatie van je bedrijf een flinke klap gekregen. Dit is een horror-scenario waar je liever niet aan denkt, maar wat je zeker wilt voorkomen.

Auteur: Marcel Dassen

Marcel is Test Consultant bij APG. ISTQB Expert op gebied van Test Improvement. Houdt van verandering en dynamiek. Motto: Durf nieuwe dingen te ondernemen, lach om je fouten en doe het vervolgens beter.

De harde cijfers

Het is niet toevallig dat je gehackt bent via een applicatie, want applicaties zijn vaak zwakke plekken in de beveiliging. Securitybedrijf Veracode stelt in een van zijn infographics dat 70% van alle webapplicaties ten minste één van de 10 meest voorkomende kwetsbaarheden bevat. Verder geeft Gartner aan dat 75% van de mobiele apps uit 2015 niet door basale securitytests heen komt. Niet gek dat Content Delivery bedrijf Akamai in 2015 stelde dat het aantal aanvallen via de applicatielaag met meer dan 25% per jaar groeit. Dit betekent dat je een relatief groot risico loopt dat een hacker een kwetsbaarheid uitbuit via de applicatielaag. Een eerste stap naar een goede beveiliging is dat je je hier bewust van bent.

Waarom zijn webapplicaties dan zo kwetsbaar?

Voordat data vanaf je applicatie naar nullen en enen is vertaald, worden er zeven lagen doorlopen, gepresenteerd in het OSI-model. Elke laag kan kwetsbaarheden bevatten, maar toch is vooral de applicatielaag kwetsbaar. Het is goed om te weten waarom dat zo is.

Ten eerste is de applicatielaag voor veel mensen toegankelijk. Denk aan een website of app, deze is juist gemaakt om met de gebruikers ervan te communiceren.

Verder is de applicatielaag aan veel veranderingen onderhevig. Niet alleen doordat er nieuwe wensen ingebouwd worden, maar ook doordat er nieuwe, soms complexe, technologieën toegepast worden. Die nieuwe technologieën bevatten misschien risico's die je nog niet onderkend hebt of ze worden simpelweg nog niet zo goed toegepast door onwetendheid.

Welke risico's loop je?

Sommige mensen denken bij security aan hele complexe zaken, die alleen hackers begrijpen. Maar dat is een misvatting. Ook de eenvoudige tekstuele melding die je teruggeeft aan een gebruiker op een inlogpagina kan een risico vormen. Stel dat jouw applicatie of website bij een foute aanmeldingspoging zegt: "Uw wachtwoord moet bestaan uit 8 tot 10 karakters", dan is dat al een cadeautje voor een hacker. Hij weet waar hij zich op kan richten en hoeft geen overuren te maken.

Daarnaast zijn er uiteraard ook meer 'technische risico's'. De 'Open Web Application Security Project' (afgekort: OWASP) heeft voor ons al in kaart gebracht wat de 10 meest kritieke risico's zijn en vertelt je zelfs hoe je ze kunt voorkomen.

Om aan te geven hoe simpel je moet denken zal ik hier alleen nummer 1 uit deze lijst beschrijven: SQL Injection. SQL Injection is een veel voorkomend risico en is voor hackers ook vrij makkelijk 'uit te buiten'. Om deze reden staat deze al vele jaren op nummer 1. Zodra jouw applicatie met een achterliggende database communiceert, kunnen hackers proberen om commando's (queries) op de database uit te voeren via de invoervelden van jouw applicatie, met alle gevolgen van dien. Het gekke is dat het nog zo vaak voorkomt, terwijl deze aanval heel makkelijk te voorkomen is door het toevoegen van invoercontroles!

"Ok, we zijn kwetsbaar.... Wat kan ik beter niet doen?"

"Laten we snel een tool kopen die alles kan scannen van de OWASP top 10!"

Helaas, een tool is niet de heilige graal waar je naar op zoek bent. Tools kunnen je helpen, maar zullen niet alles vinden en maken jou niet slimmer.

"Huur snel een bedrijf in met security expertise om een scan uit te voeren!"

Op zich een goed idee, je kunt of wilt niet op alle gebieden een specialist zijn. Maar zou het niet veel goedkoper zijn, als je zelf al veel kwetsbaarheden gevonden of liever voorkomen had? En wie zegt me dat zo'n scan niet alleen het topje van de ijsberg laat zien?

"Maar wat kan ik dan wel doen?"

Het woord 'ik' vind ik in dit vraagstuk belangrijk, want daar gaat het al mis. Beveiliging is niet iets voor één persoon. Goede beveiliging begint bij nadenken over security door alle teamleden. Vaak kan een awareness-sessie over risico's een mooi begin zijn.

De volgende stap is het opnemen van security als vast onderwerp in het ontwikkelproces. Alleen kijken naar het testproces is niet voldoende. Het is goedkoper om kwetsbaarheden te voorkomen. Er zijn gratis frameworks die je hierbij kunnen helpen. Een bekende is de Secure Development Lifecycle van Microsoft. De essentie daarvan is wat mij betreft dat je hiermee een andere mindset creëert. Je gaat bewust nadenken over security requirements, legt vast wat een applicatie juist niet mag (abuse cases i.p.v. use cases), brengt bedreigingen in kaart (threat model) en je houdt hier bij het ontwikkelen en testen rekening mee.

Je bent nu al een heel eind gekomen, door in feite alleen awareness te kweken en in het proces na te denken over bedreigingen. Hierna of parallel hieraan zou ik (sommige) ontwikkelaars en testers verder opleiden. Er zijn namelijk risico's die je alleen kunt voorkomen of testen met specifieke technische bagage. Denk bijvoorbeeld aan de SQL Injections die ik hierboven beschreef. Een geavanceerde security scan kun je nog altijd door een externe partij laten uitvoeren. Deze scan wordt nu een stuk effectiever doordat je zelf al maatregelen hebt genomen in je ontwikkelproces en je de resultaten van de scan beter kunt interpreteren.

En dan is nu eindelijk het moment aangebroken om te kijken naar tooling!