Security Geeks Introduction to SAP - Vulnerabilities
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 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 roles 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.
This blog is the second in a series that documents the self-education that I have been undertaking as I learn about SAP, assessing the security of a SAP system and then implementing secure practices.
As I mentioned in my first post in this series, the typical reaction of a business when asked about the security of their SAP systems is to refer to the SoD checks they do. That is the testing they do to ensure proper Segregation of Duties is enforced; which is, the system has the logic in place to prevent fraud – so the person who submits an expense report cannot approve it as well, for example.
Given 10 years of dealing with buffer overflows, ClientSide attacks, SQLi and numerous other ways to exploit weaknesses in how systems have been coded and implemented, I was more than a little surprised to learn that the testing of the underlying SAP applications and their configuration was not common practice.
There are numerous presentations and articles online that talk about the day SAP released 500 notes; and those that talk about the current rate at which SAP releases their notes. Suffice it to say that SAP is a large and mature technology that has the typical amount of issues of any large and mature technology.
So, when assessing the security of SAP you have to treat it that way too. By virtue of its flexibility, an SAP implementation can be configured in a very secure way and also configured insecurely. As a security professional it is our responsibility to accurately review the security posture of that SAP implementation and report on the weaknesses found and the potential negative impact that these weaknesses could have on the organization. This should consist of at least two types of tests; Blackbox and whitebox testing; with the option of fully testing your defenses by running safe exploits against your target SAP system in order to fully prove out what an attacker could do.
Blackbox testing allows you to evaluate the exposed surface of the SAP system; what can someone with no credentials learn and do with that system? Whitebox is an authenticated assessment, and allows you to dig into internal settings and configurations that are not typically accessible without credentials. The goal of both is the same, check how the SAP systems have been implemented and reporting any aspect which is insecure; ideally with recommended remediation steps. What kinds of things are we talking about? Default accounts, insecure connections between non-production and production systems; along with missing notes/patches and other weaknesses.
This is all possible to do manually of course, just like it is possible to use notepad and a calculator instead of Excel. There are also free tools available like Bizploit to help get this done in a more automated way. Regardless of how you get this checking done; given the monthly release by SAP of notes/patches for SAP systems best practice should be a monthly review of what patches are missing and what the consequence of not having those patches means.
In my next blog post I am going to talk about ways more forward thinking security professionals have been able to educate the business regarding the importance of regular or continuous SAP security monitoring and testing.