Een Audittrail Opbouwen die Standhoudt voor Defensie
Een aannemer kan meestal een access log overleggen wanneer een beoordelaar daarom vraagt. Veel minder aannemers kunnen echter een moeilijkere vraag beantwoorden: had iemand met beheerdersrechten stilletjes dat log kunnen bewerken voordat het werd overlegd? Als het antwoord ja is, zelfs theoretisch, is het log geen bewijs. Het is een document dat iemand met de juiste inloggegevens had kunnen schrijven om alles te zeggen wat ze wilden over wie een gecontroleerd bestand heeft aangeraakt.
Dit artikel onderzoekt wat een audittrail daadwerkelijk betrouwbaar maakt als bewijs voor een defensie-aannemer, en waar de logging van de meeste aannemers stilletjes niet aan die toets voldoet.
Samenvatting
De bruikbaarheid van een audittrail voor een CMMC-beoordelaar of interne onderzoeker hangt volledig af van het vertrouwen in de integriteit ervan, en dat vertrouwen kan niet alleen op beleid gebaseerd zijn. Als administratieve toegang tot de onderliggende logopslag technisch bewerken mogelijk maakt, is het feit dat beleid dit verbiedt niet hetzelfde als dat het onmogelijk is. Voor programmabeveiligingsleiders is de praktische standaard architectonisch: kan een individu, inclusief een systeembeheerder, het log daadwerkelijk wijzigen?
Belangrijkste inzichten
- Een log die een beheerder kan bewerken of verwijderen is geen bewijs, ongeacht hoe gedetailleerd het is.
- Toegang tot de onderliggende logopslag moet architectonisch beperkt zijn, niet alleen beleidsmatig.
- Scheiding van taken is net zo belangrijk als toegangsbeperking. Degene die CUI benadert en degene die het log van die toegang bekijkt, mogen niet dezelfde rol zijn.
- Volledigheid en directheid zijn onderdeel van betrouwbaarheid, niet losstaand ervan.
- Beoordelaars vragen steeds vaker hoe een log wordt beschermd, niet alleen wat het bevat.
Waarom “We hebben gedetailleerde logs” het verkeerde uitgangspunt is voor aannemers
De meeste gesprekken over auditlogging richten zich op dekking. Dekking is belangrijk, maar beantwoordt niet de juiste eerste vraag.
Detail zonder integriteit is slechts een goed geschreven verhaal
Een log met veel detail over wie een gecontroleerd bestand heeft benaderd, is alleen zo betrouwbaar als de garantie dat niemand het achteraf heeft gewijzigd.
De vraag die echt telt: wie had dit kunnen wijzigen
De juiste eerste vraag is niet wat een log vastlegt, maar wie de technische mogelijkheid heeft om het na het schrijven te wijzigen.
Wat maakt logintegriteit architectonisch in plaats van procedureel
Een beleid dat stelt dat beheerders geen logs mogen bewerken, vertrouwt erop dat beheerders zich eraan houden. Een architectonische controle neemt de technische mogelijkheid om anders te handelen weg.
Geen standaardtoegang tot de onderliggende logopslag
De sterkste vorm van deze controle is dat noch de eigen IT-beheerders van de aannemer, noch de platformleverancier gewone toegang hebben tot het besturingssysteem of de database waar logs worden opgeslagen.
Uitzonderingen moeten echt uitzondering zijn, geen achterdeur
Wat een verdedigbare uitzondering onderscheidt van een achterdeur is of die toegang tijdelijk is, dubbele autorisatie vereist en zelf volledig wordt gelogd.
Scheiding van taken als tweede, onafhankelijke waarborg
Als dezelfde rol CUI kan benaderen én het log van die toegang kan beoordelen, is er sprake van een inherent belangenconflict.
Degene die handelt, mag niet degene zijn die controleert
Echte scheiding van taken wijst compliance-, audit- en beleidsfuncties toe aan andere rollen dan operationeel beheer.
De standaard bouwen voordat een beoordelaar erom vraagt
De praktische test is om eerlijk te vragen wie technisch het auditlog van de aannemer zou kunnen wijzigen, en of de rollen die handelen en de rollen die auditen daadwerkelijk gescheiden zijn.
Hoe een Data Control Plane bewijsintegriteit in de architectuur inbouwt
Het Kiteworks Data Control Plane draait op een geharde architectuur waarbij noch Kiteworks, noch de eigen IT-beheerders van de aannemer gewone toegang hebben tot het onderliggende besturingssysteem of de database, inclusief de opslag van het auditlog; elke supporttoegang is tijdelijk, vereist dubbele autorisatie en wordt zelf volledig gelogd. Specifieke Compliance- en Auditor-rollen scheiden operationeel beheer van auditfuncties, en elke actie via elk kanaal wordt volledig en direct vastgelegd in een manipulatiebestendig, onbeperkt auditlog dat rechtstreeks in SIEM-tools wordt gevoed.
Aannemers die willen testen of hun huidige audittrail de “kon een admin dit bewerken”-vraag zou doorstaan, kunnen een aangepaste demo plannen.
Veelgestelde vragen
De bruikbaarheid van een audittrail hangt volledig af van het vertrouwen in de integriteit ervan. Dit vertrouwen kan niet alleen op beleid rusten; toegang tot de onderliggende logopslag moet architectonisch beperkt zijn zodat geen enkel individu, inclusief een systeembeheerder, het log kan wijzigen.
Een log die een beheerder kan bewerken of verwijderen is geen bewijs, ongeacht hoe gedetailleerd het is. Als administratieve toegang technisch bewerken mogelijk maakt, had het log gemanipuleerd kunnen worden om alles te zeggen wat de bewerker wilde over wie een gecontroleerd bestand heeft aangeraakt.
Scheiding van taken is net zo belangrijk als toegangsbeperking. Degene die CUI benadert en degene die het log van die toegang bekijkt, mogen niet dezelfde rol zijn, omdat dit een inherent belangenconflict oplevert.
Het Kiteworks Data Control Plane draait op een geharde architectuur waarbij noch Kiteworks, noch de IT-beheerders van de aannemer gewone toegang hebben tot het onderliggende besturingssysteem of de database, inclusief de opslag van het auditlog. Elke supporttoegang is tijdelijk, vereist dubbele autorisatie en wordt volledig gelogd, met specifieke Compliance- en Auditor-rollen die operationeel beheer scheiden van auditfuncties.