Page Comparison

Wat is het?  

Maatregelen worden genomen als gevolg van een geïdentificeerd risico. Volgende mogelijkheden doen zich voor: 

• Preventie: vermijden dat iets gebeurt of het verlagen van de waarschijnlijkheid dat het gebeurt; 

• Detectie: detecteren van de (potentiële) schade zou een bedreiging optreden; 

• Reactie: beperken van de schade wanneer een bedreiging optreedt of het effect hiervan gedeeltelijk of geheel corrigeren. 

Bij preventieve maatregelen wordt de dreiging verkleind tot het niveau dat ze aanvaardbaar is.  

Detectieve maatregelen zorgen ervoor dat een dreiging en het gevolg ervan tijdig ontdekt wordt. 

Reactieve maatregelen richten zich op de gevolgen indien een dreiging zich toch voordoet, door het inperken of herstellen van de schade. 

Kwestbaarhedenbeheer is zowel een preventieve (code review, code analyse), detectieve (vulnerability scanning, penetration testing, performance testing) als reactieve (monitoring, patch management, incident response) maatregel. 

Met "kwetsbaarhedenbeheer" doelen we op het gehele proces van het identificeren, beoordelen, en aanpakken van kwetsbaarheden in een systeem of applicatie. Dit proces omvat enerzijds (geautomatiseerde) scans en analyses, waarbij toepassingen en hun onderliggende infrastructuur regelmatig worden gecontroleerd op bekende kwetsbaarheden zoals ontbrekende patches, misconfiguraties of softwarefouten gerelateerd aan bekende kwetsbaarheidspatronen. Anderzijds wordt informatie verzameld uit externe bronnen, zoals meldingen van kwetsbaarheden door derde partijen, leveranciers, openbare databases (bijv. CVE), en andere externe (security) organisaties. 

Deze bredere aanpak zorgt ervoor dat niet alleen intern gedetecteerde kwetsbaarheden worden aangepakt, maar ook die welke vanuit externe bronnen worden gemeld. De opgespoorde kwetsbaarheden en externe meldingen op omgevingen die ook extern bereikbaar zijn, worden behandeld als security incidenten, zoals beschreven in het Beleidsdocument "Incident beheer". 

Als je diensten afneemt van een Security Operations Center (SOC), kan dit in deze context helpen om snel te reageren op meldingen, wat zorgt voor een onmiddellijke risicoreductie en budgettaire voordelen. 

In welke omgeving doe je kwetsbaarhedenbeheer? 

In een traditionele DTAP-opzet (Development, Testing, Acceptance, Production) zijn er verschillende omgevingen waarin kwetsbaarhedenbeheer moet worden uitgevoerd. Elk van deze omgevingen heeft een specifieke rol en draagt bij aan een robuust en effectief proces om beveiligingsrisico's proactief te identificeren en te mitigeren. Wat volgt is een overzicht van het volledige kwetsbaarhedenbeheerproces, inclusief alle mogelijke testen en scans. Dit overzicht dient als een menukaart waaruit alleen de noodzakelijke stappen moeten worden geselecteerd, afhankelijk van de behoeften en risico's van de betreffende omgeving. 

Development (Ontwikkelingsomgeving) 

In de ontwikkelingsomgeving worden systemen en applicaties gebouwd en aangepast. Hoewel de focus hier ligt op het creëren van nieuwe functionaliteiten, is het cruciaal om in deze vroege fase al rekening te houden met beveiliging. Kwetsbaarhedenbeheer in de ontwikkelingsomgeving richt zich op: 

• Code-review en statische analyse: Het gebruik van tools die de broncode analyseren op beveiligingsfouten, zoals SQL-injecties, XSS, en andere programmeerfouten. 

• Beveiliging by design: Integratie van beveiligingsprincipes en -standaarden in de ontwikkelingscyclus (zoals OWASP). 

Hoewel de ontwikkelingsomgeving vaak niet rechtstreeks aan productie gerelateerde risico's blootgesteld is, is het belangrijk om kwetsbaarheden vroeg te identificeren om te voorkomen dat ze doorsijpelen naar latere omgevingen. 

Testing (Testomgeving) 

