Mark Deiss (CISSP)

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 artikel gaat over de spanningsvelden die ontstaan bij het oplossen van kritische rechten en het politieke spel van het verbergen van rechten.

SAP ERP software

Wereldwijd gebruiken veel bedrijven SAP als de ERP oplossing voor hun bedrijf. SAP is een van de grotere bedrijven met ERP software. De kracht van deze software is de enorme veelzijdigheid. Voor elke bedrijfstak is er specialistische software gemaakt. Door deze veelzijdigheid kunnen bijna altijd alle processen van een bedrijf door SAP ondersteund worden. Deze veelzijdigheid heeft een keerzijde: er is te veel mogelijk en je moet keuzes maken in wat je wilt gebruiken en wat niet. Dat kun je allemaal instellen in SAP. Ten eerste wat je wilt gebruiken en ten tweede welke gebruiker wat gebruikt. Dit bepaal je met autorisaties.

 Functieconflicten

Een gebruiker kan verschillende bedrijfsfuncties uitvoeren. Hoe meer autorisatie je heb, hoe meer functies je kunt uitvoeren. Sommige functies mogen niet gecombineerd worden met andere functies omdat je dan een punt creëert waarop fraude kan plaatsvinden. Bijvoorbeeld het crediteur rekeningnummer invullen en betalingen uitvoeren. Als je die twee handelingen kunt doen dan kun je zelfstandig een betaling doen naar elke gewenst rekeningnummer. Dat is natuurlijk fraudegevoelig.

Deze twee functies samen noem je een functiescheidingsconflict ofwel een Segregation of Duties (SoD) conflict. Te veel SoD conflicten zijn niet goed voor een bedrijf. Fraude is niet wat een bedrijf wil maar er zijn natuurlijk ook situaties waar dat wel voorkomt. Gelukkig is het zo dat accountancy bedrijven zoals KPMG, EY, PWC een controle doen op de getrouwheid van de jaarrekening. In eerste instantie gaat het dan om een financiële controle. Als daar posten of processen in zitten die gevoelig zijn voor fraude, dan kijkt de accountant ook naar de IT-kant van het bedrijf. Zijn er SoD conflicten aanwezig, dan is er de mogelijkheid van fraude. Dat kan dan aanleiding geven tot een nog diepere controle in het systeem. De accountant wil dan bijvoorbeeld weten of het bedrijf in staat is de verschillende conflicterende handelingen uit elkaar te houden. Zijn daar twijfels over, dan kan het zijn dat men diepgaand gegevensgericht moet gaan controleren. Dit met doorgaans met flink hogere kosten.

 Tooling voor het detecteren van functie conflicten

Gelukkig bestaan er verschillende applicaties om een ondoorzichtige berg aan SAP autorisaties te analyseren en te bepalen bij wie er SoD conflicten voorkomen en hoe dat komt. Voorbeelden van enkele van deze tools zijn SAP-GRC, SAST, SOFY, AccessConnector. Deze tools hebben ingebouwde kennis hoe een functiescheidingsconflict kan ontstaan en detecteren dat ook als deze op een vreemde of onverwachte manier tot stand komt. Bedrijven kunnen hiermee zelf controle uitvoeren. Niet zelden vraagt een accountant de rapporten van de tool op om zijn bevindingen over het financieel welzijn van een bedrijf te staven.

 Efficiëntie gaat voor security

Nu klinkt dit als een 1 + 1 = 2 verhaal. Als er een probleem is dan zie je dit en kun je het ook oplossen. In werkelijkheid is het verwijderen van functiescheidingsconflicten verre van gemakkelijk en heeft het ook een ‘duistere’ kant zoals we later in dit artikel zullen gaan zien. De drie grootste oorzaken van het niet kunnen verwijderen van SoD’s zijn:

1. Vergroeiing van autorisaties
2. Onderbezetting
3. Gekozen over-efficiëntie

Vergroeiing van autorisaties

