‘Zoveel functiescheidingsconflicten in SAP – dat kan nooit’, en waarom is dat eigenlijk een risico?

Inleiding

In 2001 is door middel van onderzoek aangetoond dat de kwaliteit van de logische toegangsbeveiliging in SAP op dat moment voor veel organisaties van onvoldoende niveau is. Wij zullen die resultaten eerst kort herhalen. De aandacht voor de logische toegangsbeveiliging in SAP is door de introductie van de code-Tabaksblat en de Sarbanes-Oxley Act toegenomen. Organisaties worden nu door wet verplicht aan te tonen dat ze orde op zaken hebben gesteld. Daarnaast zijn ook migraties, het gebruik van tooling en het opbouwen van meer kennis voor ons aannames geweest om te verwachten dat er verbetering moet zijn opgetreden. Voor ons daarom aanleiding om het onderzoek van 2001 in 2006 te herhalen, op basis van achtentwintig audits en quick scans, uitgevoerd in 2005 en 2006 op het gebied van de logische toegangsbeveiliging in SAP. Daarbij hebben wij ons de volgende vragen gesteld:

• Zijn de resultaten op het gebied van de logische toegangsbeveiliging voor SAP verbeterd?
• Wat zijn de belangrijkste oorzaken, zijn onze tips opgevolgd? Op basis van onze praktijkervaring hebben wij namelijk in 2001 een aantal tips gegeven. Wij zullen deze tips kort de revue laten passeren.

Op basis van de uitkomsten van ons onderzoek in 2006 wordt door ons wederom een aantal praktische tips gegeven voor het gebruik van ondersteunende tooling en het definiëren van de functiescheidingsregels. Bij het geven van de ‘nieuwe’ tips baseren wij ons niet alleen op de resultaten van het onderzoek, maar ook op onze observaties in de praktijk tijdens onze advieswerkzaamheden.

De resultaten uit 2001

De resultaten van het onderzoek in 2001 naar de kwaliteit van de SAP-autorisaties (logische toegangsbeveiliging) laten zich als volgt samenvatten:

• De basisbeveiliging is niet in orde. Eenvoudige instellingen op het gebied van identificatie en authenticatie zijn niet geactiveerd. Er zijn veel gebruikers met ‘super’-rechten.
• Op het gebied van functiescheiding is het niveau slecht. De toegang tot kritieke technische en functionele transacties is niet eenduidig belegd. Ook combinaties van ongewenste transacties komen te veelvuldig voor.
• Organisaties hadden hun gebruikers- en autorisatiebeheer op redelijk voldoende niveau georganiseerd, al waren de documentatie en het beheer van de inactieve gebruikers weer ver onder de maat. De transparantie kan worden verbeterd.
• Organisaties hadden vaak voor een slecht beheersbare autorisatiestructuur gekozen, die met name was gebaseerd op ‘enkele rollen’ (of zoals dat toen heette ‘activiteitgroepen’).

In figuur 1 ziet u de resultaten uit 2001 per deelgebied van dat betreffende onderzoek. Deze figuur laat bijvoorbeeld zien dat bij zeventig procent het beheer van inactieve gebruikers onvoldoende plaatsvindt (rood), bij twintig procent wordt dit redelijk uitgevoerd (oranje) en slechts tien procent heeft het beheer van inactieve gebruikers onder controle.

Figuur 1. Bevindingen uit de praktijk – juni 2001.

De belangrijkste oorzaken van de bovengenoemde slechte resultaten waren volgens ons:

• De opzet en inrichting van de autorisaties vindt vaak te geïsoleerd door technisch beheerders plaats. Er is te weinig afstemming met de processpecialisten. Ook ontbreekt er vaak een procesgebaseerde risicoanalyse om te komen tot de eisen van de autorisaties.
• Het haastwerk waarmee autorisaties vaak in projecten zijn opgezet, veelal door onervaren of door te druk bezette personen in het project.
• Het belang van een goed werkend autorisatieconcept als maatregel van interne controle werd onderschat.
• De complexiteit van het autorisatieconcept in SAP, zowel in de opzet en inrichting van de autorisaties als op het gebied van goede rapportages. Een fout is snel gemaakt. Beide schrijvers van dit artikel hebben vaak ongelovige reacties gekregen naar aanleiding van de uitkomsten van hun onderzoeken.

In het algemeen kan worden gesteld dat er op het gebied van autorisaties weinig voldoendes werden gegeven. Of het is een ‘goed‘ of het is een ‘zware onvoldoende‘. Het is namelijk de attitude en de professionaliteit van de organisatie die bepalend is voor de kwaliteit van de autorisaties. Een beetje goed beveiligd bestaat dan niet.

Aandacht voor SAP-autorisaties opgekrikt door externe wetten en codes

Door de invoering van de code-Tabaksblat en de Sarbanes Oxley Act is het SAP-autorisatieconcept door veel organisaties flink onder de loep genomen. Dit omdat er vanuit deze wetgeving hogere eisen werden gesteld aan de transparantie en kwaliteit van de autorisaties, inzake de rapportage over functiescheidingen, maar ook voor wat betreft de effectiviteit van autorisaties als maatregel van interne controle.

De wetgeving eist dat de bestuurders aangeven ‘in control’ te zijn over hun processen. Met andere woorden, dat de maatregelen van interne controle over een periode effectief zijn geweest. Omdat één van die belangrijke typen maatregen van interne controle ‘de functiescheiding’ is, hebben veel ondernemingen de afgelopen jaren aandacht geschonken aan de autorisaties in de systemen. Functiescheiding als het scheiden van opeenvolgende taken en bevoegdheden in de waardekringloop om fraude te voorkomen. Door het realiseren van functiescheidingen in het systeem wordt het gewenste tegengestelde belang van functies verankerd in de systemen.

