Een adequate, logische toegangsbeveiliging tot de geautomatiseerde systemen is nog steeds een onvervangbare maatregel van interne beheersing. Niet alleen in de audit- maar ook in de samenstelpraktijk is dit een aandachtspunt, immers ook daar lopen ondernemers digitale risico’s. Kortom ondernemingen – en accountants moeten daar goed op letten – moeten hier opnieuw de puntjes op de i zetten. En dat is geen rocket science.
Bij de meeste bedrijven heeft een controller of een systeembeheerder alle rechten binnen een applicatie, simpelweg omdat het functioneel is. Bedrijven kiezen voor zo’n functionele benadering van authenticatie en autorisatie. Daarbij stellen zij zich vaak niet de vraag: welke risico’s lopen we? Er is immers vooral behoefte aan voor de business werkbare oplossingen. Als je dan als accountant of IT-auditor aankomt met formele managementletterpunten waarin wordt gepleit voor een strakke logische toegangsbeveiliging dan is dat een bijna kansloze missie. Zeker als dat betekent dat een controller zijn rechten (lees status) moet afstaan.
Hierdoor is een systeemgerichte controle leuke theorie maar in praktijk nauwelijks uitvoerbaar. Als je een stap verder gaat zou je zelfs vraagtekens kunnen zetten bij de betrouwbaarheid van de transactieverwerking als zodanig. Immers, wie kan nog de garantie geven dat er niet gerommeld is met de transacties als een controller alles kan en mag in een financiële applicatie? Daarmee leggen we gelijk een bommetje onder de theorie dat met data-analyse de voortdurende werking van logische toegangsbeveiliging kan worden vastgesteld. Zonder een goed wijzigingsbeheer op uitgifte en inname van accounts, wachtwoorden en rechten weten we niet of de geregistreerde medewerker bij de transactie wel daadwerkelijk degene is die de bewerking heeft uitgevoerd. Dit riekt inderdaad naar de directe route richting een controleverklaring met oordeelonthouding zoals die inmiddels soms ook al door toetsers wordt gepropageerd.
Procesvolwassenheid
De betrouwbaarheid van een proces wordt, gelukkig voor accountants, door veel meer factoren bepaald dan alleen de logische toegangsbeveiliging. De PDCA (plan-do-check-act) cyclus van Deming is al enige jaren geleden onderdeel geworden van CoBIT (Control Objectives for Information and Related Technologies) en biedt een overzichtelijke manier om de volwassenheid van een proces en daarmee de mogelijke verwachting omtrent de controleerbaarheid ervan vooraf vast te kunnen stellen.
Aan de hand van gerichte vragen over de werking van de PDCA cyclus kan die verwachting vervolgens aan de werkelijkheid worden getoetst.
Om u op weg te helpen delen we deze vragen (gebaseerd op CoBIT 5) graag met u aan het einde van dit artikel.
Deze vragen kunt u op bijna elk proces toepassen om de volwassenheid snel in kaart te brengen. Uiteraard wordt er ook gekeken naar autorisatie (Do-fase tweede vraag) maar er zijn veel meer en soms zelfs betere aanknopingspunten voor de betrouwbaarheid van een proces. Je zou bijna zeggen dat logische toegangsbeveiliging overgewaardeerd is binnen de accountantscontrole. Dit is niet helemaal waar natuurlijk. Maar om te stellen dat er zonder een adequate logische toegangsbeveiliging geen goedkeurende verklaring mogelijk is, daar kunnen we met elkaar vraagtekens bij zetten.
Praktisch werkbare oplossingen voor logische toegangsbeveiliging
Dit neemt niet weg dat een goede logische toegangsbeveiliging nog steeds een waardevol stukje extra controlezekerheid biedt. Alleen al om die reden is het goed om te zoeken naar werkbare oplossingen waarmee ook kleinere controleklanten uit de voeten kunnen.
De techniek anno nu komt ons hierbij steeds meer te hulp. Wat zou u samen met u klant kunnen doen om logische toegangsbeveiliging op een werkbare manier in te richten voor zowel business als auditor?
- Om te beginnen kunt u de klant attenderen op twee fasen authenticatie waarbij bijvoorbeeld gebruik wordt gemaakt van een app op een smartphone als extra slot op de deur. Hierdoor wordt de authenticatie vraag (bent uw wie u zegt dat u bent?) in een keer getackeld. Immers het uitwisselen van wachtwoorden is in een klap zinloos geworden.
Hiermee voorkomt u ook dat medewerkers maandelijks hun wachtwoord moeten wijzigen, wat de garantie is voor een vast en dus makkelijker hackbaar patroon in wachtwoordstructuren, of (nog erger) geeltjes onder het toetsenbord. - Verder kan er gedacht worden aan een oplossing die in de SAP wereld al lang bekend staat onder te term Firefighter account. Een apart account waarmee bijzonder beheertaken op een systeem kunnen worden uitgevoerd en wat dient als vervanging voor de noodzaak om alle rechten toe te kennen aan de controller of systeembeheerder. Typisch kenmerken van een dergelijk account zijn:
- Permanente logging van alle activiteiten
- Geen mogelijkheid om rechtenbeheer uit te voeren
- Een aparte aanvraagprocedure om het wachtwoord van het account te verkrijgen
- Directe wijziging van het wachtwoord na gebruik
- Beperkte toegangsduur op het account.
- Nog net iets verder van ons bed zijn de biometrische beveiligingsopties zoals de vingerafdrukscanner. Maar het zal niet lang meer duren of deze zullen het traditionele aanloggen met een wachtwoord (geheel of gedeeltelijk) vervangen.
- Echt interessant wordt het als processmining als aanvullend controlemiddel om de hoek komt kijken als manier om de voortdurende werking van een klantproces mee vast te kunnen stellen. Immers dan zien we niet alleen hoe het proces zich werkelijk heeft voltrokken, maar is in één keer de vraag wie er steeds afwijkt van de procedures veel makkelijker te beantwoorden.
Kortom het moment dat we de discussie mogen gaan starten over logische toegangsbeveiliging als wellicht zelfs (deels) vervangbare maatregel van interne beheersing is wat mij betreft aangebroken en gegeven steeds verdergaande integratie tussen proces en IT ook hard nodig.
Jack van Crooij MSc.
Directeur Refl@ction
Geef een antwoord