Een autorisatie systeem is goed te vergelijken met een apothekers kast met flessen met een opschrift. Als het goed is kun je iets makkelijk opzoeken. Ook zit er in het potje wat er op het etiket staat. Onder de druk om een hele specifiek oplossing te leveren worden er soms zaken gecombineerd die niet bij elkaar horen. Als dit een aantal jaren door gaat dan zit niet meer in het potje wat er op het etiket staat. Bij een autorisatiessysteem geldt dat hoe hoger de standaardisatie is, hoe beter het te besturen is. Er zijn echter autorisatiesystemen waar door jaren van onzorgvuldige wijzigen alles aan elkaar vast zit. In dat geval is het niet meer mogelijk om rechten goed uit te leveren. Ook corrigeren is goed mogelijk meer. Een verandering heeft dan heel veel zijeffecten. Alles zit aan elkaar vast.

Onderbezetting

De SAP gebruikers in de grotere bedrijven van ons land hebben het lang niet altijd makkelijk. Vaak is er minimale bezetting op een afdeling. Dit betekent netto dat alle benodigde functies over deze mensen verdeeld moeten worden. Het is dus niet mogelijk om aan een aantal SoD conflicten te ontkomen. Je zit er aan vast. Het kernprobleem is dus altijd onderbezetting terwijl autorisatie vergroeiing het losmaken onmogelijk kan maken.

Over-Efficiëntie

Efficiëntie en economisch belang gaan bij de meeste bedrijven altijd vóór op veiligheid van hun gegevens. Met méér autorisaties kun je zelfstandig ook meer zaken oplossen. Je kunt dus met opzet iemand zo’n brede autorisatie geven dat hij virtueel drie verschillende functies vervult. Als deze medewerker heel hard werkt dan heb je er dus eigenlijk drie voor de prijs van één. Zo’n regelneef is voor het bedrijf heel efficiënt. Pas later beseft het bedrijf dat die over-efficiënte werkwijze ook zijn keerzijde heeft. Als de regelneef ineens thuis ziek in bed ligt, sla je een gat in het bedrijf. Er is een zeer sterke afhankelijkheid gecreëerd. Misschien dat medewerkers die nu overspannen thuis zitten bij het lezen van deze regels een patroon herkennen en beseffen dat ze eigenlijk jarenlang een heel team aan mensen aan het vervangen zijn geweest. 

Er komt pas een kanteling in de over-efficiëntie maar fraude gevoelige werkwijze als er een dwingende reden is. Dat is als de jaarrekening niet meer automatisch wordt goedgekeurd. Op dat moment ontstaat er pas een belang om van de fraudegevoelige rechten af te komen.

Fasen in het oplossen van functieconflicten

Een accountant die na de jaarcontrole een zeer fraudegevoelige omgeving aantreft, zal met recht beweren dat fraude 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 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 business transformatie.

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.

De grote terugslag en de grote duik

De grote terugslag komt als men ontdekt dat sommige SoD’s ‘muurvast’ in de organisatie zitten ondanks het feit dat ze in technische zin verwijderd zouden kunnen worden. 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 verminderd kan worden. Dan heeft Internal Audit baat bij een heldere omschrijving van het risico. Geen technische SoD beschrijving, maar liever het concrete risico. Dit is dus ook een belangrijk aspect van de SoD detectie applicatie. Er zit helaas zeer vaak een laagje zeep tussen Internal Audit en de Business: ‘de business’ zal nooit risico’s gaan melden bij Internal Audit. Zij hebben 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 detectie tool ontstaat een tweedeling tussen de Internal Audit kant en de businesskant. Vrij vertaald komt dit neer op het volgende:

• De lijst met SoD conflicten moet leeg en we passen business transformatie 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 men met geld omgaat, is de fraude plegen al snel verleidelijk, zeker als het kan. Denk hierbij aan de fraudedriehoek. Bij sommige andere bedrijven slaat het echter weer door naar de businesskant. En wuiven managers dit risico weg omdat men 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 fraude risico onzichtbaar te verbergen, eerst de opties die je hebt bij een functie conflict dat zich niet laat verwijderen.