Daarnaast vormen autorisaties in het systeem naast een heel effectieve controle, vanwege het preventieve geautomatiseerde karakter, ook een heel efficiënte controle. Efficiënt in het licht van de ‘total costs of compliance’. Om aan te tonen dat internecontrolemaatregelen effectief zijn geweest over een bepaalde periode moet het management tests uitvoeren. De grootte van de steekproef, lees het aantal tests, is afhankelijk van het type en de periodiciteit van de controle. Een controle uitgevoerd door het systeem (zoals autorisaties) vereist veel minder testwerk. Om het systeem van interne controle zo effectief en efficiënt te maken is de applicatie steeds meer als middel centraal komen te staan om controles uit te oefenen. Waar organisaties vroeger maatregelen om SAP hadden geïmplementeerd, hebben zij duidelijk geïnvesteerd om steeds meer controlemaatregelen in SAP in te richten. Een trend die binnen KPMG wordt aangeduid als ‘controls transformation’. Controls transformation om uiteindelijk de ‘total costs of compliance’ te reduceren. Naast autorisaties zijn andere bekende voorbeelden van ‘application embedded controls’ specifieke configuraties, customizing op het gebied van toleranties, validaties, automatische boekingsgangen en verplichte velden.

Vanwege bovenstaande ontwikkelingen (1) de introductie van codes en wetten, die eisen dat de interne controle wordt verscherpt en (2) de wens om controles in de applicatie te verankeren, kan verwacht worden dat er tevens meer aandacht is geschonken aan logische toegangsbeveiliging. Omdat organisaties ook dienen te rapporteren over de autorisaties, zien wij een toenemend gebruik van tools. De zojuist geschetste ontwikkelingen zouden moeten resulteren in een positiever beeld over de logische toegangsbeveiliging in SAP.

Migraties en leereffecten

Een andere belangrijke ontwikkeling die zich de laatste vijf jaar heeft doorgezet, is het gebruik van ‘nieuwe’ SAP-specifieke functionaliteiten om autorisaties in te richten en te beheren. Zo is er nagenoeg niet één organisatie meer, die zonder ‘profile generator’ werkt. Eerlijkheidshalve moet gezegd worden, dat wij ze nog steeds tegenkomen, maar slechts heel af en toe. Ook maken steeds meer organisaties gebruik van het afleiden (‘deriven’) van de (samengestelde) rollen. Bij migraties naar nieuwe versies zijn vaak ook de autorisaties niet één op één overgenomen, maar hebben ze vaak een facelift gekregen. Met name omdat met het gebruik van de nieuwe tools ook efficiency in het beheer kan worden bereikt. En met autorisaties in SAP geldt des te sterker dat als je het één keer fout gedaan hebt en het daarna hebt mogen beheren, dat je dan weet wat je volgende keer anders zou willen doen. Misschien is de druk vanuit de codes en wetten voor veel beheerders dan ook een geschenk geweest.

De resultaten uit 2006

In juli 2006 zijn de resultaten van achtentwintig quick scans beoordeeld. In de populatie van onderzochte ondernemingen zitten hoofdzakelijk ondernemingen die ook zijn meegenomen in het onderzoek van juni 2001, daar de auteurs mede in het kader van ondersteuning jaarrekening deze onderzoeken uitvoeren. De ontwikkelingen op het gebied van de externe wetten en codes en die van de additionele functionaliteit in de nieuwe versies van SAP zouden een duidelijke verbetering moeten laten zien. Figuur 2 geeft de resultaten van dit onderzoek weer.

Figuur 2. Bevindingen uit de praktijk – augustus 2006.

Gelukkig, de eerste blik laat ons meer groen en oranje zien, maar rooskleurig is het zeker nog niet. Wij kunnen dan ook toch de volgende conclusies trekken:

• Er zijn nog steeds geen grijze gebieden. Organisaties scoren over alle punten of goed of slecht. In 2006 hebben meer organisaties beter gescoord. Er blijven echter organisaties tussen zitten, waarvan het niveau onvoldoende is.
• De basisbeveiliging is over het algemeen verbeterd, maar laat nog steeds te wensen over. Bij elf van de achtentwintig respondenten zien wij nog steeds een overmaat van ‘super’-gebruikers actief. Ook heeft bijna vijftig procent van de respondenten nog niet de juiste parameters ingericht en gebruikgemaakt van de tabel om zeer kritische transacties te blokkeren. Duidelijk verbeterd zijn de beveiliging van de systeemstatus en het beveiligen van de standaard-user-id’s.
• Op het gebied van de inrichting zien wij over de hele linie inderdaad de verbetering die wij verwachtten, al is nog steeds bij eenderde van de organisaties de toegang tot kritieke functionele transacties of combinaties van transacties onvoldoende. Bij ongeveer vijftig procent van de respondenten is de inrichting redelijk. Alleen bij tien procent van de respondenten, gelijk aan de score in 2001, is het goed op orde.
• Op het gebied van het beheer van de autorisaties zien wij over de hele linie een duidelijke verbetering. Hiervan zijn het ontstaan van competence centers en het gebruik van ondersteunende tools de belangrijkste oorzaken.

Opvolging tips 2001

In het artikel in 2001 hebben wij de lezer een aantal tips meegegeven. In het vervolg van dit artikel zullen wij onze tips nog eens kort doorlopen en kijken hoe de ondernemingen met deze aandachtspunten zijn omgegaan. In tabel 1 ziet u de trend in kolom 2, plus een korte verklaring in kolom 3. Het vervolg van deze paragraaf geeft een verdere toelichting hierop.

Tabel 1. De tips van 2001, trends en uitleg.

Tip 1. Quick Win Autorisatieprofielen voor beheerders

In veel van de onderzochte SAP-applicaties valt het op dat de beheerders niet standaard meer een SAP_ALL-profiel hebben. Ten opzichte van 2001 zijn er nu wel speciale autorisatierollen gebouwd voor beheerders, interne en externe consultants en auditors. Vaak hebben de beheerders nu zelfs geen mutatiebevoegdheid meer in het productiesysteem en hebben zij alleen weergavebevoegdheid in de applicatie (naast de bevoegdheid voor hun dagelijkse werkzaamheden). Met bijvoorbeeld de KPMG Security Explorer of andere tools is het mogelijk aan te tonen van welke transactiecodes een beheerder gebruik heeft gemaakt. Hierdoor vervalt over het algemeen al snel het argument van de beheerder dat hij alle bevoegdheden nodig heeft voor zijn dagelijkse werkzaamheden. Eventueel kan via de Security audit log worden getraceerd welke transactiecodes een bepaalde beheerder gedurende een bepaalde periode heeft gestart.

Tip 2. Verwijder superusers

