Veel organisaties voeren regelmatig een vulnerability scan uit op hun websites, API's en webapplicaties. Dat is ook logisch. Een vulnerability scan kan snel inzicht geven in bekende kwetsbaarheden, configuratiefouten en verouderde softwareversies die aandacht verdienen.

Toch ontstaat hierdoor soms een misverstand.

Wanneer een vulnerability scan weinig of geen belangrijke bevindingen oplevert, ontstaat al snel het idee dat de applicatie veilig is. Vanuit technisch oogpunt lijkt daar ook weinig op af te dingen. De software is up-to-date, bekende kwetsbaarheden zijn niet aanwezig en de configuratie voldoet grotendeels aan de gebruikelijke best practices.

Toch worden juist in dit soort situaties tijdens een webapplicatie pentest regelmatig kwetsbaarheden gevonden die een scanner niet heeft gezien.

Niet omdat de scan verkeerd is uitgevoerd, maar omdat een vulnerability scan en een pentest naar verschillende soorten risico's kijken.

Waar een vulnerability scan sterk in is

Een vulnerability scan is ontworpen om bekende kwetsbaarheden op te sporen.

Denk bijvoorbeeld aan:

  • verouderde softwareversies;
  • bekende CVE's;
  • ontbrekende security headers;
  • TLS-configuratieproblemen;
  • publiek bereikbare services;
  • bekende misconfiguraties.

Dat soort controles zijn waardevol. Ze helpen organisaties om technische risico's snel zichtbaar te maken en vormen vaak een belangrijk onderdeel van vulnerability management.

Daarnaast zijn vulnerability scans relatief eenvoudig periodiek uit te voeren. Daardoor ontstaat continu inzicht in nieuwe kwetsbaarheden die binnen de omgeving verschijnen.

Voor veel organisaties is dat een belangrijke eerste verdedigingslinie.

Waarom een schone scan niet automatisch betekent dat een applicatie veilig is

Een vulnerability scan kijkt vooral naar wat herkenbaar is.

De scanner weet bijvoorbeeld dat een bepaalde softwareversie kwetsbaar is of dat een configuratie afwijkt van een bekende beveiligingsrichtlijn. Wat een scanner niet weet, is waarom een applicatie gebouwd is zoals hij gebouwd is en welke keuzes tijdens de ontwikkeling zijn gemaakt.

Juist daar ontstaan regelmatig risico's.

Neem bijvoorbeeld een klantportaal waarin gebruikers hun eigen gegevens kunnen bekijken. Technisch gezien kan zo'n applicatie volledig up-to-date zijn en geen enkele bekende kwetsbaarheid bevatten. Toch kan er een autorisatieprobleem aanwezig zijn waardoor een gebruiker gegevens van een andere klant kan opvragen.

Hetzelfde geldt voor webshops, reserveringssystemen, ledenomgevingen en API's.

Een kortingscode die onbeperkt herbruikbaar blijkt. Een bestelproces waarbij stappen kunnen worden overgeslagen. Een API die onvoldoende controleert welke gegevens mogen worden opgevraagd. Een gebruikersrol die meer rechten heeft dan de bedoeling was.

Dat zijn kwetsbaarheden die vaak niet voortkomen uit verouderde software, maar uit de manier waarop een applicatie is ontworpen of geïmplementeerd.

Een pentester onderzoekt hoe een applicatie zich laat misbruiken

Tijdens een webapplicatie pentest wordt niet alleen gekeken naar de gebruikte technologie, maar vooral naar het gedrag van de applicatie.

Hoe worden gebruikersrechten afgedwongen?

Welke gegevens kunnen worden opgevraagd?

Wat gebeurt er als invoer bewust wordt aangepast?

Zijn er functies die anders werken dan bedoeld?

Kan een gebruiker handelingen uitvoeren die eigenlijk niet mogelijk zouden moeten zijn?

Dat soort vragen vereisen menselijke analyse. Een pentester probeert daarbij niet alleen te begrijpen hoe een applicatie hoort te werken, maar onderzoekt ook wat er gebeurt wanneer iemand bewust buiten de gebaande paden beweegt.

Juist daardoor komen regelmatig kwetsbaarheden aan het licht die in geen enkele kwetsbaarhedendatabase voorkomen.

Vooral maatwerkapplicaties vragen om handmatig onderzoek

Hoe meer een applicatie aansluit op unieke bedrijfsprocessen, hoe kleiner de kans dat een geautomatiseerde controle alle relevante risico's ontdekt.

Dat geldt bijvoorbeeld voor:

  • klantportalen;
  • SaaS-platformen;
  • webshops;
  • reserveringssystemen;
  • maatwerkapplicaties;
  • API-platformen.

Deze systemen bevatten vaak functionaliteit die specifiek voor één organisatie is ontwikkeld. Een scanner heeft geen kennis van die processen en kan daarom moeilijk beoordelen of een bepaalde handeling logisch, veilig of toegestaan is.

Een pentester kan dat wel.

Niet omdat hij meer kwetsbaarhedendatabases heeft, maar omdat hij probeert te begrijpen hoe de applicatie werkt en waar de onderliggende aannames mogelijk niet kloppen.

Waarom organisaties vaak beide inzetten

In de praktijk vullen vulnerability scans en webapplicatie pentests elkaar goed aan.

Een vulnerability scan helpt om bekende technische kwetsbaarheden snel te signaleren en periodiek te controleren of nieuwe risico's zijn ontstaan. Een pentest richt zich juist op de risico's die buiten het bereik van geautomatiseerde controles vallen.

Organisaties die uitsluitend vertrouwen op vulnerability scans krijgen daardoor vaak een beperkt beeld van hun werkelijke risico's. Andersom is het ook niet verstandig om alleen een pentest uit te voeren en vervolgens nooit meer naar nieuwe technische kwetsbaarheden te kijken.

De meeste volwassen beveiligingsprogramma's combineren daarom beide vormen van onderzoek.

Niet omdat ze hetzelfde doen, maar juist omdat ze elkaar aanvullen.

Een vulnerability scan vertelt welke bekende kwetsbaarheden aanwezig zijn. Een webapplicatie pentest laat zien hoe een applicatie zich gedraagt wanneer iemand actief probeert die te misbruiken.

En juist dat verschil blijkt in de praktijk vaak groter dan vooraf wordt gedacht.