Cybersecurity

Beveiliging van websites, apps en infrastructuur, getest door ethische hackers

Elke website, app en API is een doelwit, ook die van een KMO. Op deze pagina leest u wat een penetration test precies inhoudt, welke kwetsbaarheden we het vaakst vinden, hoe een test verloopt, wat die kost en hoe u er bewijs voor NIS2, ISO 27001 en GDPR mee levert.

  • Handmatig getest volgens OWASP, PTES en NIST
  • Altijd met schriftelijke toestemming en afgebakende scope
  • Rapport voor directie én ontwikkelaars
  • Hertest en verklaring inbegrepen

Waarom dit belangrijk is

De meeste aanvallen zijn geautomatiseerd en kiezen geen doelwit uit

Bots scannen het hele internet op bekende kwetsbaarheden, standaardwachtwoorden en vergeten testomgevingen. Wie een zwakke plek heeft, wordt gevonden, ongeacht de grootte van het bedrijf.

Een geslaagde aanval kost zelden alleen geld. Het kost klantvertrouwen, dagen tot weken operationele stilstand, meldingsplicht bij de Gegevensbeschermingsautoriteit en vaak ook contractuele boetes. Een pentest is de goedkoopste manier om te weten waar u staat, vóór iemand anders het u vertelt.

Wij bouwen zelf software en IoT-oplossingen. Daardoor testen we niet alleen, maar begrijpen we ook waarom kwetsbaarheden ontstaan en hoe ze op een haalbare manier opgelost worden. Dat merkt u in het rapport en in de debriefing.

Kwetsbaarheden die scanners missen

Autorisatiefouten, business-logicafouten en ketens van kleine zwakheden vind je enkel met handmatig werk. Dat is waar de echte impact zit.

Bewijs voor klanten en toezichthouders

Een onafhankelijk rapport en hertestverklaring zijn bruikbaar in NIS2-, ISO 27001- en leveranciersaudits.

Uitleg die uw team meeneemt

We overlopen elk rapport met uw ontwikkelaars of leverancier, zodat de fixes juist en volledig zijn.

Wat we testen

Van bedrijfswebsite tot industriële installatie

Per type doelwit gebruiken we de passende methodiek en checklist. Hieronder leest u wat er concreet onderzocht wordt.

Websites & webapplicaties

Van bedrijfswebsite en webshop tot klantenportaal en SaaS-platform. We testen handmatig volgens OWASP Top 10 en OWASP ASVS, met focus op wat een scanner mist: business logic, autorisatie en ketens van kleine fouten.

  • Authenticatie & sessiebeheer
  • Autorisatie per rol en object (IDOR)
  • Injecties (SQL, XSS, command, template)
  • Uploads, exports en bestandsverwerking
  • Betaal- en bestelflows
  • Security headers & configuratie

Mobiele apps (iOS & Android)

Native, Flutter of React Native: we analyseren de app, de opslag op het toestel en vooral de backend-API waarmee ze praat. Getest volgens OWASP MASVS en MASTG.

  • Lokale opslag van tokens en data
  • Certificate pinning & transportbeveiliging
  • Reverse engineering & tampering
  • Biometrie en authenticatieflows
  • Deeplinks en intents
  • API-autorisatie vanuit de app

API’s & koppelingen

REST, GraphQL, SOAP en webhooks. De API is vaak de echte toegangspoort tot uw data, ook als de frontend er netjes uitziet. Getest volgens de OWASP API Security Top 10.

  • Broken object level authorization (BOLA)
  • Broken function level authorization
  • Mass assignment & excessieve data
  • Rate limiting en brute force
  • Token- en API-keybeheer
  • Schema- en inputvalidatie

Cloud & Microsoft 365

Configuratie-review van Azure, AWS en Microsoft 365: identiteiten, rechten, opslag, netwerken en logging. De meeste cloudincidenten zijn geen exploits maar misconfiguraties.

  • Identiteiten, MFA en conditional access
  • Overbodige rechten en service principals
  • Publieke storage en databases
  • Netwerksegmentatie en firewalls
  • Secrets en sleutelbeheer
  • Logging en alerting

Externe & interne infrastructuur

Wat ziet een aanvaller vanaf het internet, en hoe ver geraakt iemand die al binnen is, bijvoorbeeld via een besmette laptop? Inclusief Active Directory en netwerksegmentatie.

  • Aanvalsoppervlak & blootgestelde services
  • Verouderde software en bekende CVE’s
  • Active Directory & privilege escalation
  • Wachtwoordbeleid en credential reuse
  • Laterale beweging tussen systemen
  • VPN, RDP en remote access