Ten opzichte van 2001 is duidelijk waar te nemen dat het aantal SAP_ALL-gebruikers in het systeem is afgenomen. Eén van de belangrijkste redenen hiervoor is ook dat de bevoegdheden van de beheerders zijn ingeperkt. Daarnaast wordt het profiel SAP_ALL niet meer snel tijdelijk uitgegeven. In geval van nood is er vaak een Emergency SAP_ALL-gebruiker aanwezig die gebruikt kan worden en waar de activiteiten van worden gelogd. Moderne tools, zoals Virsa, ondersteunen het actief monitoren van gebruikers die tijdelijk alle bevoegdheden in het systeem hebben (SAP_ALL-bevoegdheid).

Tip 3. Gebruik de kennis van uw externe adviseur voor parameters en tabelwaarden

Bij veel ondernemingen zijn de parametersettings ten opzichte van 2001 geoptimaliseerd. Indien naar een nieuwe SAP-versie wordt gemigreerd, moet men er wel rekening mee houden dat er nieuwe parametersettings mogelijk zijn. Zo zijn er in SAP ECC 5.0 parameters geïntroduceerd waarmee de geldigheidsduur van paswoorden kan worden beïnvloed (een nieuw paswoord is vijf dagen geldig) of de hoeveelheid letters, getallen of speciale karakters die het paswoord minimaal moet bevatten.

Tip 4. Logging

In 2006 hebben de meeste ondernemingen nog steeds geen logging geactiveerd. Belangrijkste reden hiervoor is dat de meeste ondernemingen niet weten welke tabellen er gelogd moeten worden. Daarnaast staan er per default redelijk veel tabellen geactiveerd voor logging.

Tip 5. Test de profielen naast positief ook negatief

Het belang van negatief testen wordt nog vaak onderschat. De negatieve test heeft meestal als insteek om te testen of medewerkers geen toegang hebben tot bepaalde gedeelten van de organisatie. Een goede negatieve test moet echter ook de weergaveprofielen testen. Autorisatieobjecten die in weergaverollen mutatiebevoegdheid bevatten, moeten worden aangepast. Hierbij is het aan te raden om gebruik te maken van transactiecode SU24 om de waarden binnen de objecten voor de profiel generator aan te passen. In 2006 zien we nog steeds dat er redelijk veel negatieve fouten in rollen zitten. Vooral op het gebied van weergaveprofielen zien we dat de rollen vaak ook mutatiebevoegdheden bevatten. Deze rollen an sich werken prima, echter in combinatie met andere rollen kan dit tot gevolg hebben dat gebruikers te veel bevoegdheden krijgen. Zo kan een weergavebevoegdheid systeemoverschrijdend zijn en kunnen de updateprofielen plantspecifiek zijn. Indien een weergavebevoegdheid vervolgens ook mutatiebevoegdheid bevat dan kan door de combinatie van rollen de gebruiker systeemoverschrijdend muteren. De gebruiker krijgt immers de transactiecodebevoegdheid uit de mutatierol en de autorisatieobjectbevoegdheid uit de weergaverol.

Tip 6. Kies een evenwichtige structuur van autorisatieprofielen

In 2006 hebben wij gezien dat veel ondernemingen zijn afgestapt van de rolgebaseerde opzet en hebben gekozen voor een taakgebaseerde opzet (vaak wordt deze keuze gemaakt tijdens een migratietraject wanneer alle rollen toch moeten worden herzien of naar aanleiding van een rapportage van de interne of externe auditor over functievermenging). Belangrijk voordeel van een taakgebaseerde opzet is dat het een flexibele, onderhoudbare en controleerbare structuur is. Indien de taken verder inhoudelijk goed zijn gedefinieerd, kan men zelfs alle mogelijke functiescheidingen inrichten. Tevens geldt voor de evenwichtige autorisatiestructuur dat moet worden voorkomen dat transactiecodes uit de verschillende SAP-modules in een rol worden gestopt. Dit heeft immers een negatieve invloed op het afleiden van de rollen en het invullen van de organisatieniveaus.

Tip 7. Gebruik de autorisatiemogelijkheden zo beperkt mogelijk

Het SAP R/3-autorisatieconcept is zeer complex. Door veel autorisatiemogelijkheden te gebruiken zal een zeer complexe autorisatiestructuur ontstaan. Indien er te veel eisen aan het autorisatieconcept worden gesteld waardoor de autorisatiestructuur te complex wordt, dan dient een onderneming te onderzoeken of er ook andere controlemaatregelen zijn om het mogelijke risico te ondervangen. Hierbij kunnen bijvoorbeeld controlerapportages worden ingezet. Geconstateerd is dat de autorisatiespecialist in projecten beter gepositioneerd is, en dat er kritischer wordt nagedacht over de opzet van de autorisaties.

Tip 8. Combineer een top-down methodiek met een bottom-up methodiek

Met de bottom-up methodiek wordt aan de hand van de gebruikte functionaliteit in SAP een transactietakenmatrix gedefinieerd. De taken die worden gedefinieerd, dienen alleen die transactiecodes te bevatten waarmee een specifieke taak kan worden uitgevoerd. Daarnaast is het belangrijk om te voorkomen dat er functiescheidingen in een taak voorkomen. Op taakniveau kan vervolgens de business impact worden gedefinieerd. Toekenning van taken met een hoge business impact aan gebruikers kan alleen na expliciete toestemming van de verantwoordelijke business process owner. Daarnaast is het mogelijk op taakniveau functiescheidingsconflicten te definiëren.

Binnen de top-down approach worden de businessfuncties gedefinieerd. Hierbij worden de taken aan de hand van workshops en interviews aan functies toegekend. Door de functiescheidingsanalyse op taakniveau is het direct mogelijk om de blueprintfase vast te stellen of er in functies conflicten voorkomen, waarna het mogelijk is direct compenserende maatregelen te definiëren en te implementeren.

In de praktijk zien wij dat redelijk veel ondernemingen reeds gebruikmaken van een taakgebaseerd autorisatieconcept waarbij de taken in functies worden gegroepeerd door middel van verzamelrollen. Ook worden op basis van een procesgebaseerde risicoanalyse de top-down eisen aan de autorisaties gedefinieerd. Nadeel hierbij is dat het flexibele gebruikersmenu niet meer netjes wordt opgebouwd door de SAP-applicatie.

Tip 9. Isoleer kritische transacties in ‘dedicated’ profielen

