SAP Basis Security – de kroonjuwelen te grabbel

Inleiding

In de afgelopen decennia werden binnen de audit- en IT-beveiligingswereld functiescheiding en security in één woord genoemd, alsof ze dezelfde betekenis hebben. Vele SAP-professionals zien SAP-security als een proces, dat gaat over authenticatie, rollen en autorisatieprofielen. Gebruikers moeten alleen toegang krijgen tot die functies in het systeem welke sec behoren tot zijn of haar taken en verantwoordelijkheden, is het adagium. Binnen de controletechnische functiescheiding mogen personen geen combinatie van beschikkende, registrerende, bewarende of controlerende functies uitvoeren. Met deze controle moet worden voorkomen dat medewerkers de organisatie kunnen benadelen en dat registraties onbetrouwbaar zijn. Diverse organisaties hebben veel energie gestoken in hun autorisatieconcept, mede vanwege de Sarbanes-Oxley Act ([Vree06]). Hoewel het doorvoeren van functiescheiding en een ‘schoon’ autorisatieconcept randvoorwaardelijk zijn voor een ‘veilig’ SAP-systeem betekent dit niet, dat deze maatregelen voldoende zijn om bijvoorbeeld kwetsbaarheden in de onderbelichte (technische) aspecten zoals de SAP-gateway, password hashes of standaard geactiveerde internetservices mee af te dekken.

Een SAP-systeem wordt steeds complexer, mede door de toename van SAP-functionaliteiten en -producten. Organisaties implementeren steeds meer SAP-systemen naast het kerncomponent ECC en creëren onbewust een uitbreiding van de toegangspaden naar belangrijke gegevens: de kroonjuwelen van de organisatie. Daarnaast omarmt SAP technologieën zoals Java, HTTP, SOAP, XML en open SQL. Dit heeft geresulteerd in de adoptie van alle inherente beveiligingsrisico’s binnen SAP die met deze technologieën gepaard gaan. Een kwetsbaarheid in slechts één van de SAP-systemen kan een complete compromittatie betekenen van het IT-landschap ([Edmo11]). Problemen die de afgelopen jaren binnen SAP aan het licht zijn gekomen, moeten gezien de integriteit, continuïteit en vooral de betrouwbaarheid van SAP direct door organisaties worden verholpen. Hierbij moet vooral worden gedacht aan de technische componenten zoals de SAP-gateway, SAP Application Server, SAP Message Server, Internet Communication Manager en SAP-router, alswel hashingalgoritmes en verscheidene poorten die tijdens een implementatie worden opengezet (SAP Management Console). Deze onderwerpen worden binnen verschillende SAP security notes geadresseerd.

In de volgende paragraaf zullen wij een aantal kwetsbaarheden uiteenzetten die wij tegenkomen in het SAP-landschap. De wachtwoordversleutelingsmethode van SAP NetWeaver zal als eerste de revue passeren. Vervolgens zullen wij inzoomen op SAP-systemen die via het internet toegankelijk zijn. Wij sluiten af met een beschrijving van de gevaren bij ontbrekende SAP security notes. De (technische) beveiliging van SAP op het niveau van de basislaag is vaak onderbelicht. Met dit artikel willen wij hier hernieuwde aandacht voor vragen.

Kwetsbaarheden

De wachtwoordversleutelingsmethode binnen SAP (hashes)

Wachtwoorden in SAP worden versleuteld opgeslagen in de user master record tabel. Een belangrijk aspect bij het opslaan van wachtwoorden is de manier waarop het wachtwoord is versleuteld. De versleutelmethode wordt ook wel het ‘hashingalgoritme’ genoemd. Hashes zijn onomkeerbare versleutelingen waardoor het oorspronkelijke wachtwoord niet valt te achterhalen. Het hashingalgoritme dat gebruikt wordt binnen SAP is de afgelopen jaren diverse malen gewijzigd. De achtergrond hiervan zijn tekortkomingen in voormalige algoritmes die aan het licht zijn gebracht door securityonderzoekers. Tevens werden password cracking tools steeds effectiever in het raden van combinaties van wachtwoorden, onder andere door gebruik te maken van rainbow tables. In een rainbow table staan allerlei mogelijke wachtwoorden en de hashes van deze wachtwoorden klaar, zodat het achterhalen van de wachtwoorden snel kan worden uitgevoerd. Password cracking tools kunnen gebruikt worden als assessment op de complexiteit van de gebruikte wachtwoorden.

