Overslaan naar hoofdinhoud

Beheer van aanvalsoppervlakken: hoe u de blootstelling kunt vinden, prioriteren en verminderen

Elke organisatie heeft een aanvalsoppervlak. De vraag is of het weet wat aanvallers kunnen zien.

Een openbare webtoepassing, een vergeten cloudworkload, een portal voor externe toegang die is gemaakt voor een leverancier, een blootgestelde opslagbucket of een oud subdomein kunnen allemaal routes naar het bedrijf worden.

In context: externe en interne aanvalsvlakken

Dit artikel is voornamelijk gericht op de externe aanval: de domeinen, programma's, cloudservices, systemen voor externe toegang en andere activa die aanvallers kunnen identificeren en bereiken van buiten de organisatie.

Maar het bredere aanvalsoppervlak omvat ook interne systemen, identiteiten, netwerkverbindingen, zwakke software en bedrijfsprocessen. Het beheer van externe aanvalsoppervlakken is daarom een onderdeel van een breder programma voor blootstellingsbeheer, naast het beheer van kwetsbaarheden, identiteitsbeveiliging, programmabeveiliging en netwerksegmentatie.

De waarde van externe ASM is dat het organisaties helpt bij het identificeren van de routes die een aanvaller kan gebruiken om voet aan de grond te krijgen - voordat die blootstelling leidt tot interne toegang, verstoring of gegevensverlies.

Sommige zijn gedocumenteerd en worden actief beheerd, terwijl andere buiten de formele activa-inventarissen vallen, toebehoren aan onlangs overgenomen bedrijven of zijn opgericht voor een kortlopend project en nooit naar behoren zijn gepensioneerd.

Attack Surface Management, of ASM, helpt organisaties deze risico's te vinden voordat een aanvaller dat doet.

ASM is geen eenmalige scan of een lange lijst met technische bevindingen, maar een continu proces voor het ontdekken van extern zichtbare activa, het begrijpen welke belangrijk zijn en het verminderen van onnodige blootstelling.

Wat is Beheer van aanvalsoppervlakken?

Een aanvalsoppervlak is de verzameling punten waar een aanvaller mogelijk een systeem kan binnendringen, een effect kan veroorzaken of gegevens kan extraheren. In de huidige ondernemingen gaat dit veel verder dan het bedrijfsnetwerk. Het kan het volgende omvatten:

  • Internetgerichte programma's en API's
  • Domeinen, subdomeinen en DNS-records
  • Openbare IP-adressen en open poorten
  • Cloudworkloads, opslag- en beheerinterfaces
  • Diensten voor externe toegang, zoals VPN's en virtuele desktopgateways
  • SaaS-programma's en integraties van derden
  • Blootgestelde ontwikkelomgevingen en codeopslagplaatsen
  • Referenties en andere gevoelige informatie die is gelekt of online is gepubliceerd
  • Verbonden apparaten en operationele technologiesystemen die zichtbaar zijn vanaf het internet.

Deze blootstelling is verre van theoretisch. Volgens onderzoek van Kaspersky was de exploitatie van openbare programma's verantwoordelijk voor bijna 44% van de eerste aanvalsvectoren die in 2025 werden waargenomen, waardoor dit de meest voorkomende route naar getroffen organisaties is.

Aanvalsoppervlakbeheer is de discipline van het ontdekken, beoordelen en verminderen van deze blootstellingen vanuit een outside-in perspectief. Dus in plaats van te vragen: "Wat zegt onze CMDB (database voor configuratiebeheer) dat we bezitten?", wordt gevraagd: "Wat zou een aanvaller kunnen identificeren, bereiken of misbruiken?"

Dit is belangrijk omdat interne inventarissen van activa essentieel zijn, maar mogelijk niet de cloudservices bevatten die zijn geïmplementeerd buiten standaardprocessen, verlaten domeinen, onbeheerde SaaS-accounts, tijdelijke systemen of infrastructuur die door derden is gemaakt.

Waarom is het beheer van het aanvalsoppervlak belangrijk?

Digitale bedrijven staan nooit stil. De infrastructuur verandert elke dag wanneer teams nieuwe applicaties implementeren, workloads verplaatsen tussen cloudproviders, leveranciers verbinden, externe toegang openen, regionale websites lanceren of overgenomen bedrijven integreren.

Dit leidt tot een operationeel probleem: het beeld van de organisatie van haar landgoed kan snel onvolledig worden.

Beveiligingsteams zijn mogelijk op de hoogte van kernsystemen, maar hebben geen betrouwbaar beeld van extern zichtbare activa in business units, cloudaccounts, ontwikkelteams en omgevingen van derden. Hierdoor kunnen onbekende of slecht gecontroleerde systemen veel langer worden blootgesteld dan de bedoeling was.

Aanvallers hebben geen organigram, een lijst met goedgekeurde items of toestemming nodig om te kijken. Ze gebruiken openbare informatie, internetscans, certificaatrecords, DNS-gegevens, blootgestelde services en gelekte informatie om hun eigen beeld van de omgeving op te bouwen.