Uit de resultaten van 2006 blijkt dat de meeste ondernemingen de kritische transactiecodes in aparte profielen hebben opgenomen. Belangrijkste reden hiervoor is ook dat ondernemingen zijn overgestapt van een rolgebaseerde opzet naar een taakgebaseerde opzet. Hierdoor krijgt een gebruiker die een bepaalde rol krijgt gekoppeld, niet meer automatisch toegang tot de technische transactiecodes. Vooral het aantal gebruikers die toegang hebben tot het direct muteren van tabellen is afgenomen. Tevens zien wij in 2006 dat ook de bevoegdheid voor het direct opstarten van ABAP-programma’s vrijwel niet meer aan eindgebruikers wordt gegeven. In plaats hiervan worden maatwerktransactiecodes ontwikkeld die via de normale weg aan rollen worden gekoppeld.

Tip 10. Kies een heldere naamgeving

Bij de meeste onderzochte ondernemingen was uit de definitie van de rol te identificeren wat de inhoud van de rol ongeveer was. In de naamgeving van de rollen is meestal opgenomen voor welke module de rol is gemaakt en wat voor type bevoegdheid de rol bevat. Hierbij wordt vaak onderscheid gemaakt tussen weergave, rapportages en stamgegevens. Tevens valt uit de resultaten van 2006 op dat in de nieuwere versies van SAP (4.7, 5.0) vaak de profielnaam niet meer wordt aangepast. Nadeel hiervan is dat er minder mogelijkheden zijn om te zoeken in tabellen (minder tabellen om goed in te kunnen zoeken).

Tip 11. Beveilig ook het maatwerk

Uit de resultaten van 2006 blijkt dat er meer en meer aandacht wordt geschonken aan het beveiligen van maatwerk. De toegang tot maatwerk wordt steeds vaker afgeschermd door het aanmaken van nieuwe maatwerktransactiecodes, waardoor het eenvoudiger is om alleen aan een beperkt aantal gebruikers toegang te verschaffen tot het maatwerk. Daarnaast zien wij meer geprogrammeerde controles binnen het maatwerk. Dit geldt echter meestal alleen voor maatwerk waarmee gegevens kunnen worden aangelegd of worden gewijzigd. Binnen maatwerkrapportages, queries of COPA-rapportages treffen wij zelden geprogrammeerde controles aan.

Tip 12. Beheer inactieve gebruikers

In 2006 valt het op dat ondernemingen hun inactieve gebruikers goed beheren. De meeste ondernemingen hebben strikte procedures voor het beheren van hun inactieve gebruikers, waarbij na zestig dagen gebruikers worden geblokkeerd en waarbij na negentig dagen de gebruikers uit het systeem worden verwijderd. Een belangrijke reden hiervoor is enerzijds beveiliging, daar inactieve gebruikers niet misbruikt kunnen worden. Daarnaast kan het verwijderen van inactieve gebruikers ook een kostenbesparing opleveren, daar er minder aan licentiekosten hoeft te worden betaald. Tevens zien wij dat veel meer ondernemingen per gebruiker het type licentie aangeven. Het licentietype voor een gebruiker die alleen weergavebevoegdheid heeft of die alleen kan goedkeuren, kost minder dan een gebruiker die ook inkooporders en verkooporders moeten invoeren.

Tip 13. Gebruik en kennis van de tabellen en CATT

Met CATT of E-CATT kunnen in een korte periode veel rollen worden aangepast of worden aangemaakt met behulp van de profiel generator. Het gebruik van tabellen kan dienen om de kwaliteit van de inrichting te beoordelen. Zo kan met behulp van tabel AGR_1251 snel worden gecontroleerd of weergaverollen ook alleen weergavebevoegdheid bevatten op autorisatieobjectniveau. Dit is een controle die een onderneming eigenlijk periodiek zou moeten uitvoeren teneinde het kwaliteitsniveau van de autorisatie-inrichting te verhogen. In 2006 zien wij een toenemend aantal ondernemingen die gebruikmaken van CATT of E-CATT voor het aanleggen van rollen of gebruikers. Veel beheerders kennen echter de belangrijkste autorisatietabellen binnen SAP nog niet (UST-, AGR- en USR-tabellen).

Tip 14. Implementeer een goede impactanalyse op de beveiligingsaspecten als complexe beheerprocedures

Niet in scope van de onderzoeken in 2005 en 2006.

Tip 15. Gebruik van ondersteunende tools

In 2006 zien wij een duidelijk toename van ondernemingen die een geautomatiseerde tool gebruiken of er duidelijk interesse in hebben. Op het gebruik en het implementatietraject van dit soort tools gaan wij in het vervolg van dit artikel nog verder in.

Tip 16. Betrek uw eigen beheerders bij de ontwikkeling

In 2006 zijn wij bij redelijk veel ondernemingen competence centers ten behoeve van autorisatie tegengekomen. In deze competence centers zitten vaak meerdere fulltime beheerders die gespecialiseerde kennis hebben van het SAP R/3-autorisatieconcept. Deze beheerders zijn vaak nauw betrokken bij de inrichting of de uitrol van het SAP R/3-autorisatieconcept.

Tip 17. Genereer uw documentatie

Bij de meeste onderzochte ondernemingen in 2006 was er documentatie aanwezig maar was deze verouderd. Een aantal onderzochte ondernemingen had queries in SAP, SAP BW of MS Access gebouwd voor de documentatie van het autorisatieconcept. Veelal wordt direct naar SAP verwezen waar de documentatie uit kan worden gehaald.

De uitdagingen van nu

Wij hebben absoluut een aantal verbeteringen kunnen constateren. Maar zeker niet bij alle organisaties. Daarnaast zien wij dat organisaties op een aantal gebieden nog steeds problemen ondervinden. Deze observaties hebben wij niet alleen opgedaan gedurende onze auditwerkzaamheden, maar ook tijdens ons advieswerk. Daarnaast hebben wij bijzondere audits uitgevoerd op het gebruik en de inrichting van ondersteunde SAP security tools, zoals Virsa, Approva, SecurInfo en CSI.

Over de volgende onderwerpen geven wij u graag nog enkele praktische adviezen:

