5.2.3. Aanvullende informatie over de maatregelen (logging en monitoring)
- Yentl Goossens (Unlicensed)
5.2.3.1. Logging als maatregelen
5.2.3.1.1. Kenmerken van de logging maatregelen
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.2.3.2.2. 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?