Wanneer organisaties aan cybersecurity denken, gaat de aandacht vaak direct naar kwetsbare software. Verouderde systemen, ontbrekende patches en bekende CVE’s krijgen veel aandacht.
Dat is logisch. Kwetsbare software kan immers grote risico’s opleveren.
Maar in de praktijk ontstaat een groot deel van de impactvolle beveiligingsproblemen niet door ingewikkelde exploits of onbekende zero-days. Ze ontstaan door systemen die verkeerd zijn ingericht.
Een database die bereikbaar is vanaf het internet. Een opslaglocatie die te ruim openstaat. Een beheerinterface die publiek toegankelijk is. Een gebruiker of serviceaccount met meer rechten dan nodig.
De software zelf kan volledig up-to-date zijn. Toch kan de omgeving onveilig zijn door de manier waarop systemen, rechten en koppelingen zijn ingericht.
Juist dat maakt configuratiefouten zo gevaarlijk.
Wat zijn configuratiefouten?
Configuratiefouten zijn fouten in de inrichting van systemen, applicaties of infrastructuur.
Het gaat dus niet om een programmeerfout in de software zelf, maar om de manier waarop die software wordt gebruikt, gekoppeld of beschikbaar gemaakt.
Denk aan cloudopslag die publiek toegankelijk is, adminpanelen die vanaf internet bereikbaar zijn, te ruime rechten voor gebruikers of services, ontbrekende netwerksegmentatie of standaard wachtwoorden.
Dit soort fouten ontstaan vaak niet door één bewuste keuze. Ze ontstaan meestal geleidelijk. Een instelling wordt tijdelijk ruimer gezet om iets werkend te krijgen. Een testomgeving blijft online staan. Een oude koppeling wordt vergeten. Een serviceaccount krijgt ruime rechten omdat dat sneller is dan precies uitzoeken welke rechten nodig zijn.
Op dat moment lijkt het praktisch.
Later wordt het een risico.
Waarom kwetsbare software vaak sneller zichtbaar is
Kwetsbare software heeft één belangrijk verschil met configuratiefouten: het probleem is vaak herkenbaar.
Er is een bekende kwetsbaarheid. Er is een CVE. Een vendor publiceert een patch. Vulnerability scanners herkennen de versie. Beheerders krijgen een melding dat iets moet worden bijgewerkt.
Dat maakt kwetsbare software niet minder ernstig, maar wel concreter.
Een organisatie kan zien dat een systeem achterloopt. Er kan een patchproces worden gestart. Er kan prioriteit worden gegeven op basis van ernst, business impact, beschikbaarheid van exploits en blootstelling aan het internet.
Bij configuratiefouten werkt dat anders.
Daar is niet altijd een duidelijke melding voor. Er is vaak geen update die het probleem oplost. Het systeem blijft gewoon functioneren. Gebruikers merken niets. Monitoring slaat niet altijd aan.
Een verkeerde instelling ziet er van binnenuit vaak uit als een werkende omgeving.
Dat is precies waarom dit soort fouten lang kunnen blijven bestaan.
Waarom configuratiefouten vaak lang onopgemerkt blijven
Configuratiefouten veroorzaken meestal geen storing of foutmeldingen.
Een publiek bereikbare beheerinterface werkt nog steeds. Een te ruim ingestelde IAM-rol blokkeert niemand. Een API die te veel data teruggeeft, blijft gewoon correcte responses leveren. Een netwerksegment zonder duidelijke scheiding maakt systemen misschien zelfs makkelijker bereikbaar voor beheerders.
Vanuit operationeel perspectief lijkt er dus weinig aan de hand.
Het probleem wordt pas zichtbaar wanneer iemand kijkt vanuit het perspectief van een aanvaller.
Wat is bereikbaar vanaf buiten?
Welke rechten zijn aanwezig?
Welke data komt terug?
Welke systemen kunnen elkaar bereiken?
Wat gebeurt er als een account of service wordt misbruikt?
Die vragen worden niet altijd gesteld tijdens normaal beheer of functioneel testen. Daardoor blijven configuratiefouten soms maanden of jaren aanwezig.
Niet omdat niemand iets doet aan security, maar omdat de fout niet opvalt zolang alles blijft werken.
Geen exploit nodig, alleen toegang
Een belangrijk verschil met veel softwarekwetsbaarheden is dat configuratiefouten vaak geen complexe exploit vereisen.
Bij kwetsbare software moet een aanvaller vaak specifieke voorwaarden misbruiken. Er is een bepaalde versie nodig, een exploit moet werken en soms is technische kennis vereist.
Bij configuratiefouten ligt de drempel vaak lager.
Als een opslaglocatie publiek bereikbaar is, hoeft een aanvaller alleen de juiste URL te vinden. Als een database zonder goede afscherming bereikbaar is, is toegang zelf al het probleem. Als een gebruiker te ruime rechten heeft, hoeft die toegang alleen nog maar misbruikt te worden.
Het risico zit dan niet in het doorbreken van een beveiligingslaag, maar in het ontbreken of verkeerd toepassen ervan.
Dat maakt configuratiefouten aantrekkelijk voor aanvallers. Ze zijn vaak eenvoudig te misbruiken en kunnen direct toegang geven tot data, systemen of beheerfunctionaliteit.
De impact is vaak direct groot
Configuratiefouten raken vaak fundamentele onderdelen van een omgeving: toegang, rechten, netwerkbereikbaarheid en datastromen.
Daarom kan de impact groot zijn.
Een ontbrekende beveiligingsheader is vervelend, maar leidt meestal niet direct tot volledige toegang. Een publiek toegankelijke database kan dat wel. Een verkeerd ingestelde cloudrol kan directe toegang geven tot meerdere resources. Een slecht gesegmenteerd netwerk kan ervoor zorgen dat één eerste ingang leidt tot toegang tot andere systemen.
Het gevaar zit dus niet alleen in de fout zelf, maar in wat die fout mogelijk maakt.
Een configuratiefout kan een opstap zijn. Vanaf daar kan een aanvaller verder kijken, data verzamelen, rechten misbruiken of zich verplaatsen binnen een omgeving.
Juist daarom zijn configuratiefouten vaak zo relevant tijdens pentesten.
Een praktisch voorbeeld
Stel dat een organisatie een interne beheerinterface gebruikt voor klantgegevens. De software is up-to-date, de login werkt en er zijn geen bekende kritieke kwetsbaarheden aanwezig.
Op papier lijkt dat netjes.
Maar de beheerinterface is wel bereikbaar vanaf internet. Niet omdat dat bewust zo is ontworpen, maar omdat het ooit tijdelijk handig was voor beheer op afstand. Later is die instelling nooit teruggedraaid.
Vanaf dat moment is de beveiliging afhankelijk van alleen de login.
Als er zwakke wachtwoorden worden gebruikt en multi factor authenticatie ontbreekt, kan de impact groot zijn. Niet door een ingewikkelde exploit, maar doordat een gevoelige beheerinterface onnodig aan het publieke internet hangt.
De kwetsbaarheid zit dan niet in de softwareversie.
De kwetsbaarheid zit in de inrichting.
Dat is het soort verschil dat in de praktijk vaak wordt onderschat.
Waarom configuratiefouten vaak ontstaan
Configuratiefouten ontstaan zelden omdat iemand bewust onveilig wil werken.
Meestal ontstaan ze door snelheid, complexiteit en groei.
Teams moeten functionaliteit opleveren. Systemen moeten met elkaar kunnen communiceren. Externe leveranciers hebben tijdelijk toegang nodig. Nieuwe cloudresources worden snel aangemaakt. Rechten worden ruim gezet om blokkades te voorkomen. Testomgevingen worden later productieachtig gebruikt.
Elke keuze is op dat moment te verklaren.
Het echte risico ontstaat wanneer tijdelijke keuzes permanent worden. Of wanneer niemand meer precies weet waarom een bepaalde instelling ooit zo is ingesteld.
Vooral in cloudomgevingen, moderne applicaties en omgevingen met meerdere teams kan dit snel gebeuren. Het aantal instellingen, rechten, koppelingen en afhankelijkheden groeit sneller dan het overzicht.
Dan is één verkeerde instelling genoeg om een groot risico te creëren.
Waarom vulnerability scans configuratiefouten niet altijd goed beoordelen
Vulnerability scans zijn nuttig voor bekende kwetsbaarheden en zichtbare configuratieproblemen. Ze kunnen helpen om verouderde software, open poorten of bekende misconfiguraties te signaleren.
Maar ze hebben beperkingen.
Een vulnerability scanner kan vaak zien dát iets openstaat. Maar niet altijd of dat ook logisch is binnen jouw omgeving. Een scanner kan een permissie tonen. Maar niet altijd beoordelen welke data daarmee bereikbaar wordt. Een scanner kan een API-response zien. Maar niet altijd begrijpen of die data voor die gebruiker bedoeld is.
Configuratiefouten vragen daarom om context.
De vraag is niet alleen:
“Is dit technisch toegestaan?”
Maar:
“Hoort dit in deze situatie toegestaan te zijn?”
Dat verschil is belangrijk. Veel risico’s zitten namelijk niet in een losse instelling, maar in de combinatie van rechten, bereikbaarheid en gebruik.
Daarom kan een omgeving een relatief schoon scanrapport hebben en toch serieuze risico’s bevatten.
Wie dit verschil beter wil begrijpen, kan ook kijken naar het verschil tussen een vulnerability scan en een pentest.
Wat een pentest anders doet
Een pentest kijkt niet alleen naar losse kwetsbaarheden, maar naar wat een aanvaller in de praktijk kan bereiken.
Bij configuratiefouten is dat extra belangrijk.
Een tester kijkt bijvoorbeeld niet alleen of een service bereikbaar is, maar ook wat er mogelijk is als die service wordt benaderd. Ook kijkt een pentester niet alleen welke rechten een account heeft, maar ook wat er met die rechten gedaan kan worden. Verder kijkt een tester niet alleen of systemen elkaar kunnen bereiken, maar of die bereikbaarheid laterale beweging mogelijk maakt.
Daarmee wordt duidelijk wat de impact van een configuratiefout echt is.
Het kan zo zijn dat een fout beperkte impact heeft. Maar het kan ook zo zijn dat een kleine instelling juist een ingang is naar een veel groter probleem.
Dat onderscheid kun je alleen maken door gedrag, context en samenhang te onderzoeken. Bij netwerk- en infrastructuuromgevingen draait het niet alleen om de vraag welke systemen bereikbaar zijn, maar ook om wat er mogelijk wordt zodra een aanvaller eenmaal toegang heeft. Een netwerk pentest helpt om die samenhang zichtbaar te maken.
In het artikel over wat er tijdens een pentest gebeurt leggen we uitgebreider uit hoe zo’n onderzoek in de praktijk verloopt.
Configuratiefouten in cloudomgevingen
In cloudomgevingen zijn configuratiefouten extra relevant.
Dat komt doordat cloudplatformen veel flexibiliteit bieden. Resources kunnen snel worden aangemaakt, rechten zijn fijnmazig in te stellen en systemen kunnen makkelijk met elkaar integreren.
Die flexibiliteit is krachtig, maar maakt het ook makkelijker om per ongeluk te veel open te zetten.
Een opslagbucket kan publiek toegankelijk worden. Een identity-rol kan meer rechten krijgen dan nodig. Een security group kan verkeer toestaan vanaf het hele internet. Een tijdelijke testresource kan blijven bestaan en later vergeten worden.
Het lastige is dat dit soort instellingen vaak niet zichtbaar zijn aan de buitenkant. De applicatie werkt gewoon. Gebruikers merken niets. Maar onderliggend kan de omgeving veel meer toestaan dan de bedoeling is.
Daarom draait een cloud pentest niet alleen om kwetsbare software, maar juist ook om inrichting, rechten, netwerktoegang en de samenhang tussen cloudresources.
Configuratiefouten en laterale beweging
Configuratiefouten worden nog gevaarlijker wanneer ze aanvallers helpen om verder te komen.
Een eerste ingang is vaak niet het einddoel. Nadat toegang is verkregen probeert een aanvaller meestal te ontdekken welke systemen te benaderen zijn, welke accounts bruikbaar zijn en welke rechten kunnen worden misbruikt.
Slechte netwerksegmentatie, te ruime serviceaccounts of onnodige interne toegang kunnen dat proces makkelijker maken.
Een systeem dat eigenlijk geïsoleerd had moeten zijn, blijkt toch andere systemen te kunnen bereiken. Een account dat alleen bedoeld was voor één taak, blijkt toegang te hebben tot meerdere omgevingen. Een intern portaal blijkt bereikbaar vanaf een plek waar dat niet nodig is.
Op die manier wordt één configuratiefout onderdeel van een groter aanvalspad.
Daarom is laterale beweging zo belangrijk om mee te nemen tijdens een securityonderzoek. Niet alleen de eerste kwetsbaarheid telt, maar ook wat daarna mogelijk wordt.
Wat organisaties hiervan kunnen leren
De belangrijkste les is dat security niet alleen draait om patchen.
Patchmanagement blijft belangrijk, maar het is niet genoeg. Een volledig bijgewerkt systeem kan nog steeds onveilig zijn wanneer het verkeerd is ingericht.
Daarom moeten organisaties ook kijken naar vragen als:
Wie heeft toegang?
Welke systemen zijn bereikbaar?
Welke poorten staan open?
Welke data is toegankelijk?
Welke instellingen zijn ooit tijdelijk aangepast en nooit teruggedraaid?
Dat zijn geen eenmalige vragen. Omgevingen veranderen continu. Nieuwe releases, extra koppelingen, cloudwijzigingen en beheerkeuzes kunnen nieuwe configuratiefouten introduceren.
Goede beveiliging vraagt daarom om overzicht, periodieke toetsing en aandacht voor de manier waarop systemen daadwerkelijk zijn ingericht.
Van patchniveau naar echte weerbaarheid
Kwetsbare software blijft een belangrijk risico. Maar wie alleen naar softwareversies en patches kijkt, mist een groot deel van het werkelijke aanvalsoppervlak.
Configuratiefouten zijn gevaarlijk omdat ze vaak onopgemerkt blijven, direct toegang kunnen geven en pas zichtbaar worden wanneer iemand er misbruik van maakt.
De vraag is dus niet alleen of alles up-to-date is.
De vraag is of systemen, rechten en koppelingen veilig zijn ingericht.
Wil je weten of jouw omgeving niet alleen gepatcht is, maar ook veilig is ingericht? Dan kan een gerichte pentest helpen om aantoonbare risico’s in kaart te brengen.