In de testomgeving wordt de nieuwe code of de gewijzigde configuratie uitvoerig getest. Dit is een cruciale fase voor kwetsbaarhedenbeheer omdat hier integratietests worden uitgevoerd en applicaties in een bijna-productieomgeving worden getest.  

• Vulnerability scanning: Tools zoals vulnerability scanners kunnen worden ingezet om potentiële kwetsbaarheden in de applicatie te identificeren voordat deze naar de volgende fase gaat. 

• Dynamische analyse: Tijdens dynamische analyse wordt de applicatie getest terwijl deze actief draait om kwetsbaarheden te identificeren die alleen tijdens runtime zichtbaar zijn. Dit omvat het controleren van zaken zoals invoervalidatie, geheugenbeheer en de interactie met andere systemen, wat kan helpen om kwetsbaarheden op te sporen die niet door statische analyse of scans worden gedetecteerd. 

• Initiële performantietesten: Basis prestatietesten om te controleren of het systeem onder normale belasting functioneert zonder problemen. 

• Penetratietesten: Hoewel penetratietesten vaak in de acceptatie- of productieomgeving plaatsvinden, kan het nuttig zijn om in de testomgeving al een eerste ronde uit te voeren om ernstige kwetsbaarheden te detecteren. 

Het doel in de testomgeving is om beveiligingsproblemen te vinden die in de ontwikkelingsfase gemist zijn, zonder dat deze al impact kunnen hebben op echte gebruikers. 

Acceptance (Acceptatieomgeving) 

De acceptatieomgeving simuleert de productieomgeving en dient als laatste controlepunt voordat een systeem of applicatie naar productie wordt vrijgegeven. Hier vinden vaak intensievere kwetsbaarhedentesten plaats, aangezien de acceptatieomgeving een representatieve weergave is van de productieomgeving. Tevens is dit de meest geschikte plaats om performantietesten op grotere schaal uit te voeren, aangezien deze omgeving de reële belasting en schaal van de productieomgeving simuleert. 

• Vulnerability scanning en penetratietesten: Deze worden uitgebreid uitgevoerd om zeker te zijn dat er geen kwetsbaarheden meer aanwezig zijn. 

• Performantietesten (Belastingtests): Simuleren van hoge belasting op systemen en applicaties om te testen of de beschikbaarheid en prestaties onder stressvolle omstandigheden voldoende blijven. Dit omvat tests zoals load testing, stress testing en endurance testing. 

• Security review: In deze fase kan een formele security review plaatsvinden, waarbij de volledige applicatie en infrastructuur wordt beoordeeld op mogelijke kwetsbaarheden. 

De acceptatieomgeving biedt een veilige omgeving om laatste kwetsbaarheden te identificeren zonder dat de eindgebruikers beïnvloed worden. 

Production (Productieomgeving) 

De productieomgeving is de omgeving waarin het systeem of de applicatie daadwerkelijk operationeel is en wordt gebruikt door eindgebruikers. Kwetsbaarhedenbeheer in de productieomgeving is essentieel om de beveiliging te waarborgen en risico's voor de organisatie te beperken. 

• Continue monitoring en scanning: In de productieomgeving is continue monitoring van kwetsbaarheden via SIEM-systemen of real-time vulnerability scanners essentieel om nieuwe dreigingen snel op te sporen. 

• Patch management: Wanneer kwetsbaarheden in de productieomgeving worden gedetecteerd, moeten er snel patching- of mitigatieacties plaatsvinden om beveiligingsincidenten te voorkomen. 

• Incident response: Als er kwetsbaarheden worden geëxploiteerd, is een snel incidentbeheerproces nodig om de impact te minimaliseren. 

In de productieomgeving ligt de nadruk op reactief kwetsbaarhedenbeheer (bij nieuwe exploits of kwetsbaarheden) en proactief beheer via continue monitoring. 

Wat te doen? 

De scope van kwetsbaarheden waartegen je scant of die je beheert via externe meldingen, leg je vast in overleg met de specialist informatieveiligheid van je entiteit. Dit leidt tot het instellen van parameters in de gebruikte tooling voor scans en tot een afwegingskader voor het behandelen van externe meldingen. 

