Overladen rechten in SAP-applicaties risico (part II)

Veel bedrijven met SAP-erp-software hanteren een set met bovenmaats kritische rechten. Daarbij worden applicaties en afdelingen die dit controleren handig omzeild. Dit schaadt uiteindelijk het bedrijf en geeft fraudeurs, hackers en malware vrij spel. De oplossing ligt niet in techniek of in een applicatie maar in hoe we met security omgaan. Dit is het tweede deel van een drieluik over de spanningsvelden die ontstaan bij het oplossen van kritische rechten en het politieke spel van het verbergen van rechten.

Een accountant die na de jaarcontrole een fraudegevoelige omgeving aantreft, zal met recht beweren dat misbruik nu slechts een kwestie van tijd is. Daarom moeten de vergroeide autorisaties eerst los gemaakt worden. Dat komt er op neer dat je kleine brokjes autorisatie hebt waarmee tot de ene functie óf tot de andere functie toegang kunt geven. Je hebt vanaf dat moment dus een keuze in het toekennen van autorisaties.

Dit zijn de fasen in het oplossen van  segregation of duties (sod)-conflicten:

• Fase 1: Bewustwording dat het elimineren van functieconflicten nodig is;
• Fase 2: Aanschaffen van een applicatie die sod’s kan detecteren;
• Fase 3: Herbouwen van autorisatie als deze vergroeid is;
• Fase 4: Opnieuw samenstellen van het takenpakket van medewerker teams op basis van de oude situatie;
• Fase 5: Tactisch verschuiven van verschillende taken zodat sod-conflicten vervallen;
• Fase 6: Zoeken naar oplossingen voor sod-conflicten die vast zitten.

De werkelijke oplossing wordt pas behaald in fase 5 en 6 waar de business zelf met taken gaat schuiven om zo het aantal sod-conflicten te verminderen. Dit betekent dat teams meer specialistisch worden ingericht en dat bestaande teams soms gesplitst worden in hun uitvoerende taken.

Dit is natuurlijk niet waar de business op zit te wachten. De business heeft jaren gewerkt aan een efficiënte werkwijze met uiteenlopende taken per team en dus brede autorisaties. Deze werkwijze is verankerd en zit vast in het hoofd van de medewerkers. In het veranderen van deze werkwijze moet de business zichzelf vaak herontdekken. Er is dus sprake van businesstransformatie.

Dit zorgt voor een spanningsveld tussen het management en de business waar enig vuurwerk aan te pas komt. Dit artikel gaat over dit spanningsveld en hoe het zich een weg baant. Een spanningsveld waar internal audit midden in zit.

Muurvast

De grote terugslag komt als je ontdekt dat sommige sod’s ‘muurvast’ in de organisatie zitten, hoewel ze in technische zin zijn te verwijderen. De business claimt dat de efficiënte maar risicovolle werkwijze nodig is. Vanaf dit punt bouwt de druk alleen nog maar meer op om tot een oplossing te komen. Het hoger management wil de sod-conflicten weg hebben wegens het goedkeuren van de jaarrekening, de business wil de huidige werkwijze behouden wegens efficiëntie.

Stel nu dat internal audit bezig is met het in kaart brengen van de risico’s en uit aan het zoeken is met welke maatregelen het risico van een sod is te verminderen. Dan heeft internal audit baat bij een heldere omschrijving van het risico. Geen technische sod-beschrijving, maar het concrete risico. Dit is dus ook een belangrijk aspect van de sod-detectieapplicatie. Er zit helaas vaak een laagje zeep tussen internal audit en de business: die laatste zal nooit risico’s melden bij de eerste. De business heeft te veel baat bij deze ‘efficiënte’ werkwijze die inderdaad risico’s met zich meebrengt. Internal audit is dus niet altijd goed geïnformeerd. De eerder genoemde sod-tool is voor internal audit dus ook een ankerpunt om inzicht te krijgen.

Bij de interpretatie van de gegevens van de sod-detectietool ontstaat een tweedeling tussen de internal audit- en de businesskant. Vrij vertaald komt dit neer op het volgende:

• De lijst met sod-conflicten moet leeg en we passen businesstransformatie toe om dat te bereiken.

Of:

• We willen de risicovolle toegang met veel rechten laten bestaan ten behoeve van flexibiliteit in de business en passen ontduiking toe om detectie te voorkomen.

Bij financiële instellingen slaat deze tweedeling doorgaans door naar de kant van internal audit. Dat is inderdaad goed want banken willen zo min mogelijk kans hebben op elke technische mogelijkheid tot fraude. Er mogen dus geen sod-conflicten bestaan, ongeacht het verhaal er achter. Als je met geld omgaat, is de fraude plegen al snel verleidelijk, zeker als het kan. Denk aan de fraudedriehoek. Bij sommige andere bedrijven slaat het echter weer door naar de businesskant. En wuiven managers dit risico weg omdat ze de kans op bonussen groter acht. Dit is de kant van technisch en politiek vuurwerk dat uiteindelijk uitmondt in de grote duik. Voordat we het echter hebben over de grote duik en duistere manieren om frauderisico onzichtbaar te verbergen, eerst de opties die je hebt bij een functieconflict dat zich niet laat verwijderen.

De opties voor het verwijderen van sod-conflicten zijn:

• Splitsen van de taken van een team zodat het sod-conflict vervalt;
• Gebruik van noodusers of firefighters;
• Automatisering van een van beide taken van het conflict;
• Extra controle voor de uitoefening van het sod-conflict;
• Extra controle na de uitoefening van het conflict;
• Verlaging van het risico door andere omstandigheden.

Manier 1 is eigenlijk de natuurlijke manier van verwijderen. In veel gevallen lukt dit niet, zeker niet als je kiest voor het in managementkringen momenteel mateloos populaire ‘agile’ werken.

Manier 2 is het inzetten van een nooduser-account. Het idee is dat bij een noodsituatie de gebruiker de beschikking krijgt over een nooduser met uitgebreide(-re) rechten dan een gewone gebruiker. De noodsituatie is hiermee af te handelen zonder dat de medewerker permanent de beschikking heeft over deze rechten. Daardoor kunnen de rechten van het normale account van de medewerker lager zijn. Daarmee is dus een sod-conflict te voorkomen. Het gebruik van de nooduser wordt goed bewaakt en meestal is er goedkeuring nodig. Daarmee is er effectief een extra controle op beide functies. Tot zover de theorie.

Manier 3 is een van beide taken te automatiseren (via de ‘application controls’). Dit is een elegante manier om van het sod-conflict af te komen. Hierbij vervallen de rechten om een van beide taken zelf handmatig uit te voeren.

Manier 4 vergt soms ook enige customizing of programmeerwerk. Er wordt vooraf een extra controle gedaan waardoor het risico inderdaad lager wordt. Een voorbeeld is het vier-ogenprincipe bij het invullen van een rekeningnummer.

Manier 5 is min of meer alles laten bestaan van de sod en achteraf een controle uit te voeren of er sprake is van echte fraude. Dit kan wel prijzig uitvallen, omdat achteraf nog veel controlewerk dient te worden verricht.

Manier 6 is als er iets speciaals is dat het risico verlaagt. Dat kan inderdaad een serieuze en realistische situatie zijn. Bijvoorbeeld als de hoeveelheid winst of geld die je er mee zou kunnen opstrijken heel beperkt is.

(Wordt vervolgd.)