• Het relateren van de SAP-autorisaties met de HR-organisatorische posities is vaak onmogelijk. Vaak is de personeelsafdeling niet betrokken bij de inrichting van de autorisaties. En daarnaast worden de rollen vaak te gemakkelijk gealloceerd aan gebruikers. Een verschijnsel dat wij ‘splitted roles’ noemen, treedt dan op. Dit verschijnsel heeft een negatieve invloed op het resultaat van standaardisatie- en harmonisatie-inspanningen. Zie tip A.
• Het selecteren van een ondersteunende tool vindt vaak niet vanuit een bredere visie plaats. Ook is te weinig rekening gehouden met de complexiteit van het gebruik. Zie tip B.
• Het nemen van beslissingen over de functiescheidingsconflicten blijkt een kunst op zich. Poolse landdagen zijn er vaak nodig om te komen tot de functiescheidingsmatrices. De hele wereld praat mee. En zodra ze er zijn, worden ze na elke scan weer in twijfel getrokken. ‘Dat kan nooit!‘ is een uitspraak die wij vaak gehoord hebben na het doen van onze onderzoeken. Zie tip C.
• De uitspraak ‘Dat kan nooit!’ kan een gevolg zijn van een foutieve inrichting van de ondersteunende tools. De technische inrichting van de tool is namelijk complex. Zie tip D.

Tip A. Steek net zoveel effort (misschien zelfs meer) in het voorkomen van ‘splitted roles’ als in het voorkomen van functiescheidingen. Ken autorisaties eenduidig toe.

Een veelvoorkomende fout bij de allocatie van rollen aan gebruikers is dat men alleen let op de beperking van de functiescheidingen. Het lijkt soms wel een sport om zoveel mogelijk (samengestelde) rollen te koppelen aan eindgebruikers totdat de grenzen van de functiescheidingen zijn genaderd (of zelfs van de user buffer). Dit is een volkomen verkeerd uitgangspunt. Zeker waar het gaat om ook de transparantie van het autorisatieconcept. Bij deze insteek zullen de SAP-autorisaties hoogstwaarschijnlijk niet overeenkomen met wat de daadwerkelijke taken en verantwoordelijkheden van de natuurlijke personen in de organisatie zijn, zoals vastgelegd in de functiebeschrijvingen op de personeelsafdeling.

Wat is een ‘splitted role’?

Stelt u zich voor dat in een inkooprol twee taken zitten (naast allerlei weergaveactiviteiten):

1. opvoeren contracten;
2. afroepen orders.

Als u nu aan één persoon deze rol geeft, dan kan deze persoon beide taken uitvoeren in de organisatie en daarvoor dan ook op schrift de taken en verantwoordelijkheden hebben. U heeft een ‘splitted role’ gecreëerd wanneer aan twee natuurlijke personen de inkooprol wordt toegekend, waarbij de ene gebruiker alleen de contracten opvoert en de ander alleen de order afroept. Dit fenomeen is uitermate nadelig voor de transparantie van het concept.

Daar waar u eenduidiger bent in het toekennen van rollen zult u ook minder problemen hebben met functiescheidingen. Begrijpelijk, omdat de units door het accepteren van ‘splitted roles’ minder worden gedwongen het standaardbedrijfsproces te implementeren en hierdoor ook minder worden gedwongen om de eigen bedrijfsprocessen aan te passen.

Om ‘splitted roles’ te voorkomen, en dus echt standaardisatie te realiseren, zult u taken opnieuw moeten toekennen en medewerkers competent moeten maken (trainen) in de nieuwe activiteiten. Indien u dit bereikt is de link tussen SAP-autorisaties en de HR-functiebeschrijvingen transparant, wat een goede basis biedt voor performance management.

Een truc om achter het bestaan van ‘splitted roles’ te komen is te analyseren welke gebruikers van hun bevoegdheden geen gebruik hebben gemaakt gedurende de laatste drie maanden.

Wij zien veel organisaties met ‘splitted roles’, daar waar de uitrol van SAP niet voldoende gericht was op de organisatorische (menselijke) aspecten. De organisaties geven toe dan minder resultaat uit de standaardisatieactiviteiten te halen dan verwacht.

Tip B. Verdiep u en selecteer een ondersteunende tool op basis van een gedegen detailonderzoek. Het verschil zit hem in de details.

Tijdens de uitvoering van de toegangsbeveiligingsonderzoeken bleek dat veel ondernemingen geautomatiseerde tooling voor het beoordelen van functiescheidingsconflicten aan het implementeren zijn, of reeds gebruiken. Voor het efficiënt analyseren van functiescheidingen en het rapporteren over de autorisaties zijn tools eigenlijk een must. In de markt komen wij de volgende shortlist aan tools veelvuldig tegen voor de ondersteuning van het implementeren, beoordelen en continu monitoren van toegang in SAP. Dit type tools vindt u terug onder namen als ‘SAP Security Tools’ of ‘Compliance Management Software’ of ‘Governance, Risk and Assurance Platforms’. Let op! Na even googelen zult u zien dat het aanbod wereldwijd nog veel omvangrijker is. Enkele voorbeelden van tools, zonder volledig te willen zijn, worden in het vervolg kort toegelicht. Dit zijn de tools die wij het meest op de Nederlandse markt tegenkomen.

Virsa Compliance toolset

Een zeer uitgebreide toolset op het gebied van SAP Beveiliging. En sinds kort onderdeel van SAP. Sterke punten zijn de simuleringsfunctionaliteit en het detail van de beveiligingsregels. Daarnaast is ook de functiescheidingscheck tijdens realisatie een sterke functionaliteit. Een ander voordeel is het feit dat de tool nest in SAP en daardoor real-time is. Nadeel is dat de initiële inrichting van de regels complex en foutgevoelig is, dus echt expertwerk. (www.virsa.com)

Approva Bizrights

Een zeer sterke analysetool op het gebied van SAP-beveiliging. Ook is dit platform al ver op het gebied van business process monitoring op basis van SAP-data-extracten. Daarnaast kan deze tool cross-applicatie (zelfs niet SAP) functiescheidingsanalyses uitvoeren. De graphical user interface is mooi. De tool nest echter niet in SAP, is echt weggelegd voor de grotere complexere organisaties en ook het configureren van de regels is complex. (www.approva.net)

CSI Authorization auditor