Het beheer van het aanvalsoppervlak biedt verdedigers een manier om eerst hetzelfde te doen, en wel systematischer.

Voor CISO's is de waarde niet alleen een betere zichtbaarheid, maar ook een geloofwaardiger basis voor risicobeslissingen. Teams kunnen identificeren welke blootgestelde activa kritieke services ondersteunen, die geen duidelijk eigendom hebben, die onnodig toegankelijk zijn vanaf internet en die onmiddellijke aandacht verdienen.

Hoe effectief beheer van aanvalsoppervlakken werkt

Effectieve ASM volgt een herhaalde cyclus in plaats van een enkel project.

1. Ontdekken wat is? zichtbaar

De eerste stap is het opbouwen van een extern beeld van de organisatie.

Dit omvat doorgaans de identificatie van domeinen, IP-bereiken, cloudservices, blootgestelde programma's, certificaten, open poorten, openbare codeopslagplaatsen en andere op het internet zichtbare infrastructuur die verband houdt met de organisatie. Discovery moet waar nodig dochterondernemingen, regionale entiteiten, overgenomen bedrijven en bekende derden omvatten.

Een nuttige startvraag is: "Welke activa zouden ons verbazen als een aanvaller ze zou vinden?"

2. Bevestig de eigendom en het zakelijke doel

Niet alle gevonden activa zijn eigendom van de organisatie. Sommige kunnen geparkeerde domeinen, voormalige leveranciers, gedeelde services of infrastructuur van een andere partij zijn. Anderen behoren mogelijk tot de organisatie maar hebben geen duidelijke eigenaar.

Dit is waar ASM een operationeel proces wordt in plaats van een technische oefening. Beveiligingsteams hebben een praktische manier nodig om te bevestigen of een actief legitiem is, wie de eigenaar is, waarom het wordt blootgesteld en of die blootstelling nog steeds nodig is.

Een portaal met externe toegang kan van cruciaal belang zijn voor een relatie met een leverancier, een ontwikkelserver kan nodig zijn voor een tijdelijk project of een testprogramma is mogelijk online gebleven na de lancering. De juiste reactie is niet automatisch om alles af te sluiten, maar om de blootstelling opzettelijk, gecontroleerd en verantwoord te maken.

3. Beoordeel de blootstelling, niet alleen de kwetsbaarheid

Een systeem heeft geen kritieke CVE nodig om risico's te creëren. Een administratieve interface die is blootgesteld aan het openbare internet kan zelfs na volledige patch een probleem vormen, een cloudservice is mogelijk breder toegankelijk dan de bedoeling is, een aanmeldingspagina kan te veel informatie onthullen om aanvallen met inloggegevens te ondersteunen en een vergeten domein kan kwetsbaar zijn voor overname of imitatie.

4. Prioriteer op basis van de impact op het bedrijf

Prioritering is waar veel ASM-programma's nuttig worden of mislukken.

Een grote organisatie kan honderden of duizenden blootgestelde activa ontdekken, maar het is niet mogelijk en ook niet nodig om elke bevinding als een crisis te behandelen. De nadruk moet liggen op blootstellingen die technische zwakte combineren met belangrijke zakelijke gevolgen.

Een blootgestelde testserver kan bijvoorbeeld een laag risico vormen als deze geen gevoelige gegevens bevat, geïsoleerd is van de productie en is gepland voor buitengebruikstelling. Een blootgestelde gateway voor externe toegang die distributieactiviteiten ondersteunt, kan daarentegen onmiddellijk worden beoordeeld, zelfs als er geen kritieke kwetsbaarheid bekend is.

Een praktisch prioriteringsmodel houdt rekening met het volgende:

  • Blootstelling: hoe zichtbaar en toegankelijk is het?
  • Exploitabiliteit: hoe gemakkelijk kan een aanvaller de blootstelling gebruiken?
  • Kritiek: welk bedrijfsproces, welke gegevens of service worden er door ondersteund?

Dit helpt beveiligingsleiders om technische bevindingen om te zetten in beslissingen die bedrijfseigenaren kunnen begrijpen.

Een praktisch voorbeeld: een onbeveiligde service voor externe toegang

Stel dat een fabrikant een gateway voor externe toegang ontdekt die is verbonden met een regionale operationele omgeving. De service is enkele jaren geleden opgezet om een onderhoudsaanbieder in staat te stellen apparatuur op afstand te ondersteunen. Het is nog steeds internetgericht, gebruikt een verouderde authenticatiemethode en is niet gecontroleerd sinds het contract met de provider is gewijzigd.

Een ASM-proces stopt niet bij het melden dat de gateway bestaat. Maar het zou wel het volgende vaststellen :

  • Wie is de eigenaar van de service
  • Of de leverancier nog steeds toegang nodig heeft
  • Welke systemen via de service kunnen worden bereikt
  • Of multi-factor authenticatie is ingeschakeld
  • Of de toegang wordt beperkt door de locatie van het netwerk, de tijd of de rol van de gebruiker
  • Of de activiteit wordt geregistreerd en gecontroleerd
  • Of de service kan worden verwijderd, vervangen of gesegmenteerd

