Cybersecurity wordt al snel geassocieerd met grote organisaties, uitgebreide IT-afdelingen en forse beveiligingsbudgetten. Toch zijn veel kleinere en middelgrote bedrijven inmiddels sterk afhankelijk van digitale systemen. Klanten loggen in op een portaal, medewerkers werken in de cloud, webshops verwerken bestellingen en betalingen en steeds meer bedrijfsprocessen verlopen via webapplicaties en API’s.
Daarmee ontstaat ook een serieus digitaal aanvalsoppervlak.
De vraag is alleen: betekent dit dat ieder MKB-bedrijf een pentest nodig heeft? Niet per se. Een bedrijf met een eenvoudige informatieve website loopt andere risico’s dan een SaaS-bedrijf met honderden gebruikers, verschillende gebruikersrollen en gevoelige klantgegevens.
Een pentest is daarom vooral zinvol wanneer de mogelijke impact van een beveiligingslek groot genoeg is om onafhankelijk te willen laten toetsen of de bestaande beveiligingsmaatregelen daadwerkelijk werken.
In dit artikel leggen we uit wanneer een pentest voor het MKB verstandig is, wat je kunt laten testen en met welke kosten je ongeveer rekening moet houden.
Wat is een pentest?
Een pentest, voluit penetratietest, is een gecontroleerd beveiligingsonderzoek waarbij een pentester probeert echte kwetsbaarheden te vinden en waar mogelijk veilig aan te tonen wat daarmee kan worden bereikt.
Daarmee gaat een pentest verder dan een geautomatiseerde vulnerability scan.
Een vulnerability scanner kan bijvoorbeeld detecteren dat bepaalde software verouderd is of dat een beveiligingsheader ontbreekt. Een pentester kijkt ook naar de samenhang tussen verschillende onderdelen en naar kwetsbaarheden die niet eenvoudig automatisch te herkennen zijn.
Denk bijvoorbeeld aan een klantportaal waarbij iedere klant alleen zijn eigen facturen mag bekijken. Technisch kan de applicatie volledig up-to-date zijn, terwijl een fout in de autorisatie ervoor zorgt dat een ingelogde gebruiker door het aanpassen van een nummer in een API-request de factuur van een andere klant kan opvragen.
Juist dit soort kwetsbaarheden in autorisatie en businesslogica maken handmatig testen waardevol.
Heeft ieder MKB-bedrijf een pentest nodig?
Nee.
Voor een lokale onderneming met een eenvoudige website waarop alleen openingstijden en contactgegevens staan, is een uitgebreide penetratietest waarschijnlijk niet de eerste beveiligingsmaatregel waarin geïnvesteerd moet worden.
Dat verandert wanneer digitale systemen belangrijker worden voor de bedrijfsvoering of toegang bieden tot waardevolle gegevens en functionaliteiten.
Een pentest wordt bijvoorbeeld interessant wanneer je organisatie:
- een eigen webapplicatie of SaaS-platform heeft
- klanten of medewerkers laat inloggen op een portaal
- persoonsgegevens, financiële gegevens of andere vertrouwelijke informatie verwerkt
- gebruikmaakt van API’s voor belangrijke gegevensuitwisseling
- verschillende gebruikersrollen en rechten heeft
- een webshop exploiteert
- bedrijfskritische systemen vanaf het internet bereikbaar heeft
- een nieuwe applicatie binnenkort in productie neemt
- grote technische wijzigingen heeft doorgevoerd
- van een klant, auditor of zakelijke partner moet aantonen dat de beveiliging onafhankelijk is getest.
De omvang van het bedrijf is daarbij eigenlijk niet het belangrijkste criterium.
Een softwarebedrijf met twaalf medewerkers kan een platform beheren waarop gevoelige gegevens van duizenden gebruikers staan. Het beveiligingsrisico kan dan aanzienlijk groter zijn dan bij een onderneming met honderd medewerkers en nauwelijks publieke IT-systemen.
De juiste vraag is daarom niet:
“Zijn wij groot genoeg voor een pentest?”
maar:
“Wat kan er gebeuren als iemand misbruik maakt van een kwetsbaarheid in onze systemen?”
Wanneer is een pentest voor het MKB vooral zinvol?
Er zijn een aantal situaties waarin een pentest bijzonder veel waarde kan hebben.
Voor de livegang van een nieuwe applicatie
Een logisch moment om een pentest uit te voeren is voordat een nieuwe applicatie daadwerkelijk door klanten of medewerkers wordt gebruikt.
Tijdens de ontwikkeling ligt de nadruk begrijpelijkerwijs vooral op functionaliteit. Werkt de login? Kunnen klanten hun gegevens aanpassen? Worden betalingen goed verwerkt? Werkt de koppeling met het CRM?
Dat iets functioneel correct werkt, betekent echter niet automatisch dat het ook veilig is.
Een pentest vóór livegang geeft de mogelijkheid om kwetsbaarheden te herstellen voordat echte gebruikers en echte gegevens in het systeem aanwezig zijn.
Wanneer klanten kunnen inloggen
Zodra een applicatie gebruikersaccounts bevat, wordt authenticatie en autorisatie een belangrijk onderdeel van de beveiliging.
Een gebruiker moet niet alleen veilig kunnen inloggen. De applicatie moet bij iedere relevante actie ook controleren wat die specifieke gebruiker mag doen.
Dat wordt belangrijker wanneer er verschillende rollen zijn. Denk aan een medewerker, manager, beheerder, of aan verschillende klanten binnen hetzelfde SaaS-platform.
Een pentester onderzoekt dan bijvoorbeeld of een normale gebruiker beheerfunctionaliteit kan benaderen of gegevens van een andere klant kan bekijken of aanpassen.
Wanneer je gevoelige gegevens verwerkt
Niet ieder datalek heeft dezelfde impact.
Een lek van een publiek beschikbare productcatalogus is iets anders dan ongeautoriseerde toegang tot medische gegevens, personeelsdossiers, contracten, financiële informatie of persoonsgegevens van klanten.
Naarmate de gevoeligheid en hoeveelheid van de gegevens toenemen, wordt het belangrijker om onafhankelijk te laten controleren of de technische beveiliging daadwerkelijk voldoende is.
Na grote wijzigingen
Een applicatie die drie jaar geleden is getest, is waarschijnlijk niet meer dezelfde applicatie.
Nieuwe functionaliteiten, API-koppelingen, gebruikersrollen, cloudmigraties en wijzigingen in authenticatie kunnen allemaal nieuwe aanvalspaden introduceren.
Daarom is een pentest niet uitsluitend iets voor de eerste livegang. Ook een belangrijke release of architectuurwijziging kan een logisch moment zijn voor een nieuwe test.
Wanneer klanten of auditors erom vragen
Voor veel MKB-bedrijven komt de eerste concrete pentestvraag niet vanuit de eigen IT-afdeling, maar vanuit een klant, aanbesteding, audit of certificeringstraject.
Een zakelijke klant wil bijvoorbeeld zekerheid dat zijn gegevens veilig worden verwerkt en vraagt om een recent pentestrapport.
In zo’n situatie is het belangrijk om niet alleen “een pentest” te laten uitvoeren om een vinkje te kunnen zetten. De scope moet aansluiten op het risico waarover de klant of auditor zekerheid wil hebben.
Een test van alleen de publieke website zegt bijvoorbeeld weinig over de beveiliging van een achterliggend SaaS-platform waarin klantgegevens worden verwerkt.
Wat moet je als MKB-bedrijf laten pentesten?
Dat hangt volledig af van je digitale omgeving.
Een veelgemaakte fout is om de scope te bepalen op basis van wat eenvoudig te testen is in plaats van op basis van waar het grootste risico zit.
Voor de meeste MKB-organisaties vallen de belangrijkste systemen in een aantal categorieën.
Webapplicaties en klantportalen
Heeft je organisatie een eigen webapplicatie, dashboard, SaaS-platform of klantportaal, dan is een webapplicatie pentest vaak het meest logisch.
Daarbij wordt onder andere gekeken naar authenticatie, autorisatie, gebruikersrollen, invoerverwerking, sessiebeveiliging en businesslogica.
Vooral applicaties met meerdere gebruikers en rollen verdienen extra aandacht. Een kwetsbaarheid hoeft namelijk niet te betekenen dat een aanvaller zonder account direct kan inbreken. Ook een normale gebruiker die meer gegevens of functionaliteit kan benaderen dan bedoeld, kan een ernstig beveiligingsprobleem opleveren.
API’s
Moderne applicaties zijn vaak sterk afhankelijk van API’s.
Een web- of mobiele applicatie kan er aan de voorkant eenvoudig uitzien, terwijl tientallen API-endpoints op de achtergrond gegevens ophalen en wijzigen.
Bij een API pentest wordt daarom onder andere onderzocht of authenticatie en autorisatie goed worden afgedwongen en of gebruikers uitsluitend toegang hebben tot de gegevens en acties waarvoor zij bevoegd zijn.
Dat is bijvoorbeeld belangrijk bij SaaS-platformen waarbij gegevens van verschillende klanten strikt van elkaar gescheiden moeten blijven.
Cloudomgevingen
AWS, Azure en andere cloudplatformen bieden veel beveiligingsmogelijkheden, maar die moeten wel correct worden geconfigureerd.
Denk aan toegangsrechten, publiek bereikbare resources, opslag, secrets, netwerkconfiguratie en logging.
Wanneer een groot deel van de dienstverlening in de cloud draait, kan het daarom verstandig zijn om naast de applicatie ook relevante onderdelen van de cloudomgeving te laten toetsen.
Netwerken en infrastructuur
Niet ieder risico zit in een webapplicatie.
Een netwerk pentest richt zich bijvoorbeeld op systemen, services, netwerksegmentatie en mogelijke aanvalspaden binnen de infrastructuur.
Voor organisaties met eigen servers, kantoorinfrastructuur, VPN-toegang of andere bedrijfskritische netwerkdiensten kan dit relevanter zijn dan een uitgebreide webapplicatietest.
Webshops
In een webshop komen verschillende beveiligingsrisico’s samen. Er worden persoonsgegevens van klanten verwerkt, terwijl ook bestelprocessen, betalingen, kortingscodes en koppelingen met externe partijen onderdeel zijn van de applicatie.
Daarom is het belangrijk om niet alleen naar technische kwetsbaarheden te kijken, maar ook naar de werking van de webshop zelf. Kan een gebruiker bijvoorbeeld prijzen of aantallen manipuleren? Is een kortingscode vaker of op een andere manier te gebruiken dan bedoeld? Of kan een klant gegevens of bestellingen van andere klanten inzien
Wanneer is een vulnerability scan voldoende?
Een volledige pentest is niet voor iedere situatie noodzakelijk.
Een vulnerability scan kan een goede eerste stap zijn wanneer je vooral wilt weten of er bekende technische kwetsbaarheden of configuratieproblemen aanwezig zijn. Ook voor het periodiek identificeren van nieuwe kwetsbaarheden is geautomatiseerd scannen waardevol.
Het verschil met een pentest zit vooral in de diepgang. Een vulnerability scanner zoekt voornamelijk naar bekende kwetsbaarheden. Een pentester onderzoekt daarnaast hoe een systeem daadwerkelijk kan worden aangevallen en kijkt bijvoorbeeld naar autorisatie, businesslogica en of meerdere kwetsbaarheden samen tot een groter beveiligingsrisico kunnen leiden.
Bij een applicatie met accounts, verschillende gebruikersrollen, gevoelige data of complexe processen is het daarom verstandig om niet uitsluitend op een vulnerability scan te vertrouwen.
Wat kost een pentest voor een MKB-bedrijf?
De kosten van een pentest worden niet zozeer bepaald door het aantal medewerkers van je organisatie, maar door de omvang en complexiteit van wat getest moet worden.
Een kleine applicatie met beperkte functionaliteit, één gebruikersrol en een overzichtelijke technische scope kan relatief snel worden onderzocht. Een uitgebreid SaaS-platform met meerdere rollen, API’s, verschillende klantomgevingen en complexe autorisatielogica vraagt aanzienlijk meer testtijd.
Als globale indicatie liggen de kosten van een pentest vaak tussen de €2.500 en €15.000.
Voor een kleine applicatie met een beperkte scope ligt een pentest vaak rond de €2.500 tot €5.000. Voor uitgebreidere webapplicaties, API’s en klantportalen met meerdere gebruikersrollen en koppelingen is €5.000 tot €10.000 realistischer. Grote of complexe omgevingen kunnen daarboven uitkomen.
Het is belangrijk om deze bedragen als indicatie te zien. Twee applicaties die er aan de buitenkant vergelijkbaar uitzien, kunnen qua benodigde testinspanning sterk verschillen.
Wil je precies weten waardoor die prijsverschillen ontstaan? In ons uitgebreide artikel over pentest kosten leggen we uit hoe de prijs wordt opgebouwd en waar je op moet letten bij het vergelijken van offertes.
Waar wordt de prijs door bepaald?
Een belangrijke prijsfactor is de omvang van de scope.
Tien eenvoudige pagina’s zonder login vragen nu eenmaal minder testtijd dan een platform met tientallen functionaliteiten, meerdere API’s en verschillende gebruikersrollen.
Maar omvang alleen vertelt niet het hele verhaal.
Ook complexiteit telt zwaar mee.
Neem een SaaS-applicatie met drie gebruikersrollen en verschillende klanten binnen dezelfde omgeving. Een pentester moet dan niet alleen controleren of iedere functionaliteit technisch veilig is, maar ook of gebruikers hun eigen bevoegdheden niet kunnen overschrijden en of gegevens tussen klanten daadwerkelijk van elkaar gescheiden blijven.
Andere factoren die invloed hebben op de benodigde testtijd zijn onder meer:
- het aantal applicaties
- het aantal gebruikersrollen
- de hoeveelheid functionaliteit
- de complexiteit van autorisatie
- het aantal API-endpoints
- koppelingen met externe systemen
- de gebruikte cloudomgeving
- de gewenste testdiepgang
- beschikbare technische documentatie
Een goede offerte maakt daarom duidelijk wat daadwerkelijk wordt getest en hoeveel testinspanning daarvoor benodigd is.
Kijk daarom niet alleen naar de prijs, maar ook naar de testinspanning die daar tegenover staat. Een brede scope met weinig testtijd kan ten koste gaan van de diepgang van het onderzoek.
Wat levert een pentest concreet op?
Een goede pentest levert meer op dan een overzicht van wat er allemaal gevonden is.
Na afloop wil je antwoord hebben op vier vragen:
Waar zijn we kwetsbaar?
Hoe kan een aanvaller daar misbruik van maken?
Welke impact kan dat hebben op onze organisatie?
Daarom hoort een bruikbaar pentestrapport per relevante bevinding niet alleen een technische omschrijving te bevatten, maar ook de impact, reproduceerbare stappen en concrete aanbevelingen voor herstel.
Voor ontwikkelaars moet duidelijk zijn hoe een probleem kan worden gereproduceerd en opgelost. Voor management moet duidelijk zijn welke risico’s daadwerkelijk belangrijk zijn.
Na herstel van de bevindingen kan een hertest vervolgens aantonen of de kwetsbaarheden daadwerkelijk zijn verholpen.
Waar moet je op letten bij het aanvragen van een pentest?
Het vergelijken van pentestoffertes uitsluitend op prijs is lastig.
Een offerte van €3.000 en een offerte van €6.000 kunnen op papier allebei spreken over een “webapplicatie pentest”, terwijl de daadwerkelijke testinspanning sterk verschilt.
Vraag daarom in ieder geval naar de voorgestelde scope en aanpak.
Worden alle relevante gebruikersrollen getest? Vallen API’s binnen scope? Wordt businesslogica meegenomen? Hoeveel tijd is daadwerkelijk beschikbaar voor het handmatige onderzoek? Is rapportage inbegrepen? En wordt na het mitigeren van de bevindingen een hertest uitgevoerd?
Ook de gekozen testvorm en de informatie die je vooraf beschikbaar stelt kunnen verschil maken. Bij een black box, grey box of white box pentest krijgt de pentester in verschillende mate vooraf toegang tot informatie, accounts of technische documentatie
Met testaccounts, API-documentatie, een architectuuroverzicht en een duidelijke beschrijving van belangrijke functionaliteiten kan een pentester zijn tijd efficiënter besteden aan daadwerkelijk testen in plaats van het eerst volledig reconstrueren van de omgeving.
Een pentest hoeft voor het MKB niet groot te beginnen
Een pentest hoeft niet direct de volledige IT-omgeving van een bedrijf te omvatten.
Sterker nog: een kleinere, goed gekozen scope levert vaak meer waarde op dan een enorme scope waar onvoldoende testtijd tegenover staat.
Voor een SaaS-bedrijf kan het bijvoorbeeld verstandiger zijn om eerst het klantportaal, de API en de scheiding tussen klanten grondig te testen dan om tegelijkertijd iedere cloudresource en elk intern systeem aan dezelfde beperkte testinspanning toe te voegen.
Hetzelfde geldt voor een webshop. De grootste risico’s zitten mogelijk in klantaccounts, betalingen en bestelprocessen. Dat zijn dan logische onderdelen om prioriteit te geven.
Begin daarom bij de systemen waarvan misbruik daadwerkelijk impact zou hebben op je organisatie of klanten.
Hoe vaak moet een MKB-bedrijf een pentest uitvoeren?
Er bestaat geen universele frequentie die voor ieder bedrijf passend is.
Een jaarlijkse pentest wordt vaak als praktisch uitgangspunt gebruikt, maar de snelheid waarmee je omgeving verandert is minstens zo belangrijk.
Wanneer iedere week nieuwe functionaliteit wordt uitgerold, kan één test per jaar onvoldoende zijn. Bij een stabiele applicatie die nauwelijks verandert, kan dezelfde frequentie juist prima aansluiten op het risico.
Belangrijke momenten om een (nieuwe) pentest te overwegen zijn bijvoorbeeld:
- voor de livegang van een nieuwe applicatie of dienst
- na grote wijzigingen binnen een bestaande applicatie of omgeving
- wanneer de aard of gevoeligheid van de verwerkte gegevens verandert
- wanneer nieuwe systemen of functionaliteiten het aanvalsoppervlak aanzienlijk vergroten
- na een ernstig beveiligingsincident, wanneer onderzocht moet worden of vergelijkbare aanvalsmogelijkheden nog aanwezig zijn
- wanneer klanten, auditors of andere belanghebbenden actuele zekerheid over de beveiliging verlangen.
Het doel is niet om een kalender af te vinken, maar om te voorkomen dat grote veranderingen jarenlang ongetest blijven.
In ons artikel over hoe vaak je een pentest moet uitvoeren gaan we uitgebreider in op het bepalen van een passende testfrequentie.
Is een pentest de investering waard voor het MKB?
Dat hangt uiteindelijk af van het risico.
Voor een eenvoudige website zonder accounts of gevoelige gegevens kan een uitgebreide pentest buitenproportioneel zijn. Voor een MKB-bedrijf waarvan klanten dagelijks inloggen op een eigen platform, gevoelige gegevens opslaan of afhankelijk zijn van digitale dienstverlening, kan de afweging heel anders uitvallen.
Een pentest geeft geen garantie dat een systeem nooit gehackt kan worden. Dat is ook niet wat een serieuze pentester zou moeten beloven.
Wat een goede pentester wel doet, is onzekerheid verkleinen.
Je laat een onafhankelijke specialist actief zoeken naar zwakke plekken voordat iemand met verkeerde bedoelingen dat doet. Daarmee krijg je inzicht in kwetsbaarheden die tijdens de ontwikkeling, reguliere testen of geautomatiseerde scans over het hoofd zijn gezien.
De resultaten helpen om beveiligingsmaatregelen gericht te prioriteren op basis van de kwetsbaarheden en risico’s die tijdens het onderzoek zijn aangetoond.
Benieuwd wat voor jouw organisatie zinvol is?
Niet iedere MKB-organisatie heeft dezelfde pentest nodig. De juiste scope hangt af van je applicaties, infrastructuur, gegevens, gebruikersrollen en de risico’s die je wilt laten onderzoeken.
Securitytest.nl voert onafhankelijke pentesten uit op onder andere webapplicaties, API’s, cloudomgevingen, netwerken en webshops.
Tijdens een vrijblijvende intake kijken we samen naar je applicatie, omgeving en belangrijkste risico’s. Op basis daarvan bepalen we welke onderdelen relevant zijn om te testen en welke testdiepgang daarbij past. Zo krijg je een pentest die aansluit op jouw organisatie en besteed je de beschikbare testtijd aan de onderdelen die er daadwerkelijk toe doen.
Plan een vrijblijvende intake