IoT, embedded & OT

Slimme toestellen, industriële apparatuur en het bijhorende platform: firmware, hardware-interfaces, communicatieprotocollen en de cloudkant. Dezelfde expertise die we inzetten bij onze eigen IoT-projecten.

  • Firmware-analyse en update-mechanisme
  • Debug-poorten (UART, JTAG) en opslag
  • MQTT, Modbus, BLE en LoRaWAN
  • Provisioning en certificaten per toestel
  • Segmentatie tussen OT en IT
  • Cloudplatform en device management

Testvormen

Black box, grey box of white box?

Het verschil zit in hoeveel voorkennis en toegang de tester krijgt. Meer inzage betekent meer diepgang per testdag, minder inzage betekent een realistischer beeld van een buitenstaander.

Geen voorkennis

Black box

We krijgen enkel een URL of IP-adres, net als een echte buitenstaander. Realistisch beeld van wat een opportunistische aanvaller bereikt, maar minder diepgang per testdag.

Geschikt voor: Externe infrastructuur, eerste kennismaking met pentesten.

Volledige inzage

White box

Toegang tot broncode, architectuur en configuratie. Hiermee vinden we ook subtiele fouten in cryptografie, autorisatielogica en afhankelijkheden die van buitenaf onzichtbaar blijven.

Geschikt voor: Kritieke systemen, secure code review, compliance-trajecten.

Kwetsbaarheidsscan, pentest of red team?

Kwetsbaarheidsscan

Geautomatiseerd, snel en goedkoop. Toont bekende kwetsbaarheden en misconfiguraties, maar geen logische fouten en geen bewijs van impact. Ideaal als periodieke aanvulling.

Penetration test

Handmatig werk van een ethische hacker, aangevuld met tools. Vindt ook autorisatie- en business-logicafouten en toont de echte impact aan. De standaard voor applicaties en infrastructuur.

Red team

Een volledige, langdurige aanvalssimulatie inclusief phishing en social engineering, gericht op uw detectie en respons. Voor organisaties die al een volwassen basis hebben.

OWASP Top 10

De kwetsbaarheden die we het vaakst vinden

De OWASP Top 10 is de internationale referentie voor de meest kritieke risico’s in webapplicaties. Elke pentest die we uitvoeren dekt minstens deze categorieën. Hieronder uitgelegd zonder jargon, met een voorbeeld uit de praktijk.

  1. A01

    Broken Access Control

    Gebruikers kunnen data of functies bereiken waar ze geen recht op hebben. De vaakst gevonden en meest impactvolle categorie.

    Voorbeeld: Het factuurnummer in de URL aanpassen en zo de facturen van een andere klant downloaden.

  2. A02

    Cryptographic Failures

    Gevoelige gegevens worden onversleuteld opgeslagen of verzonden, of met zwakke algoritmes en slecht sleutelbeheer.

    Voorbeeld: Wachtwoorden met MD5 gehasht, of een API-sleutel die in de JavaScript van de website staat.

  3. A03

    Injection

    Invoer van de gebruiker wordt zonder controle in een query, commando of pagina geplaatst. SQL-injectie en cross-site scripting (XSS) zijn de bekendste vormen.

    Voorbeeld: Een zoekveld waarmee de volledige klantendatabase uitgelezen kan worden.

  4. A04

    Insecure Design

    Fouten in het ontwerp zelf, die geen enkele code-fix oplost. Ontbrekende threat modeling, onveilige businessflows, te veel vertrouwen in de client.

    Voorbeeld: Een kortingscode die onbeperkt herbruikt kan worden omdat de check enkel in de browser gebeurt.

  5. A05

    Security Misconfiguration

    Standaardwachtwoorden, debug-modus in productie, open cloud-buckets, uitgebreide foutmeldingen of ontbrekende security headers.

    Voorbeeld: Een admin-paneel van een framework dat nog bereikbaar is op /admin met het standaardwachtwoord.

  6. A06

    Vulnerable & Outdated Components

    Bibliotheken, frameworks en servers met bekende kwetsbaarheden (CVE’s) die niet geüpdatet zijn.

    Voorbeeld: Een verouderde PDF-bibliotheek waarmee een aanvaller code op de server uitvoert.

  7. A07

    Identification & Authentication Failures

    Zwakke login- en sessiemechanismen: geen bescherming tegen brute force, voorspelbare sessietokens, onveilige wachtwoordreset.

    Voorbeeld: Een resetlink die niet vervalt en voor elke gebruiker voorspelbaar is.

  8. A08

    Software & Data Integrity Failures

    Code of updates worden geladen zonder integriteitscontrole; onveilige deserialisatie; CI/CD-pipelines zonder bescherming.

    Voorbeeld: Een build-pipeline die scripts van een extern domein uitvoert zonder controle van de inhoud.

  9. A09

    Security Logging & Monitoring Failures

    Aanvallen worden niet gelogd of niemand kijkt naar de logs. Daardoor blijven inbraken maanden onopgemerkt.

    Voorbeeld: Duizenden mislukte loginpogingen waar geen enkele melding van komt.

  10. A10

    Server-Side Request Forgery (SSRF)

    De server kan overtuigd worden om zelf verzoeken te doen naar interne systemen of cloud-metadata.

    Voorbeeld: Een “afbeelding ophalen via URL”-functie die de interne cloudcredentials prijsgeeft.