De zakelijke beslissing kan zijn om de gateway buiten gebruik te stellen, meer gecontroleerde toegang van leveranciers te eisen, deze te beperken tot goedgekeurde onderhoudsperiodes of achter strengere controles voor authenticatie en segmentatie te plaatsen.

Het resultaat is niet zomaar een gesloten technisch ticket. Het is een vermindering van de blootstelling van de organisatie aan operationele onderbrekingen.

Hoe ASM werkt met kwetsbaarheidsbeheer, XDR en informatie over dreigingen

Het beheer van het aanvalsoppervlak is het nuttigst wanneer het verbinding maakt met de rest van het beveiligingsprogramma.

Kwetsbaarheidsbeheer identificeert, prioriteert en helpt bij het verhelpen van bekende zwakke punten in de systemen die de organisatie al kan beoordelen. ASM helpt bij het identificeren van de systemen, services en cloudassets die mogelijk nog niet zichtbaar zijn voor dat proces.

Informatie over dreigingen voegt context toe. Het kan laten zien of een bepaalde technologie, blootgestelde service of type inloggegevens actief wordt getarget door cybercriminelen of is gekoppeld aan een bekende campagne. Dat helpt teams om te beslissen welke bevindingen vooraan in de wachtrij moeten komen te staan.

XDR , SIEM en andere SOC tools helpen teams verdachte activiteit op endpoints, netwerken, cloudomgevingen en andere IT-systemen te detecteren en te onderzoeken. ASM kan de effectiviteit ervan verbeteren door de externe activa te markeren die het meest waarschijnlijk toegangspunten voor aanvallen worden.

Diensten voor respons op incidenten en de beoordeling van compromissen kunnen ook een rol spelen wanneer teams vermoeden dat een blootstelling al is misbruikt, of wanneer ze een onafhankelijk onderzoek nodig hebben om vast te stellen wat er is gebeurd.

Services voor beveiligingsbeoordeling simuleren het gedrag van kwaadwillenden en laten zien hoe echte aanvallers programma's, netwerken en apparaten kunnen misbruiken, waardoor een beter inzicht wordt verkregen in het aanvalsoppervlak van de organisatie en de blootstelling aan de beveiliging wordt verminderd.

Het gaat er niet om om nog een geïsoleerd beveiligingshulpmiddel te maken, maar om blootstellingsbeheer te verbinden met detectie, respons, eigendom van activa en risicobeheer.

Een ASM-programma bouwen dat tot actie leidt

Een werkbaar ASM-programma begint bij eigendom, niet bij een dashboard.

Beveiligingsteams moeten overeenkomen hoe ontdekte activa worden toegewezen, gevalideerd en hersteld. Hiervoor is normaal gesproken de deelname van infrastructuur-, cloud-, applicatie-, netwerk-, inkoop-, juridische en zakelijke teams vereist.

Vijf werkingsprincipes helpen:

  1. Behandel eigendom van activa als een beveiligingscontrole. Elk significant zichtbaar item moet een eigenaar met naam hebben (hoewel dit meestal buiten ASM gebeurt).
  2. Koppel bevindingen aan bestaande workflows. De bevindingen van ASM moeten de teams bereiken die ze kunnen oplossen met behulp van reeds bestaande processen voor servicebeheer, kwetsbaarheidsbeheer of risicobeheer.
  3. Meet vermindering, niet alleen ontdekking. Een groeiend aantal activa kan wijzen op een betere zichtbaarheid, niet op een verslechtering van de beveiliging.
  4. Rapporteer in zakelijke termen. Boards en executives hebben geen lijst met poorten en certificaten nodig. Ze moeten begrijpen waar externe blootstelling van invloed kan zijn op klantenservice, activiteiten, wettelijke verplichtingen, inkomsten of herstelcapaciteit.

Hoe ASM inzicht omzet in risicovermindering

Zelfs een volwassen ASM-programma belooft niet dat elk kwetsbaar systeem zal verdwijnen: bedrijven hebben internetgerichte services nodig om te verkopen, te ondersteunen, verbinding te maken en te werken.

Een sterk ASM-programma heeft meer te maken met discipline:

  • de organisatie weet welke extern zichtbare activa het bezit
  • Het kan legitieme blootstelling onderscheiden van onbedoelde blootstelling
  • Bevindingen met een hoog risico hebben duidelijke eigenaren, gedefinieerde reactietijden en zakelijke context
  • Onnodige services worden verwijderd
  • Essentiële services worden beschermd, gecontroleerd en beoordeeld
  • Beveiligingsleiders kunnen aantonen dat de blootstelling wordt verminderd in gebieden die er het meest toe doen.

Dit is de praktische waarde van het beheer van het aanvalsoppervlak: geen abstract beeld van risico, maar een continue manier om de organisatie moeilijker te vinden, moeilijker te betreden en moeilijker te verstoren te maken.

Bronnen en meer informatie

Beheer van aanvalsoppervlakken: hoe u de blootstelling kunt vinden, prioriteren en verminderen

Elke organisatie heeft een aanvalsoppervlak. De vraag is of het weet wat aanvallers kunnen zien.
Kaspersky logo

Gerelateerde artikelen