Dit product van Nederlandse bodem blijft na jaren en ook met de nieuwe versies een zeer goed product. CSI AA is gewoon erg sterk in het doen van analyses. Daarnaast is het maken van de regels eenvoudiger dan bij Virsa en Approva. Zeer sterk en nog steeds daardoor als audit-tool onderscheiden (Virsa en Approva komen hiermee in nieuwere versies) is de functionaliteit van de ‘Varianten’. Zo kunnen de regels voor ranges van company codes gerund worden en hoeven niet per company code de regels te worden gedefinieerd en te worden gestart. De tool nest niet in SAP, en heeft soms moeite met heel grote omgevingen. De tool is meer geschikt als audit- en reporting-tool, dan dat zij het dagelijks beheer goed ondersteunt. (www.csi4sap.com)

SecurInfo

Een tool die buiten SAP draait, maar volledig met SAP geïntegreerd kan worden. In deze tool kunnen de autorisatierollen worden gedefinieerd en worden ingericht. Vervolgens kan met een risicoanalyse worden gecontroleerd of er, aan de hand van voorgedefinieerde regels, functiescheidingsconflicten in de rol zitten. Ook tijdens de toekenning aan de eindgebruiker wordt deze controle uitgevoerd. Indien via een controle conflicten zijn gedefinieerd, kan via workflow goedkeuring worden gevraagd aan de business process owner of aan de betreffende verantwoordelijke manager. Deze manager kan de conflicten alleen accepteren door een mitigerende controle te koppelen aan het conflict. Hierdoor wordt het eigenaarschap bij de business gelegd. Indien vervolgens ook de security manager akkoord is met de mitigerende controle kan de gebruiker worden goedgekeurd en via deze tool in SAP worden aangelegd. (www.securinfo.com)

Synaxion for SAP

Is een nieuw product op de markt op het gebied van SAP en is ook van Nederlandse bodem. Synaxion is al langer een erkend product op het gebied van data-analyse en performance reporting. De tool kan naast allerlei analyses op het gebied van autorisaties ook allerlei voorgedefinieerde analyses maken op het gebied van business controls (zoals openstaande facturen, ongeautoriseerde prijswijzigingen, etc.). Sterk aan de tool zijn de rapportagemogelijkheden. Zo kunt u eenvoudig de units ten opzichte van elkaar benchmarken, of het verloop van de functiescheidingen checken. Ook is deze tool in staat te rapporteren welke personen hoe vaak hun autorisaties gebruikt hebben. En of functiescheidingsconflicten ook echt doorbroken zijn. Dit is ook een functionaliteit die in de nieuwe CSI AA wordt aangeboden. Het inregelen van de regels is echter complex en vindt in de code plaats. (www.synaxion.nl)

Zelfontwikkelde BW-rapportages

Binnen een aantal door ons onderzochte ondernemingen wordt gebruikgemaakt van BW om rapportages over autorisaties en functiescheidingen te maken. Nadeel van dit soort rapportages is dat ze over het algemeen erg veel output genereren, waardoor de bruikbaarheid van de documentatie erg beperkt is. Op het niveau van functiescheidingsconflicten worden vaak rapportages gedraaid op het niveau van conflicterende functies. Hierbij worden vaak minder kritische functies over het hoofd gezien en niet in de uiteindelijke rapportages meegenomen, waardoor het aantal conflicten in het systeem vaak veel groter is dan daadwerkelijk gerapporteerd.

Zelfontwikkelde Excel of MS Access tooling

Net als bij de BW-rapportages kan er gebruik worden gemaakt van Excel of MS Access om rapportages te maken over het SAP R/3-autorisatieconcept.

De bovenstaande tools lijken in eerste instantie op elkaar, ze doen allemaal een goede scan, maar in de details zijn ze echt verschillend. Organisaties moeten daarom goed hun wensen en behoeften bepalen voordat zij een tool selecteren. De standaard-requirementlijst van KPMG’s SAP Advisory telt meer dan 150 criteria. Ook het kostenplaatje loopt tussen de tools zeer sterk uiteen.

Daarnaast zijn andere relevante aspecten van vergelijking van de tools:

1. Het feit of de tool al dan niet deel uitmaakt van een breder Compliance Management Software Platform.
2. De ondersteuning die de tool(set) biedt bij het ontwerpen, inrichten, testen, documenteren, monitoren en auditen van de autorisaties. Deze functionaliteiten kunnen gecombineerd voorkomen in de tool, maar de tool kan zich ook op een of enkele daarvan richten.
3. Bijzondere functionaliteiten:
   • simuleren van functiescheidingsconflicten vanuit een bouwomgeving op gebruikers, composite- en single role-niveau;
   • uitsluiten van gebruikers in analyses bij aanwezigheid van compenserende maatregelen, waarvan de effectiviteit via workflow wordt getoetst;
   • classificatie van regels, bijvoorbeeld naar het kritieke gehalte zoals ‘high’, ‘medium’ en ‘low’;
   • automatisch genereren van een risico alert bij verboden combinaties;
   • geïntegreerde herstelplanning (remediation). Remediation van de risico’s kan op verschillende manieren plaatsvinden. De activiteiten op dit gebied dienen te kunnen worden gedefinieerd en bewaakt:
     • implementeren van een compenserende maatregel, die in de tool dient te kunnen worden beschreven en qua effectiviteit te worden bewaakt;
     • het ontkoppelen van autorisatierollen (een gebruiker heeft twee functies), met als gevolg dat de gebruiker op de volgende lijst niet meer voorkomt;
     • het aanpassen van autorisatierollen (een functie bevat een conflict), waardoor groepen van gebruikers afvallen;
     • het aanpassen van de autorisatieregels;
   • scenario’s/varianten bij autorisatiescanning (lijsten van regels afspelen voor meerdere organisatie-eenheden);
   • Change Tracking op de beveiligingsregels, waardoor u achteraf precies kunt vaststellen welke wijzigingen, wanneer en door wie hebben plaatsgevonden op de beveiligingsregels;
   • continue auditing of monitoring, waardoor de tool in staat is bijvoorbeeld de beheerder via sms of mail te alarmeren indien SAP_ALL gekoppeld wordt, of zodra heel kritische transacties worden opgestart;
   • functiescheidingschecks bij de realisatie, waardoor het systeem al bij de realisatie van enkele en samengestelde rollen waarschuwt zodra transacties worden gecombineerd.
4. De kwaliteit van de tabelextractie, en daarmee direct samenhangend de kwaliteit van de analysemogelijkheden en de rapportage.
5. De benodigde infrastructuur en de kwaliteit en snelheid van de data-extractie (indien niet real-time).
6. De ‘levensvatbaarheid’ en de omvang van de leverancier.