Voor API’s, mobiele apps en IoT gebruiken we de specifieke OWASP-lijsten (API Security Top 10, MASVS, ISVS) als aanvulling.

Verloop

Zo verloopt een pentest bij N-innovative

Van scoping tot hertest in vijf stappen. U weet op elk moment wat er gebeurt, wat u in handen krijgt en wanneer. Een gemiddelde webapplicatie- of API-test neemt 3 tot 10 werkdagen in beslag.

Dienst penetration testing
  1. Scoping & toestemming

    We bepalen samen wat getest wordt (domeinen, apps, IP-ranges, rollen), wat niet, welk testtype en in welk venster. Alles wordt vastgelegd in een opdracht en toestemmingsverklaring van de eigenaar van de systemen.

    U ontvangt: Scopedocument, planning en noodcontacten.

  2. Verkenning

    We brengen het aanvalsoppervlak in kaart: subdomeinen, technologieën, endpoints, gebruikersrollen, externe diensten. Vaak levert dit al verrassingen op: vergeten testomgevingen of oude portalen.

    U ontvangt: Overzicht van het aanvalsoppervlak.

  3. Handmatig testen & exploitatie

    De kern van het werk. We zoeken kwetsbaarheden en buiten ze gecontroleerd uit om de echte impact aan te tonen, zonder data te beschadigen of uw operatie te verstoren. Kritieke bevindingen melden we meteen, niet pas in het rapport.

    U ontvangt: Onmiddellijke melding van kritieke bevindingen.

  4. Rapportage

    Per bevinding: ernst (CVSS), bewijs, reproductiestappen, impact voor uw bedrijf en concrete remediatie. Met een managementsamenvatting voor directie en details voor ontwikkelaars.

    U ontvangt: Pentestrapport in PDF, binnen de week na afronding.

  5. Debriefing & hertest

    We overlopen het rapport met uw team of leverancier en beantwoorden vragen. Na de fixes controleren we of elke kwetsbaarheid effectief gesloten is en leveren we een hertestverklaring.

    U ontvangt: Hertestrapport en verklaring voor klanten of auditors.

Het rapport

Een rapport dat uw team kan gebruiken, geen scan-dump

Het verschil tussen een goede en een slechte pentest zit in het rapport. U krijgt één document dat zowel de directie als de ontwikkelaars verder helpt.

01

Managementsamenvatting

Risicobeeld in gewone taal: wat is de grootste blootstelling, wat moet eerst, wat is de algemene volwassenheid.

02

Scope en methodiek

Wat precies getest werd, hoe, in welke periode en met welke beperkingen, zodat het rapport bruikbaar is voor auditors.

03

Bevindingen met CVSS-score

Elke kwetsbaarheid met ernst (CVSS 4.0), getroffen component, bewijs (screenshots, requests) en reproductiestappen.

04

Impact voor uw bedrijf

Niet enkel “XSS gevonden”, maar wat een aanvaller er effectief mee bereikt: data-exfiltratie, accountovername, fraude.

05

Concrete remediatie

Per bevinding een oplossing op maat van uw technologie, met code- of configuratievoorbeelden waar nuttig.

06

Hertestverklaring

Na de fixes: welke bevindingen gesloten zijn, met bewijs. Een document dat u aan klanten of auditors kunt bezorgen.

