Talk/Workshop: SAP Security In-Depth
No two SAP deployments are the same. If you run an SAP environment, then you will most certainly use customisations and a multi-tier architecture. You will have tied your SAP deployment to your assets. The typical setup features Development, Quality Assurance and Production (which is the minimal amount of tiers, you may have more). While the development and IT staff mainly interacts with Development and Quality Assurance environments, the organisation’s end-user only connects to the Production systems in order to undertake the required business processes. As soon as security considerations come into play you will probably audit your infrastructure. Since auditors cost money most SAP deployments won’t be scrutinised completely. And then you are in trouble despite passing tests with flying colours.
Using short-cuts is the best way to run into trouble. Consider your multi-tier deployment that links a lot of different systems together. The Productive system is usually connected directly or indirectly to several other systems, either SAP or non-SAP solutions, as well as to the Quality Assurance and Development environments. As these other systems are usually regarded as non-critical, their security is often disregarded. While it is absolutely true that the Production system’s environment is the most critical one, the fact that other systems and components are not evaluated means that the chain can still be broken by the weakest links. This is not what a secure deployment looks like. SAP landscapes are highly interconnected. Attackers will uses these links to advance further into your network. It is entirely possible for a malicious intruder to access a weak Development/Quality Assurance system and, from there, take advantage of an RFC interface to “jump to” the Production environment. From there, the attacker can engage in espionage, sabotage and fraud attacks on the most valuable business information.
You might say that you followed best practices and secured your SAP infrastructure by Segregation of duties (SoD). While the theory is sound, it is not enough to prevent security incidents. There are many other threats that are overlooked and involve much higher levels of risk: the security vulnerabilities in the technological components that build up SAP platforms (business runtime). Examples of these components include: SAP Web Application Servers, SAP J2EE Engines, SAP Enterprise Portals, SAP XI/PI, SAP BI, SAP ITS, SAP Web Dispatchers, SAProuters, RFC interfaces and other technical services such as the SAP Gateways and SAP Message Servers.
For all of these reasons we have included two talks about SAP security and a full-blown 2-day training SAP Security In-Depth into the DeepSec 2011 conference. In his talk Your crown jewels online: Further Attacks to SAP Web Applications by Juan Pablo Perez Etchegoyen from Onapsis will dispel the myth that SAP platforms are only accessible internally.
Once you have portals and web interfaces you are exposed. Period.
Nowadays everyone has portals and web-accessible interfaces. Just slapping SSL onto it doesn’t make it more secure. The second talk Rootkits and Trojans on Your SAP Landscape by Ertunga Arsal explores the attack vectors to your SAP infrastructure. While companies invest a lot to secure SAP systems at business process level for example by designing authorisation concepts, implementing separation of duties or by using GRC (Governance Risk and Compliance) tools, the security at technical level mostly lacks attention. The talk presents several attack paths exploiting configuration weaknesses at technical level, leading to attack potential to single systems, to whole SAP landscapes, and finally the whole enterprise network.
If you run SAP, you better be aware of the risks. Make sure your IT staff is well-trained and knows how to secure your crown jewels.