by: Carlos Chalico
Let’s think about SAP, a company founded in 1972, a company that offered the world a software that currently holds more than 250,000 customers in over 180 countries, and which is related in some way to 86% of the companies that integrate the list of the Global Fortune 500 (according to their corporate fact sheet). Well, this is clearly a product that is widely deployed and every single company that uses it should be thinking of defining formal and robust internal security control measures to protect the information and the data that is processed by this application.
A lot of things can be said about information security related to SAP; my intention now is to talk a little bit about the mistake made when defining the scope for executing an information security assessment on an SAP environment.
This misconception comes from the definition of what an SAP environment is. Typically, SAP platforms are comprised, at least, of three different tiers: Development, Quality Assurance and Production; It is very common that, depending on your role inside your organization, you might be conceptualizing differently what an SAP environment is.
If you are a programmer, for example, you might be thinking of the Development tier, this is where you spend most of your time and, as a consequence, everything there is valuable for you, so that might be your environment. But wait… What if you are from the IT department? Then you might be thinking not only of the Development tier but also of the one for Quality Assurance and, maybe, you are even thinking of the Production tier, the one that constitutes the environment for the users, on which real life happens, where true transactions occur.
When you think of the SAP environment, you have to keep in mind ALL the different tiers that comprise it and even beyond that. Each one of the tiers, and also the IT infrastructure elements that support them, has to be considered as a component that can reinforce or fully compromise information security on an SAP landscape.
Due to different regulations, most SAP user-organizations need to execute security assessments on their SAP environments and, commonly, these are executed by teams that for different reasons (budget, scope and time, to mention some) develop a partial and infrequent focus on the review, covering only a section of the production environment and thus creating the misconception on the scope definition.
It is true that you can find real and serious risks at the production environment, however, we need to recognize that this tier is always connected to the others and also to more SAP or non-SAP systems where we can definitely find real risks too that can even be bigger.
Experience has showed me different situations where weaknesses in non-productive systems or non-SAP environments fully compromise the security effectiveness of productive tiers on SAP systems; I would even say that most of the attacks against an SAP environment become successful outside production and even on non-SAP components. I even remember a project where my team was engaged on practicing a penetration testing exercise on an SAP environment that was very well protected. We unsuccessfully tried to penetrate the SAP system until one of my consultants, that was still executing some discovery duties, found an interesting file publicly available in our client’s corporate internal network, the file included a list of SAP users and passwords in clear text that we finally used to get access to the system
Because of this I always recommend to expand the risk sight when executing a security assessment on SAP environments; we need to have a full approach here in order to identify all the possible risks that can affect the confidentiality, integrity and availability of the information supported by, in this case, an SAP environment.
Considering this, next time you need to execute an information security assessment for SAP, please make sure you fully understand and clearly define what your target SAP environment is, considering all of the elements that can pose risk to your SAP operation even if they are not part of the SAP production environment or if they are not even SAP products. Remember that big failures also come from small mistakes.
How have you faced this?