De opties voor het verwijderen van SoD conflicten zijn:

 1.      Splitsen van de taken van een team zodat het SoD conflict vervalt

2.      Gebruik van noodusers of firefighters

3.      Automatisering van een van beide taken van het conflict

4.      Een extra controle voor de uitoefening van het SoD conflict

5.      Een extra controle na de uitoefening van het conflict

6.      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 men 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 kan hiermee worden afgehandeld 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 kan dus een SoD conflict worden 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 wat customizing of programmeerwerk. Er wordt vooraf een extra controle gedaan waardoor het risico inderdaad lager wordt. Een voorbeeld is het vier ogen principe bij het invullen van een rekening nummer.

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.

‘Ondergrondse’ toegang en het omzeilen van Internal Audit of Control

Zoals gezegd zit er een tweedeling in de interpretatie van de resultaten van de SoD detectie tool. De business heeft er soms alle belang bij om ten koste van alles bepaalde toegang te behouden. Dit is meestal niet eens op onredelijke basis, het gaat dan om efficiëntie of ernstige onderbezetting. Vaak ook weer veroorzaakt door de directie die stuurt op (extreme) kostenverlaging. Dit betekent dat Internal Audit of Control omzeild moet worden. Mazen in het toepassen van de bovenstaande opties geven daar de gelegenheid toe. Daarbij ontstaan vaak groteske en absurdistische situaties.

De onderstaande situaties zijn niet hypothetisch, maar praktijkvoorbeelden:

Uitwisselen van het wachtwoord / dubbele accounts

Teams zijn soms gesplitst in een A en B kant om daarmee bepaalde conflicterende taken te voorkomen. Met het uitwisselen van het wachtwoord kan dat effectief omzeild worden. Dit is echter ook totaal onzichtbaar. Het lijkt net of er 2 mensen aan het werk zijn terwijl dat niet zo is. Een andere manier is twee accounts gebruiken.

Misbruik van de Nooduser

De Nooduser wordt op permanente basis gebruikt om extra rechten te krijgen. Er is dus geen sprake meer van een noodsituatie, maar van een operationele situatie waarin op tactische wijze gebruik wordt gemaakt van de Nooduser.

Nieuwe naam

De SoD tool herkent alleen dingen die hij kent. Hij herkent geen bedrijfseigen maatwerk. Dit moet je bekent maken aan de tool. Daarmee kan al een hele sloot aan maatwerk onder de radar van Internal Audit schuiven. Als je een nieuwe SAP transactie maakt dan wordt deze dus initieel niet herkent. Slordigheid en gecalculeerde listigheid voeren beide naar dit punt van niet gedetecteerde SoD’s.

De ontbrekende IT-architect

Ontbreekt de IT-architect in een organisatie, dan kan alles op een eigen manier gemaakt worden. Zolang maatwerk maar functioneel werkt, zal het door de business geaccepteerd worden. Je kunt dus iets maken wat net twee taken combineert die gescheiden zouden moeten blijven. Dit komt voor bij SAP Fiori applicaties. Bij een goed ontwerp worden functieconflicten in Fiori applicaties net zo goed gedetecteerd als bij normale transacties. De praktijk is dat dit lang niet altijd gebeurt. Er worden op die manier applicaties gemaakt die functioneel goed werken maar SoD technisch toch een haakje missen of erger … een datalek kunnen veroorzaken.

Extra toetsing achteraf

Velen die bepaalde toegang met een frauderisico willen houden, zullen beargumenteren dat het niet gaat om de detectie van de mogelijkheid tot het plegen van fraude, maar de detectie van werkelijke fraude. Met dit argument in de hand worden dan inhoudelijke loggingen opgezet om zo de fraudegevallen te filteren uit de operationele stroom van bewerkingen. Het gaat dan om situaties waarbij zowel functie A als functie B op hetzelfde subject worden uitgevoerd. Als er echter fraude wordt uitgevoerd dan gebeurt dit door die mensen die dit systeem heel goed kennen. Er zijn bijzonder interessante constructies gevonden waarbij de logging uit te schakelen was. Daarbij ontstaat een situatie waarbij een logschaduw van een paar minuten ontstaat. Daarmee ontloop je automatische detectie. Ook zijn er situaties gezien waarbij de logging door “technische problemen” niet aan stond net aan het begin van het jaar toen de jaarafsluiting werd gedaan. Dat is inderdaad heel toevallig…

