Logboekregistratie, de beheersmaatregel die stilletjes verdwijnt.
ISO 27001:2022 A.8.15 (logboekregistratie) vereist dat veiligheidsrelevante gebeurtenissen (inlogpogingen, fouten, storingen, toegang tot gevoelige gegevens) worden geregistreerd, voor een gedefinieerde periode worden bewaard en beschermd tegen manipulatie. Het is essentieel voor A.8.16 (monitoring) en voor latere onderzoeken: je kunt niets detecteren of reconstrueren wat nooit is geregistreerd. En het is gemakkelijk te verzwakken zonder dat het opvalt, omdat een logregel vaak wordt opgeruimd.
The shapes the same control failure takes.
A.8.15 breekt zelden door een dramatische wijziging. Het breekt wanneer een veiligheidsrelevante gebeurtenis niet meer wordt geregistreerd. De terugkerende patronen:
Een veiligheidslog wordt verwijderd
Een logoproep voor een authenticatiegebeurtenis, een wijziging in rechten of toegang tot gevoelige gegevens wordt verwijderd tijdens een opschoning omdat het er 'ruisig' uitzag.
Het logniveau daalt onder productieniveau
Een veiligheidsgebeurtenis wordt verplaatst naar een niveau (debug) dat niet in productie wordt uitgevoerd, waardoor het stilletjes stopt met registreren waar het telt.
De actor ontbreekt in de registratie
Een log blijft actief, maar bevat niet meer wie de actie heeft uitgevoerd, waardoor de gebeurtenis niet meer kan worden toegeschreven tijdens een onderzoek.
Een nieuwe bevoorrechte actie wordt niet geregistreerd
Een nieuwe admin- of destructieve bewerking wordt toegevoegd zonder auditlog, waardoor er later niets te controleren is.
Bewaartermijn wordt verkort
De bewaartermijn of rotatie van een log wordt verkort tot onder wat de beheersmaatregel vereist, waardoor de registratie verdwijnt voordat iemand deze nodig heeft.
Authenticatiefouten verplaatst naar een logniveau onder productie.
Authenticatiefoutlogs zijn in ontwikkeling storend, dus een wijziging verplaatst ze van een waarschuwingsniveau naar een debugniveau. In productie staat het logniveau op info, waardoor deze fouten nu volledig uit de registratie verdwijnen, precies de gebeurtenissen die je het meest nodig hebt bij het onderzoeken van een inbraak.
if (!valid) {- logger.warn("auth.failed", { userId, ip })+ logger.debug("auth.failed", { userId, ip }) return unauthorized()}Met productie op info-niveau betekent het verlagen van authenticatiefouten naar debug dat ze niet meer in productie worden geregistreerd. A.8.15 vereist dat veiligheidsrelevante gebeurtenissen, inclusief mislukte authenticatie, worden gelogd en bewaard, en A.8.16 (monitoring) is hiervan afhankelijk. Houd ze op waarschuwingsniveau of leid ze door naar het veiligheidslog in plaats van ze in productie te dempen.
Logboekregistratie wordt gecontroleerd aan de hand van echte gebeurtenissen.
Een auditor controleert of veiligheidsrelevante gebeurtenissen daadwerkelijk worden gelogd, voor de in het beleid vastgelegde periode worden bewaard en beschermd tegen manipulatie. Ze zullen specifieke gebeurtenistypen controleren (inlogpogingen, wijzigingen in rechten, toegang tot gevoelige gegevens). Een wijziging die stilletjes stopt met het registreren van een van deze gebeurtenissen, door deze te verwijderen of onder het productieniveau te brengen, is de leemte die ze ontdekken. De wijziging die dit introduceerde was meestal een gewone pull request die eruitzag als ruisonderdrukking.
Een review, niet je SIEM.
heygrc markeert wijzigingen die A.8.15 raken en verwijst naar de beheersmaatregel, zodat de correctie in de pull request plaatsvindt. Het voert je loggingpijplijn of monitoring niet uit. Het vangt het moment op waarop een veiligheidsgebeurtenis stopt met registreren, in de diff.