Tip C. Het opzetten van de functiescheidingsmatrix

Proceseigenaren dienen actief betrokken te worden in het opzetten van de functiescheidingsregels. Het meest praktische hulpmiddel in de praktijk is het opzetten van een matrix, waarin u zowel in de eerste kolom als in de rij de rollen zet. Daar waar de rollen conflicteren zijn, zet u kruisjes. Een vereenvoudigd voorbeeld van een dergelijke (niet volledig ingevulde) matrix staat in figuur 3 weergegeven.

Figuur 3. Vereenvoudigd voorbeeld van een functiescheidingsmatrix. [Klik hier voor grotere afbeelding]

Tijdens workshops met business process owners en het verantwoordelijke management kunnen de functiescheidingsregels worden gedefinieerd. U doet dit tot op het niveau van de SAP-transacties. Anders kunt u niet de link naar de rollen maken. Over het algemeen is dit een behoorlijk tijdsintensieve activiteit waar het management verantwoordelijk voor is. Om van dit soort workshops een succes te maken is het van groot belang ze op te splitsen naar processtreams (Purchase-to-Payment, Order-to-Cash, Hire-to-Retire, Finance-to-Management) en vooraf matrices met conflicterende activiteiten voor te bereiden met een kleine groep van specialisten.

Nadat de functiescheidingsmatrix duidelijk is opgesteld, dienen de conflicten verder te worden uitgewerkt. Per conflict dient duidelijk en in ‘business’-termen te worden gedocumenteerd wat exact het bijbehorende risico is. Hiermee kan worden voorkomen dat business process owners of lokale managers achteraf gaan vragen waarom iets een risico is. Het risico moet hierbij ook duidelijk doch eenvoudig worden beschreven en onderdeel zijn van het validatieproces. Voorbeelden zijn:

• Indien een persoon in staat is de recepturen aan te passen en de gereedmelding van producten te verzorgen, dan is hij in staat het productieresultaat te beïnvloeden.
• Indien een persoon in staat is prijzen aan te passen en orders in te voeren, dan kan hij om zijn klanten tegemoet te komen, de geldende richtlijnen omzeilen.

Ten aanzien van de matrix moet worden voorkomen dat men denkt dat de matrix onvolledig is, of dat de kruisjes een resultaat van willekeur zijn. Daarom moeten de organisatiespecifieke uitgangspunten achter de kruisjes in de matrix eenduidig worden vastgelegd, worden gecommuniceerd en ook worden gevalideerd. U moet eigenlijk met deze stap beginnen.

Het eigenaarschap van de functiescheidingsmatrix dient hoog in de organisatie te worden belegd. Zodra dat is gebeurd, dient de eigenaar te communiceren naar eenieder, dat de matrix geen richtlijn is, maar een wet.

Zorg ervoor dat gecommuniceerd wordt door de eigenaar van de matrix (vaak de concern controller of hoofd financiën) dat de matrix een wet is.

Het kan voorkomen dat in sommige gevallen voor sommige conflicten een uitzondering geldt, indien er compenserende maatregelen zijn geïmplementeerd. Voor die conflicten die in het systeem zijn toegestaan, moet worden gedocumenteerd welke mitigerende maatregelen dienen te worden geïmplementeerd om het risico te beperken. Hierbij dient duidelijk te worden gemaakt dat het lokale management van de onderneming verantwoordelijk is voor de implementatie en de uitvoer van de mitigerende maatregelen en dat periodiek dient te worden getoetst of de maatregel ook daadwerkelijk wordt uitgevoerd. In goede functiescheidingsmatrices staat met kleuren of indicatoren weergegeven, of er voor een functiescheidingsconflict compenserende maatregelen moeten worden geïmplementeerd en zo ja, voor welke functiescheidingsconflicten dat geldt. Het monitoren of compenserende maatregelen hebben gewerkt, dient te worden ingebed in de organisatie

Vaak komen functiescheidingsconflicten voor in relatief kleine business units. Uit die business units kan bijvoorbeeld de reactie komen dat de afdelingen te klein zijn om functiescheiding te waarborgen. Een mogelijke reactie van het corporate management zou dan kunnen zijn om de werkzaamheden te verplaatsen naar groep- of clusterniveau of gebruik te gaan maken van het shared service center. Let op! Deze reactie kan confronterend zijn en moet dus met enige omzichtigheid worden gebracht.

Tip D. Technische inrichting van de tool

Met de technische inrichting van de tool wordt bedoeld het inregelen van de beveiligingsregels. Dit zijn de auditregels waarmee de gebruikers worden geïdentificeerd die een functiescheidingsconflict in de aan hen toegekende bevoegdheden hebben zitten. U moet om tot deze regels te komen een aantal inrichtingskeuzen maken. Hier volgen enkele tips die u helpen de juiste keuzen te maken.

Keuze 1. Scope van transacties

Bij het inrichten van de regels kunnen twee verschillende keuzen worden gemaakt:

1. inrichten alleen op transactiecodes op basis van de organisatiespecifieke transaction process master list (TPML);
2. inrichten op alle transactiecodes waarmee het mogelijk is de activiteit uit te voeren, op basis van alle transacties die in SAP zitten.

De eerste methode lijkt de meest eenvoudige methode, de tweede methode is de meest complete. In het eerste geval is het immers mogelijk dat bepaalde conflicten niet gerapporteerd worden doordat één van de mogelijke transactiecodes niet is meegenomen in het auditfilter, maar mogelijk via wijzigingsbeheer toch in de rollen terecht is gekomen. Dit kan tot vervelende verrassingen leiden tijdens de jaarrekeningcontrole (minder in control dan gedacht). Daarnaast komt het voor dat er niet een unieke transactiecode is om een activiteit uit te voeren. Indien we naar het aanmaken/wijzigen van bijvoorbeeld een inkooporder kijken, dan zijn er in SAP de volgende transactiecodes te onderkennen: ME21, ME22, ME21N, ME22N, MEPO (afhankelijk van de SAP-versie). Daarbij kan het voorkomen dat de onderneming zelf ook nog een aantal transactiecodevarianten heeft ontwikkeld voor het invoeren van een inkooporder. Deze dienen ook in de auditfilters te worden opgenomen. Wij adviseren in de regel om de tweede optie te kiezen; dat betekent bij de initiële inrichting meer werk, maar maakt het onderhoud van de regels beperkt.

