Patroon voor logging

Onderdeel van: Thema's
Contact: Guus van den Berg; Guus.vandenberg@cip-overheid.nl
Status: Dit thema wordt momenteel opnieuw bekeken door de Expertgroep Beveiliging

Criteria

Controleerbaarheid

Context

Veel gebeurtenissen die voor het beheer van IT-voorzieningen van belang zijn, hebben tevens betekenis voor informatiebeveiliging en worden daarom vastgelegd ofwel gelogd. Loggegevens kunnen zowel betrekking hebben op handelingen van natuurlijke personen als op het gedrag van informatiesystemen. Daarnaast zijn er andere doelen zoals technisch beheer, productiebesturing, capacitymanagement, configurationcontrol, SLA compliancemonitoring etc. Dit patroon beperkt zich tot vastleggen van gegevens voor informatiebeveiliging en richt zich op technische logging. Functionele logging door applicaties zoals transactionele logging en audittrails vallen hier buiten. Loggegevens over personen kunnen dienen als wettig bewijsmateriaal, waarmee onwettige handelingen aangetoond kunnen worden. Loggegevens kunnen ook betrekking hebben op ongewenste handelingen, die niet in overeenstemming zijn met het organisatiebeleid. Deze gegevens worden daarom zeer vertrouwelijk behandeld.

Vastleggen van gebeurtenissen

Probleem

De problematiek van het vastleggen van gebeurtenissen benaderen we vanuit twee gezichtpunten: 1) Waarom loggen? En 2) Wat komen we tegen als we logfuncties willen inrichten of verbeteren?

De problemen die via het vastleggen van gebeurtenissen geheel of gedeeltelijk opgelost kunnen worden zijn:
1. Misbruik door gebruikers van informatiesystemen.
2. Aanvallen op de beschikbaarheid, integriteit en vertrouwelijkheid van informatie (systemen).
3. Onderbrekingen van dienstverlening als gevolg van gebruikersfouten of configuratiefouten.
4. Falende componenten en kritisch- relevante meldingen worden niet (tijdig) opgemerkt.
De problemen die zich voordoen bij het vastleggen van gebeurtenissen zijn de volgende:
1. Onduidelijk logbeleid. Beleidsregels zijn niet duidelijk t.a.v. welke gebeurtenissen moeten worden gelogd en welke niet, wat leidt tot een “alles of niets” gebruik van logfuncties.
2. Hoeveelheid meldingen is zo groot dat dit leidt tot vollopen van opslagmedia.
3. Beheerders kunnen logfiles wissen. Configuratiefouten of misbruik door beheerders kunnen worden gemaskeerd omdat beheerders logfiles in systemen kunnen wissen.
4. Incidenten oplossen in plaats van het voorkomen van incidenten.

Oplossing

Logbeleid wordt vastgesteld, waaruit kan worden afgeleid welk type gebeurtenissen moeten worden vastgelegd. Zie hiervoor richtlijnen voor logging in het toegepaste normenkader IT-voorzieningen. Een ‘standaard’ technische voorziening voor logging van infrastructuur componenten is: Syslog. Syslog is een client/server protocol dat is beschreven in RFC 3164: “The BSD syslog Protocol”. Het wordt ondersteund door een groot aantal componenten en werkt over meerdere hardware platformen. Werking: De Syslog zender stuurt kleine tekstberichten (< 1kB) van gebeurtenissen naar de Syslog ontvanger, die ‘Syslogd’, ‘Syslog deamon’ of ‘Syslog server’ wordt genoemd. Voor transport wordt het UDP netwerkprotocol, of SSL/TLS protocol gebruikt. Hieronder is de logarchitectuur geschetst.

Architectuur van logging

De verzamelde logmeldingen worden vervolgens gefilterd en gecomprimeerd, waarmee de hoeveelheid te bewaren informatie aanzienlijk wordt beperkt. Filtering wordt ingesteld op basis van het vigerende log-beleid van een organisatie. Meldingen worden vanuit kritische bedrijfsfuncties ‘real-time’ gevolgd via de Log Monitoring functie, en wel op basis van z.g. ‘content-based filtering’. De alarmering wordt geregeld met behulp van SMS-oproepen. NB: deze alarmering is niet per definitie dezelfde als de monitoringfunctie van Security Information Event Management (SIEM), maar kan wel door een SIEM omgeving worden uitgevoerd. De log-informatie wordt vervolgens voorzien van een Hash, een Tijdstempel, een Severity- (ernst) aanduiding en een Sequencenummer, waarna het vervolgens ‘write once’ versleuteld wordt opgeslagen in een database. Eventuele modificatie, toevoeging of verwijdering van de geregistreerde informatie wordt hiermee detecteerbaar. Vervolgens kan log-data voor analyse en auditing beschikbaar worden gesteld aan platform specifieke tools of aan generieke log-analyse systemen zoals SIEM. Binnen een te loggen object kunnen diverse types logfiles ontstaan. Dit kunnen zowel “flatfiles” zijn, maar ook loginformatie, opgenomen in een database. Al deze types moeten door het verzameltool ingelezen kunnen worden. Het verwijderen van loggegevens moet met de nodige waarborgen omkleed zijn, zoals het ‘vier-ogen’ principe en het opmaken van een protocol.

