Kwetsbaarhedenbeheer

Een scanrapport is het begin van een beslissing. Het geeft mogelijke zwakke plekken op specifieke IT-middelen aan; een analist controleert die bevindingen, plaatst ze in hun context en volgt het werk totdat het resultaat is geverifieerd. Dit terugkerende proces heet kwetsbaarhedenbeheer.

Benoem het probleem nauwkeurig

Een kwetsbaarheid is een zwakke plek in software, hardware, instellingen of een proces. Een dreiging is een persoon, groep of gebeurtenis die schade kan veroorzaken. Een exploit is code of een techniek die misbruikmaakt van een zwakke plek. Risico combineert de kans op schade met de impact ervan op de vertrouwelijkheid, integriteit of beschikbaarheid. Een ontbrekende update is een kwetsbaarheid; aanvallers die daarvan gebruikmaken om gegevens te stelen, vormen de dreiging die via een exploit handelt.

Bevindingen omvatten ook standaardwachtwoorden, openbare opslag, verouderde versleutelingsinstellingen en producten aan het einde van hun levensduur die geen beveiligingsupdates meer ontvangen. Voor een zerodaykwetsbaarheid bestaat nog geen oplossing omdat de leverancier geen tijd heeft gehad om te reageren. Een zerodayaanval gebruikt die kwetsbaarheid; openbaarmaking alleen toont niet aan dat er aanvallen hebben plaatsgevonden. Tot er controles en oplossingen bestaan, helpen risicobeperkende maatregelen en detectie de getroffen systemen te beschermen.

Van ontdekking naar afhandeling

1. Identificeer IT-middelen: stel vast wat er bestaat en wie de eigenaar is.
2. Spoor zwakke plekken op: scan de IT-middelen en verzamel andere meldingen.
3. Analyseer en valideer: controleer of elke bevinding van toepassing is.
4. Bepaal de prioriteit: combineer technische ernst, informatie over de dreiging en bedrijfscontext.
5. Pak de kwetsbaarheid aan: verwijder de zwakke plek, beperk het risico of verkrijg formele risicoacceptatie.
6. Verifieer en rapporteer: bevestig het resultaat, leg bewijs voor de afhandeling vast en meet het werk.

Stel dat een scanner een verouderde dienst op een medewerkersportaal signaleert. De analist controleert de geïnstalleerde build en het advies van de leverancier. De eigenaar van het portaal legt de rol ervan in de bedrijfsvoering uit. Een ontwikkelaar werkt de dienst via wijzigingsbeheer bij. Een nieuwe controle bevestigt de verholpen build en de werking van het portaal. Als nieuwe servers steeds de oude build terugbrengen, leidt dat bewijs het programma terug naar de uitrolinventaris en sjablonen.

Lees de identificaties

CVE Numbering Authorities kennen ID's toe zoals CVE-2014-0160, de Heartbleed-kwetsbaarheid in OpenSSL. Het jaar is onderdeel van de identificatie en geen betrouwbare datum van ontdekking of oplossing. Ook voor fouten in eigen code en configuratiefouten zonder CVE kan actie nodig zijn.

Geef elke rol een duidelijke taak

Het beveiligingsteam spoort op en valideert, bepaalt prioriteiten en volgt bevindingen op. Beheerders en ontwikkelaars voeren wijzigingen uit; eigenaren van IT-middelen zijn eindverantwoordelijk voor systeemrisico's. Bevoegden voor wijzigingen keuren productiewijzigingen goed, terwijl bevoegde risico-eigenaren uitzonderingen goedkeuren. Een brede kwetsbaarheidsbeoordeling, een geautoriseerde penetratietest die de impact aantoont en geldige bugbountymeldingen leveren allemaal input voor ditzelfde proces. Een scan zonder bevindingen zegt alleen iets over de controles die met succes zijn uitgevoerd; gemiste IT-middelen en onbekende kwetsbaarheden hebben nog steeds aandacht nodig.

Een inventaris vertelt het programma wat moet worden beoordeeld en geeft betekenis aan dekkingscijfers. Neem servers, laptops, netwerkapparatuur, applicaties, cloudresources en via internet bereikbare domeinen en certificaten op. Software en bibliotheken zijn net zo belangrijk als machines.

Leg identiteit en betekenis voor de bedrijfsvoering vast

Elke registratie heeft een stabiele identificatie, hostnaam, adressen, eigenaar, ondersteuningsteam, locatie of cloudaccount, besturingssysteem en softwareversies, bedrijfsfunctie, gegevensclassificatie, kriticiteit, blootstelling en levenscyclusstatus nodig. Gebruik een cloudinstantie-ID of agent-ID om een machine bij adreswijzigingen te blijven volgen. Een IP-adres alleen kan na wijziging van een DHCP-lease naar een ander apparaat verwijzen.

Ken samen met de eigenaar een kriticiteitsklasse toe. In een voorbeeldschema omvat klasse 1 betalingsdiensten en identiteitssystemen, klasse 2 belangrijke interne diensten en klasse 3 laboratoria met weinig impact. De klasse beschrijft de schade door verlies van vertrouwelijkheid, integriteit of beschikbaarheid. Een moeilijk te patchen systeem wordt niet minder kritiek omdat het lastig te repareren is.

Vergelijk meerdere bronnen

Een configuratiebeheerdatabase (CMDB) registreert beheerde IT-middelen, maar opsporing brengt vaak resources aan het licht die daarin ontbreken. Vergelijk de database met endpointagents, directorydiensten, DNS en DHCP, inkoopgegevens, passieve netwerkwaarnemingen en cloud-API's. Vergelijk afzonderlijke registraties voordat je verschillen tussen totalen interpreteert. Onderzoek een IT-middel dat maar in één bron voorkomt: het kan nieuw, buiten gebruik gesteld, dubbel geregistreerd of onbekend bij IT zijn.

Actieve opsporing verstuurt testverzoeken om reagerende hosts te vinden. Voor een netwerk waarvoor toestemming is gegeven, voert nmap -sn 10.20.0.0/24 hostopsporing uit over een bereik met 256 adressen. Apparaatherkenning via een vingerafdruk leidt apparaat- of besturingssysteemdetails af uit reacties; -O van Nmap vraagt om detectie van het besturingssysteem. Behandel een afgeleide identiteit als bewijs dat je moet bevestigen. Passieve opsporing bekijkt bestaand verkeer en helpt kwetsbare apparaten te vinden zonder ze testverzoeken te sturen, al kunnen stille apparaten worden gemist.

Bepaal het werkelijke verschil

Een opsporingsscan vindt 212 actieve hosts. De CMDB bevat 195 registraties en vergelijking per host bevestigt dat alle 195 tot de gevonden hosts behoren. Er zijn dus 17 niet-geregistreerde actieve hosts. Wijs aan elk een eigenaar en een registratie toe, of verwijder de host via het daarvoor bestemde proces.

De kwetsbaarheidsscan controleert in dezelfde week 180 van die 212 actieve hosts:

De 32 niet-gecontroleerde hosts blijven een hiaat in de dekking. Als sommige CMDB-hosts bij de opsporing hadden ontbroken, zou eenvoudig aftrekken van de totalen een deel van het verschil hebben verborgen. Houd de periode en populatie gelijk wanneer je dekking vergelijkt.

Vind resources die komen en gaan

Schaduw-IT is technologie die zonder medeweten van IT is ingericht. Die kan buiten het normale patchen en scannen vallen. Cloudinstanties en containers kunnen enkele minuten bestaan, zodat een maandelijkse netwerkscan hun hele levensduur kan missen. Vul de inventaris vanuit API's van providers en vereis bruikbare resourcetags, waaronder eigenaar, omgeving en gegevensclassificatie. Beoordeel de images en sjablonen waarmee ze worden gestart.

Voor een applicatie vermeldt een softwarestuklijst (SBOM) de componenten en bibliotheken. Wanneer een bibliotheekkwetsbaarheid openbaar wordt gemaakt, koppel je getroffen componentversies aan de applicaties die ze bevatten. Blijf de inventaris bijwerken wanneer resources worden aangemaakt, verplaatst en buiten gebruik gesteld; een eenmalige spreadsheet kan een veranderende omgeving niet lang beschrijven.

Een bruikbaar beleid vertelt teams wat er moet gebeuren, wie beslist en wanneer het werk klaar moet zijn. Het verbindt beveiligingsbevindingen met de bedrijfsprioriteiten van de organisatie. Het management keurt het beleid goed en het programma meet of mensen zich eraan houden.

Onderscheid de risicobegrippen

Inherent risico is het risico vóór maatregelen. Restrisico blijft over na maatregelen. Risicobereidheid is de hoeveelheid en het soort risico dat de leiding wil accepteren bij het nastreven van haar doelen. Beslissingen over een uitzondering gebruiken het resterende risico, niet alleen de oorspronkelijke ernstscore.