Politiek

Het laatste wapen in het in stand houden van een omgeving met fraude mogelijkheden is politiek. Zoals eerder gesteld, is security bijna altijd ondergeschikt aan het commerciële bedrijfsbelang, terwijl security juist één van de bedrijfsbelangen zou moeten zijn. Als het om economische winst gaat, legt veiligheid van gegevens het af. Er zijn documentaires over de Space Shuttle die het fenomeen van politiek versus risico’s haarfijn uitleggen. Dit wordt bijvoorbeeld gedaan door niet de SoD’s zelf te ontkennen, maar glashard het risico ontkennen dat ze vormen. Er bestaan gevallen van geïnstitutionaliseerde risico-ontkenning die een Teletubbielandschap waardig is. Gewoon aanhouden van “Wij zien het risico niet” en uiteindelijk wint de retoriek. Bedrijven die ransomware in hun systemen hadden, hebben de les van de hele kleine kansen wel geleerd. Een andere manier dan de risico-ontkenning is de acceptatie van het risico en daarmee ook het SoD’s conflict voor lief te nemen [link]. Dus alles houden zoals het is en misschien een extra verzekering afsluiten. Er is inderdaad een ondergrens aan het risico waar men nog iets mee moet. Dat klopt. De politieke manager beheerst daarom de vaardigheid om op het moment waarop het tapijt wordt opgelicht er een aantal extra risico’s onder te vegen. Hoe grotesk de situatie is merk je pas als je het vergelijkt met kruitvaten:

 “Wij hebben hier een kamer met kruitvaten. Maar wij steken de lontjes niet aan, want dat doen wij niet. Als anderen het lontje aansteken dan detecteren wij dat net voordat de boel af gaat”.

Slot

Je kunt je afvragen wie er werkelijk gewonnen heeft als de politiek binnen een bedrijf wint?

Het punt dat hier gemaakt wordt, is dat als de afslag naar ontduiking gemaakt wordt, je daarmee het enige goede argument naar een oplossing verspeelt. De oorzaak van functieconflicten is namelijk meestal onderbezetting. Door de afslag naar ontduiking te maken verspeel je de kans daar iets aan te veranderen en blijf je tevens met een onveranderde werkdruk zitten. Gek genoeg is dat vaak een geaccepteerde oplossing. Dit komt omdat dit het referentiekader is: “wij zijn in staat om met deze kritische rechten zorgvuldig om te gaan”. Dat mag zelfs ook nog waar zijn maar daarbij vergeten wij dat niet alleen wij deze rechten kunnen uitoefenen maar dat botnets en ransomware dat in onze naam ook kunnen doen. Daarnaast hoeft fraude niet op eigen initiatief te gebeuren, maar kan ook het gevolg zijn van afpersing. Uiteindelijk geldt altijd: te veel macht is voor niemand goed. Als de afslag naar Internal Audit wordt genomen en alle SoD conflicten met al hun gevolgen op tafel komen, dan staat elk conflict direct in verband met een economisch belang. Daar is wel oog voor. Dit betekent of uitbreiding van het aantal mensen, andere taakverdeling of automatisering om het probleem op te lossen. SoD conflicten zijn in dit geval het wisselgeld om een steeds uitgestelde automatisering wel te krijgen. Dat is een werkelijke oplossing en het is er ook een die in het licht staat en niet ondergronds is.

Over de auteur

Mark Deiss (CISSP) is een SAP autorisatie consultant die autorisatie systemen herbouwt en audits uitvoert. De genoemde voorbeelden komen allen uit praktijkervaringen.