Document toolboxDocument toolbox

5.2.3. Aanvullende informatie over de maatregelen (logging en monitoring) 3.0

Owned by Kenzo Vertenten (VO)
Last updated: 12 Dec, 2024 by Tom De Cubber
20 min read

Om review makkelijker te maken werden de wijzigingen tegenover ICRv2 als volgt in de tekst duidelijk gemaakt:

  • Nieuw toegevoegde tekst wordt overal in het rood weergegeven

5.2.3.1 Log Informatie

5.2.3.1.1 Bronnen voor logging

Er zijn vele verschillende soorten mechanismen voor logging van componenten die naast elkaar
kunnen voorkomen. Voorbeelden van deze mechanismen zijn:

  • SYSLOG is een standaard voor computerlogging. De logging is gescheiden tussen systemen die de logging genereren en systemen die de logging opslaan.

  • SNMP staat voor Simple Network Management Protocol. Dit protocol kan worden gebruikt voor het besturen van netwerkapparaten. Het protocol voorziet ook in statusmeldingen (traps).

  • De Windows Event log is standaard in de Windows-besturingssystemen aanwezig en kan ook naar een centrale logvoorziening worden verzonden.

  • Losse logbestanden zoals tekstbestanden, komma gescheiden (CSV) bestanden en andere varianten.

  • Vanuit applicaties en binnen databases wordt vaak gelogd binnen de database zelf of een aparte database. Deze logging is doorgaans gestructureerd en ook door te zenden aan een centraal logsysteem.

  • Logging van beveiligingssystemen, zoals Intrusion Detection Systems

Een systeem voor logging zou er dan bijvoorbeeld zo kunnen uitzien:

Binnen de Vlaamse overheid worden audit records verzameld uit de diverse bronsystemen, 

  • Dit kan gaan over systeem data op alle soorten servers, netwerk apparaten, eindgebruikersapparaten en allerlei soorten devices, over applicatie data tot data die gegenereerd wordt door tools die gedrag van eindgebruikers monitoren (via bv. endpoints). Aangezien alle moderne apparaten beschikken over een logging-functie, dienen deze zonder uitzondering geactiveerd en als bronsysteem geïntegreerd te worden. Voor oudere apparaten die deze functionaliteit niet ingebouwd hebben dient bekeken te worden hoe logging kan gerealiseerd worden. 

  • Deze lijst met bronsystemen is niet exhaustief en kan slechts beschouwd worden als een startpunt voor de inventaris van mogelijke bronsystemen voor audit records. 

5.2.3.1.2 Auditeerbare gebeurtenissen

Hiermee worden de geïdentificeerde activiteiten voor logging bedoeld:

  • Succes en falen van aanloggen,

  • Succes en falen van authenticatie,

  • Succes en falen in autorisatie,

  • Succes en falen in het uitvoeren van geprivilegieerde activiteiten,

  • Succes en falen in toegang tot bestanden, folders, toepassingen en systeemtools,

  • Succes en falen in toegang tot functionele en technische beheersfuncties,

  • Creatie, wijziging, verwijdering van accounts, bestanden, folders,

  • Creatie, wijziging, verwijdering van systeem parameters (inclusief database),

  • Creatie, wijziging, verwijdering in policies,

  • Creatie, wijziging, verwijdering in toegangsparameters zoals rechten en privileges,

  • Creatie - en toepassingsactiviteiten zoals shutdown, reboot, fouten,

  • Wijzigingen aan systemen en toepassingen.

Daarnaast moet men ook de nodige drempelwaarden (thresholds) zetten: vanaf welke grens wordt een auditeerbare gebeurtenis aanzien als een (potentieel) incident.

5.2.3.1.3 Inhoud van audit records

Audit records moeten voldoende informatie bevatten om – eventueel in aggregatie met andere informatiebronnen – weer te geven welke gebeurtenis heeft plaats gevonden, wat de oorzaak en wat de gevolgen zijn. Daarnaast moet het mogelijk zijn om elke menselijke interventie in verband met een gebeurtenis te identificeren.

Een correct geïmplementeerde log moet antwoord kunnen bieden op volgende vragen:

  • Wat gebeurde er?

  • Wanneer gebeurde het?

  • Waar gebeurde het?

  • Wie was betrokken?

  • Waar komt het vandaan?

Concreet betekent dit voor het opzetten van een succesvolle audit trail:

  • Datum en tijdsstip,

  • Userid/domein, herleidbaar tot een persoon, systeem, locatie,

  • Bron IP of toepassing,

  • Gebruikte toepassing, URL of service,

  • Gebruikte module of functie,

  • Uitgevoerde actie (creatie, wijziging, consultatie, verwijdering),

  • Dataveld gewijzigd of geconsulteerd

5.2.3.2 Audit Trail & Monitoring

5.2.3.2.1 Audit Log en Audit Trail