Keuze 2. De inrichting op autorisatieobjectniveau

Indien een onderneming op de output van zo’n tool wil kunnen steunen, dan is het heel belangrijk dat de in deze tools opgenomen audit queries adequaat zijn.

Het technisch instellen van de regels in de tool is echt expertwerk. Daarbij dient u een combinatie aan te wenden van experts van uw SAP-systeem, de toolexpert en de SAP-security expert. Wij kunnen op basis van onze laatste audits concluderen, dat veel regels in de tool vaak onjuistheden bevatten op objectniveau en onvoldoende rekening houden met de systeemspecifieke eigenschappen. Onjuiste regels resulteren in ‘false positives’ en/of ‘false negatives’. De geautomatiseerde tool zal namelijk rapporteren over gebruikers die én de combinatie van conflicterende transactiecodes hebben én de relevante autorisatieobjecten om de transactiecodes binnen het conflict volledig te kunnen uitvoeren. Het is hierbij dus belangrijk dat de beveiligingsregels de juiste autorisatieobjecten met de juiste waarden bevatten:

• te veel objecten: de kans is aanwezig dat niet alle gebruikers die de activiteit daadwerkelijk kunnen uitvoeren ook worden gerapporteerd (false positives);
• te weinig objecten: de kans is aanwezig dat gebruikers worden gerapporteerd die de activiteit niet kunnen uitvoeren (negatives).

Het bepalen van het gebruik van autorisatieobjecten is een activiteit die specialistische kennis van het SAP R/3-autorisatieconcept, de autorisatie-inrichting, de configuratie van het systeem en het gebruik van verplichte velden in masterdata vereist. Quick wins kunnen worden behaald in het beoordelen van de optionele autorisatieobjecten in SAP. De optionele autorisatieobjecten zijn objecten die gecontroleerd worden indien bepaalde customizing settings of bepaalde velden in stamgegevens zijn onderhouden. Een eenvoudig voorbeeld is transactiecode FB01 in SAP. In tabel 2 staan de autorisatieobjecten weergegeven die volgens tabel USOBT door deze transactiecode worden gecontroleerd. Tevens staan de belangrijkste kenmerken opgenomen van deze objecten.

Tabel 2. In SAP voorgestelde autorisatieobjecten voor transactiecode FB01. [Klik hier voor grotere afbeelding]

De meeste ondernemingen onderhouden geen bevoegdheidsgroepen en hebben geen business areas ingericht. Dit heeft tot gevolg dat een audit query voor transactiecode FB01 alleen op autorisatieobject F_BKPF_BUK en F_BKPF_KOA zal controleren.

Een andere belangrijke vraag in de technische realisatie is de vraag hoe de tool omgaat met meerdere veldwaarden in een object. Indien de tool meerdere waarden in een object behandelt met een AND-Logic, dan houdt dat in dat een gebruiker alle waarden in het object moet hebben voordat hij gerapporteerd zal worden. Indien via een audit query specifiek gekeken wordt naar waarde 01 en 02 en 03, dan zal een gebruiker die alleen waarde 01 heeft dus al niet meer worden gerapporteerd. Een tool die de OR-Logic gebruikt voor veldwaarden zal deze gebruiker wel rapporteren.

Keuze 3: Gebruik van default of organisatiespecifieke regels

De meeste van de aangeboden tools bevatten al voorgedefinieerde regels. De standaard door de toolleverancier aangeboden regels bevatten over het algemeen een goed technisch startpunt, echter niet meer dan dat. Deze content is immers niet in overeenstemming met de door het management bepaalde gewenste functiescheiding en is niet in overeenstemming met de configuratie van het R/3-systeem en de behoefte van de onderneming.

Samenvattend

Vergeleken met de resultaten van 2001 is de kwaliteit van de inrichting van het autorisatieconcept over de hele linie verbeterd. Echter, het blijft gelden dat een grijs gebied niet bestaat. Organisaties doen het of goed of slecht. Er zijn dus meer organisaties aangetroffen waar het beter gaat. Belangrijkste oorzaken hiervan zijn volgens ons de invoering van wetgevingen zoals SOX en Tabaksblat, het ontstaan van SAP-autorisatie competence centers en het gebruik van ‘nieuwe’ functionaliteit zoals afgeleide rollen (activity groups), object inheritance en samengestelde rollen. Als reactie op de wetgeving zijn veel ondernemingen intensief aan de slag gegaan met het SAP R/3-autorisatieconcept door middel van een herimplementatie van het SAP R/3-autorisatieconcept of de ingebruikname van Compliance Management Software, lees ondersteunende tooling. Veel ondernemingen zijn op dit moment zeer geïnteresseerd in ondersteunende tooling voor SAP R/3-autorisaties. Zij maken daarin helaas vaak niet een weloverwogen keuze en hebben moeite de tools goed in te regelen. Niet alleen vanuit de techniek. Het opstellen, implementeren en communiceren van de functiescheidingsmatrix die vaak de basis is van de regels in de tool blijkt een nachtmerrie te zijn binnen veel organisaties. Oorzaken hiervan zijn vaak het niet bij het project betrekken van de proceseigenaren, het vergeten van het benoemen van de uitgangspunten, het niet duidelijk maken in businesstermen waarom een conflict een risico is en het niet hoog genoeg beleggen van het eigenaarschap in de organisatie. De resultaten van de scans worden dan continu ter discussie gesteld.

Een andere observatie op basis van onze advieswerkzaamheden is dat de allocatie van rollen vaak niet eenduidig gebeurt en dat daardoor bepaalde verwachte standaardisatieresultaten niet gerealiseerd worden. Zie onze opmerkingen over ‘splitted roles’.

De toekomst in SAP op het gebied van beveiliging zal nog uitdagender worden. Het concept van de ‘Service Oriented Architecture’ of ‘Enterprise Service Architecture’ dat SAP zal kenmerken, zal infrastructuurbeveiliging en applicatiebeveiliging meer integreren. Ook zal de totale logische toegangsbeveiliging over meerdere applicaties (intern/extern) dienen te worden opgezet, geïmplementeerd en bewaakt. Dus zeker een kans dat wij rond 2010 het onderzoek weer herhalen.