Een eenvoudig kwalitatief model vermenigvuldigt waarschijnlijkheid en impact, elk beoordeeld van 1 tot 5:

Een via internet bereikbare dienst met een kwetsbaarheid voor uitvoering van code op afstand krijgt waarschijnlijkheid 4 en impact 5, wat 20 van de 25 oplevert. Een geteste webapplicatiefirewallregel verlaagt de beoordeelde waarschijnlijkheid tot 2 terwijl de impact 5 blijft; het restrisico is dan 10. Volgens een voorbeeldbeleid dat verhelpen binnen 30 dagen vereist wanneer het restrisico hoger is dan 8, heeft de dienst nog steeds binnen 30 dagen een oplossing nodig. De maatregel verminderde het risico zonder onder de acceptatiedrempel van dat beleid te komen.

Deze beoordelingen ordenen inschattingen; het zijn geen gemeten kansen. Leg de redenen achter de beoordelingen van waarschijnlijkheid en impact vast, zodat een latere beoordelaar de beslissing kan begrijpen.

Stel meetbare regels op

Het beleid bepaalt welke IT-middelen binnen het bereik vallen, de scanfrequentie, verantwoordelijkheden, regels voor ernst en prioriteit, termijnen voor het verhelpen van kwetsbaarheden, uitzonderingen, escalatie en rapportage. Standaarden specificeren technische vereisten en procedures beschrijven hoe teams die uitvoeren. Governance betekent dat deze regels worden gehandhaafd, gemeten en geëvalueerd.

Een voorbeeld van SLO-termijnen is kritiek 15 dagen, hoog 30, gemiddeld 90 en laag 180. Vermeld wanneer de termijn begint. Contracten en toepasselijke vereisten kunnen strengere termijnen vastleggen. Voeg regels voor uitbuiting en blootstelling toe, zodat een bekende uitgebuite gatewaykwetsbaarheid spoedwerk kan vereisen in plaats van te wachten op de gebruikelijke termijn voor ernstniveau hoog.

Plan voor werk dat vastloopt

Een oplossing kan een bedrijfsproces onderbreken, een afhankelijk systeem verstoren of goedkeuring door de leverancier vereisen. Voor verouderde producten bestaat mogelijk geen patch, terwijl een SLA of intentieovereenkomst kan beperken wanneer wijzigingen plaatsvinden. Het beleid heeft routes nodig voor extra onderhoudsvensters, geverifieerde compenserende maatregelen en tijdelijke uitzonderingen. Een overschreden termijn gaat volgens de vastgelegde escalatieroute naar de eigenaar van het IT-middel, daarna naar de manager van de eigenaar en vervolgens naar het risicocomité.

Verbind beleid met gevestigde raamwerken

ISO/IEC 27001:2022 bijlage A, maatregel 8.8, behandelt het beheer van technische kwetsbaarheden. CIS Critical Security Controls v8.1, maatregel 7, gaat over doorlopend kwetsbaarhedenbeheer; maatregelen 1 en 2 ondersteunen de inventarisatie van IT-middelen en software. PCI DSS v4.0.1, vereiste 11.3, behandelt kwetsbaarheidsscans in de betaalkaartomgeving en NIST SP 800-40 Rev. 4 geeft richtlijnen voor patchplanning binnen organisaties. Volg de naleving van termijnen en achterstallige risico's, zodat de beleidsevaluatie op werkelijke prestaties is gebaseerd.

Een scantype beschrijft een verschillend deel van de beoordeling. Locatie, toegang, inzet en activiteit zijn afzonderlijke keuzes: een interne scan kan geauthenticeerd en zonder agent zijn, terwijl een agent een laptop buiten kantoor kan beoordelen. Kies een combinatie die past bij het IT-middel en de benodigde informatie.

Bepaal waar en hoe je kijkt

Gebruik zowel een intern als een extern perspectief. Een externe scan toont de aanvankelijke blootstelling; een interne beoordeling helpt paden te vinden die na compromittering of voor iemand van binnenuit beschikbaar zijn. Geauthenticeerde controles verminderen doorgaans foutpositieve en foutnegatieve resultaten omdat ze pakketbuilds en instellingen rechtstreeks onderzoeken. Gebruik aparte scanaccounts met de minimale rechten die nog een grondige beoordeling mogelijk maken. Bewaar authenticatiegegevens in de kluis van de scanner, monitor ze en wijzig ze regelmatig.

Stem de inzet af op het IT-middel

Agents rapporteren lokaal verzamelde informatie aan een console. Ze zijn geschikt voor laptops die zelden verbinding maken met het bedrijfsnetwerk en voor ondersteunde cloudhosts. Het uitrollen, bijwerken en monitoren van de agents blijft onderdeel van het programma.

Netwerkscans zonder agent vereisen geen geïnstalleerde software en zijn geschikt voor apparaten zoals printers en switches. Ze vereisen netwerktoegang en, voor lokaal bewijs, authenticatiegegevens. Sommige cloudhulpmiddelen beoordelen ook schijfmomentopnamen via API's van providers zonder agents op de host. Controleer welke toegang daadwerkelijk is verkregen, niet alleen welk scanlabel is gekozen.

Onderscheid activiteit en doel

Actieve scans versturen testverzoeken en analyseren antwoorden. Een passieve beoordeling bekijkt bestaand verkeer via een spiegelpoort of netwerk-TAP. Passieve waarneming voorkomt belasting door testverzoeken op kwetsbare systemen, maar mist diensten die tijdens de waarnemingsperiode stil blijven.

Een opsporingsscan brengt hosts, poorten, diensten en vermoedelijke besturingssystemen in kaart. Een kwetsbaarheidsscan controleert op bekende zwakke plekken. Een scan op naleving van een beveiligingsstandaard vergelijkt instellingen met een vereiste zoals een CIS Benchmark of een interne standaard voor systeemverharding. Zo kan de scan melden dat de minimale wachtwoordlengte 8 is terwijl de goedgekeurde standaard 14 vereist. Een open poort op zichzelf toont geen kwetsbaarheid aan.

Voor software onderzoekt statische analyse broncode of binaire bestanden zonder die uit te voeren. Dynamische analyse observeert een actief programma. Webscans en fuzzing zijn dynamisch; fuzzing biedt onjuist gevormde of willekeurige invoer aan en zoekt naar fouten zoals crashes. Bij statische reverse-engineering kan een disassembler worden gebruikt om gecompileerde code te onderzoeken.

Pas de keuzes toe

Een openbare website vereist een extern netwerkperspectief plus geauthenticeerd testen van de gebruikersfuncties op het web. Voor laptops die vaak buiten de locatie zijn, zijn agents geschikt. Voor Linux-servers in een datacenter zijn interne geauthenticeerde controles geschikt. Begin bij fabriekscontrollers met passieve monitoring en stem eventuele geteste actieve controles af met de technische afdeling. Het kortste rapport kan simpelweg voortkomen uit het minste zicht: vergelijk bereik en authenticatie voordat je de omvang als goed nieuws interpreteert.

Een scanplan moet bruikbaar bewijs opleveren zonder de beoordeelde systemen te onderbreken. Bereik, timing, toegang en belastingslimieten horen in het plan voordat de scanner wordt gestart. Test alleen systemen en accounts waarvoor schriftelijke toestemming geldt en volg de testregels van de hostingprovider.

Bepaal het bereik en de operationele grenzen

Leg adresbereiken, hostnamen, cloudaccounts, applicaties, contactpersonen, goedgekeurde vensters en uitgesloten gevaarlijke controles vast. Stem af met systeembeheerders en het team voor beveiligingsoperaties, zodat scanmeldingen worden verwacht. Beperk de toegang tot de scanner en zijn rapporten: die bevatten authenticatiegegevens en een gedetailleerd overzicht van zwakke plekken.

Werk de kwetsbaarhedenfeed of plug-ins vóór elke uitvoering bij. Beperk het aantal gelijktijdige doelen en controles om verbindingen of CPU's niet te overbelasten. Verkeerde authenticatiegegevens kunnen accounts blokkeren, testverzoeken vullen logboeken en activeren verdedigingssystemen, en ingrijpende controles kunnen kwetsbare diensten laten vastlopen. Gebruik profielen die veilig zijn voor productie, schakel dienstweigeringscontroles uit en spreid zwaar werk buiten piekperioden.