Een audit log is een verzameling chronologische records (een flat file, gestructureerd bestand, database of fysiek logboek) deze verzameling voert bewijs aan van een activiteit of geheel van activiteiten in een verwerking, procedure of gebeurtenis.

Een audit trail is een beveiligde en geautomatiseerde verzameling chronologische records, deze verzameling (een flat file, gestructureerd bestand, database of fysiek logboek), laat toe om een reeks gebeurtenissen te reconstrueren volgens hun tijdstip van voorkomen en gerelateerd aan de aanmaak, wijziging en verwijdering van elektronische records. Dankzij deze structuur is de audit informatie toegankelijker en makkelijker te ontginnen dankzij het gebruik van analyse tools.
Als dusdanig zijn audit logs en trails een belangrijke beveiligingsmaatregel:

  • Preventief: door opvolgen van informatie uit audit logs is het mogelijk om bvb de eerste signalen van een cyberaanval te herkennen, waarna stappen kunnen worden ondernomen om deze aanval te stoppen en/of verdere gevolgen te voorkomen;

  • Reactief: door log analyse en correlatie met andere informatiebronnen achterhalen wat er precies is gebeurd:

  • Ter ondersteuning van het proces risico beheer

  • Ter ondersteuning van het proces probleembeheer;

  • Lering trekken uit incidenten;

  • Bewijsvoering – juridische bewijsvoering;

  • Voor statistisch gebruik.

5.2.3.2.2 Audit log beheer

Audit log beheer omvat een aantal processen:

  • Identificatie van de systemen waarop audit logging moet worden geactiveerd (werkstations, servers, databases, middleware, speciale apparatuur zoals firewalls, proxy, routers, enz.),

  • Configuratie van het log beheer op de relevante configuraties,

  • Creatie van audit logs,

  • Opslaan, archivering en verwijderen van audit logs,

  • Review en analyse van audit log resultaten, rapportering.

Lifecyclebeheer van de lo informatie: de lifecycle van loginformatie omvat volgende fasen: aanmaak, formattering, beveiliging, online opslag, archivering (off-line retentie) en vernietiging

De nodige procedures moeten opgezet worden om intern onderzoek, forensische analyse, vastleggen van technische baselines en identificatie van lange-termijn trends te ondersteunen.

5.2.3.2.3 Lokale versus centrale opslag

Door de verschillende mechanismen voor logging loopt een organisatie het risico om het overzicht over alle gebeurtenissen kwijt kan raken. Om bijvoorbeeld aanvallen efficiënt te kunnen detecteren is het belangrijk de log informatie op één centraal punt op te slaan, waardoor een duidelijk zicht op alle informatie vanuit de verschillende componenten uit de infrastructuur mogelijk is. Het voordeel van
centraal loggen is:

  • Gebruiksgemak: Er hoeft maar op één plaats gekeken te worden.

  • Beschikbaarheid: De logging is beschikbaar, ook als het systeem dat logt niet beschikbaar is.

  • Veiligheid: De logging is ook beschikbaar als het bronsysteem gehackt of besmet is.

  • Veiligheid: De logging kan worden afgeschermd tegen onbevoegd inzien en modificatie, bijvoorbeeld door digitaal ondertekenen.

  • Eenvoud: Een centrale logging is eenvoudiger veilig te stellen op bijvoorbeeld een back-up.

  • Automatische analyse van logbestanden geeft sneller de samenhang van incidenten weer en maakt het mogelijk om logische verbanden tussen geïsoleerde incidenten te detecteren, zoals een systeeminbraak die zich in meerdere, verschillende stappen laat herkennen.

Toch ontkomt men niet aan het lokaal bijhouden van log informatie: dit is immers nodig om de coherentie en consistentie van de log informatie te garanderen: de log informatie moet minstens zolang lokaal worden bijgehouden tot er een bevestiging van goed ontvangst van de log informatie door het centrale opslagsysteem.
Een centraal opgezette logging architectuur ziet er schematisch als volgt uit:

 

 

 

5.2.3.2.4. Security monitoring

Security Monitoring is een samenspel van mensen, processen en techniek. Er is techniek nodig om zichtbaar te maken wat erin gebeurt op gebied van informatie veiligheid. Daarna zijn er analisten nodig om gebeurtenissen te analyseren en om daar opvolging aan te geven.

Het is verplicht om gebruikersactiviteit op alle endpoints binnen de organisatie te monitoren en op te volgen. Dit houdt in dat de interacties van gebruikers met systemen, applicaties en gegevens op endpoints systematisch worden vastgelegd en geanalyseerd. 

 Wat er precies door security monitoring wordt opgevolgd, wordt meestal bepaald door een risicoanalyse. Die risicoanalyse laat zien welke assets kritiek zijn en welke minder kritiek zijn. Aan de hand daarvan kan bepaald worden welke logging of alarmen relevante informatie kunnen opleveren rondom die assets. Als een risicoanalyse is uitgevoerd, kan er een kwalificatie toegekend worden aan de assets en bepaald worden wat wel en niet is toegelaten met die assets. De logging en alerting rond die assets en die van de maatregelen leveren relevante informatie op rondom de gebeurtenissen die plaatsvinden richting die assets. Een verzameling maatregelen en assets kunnen bijvoorbeeld zijn: een active directory, een firewall, een intrusion detection systeem, de antivirussoftware en de logging van de betrokken assets. 

