Managing van SoD’s: preventieve en detective controles met MARC
Een tijdje geleden plaatste onze partner XS Control (Azië) een artikel op hun website over preventieve versus detective controles. Het geeft een interessante kijk op hoe u de impact van risico's in uw organisatie kunt beheersen. Hier willen we de conclusies uit dat artikel oppikken en analyseren hoe dit werkt voor de autorisaties en toegangscontroles en hoe software zoals de MARC4GRC-suite kan helpen.
Preventief versus detective
Het belangrijkste voordeel van preventieve controles is dat het gerelateerde risico zich niet voordoet, of dat op z'n minst de impact wordt minimaliseert. Het is zoals het Nederlandse gezegde: Voorkomen is beter dan genezen! Dit gezegde, eind 16e eeuw komend van de Nederlandse filosoof Desiderius Erasmus, wordt vaak gebruikt in strategieën voor gezondheidszorg en sociale zorg en komt nu in steeds meer vakgebieden terug. Meer algemeen: ‘Better Safe than Sorry!’
Dat hangt samen met het grootste nadeel van detective-controles: een risicoschending kan pas worden opgespoord nadat deze heeft plaatsgevonden en dan blijf je achter met het proberen de impact zoveel mogelijk te beperken.
Maar effectieve detective-controles helpen een incident onmiddellijk te ontdekken, zodat passende actie kan worden ondernomen om de impact te elimineren of op zijn minst te beperken.
Preventieve controle: monitoring van autorisaties (SoD-analyse)
Het hebben van een solide framework voor rollen en autorisaties (met duidelijke naamgevingsconventies, SoD-vrije rollen, etc.) is een goed begin. Het is belangrijk om dit kader goed te onderhouden: transporten van onjuiste rolwijzigingen naar productie en/of verkeerde roltoewijzingen naar gebruikers kunnen de preventieve protectie ondermijnen. In onze post van oktober 2022 (hier) lees je meer over het verandermanagement van rollen.
Bij het monitoren van de naleving van actuele user access met SoD-regels kunnen mitigaties worden toegestaan. Mitigaties verzwakken de effectiviteit van preventieve controle. Veel mitigatiecontroles zijn namelijk ‘detective’ van aard, en dan voorkomen de verleende autorisaties niets. Het wordt aanbevolen om SoD-risico's en autorisatierollen maximaal te finetunen, zodat het optreden van echte en valse SoD-overtredingen kan worden geminimaliseerd. Dan kunnen ook detective mitigatie controles worden gereduceerd.
Het is een hele uitdaging om user acces en autorisaties volledig te managen binnen een solide controlekader. Dit rechtvaardigt echter niet het nemen van short cuts. Om operationele redenen zijn sowieso rollen en autorisaties nodig. Dus het loont om daar zo effectief mogelijk mee om te gaan. Houd er rekening mee dat om operationele redenen toch rollen en autorisaties nodig zijn en dat het dus loont om er zo effectief mogelijk mee om te gaan.
Het belangrijkste is om frequente controles op de productie uit te voeren op SoD-problemen en de output van deze controles op de juiste manier aan te pakken.
Detective controles: monitoring op access violation
Zoals eerder aangegeven: mitigaties moeten worden toegestaan wanneer gebruikerstoegang moet worden verleend ondanks dat deze toegang mogelijk de SoD-regels schendt. Mitigaties, meestal detectivecontroles, veroorzaken de behoefte aan monitoring van toegangsschendingen. Hoe vaak (frequentie) deze detectiecontroles moeten worden uitgevoerd hangt af van de responstijd die nodig is om de waargenomen output te adresseren.
Ook moeten de definities zo nauwkeurig mogelijk zijn, aangezien je niet wilt dat er veel issues worden gemeld en zeker niet teveel false-positieven, omdat actie vereist is bij elk incident.
Het opsporen van violations is één ding, maar het is ook belangrijk hoe snel de vertegenwoordiger-bedrijf hierop kan reageren en of de impact van een echt probleem kan worden verminderd. Dit hangt echt af van de aard van de gemelde overtreding en het gevonden incident.
Bijvoorbeeld:
Hoe zit het met MARC?
MARC biedt verschillende mogelijkheden om de risico's te verminderen.
Ten eerste is er natuurlijk de Access Conflict Monitor (ACM) die een diepgaande, geautomatiseerde analyse biedt van de gebruikersautorisaties in vergelijking met de SoD-regels die zijn gedefinieerd in het MARC-regelboek. Door deze analyse in te plannen, bijvoorbeeld elke maandafsluiting, kunnen autorisaties het hele jaar door worden gemonitord.
Als deze ACM-rapportage wordt verwerkt met de Risk Execution Monitor (REM), kunt u het aantal gerapporteerde hits verminderen door uitsluiting waar transacties met betrekking tot de risico's niet zijn uitgevoerd.
Ten derde bevat de Internal Control Monitor (ICM) vooraf gedefinieerde SoD-risicodefinities voor controle op SAP-document-/transactieniveau. Op basis hiervan kunnen SoD-violations op documentniveau door dezelfde gebruiker worden gedetecteerd (zoals in het voorbeeld van gebruiker X die de factuur boekt van de inkooporder die door hemzelf is goedgekeurd).
Enkele conclusies
Zoals vermeld in het artikel van XS Control, moeten de preventieve en detectivecontroles in evenwicht zijn.
Het gebruik van alleen de ICM-besturingselementen in MARC lijkt een aantrekkelijke short cut te zijn, maar het levert valse positieven op omdat definities mogelijk niet helemaal nauwkeurig zijn. Bij gemelde problemen is een korte responstijd vereist. En zonder een goed begrip van de onderliggende autorisaties die het probleem mogelijk maakten, kan het probleem zich in de toekomst opnieuw voordoen. Nederlanders zouden dit ‘dweilen met de kraan open’ noemen…
Een goede inrichting van de autorisaties voorkomt dat deze problemen zich voordoen. Als onderdeel van het role provisioning process is het eenvoudig om SoD-compatibele user access te implementeren – dat vergt weinig extra inspanning.
Met een eenvoudig te implementeren en kosteneffectieve oplossing zoals MARC is, kunnen SAP SoD's uitstekend worden gemanaged met behulp van een uitgebalanceerde mix van preventieve en detective controles.