Scandiepte is een keuze. Een opsporingsprofiel heeft minder operationele impact dan een diepgaand, ingrijpend profiel, maar beantwoordt ook minder vragen. Test een nieuw profiel op representatieve systemen voordat je het bereik vergroot. De frequentie moet passen bij verandering en blootstelling: maandelijks intern scannen is een gebruikelijke minimumkeuze voor een programma, terwijl een wekelijkse of doorlopende beoordeling actueler bewijs oplevert. Ingrijpende wijzigingen en dringende adviezen kunnen extra uitvoeringen vereisen.

Bereik elk netwerksegment

Een centrale scanner achter een firewall kan mogelijk vrijwel niets in een geïsoleerd subnet bereiken. Plaats verspreide scanners of agents in de relevante segmenten, of gebruik nauw afgebakende, tijdelijke scantoegang. Behoud de segmentatie buiten wat is goedgekeurd. Controleer na de uitvoering het bereik van hosts en geslaagde authenticaties, zodat geblokkeerde testverzoeken niet tot schijnbaar schone resultaten leiden.

Pas scanvereisten voor betaalkaarten toe

Voor de omgeving met kaarthoudergegevens vereist PCI DSS v4.0.1 minstens eenmaal per drie maanden interne scans. Bevindingen met een hoog risico en kritieke bevindingen, zoals door de organisatie gerangschikt, moeten worden verholpen en met nieuwe scans worden gecontroleerd; het scanprogramma moet actuele kwetsbaarheidsinformatie gebruiken. Ook na ingrijpende wijzigingen volgen interne scans.

Geauthenticeerd intern scannen volgens vereiste 11.3.1.2 is sinds 31 maart 2025 verplicht. Gebruik voldoende scanrechten; documenteer systemen die geen authenticatiegegevens kunnen accepteren. Het vereiste voor geauthenticeerd scannen geldt niet voor de afzonderlijke scans na ingrijpende wijzigingen volgens 11.3.1.3. Externe scans vinden minstens eenmaal per drie maanden plaats via een PCI SSC Approved Scanning Vendor (ASV), met zo nodig nieuwe scans om voldoende resultaten te behalen. Ingrijpende wijzigingen vereisen ook een externe beoordeling volgens de afzonderlijke bepaling voor scans na wijzigingen in de standaard.

Bescherm fysieke processen

Operationele technologie (OT) omvat systemen die fysieke apparatuur aansturen. Bij industriële besturingssystemen (ICS) en SCADA voor bewaking, besturing en gegevensverzameling hebben veiligheid en beschikbaarheid vaak voorrang op scandiepte. Oude controllers kunnen slecht reageren op onbekende pakketten. Geef de voorkeur aan passieve monitoring en door de leverancier goedgekeurde hulpmiddelen; test in een replica en verkrijg technische goedkeuring voor actieve werkzaamheden tijdens geplande onderbrekingen.

Een voorbeeldplan scant 10.20.0.0/24 op zaterdag van 01.00 tot 05.00 uur met authenticatiegegevens, beperkt het aantal gelijktijdig gescande hosts tot 10, werkt feeds op vrijdag bij en exporteert bevindingen naar tickets. Het voegt wekelijkse externe scans en passieve fabrieksmonitoring toe. Contactpersonen voor de uitvoering en stopvoorwaarden maken het plan bruikbaar wanneer de prestaties tijdens een uitvoering veranderen.

Begin met de vraag en kies daarna het hulpmiddel. Een adresbereik in kaart brengen, een afhankelijkheid beoordelen en controleren of een verdedigingsmaatregel een aanval detecteert zijn verschillende taken. De uitvoer van een hulpmiddel moet worden gevalideerd, ook wanneer de productnaam bekend is.

Vind hosts, diensten en bekende zwakke plekken

Nmap brengt poorten en diensten in kaart; -sV vraagt om detectie van dienstversies, -O vraagt om detectie van het besturingssysteem en de Nmap Scripting Engine ondersteunt aanvullende controles. Angry IP Scanner biedt eenvoudige opsporing van hosts en poorten. Masscan scant grote adresbereiken snel op open poorten, met weinig details over diensten.

Nessus gebruikt plug-incontroles om bekende kwetsbaarheden te beoordelen. OpenVAS van Greenbone rapporteert zwakke plekken met een beoordeling van de detectiekwaliteit. Nuclei voert YAML-sjablonen uit voor gerichte controles, waaronder controles van webdiensten en CVE's. De keuze van sjablonen is van belang omdat controles verschillen in doel en operationele impact.

Beoordeel webgedrag

Een netwerkscanner kan een webserver en bekende componentproblemen vinden, terwijl geauthenticeerd testen van webapplicaties het applicatiegedrag onderzoekt. Problemen in de bedrijfslogica vereisen nog steeds zorgvuldige validatie van het daadwerkelijke werkproces.

Onderzoek cloudresources en softwareartefacten

Prowler en ScoutSuite vragen cloudconfiguraties via API's op en rapporteren problemen in de beveiligingsstatus. Checkov analyseert infrastructuur als code, zoals Terraform- of Kubernetes-definities. Trivy beoordeelt artefacten waaronder containerimages en repository's op kwetsbare componenten, configuratiefouten en blootgestelde geheimen en kan softwarestuklijsten genereren.

Zo vraagt een open beheerpoort in een Terraform-regel vóór uitrol om Checkov of Trivy. Een al uitgerolde openbare opslagbucket vraagt om een beoordeling van de cloudbeveiligingsstatus. Een bibliotheek in een container vraagt om een scan van het image of de samenstelling. Deze bevindingen kunnen dezelfde eigenaar hebben, maar vereisen verschillend bewijs.

Herken specialistische testrollen

Maltego bouwt relatiegrafieken uit gegevens van openbare bronnen met behulp van transforms; Recon-ng organiseert modulaire verkenning. Beide ondersteunen het in kaart brengen van het externe aanvalsoppervlak. Metasploit Framework bevat modules voor uitbuiting en aanvullende beoordeling; Pacu richt zich op aanvalstests voor AWS. Geautoriseerde specialistische tests kunnen de uitbuitbaarheid bevestigen, terwijl analisten bij hun reguliere werk nog steeds bewijs en een registratie van de aanpak nodig hebben.

GDB en Immunity Debugger onderzoeken actieve programma's, geheugen en registers. Ze helpen crashes te verklaren die met fuzzing zijn gevonden. Atomic Red Team biedt kleine tests die aan MITRE ATT&CK zijn gekoppeld en Caldera van MITRE automatiseert aanvallersemulatie. Deze hulpmiddelen voor inbraak- en aanvalssimulatie testen of maatregelen technieken detecteren of blokkeren. Een geslaagde detectietest zegt iets over die maatregel; hij toont niet aan dat geïnstalleerde pakketten actueel zijn.

De ernst helpt een rapport te sorteren, maar het bewijs verklaart waarom de scanner een bevinding heeft gemeld. Lees het getroffen IT-middel en de gedetecteerde versie, instelling of reactie voordat je werk toewijst. Een bruikbaar ticket moet de eigenaar voldoende details geven om het probleem te reproduceren en te verhelpen.

Lees de bevinding als een registratie

Zoek naar de titel, plug-in- of controle-ID, CVE-verwijzingen, ernst, CVSS-versie en -vector, het IT-middel, de poort, het protocol, de dienst, het detectiebewijs, de aanbevolen oplossing en de datums waarop de bevinding voor het eerst en laatst is gezien. Een plug-in-ID identificeert de controle van de scanner; die is niet uitwisselbaar met een CVE-ID.

Onderzoek bij een webprobleem de URL, parameter, het verzoek, de reactie en de betrouwbaarheid. Een rapport zoals “Gereflecteerde cross-site scripting in parameter q van /search” geeft een applicatie-invoer aan die onderzocht moet worden. Een cloudresultaat heeft account, regio, resource-ID, controle-ID en PASS of FAIL nodig, zodat de juiste resource-eigenaar actie kan ondernemen.

Interpreteer poortstatussen nauwkeurig

Bekijk deze resultaten van dienstdetectie:

22/tcp   open     ssh    OpenSSH 7.4
80/tcp   open     http   Apache httpd 2.4.6 ((CentOS))
443/tcp  closed   https
3306/tcp filtered mysql

SSH en HTTP zijn bereikbaar voor deze scanner. Volgens deze waarneming luistert er niets op 443. De status van poort 3306 blijft onzeker omdat een filter het benodigde bewijs blokkeert. De banners wijzen op een oudere CentOS-omgeving; bevestig het besturingssysteem en de ondersteuningsstatus met geauthenticeerde gegevens voordat je een bevinding vastlegt dat het systeem het einde van de levensduur heeft bereikt. CentOS Linux 7 bereikte op 30 juni 2024 het einde van de levensduur; controleer ook eventuele afspraken over uitgebreide ondersteuning.

Gebruik betrouwbaarheid om validatie te plannen