Daarnaast dienen Key Risk Indicators (KRI's) opgenomen te worden in de rapportering van alle relevante processen voor de hogere classificatie (vanaf klasse 4) waar nuttig, op basis van informatie geëxtraheerd door de SIEM. Deze KRI's bieden een meetbare manier om risicogebieden te monitoren en trends in veiligheidsincidenten, afwijkingen en kwetsbaarheden te volgen. Ze kunnen helpen bij het identificeren van de effectiviteit van maatregelen en ondersteunen bij het tijdig nemen van corrigerende acties. Voorbeelden van KRI's zijn onder andere het aantal openstaande kritieke kwetsbaarheden, het aantal afwijkingen in de logging, en het percentage false positives ten opzichte van echte bedreigingen. 

5.2.3.2.5. Omgaan met fouten in auditing

Om te garanderen dat audit informatie steeds voorhanden is, is het belangrijk dat fouten tijdens de logging tijdig worden opgespoord en verholpen. Daarom moet logging zodanig opgezet worden dat geautoriseerd personeel automatisch op de hoogte wordt gebracht van problemen met het aanmaken en beheren van log informatie. De nodige aandacht moet gaan naar opslagcapaciteit voor logbestanden.
Als er niet meer gelogd kan worden, kan niet meer worden aangetoond wie toegang heeft gehad tot een systeem of tot informatie, of berichten ontvangen of verzonden zijn, of dat gegevens zijn ingevoerd en door wie. Dit brengt risico’s voor de informatieveiligheid met zich mee.

De volgende keuzes moeten gemaakt worden:

  • Het systeem of de toepassing normaal te laten functioneren en geen logging opslaan met als gevolg dat de log informatie verloren gaat.

  • Het systeem of de toepassing lokaal te laten loggen en later de logging te synchroniseren. Veel systemen/toepassingen kunnen lokaal loggen, waardoor de log informatie tijdelijk wordt veiliggesteld. Op het moment dat het centrale logmechanisme weer beschikbaar komt, worden de verzamelde records alsnog doorgestuurd. Er moet wel over gewaakt worden dat de lokale logging niet alle beschikbare opslagcapaciteit van het systeem verbruikt. Op het moment dat de lokale opslag volloopt, moet opnieuw besloten worden of men in productie blijft of niet.

  • Het systeem of de toepassing uit productie te nemen. Dit betekent dat gebruikers niet meer kunnen werken. Stoppen met verwerking betekent dat inbreuken niet ongemerkt kunnen plaatsvinden en ook dat de audit log geen hiaten gaat vertonen, maar dit gaat ten koste van de operationele werking.

5.2.3.2.6. Audit opvolging, analyse en rapportering

Log bestanden moeten regelmatig geanalyseerd worden om:

  • Afwijkingen op beleidslijnen te detecteren,

  • Ongewone activiteiten op te sporen en op te volgen,

  • De effectiviteit van veiligheidsmaatregelen te testen.

Omdat log bestanden zeer veel informatie bevatten, is het ondoenbaar en inefficiënt om audit logs manueel na te kijken; er moeten dus geautomatiseerde tools geïmplementeerd worden om auditing, monitoring, analyse en rapportering in een coherent proces te verwerken.

Audit rapporten moeten periodisch aangemaakt worden en ter beschikking gesteld aan het management. Het is hierbij belangrijk dat de rapportering in begrijpelijke taal geschreven is, het mag dus niet alleen uit technische details bestaan.

Audit rapportering moet bovendien geïntegreerd worden in het proces voor incident- en probleem beheer.

Enkel geautoriseerd personeel mag audit rapporten aanmaken en reviewen. 

5.2.3.3. Privileged Access Management (PAM)

Privileged Access Management (PAM) wordt hier vermeld omdat het essentieel is voor de bescherming van onze logdata. Door het beheer van geprivilegieerde accounts te controleren, voorkomen we dat onbevoegde gebruikers toegang krijgen tot gevoelige logbestanden. PAM zorgt ervoor dat alleen geautoriseerde personen logdata kunnen inzien of logfunctionaliteiten kunnen aanpassen, wat de integriteit en vertrouwelijkheid van de auditlogs waarborgt. Het toepassen van het 4-ogen principe bij wijzigingen in logfunctionaliteit versterkt deze beveiliging verder en helpt incidenten te voorkomen. 

Voor meer informatie zie ook https://vlaamseoverheid.atlassian.net/wiki/x/BpIHpwE

5.2.3.4. Log Policy

5.2.3.4.1. Retentie en beveiliging van audit records

Audit records moeten op een beveiligde manier opgeslagen worden en bijgehouden om analyse toe te laten. Dit houdt in:

Er moet een lifecycle model op de logdata toegepast worden rekening houdend met de operationele beschikbaarheid en de archivering van logdata.

  • Enkel geautoriseerde personen mogen toegang hebben tot de audit records en logbestanden.

  • Audit records mogen niet gewijzigd, overschreven of verwijderd worden.

  • Paramaters van het audit systeem mogen enkel gewijzigd worden door geautoriseerd personeel en met toepassing van het 4-ogen principe.

  • Audit records moeten beschikbaar zijn voor analyse en rapportering wanneer nodig, bvb in geval van een intern of extern onderzoek. Bovendien moeten ze voldoende lang worden bijgehouden, in lijn met de toepasbare wet- en regelgeving. Dit betekent ook dat voldoende opslagcapaciteit – eventueel offline – beschikbaar moet zijn en dat er rekening moet worden gehouden met potentiële impact op performantie van het systeem/de toepassing.

  • Audit records kunnen informatie bevatten van een bepaalde informatieklasse. Deze records en de logbestanden zelf moeten dan ook minstens dezelfde informatieklasse krijgen. Zo zal bvb een security log op toepassingen met persoonsgegevens minstens dezelfde klasse krijgen als de persoonsgegevens zelf.

5.2.3.4.2. Backups van logbestanden

Back-ups van logbestanden zijn noodzakelijk om te garanderen dat loginformatie beschikbaar blijft voor forensisch onderzoek en compliance-doeleinden.  

Loginformatie moet worden opgenomen in het reguliere back-up schema, waarbij de frequentie en scope van de back-ups afhankelijk zijn van de criticiteit van de applicatie. De back-ups moeten regelmatig worden gecontroleerd op succesvolle aanmaak en worden getest op herstelprocedures (recovery) om ervoor te zorgen dat logdata correct kan worden hersteld wanneer dat nodig is. Deze hersteltests moeten periodiek worden uitgevoerd, wederom afgestemd op de criticiteit van de systemen en applicaties. Dit zorgt ervoor dat de integriteit en beschikbaarheid van loginformatie gewaarborgd blijft, zelfs in het geval van een ernstig incident. 

5.2.3.4.3. Beveiliging van logbestanden

Ook logbestanden moeten beveiligd worden tegen niet-geautoriseerde toegang. De log zelf moet dezelfde informatieklasse toegewezen krijgen als de informatieklasse van de informatie die ze beschermt, indien deze informatie opgenomen is in de logs en bijgevolg moeten de bijhorende maatregelen ook op de loginformatie toegepast worden. Dit geldt dus vooral voor applicatie logs en in mindere mate voor systeemlogs, omdat deze laatste meestal geen applicatieve informatie bevatten. Volgende maatregelen moeten toegepast worden om de vertrouwelijkheid, integriteit en beschikbaarheid van loginformatie te garanderen doorheen de volledig levenscyclus van de log
informatie:

Vertrouwelijkheid:

Integriteit:

  • Read only toegang tot log informatie verzekeren;

  • Functiescheiding toepassen;

  • Log informatie centraal opslaan;

  • Time stamping en digitaal tekenen.

Beschikbaarheid:

  • Log informatie centraal opslaan;

  • Back-up nemen van logbestanden;

  • Logging opnemen in DRP (disaster recovery plannen)

5.2.3.5. SIEM en IDS/IDP

Security monitoring bestaat uit het verzamelen en analyseren van informatie teneinde verdacht gedrag of niet-geautoriseerde toegang en activiteiten te detecteren, hierop alarmen te genereren en actie te ondernemen.

Een bijzondere vorm van security monitoring is SIEM: hierbij gaat men diverse bronnen raadplegen om op basis van deze informatie en de correlatie ervan verdacht gedrag of niet-geautoriseerde toegang en activiteiten te detecteren, hierop alarmen te genereren en actie te ondernemen. 

Deze maatregelen onderscheiden zich van de logging als maatregelen door de nood aan gespecialiseerde tools en kennis om monitoring te kunnen implementeren. Als dusdanig worden ze dan ook voorzien als maatregel na risicoanalyse.

5.2.3.5.1. IDS (Intrusion Detection System) 

Een IDS-oplossing biedt de mogelijkheid om netwerk- en systeemactiviteiten te monitoren op verdachte patronen en mogelijke beveiligingsinbreuken. Het IDS analyseert verkeer vanuit verschillende bronnen, zoals netwerkapparaten, servers en firewalls, om afwijkend gedrag op te sporen. In tegenstelling tot preventieve maatregelen, richt een IDS zich op het detecteren van aanvallen zodra ze plaatsvinden, zodat verdere actie ondernomen kan worden. 

Een IDS werkt door continu gegevens te analyseren, waarbij het gebruik maakt van zowel signature-based als anomaly-based detectie. Signature-based detectie vergelijkt activiteiten met een database van bekende aanvalspatronen, terwijl anomaly-based detectie afwijkingen van normaal netwerkgedrag identificeert. Dit maakt het mogelijk om zowel bekende als nieuwe bedreigingen te signaleren. 

Een IDS kan op twee manieren worden ingezet: 

  • Network-based IDS (NIDS): richt zich op het monitoren van netwerkverkeer voor meerdere systemen. 

  • Host-based IDS (HIDS): monitort specifieke systemen of apparaten op verdachte activiteiten. 

Hoewel een IDS geen actie onderneemt om aanvallen te stoppen, speelt het een cruciale rol in incidentdetectie en forensisch onderzoek.  

Het is verplicht in de context van de Vlaamse overheid om IDS-loggegevens te integreren in de SIEM-oplossingen om trends te analyseren en incidentbeheer te ondersteunen. Voor opzet en configuratie van deze systemen: zie https://vlaamseoverheid.atlassian.net/wiki/x/340HpwE

5.2.3.5.2. IDP (Intrusion Prevention System) 

Een IPS-oplossing gaat een stap verder dan een IDS door niet alleen verdachte activiteiten te detecteren, maar ook actief te voorkomen dat deze aanvallen het netwerk of systemen bereiken. Het IPS analyseert netwerk- en systeemverkeer in real-time en kan automatisch maatregelen nemen, zoals het blokkeren van kwaadaardig verkeer of het afsluiten van verdachte sessies. 

Net als bij een IDS maakt een IPS gebruik van signature-based en anomaly-based detectie, maar voegt daarbij preventieve acties toe. Dit betekent dat, zodra een bedreiging wordt geïdentificeerd, het IPS direct reageert om verdere schade te voorkomen. Hoewel dit een feature lijkt dat per default zou moeten geactiveerd worden, dient voldoende aandacht besteed te worden aan legacy apparatuur in de infrastructuur die bij dergelijke interventies voor een volledige blokkering van de verwerking zou komen te staan. 

IPS-systemen kunnen op verschillende manieren worden ingezet: 

  • Network-based IPS (NIPS): detecteert en blokkeert dreigingen op netwerkverkeer. 

  • Host-based IPS (HIPS): beschermt individuele systemen door in te grijpen wanneer een aanval wordt gedetecteerd. 

Een IPS is essentieel in het handhaven van netwerkbeveiliging, omdat het naast detectie ook een preventieve verdediging biedt.  

Het is verplicht in de context van de Vlaamse overheid om IPS-loggegevens te integreren in SIEM-oplossingen om incidenten te onderzoeken en incidentbeheer te ondersteunen. Voor opzet en configuratie van deze systemen: zie https://vlaamseoverheid.atlassian.net/wiki/x/940HpwE

5.2.3.5.3. SIEM

Een SIEM oplossing biedt de mogelijkheid om informatie uit andere bronnen te gebruiken, bvb AD en e-mail logs, perimeter security logs, enz. Deze informatie wordt gebruikt om veiligheidsincidenten op te sporen. SIEM-systemen detecteren incidenten op basis van logdata door middel van regelgebaseerde detectie (zoals geconfigureerde detectieregels) of geavanceerde analyses zoals machine learning en anomaliedetectie.

Een SIEM-oplossing voorziet in continu loggen en real-time monitoren van beveiligingsmaatregelen en alarmen veroorzaakt door afwijkend gedrag. Daarnaast wordt ook lange termijn opslag van log informatie en historische/trend analyses. SIEM-oplossingen bieden ook vaak ondersteuning voor forensisch onderzoek door het verstrekken van loggegevens, maar specifieke forensische analyse gebeurt vaak met gespecialiseerde tools buiten het SIEM. 

SIEM is in feite samengesteld uit een aantal security oplossingen:

  • Log management: verzamelen en opslaan van log informatie van systemen en toepassingen;

  • Security event management (SEM): real-time monitoring van gebeurtenissen rond informatieveiligheid;

  • Security information management (SIM): legt zich toe op opslaan van informatie, analyse en rapportering;

  • Security event correlatie (SEC): correlatie van de verzamelde informatie.

Vanuit diverse bronsystemen wordt informatie verzameld en verwerkt door de SIEM oplossing. Vervolgens wordt de informatie verrijkt vanuit andere bronnen (bv. AD voor linken van accounts aan gebruikersinformatie zoals naam, afdeling, locatie, …), waarna de informatie wordt geaggregeerd en gecorreleerd om tenslotte vanuit het overkoepelende overzicht geanalyseerd te worden. 

Een SIEM oplossing zou er bijvoorbeeld als volgt kunnen uitzien: 

 

 

Bij het opzetten en onderhouden van een SIEM is het verplicht om de regels die gebruikt worden voor detectie op regelmatige basis te testen, te verbeteren of te fine-tunen op basis van veranderende dreigingsmodellen en organisatorische behoeften, en te valideren vooraleer deze effectief in gebruik worden genomen. 

Implementatie van een SIEM heeft de meeste toegevoegde waarde als aan twee voorwaarden is voldaan: 

  • Er moet een solide logging basis zijn

  • Er moeten goede use cases uitgewerkt worden

5.2.3.5.4. SIEM Use Cases 

Monitoring van mobiele code 

Bij monitoring van mobiele code wordt een SIEM ingezet om specifieke controle uit te voeren op het gebruik van mobiele code en de bijbehorende technologieën binnen een IT-systeem. Mobiele code, zoals scripts, applets en actieve inhoud die wordt gedownload of uitgevoerd op systemen, brengt mogelijke beveiligingsrisico's met zich mee. Een SIEM-systeem kan helpen bij het definiëren van beleidsregels rond het gebruik van deze code en het monitoren van de uitvoering ervan om ongeautoriseerde of gevaarlijke acties te detecteren en te blokkeren. 

Ten eerste zal het SIEM geconfigureerd worden om logs te verzamelen van alle activiteiten die gerelateerd zijn aan mobiele code. Dit omvat de initiële download, uitvoering, en eventuele interacties met systemen. Door regels te definiëren binnen het SIEM, kan worden bepaald welke mobiele code en scripts als veilig worden beschouwd, en wie de juiste autorisaties heeft om deze uit te voeren. In geval van afwijkingen, zoals het gebruik van niet-geautoriseerde code of onverwachte gedragingen, genereert het SIEM waarschuwingen die toelaten onmiddellijk actie te ondernemen. 

Daarnaast biedt het SIEM mogelijkheden om mobiele code continu te monitoren op verdachte patronen of afwijkingen die wijzen op malware of pogingen tot aanvallen. Door real-time analyse en correlatie met bekende dreigingsmodellen, zoals het MITRE ATT&CK-framework, kan het systeem vroegtijdig aanvallen detecteren en mitigeren. Hierdoor kan niet alleen de uitvoering van mobiele code worden gecontroleerd, maar kunnen ook de onderliggende technologieën binnen het systeem worden beschermd tegen mogelijke bedreigingen. 

Monitoring van Access points en endpoints (devices) 

Hier wordt een SIEM ingezet om specifieke maatregelen te implementeren voor het monitoren van toegangspunten (access points) en aangesloten apparaten binnen een netwerk. Access points vormen een cruciaal onderdeel van de netwerkarchitectuur en kunnen, indien onbeheerd of onveilig, een kwetsbaar toegangspunt vormen voor cyberdreigingen. Het SIEM-systeem biedt een geïntegreerde oplossing om alle activiteiten rond deze toegangspunten te controleren, autorisaties te valideren en verdachte activiteiten te detecteren. 

Het SIEM verzamelt continu logs van alle toegangspunten in het netwerk, inclusief connecties en apparaten die verbinding proberen te maken. Deze logs worden gebruikt om ongeautoriseerde toegangspogingen of afwijkende verbindingspatronen op te sporen. Door gebruik te maken van op regels gebaseerde monitoring, kan het SIEM afwijkende activiteiten identificeren, zoals onverwachte connecties buiten kantooruren, pogingen om toegang te krijgen tot niet-geautoriseerde netwerken, of het aansluiten van onbekende apparaten. 

Daarnaast biedt het SIEM de mogelijkheid om verdachte toegangspunten of apparaten direct te isoleren (via bv. Network Access Control als onderdeel van de Zero Trust Network Architecture) en/of waarschuwingen te versturen naar het IT-team. Via real-time analyse kan het systeem bedreigingen vroegtijdig opsporen en in verband brengen met bekende aanvalspatronen, wat de effectiviteit van de beveiliging vergroot. Dit zorgt ervoor dat de toegangspunten en aangesloten apparaten continu worden beschermd en dat ongeautoriseerde toegang tot het netwerk tijdig wordt gedetecteerd en tegengegaan. 

Monitoring van externe verbindingen met leveranciers 

In deze use case wordt een SIEM ingezet om de externe verbindingen van leveranciers naar interne systemen te monitoren. Leveranciers die toegang hebben tot bepaalde gedeelten van de IT-infrastructuur kunnen, indien niet goed beheerd, een kwetsbaarheid vormen. Het SIEM-systeem biedt een oplossing door alle verbindingen van leveranciers in real-time te monitoren, afwijkende patronen te detecteren en verdachte activiteiten te blokkeren. 

Het SIEM verzamelt logs van alle verbindingen die door leveranciers worden opgezet, inclusief de gebruikte protocollen, IP-adressen en toegangstijden. Door op regels gebaseerde monitoring kunnen afwijkingen, zoals buiten kantooruren toegangspogingen of pogingen om toegang te krijgen tot niet-geautoriseerde systemen, onmiddellijk worden gedetecteerd. 

In het geval van een verdachte activiteit, zoals een onbekende leverancier die verbinding maakt met een kritiek systeem, genereert het SIEM automatisch waarschuwingen en kan het toegangen proactief blokkeren. 

Het SIEM-systeem biedt daarnaast de mogelijkheid om trends te analyseren, bijvoorbeeld door leveranciersverbindingen over langere perioden te monitoren en te rapporteren. Dit helpt om potentiële zwakke punten te identificeren en om preventieve maatregelen te nemen, zoals het beperken van toegang of het verplichten van extra authenticatiemethoden voor leveranciers. 

Monitoring van wijzigingen 

Bij deze use case wordt een SIEM ingezet om configuratiewijzigingen binnen kritieke systemen te monitoren, zoals vereist door NIS2 voor systemen die kritieke data verwerken. Ongeautoriseerde wijzigingen aan de configuratie van systemen kunnen leiden tot beveiligingsrisico’s, waaronder het verlagen van de beveiligingsinstellingen of het onbedoeld openen van kwetsbaarheden die door kwaadwillenden kunnen worden misbruikt. 

Het SIEM-systeem wordt geconfigureerd om logs te verzamelen van alle configuratiewijzigingen die binnen de systemen worden doorgevoerd. Dit omvat wijzigingen aan zowel hardware- als software-instellingen. Het SIEM wordt daarnaast gekoppeld aan het configuratiemanagementsysteem om te kunnen verifiëren of een wijziging geautoriseerd is. Door deze integratie kan het SIEM onderscheid maken tussen goedgekeurde en ongeautoriseerde wijzigingen. 

Wanneer een ongeautoriseerde wijziging wordt gedetecteerd, dient deze automatisch te worden gelinkt aan het incident management-proces. Dit houdt in dat er een incidentticket wordt aangemaakt, waarin de details van de configuratiewijziging en bijbehorende acties worden vastgelegd. Het incident management-proces zorgt ervoor dat de wijziging grondig wordt onderzocht, dat corrigerende maatregelen worden geïmplementeerd, zoals het terugdraaien van de wijziging, en dat de betrokken systemen worden gemonitord voor verdere incidenten. 

Opvolging van systeemaccount 

Bij deze use case wordt een SIEM ingezet om atypische acties van systeemaccounts te monitoren. Systeemaccounts, die worden gebruikt voor geautomatiseerde processen en machine-to-machine interacties, hebben vaak uitgebreide toegangsrechten en worden daarom beschouwd als een risicofactor binnen een IT-omgeving. Het SIEM-systeem helpt bij het identificeren van afwijkend gedrag van deze accounts om mogelijke beveiligingsincidenten tijdig te detecteren. 

Het SIEM wordt geconfigureerd om continu logs te verzamelen van alle acties die door systeemaccounts worden uitgevoerd. Dit omvat onder andere loginpogingen, aanroepen van API's, en interacties met andere systemen. Door baseline-profielen te creëren voor het normale gedrag van systeemaccounts, kan het SIEM afwijkingen in real-time detecteren. Denk hierbij aan acties zoals onverwachte wijzigingen in configuraties, onregelmatig gebruik van bepaalde rechten, of ongebruikelijke tijden van activiteit. 

Bij het vaststellen van atypische acties genereert het SIEM automatisch waarschuwingen, die geanalyseerd kunnen worden om te bepalen of er sprake is van een mogelijk beveiligingsincident. Het systeem kan bijvoorbeeld detecteren wanneer een systeemaccount toegang probeert te krijgen tot gevoelige data of systemen buiten de normale gebruikspatronen. Deze waarschuwingen worden vervolgens gekoppeld aan het incident management-proces, waarbij automatisch incidenttickets met hoge prioriteit worden aangemaakt om het verdachte gedrag verder te onderzoeken en indien nodig corrigerende maatregelen te nemen. 

5.2.3.5.5. Capaciteitsplanning 

Capaciteitsplanning is essentieel voor een SIEM-systeem omdat het zorgt voor een correcte verwerking en opslag van logdata, zodat het systeem goed kan functioneren.  

Een goed uitgevoerde capaciteitsplanning houdt rekening met de hoeveelheid gebeurtenissen (events) en de opslagvereisten, afgestemd op de verwachte groei van het aantal systemen en netwerken. Verwerkingskracht is cruciaal om logs in real-time te analyseren en correlaties uit te voeren, terwijl voldoende netwerkbandbreedte nodig is om logdata zonder vertraging over te dragen naar het SIEM-platform. Schaalbaarheid is belangrijk, omdat een SIEM flexibel moet kunnen meegroeien met toenemende logdata zonder aan functionaliteit in te boeten. Daarnaast moet de infrastructuur bestand zijn tegen storingen, met back-up- en disaster recovery-oplossingen om data-integriteit en -beschikbaarheid te waarborgen. 

5.2.3.5.6. Continue verbetering 

Operationele issues die via monitoring naar boven komen, moeten niet alleen worden opgelost, maar dienen ook structureel aangepakt te worden. Dit betekent dat de lessons learned uit incidenten en afwijkingen worden geïntegreerd in de bestaande oplossingen. Door processen, configuraties en correlatieregels voortdurend te evalueren en aan te passen, wordt de algemene beveiliging versterkt en worden toekomstige risico's reeds vooraf aangepakt. 

Binnen het proces van continue verbetering voor SIEM is het tevens belangrijk dat de organisatie regelmatig incidenten, logs en auditresultaten evalueert om beveiligingsmaatregelen verder te optimaliseren. Voor hogere dataklassen is het bovendien noodzakelijk om de detectieregels regelmatig te controleren, niet alleen op hun efficiëntie en effectiviteit, maar ook met het oog op false positives bij het opsporen en uitroeien van kwaadardige code. Dit garandeert dat de detectieprocessen effectief functioneren en dat ze correct inspelen op nieuwe dreigingen en risico's. 

Zie ook https://vlaamseoverheid.atlassian.net/wiki/x/1ZQHpwE

5.2.3.5.7. Logging in het kader van verwerking van persoonsgegevens

Logging en GDPR

Logging is een belangrijke maatregel ter ondersteuning van GDPR-conformiteit. Wanneer d.m.v. een systeem (toepassing, (gebruikers)apparatuur, server, database, …) toegang kan worden genomen tot persoonsgegevens, dan moet deze toegang gelogd worden. In GDPR vindt men dit terug als:

  • Logging als veiligheidsmaatregel: artikel 24 – de verwerkingsverantwoordelijke moet de nodige technische maatregelen nemen om aan te kunnen tonen dat de verwerking in overeenstemming is met de Verordening.

  • Logging als middel voor transparantie: artikel 13 en 14 – de betrokkene moet geïnformeerd worden over de categorieën van ontvangers van zijn gegevens en heeft het recht om te laten nagaan of de toegang door deze personen gerechtigd was of niet.

  • Logging als essentieel element in toegangsbeheer: artikel 24 – logs worden ook gebruikt als intern controlemiddel.

Privacy logging

Privacy logs vereisen extra maatregelen tegenover ‘gewone’ security logging. Deze vereisten worden in dit hoofdstuk samengevat.
De GDPR stelt dat elke verwerking van persoonsgegevens gerechtvaardigd moet zijn. De privacy log dient dan ook een gepast antwoord op volgende vragen te geven:

  • Wie heeft wanneer welke persoonsgegevens verwerkt² ? Dit vertaalt zich naar een tot natuurlijke persoon herleidbare gebruikersnaam of ID, tijdsstip (datum/uur), identificatie van het werkstation of locatie, gebruikte toepassing.

  • Wie is de betrokkene wiens persoonsgegevens werden verwerkt? Dit vertaalt zich naar de persoon die het object is van de handeling.

  • Wat was het resultaat van deze verwerking? Dit vertaalt zich naar het resultaat van de handeling (consultatie, wijziging, verwijdering, query).

De privacy logs moeten bewaard worden overeenkomstig de toepasselijke wet- en regelgeving. Voor de KSZ is bvb een bewaartermijn van 10 jaar voorzien.

Aangezien de privacy logs evenzeer persoonsgegevens bevatten, moeten zij dezelfde informatieklasse toegewezen krijgen als de informatieklasse die aan de persoonsgegevens werd gegeven (informatieklasse 3 voor logbestanden op de verwerking van algemene persoonsgegevens, informatieklasse 4 voor logbestanden op de verwerking van gevoelige persoonsgegevens).

De integriteit van de logs moet bewaard worden zodat manipulaties vermeden worden en de consistentie in de loginformatie bewaakt wordt.

Logging inbreuken

De GDPR stelt in artikel 33: ‘De verwerkingsverantwoordelijke documenteert alle inbreuken in verband met persoonsgegevens, met inbegrip van de feiten omtrent de inbreuk in verband met persoonsgegevens, de gevolgen daarvan en de genomen corrigerende maatregelen.’ Het bijhouden van een logboek met inbreuken in verband met de verwerking van persoonsgegevens is dan ook aangewezen. Dit logboek moet een antwoord bieden op volgende vragen:

  • Wat is er gebeurd?

  • Op welke datum en tijdsstip is de inbreuk vastgesteld?

  • Welke persoonsgegevens zijn hierbij betrokken?

  • Wie zijn de personen wiens gegevens betrokken zijn bij de inbreuk?

  • Welke zijn de gevolgen voor de betrokkenen?

  • Welke maatregelen worden genomen om de gevolgen van de inbreuk te verminderen?

  • Welke maatregelen worden genomen om de inbreuk in de toekomst te voorkomen?