Financiële sector en het vertrouwensprobleem in de eigen audittrail

Een bank kan meestal een audittrail overleggen wanneer een toezichthouder hierom vraagt. Veel minder banken kunnen echter een lastigere vraag beantwoorden: had iemand met beheerdersrechten in alle stilte die log kunnen aanpassen voordat deze werd overlegd? Als het antwoord ja is, zelfs theoretisch, is de log geen bewijs. Het is dan een document dat iemand met de juiste inloggegevens had kunnen schrijven om alles te zeggen wat hij of zij wilde over de transactiegeschiedenis van een klant.

Toezichthouders en controleurs stellen deze vraag steeds vaker direct, omdat de waarde van een audittrail volledig afhangt van de betrouwbaarheid: weerspiegelt het wat er daadwerkelijk is gebeurd, of wat een beheerder liever zou laten zien? In dit artikel bekijken we wat een audittrail daadwerkelijk betrouwbaar maakt als bewijs voor een financiële instelling, en waar de logging bij de meeste instellingen stilletjes niet aan die toets voldoet.

Samenvatting voor het management

Het nut van een audittrail voor een toezichthouder 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 leiders op het gebied van beveiliging en compliance is de praktische norm architectonisch: kan een individu, inclusief een systeembeheerder, het logbestand daadwerkelijk wijzigen?

Belangrijkste inzichten

1. Een log die een beheerder kan bewerken of verwijderen is geen bewijs, ongeacht hoe gedetailleerd deze is. De bewijskracht hangt af van de vraag of het bestand aangepast had kunnen worden.
2. Toegang tot de onderliggende logopslag moet architectonisch beperkt zijn, niet alleen op basis van beleid. Een regel tegen het bewerken van logs betekent niets als de technische mogelijkheid daartoe nog steeds bestaat.
3. Scheiding van taken is minstens zo belangrijk als toegangsbeperking. Degene die een transactie uitvoert en degene die het log hiervan kan beoordelen of beheren, mogen niet dezelfde rol zijn.
4. Volledigheid en directheid zijn onderdeel van betrouwbaarheid, niet los ervan. Een log die steekproeven neemt bij hoge belasting of het schrijven van entries uitstelt, creëert een venster waarin gebeurtenissen kunnen worden verwijderd voordat ze worden vastgelegd.
5. Toezichthouders vragen steeds vaker hoe een log wordt beschermd, niet alleen wat erin staat. Een instelling die niet kan aangeven wie een logbestand had kunnen wijzigen, is niet volledig voorbereid op die vraag.

Waarom “We hebben gedetailleerde logs” het verkeerde vertrekpunt is voor financiële instellingen

De meeste gesprekken over auditlogging gaan over dekking. Dekking is belangrijk, maar beantwoordt niet de juiste eerste vraag.

Detail zonder integriteit is slechts een goed geschreven verhaal

Een log met veel details over klanttransacties is alleen zo betrouwbaar als de garantie dat niemand deze achteraf heeft aangepast. Een beheerder met database-toegang kan in principe een zeer gedetailleerde log net zo makkelijk bewerken als een beknopte.

De vraag die écht telt: wie had dit kunnen aanpassen

De juiste eerste vraag bij het beoordelen van een auditlog is niet wat er wordt vastgelegd, maar wie technisch in staat is het log achteraf te wijzigen.

Waarom logintegriteit architectonisch moet zijn en niet alleen procedureel

Een beleid dat stelt dat beheerders geen logs mogen bewerken, vertrouwt erop dat beheerders zich hieraan 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 wanneer noch de eigen IT-beheerders van de instelling, 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, expliciete goedkeuring van meer dan één partij vereist, en zelf volledig wordt gelogd.

Scheiding van taken als tweede, onafhankelijke waarborg

Als dezelfde rol die klantgelden kan verplaatsen ook de rol is die het log hiervan kan beoordelen, is er een inherent 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 operationeel beheer.

De standaard opbouwen voordat een toezichthouder erom vraagt

De praktische test is om eerlijk te vragen wie technisch de auditlogs van de instelling zou kunnen wijzigen, en of de rollen die handelen en de rollen die auditen echt gescheiden zijn.

Hoe een Data Control Plane bewijsintegriteit in de architectuur verankert

Het Kiteworks Data Control Plane draait op een geharde architectuur waarbij noch Kiteworks, noch de eigen IT-beheerders van de instelling gewone toegang hebben tot het onderliggende besturingssysteem of de database, inclusief de opslag van auditlogs; elke supporttoegang is tijdelijk, vereist dubbele goedkeuring en wordt zelf volledig gelogd. Gescheiden rollen voor Compliance, Auditor en CISO zorgen ervoor dat operationeel beheer en auditfuncties gescheiden zijn, en elke actie via elk kanaal wordt volledig en direct vastgelegd in een manipulatiebestendige, onbeperkte auditlog die direct wordt doorgezet naar SIEM-tools.

Instellingen die willen testen of hun huidige audittrail bestand is tegen de vraag “had een beheerder dit kunnen aanpassen”, kunnen een aangepaste demo plannen.