Security Geeks Introduction to SAP

As means of a background, I have been in the security field, specifically the pro-active testing (penetration testing) side of security for over a decade. As part of my past role, I would present at public and private conferences, helping to educate organizations about the benefits of pen testing or helping to educate pen testing teams about the latest techniques.

I say all of this in order to communicate that I would grade myself as having an above average knowledge of the security space and significant familiarity with commonly used terms in the industry. So when I recently took a product manager role at Onapsis and was told I would have to learn about SAP and the security and risk implications around SAP in the enterprise I smiled and thought “well, I guess I know what I am doing the first couple of days”. As it turns out SAP is a world unto itself, with a lot of history and complexity.

I know that more and more ‘traditional’ security professionals are being asked to evaluate the security posture and risk of a business’s SAP system; which makes sense as SAP typically runs the most critical processes and workflows for an organization, as well as housing the most important data. Given the amount of time and effort it is taking me to learn SAP I thought it would be beneficial to publish a little resource for other professionals making the same jump.

So, SAP? For those like me who need to know what an acronym stands for it is Systems, Applications and Products in data processing, also it is never said as a single word, but spelled out S-A-P. It started in and is still based in Germany and according to Wikipedia has a revenue of over 16 billion Euro in 2012 – so not a small company by any stretch of the imagination.

SAP provides a large number of applications for businesses; all of which has an acronym to describe them…

  • SAP CRM (Customer Relationship Management)
  • SAP ERP (Enterprise Resource Planning)
  • SAP PLM (Product Lifecycle Management)
  • SAP SCM (Supply Chain Management)
  • SAP SRM (Supplier Relationship Management)
  • etc…

And many, many more including finance and payroll applications (aka very tempting targets). Essentially any type of business process SAP has an application for. A big selling point for SAP is these different applications talk and work well together with each application being owned and managed by different departments; so you could have a CRM registering customer interactions that is able to reach out into the SCM and ensure that products will be ready on time.

How does this all work? SAP is installed on top of an (enterprise) operating system and database of the customers choosing (though SAP has recently announced their own in memory database ‘HANA’). If we ignore HANA for now, then when we think about SAP running on top of our OS we should first think of a base layer called NetWeaver; which is the SAP application layer. The specific SAP applications then run on top of this framework. As a result this framework has full access to the applications that run on top of itself and the data running through them.

As you would expect, SAP has its own terminology to described installed systems. There are a couple of key concepts and words that are used in the SAP that are important to know:

Landscape: A logical grouping of SAP systems of the same flavor (CRM or SCM etc.). In a typical landscape you would expect to see three different groupings of systems, one for development, one for QA and one for production. Given the importance of these systems to a business there is a lot of testing before changes are pushed to production. By virtue of how changes move from development to QA and to production these different systems all have communication channels connecting them.

System: A grouping of one or more application servers/Instances. Each SAP System is identified by an SAP System ID (SID) which is three alphanumeric characters (so DEV, QAS, PRD etc.)

Instance: An instance is a logical entity, grouping related components of an SAP system that provide one or more services. An Instance is identified by a two digit number. An SAP system might have more than one instance to allow for load balancing; so you typically only see multiple instances in a production system.

Client: An organizational unit within the SAP system; so could be a group, business unit or perhaps an external corporation (like a supplier). A client of an SAP system is identified by a three digit number (and there are three built-in clients on every SAP system, 000, 001, 066). When a user connects to a SAP system the specific client they wish to connect to has to be specified.

So there are a lot of elements, and a lot of connections and moving parts, which means a large attack surface and a lot to be tested and a significant challenge in identifying and remediating security weaknesses. That was my initial reaction and what got me so excited about this opportunity, there is nothing like taking on a complex and sensitive set of systems and safely showing ways in which the system is weak and helping to make it as strong as it can be without compromising the ability of the business to, well, stay in business.

However the traditional ‘standard practice’ (I refuse to say ‘best’) is not to test the systems ability to withstand attempts to attack and compromise it but instead to only check the business logic and permissions assigned to the legitimate users of the system. What I have learnt pretty quickly is most organizations when they think about the risk related to their SAP systems think of SoD. SoD is Segregation of Duties, and is a check to identify if any users of the SAP system have mistakenly been given sufficient rights to perform fraud. So for example it will check that a person who can create a vendor for payment in the business system cannot also submit purchase orders for that vendor and also approve those orders.

The opportunity I see that I have here at Onapsis, and security professionals have within their organization is that of education. We get to educate the business as to the real risk associated with their SAP implementation and how to best minimize that risk. Anytime I get to help educate businesses and make them more secure, and empower fellow security and IT professionals to become heroes within their organization I get excited.

I’m going to continue to write blog posts on what exactly these different types of risks are and how to test both for the risk and the effectiveness of the remediation/compensating controls used.

Share Button
This entry was posted in Research and tagged , , , , , , , , , , by Alex Horan. Bookmark the permalink.

About Alex Horan

Alex Horan is a Product Manager at Onapsis Inc. where he is responsible for the development of ERP vulnerability assessment, testing and securing solutions. Alex has over 15 years of experience working within the IT security industry, covering both software and hardware. As a result he brings a deep knowledge and understanding of vulnerability assessment and penetration testing, as well as systems and network administration and auditing to his work at Onapsis. Alex has previously worked for mid- and large-sized companies helping to design and maintain their security posture.

2 thoughts on “Security Geeks Introduction to SAP

  1. It will be nice to present a blog post about (if it exists) the possibilities that are offered to security researcher in order to setup their own SAP Lab.
    Thanks in advance.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>