Een efficiënte methode om het achterhalen van wachtwoorden tegen te gaan is het gebruik van een zogenaamde salt. Dit is het toevoegen van een willekeurige tekenreeks aan het wachtwoord voordat het gehasht wordt. Zo wordt het voor password cracking tools minder eenvoudig om wachtwoorden te achterhalen. Voor de introductie van SAP NetWeaver 7.1 of SAP NetWeaver 7.0 met Enhancement Pack 2 werd de gebruikersnaam standaard toegevoegd in de versleuteling van het wachtwoord zoals is weergegeven in figuur 1.

Figuur 1. Hash function.

John the Ripper, een bekende password cracking tool, heeft een module beschikbaar voor het analyseren van SAP-wachtwoorden.

Op internet circuleren diverse hulpmiddelen om de wachtwoordhashes gemakkelijk te downloaden uit de gebruikerstabel (USR02) en gereed te maken voor John the Ripper. De ervaring van de auteurs leert dat circa 5% van de wachtwoorden binnen één uur door John zijn achterhaald. Vaak maakt John hierbij een account met onbeperkte rechten (SAP_ALL) buit.

Op 21 februari 2009 bracht SAP een security patch[https://websmp230.sap-ag.de/sap/support/notes/991968] uit met een sterker hashingalgoritme, dat gebruikmaakt van een willekeurige salt. Echter, wachtwoorden die gebruikmaken van deze nieuwe methode worden standaard ook opgeslagen in het oude, kwetsbare formaat, vanwege compatibiliteit met andere systemen. Hierdoor is dit aangepaste algoritme niet effectief tegen hackers, omdat de zwakkere hash immers nog beschikbaar is. SAP heeft securityparameters beschikbaar gesteld om te voorkomen dat hashes worden opgeslagen in het (oudere) kwetsbare formaat[login/password_downwards_compatibility]. Helaas introduceert deze oplossing nieuwe uitdagingen met betrekking tot de connectiviteit van het systeem met oudere kernels (interfacing). Als mitigerende maatregel moeten autorisaties die toegang verschaffen tot de wachtwoordhashes, zo veel mogelijk worden ingeperkt. Op die manier kunnen zo weinig mogelijk mensen de hashes inzien.

Onbedoelde exposure op het internet

Potentiële kwetsbaarheden die vaak over het hoofd worden gezien, zijn de zogenaamde Internet Communication Framework services. Steeds vaker stellen organisaties hun SAP-systemen beschikbaar via het internet voor de koppeling met klanten, leveranciers, partners en de eigen medewerkers ([Poly10]). Het resultaat van deze functionaliteituitbreiding is dat organisaties hun traditionele interne systemen, welke deels zijn ontworpen in het tijdperk van de mainframes, blootstellen aan een nieuwe wereld. Zoekmachine Shodan[http://www.shodanhq.com] kan bijvoorbeeld een impressie geven van het aantal SAP-systemen dat benaderbaar is via het internet. Shodan is een zoekmachine die onder andere kan constateren welke software gebruikt wordt per website. Via deze zoekmachine zijn op het moment van schrijven (augustus 2013) 7.493 SAP-systemen aan het internet gekoppeld via onder andere de SAP ICM (Internet Communication Manager).

Figuur 2. SAP-koppelingen op internet.

De zoekopdracht uit figuur 2 geeft een overzicht van diverse SAP NetWeaver Application Servers. Het grootste gedeelte van de SAP-systemen is gevestigd in Amerika (1.762 systemen), gevolgd door Duitsland (1.007), Mexico (409) en India (350). Het beschikbaar stellen van SAP-functionaliteiten via het internet kan veel voordelen bieden aan organisaties, maar stelt de organisatie eveneens onbedoeld bloot aan gevaren die met internet gepaard gaan. SAP-systemen worden een toegankelijker en reëler doelwit voor cybercriminelen of hackers, mede door de blootstelling van interne kwetsbaarheden en misconfiguraties in het SAP-systeem. Standaard geactiveerde internetservices en de inherente kwetsbaarheden daarvan kunnen door hackers worden misbruikt voor het uitvoeren van een gerichte (cyber)aanval. Een voorbeeld van een SAP-service die gebruikmaakt van de zogenaamde Internet Communication Manager is de ‘info’ (/sap/public/info) service (figuur 3). Uit onze eerdere zoekopdracht in Shodan blijkt dat meerdere SAP-servers deze service via het internet aanbieden. Hierbij komen vertrouwelijke gegevens over het besturingssysteem, de databaseversie, IP-adressen en de SAP-system Identifier onbedoeld op straat te liggen (information disclosure). Het door hackers benaderbare spectrum van kwetsbaarheden kan op deze manier worden uitgebreid naar de onderliggende lagen. Tevens bestaat het risico dat hackers via zogenaamde ‘zero day exploits’ reeds onbekende kwetsbaarheden uitbuiten of misbruik maken van services met opgeslagen credentials. Men doet er daarom goed aan zich te realiseren welke services via het internet worden aangeboden. Vooral publiek toegankelijke services of services die beveiligingsrisico’s met zich meebrengen moeten worden uitgeschakeld[http://scn.sap.com/docs.DOC-17149].

Figuur 3. Internet enabled services (/sap/public/info).

SAP security notes

Vanaf 2008 is het aantal door SAP uitgebrachte security patches, ook wel security notes genoemd, drastisch gestegen. Waar SAP voorafgaand aan 2008 slechts enkele patches uitbracht, werden er in 2010, 2011 en 2012 gemiddeld 735 security patches per jaar beschikbaar gesteld. Naast de toename in kwantiteit steeg ook de diversiteit van de ontdekte kwetsbaarheden. De oorzaak hiervan ligt ten grondslag aan de toevoeging van steeds meer features, componenten en modules aan het oude, vertrouwde SAP R/3-systeem. Tegenwoordig is het compleet beveiligen en auditen van een modern SAP-systeem een tijdrovend en kennisintensief karwei geworden, gezien de toename van de complexiteit en de aard van de risico’s.

Figuur 4. SAP security notes

Door het toevoegen van steeds meer functionaliteiten aan SAP wordt het systeem blootgesteld aan (inherente) kwetsbaarheden die ten grondslag liggen aan de onderliggende technologieën. Een aantal technologieën die SAP heeft opgenomen zijn de programmeertaal Java, HTTP, SOAP/ XML en Open SQL. Deze ontwikkelingen veroorzaakten onder andere de expansie van het aantal uitgebrachte security notes. In figuur 4 is een overzicht opgenomen van kwetsbaarheden in verschillende SAP-systemen (Solution Manager, Portal) en inherente kwetsbaarheden in de gebruikte technologieën, door middel van Cross Site Scripting en SQL-injectie. Helaas zijn niet alle organisaties in staat security notes op korte termijn te implementeren. De continuïteit van het SAP-systeem moet gewaarborgd blijven tijdens het doorvoeren van een wijziging. Mede vanwege het changemanagementproces, waarbij diverse acceptatietesten worden uitgevoerd, duurt het vaak maanden voordat de kwetsbaarheden daadwerkelijk zijn verholpen ([Scho13]).

De uitleg van SAP over de risico’s die organisaties lopen bij het niet implementeren van security patches, is vaak ‘high level’ en onvoldoende informatief geformuleerd. De screenshots in figuur 5 schetsen de risico’s van een aantal ontbrekende security patches in het SAP-systeem. Eindgebruikers zijn in staat commando’s uit te voeren op besturingssysteemniveau, doordat de input van de gebruiker niet door SAP wordt gecontroleerd op juistheid.

Figuur 5. Het ontbreken van SAP security note 1580017 en 1445998.

Om een risico-inschatting te maken moeten organisaties afgaan op de categorieën waar SAP haar patches in classificeert. Wanneer we kijken naar het aantal security patches per categorie, zien we vooral in 2010 / 2011 een piek in het aantal uitgebrachte ‘hotnews’ patches. Eén van de oorzaken daarvan is de aandacht die SAP heeft gekregen binnen de securitygemeenschap. Vanaf 2010 nam het aantal SAP-securityconferenties sterk toe tijdens onder andere Blackhat en Hack in the Box ([Poly12]).

Figuur 6 toont de ontwikkeling van het aantal uitgebrachte security notes. Het cijfer van 2013 is tot en met augustus 2013. Deze cijfers zijn geëxtrapoleerd aan de hand van de eerste acht maanden. Vooralsnog lijken er in 2013 beduidend minder patches te zijn uitgebracht door SAP. Echter, de kwetsbaarheden zijn in 2013 ernstiger dan in voorgaande jaren.

Figuur 6. Uitgebrachte SAP security notes.

Eén van de risico’s die wordt onderkend in verschillende SAP-patches, zijn kwetsbaarheden in de SAP-gateway (note 1408081, 1465129, 1531820). De SAP-gateway is een technische SAP-component, die standaard ‘gebruiksvriendelijk’ wordt opgeleverd. Dit betekent dat security achteraf kan worden toegevoegd, maar niet standaard wordt geactiveerd. Een technische vertaling hiervan is de configuratie van de SAP-gateway, door middel van een Access Control List (ACL). De SAP-gateway zou alleen moeten communiceren met die systemen die in de ACL zijn opgenomen. Wanneer Access Control op de SAP-gateway niet is geactiveerd, kunnen ongeautoriseerde personen of systemen toegang krijgen tot het SAP-systeem, door bijvoorbeeld het uitvoeren van operating system commands. Een standaard SAP-systeem wordt dus ‘gebruiksvriendelijk’, maar kwetsbaar opgeleverd.

Een tendens in de securitywereld is het feit dat kwetsbaarheden in onder andere de SAP-gateway steeds meer worden omarmd door populaire penetratietesting suites, zoals Metasploit, Bizploit en Onapsis X1. Via deze tools wordt het hacken van een SAP-systeem steeds makkelijker voor een grote groep mensen. Figuur 7 toont plugins zoals ‘callback’, ‘eviltwin’ en ‘gwmon’, die gebruikt kunnen worden om misconfiguraties in de SAP-gateway uit te buiten. Een volledige compromittatie van het SAP-landschap is het gevolg.

Figuur 7. SAP penetratie Testing suites.

Onderzoek SAP-kwetsbaarheden

In de vorige paragraaf hebben wij een aantal elementen van de problematiek rondom SAP-security geschetst. Om helder te krijgen in hoeverre deze problematiek daadwerkelijk voorkomt, zijn verschillende kwesties getoetst binnen de praktijk ([Scho13]). Onder andere wachtwoordhashes, internet services, security notes alsmede scoping issues zijn in het onderzoek geadresseerd. Op deze manier wordt duidelijk in hoeverre risico’s binnen SAP door organisaties worden gemitigeerd.

Voor dit onderzoek zijn alle leden van de Vereniging Nederlandstalige SAP Gebruikers (VNSG) binnen de focusgroep Security Access Management benaderd. Door middel van een anonieme survey op 19 september 2012 hebben wij beveiligingsvraagstukken voorgelegd binnen deze groep SAP-securityexperts. De vragenlijst bestond uit 21 verschillende vragen en is door 22 respondenten ingevuld.

Hieronder geven wij de belangrijkste resultaten weer.

1. Zwakke password hashes in gebruik

Helaas komen wij bij veel van onze klanten wachtwoorden tegen die zijn opgeslagen in een zwak hashingalgoritme (zgn. A, B, D, E, F, G), ondanks dat er sterkere versleutelingsmethoden door SAP beschikbaar zijn gesteld (zgn. H/I). De oorzaak hiervan is enerzijds downwards compatibility en anderzijds het feit dat een aantal gebruikers als ‘service-‘ of ‘communicatiegebruikers’ is gedefinieerd. Deze gebruikers hoeven niet te voldoen aan de ingestelde security policy’s in SAP en het wachtwoord is zodoende niet eerder gewijzigd. Slechts één van de respondenten gaf in het onderzoek aan dat wachtwoordcomplexiteit wordt gecontroleerd door middel van password cracking tools.

2. Internetservices

Uit het onderzoek is gebleken dat onder 41% van de respondenten ICF[ICF = Internet Communication Framework]-services zijn uitgeschakeld. Overige respondenten geven aan dat overbodige ICF-services niet zijn uitgeschakeld of melden niet te weten of deze zijn gedeactiveerd.

3. Ontbrekende SAP-security patches

Veel security-incidenten of risico’s kunnen worden gemitigeerd door het tijdig doorvoeren van security patches in SAP. Uit het onderzoek blijkt dat minder dan 14% van de respondenten een security note binnen één maand implementeert. Door het niet tijdig doorvoeren van security patches stelt een organisatie zich (tijdelijk) bloot aan alle risico’s die in de patch worden beschreven. Helaas blijft de beschrijving van de concrete risico’s in de security notes onvoldoende duidelijk, waardoor organisaties de risico’s van de problematiek niet goed kunnen inschatten. Uit het onderzoek is gebleken dat toegang tot de SAP-gateway is beperkt bij 23% van de respondenten. Bij veel van onze klantorganisaties herkennen wij bovenstaand beeld.

Overige bevindingen:

4. Uitbraak van SAP in OSI-model

Normaliter wordt de OS- en DB-laag tijdens een IT-audit apart onderzocht ten opzichte van de applicatielaag. SAP biedt echter de mogelijkheid om vanuit de SAP-gebruikersinterface rechtstreeks commando’s uit te voeren op de OS- of DB-laag. Hierdoor zijn alle SAP-gebruikers potentieel in staat zich toegang te verschaffen tot andere lagen in het OSI-model (Open Systems Interconnect), namelijk OS en DB, terwijl dit niet tot hun taken en verantwoordelijkheden behoort. Via het OS kan de SAP-gebruiker met bijvoorbeeld SQLplus commando’s uitvoeren op de database, waardoor de ingebouwde controles in SAP niet meer effectief zijn. Het risico bestaat dat er bijvoorbeeld netwerk shares worden opengezet of nieuwe gebruikers worden aangelegd. Dergelijke commando’s worden uitgevoerd door de systeemgebruiker waar de SAP-applicatie onder draait. Het is daarom belangrijk dat de SAP-applicatie wordt uitgevoerd onder een systeemgebruiker met beperkte rechten op het OS-niveau. Tevens moeten SAP-transacties waarbij het OS en DB kunnen worden benaderd, beperkt worden toegekend. Uit onderzoek ([Scho13]) blijkt dat het bovengenoemde meestal niet wordt onderzocht gedurende een SAP-audit. Hierdoor loopt de organisatie het risico dat er ongecontroleerde wijzigingen worden doorgevoerd in SAP.

5. Niet-productieomgevingen te weinig onderzocht

Een SAP-landschap bestaat uit meer dan alleen een productie systeem. Organisaties gebruiken normaliter een OTAP-straat met aparte systemen voor Ontwikkeling, Test, Acceptatie en Productie. Op elk van deze systemen zijn meerdere mandanten aanwezig. Vanuit de gebruiker gezien is een mandant een aparte omgeving met een eigen gebruikersnaam en aparte transactie- en masterdata. In totaal kunnen er acht tot zestien SAP-mandanten in een SAP-landschap voorkomen. We hebben het dan alleen over de kerncomponent, SAP ECC, en laten andere componenten zoals CRM of BW buiten beschouwing omdat niet elke organisatie daar gebruik van maakt. In plaats van acht tot zestien SAP-mandanten wordt normaliter één mandant (productie) onderzocht, terwijl overige systemen zoals Test en Acceptatie grote risico’s kunnen bevatten.

Het risico bestaat dat vanuit niet-productiesystemen kan worden ingelogd op de productiemandant met behulp van een RFC-verbinding of door gebruik te maken van mandantonafhankelijke transacties. Hiermee is het mogelijk om de productiemandant te benaderen vanuit andere mandanten zonder dat vanuit het productiesysteem zichtbaar is wat er gebeurt. Bij een binnenkomende RFC-verbinding steunt SAP op de authenticatie en autorisatie van het andere (remote) systeem. Uit onderzoek ([Scho13]) blijkt dat IT-audits zich met name richten op de kerncomponent en niet op de vele andere mandanten of systemen in het SAP-landschap. Het is belangrijk dat alle systemen en mandanten worden onderzocht, vanwege de (identieke) risico’s die daar liggen.

Remediation plan

In de voorgaande paragrafen hebben wij de problematiek rondom SAP-security proberen te schetsen. Allereerst hebben wij een aantal inherente kwetsbaarheden uiteengezet in het SAP-landschap. Vervolgens hebben wij onderzocht in hoeverre deze en andere kwetsbaarheden in de praktijk worden gemitigeerd. Onderstaand volgt een aantal praktische adviezen voor systeemeigenaren ter mitigatie van een aantal bekende SAP-beveiligingsrisico’s. Per advies zijn in de Appendix handreikingen gedaan voor de praktische, technische oplossingen.

Figuur 8. Mitigatieplan SAP-beveiligingsrisico’s.

Password hashes

1. Allereerst moet het gebruik van zwakke password hashes in het SAP-systeem zo veel mogelijk worden voorkomen. Waar mogelijk moeten SAP-wachtwoorden in het verbeterde hashingalgoritme (CODVN H/I) worden opgeslagen. Dit kan worden gerealiseerd met behulp van een upgrade van SAP NetWeaver (minimaal 7.1). Daarnaast kunnen sterke password hashes via securityparameters worden afgedwongen.

2. Door middel van password cracking tools, zoals John the Ripper, kunnen zwakke wachtwoorden worden geïdentificeerd. Vooral achtergrondgebruikers zijn vaak geconfigureerd met een wachtwoord dat soms stamt uit de periode waarin SAP is geïmplementeerd. Wij adviseren om de geïdentificeerde zwakke wachtwoorden te wijzigen.

3. Functiescheiding in SAP is zo sterk als het zwakste wachtwoord. Verschillende tabellen en toegangspaden naar de password hashes moeten worden beperkt door middel van autorisaties. De mogelijkheden om toegang te krijgen tot de password hashes moeten in kaart worden gebracht en worden ingeperkt. Password hashes moeten worden gezien als vertrouwelijk.

Operating System & Database

4. Toegang tot SAP via het Operating System moet zo veel mogelijk worden beperkt. Security baselines op OS- en databaseniveau moeten worden ontworpen en geïmplementeerd. Tevens moeten autorisaties voor het rechtstreeks uitvoeren van commando’s op het besturingssysteem worden beperkt.

5. Zorgdragen dat de rechten van de SAP-applicatie op OS- en DB-niveau zijn beperkt, en dus niet worden uitgevoerd onder root- dan wel administratorrechten.

Technische SAP componenten

6. SAP-componenten moeten alleen kunnen communiceren met systemen of componenten in het landschap die bij hen bekend zijn. Op die manier kunnen onbekende (kwaadwillende) systemen en IP-adressen uit het landschap worden geweerd. Door het implementeren van Access Control Lists, voor onder andere de SAP-router, Oracle – SAP-verbindingen, Application Servers en Message Servers, kan worden voorkomen dat kwaadwillenden zich voordoen als een technische component en een ‘man in the middle’-aanval uitvoeren. Hierbij moet inzichtelijk worden gemaakt welke SAP-systemen en -servers operationeel zijn en bestaat de uitdaging geen adressen over het hoofd te zien.

SAP security notes

7. Het doorvoeren van de meest recente security patches, met name patches voor de SAP-gateway. Daarnaast moet het meest recente Basis Support package zijn geïmplementeerd, dat gedownload kan worden vanaf de SAP Marketplace. Review regelmatig Earlywatch-rapportages voor ontbrekende patches.

Koppelingen en interfaces

8. Controleer alle koppelingen vanuit non-productieomgevingen op basis van Remote Function Calls (RFC’s) en zorg dat inkomende verbindingen niet misbruikt kunnen worden.

Services

9. Activeer enkel die services welke noodzakelijk zijn voor de business. Onnodige (internet) services moeten zo veel mogelijk worden uitgezet op de applicatieserver. Controleer welke andere poorten en services door SAP worden gebruikt en opengezet. Beperk indien mogelijk de toegang tot kritieke logboekbestanden binnen de SAP Management Console.

Bovenstaande lijst met handreikingen kan worden gebruikt ter inspiratie en mitigatie van een aantal bekende SAP security issues. Tevens zijn zachte voorwaarden als soft controls en user awareness randvoorwaardelijk voor een veilig systeem. SAP-penetratietestingsoftware kan worden overwogen om snel de kwetsbaarheden in het SAP-landschap in kaart te brengen. Er zijn op de markt diverse commerciële en laagdrempelige freewareoplossingen (Bizploit) in omloop.

Conclusie

Mede vanwege een toename aan SAP-functionaliteiten en -producten creëren organisaties onbewust een uitbreiding van de toegangspaden naar hun kroonjuwelen. Daarnaast omarmt SAP technologieën zoals Java, HTTP, SOAP, XML en open SQL. Dit heeft geresulteerd in de adoptie van alle inherente beveiligingsrisico’s binnen SAP die met deze technologieën gepaard gaan. De risico’s rondom de (technische) beveiliging van SAP op het niveau van de basislaag zijn vaak onbekend en onderbelicht. Uit onderzoek blijkt dat deze risico’s dan ook beperkt worden gemitigeerd.

De aandacht die SAP krijgt binnen de cybersecuritygemeenschap groeit snel. Vanaf 2010 werden steeds meer SAP-securityconferenties georganiseerd. Daarnaast zijn de tools om kwetsbaarheden in SAP te misbruiken laagdrempeliger geworden. Via deze tools nemen de mogelijkheden voor het hacken van een SAP-systeem toe.

Met dit artikel hebben wij de risico’s van kwetsbaarheden en misconfiguraties in SAP geconcretiseerd. Organisaties zijn zich vaak niet bewust van de risico’s die men loopt door het niet mitigeren van de (onderbelichte) kwetsbaarheden. SAP-schroeft gelukkig de (standaard) beveiliging van haar systeem steeds verder op.

Het effect op reguliere IT-audit is dat werkprogramma’s voor SAP moeten worden aangepast en de risicoanalyse moet worden herzien. Een aantal van de huidige risico’s in het SAP-landschap is relatief eenvoudig op te lossen zoals weergegeven onder ‘Remediation plan’. Een team met daarin kennis van de applicatielaag en de infrastructuurlaag is daarvoor vereist.

Appendix

Onderstaande lijst met technische handreikingen kan worden gebruikt ter inspiratie en mitigatie van een aantal bekende SAP security issues. De nummering loopt parallel met die in de paragraaf ‘Remediation plan’.