De audittrail van een bedrijf onder dezelfde controle als die van zijn klanten
Een bedrijf kan meestal een activiteitenlogboek overleggen wanneer een cliënt of rechtbank hierom vraagt. Veel minder bedrijven kunnen een moeilijkere vraag beantwoorden: had iemand met beheerdersrechten het logboek stilletjes kunnen aanpassen voordat het werd overlegd? Als het antwoord ja is, zelfs in theorie, is het logboek 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 dossier heeft geraadpleegd.
Dit artikel onderzoekt wat een audittrail daadwerkelijk betrouwbaar maakt als bewijs voor een advocatenkantoor, en waar de logging van de meeste kantoren ongemerkt tekortschiet.
Samenvatting voor het management
De waarde van een audittrail voor een cliënt, rechtbank of interne onderzoeker hangt volledig af van het vertrouwen in de integriteit ervan, en dat vertrouwen kan niet alleen op beleid rusten. 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 risicoleiders is de praktische norm architectonisch: kan een individu, inclusief een systeembeheerder, daadwerkelijk het logboek aanpassen?
Belangrijkste punten
- Een logboek dat 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 via beleid.
- Scheiding van taken is net zo belangrijk als toegangsbeperking. Degene die een dossier raadpleegt en degene die het logboek daarvan controleert, mogen niet dezelfde rol hebben.
- Volledigheid en directheid zijn onderdeel van betrouwbaarheid, niet los ervan.
- Cliënten vragen steeds vaker hoe een logboek wordt beschermd, niet alleen wat het bevat.
Waarom “We hebben gedetailleerde logs” het verkeerde uitgangspunt is voor advocatenkantoren
De meeste gesprekken over auditlogging gaan over dekking. Dekking is belangrijk, maar beantwoordt niet de belangrijkste eerste vraag.
Detail zonder integriteit is slechts een goed geschreven verhaal
Een logboek met veel details over wie een dossier heeft geraadpleegd, is alleen zo betrouwbaar als de garantie dat niemand het achteraf heeft aangepast.
De vraag die echt telt: wie had dit kunnen wijzigen
De juiste eerste vraag is niet wat een logboek vastlegt, maar wie technisch in staat is het na het schrijven te wijzigen.
Waarom logintegriteit architectonisch in plaats van procedureel moet zijn
Een beleid dat stelt dat beheerders geen logs mogen bewerken, vertrouwt erop dat beheerders zich eraan houden. Een architectonische controle neemt de technische mogelijkheid weg om anders te handelen.
Geen standaardtoegang tot de onderliggende logopslag
De sterkste vorm van deze controle is dat noch de IT-beheerders van het kantoor, noch de platformleverancier gewone toegang hebben tot het besturingssysteem of de database waar logs worden opgeslagen.
Uitzonderingen moeten echt uitzonderingen zijn, geen achterdeuren
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 die een dossier kan raadplegen ook de rol is die het logboek daarvan controleert, ontstaat er een fundamenteel belangenconflict.
Degene die handelt, mag niet degene zijn die controleert
Echte scheiding van taken betekent dat compliance-, audit- en beleidsfuncties worden toegewezen aan andere rollen dan operationele administratie.
De norm opbouwen voordat een cliënt erom vraagt
De praktische test is om eerlijk te vragen wie technisch het auditlogboek van het kantoor zou kunnen aanpassen, en of de rollen die handelen en de rollen die auditen daadwerkelijk gescheiden zijn.
Hoe een Data Control Plane bewijswaarde in de architectuur verankert
Het Kiteworks Data Control Plane draait op een geharde architectuur waarbij noch Kiteworks, noch de eigen IT-beheerders van het kantoor gewone toegang hebben tot het onderliggende besturingssysteem of de database, inclusief de auditlogopslag; elke ondersteunende toegang is tijdelijk, vereist dubbele autorisatie en wordt volledig gelogd. Toegewijde Compliance- en Auditor-rollen scheiden operationele administratie van auditfuncties, en elke handeling via elk kanaal wordt volledig en direct vastgelegd in een manipulatiebestendig, onbeperkt auditlogboek dat rechtstreeks wordt doorgegeven aan SIEM-tools.
Kantoren die willen testen of hun huidige audittrail bestand is tegen de vraag “had een beheerder dit kunnen bewerken”, kunnen een aangepaste demo plannen.
Veelgestelde vragen
Een logboek dat een beheerder kan bewerken of verwijderen is geen bewijs, ongeacht hoe gedetailleerd het is, omdat het achteraf aangepast kan zijn om alles te zeggen wat de bewerker wilde over wie een dossier heeft geraadpleegd.
Een beleid dat stelt dat beheerders geen logs mogen bewerken, vertrouwt erop dat zij zich eraan houden, terwijl een architectonische controle de technische mogelijkheid wegneemt om de onderliggende logopslag te bewerken of te benaderen.
Scheiding van taken zorgt ervoor dat degene die een dossier raadpleegt niet dezelfde rol heeft als degene die het logboek controleert of kan aanpassen, waardoor een fundamenteel belangenconflict tussen operationele handelingen en auditfuncties wordt voorkomen.
Het Kiteworks Data Control Plane gebruikt een geharde architectuur waarbij noch Kiteworks, noch IT-beheerders van het kantoor gewone toegang hebben tot de logopslag; elke ondersteunende toegang is tijdelijk, vereist dubbele autorisatie en wordt volledig gelogd, met aparte Compliance- en Auditor-rollen die auditfuncties gescheiden houden van operationele taken.