Security-by-design

Beter dan testen achteraf: veilig bouwen vanaf het begin

Een pentest toont wat misliep. Nog beter is zorgen dat het niet misloopt. Dit passen we toe in elke applicatie en IoT-oplossing die we zelf bouwen, en helpen we uw team of leverancier invoeren.

Threat modeling

Vóór de eerste regel code: wie zou dit systeem aanvallen, hoe, en wat staat er op het spel? Zo belanden de juiste maatregelen in het ontwerp.

Secure coding & code review

Richtlijnen per technologie, parametrized queries, inputvalidatie, veilige standaardbibliotheken en een security-check in elke code review.

Security in de CI/CD-pipeline

Dependency scanning, statische analyse (SAST), geheimen-detectie en geautomatiseerde tests bij elke build. Kwetsbare componenten komen niet in productie.

Hardening & configuratie

Security headers, TLS-configuratie, minste privilege, gescheiden omgevingen, geheimenbeheer en logging die bruikbaar is bij een incident.

Identiteit & toegang

MFA, single sign-on, rolgebaseerde toegang en sessiebeheer die bestand zijn tegen de aanvallen die we in pentests dagelijks zien.

Kwetsbaarheidsbeheer

Periodieke scans, opvolging van CVE’s in uw stack en een duidelijk proces om patches te prioriteren en uit te rollen.

Website of app laten bouwen?

Combineer ontwikkeling en pentest bij één partner

Onze ontwikkelaars kennen de aanvalstechnieken en onze testers begrijpen hoe software gebouwd wordt. Het resultaat: applicaties die bij oplevering al aantoonbaar veilig zijn.

Wet- en regelgeving

Bewijs voor NIS2, ISO 27001, GDPR en klantenaudits

Steeds meer bedrijven moeten aantonen dat hun beveiliging werkt, niet alleen dat ze een beleid hebben. Een onafhankelijke pentest met hertestverklaring is daarvoor het meest erkende bewijsstuk.

We leveren het technische luik: pentesten, kwetsbaarheidsbeheer, configuratie-reviews en secure development. Voor het beleidsmatige luik (risicoanalyse, procedures, certificatiebegeleiding) werken we samen met uw compliance-verantwoordelijke of een gespecialiseerde partner.

NIS2

De Europese richtlijn, in België omgezet via de NIS2-wet, verplicht essentiële en belangrijke entiteiten tot risicobeheer, incidentmelding en het beoordelen van de effectiviteit van hun maatregelen. Periodieke pentests en kwetsbaarheidsscans zijn de gangbare manier om dit aantoonbaar te maken, ook voor leveranciers in de keten van een NIS2-entiteit.

ISO 27001

De norm vraagt om technische kwetsbaarheidsbeheersing en onafhankelijke beoordeling van de informatiebeveiliging. Onze rapporten sluiten aan op de controls uit Annex A en zijn bruikbaar als bewijs tijdens de certificatie-audit.

GDPR / AVG

Artikel 32 verplicht “passende technische maatregelen” en een procedure om die regelmatig te testen en te evalueren. Een pentest van systemen die persoonsgegevens verwerken is daar de meest directe invulling van.

Klant- en leveranciersaudits

Steeds meer bedrijven vragen hun softwareleveranciers om een recent pentestrapport of hertestverklaring vóór ze een contract tekenen. Wij leveren een samenvatting die u kunt delen zonder gevoelige details prijs te geven.

Timing

Wanneer laat u uw website of app testen?

Vóór de livegang

Een nieuwe website, app of portaal testen voor er echte klantgegevens in zitten. Fouten zijn dan nog goedkoop te herstellen.

Na een grote wijziging

Nieuwe loginflow, betaalmodule, API of cloudmigratie: elke structurele verandering verdient een gerichte hertest.

Jaarlijks of per kwartaal

Periodiek testen vangt nieuwe kwetsbaarheden in afhankelijkheden en sluipende configuratiefouten op. Voor NIS2 en ISO 27001 is dit de norm.

Op vraag van een klant of auditor

Een leveranciersaudit, aanbesteding of certificatie vraagt een onafhankelijk rapport. Wij leveren het in een vorm die u kunt delen.

Na een incident of vermoeden

Is er iets gebeurd, of twijfelt u? Een gerichte test bevestigt of de deur echt dicht is en of er nog andere openstaan.

Bij overname van software

