De beveiliging van ERP-systemen sluit vaak onvoldoende aan op moderne dreigingen. En dat terwijl de complexiteit en het aantal afhankelijke processen van ERP-pakketten alleen maar groter worden. De beveiliging is met name gericht op traditionele functiescheiding, autorisaties en rolgebaseerde toegangscontroles. Dit is echter onvoldoende bescherming tegen de hedendaagse risico's waaraan bedrijven worden blootgesteld.
Over deze blogger
Martijn Sprengers MSc is werkzaam als IT Security Consultant bij KPMG IT Advisory. Hij studeerde af op het gebied van Computer Security en heeft meer dan 5 jaar relevante ervaring met IT-beveiliging. Hij is gespecialiseerd in de vele facetten van het beoordelen van IT-beveiliging: ethisch hacken, social engineering, penetratie testen, red teaming en IT-auditing. Klanten zijn onder meer grote bedrijven, zoals financiële instellingen, overheden en petrochemische organisaties. Onlangs heeft Martijn zich verder gespecialiseerd op het gebied van industriële IT-beveiliging (Industrial Control Systems), met een focus op nieuwe ontwikkelingen en bedreigingen.
ERP-systemen, zoals SAP, Oracle en Peoplesoft, zijn vaak het kloppend hart van een organisatie en bevatten een schat aan gevoelige bedrijfsgegevens. Ze zijn daardoor een gewild doelwit van internetcriminelen. De omvang en complexiteit van die bedrijfssoftware biedt echter allerlei ingangen voor criminelen. Het wordt daarom tijd dat leveranciers van bedrijfssoftware beveiliging serieus gaan nemen. Maar dit kunnen ze niet alleen. Ook als je een ERP-pakket in je eigen organisatie hebt geïntegreerd moet je aan beveiliging denken, met name omdat elke omgeving weer anders is.
Autorisatie en functies
Traditioneel is de beveiliging van ERP-systemen ingericht rondom autorisaties en functiescheiding. Ofwel, afhankelijk van de rol van een gebruiker binnen de organisatie krijgt die persoon bepaalde rechten toegewezen. Op basis van die rechten krijgt hij toegang tot de informatie die voor hem relevant is. Meestal is er voor veel handelingen aanvullende autorisatie van een tweede of derde gebruiker nodig. Zo mag een gebruiker die de crediteuren onderhoudt, bijvoorbeeld nooit dezelfde persoon zijn als degene die facturatie voorbereidt of degene die de betalingen uitvoert. Dit is een goed doordachte manier van gegevensbeveiliging, maar helaas niet genoeg.
De zwakste schakel
Moderne beveiliging gaat veel verder dan het afdwingen van functiescheiding in proces- en applicatielagen. Zo heeft SAP bijvoorbeeld de voordeur goed dichtgetimmerd, maar vergeet de achterkant. Ook de database, het besturingssysteem en het netwerk moeten beveiligd zijn. Dat is nodig, omdat systemen steeds vaker (indirect) gekoppeld zijn aan internet en software en systemen van ketenpartners. Door die toenemende complexiteit van interfaces en gebruikers is het nodig om holistisch naar de beveiliging van het hele proces te kijken.
Criminelen kunnen bijvoorbeeld via malware op een computer van een medewerker het onderliggende besturingssysteem van het ERP compromitteren en daarmee alle functiescheidingen in één keer doorbreken. Als het systeem wel is dichtgetimmerd, zullen aanvallers proberen de zwakste schakel in de keten te vinden. Ze kunnen bijvoorbeeld proberen zich indirect toegang te verschaffen tot het betaalsysteem, dat in verbinding staat met de banken, door in te breken op het Windows-domein (Active Directory).
Kwetsbaarheden in SAP
Laten we de security van SAP eens nader bekijken. Door het verleden als on-premise leverancier lijkt de softwarereus onvoldoende oog te hebben voor dreigingen van buiten. Ook wordt in de transitie naar software als cloud-dienst naar mijn idee nog te weinig gedaan om de beveiliging van die programmatuur te verbeteren ten aanzien van webdreigingen.
SAP-systemen zijn vaak complex en groot. Ze bevatten enorme hoeveelheden code en hebben bijna de omvang van een besturingssysteem. Meer code betekent ook meer bugs. Maar juist in het patchen daarvan is de leverancier niet sterk. De patches (SAP Notes genoemd) zijn vaak complex en het proces van toepassen ervan is ondoorzichtig. Ik heb zelf ook meegemaakt dat SAP laks omgaat met het melden van lekken (responsible disclosure). In 2012 meldde ik een nieuwe kwetsbaarheid in hun software en kreeg toen geen reactie. In 2013 lieten ze weten ze dat ze er toch mee aan de slag gingen. En nu hebben ze in april 2015 een patch uitgebracht voor die kwetsbaarheid. Daar zit echt te veel tijd tussen!
Daarnaast hebben SAP-systemen standaard veel (onveilige) functionaliteiten en (netwerk)interfaces geactiveerd, wat ze kwetsbaar maakt. Als je kijkt naar een standaard Windows-systeem, dan heeft dat gemiddeld al een tiental newerkpoorten openstaan. Bij SAP-systemen staan vaak tot wel honderd poorten open die door hackers gebruikt kunnen worden om binnen te dringen.
Waar andere softwarebedrijven regelmatig informatie delen over hoe je hun applicaties veilig configureert en installeert, heeft SAP pas in maart 2015 voor het eerst een ‘security baseline’ uitgebracht. Zo’n document beschrijft de beveiliging van het hele productaanbod, en andere grote softwarebedrijven, zoals Microsoft, leveren dit al veel langer.
Tips voor ERP-beveiliging
Voor organisaties die willen voorkomen dat gegevens uit ERP-systemen in handen van criminelen terecht komen, geef ik een aantal tips. Uiteraard is dit geen vervanging voor een gedegen security assessment, maar het is een goed begin.
– Kijk kritisch naar gevaren en dreigingen. Wat is het pad van de eindgebruiker naar de data? Waar zitten op technisch gebied en binnen processen de zwakste schakels?’
– Kijk van een afstand naar je systemen en processen. Monitor waar het gevaarlijk wordt, bijvoorbeeld koppelingen met externe partijen en systemen, zoals banken.
– Standaard-SIEM (Security Information en Event Management) werkt niet. Stippel het hele pad van een potentiële hacker uit en speel daarop in door te bepalen welke cruciale stappen voor hem belangrijk zijn (zogenaamde ‘choke-points’).
– Organiseer beveiliging op alle niveaus: zowel applicatie, database, OS en netwerklaag. Ga hier vooral over in gesprek met de business.
– Kijk goed naar de scheiding tussen ontwikkel-, test-, acceptatie- en productie-omgevingen (OTAP), maar niet alleen op applicatieniveau. Het zal niet de eerste keer zijn dat het mogelijk is om de geïmplementeerde scheiding te doorbreken, omdat een beheerder hetzelfde wachtwoord gebruikt voor acceptatie en productie.