De detectiekwaliteit (QoD) van Greenbone beoordeelt het bewijs achter een resultaat. Voorbeelden zijn 97% voor geauthenticeerde pakketcontroles, 80% voor banners die het patchniveau vermelden en 30% voor banners die dat niet doen. Rapporten verbergen resultaten onder 70% doorgaans standaard. Burp duidt de betrouwbaarheid aan als zeker, overtuigend of voorlopig. Een ernstige bevinding met zwak bewijs moet snel worden gevalideerd; betrouwbaarheid en ernst beantwoorden verschillende vragen.

Zet herhaalde regels om in bruikbaar werk

Eén leveranciersupdate kan veel CVE's verhelpen. Als 900 van de 1.240 bevindingsregels door vijf updates worden opgelost, groepeer je tickets per update, eigenaar en lijst met getroffen hosts. Behoud de afzonderlijke verwijzingen naar bevindingen, zodat validatie elke getroffen instantie kan bevestigen.

Vergelijk scans met statussen zoals nieuw, verholpen, heropend en voortdurend aanwezig. Voordat je een grote daling van het aantal bevindingen accepteert, vergelijk je bereikbare hosts, geslaagde authenticaties en scanduur. Een wachtwoordwijziging waardoor de scanner zich niet meer kan aanmelden, kan lokale bevindingen uit het rapport laten verdwijnen zonder een zwakke plek weg te nemen. Informatieve resultaten kunnen ook onbekende diensten of aflopende certificaten blootleggen, dus neem ze mee in de beoordeling.

Een positief resultaat en een daadwerkelijke kwetsbaarheid zijn twee verschillende dingen. Validatie controleert of de bevinding op het IT-middel van toepassing is. De goede werking van de scan beoordelen helpt ook zwakke plekken te vinden die de scanner niet heeft gerapporteerd.

Classificeer de vier uitkomsten

Foutnegatieve resultaten laten echte zwakke plekken buiten de werklijst. Veelvoorkomende oorzaken zijn mislukte authenticatie, geblokkeerde testverzoeken, uitgeschakelde hosts, een onvolledig bereik, oude feeds, niet-herkende aangepaste software en kwetsbaarheden waarvoor geen controle beschikbaar is. Vergelijk de inventaris, scandekking, authenticatielogboeken en onafhankelijke bronnen wanneer een rapport onverwacht weinig bevindingen bevat.

Valideer van bewijs tot conclusie

1. Lees het bewijs van de controle en de toestand die volgens de controle kwetsbaar is.
2. Verkrijg de werkelijke pakketbuild of configuratie via geauthenticeerde toegang.
3. Vergelijk die met het relevante leveranciersadvies en de verholpen build.
4. Controleer of de getroffen functie en omstandigheden aanwezig zijn.
5. Breng bewijs van agents of endpoints met elkaar in verband en leg de conclusie vast.

Een banner kan verouderd of onvolledig zijn en een proxy kan namens een andere machine antwoorden. Een onjuiste vingerafdruk van het besturingssysteem kan leiden tot controles voor het verkeerde product. Handmatige bevestiging hoort, wanneer nodig, bij geautoriseerde tests met een passend operationeel plan.

Herken een teruggeporteerde oplossing

Een distributie kan een oudere softwaretak patchen met behoud van het oorspronkelijke versienummer. Dit is een backport. Stel dat een banner OpenSSH_7.4 toont, terwijl de oplossing in het oorspronkelijke project in 7.7 verscheen. Die vergelijking alleen mist oplossingen die specifiek zijn voor de distributie.

In een fictieve distributie geeft een geauthenticeerde controle pakketbuild openssh-7.4p1-23 terug en vermeldt het leveranciersadvies openssh-7.4p1-21 als de verholpen build voor dezelfde ondersteunde release. Build 23 bevat de teruggeporteerde oplossing, dus de specifieke CVE-bevinding is onjuist. Als geauthenticeerd bewijs ook een niet-ondersteund besturingssysteem bevestigt, blijft de bevinding dat het systeem het einde van de levensduur heeft bereikt terecht. Het afsluiten van één bewering neemt niet elk risico op de host weg.

Onderdruk beperkt en beoordeel opnieuw

Leg bij een bevestigd foutpositief resultaat de controle, het IT-middel, de reden, het ondersteunende bewijs en de evaluatiedatum vast. Beperk de onderdrukking tot die specifieke controle op dat specifieke IT-middel. Een algemene uitschakeling kan echte bevindingen elders verbergen en een latere configuratiewijziging kan de oude conclusie ongeldig maken.

Een uitspraak zoals “we hebben het gepatcht” moet worden geverifieerd: mogelijk moet nog een herstart plaatsvinden of is er nog een tweede geïnstalleerde kopie. Controleer de daadwerkelijk gebruikte versie of instelling in plaats van een herinnerde onderhoudsactie als bewijs te aanvaarden.

Gebruik de juiste noemer

Als 6 van de 50 gerapporteerde bevindingen onjuist zijn, is 12% van de gerapporteerde steekproef onjuist. Het statistische foutpositieve percentage deelt daarentegen de foutpositieve resultaten door alle werkelijk negatieve gevallen:

De steekproef van positieve meldingen levert geen aantal terecht negatieve resultaten op en kan dat percentage dus niet vaststellen. Vermeld precies wat een meetwaarde meet; betere authenticatiegegevens, een beter bereik, actuelere feeds en betere plaatsing van scanners verbeteren het bewijs achter zowel positieve als negatieve resultaten.

Het Common Vulnerability Scoring System (CVSS) beschrijft de technische ernst op een schaal van 0,0 tot 10,0. Leg de bron, versie en vector van de score vast, zodat de betekenis duidelijk is. FIRST onderhoudt CVSS; voor de prioriteit voor de bedrijfsvoering zijn nog steeds blootstelling, bewijs van uitbuiting en de context van het IT-middel nodig.

Ontcijfer uitbuitbaarheid en impact

Wanneer een aanvaller uit een virtuele machine ontsnapt, kan die vanuit het beveiligingsdomein van het gastsysteem de hypervisor bereiken. Cross-site scripting kan het beveiligingsdomein van de browser van het slachtoffer treffen. Reikwijdte betekent niet het aantal machines in de scan.

De vector van Heartbleed is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Die beschrijft bereik via het netwerk, lage complexiteit, geen vereiste rechten of interactie, ongewijzigde reikwijdte en grote impact op de vertrouwelijkheid. De basisscore is 7,5. AV:N beschrijft de toegangsmethode tot de kwetsbaarheid; het vertelt je niet of jouw specifieke server via internet bereikbaar is.

Gebruik de weegfactoren voor ongewijzigde reikwijdte

De AV-weegfactoren zijn N 0,85, A 0,62, L 0,55, P 0,20. AC is L 0,77 of H 0,44; UI is N 0,85 of R 0,62. PR is N 0,85, L 0,62 of H 0,27 bij ongewijzigde reikwijdte; bij gewijzigde reikwijdte geldt 0,68 voor L en 0,50 voor H. Elke impactweegfactor is hoog 0,56, laag 0,22 of geen 0.

Als de impact positief is, begrens je de som op 10 en rond je naar boven af op één decimaal. Nul impact geeft een basisscore van nul. Voor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H is ISS 0,914816, de impact ongeveer 5,8731 en de uitbuitbaarheid ongeveer 3,8870. De som is ongeveer 9,7602, dus de basisscore is 9,8.

Gewijzigde reikwijdte gebruikt een andere impactuitdrukking en een vermenigvuldigingsfactor van 1,08 voor de basisscore:

Gebruik de calculator voor de betreffende versie om deze regels toe te passen zonder formules te mengen.

Interpreteer het resultaat

De ernstniveaus zijn geen 0,0, laag 0,1–3,9, gemiddeld 4,0–6,9, hoog 7,0–8,9 en kritiek 9,0–10,0. De eis van lage rechten verandert de 9,8 in het voorbeeld met ongewijzigde reikwijdte in 8,8; toevoeging van lokale toegang geeft 7,8; alleen de aanvalscomplexiteit veranderen naar hoog geeft 8,1. Dit beschrijft technische verschillen, geen kansen op uitbuiting. Als twee bronnen verschillen, vergelijk dan de vectoren en beoordelingen van de bronnen voordat je een score kiest om vast te leggen.

Een basisscore beschrijft de technische kenmerken van de kwetsbaarheid. Informatie over de dreiging verandert in de loop van de tijd en dezelfde kwetsbaarheid kan in twee verschillende inrichtingen een andere betekenis hebben. CVSS biedt afzonderlijke groepen meetwaarden voor deze aanpassingen, met verschillende regels in versie 3.1 en 4.0.

Pas v3.1 aan de tijd aan