Je maakt een risico-afweging van welke kwetsbaarheden je moet oplossen, ongeacht of deze via scans, interne of externe bronnen aan het licht komen. Het streefdoel is dat je zoveel mogelijk kwetsbaarheden oplost in de mate van het financieel/projectmatig haalbare. Indien er rest-risico’s zijn, moet de (toepassings)beheerder deze formeel laten aanvaarden door het (top)management, zoals beschreven in het Beleidsdocument “Risicobeheer”. 

Daarnaast moeten kwetsbaarheden die worden geïdentificeerd, kunnen geremedieerd worden via het incidentbeheerproces. Dit houdt in dat elke kwetsbaarheid waarvoor actie nodig is, kan leiden tot de aanmaak van een incidentticket wat dan via het incidentbeheer verder dient opgelost te worden. Voor assets onder klasse 5 moet niet alleen dit ticket automatisch worden aangemaakt, maar dient ook een automatische opvolging van de remediëring te worden opgezet, zodat er zekerheid is dat de oplossing effectief wordt doorgevoerd en opgevolgd. 

NIS2 vereist daarbovenop specifiek dat organisaties maatregelen nemen om de integriteit van software en systemen te waarborgen voor zeer vertrouwelijke data (klasse 5). Hiervoor wordt gebruikgemaakt van code signing, waarbij cryptografische handtekeningen worden gebruikt om te verifiëren dat de code authentiek is en niet werd gewijzigd. Waar mogelijk moeten daarbij geautomatiseerde tools worden ingezet om direct notificaties te ontvangen wanneer tijdens de integriteitsverificatie afwijkingen worden vastgesteld. Dit stelt ons in staat om snel te reageren op potentiële integriteitsproblemen en zo te voorkomen dat onbevoegde of gemanipuleerde code de systemen binnendringt. 

Naast integriteitscontroles op software, schrijft NIS2 ook voor dat organisaties hardware-integriteitscontroles implementeren om ongeautoriseerde manipulatie van hardware in kritieke systemen te detecteren. Dit betekent dat er periodiek controles moeten worden uitgevoerd om te verzekeren dat de hardware niet werd aangetast of aangepast.  

Bij het ontdekken van integriteitsschendingen moeten beveiligingsmaatregelen automatisch worden geactiveerd om de dreiging in te perken en verdere schade te voorkomen. Deze maatregelen omvatten onder andere: 

• Het blokkeren van verdachte software en/of hardware die niet aan de integriteitscontroles voldoet. 

• Het automatisch herstellen van legitieme code om te garanderen dat het systeem in een veilige staat blijft. 

• Het uitvoeren van aanvullende controles en audits om de omvang van de integriteitsschending te bepalen en de impact te minimaliseren. 

Welke tools? 

De Vlaamse overheid legt geen specifieke tools op. Het team Informatieveiligheid kan wel advies verlenen. Dit is een dienst die je kunt afnemen binnen het raamcontract. 

Scope? 

Vulnerability management strekt zich uit over alle toepassingen en hun onderliggende infrastructuurcomponenten die onder de verantwoordelijkheid van de Vlaamse overheid vallen. Deze kunnen intern beheerd worden of uitbesteed zijn aan een leverancier. In geval van uitbesteding, moet je contractueel afdekken dat de leverancier zowel vulnerability scans uitvoert als externe meldingen beheert, en dat de Vlaamse overheid inzicht krijgt in de resultaten en remediëring van gevonden kwetsbaarheden. Hoe betrokken je hierin bent, hangt af van je risico-appetijt, zoals ook reeds hierboven besproken. 

Opgelegde beperkingen? 

Vulnerability scans en het beheer van externe meldingen mogen in geen geval de operationele setup van systemen beïnvloeden of in gevaar brengen. De primaire systeemfuncties moeten altijd beschikbaar blijven, en de stabiliteit, beschikbaarheid of prestaties van het systeem mogen niet worden verstoord. Voor externe meldingen geldt dat snelle actie essentieel is, maar ook deze moet plaatsvinden zonder de operationele continuïteit te schaden. 

Bij vulnerability scans, die standaard op afstand worden uitgevoerd, moeten extra voorzorgsmaatregelen worden getroffen om datalekken te voorkomen, met name bij systemen die gevoelige data bevatten. Dit omvat het versleutelen van gegevens tijdens de transmissie, het beperken van de toegang tot gevoelige systemen tijdens de scan, en het toepassen van strikte toegangs- en loggingmaatregelen.