| Note |
|---|
Om review makkelijker te maken werden de wijzigingen tegenover ICRv2 als volgt in de tekst duidelijk gemaakt:
|
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.
Let wel: hierbij dient expliciet opgemerkt te worden dat rekening moet gehouden worden bij het implementeren van de technische oplossing met de bescherming van persoonsgegevens en alle andere wettelijke regelgeving.
De detectiesystemen (SIEM) worden uitgerust met kennis over standaard situaties en te verwachten events. Alle ongekende events en situaties zullen aanleiding geven tot meldingen door deze detectiesystemen.
Ingeval van een melding door de detectiesystemen dient dit als een incident gelogd en verder onderzocht te worden.
Ingeval een incident dient onderzocht te worden, moet er een proces gevolgd worden om op die manier enerzijds het incident en de implicaties ervan volledig te begrijpen en anderzijds de nodige maatregelen en acties te kunnen definiëren om het incident te kunnen oplossen (oa door correlatie met andere informatiebronnen, door gebruik te maken van mapping van de gevonden gebeurtenissen op gekende aanvalsmethodes waar mogelijk). Hiervoor dient het proces van incidentbeheer gevolgd te worden (zie ook https://vlaamseoverheid.atlassian.net/wiki/x/NgQIpwE )
Bij het onderzoeken van incidenten is het verplicht om vastgestelde patronen te vergelijken met bekende aanvalspatronen. Dit kan helpen om te bepalen of de activiteit verband houdt met een specifieke aanvalsmethode of dreigingsactor. Door patronen te mappen op bekende dreigingsmodellen, zoals het MITRE ATT&CK-framework, kunnen we in een vroeg stadium begrijpen welke technieken worden gebruikt, welke fases van de aanval reeds zijn doorlopen, en welke verdedigingsmechanismen mogelijk zijn om verdere escalatie te voorkomen.
Er kunnen ook trends geanalyseerd en gerapporteerd worden om preventieve acties te identificeren en in te plannen.
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 intrusiondetection 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:
Fysieke of logische toegangscontrole;
Versleuteling van de log informatie.
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.
...
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 tijdsstip 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.
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,
Lifecyclebeheer van de lo informatie: de lifecycle van loginformatie omvat volgende fasen: aanmaak, formattering, beveiliging, online opslag, archivering (off-line retentie) en vernietiging
...
Opslaan, archivering en verwijderen van audit logs,
Review en analyse van audit log resultaten, rapportering.
De nodige procedures moeten opgezet worden om intern onderzoek, forensische analyse, vastleggen van technische baselines en identificatie van lange-termijn trends te ondersteunen.
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:
...
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:
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.
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
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.
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:
Fysieke of logische toegangscontrole;
Versleuteling van de log informatie.
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)
Ook over loggen moet worden gelogd: het openen van een nieuw logbestand, het verplaatsen,
wijzigen naam of verwijderen van een logbestand, het inkijken, verwijderen of wijzigen van de inhoud van een logbestand dient te worden gelogd om niet-geautoriseerde toegang te kunnen opsporen. Speciale aandacht moet besteed worden aan manuele logboeken omdat het risico op schending van vertrouwelijkheid, integriteit en beschikbaarheid groter zijn dan bij geautomatiseerde logging:
Door de manuele procedure en opvolging is het risico op fouten, inconsistenties, ontbreken van informatie groter;
Fysieke toegang tot het logboek moet beveiligd worden;
Beschikbaarheid van het logboek moet gegarandeerd worden, bvb door het nemen van kopieën.
Mitigerende maatregelen om manuele logboeken te beveiligen bestaan o.a. uit:
Fysieke toegangsbeveiliging d.m.v. afsluitbare/brandveilige kast;
Kopieën bijhouden van het logboek;
Inscannen en opslaan als pdf-bestand;
Controle en 4-ogen principe.
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.
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.2. Monitoring als maatregelen
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.2.1. 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.
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.
Security monitoring bestaat er dan verder in om de relevante informatie te verzamelen, te analyseren en op te volgen. Zo kunnen kwetsbaarheden, verdachte activiteiten en potentiële en effectieve veiligheidsincidenten in het oog worden gehouden en waar nodig wordt dan actie genomen. Er kunnen ook trends geanalyseerd en gerapporteerd worden om preventieve acties te identificeren en in te plannen.
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. Het extraheren van incidenten uit logs is wat SIEM-systemen op een geautomatiseerde manier beloven te doen.
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 en koppeling met incident beheer en forensisch onderzoek.
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:
Audit records worden verzameld uit de diverse bronsystemen,
Audit records worden in een bepaald formaat gebracht voor verdere verwerking,
De informatie wordt verrijkt vanuit andere bronnen (bv. AD voor linken van accounts aan gebruikersinformatie zoals naam, afdeling, locatie, …),
Informatie wordt geaggregeerd en gecorreleerd,
Analyse en rapportering.
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,
Een SIEM oplossing zou er bijvoorbeeld als volgt kunnen uitzien:
...
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:
...