De v3.1-groep met tijdsafhankelijke meetwaarden bevat de volwassenheid van exploitcode, het oplossingsniveau en de betrouwbaarheid van de melding. De vermenigvuldigingsfactoren zijn:

Niet gedefinieerd telt als 1. Vermenigvuldig de basisscore met alle drie en rond naar boven af op één decimaal. Voor een basisscore van 9,8 met E:U, RL:O, RC:C:

Als de volwassenheid van de exploit hoog wordt terwijl de officiële oplossing beschikbaar blijft, wordt het product 9,31 en naar boven afgerond 9,4. Tijdsafhankelijke aanpassingen kunnen de basisscore verlagen of gelijk laten; hun factoren kunnen de score niet boven de basisscore verhogen.

Beschrijf de lokale omgeving

De omgevingsafhankelijke meetwaarden van v3.1 omvatten vereisten voor vertrouwelijkheid, integriteit en beschikbaarheid (CR, IR, AR), plus aangepaste basismeetwaarden zoals MAV en MPR. De weegfactoren voor vereisten zijn hoog 1,5, gemiddeld 1,0, laag 0,5 en niet gedefinieerd 1,0. Documenteer voor elke aanpassing het bewijs over de inrichting.

In het Heartbleed-voorbeeld geeft een hoog vertrouwelijkheidsvereiste een omgevingsscore van 9,3 en een laag vereiste een score van 5,7. Een kwetsbaarheid met basisscore 9,8 en de aangepaste aanvalsvector aangrenzend geeft 8,8. Gebruik de volledige omgevingscalculator; de berekening bestaat niet uit het vermenigvuldigen van een basisscore met een weegfactor voor een vereiste.

Lees de wijzigingen in CVSS 4.0

Versie 4.0 voegt aanvalsvereisten (AT) toe voor omstandigheden bij inrichting of uitvoering, zoals een raceconditie. Gebruikersinteractie wordt geen, passief of actief. Reikwijdte wordt vervangen door afzonderlijke impact op vertrouwelijkheid, integriteit en beschikbaarheid van het kwetsbare systeem (VC, VI, VA) en van vervolgsystemen (SC, SI, SA).

De groepen zijn basis, dreiging, omgeving en aanvullend. De volwassenheid van de exploit in de dreigingsgroep kan aangevallen, conceptbewijs, niet gemeld of niet gedefinieerd zijn; niet gedefinieerd wordt als aangevallen beoordeeld. Omgevingsvereisten worden standaard als hoog beoordeeld wanneer ze niet zijn gedefinieerd. Aangepaste waarden voor integriteit en beschikbaarheid van vervolgsystemen kunnen gevolgen voor de veiligheid aangeven. Aanvullende velden, waaronder veiligheid, automatiseerbaarheid, herstel, waardedichtheid, responsinspanning en urgentie volgens de aanbieder, voegen context toe zonder de score te veranderen.

Behoud de aanduidingen

Gebruik CVSS-B, CVSS-BT, CVSS-BE of CVSS-BTE om de gebruikte scoregroepen aan te geven. Versie 4.0 gebruikt scores op basis van opzoektabellen, dus gebruik de calculator van FIRST. Het Heartbleed-voorbeeld van FIRST is 8,7 CVSS-BT, tegenover 7,5 in v3.1; het voorbeeld met gereflecteerde XSS in Zimbra is 5,1 in v4.0 en 6,1 in v3.1. Een versiewijziging kan het getal veranderen zonder dat de software of de inrichting verandert.

Ernst beschrijft de mogelijke schade onder technische omstandigheden. Bewijs van uitbuiting vertelt je of aanvallers een kwetsbaarheid gebruiken of waarschijnlijk binnenkort zullen gebruiken. Deze signalen vullen CVSS en bedrijfscontext aan; geen enkele lijst beschrijft alle kwetsbaarheden.

Onderscheid bewijs van voorspelling

De Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) beheert de KEV-catalogus met bekende uitgebuite kwetsbaarheden. Voor opname zijn een toegekende CVE, betrouwbaar bewijs van uitbuiting in de praktijk en duidelijke richtlijnen om de kwetsbaarheid te verhelpen vereist. Vermeldingen geven ook bekend gebruik bij ransomware aan. Als een kwetsbaarheid niet in KEV staat, blijft de uitbuitingsstatus onduidelijk; nieuwe aanvallen of zwakke plekken zonder CVE staan er mogelijk niet in.

Het Exploit Prediction Scoring System (EPSS) van FIRST schat de kans op waargenomen uitbuitingsactiviteit voor een gepubliceerde CVE in de komende 30 dagen. Scores lopen van 0 tot 1 en worden dagelijks bijgewerkt. Het percentiel geeft de relatieve positie onder beoordeelde CVE's.

In een fictieve dagelijkse registratie betekenen EPSS 0,10 en percentiel 0,88 een geschatte kans van 10% op uitbuitingsactiviteit en een score die gelijk is aan of hoger is dan die van 88% van de beoordeelde CVE's. Het percentiel is geen uitbuitingskans van 88% en de score is niet de kans dat je eigen server wordt gecompromitteerd.

Beoordeel de sterkte van het signaal

Een gepubliceerd conceptbewijs laat zien dat er een aanpak voor een exploit bestaat. Bij het gereedmaken van aanvalsmiddelen wordt een aanpak omgezet in betrouwbare, bruikbare hulpmiddelen. Bevestigde uitbuiting in de praktijk, waaronder gebruik bij ransomware, is sterker bewijs dat nu actie nodig is. Volg leveranciersadviezen, dreigingsinformatie, centra voor informatie-uitwisseling en -analyse en updates van catalogi. Een lage EPSS-score kan veranderen wanneer nieuwe informatie beschikbaar komt.

Stel dat bevinding A CVSS 9,8 en EPSS 0,004 heeft en niet in KEV staat, op een interne testserver. Bevinding B heeft CVSS 7,5 en EPSS 0,94 en staat in KEV, op een via internet bereikbare VPN-gateway. Geef B voorrang: bevestigde aanvallen, directe bereikbaarheid en een kritieke toegangsrol komen samen. Plan A volgens het beleid in, in plaats van die van de werklijst te halen.

Gebruik beslisbomen voor actie

Stakeholder-Specific Vulnerability Categorization (SSVC) komt van het Software Engineering Institute van Carnegie Mellon University. De beslisboom van CISA houdt rekening met uitbuiting, technische impact, automatiseerbaarheid, belang voor de taakuitvoering en impact op het publieke welzijn. De beslissingen zijn volgen, volgen, aandacht geven en handelen*, van normaal volgen tot urgente gecoördineerde actie. Pas de daadwerkelijke beslisboom toe; één invoer kennen is niet genoeg om de uitkomst zelf te bepalen.

CISA's Binding Operational Directive 26-04, uitgegeven op 10 juni 2026, verving BOD 22-01. De richtlijn bindt Amerikaanse federale civiele uitvoeringsorganisaties voor systemen binnen het toepassingsgebied en baseert termijnen op openbare blootstelling, KEV-status, automatisering van de exploit en gedeeltelijke of volledige technische controle. Andere organisaties kunnen KEV vrijwillig gebruiken. De overgangsregeling van de richtlijn vereist dat organisaties de nieuwe termijnen voor beoordeling en het verhelpen van kwetsbaarheden uiterlijk op 7 december 2026 beginnen toe te passen.

Reageer wanneer er geen patch bestaat

Pas bij een zerodaykwetsbaarheid de risicobeperkende maatregelen van de leverancier toe, beperk de getroffen dienst en verscherp detectie en monitoring. Zodra een oplossing verschijnt, bepaal je de prioriteit op basis van ernst, blootstelling en bewijs van uitbuiting. Als aanvallen worden gemeld, escaleer je snel en onderzoek je mogelijke compromittering via het incidentresponsproces. EPSS omvat CVE's; beoordeel fouten in eigen code en configuratiefouten op basis van hun eigen bewijs.

Een prioriteit vertelt een eigenaar hoe snel actie nodig is en waarom. Begin met een gevalideerde bevinding en combineer vervolgens technische ernst, bewijs van uitbuiting, bereikbaarheid, waarde van het IT-middel, bestaande maatregelen en beschikbare oplossingen. Een score alleen kan de zakelijke gevolgen van een storing niet beschrijven.

Beoordeel het IT-middel en het aanvalspad

Externe IT-middelen zijn vanaf internet bereikbaar. Interne IT-middelen zijn bereikbaar nadat een aanvaller het netwerk is binnengedrongen of voor iemand van binnenuit. Geïsoleerde IT-middelen hebben minder toegangspaden, maar onderhoudsapparaten en verbindingen voor ondersteuning kunnen de scheiding nog steeds overbruggen.

