Protecting SAP Configurations
Over the past nine years, more than 200 Fortune 1000 companies have come to rely on Onapsis to protect their SAP implementations and the data and processes that they in turn rely on. Throughout our research experience and working with these customers, we have seen numerous attacks to SAP applications, compliance violations and business owners suffering from the impact of SAP risks.
There are many diverse security risks that can affect SAP applications, many of them related to insecure configurations. In this series of blog posts, we will talk about both the visible and invisible risks of insecure configurations and SAP configuration drift.
There are many different changes and settings that can be applied to SAP applications that would fit into the category of “security configurations:”
- Profile parameters
- Settings stored in SAP tables
- Configuration of audit logs
- ICF Services activation/authentication/authorization
- Interfaces activation/authentication/authorization
- ACL files
- Default users
- Default/weak passwords
- High-privileged profiles/users
- And more…
Changes in any specific settings of these groups may have critical security implications. In addition, most of these changes are not tracked or logged at all. Only changes in the ABAP Workbench (ABAP Programs, ABAP Dictionary, etc.) or the IMG (Implementation Guide, used for system customizing) will have the proper change management process through the SAP Change and Transport System (CTS). Other types of configurations, such as changes to RFC Destinations, ACL files content, Dynamic Profile Parameters or ICF Services, are implemented directly in production without any kind of approvals or transports between the different layers of the Transport Management System (TMS). Some of those changes (e.g. changes to Gateway ACLs content or RFC destinations) are not logged in the Security Audit Log or any other SAP system log entry.
Because of this, BASIS teams and security administrators not only have to navigate through very complex scenarios balancing operational and security activities, but business owners are not able to recognize what changes are happening in their systems. This situation is referred to as SAP configuration drift.
Third-party or internal administrators, developers and/or testers make constant changes in SAP systems as part of their daily job. As a result of this behavior, when systems are already configured in a secure or compliant way, there exists a big risk of not only becoming insecure or falling out of compliance, but also of jeopardizing the previous resource time investment around securing the system in the first place. We have heard customers discussing the challenges of internal human errors or third parties’ misuse of their resources which led to SAP configuration disasters, exposing their systems and adding a lot of unnecessary double work from the BASIS teams and security administrators.
From a security standpoint, each time a setting is misconfigured there exists a the risk of exposing the SAP systems to threats that may compromise its confidentiality, integrity or availability. From the compliance standpoint, there is a serious monetary risk related to penalties when not complying with standard policies such as SOX, GDPR or PCI.
Additionally, every time this happens there is a huge monetary impact on the efforts spent to redo the work and configure the SAP systems to be at a secure or compliant state again. Not to mention the downtime to the business for taking systems offline for hours or even days. We know that reaching that desired state (get clean) implies very high costs in terms of time and resources for our customers. But when that state is reached, there are even more costs associated to keeping the SAP system in that state (stay clean).