Software of een leverancier overnemen? Een technische due diligence met pentest en code review voorkomt dure verrassingen.

Ethisch en wettelijk

Alleen met toestemming, altijd vertrouwelijk

We testen uitsluitend systemen waarvan de eigenaar ons schriftelijk toestemming geeft, binnen een afgesproken scope en testvenster. Bevindingen delen we enkel met de opdrachtgever en bewaren we versleuteld. Op vraag tekenen we vooraf een geheimhoudingsovereenkomst. We werken niet voor particulieren en voeren geen tests uit op systemen van derden.

Meldt u zelf een kwetsbaarheid in onze systemen? Lees dan ons security.txt-beleid voor een veilig meldkanaal.

Veelgestelde vragen

Vragen over cybersecurity en pentesting

Staat uw vraag er niet bij? Stel ze via het contactformulier; u krijgt binnen één werkdag antwoord van een technisch expert.

Alle veelgestelde vragen
Wat kost een pentest van een website of app?

De prijs hangt af van de omvang: aantal schermen of endpoints, gebruikersrollen en testtype. Een gerichte grey-box pentest van een gemiddelde webapplicatie of API start doorgaans vanaf enkele duizenden euro en neemt 3 tot 10 werkdagen in beslag. Na een korte scoping krijgt u een vaste prijs, inclusief rapport, debriefing en hertest.

Hoe vaak moet ik mijn website of applicatie laten testen?

Minstens jaarlijks, en na elke grote wijziging zoals een nieuwe loginflow, betaalmodule of cloudmigratie. Voor organisaties onder NIS2 of met een ISO 27001-certificaat is een jaarlijkse pentest aangevuld met periodieke kwetsbaarheidsscans de gangbare praktijk.

Wat is het verschil tussen een kwetsbaarheidsscan, een pentest en een red team?

Een kwetsbaarheidsscan is geautomatiseerd en toont bekende zwakheden, zonder bewijs van impact. Een pentest combineert tools met handmatig werk van een ethische hacker die ook logische fouten en ketens van kwetsbaarheden vindt en de impact aantoont. Een red team simuleert een volledige aanval over langere tijd, inclusief phishing en fysieke toegang, om uw detectie en respons te testen.

Kan een pentest mijn website of productieomgeving verstoren?

We testen bij voorkeur op een staging-omgeving die identiek is aan productie. Testen we toch op productie, dan gebeurt dat in een afgesproken venster, met gecontroleerde technieken, zonder denial-of-service en met een directe communicatielijn naar uw team. Kritieke bevindingen melden we onmiddellijk.

Is een pentest verplicht onder NIS2 of GDPR?

Geen van beide schrijft letterlijk “pentest” voor. NIS2 vereist wel dat u de effectiviteit van uw beveiligingsmaatregelen beoordeelt, en GDPR (artikel 32) vraagt een procedure om technische maatregelen regelmatig te testen. Een pentest is in de praktijk de meest erkende manier om aan beide te voldoen en dit aan toezichthouders en klanten aan te tonen.

Wat gebeurt er na het pentestrapport?

We overlopen het rapport met uw team of uw softwareleverancier, geprioriteerd op risico. Daarna lost u (of wij, als u dat wenst) de bevindingen op. Vervolgens hertesten we en leveren we een verklaring dat de kwetsbaarheden gesloten zijn, bruikbaar voor klanten en auditors.

Kunnen jullie ook de website testen die een extern bureau voor ons bouwde?

Ja, dat is zelfs een van de meest voorkomende situaties. U blijft als eigenaar verantwoordelijk voor de beveiliging. We stemmen de test af met uw leverancier, delen de bevindingen in een vorm die ontwikkelaars direct kunnen gebruiken en hertesten na hun fixes.

Is ethisch hacken legaal in België?

Ja, binnen een duidelijk kader. Wij testen uitsluitend met schriftelijke toestemming van de eigenaar van de systemen en binnen een afgebakende scope. Daarnaast kent België sinds 2023 een wettelijk kader voor gecoördineerde kwetsbaarheidsmelding via het Centrum voor Cybersecurity België (CCB), waar wij ons aan houden wanneer we buiten een opdracht iets vaststellen.

Weten waar u staat?

Vraag een vrijblijvende scoping van uw pentest aan

Beschrijf kort welke website, app of infrastructuur u wilt laten testen. U krijgt binnen enkele dagen een vaste prijs met aanpak, planning en wat er in het rapport zit.