De waarde van een IT-middel omvat de kriticiteitsklasse, gegevensclassificatie, het toepassingsgebied van regelgeving en afhankelijkheden. Een identiteitsprovider kan zelf weinig klantgegevens bevatten maar de toegang tot veel andere systemen beheren. Beoordeel de gevolgen voor diensten die van het kwetsbare IT-middel afhankelijk zijn, niet alleen voor de host zelf.

Reken een compenserende maatregel alleen mee als die het relevante pad blokkeert en is getest. Een webapplicatiefirewall die alleen detecteert, registreert aanvallen maar stopt ze niet. Een segmentatieregel die de kwetsbare dienst nog steeds vanuit gebruikersnetwerken toestaat, laat dat pad open.

Pas een beleid in volgorde toe

Bekijk dit voorbeeldbeleid, toegepast vanaf P1 naar beneden:

F1 is een kwetsbaarheid met score 9,8 op een geïsoleerde virtuele laboratoriummachine, zonder bekende exploit, met EPSS 0,02. Die voldoet niet aan P1 of P2 en is dus P3. F2 is een kwetsbaarheid met score 7,5 op een externe webserver en staat in KEV: P1. F3 is een injectiekwetsbaarheid met score 6,5 op een extern portaal van klasse 1, met een openbaar conceptbewijs en EPSS 0,20: P2 via de EPSS-drempel. F4 heeft score 8,8 op een interne bestandsserver met EPSS 0,15 en een patch: eveneens P2 via EPSS.

Pak F2 eerst aan. Binnen P2 krijgt F3 in dit voorbeeld voorrang op F4 vanwege de externe blootstelling van klanten. F1 blijft ingepland. Een numerieke sortering op CVSS zou de beperkt blootgestelde laboratoriumkwetsbaarheid eerst hebben geselecteerd en de aanpak van een bekende uitgebuite openbare dienst hebben vertraagd.

Kies een beschikbare actie

Een patch maakt het mogelijk de oplossing in te plannen. Als er geen oplossing bestaat, beperk je de blootstelling en monitor je de situatie terwijl je de nog verwachte oplossing volgt. Voor producten aan het einde van hun levensduur zijn vervangingsplanning en tijdelijke bescherming nodig. Het ontbreken van een patch verandert de aanpak; het neemt de prioriteit niet weg.

Bekijk combinaties op hetzelfde IT-middel. Een informatielek dat gebruikersnamen blootlegt, zwakke aanmeldingsmaatregelen en een oude plug-in kunnen een ernstiger pad vormen dan elke afzonderlijke regel doet vermoeden. Beoordeel verwante bevindingen samen voordat je de werkvolgorde bepaalt.

Leg de beslissing uit in het ticket

Vermeld de identiteit van het IT-middel, de eigenaar, het bewijs voor de bevinding, de aanbevolen aanpak, de prioriteit, de termijn en de reden. Bijvoorbeeld: “P1: de bevestigde kwetsbaarheid wordt aantoonbaar uitgebuit en het portaal is via internet bereikbaar; verhelp de kwetsbaarheid binnen het venster van 3 dagen uit het voorbeeldbeleid.” Behoud de motivering wanneer werk voor meerdere hosts wordt gegroepeerd. Een vermoedelijk foutpositief resultaat wordt snel gevalideerd voordat daarop een definitieve beslissing over de aanpak wordt gebaseerd.

Een aanpak verandert de zwakke plek, de blootstelling of de zakelijke beslissing over het risico. Kies de aanpak die de daadwerkelijke bevinding aanpakt en plan vervolgens wie die uitvoert en hoe het effect wordt gecontroleerd. Verhelpen is de standaard wanneer dat mogelijk is.

Onderscheid de mogelijke aanpakken

Een compenserende maatregel bereikt het doel van een vereiste maatregel wanneer die niet kan worden toegepast. De compenserende maatregel moet hetzelfde risico aanpakken, worden gedocumenteerd en worden geverifieerd. Een lijst met toegestane verbindingen voor segmentatie kan een niet te patchen verouderde dienst beschermen; een webapplicatiefirewallregel kan virtueel patchen tegen een bekend exploitpatroon mogelijk maken. Detectie alleen laat het aanvalspad nog steeds open.

Classificeer maatregelen op twee manieren

Het type maatregel beschrijft de uitvoering: administratieve of bestuurlijke maatregelen omvatten beleid en risicobesluiten; operationele maatregelen zijn dagelijkse menselijke processen zoals wijzigingsbeheer; technische maatregelen omvatten MFA en firewalls; fysieke maatregelen omvatten sloten en paslezers.

De functie van een maatregel beschrijft de taak: preventieve maatregelen stoppen gebeurtenissen, detectieve maatregelen sporen ze op, corrigerende maatregelen verwijderen zwakke plekken of herstellen schade en responsmaatregelen dammen een incident tijdens het incident in. Een kwetsbaarheidsscan is detectief. Een patch is corrigerend. Geautomatiseerde endpointisolatie kan een responsmaatregel zijn. Eén maatregel kan meerdere functies vervullen; type en functie zijn afzonderlijke indelingen.

Plan de wijziging als een reeks stappen

1. Test de update of configuratie in een omgeving die op productie lijkt.
2. Implementeer via een goedgekeurde wijziging en een onderhoudsvenster.
3. Bereid vóór de productiewijziging bewijs en stappen voor om terug te keren naar een eerdere toestand, zoals een back-up of momentopname.
4. Valideer dat de dienst werkt en de oorspronkelijke zwakke plek is verdwenen.

Een actief uitgebuite kwetsbaarheid kan goedkeuring voor een spoedwijziging vereisen. Een onderhoudsvenster per kwartaal kan een beleidstermijn van 15 dagen niet stilzwijgend vervangen. Spreek een extra venster af, gebruik gefaseerde updates waar redundantie dat toestaat of verkrijg een tijdelijke uitzondering met geverifieerde maatregelen.

Werk een geblokkeerde update af

Een webmodule heeft een kritieke kwetsbaarheid voor uitvoering van code op afstand. De patch is beschikbaar, maar goedkeuring voor de applicatie duurt drie weken en de termijn is 15 dagen. Schakel de module uit als die niet wordt gebruikt. Test anders een virtuele patch, beperk de toegang tot noodzakelijke partnernetwerken en verscherp de monitoring. Leg het resterende risico vast en verkrijg de vereiste uitzondering, installeer daarna de goedgekeurde update en scan opnieuw.

Verminder ook het aanvalsoppervlak: spoor externe IT-middelen op via scans vanaf de netwerkrand, DNS en certificaatregistraties; verwijder ongebruikte diensten en buiten gebruik gestelde systemen. Tests van beveiligingsmaatregelen, penetratietests, aanvallersemulatie en bugbountymeldingen kunnen paden aan het licht brengen die aandacht nodig hebben. Door een onnodige component te verwijderen, voorkom je dat zich daarop toekomstige bevindingen opstapelen.

Sommige echte bevindingen kunnen niet binnen de beleidstermijn worden verholpen. Een uitzondering maakt het daaruit voortvloeiende risico zichtbaar en wijst een bevoegde eigenaar aan voor de beslissing. Het is een beheerst besluit met een einddatum, geen manier om moeilijk werk van het dashboard te laten verdwijnen.

Kies de risicostrategie

Bij acceptatie wordt het risico bewust behouden omdat de bedrijfsvoering de activiteit nodig heeft of omdat de kosten van de aanpak zwaarder wegen dan het verwachte voordeel. Risicobeperking verlaagt de waarschijnlijkheid of impact. Vermijding beëindigt de risicovolle activiteit. Overdracht verschuift een deel van de financiële gevolgen via een contract of verzekering, terwijl de eindverantwoordelijkheid bij de organisatie blijft.

Een contract of verzekeringspolis voorkomt niet dat een exploit een ongepatchte dienst bereikt. Beoordeel het toepassingsgebied ervan afzonderlijk van technische maatregelen. Bij een afgewezen uitzondering moet nog steeds een beslissing worden genomen: maatregelen versterken, de kwetsbaarheid verhelpen of de activiteit stoppen.

Leg de uitzondering vast

Registreer het specifieke IT-middel en de bevinding, de zakelijke rechtvaardiging, risicoanalyse, compenserende maatregelen, het restrisico, de bevoegde goedkeurder, vervaldatum en aanleidingen voor een eerdere beoordeling. Koppel de registratie aan het werk voor het verhelpen van de kwetsbaarheid, zodat de beoogde permanente oplossing zichtbaar blijft.

Een foutpositief resultaat betekent dat de gerapporteerde zwakke plek ontbreekt en wordt met bewijs afgesloten. Een uitzondering betekent dat de zwakke plek echt is en het restrisico tijdelijk wordt behouden. Door een echte bevinding ten onrechte als foutpositief te onderdrukken, zou juist het risico verdwijnen dat het management moet goedkeuren.

