ISO 27001:2022 behandelt logging en monitoring hoofdzakelijk via drie Annex A-maatregelen: 8.15 (logging), 8.16 (monitoringactiviteiten) en 8.17 (kloksynchronisatie). Samen vragen ze u om beveiligingsrelevante gebeurtenissen vast te leggen, die records te beschermen, uw systemen te bewaken op afwijkend gedrag en tijdstempels betrouwbaar te houden. Auditors willen geen toolnaam. Ze willen bewijs dat u hebt bepaald wat u logt, dat iemand ernaar kijkt en dat u handelt op wat diegene ziet.
Deze gids legt elke maatregel in begrijpelijke termen uit, toont het bewijsmateriaal dat een auditor doorgaans opvraagt en geeft een uitrolvolgorde die werkt voor een klein beveiligingsteam.
Samenvatting
- Maatregel 8.15 gaat over het produceren, beschermen en reviewen van logs. Maatregel 8.16 gaat over het actief bewaken op anomalieën. Slagen voor de ene betekent niet dat u slaagt voor de andere.
- Bepaal eerst de scope: welke systemen, welke gebeurtenissen, wie reviewt, hoe vaak en hoe lang u records bewaart. Leg het schriftelijk vast en laat vervolgens zien dat het werkt.
- Centraliseer logs en houd klokken gesynchroniseerd (8.17), anders kunt u een incident niet reconstrueren over meerdere systemen heen.
- Scheid taken waar mogelijk: de mensen die een systeem beheren mogen niet de enigen zijn die de logs ervan reviewen.
- Plan de inspanning vroeg in. Loggingtooling en reviewtijd zijn reële kostenposten in een ISO 27001-project.
Inhoudsopgave
- Hoe de drie maatregelen samenhangen
- Maatregel 8.15: logging die een audit doorstaat
- Maatregel 8.16: monitoring die iets oppikt
- Maatregel 8.17: de stille die onderzoeken doet mislukken
- Bewijsmateriaal dat een auditor wil zien
- Een uitrolvolgorde die werkt
- Branchenotities: financiën en betalingsgegevens
- Veelgemaakte fouten
- Ons perspectief
- Schat de inspanning in voordat u zich committeert
- FAQ
- Bronnen
Hoe de drie maatregelen samenhangen
Denk aan een pijplijn. Maatregel 8.15 creëert en beschermt het ruwe materiaal. Maatregel 8.17 maakt de tijdstempels op dat materiaal vergelijkbaar. Maatregel 8.16 zet het om in detectie.
| Maatregel | Wat er gevraagd wordt | Typisch bewijsmateriaal |
|---|---|---|
| 8.15 Logging | Logs van activiteiten, uitzonderingen, fouten en andere relevante gebeurtenissen produceren, opslaan, beschermen en analyseren | Loggingstandaard, voorbeeldlogs, retentie-instellingen, toegangsbeperkingen op logopslagplaatsen |
| 8.16 Monitoringactiviteiten | Netwerken, systemen en applicaties bewaken op afwijkend gedrag en adequaat reageren | Alertregels, reviewrecords, tickets geopend vanuit meldingen, escalatiepad |
| 8.17 Kloksynchronisatie | Klokken van informatieverwerkende systemen gesynchroniseerd houden met goedgekeurde tijdbronnen | NTP-configuratie, een screenshot of export die consistente tijd over systemen heen toont |
Een veelvoorkomende auditbevinding is een organisatie die alles logt maar niets reviewt. Logs die in een bucket staan zijn op zijn best bewijs voor 8.15. Een handige geheugensteun: logging beantwoordt "wat is er gebeurd," monitoring beantwoordt "gaat er nu iets mis."
Maatregel 8.15: logging die een audit doorstaat
Begin vanuit risico, niet vanuit de tool. Uw risicoanalyse zou u moeten vertellen welke systemen ertoe doen, en uw loggingstandaard moet daaruit voortvloeien.
Wat te loggen
Een verdedigbare basislijn omvat:
- Authenticatiegebeurtenissen: geslaagde en mislukte aanmeldingen, MFA-wijzigingen, wachtwoordresets.
- Bevoorrechte activiteit: beheeracties, rolwijzigingen, gebruik van break-glass-accounts.
- Toegang tot gevoelige gegevens en wijzigingen in toegangsrechten.
- Systeemwijzigingen: configuratiewijzigingen, nieuwe services, deployments.
- Uitvoer van beveiligingstools: endpointbeveiliging, firewall, inbraakdetectie, resultaten van kwetsbaarheidsscans.
- Fouten en uitzonderingen: mislukte back-ups, servicecrashes, onverwachte uitschakelingen.
U hoeft niet elk systeem even diepgaand te loggen. Een klantendatabase en een printer horen niet dezelfde logginglast te dragen, en een auditor zal verwachten die redenering terug te zien in uw risicobehandeling.
Bescherm de logs zelf
Logs zijn alleen bewijsmateriaal als niemand ze stilletjes kan bewerken. Praktische stappen:
- Verstuur logs naar een centrale opslagplaats los van het systeem dat ze heeft gegenereerd.
- Beperk schrijf- en verwijderrechten tot een kleine groep en log toegang tot de logopslagplaats.
- Gebruik onveranderlijke of write-once-opslag voor hoogwaardige logs waar uw platform dat ondersteunt.
- Stel een retentieperiode in die aansluit bij wettelijke, contractuele en onderzoeksbehoeften, en documenteer waarom u die hebt gekozen.
- Behandel logs met persoonsgegevens als persoonsgegevens: beperk wie ze kan inzien en vermijd het vastleggen van meer dan nodig is.
Retentie: kies, onderbouw, pas toe
ISO 27001 geeft u geen vast aantal dagen. U kiest, op basis van uw verplichtingen. In Nederland en België kan dat sectorale regelgeving of klantcontracten omvatten, dus controleer wat uw eigen overeenkomsten zeggen voordat u een periode vaststelt. Pas die vervolgens consistent toe. Een auditor vergelijkt uw schriftelijk beleid met de werkelijke instellingen op uw logplatform, en een discrepantie is een eenvoudig te vermijden non-conformiteit.
Maatregel 8.16: monitoring die iets oppikt
Monitoring is waar veel eerstejaars implementeerders tekortschieten. De maatregel verwacht dat u bewaakt op afwijkend gedrag en potentiële incidenten evalueert. Dat vereist gedefinieerde use cases, een eigenaar en een responspad.
Begin met een korte lijst van alerts
Tien goed afgestelde alerts verslaan tweehonderd genegeerde. Goede eerste kandidaten:
- Herhaaldelijk mislukte aanmeldingen gevolgd door een geslaagde.
- Een nieuw account toegevoegd aan een beheerdersgroep.
- Aanmelding vanuit een ongewoon land of onmogelijk reizen tussen locaties.
- Uitschakelen van endpointbeveiliging of loggingagenten.
- Grote uitgaande overdrachten vanuit een gevoelig systeem.
- Toegang tot productiegegevens buiten normale werktijden door iemand die dat normaal niet doet.
Schrijf voor elke alert op wie hem ontvangt, hoe snel diegene moet reageren en wat als een incident telt. Dat laatste punt verbindt monitoring met uw incidentproces. Onze gids over de vijf incidentmaatregelen die auditors toetsen laat zien hoe een alert uitmondt in een geregistreerde gebeurtenis en een beoordeeld incident.
Maak alerts bruikbaar voor respons
De lessen geleerd uit een incident response-opdracht van CISA stellen logging voor als een test van of responders er gebruik van kunnen maken. Het genereren van een alert is niet genoeg: het team moet vanuit de alert kunnen doorgaan naar gecorreleerde identiteits-, endpoint- en cloudrecords om gebeurtenissen te reconstrueren, en dat is waar een gecentraliseerd SIEM helpt. U kunt die test toepassen op uw eigen programma. Kies een recente alert en vraag of iemand binnen een uur het betrokken account kan traceren via uw identiteitsprovider, de getroffen laptop en uw cloudconsole.
Voor teams die een diepgaander architectuuroverzicht willen, beschrijft de Logging Reference Architecture van CISA logging die tijdige detectie, threat hunting, incident response en forensisch onderzoek ondersteunt — niet alleen verzameling en retentie. Het is geschreven voor federale instanties, maar de principes zijn overdraagbaar op private organisaties.
Als u eigen applicaties draait, is monitoring op applicatieniveau ook van belang. Dit overzicht van best practices voor applicatiemonitoring is een nuttige aanvulling voor engineers die fout- en prestatiemonitoring willen verbinden met beveiligingsalerts.
Onafhankelijkheid van review
Functiescheiding is ook van toepassing op monitoring. Het FFIEC IT Examination Handbook, geschreven voor financiële instellingen, stelt dat medewerkers die systemen of beveiliging beheren niet dezelfde mensen mogen zijn die de activiteitslogs van die systemen bewaken. ISO 27001 is geen bankregelgeving, maar de redenering geldt voor elke organisatie: als de beheerder zowel kan handelen als reviewen, kan misbruik onopgemerkt blijven.
Kleine teams kunnen deze rollen vaak niet volledig scheiden. Documenteer in dat geval de compenserende maatregel. Zo kan een tweede persoon, een manager of een uitbestede provider periodiek een samenvatting van bevoorrechte activiteit ontvangen. De FFIEC-richtlijnen over managed security service providers beschrijven beheer van gebeurtenislogboeken en alerting als een dienst die kan worden uitbesteed, wat een optie is voor slanke teams. Als u uitbesteedt, onthoud dan dat leveranciersmaatregelen binnen uw scope vallen; zie onze uitleg over ISO 27001-leveranciersbeheer.
Maatregel 8.17: de stille die onderzoeken doet mislukken
Kloksynchronisatie lijkt triviaal totdat u een firewalllog, een laptoplog en een cloudaudittrail probeert samen te leggen die enkele minuten van elkaar afwijken. Wijs systemen aan op overeengekomen tijdbronnen (doorgaans NTP), standaardiseer op één tijdzone voor beveiligingslogs (veel teams kiezen UTC) en houd een record van de configuratie bij. Neem een controle op afwijking op. Auditors accepteren doorgaans een screenshot of configuratie-export van een steekproef van systemen.
Bewijsmateriaal dat een auditor wil zien
Leg voor de fase 2-audit een map aan — fysiek of digitaal — met de volgende items:
- Logging- en monitoringbeleid of -standaard, goedgekeurd door het management.
- Een lijst van logbronnen binnen de scope, met eigenaren.
- Retentie-instellingen, afgestemd op het beleid.
- Toegangslijst voor het logplatform, met een recente review.
- Alertregels en de onderbouwing daarachter.
- Bewijs van review: gedateerde reviewrecords, ticketexports of een rapportage van een monitoringdashboard.
- Ten minste één voorbeeld waarbij een alert heeft geleid tot een onderzoek en de uitkomst daarvan.
- Tijdsynchronisatieconfiguratie voor een steekproef van systemen.
- Notulen van managementreviews die monitoringresultaten vermelden.
Item 7 telt het zwaarst. Als u geen echt incident hebt gehad, voer dan een tabletop-oefening of een testalert uit en leg dat vast. Een maatregel die nooit in werking is getreden is moeilijk te bewijzen.
Een uitrolvolgorde die werkt
Weken 1 tot 2: bepalen en documenteren
Zet uw kritieke systemen uit het activaregister en de risicoanalyse op een rij. Bepaal logbronnen, minimale gebeurtenissen, retentie en reviewers. Houd het beleid kort genoeg zodat mensen het lezen.
Weken 3 tot 6: verzamelen en beschermen
Schakel auditlogging in bij uw identiteitsprovider, cloudaccounts, endpoints en belangrijke SaaS-tools. Stuur ze door naar één centrale locatie. Beperk de toegang en corrigeer klokinstellingen.
Weken 7 tot 10: detecteren en reageren
Bouw de eerste tien alerts, wijs eigenaren toe en test ze. Koppel ze aan uw incidentticketworkflow.
Doorlopend: reviewen en verbeteren
Plan een terugkerende review, verwerk bevindingen in de managementreview en pas alertregels aan na elk incident of bijna-incident. Voor het bredere tijdschema rondom dit werk, zie onze ISO 27001-implementatietijdlijn. De bovenstaande volgorde is een planningsvoorbeeld, geen vaste vereiste. Uw eigen tempo hangt af van tooling, medewerkers en de volwassenheid waarmee u begint.
Branchenotities: financiën en betalingsgegevens
Financiële ondernemingen hebben extra verwachtingen omdat toezichthouders en examinatoren logs lezen als bewijs van beheersing. Als u ook kaartgegevens verwerkt, heeft PCI DSS eigen loggingeisen, en één gecombineerde aanpak kan vaak beide programma's bedienen. Ons artikel over het mappen van PCI DSS v4.0.1 op ISO 27001 laat zien hoe u dubbel auditwerk kunt vermijden. Voor datalekscenario's tonen de gids voor datalekrespons in de financiële sector en de gids voor incident response in het bankwezen waar logs de respons voeden.
Veelgemaakte fouten
- Alles loggen, niets reviewen. Volume is geen beheersing. Bepaal een scope die u daadwerkelijk kunt reviewen.
- Logs bewaren op dezelfde host. Een aanvaller met beheerdersrechten kan ze wissen.
- Geen schriftelijke retentie. Instellingen die afwijken van het beleid zijn een eenvoudige bevinding.
- Geen benoemde eigenaar voor alerts. Een alert die naar een gedeeld postvak wordt gestuurd, is vaak een alert die niemand leest.
- De SIEM als de maatregel beschouwen. De tool ondersteunt de maatregel. Het proces van reviewen en reageren ís de maatregel.
- SaaS en cloud negeren. Veel incidenten beginnen bij een identiteitsprovider of een cloudconsole, niet bij een server.
Als u een patroon zoekt voor het documenteren hoe een leverancier zijn eigen beveiligingspraktijken beschrijft, toont een pagina als het beveiligingsoverzicht van WorldEye hoe een dienst zijn beschermingsmaatregelen publiekelijk kan presenteren. Gebruik zo'n pagina als aanleiding voor wat uw eigen klanten mogelijk over uw logafhandeling zullen vragen.
Ons perspectief
Wij bouwen kosten- en inspanningsschattingen voor ISO 27001-projecten, en logging en monitoring is de post die mensen het meest verrast. De licentie voor een logplatform is zelden het grote getal. De tijd is dat: het afstellen van alerts, het opzetten van de reviewroutine en het maand na maand laten bewaken door iemand. Teams die alleen voor de tool budgetteren, eindigen met een dure opslagplaats van ongelezen logs.
Ons advies is om deze maatregel eerst in mensenuren te dimensioneren. Vraag uzelf af hoeveel systemen u gaat aansluiten, hoeveel alerts iemand realistisch per week kan triagen en of u een externe provider nodig heeft voor de avonden en weekenden. Vergelijk uw cijfers vervolgens met modelreferentievergelijkingen, zodat u weet of u te krap of te ruim plant. Een team dat voor het eerst implementeert in een gereguleerde branche mag hier meer van verwachten dan een startup van tien mensen in de softwaresector, omdat de bewijslat en het aantal systemen hoger liggen.
Wij denken ook dat auditors eerlijkheid belonen. Een kleine, werkende set alerts met gedateerde reviewrecords verslaat een ambitieus ontwerp dat alleen op een slide bestaat.
— Martin
Schat de inspanning in voordat u zich committeert
Als u een audit plant en wilt zien hoe logging, monitoring en de overige Annex A-maatregelen de kosten en tijdlijn beïnvloeden, probeer dan de ISO 27001-kostencalculator. Die geeft schattingen op basis van bedrijfsomvang, branche en beveiligingsvolwassenheid, en u kunt beginnen zonder u te registreren. Weet u niet waar u staat? De gratis gereedheidscheck van 2 minuten geeft een snelle eerste indruk, en de volledige gereedheidsbeoordeling gaat domein voor domein. Als u uw volledige plan opstelt, helpt de 80-stappen-certificeringschecklist u om loggingwerk te plaatsen tussen de overige taken.
FAQ
Is logging verplicht voor ISO 27001-certificering?
In de praktijk wel. Annex A-maatregel 8.15 omvat logging, en als u die uitsluit in uw Verklaring van Toepasselijkheid heeft u een solide onderbouwing nodig — wat moeilijk te geven is voor elke organisatie met IT-systemen. Auditors verwachten logs te zien voor de systemen binnen uw scope.
Wat is het verschil tussen maatregel 8.15 en 8.16?
Maatregel 8.15 gaat over het produceren, beschermen en analyseren van logs. Maatregel 8.16 gaat over het bewaken van netwerken, systemen en applicaties op afwijkend gedrag en het daarop reageren. U heeft beiden nodig: de eerste geeft u het record, de tweede geeft u detectie.
Heb ik een SIEM nodig om te voldoen aan ISO 27001?
De norm noemt geen tool. Een SIEM of een managed detectiedienst maakt correlatie en review veel eenvoudiger, en de richtlijnen van CISA wijzen op gecentraliseerde correlatie als behulpzaam voor respons. Een kleinere organisatie kan aan de maatregelen voldoen met gecentraliseerde logs, een aantal betrouwbare alerts en gedocumenteerde reviews.
Hoe lang moet ik logs bewaren?
ISO 27001 stelt geen vaste periode. Kies een retentietijd op basis van wettelijke verplichtingen, klantcontracten en hoe lang u incidenten wilt kunnen onderzoeken, leg dat vast in uw beleid en zorg dat uw platforminstellingen overeenkomen.
Kan één loggingopstelling zowel ISO 27001 als PCI DSS ondersteunen?
Vaak wel, als die van meet af aan met beide in gedachten is ontworpen, omdat beide vragen om gelogde en gereviewde activiteit. Breng de eisen naast elkaar in kaart en bevestig de details met uw beoordelaar. Ons artikel over het mappen van PCI DSS op ISO 27001 legt de aanpak uit.
Bronnen
- CISA: lessen geleerd uit een incident response-opdracht
- CISA: Logging Reference Architecture
- FFIEC IT Handbook: computer- en netwerkoperaties ter ondersteuning van betalingsoverdrachten
- FFIEC IT Handbook: managed security service providers