De lifecycle van log-informatie doorloopt de onderstaande fasering:

Levenscyclus van loginformatie

Gevoeligheid van loginformatie

In elke zone (DMZ, Frontoffice, Backoffice etc.) vinden gebeurtenissen plaats, die voor registratie in aanmerking komen. De beveiligingsgerelateerde gegevens van die gebeurtenissen worden vastgelegd met toevoeging van datum/tijd, identificatie van locatie, machine, proces, applicatieversie en in geval van gebruikershandelingen de identificatie van de betrokken gebruiker en zijn privileges. Om ongewenste vermenging tijdens collectie van loggegevens van verschillende gevoeligheidsniveaus tegen te gaan, wordt elk record voorzien van een gevoeligheidsaanduiding, in overeenstemming met de gevoeligheid van de loggingbron. Bij het extraheren van loggegevens wordt daarmee voorkomen dat hooggevoelige gegevens op ongewenste momenten in het extract terechtkomen. Het gevoeligheids- of beveiligingsniveau van een loggingbron wordt bepaald aan de hand van het beveiligingsbeleid. Als loggegevens met verschillende gevoeligheidsaanduiding worden samengevoegd, krijgt de logfile het gevoeligheidsniveau, dat gelijk is aan dat van de meest gevoelige loggegevens. Per logrecord wordt een severity-aanduiding vastgelegd. Tijdens de analyse kan hierop geselecteerd worden om b.v. in eerste instantie alleen de ernstigste meldingen te laten zien.

Doorgaande cyclische logging, waarbij op een bepaald moment de nieuwste records de oudste logs overschrijven, is niet toegestaan. Als een logfile een bepaalde instelbare maximumafmeting heeft bereikt, dan wordt deze na het toevoegen van een hash afgesloten en wordt een nieuwe logfile gestart. De hash wordt over de hele logfile berekend en is nodig om eventuele modificaties achteraf te kunnen aantonen.

Bij de opslag wordt de logfile write-once encrypted opgeslagen. Daarmee is de logfile beveiligd tegen modificatie en tegen onbevoegde raadpleging. Uitwisseling van informatie tussen systemen van twee organisaties wordt tweezijdig gelogd, voor wat betreft al dan niet succesvolle communicatie en het tijdstip waarop dit heeft plaatsgevonden.

Het loggingproces zelf wordt ook gelogd (beheer en beveiliging van beveiliging). Voor het beheer van het loggingproces geldt dezelfde eis als voor de logfiles: de beheerder (of securitymanager) heeft niet de mogelijkheid om zonder hulp van een tweede geautoriseerde persoon het loggingproces aan te passen of logfiles te verwijderen (4-ogen principe). Deze log wordt toegevoegd aan de collectie zelf en aan de nieuwe collectie.

Afwegingen

Om logging beheersbaar te houden en te voldoen aan de ‘geest’ van de wet, wordt bewust gekozen welke gebeurtenissen wel of niet worden gelogd, op welke wijze logfiles worden opgeslagen (al dan niet versleuteld) en hoe lang de minimum en maximum bewaartermijn kan of moet zijn. (De archiefwet geeft geen bewaartermijnen aan).

Voorbeelden

Toepassingsmogelijkheden: Forensisch onderzoek, tactisch en operationeel beheer (SIEM), audit, SLA compliance monitoring.

Implicaties

Als versleuteling wordt toegepast dient het sleutelbeheer adequaat geregeld te zijn (zie Patroon voor sleutelhuis).
Opslagtechnieken kunnen veranderen, waardoor loginformatie op een nieuw medium moet worden opgeslagen, hetgeen om integriteitswaarborgen vraagt.
Voor beheer van loggegevens zijn alle fasen van lifecycle management vereist, dat wil zeggen, vanaf registratie tot en met vernietiging (zie levenscyclus Log-informatie in dit patroon).
Er moet rekening worden gehouden met de verplichting om logfiles na een bepaalde bewaarperiode te vernietigen. De bewaartermijn kan voor de diverse soorten logfiles, afhankelijk van de daarin vastgelegde gegevens, sterk verschillen.
Het gaat om veel data: (gebeurtenissen/sec) x ( sec/jaar) x (gemiddelde recordgrootte) = xyzTByte.

Gerelateerde patronen

Patroon voor elektronische handtekening voor zekerheid over de integriteit van logbestanden.
Patroon voor symmetrische encryptie voor vertrouwelijke opslag
Patroon voor security information event management (SIEM) voor verzamelen en correleren van loginformatie.