Stem de goedkeuring af op het resterende risico

De risico-eigenaar keurt goed op een niveau dat past bij het restrisico. Een uitzondering met laag risico kan binnen de bevoegdheid van een eigenaar van een IT-middel vallen, terwijl hoog restrisico goedkeuring van de hoogste leiding of de hoogste verantwoordelijke voor informatiebeveiliging kan vereisen. De beheerder die om uitstel van werk vraagt, keurt dat verzoek niet alleen zelf goed. Het beveiligingsteam beoordeelt het bewijs en beveelt maatregelen aan.

Vergelijk het resterende risico met de risicobereidheid van de organisatie. Een besluit buiten de gedelegeerde bevoegdheid moet naar een hoger niveau of worden afgewezen. Dat een systeem moeilijk te vervangen is, verklaart het verzoek; het toont niet aan dat het risico acceptabel is.

Volg een voorbeeld met een verouderd systeem

Een laboratoriuminstrument gebruikt een controller met Windows 7 waarop leverancierssoftware draait die niet op een nieuwer systeem kan werken. De standaardondersteuning eindigde op 14 januari 2020 en vervanging is voor volgend jaar begroot. Het team registreert de niet-ondersteunde controller als een echte bevinding en stelt een geïsoleerd netwerk, uitgeschakelde USB-opslag, een lijst met toegestane applicaties en aanvullende monitoring voor.

Het afdelingshoofd en de beveiligingsleiding beoordelen het ingeschatte restrisico. De uitzondering vervalt na zes maanden of zodra de vervanging is geïnstalleerd, afhankelijk van wat het eerst gebeurt. Het vervangingsproject heeft nog steeds een eigenaar en mijlpalen, ook al valt de evaluatiedatum van de uitzondering vóór de verwachte voltooiing.

Beoordeel opnieuw wanneer omstandigheden veranderen

Een nieuwe exploit, KEV-vermelding, falende compenserende maatregel of verandering in blootstelling kan de eerdere beoordeling vóór de vervaldatum ongeldig maken. Beoordeel het risico dan opnieuw, niet alleen op de kalenderdatum. Volg het aantal en de ouderdom van uitzonderingen, naderende vervaldata en openstaande permanente oplossingen. Vermijd algemene uitzonderingen voor hele omgevingen: verschillende IT-middelen kunnen verschillende aanvalspaden, eigenaren en gevolgen hebben.

Een geïnstalleerde update is een actie; geverifieerd verhelpen is een resultaat. Sluit een bevinding pas af wanneer bewijs toont dat de oorspronkelijke zwakke plek is verdwenen en de dienst nog werkt. Volg de tijd en dekking achter dat bewijs, zodat managers kunnen zien waar risico blijft bestaan.

Verifieer de oorspronkelijke toestand

Scan getroffen IT-middelen opnieuw met hetzelfde relevante scantype en werkende authenticatiegegevens, of onderzoek rechtstreeks de daadwerkelijk gebruikte pakketbuild of instelling. Bevestig dat de controle met succes is uitgevoerd. Een mislukte aanmelding kan niet aantonen dat een lokale kwetsbaarheid is verholpen. Valideer ook compenserende maatregelen: test of de nieuwe toegangsregel of virtuele patch het relevante pad daadwerkelijk blokkeert.

Een oplossing kan falen omdat een herstart nog moet plaatsvinden, slechts één clusterknooppunt is bijgewerkt, een applicatie een eigen oudere bibliotheek bevat of een uitrol de instelling overschrijft. Als vervangende instanties de kwetsbaarheid steeds terugbrengen, werk dan het goedgekeurde basisimage of sjabloon bij waarmee ze worden aangemaakt. Beschouw herhaald heropenen als bewijs van een grondoorzaak in het bouw- of uitrolproces.

Gebruik duidelijke werkprocesstatussen

Voer werk door statussen zoals open, in behandeling, risico beperkt, risico geaccepteerd, opgelost in afwachting van verificatie en afgesloten. “Risico beperkt” betekent dat een maatregel het risico heeft verminderd; “afgesloten” vereist het relevante bewijs voor afsluiting. Integratie van scanner en ticketsysteem kan duplicaten verminderen, maar geautomatiseerde statuswijzigingen moeten nog steeds de regels voor geslaagde verificatie en uitzonderingen volgen.

Lees meetwaarden samen

Vijf kritieke bevindingen worden na 4, 9, 12, 20 en 30 dagen afgesloten:

Bij een SLO van 15 dagen waren er slechts drie op tijd:

Het gemiddelde voldoet aan 15 dagen terwijl 40% van deze bevindingen de doelstelling miste. Rapporteer ook openstaande achterstallige bevindingen: een gemiddelde van voltooid werk zegt niets over hoe oud een onopgelost item is geworden.

Escaleer werk dat een beslissing vereist

Ouderdomscategorieën zoals 0–30, 31–60, 61–90 en langer dan 90 dagen tonen vastgelopen werk. Vergelijk de ouderdom van elk item met de eigen termijn en volg dan het beleid van eigenaar naar manager naar risicocomité. Een recent uitgebuite kwetsbaarheid kan directe escalatie vereisen, vóór een ouderdomsdrempel wordt bereikt.

Technische teams hebben hostlijsten, bewijs en oplossingen nodig. Managers hebben trends, de belangrijkste risico's, achterstallig werk en de benodigde middelen of beslissingen nodig. Een dalend totaal kan komen door mislukte scans of snelle afsluiting van items met weinig impact; vergelijk daarom de dekking en ouderdom van werk met hoge prioriteit voordat je dit als voortgang beschouwt.

Applicatiebevindingen beschrijven fouten in de manier waarop software omgaat met gegevens, geheugen, identiteit of fouten. Stem de oplossing af op het mechanisme. De OWASP Top 10:2025 is een bewustwordingslijst: gebrekkige toegangscontrole, beveiligingsconfiguratiefouten, tekortkomingen in de softwaretoeleveringsketen, cryptografische fouten, injectie, onveilig ontwerp, authenticatiefouten, fouten in software- of gegevensintegriteit, tekortkomingen in beveiligingsregistratie en alarmering, en onjuiste afhandeling van uitzonderlijke omstandigheden.

Voorkom dat gegevens instructies worden

Injectie ontstaat wanneer niet-vertrouwde invoer onderdeel wordt van een query of opdracht. Gebruik geparametriseerde query's, validatie met een lijst van toegestane waarden en accounts met minimale rechten; vermijd shellaanroepen die uit gebruikersinvoer worden opgebouwd. Cross-site scripting (XSS) voert een door een aanvaller aangeleverd script uit in de browser van een andere gebruiker. Gereflecteerde XSS komt terug in een directe reactie, opgeslagen XSS wordt bewaard voor latere bezoekers en DOM-gebaseerde XSS ontstaat in code aan de clientzijde. Gebruik contextafhankelijke uitvoercodering en veilige sjablonen, ondersteund door een Content Security Policy. HttpOnly-cookies beperken de toegang van scripts tot cookies, maar herstellen onveilige uitvoer niet.

Onderscheid verzoeken en bestandstoegang

SSRF kan cloudmetadata bereiken op 169.254.169.254. Bestandsinclusie kan inhoud openbaar maken of code uitvoeren, afhankelijk van hoe de applicatie het bestand verwerkt.

Bescherm geheugen en rechten

Een bufferoverloop schrijft voorbij toegewezen stack- of heapgeheugen. Een integeroverloop overschrijdt het bereik van een type; bij 8-bits rekenkunde zonder teken kan 255 plus 1 teruglopen naar 0. Gebruik grenscontroles, veilige functies en geheugenveilige programmeertalen. ASLR, DEP/NX en stackcanaries maken uitbuiting moeilijker terwijl de programmeerfout blijft bestaan.

Gebrekkige toegangscontrole laat gebruikers hun bevoegdheden overschrijden, bijvoorbeeld door de factuur van een andere klant te lezen na wijziging van de identificatie. Controleer bij elk verzoek de autorisatie aan de serverzijde en weiger standaard toegang. Verticale rechtenverhoging levert hogere rechten op; horizontale rechtenverhoging geeft toegang tot de rechten van een andere gebruiker. Oplossingen voor authenticatie en sessies omvatten MFA, willekeurige sessie-ID's, vernieuwing bij aanmelding en het laten verlopen van sessies.

Pak ontwerp en ondersteunende diensten aan

