Segment, restrict, encrypt, enforce, change, harden, update...
99.9% of the time MWR can successfully compromise the SAP systems that we are contracted to assess. Almost always, this would not have been possible had standard best practice defensive measures been implemented.
Each time I deliver a presentation at a conference, briefing or client meeting on the security of the SAP platform, I am asked the same question: “What practical advice can you give to remediate and/or mitigate the threat of compromise?” This advice is compiled and presented in the assessment reports delivered to clients at the end of an engagement, where we have been able to compromise the SAP system.
To answer that question here, there are a number of resources and guides available from SAP, Microsoft, OWASP, etc., that can help you to design, implement, configure and/or deploy secureSAP systems, some of which are presented below:
Additionally, resources such as the OWASP EAS Project can be of help.
This last project is very much in its infancy, but it can be a useful resource and one to watch. The same may be said of the Business Application Security Initiative, a non-profit organisation that focuses on security defects in business applications (including SAP).
The truth of the matter, however, is that SAP is no different from any other interconnected business system. Traditional network and application testing tool sets/methodologies are just as applicable to SAP systems, and network and application security best practices/principles are just as relevant. There are naturally some application technologies, system specifics and protocol idiosyncrasies that you need to be familiar with. However, for the most part the advice given (at a high level) to secure a SAP system is no different from that which is given when looking to secure a typical network, application or system.
Principally, the functions that SAP and interconnected systems provide must prohibit unauthenticated and unauthorised access. The operating systems and supporting databases that constitute the ‘core business’ infrastructure should also prevent such access.
In addition, authenticated and authorised users should be prohibited from abusing their privileges to circumvent security controls.
Finally, the systems authorisation model must enforce ‘business logic’ rules and ensure the principles of ‘least privilege’ and ‘segregation of duty’ are adhered to.
In essence this translates into the following practical advice:
To maintain a level of security and ensure ongoing security maintenance of large estates, organisations with mature security programmes can leverage automated vulnerability software suites to help them identify resident vulnerabilities and security defects.
Traditional security vulnerability scanners, such as Nessus, a popular security scanner, aren’t “SAP aware”.
Once you are satisfied that the system has been hardened and are reasonably confident that you have done all that you could have done to protect your ‘crown jewels’, the SAP system (and interconnected systems) should be subjected to an assessment that includes (but is not limited to) a benchmark against the BIZEC TEC11.
The BIZEC TEC/11 lists the most common and most critical security defects and threats affecting the Business Runtime layer of SAP platforms. The list is sorted, with each element having a criticality, either Very High (V) or High (H), and indicating whether it is a Rare® or Common © problem, helping organisations to prioritise remediation measures.