Cryptografische fouten omvatten onversleutelde gegevens, vast in de code opgenomen sleutels en snelle wachtwoordhashes. Gebruik TLS 1.2 of hoger, beheerde sleutels en langzame wachtwoordhashes zoals Argon2 of bcrypt. Verwijder standaardaccounts, onnodige functies, directoryvermeldingen en uitgebreide foutmeldingen. Valideer specifieke componentkwetsbaarheden afzonderlijk van het ondersteuningsrisico aan het einde van de levensduur.

Onveilig ontwerp vereist wijzigingen in ontwerp en implementatie, met dreigingsmodellering om ontbrekende maatregelen te identificeren. Uitvoering van code op afstand laat een aanvaller gekozen code op afstand uitvoeren; lokale code-uitvoering heeft een andere toegangsvoorwaarde. Gegevensvergiftiging tast vertrouwde gegevens of trainingsgegevens aan: beheer bronnen en volg de herkomst. Weiger toegang wanneer fouten optreden, zodat uitzonderlijke omstandigheden geen toegang verlenen. Een webapplicatiefirewall kan de blootstelling tijdens het herstellen van code verminderen, maar de onveilige code moet nog steeds worden gerepareerd.

Veilige software heeft controles in verschillende fasen nodig omdat geen enkele test het hele systeem ziet. Voeg beveiligingsvereisten, dreigingsmodellering, codebeoordeling, geautomatiseerde tests, uitrolcontroles en onderhoud toe aan de softwareontwikkelingslevenscyclus (SDLC). Geschikte controles naar een eerdere fase verplaatsen heet eerder testen.

Vergelijk de testmethoden

SAST kan een verzoekwaarde markeren die aan een query wordt gekoppeld. DAST kan bewijs uit reacties van de actieve testapplicatie leveren. Valideer het gecombineerde bewijs voordat je de codeoplossing kiest. Fuzzing voegt tests met onjuist gevormde invoer toe om crashes en andere fouten te vinden. Authenticatie en het bereik van de verkenning zijn belangrijk: een DAST-uitvoering die nooit een beheerpagina bereikt, heeft de invoer daarvan niet beoordeeld.

Vind getroffen afhankelijkheden

SCA leest pakketmanifesten, lockbestanden of binaire bestanden om meegeleverde componenten te identificeren. Zo wordt log4j-core 2.14.1 getroffen door Log4Shell, CVE-2021-44228, met CVSS v3.1 10,0. De oplossing vereist een geschikte verholpen release en het opnieuw uitrollen van elke applicatie die de component bevat. De historische ondergrens voor de oplossing op Java 8, 2.17.1, verhelpt de kwetsbaarheden die met dat incident samenhangen; kies voor nieuw werk een momenteel ondersteunde, door de leverancier aanbevolen release.

Een SBOM registreert componenten, versies, leveranciers en afhankelijkheidsrelaties in een machineleesbaar formaat zoals SPDX of CycloneDX. Die beantwoordt waar een component wordt gebruikt. Een VEX-verklaring van een leverancier geeft aan of een product voor een kwetsbaarheid niet getroffen, getroffen, verholpen of in onderzoek is. Valideer of het product en de versie in de VEX-verklaring overeenkomen en controleer de onderbouwing voordat je de status van een bevinding wijzigt.

Bescherm de toeleveringsketen

Gecompromitteerde updatekanalen, kwaadaardige pakketten met vergelijkbare namen en niet meer onderhouden afhankelijkheden kunnen via vertrouwde leveranciers risico introduceren. De compromittering van SolarWinds Orion in 2020 illustreert een aanval via een updatekanaal. Beoordeel de werkwijzen van leveranciers; spreek verwachtingen voor patches en openbaarmaking af; vraag softwarestuklijsten op; verifieer hashes of handtekeningen; leg afhankelijkheden op vaste versies vast; en gebruik goedgekeurde interne registers. Door versies vast te zetten, blijven wijzigingen beheerst, maar een verouderde vastgezette afhankelijkheid heeft nog steeds beoordeling en updates nodig.

Bouw beveiliging in het programma in

Dreigingsmodellering gebruikt het ontwerp om te onderzoeken wat er mis kan gaan. STRIDE omvat identiteitsvervalsing, manipulatie, ontkenning van handelingen, openbaarmaking van informatie, dienstweigering en verhoging van rechten. Zet geïdentificeerde dreigingen om in maatregelen en testgevallen.

Het Software Assurance Maturity Model (SAMM) van OWASP organiseert programmaverbetering over governance, ontwerp, implementatie, verificatie en bedrijfsvoering: drie praktijken per functie, 15 in totaal, met volwassenheidsniveaus 1–3. Gebruik het model om capaciteiten te plannen, terwijl dagelijks veilig programmeren gegevens van opdrachten scheidt, uitvoer codeert, authenticatiegegevens en sessies beschermt, rechten beperkt en fouten afhandelt zonder interne details bloot te leggen.

Cloudbeveiliging hangt af van het werk van zowel provider als klant. Bepaal het servicemodel voordat je een bevinding toewijst en beoordeel vervolgens zowel uitgerolde instellingen als de images, code en sjablonen waarmee ze worden gemaakt. Cloudresources kunnen sneller veranderen dan een periodieke netwerkscan kan bijhouden.

Verdeel verantwoordelijkheden per servicemodel

In elk model blijven klanten verantwoordelijk voor hun gegevens en voor wie daartoe toegang heeft. Een beheerde database kan het patchen van het besturingssysteem overnemen, terwijl de klant nog steeds overmatige rechten of openbare blootstelling moet verhelpen.

Lees bevindingen over de beveiligingsstatus per resource

Beheer van de cloudbeveiligingsstatus (CSPM) controleert configuraties via API's van providers, meestal met alleen-lezentoegang. Prowler en ScoutSuite rapporteren bevindingen per resource en aan de hand van normen, zoals CIS-basisnormen voor cloudomgevingen. Herhaal controles omdat accountinstellingen, identiteiten en netwerkregels vaak veranderen.

Veelvoorkomende bevindingen zijn openbare opslag, te ruime identiteitsrechten zoals "Action": "*", onversleutelde volumes of momentopnamen, uitgeschakelde registratie, aan code toegevoegde toegangssleutels, gebruikers met verhoogde rechten zonder MFA, blootgestelde beheerinterfaces en SSH- of RDP-toegang vanaf het hele internet. 0.0.0.0/0 omvat alle IPv4-adressen; een regel die dit voor poort 22 of 3389 toestaat, stelt de beheerdienst bloot waar de resource ook bereikbaar is.

Herstel de uitrolbron

Infrastructuur als code (IaC) beschrijft resources in sjablonen. Checkov of Trivy kan vóór uitrol een Terraform-regel markeren die cidr_blocks = ["0.0.0.0/0"] voor SSH bevat. Beperk de toegang tot het vereiste beheeradresbereik of gebruik een goedgekeurde bastion- of sessiebeheerdienst.

Corrigeer zowel de uitgerolde instelling als het bijbehorende sjabloon. Anders kan de volgende uitrol de blootstelling herstellen. Verschillen tussen vastgelegde en werkelijke instellingen zijn configuratieafwijkingen. Een correctie alleen in de console kan tijdelijk zijn, ook als de directe controle slaagt.

Bouw images opnieuw en dek kortstondig werk

Scan containerimages in de bouwpijplijn en het register op besturingssysteempakketten en bibliotheken. Bouw opnieuw vanuit een bijgewerkt basisimage en rol opnieuw uit; vertrouw niet op het patchen van afzonderlijke draaiende containers. Minimale basisimages verminderen onnodige componenten. Onderzoek ook Kubernetes-definities op risicovolle instellingen zoals uitvoering met verhoogde rechten.

Gebruik API's van providers en resourcetags om kortstondige instanties te inventariseren. Beoordeel hun goedgekeurde basisimages, sjablonen en afhankelijkheden; gebruik waar passend ondersteunde agents of beoordeling van momentopnamen. Bij beheerde serverloze uitvoeringsomgevingen volgen updates door de provider de update-instellingen van de dienst. Klanten onderhouden functiecode en bibliotheken, bouwen containergebaseerde functies opnieuw en werken eigen uitvoeringsomgevingen bij.

Behandel een bevinding over de beveiligingsstatus tot en met verificatie

Een beoordeling vindt openbare opslag van persoonsgegevens, roottoegang zonder MFA en RDP-toegang vanaf het hele internet. Beperk de blootgestelde gegevens onmiddellijk en pak de identiteit met verhoogde rechten en het beheerpad met spoed aan. Corrigeer bucket- en netwerkregels in uitgerolde resources en IaC. Registreer MFA voor de AWS-rootgebruiker via de Management Console; gewone API's en IaC kunnen dit niet inschakelen. Voer de relevante controles opnieuw uit, verifieer dat de applicatietoegang nog werkt en controleer of een latere uitrol de correctie behoudt.