The Systems, Applications, and Products in Data Processing (SAP) platform is a suite of software applications used by 99 Fortune 100 companies and nearly 270 million cloud-based subscribers around the world.1 Organizations typically operate their SAP enterprise resource planning (ERP) systems alongside SAP supplier relationship management (SRM) and SAP human capital management (HCM) environments. These integrated solutions improve decision making through a centralized data storage, analytics, and reporting system to empower enterprises with new insights for better business processes.
Oftentimes, SAP platforms become so vast that organizations lose track of their complexity as the spread yields more attack vectors that open doors to bad actors. The unsecured network sprawl puts additional strain on IT professionals to identify vulnerabilities. Network vulnerability identification is a small part of hardening the SAP platform, and most individuals who enter this realm discover it is an ongoing process, not a destination.
Every journey to establish SAP security should begin with IT personnel identifying control weaknesses by bringing all stakeholders—security, audit, and compliance teams—into the fold. This process often leads enterprises to understand that many areas of their business are undocumented and unorganized. Such a realization may set in motion a series of spot checks and an increasing awareness of where the first SAP security responsibilities begin to materialize. It is crucial that these new responsibilities are clearly defined as the SAP maturity journey moves into putting processes and policies in place and defining and implementing various standards.
After defining responsibilities, organizations achieve a proactive state in which activities are automated and implementation is fully monitored. With these levels achieved, they can move into the security information event management (SIEM) integration phase, wherein extended security controls, risk management integration, AI support, and continuous improvements are made. However, an SAP security journey cannot be successful without first establishing a well-defined SAP baseline.
Defining an SAP Baseline
Think of the SAP security baseline as a blueprint of the optimal to-be state that will help enable secure operations and configurations. The blueprint resembles an inverted pyramid where the broad base is the top level, denoting a composite of external and internal requirements and third-party advice—crucial for providing valuable insights.
Vendor recommendations are pivotal. They yield expert insights based on extensive experience with an organization’s SAP environment. Yet, while these external guidelines are invaluable, the heart of the baseline often reflects the enterprise's culture, inherent values, and unique approaches to challenges.
The SAP Security Strategy is at the inverted pyramid’s core, which acts as the guiding principle to shape vendor recommendations and enterprise culture (e.g., strategy, people, process, technology). The human factor cannot be underestimated. Employee and vendor attitudes toward an effective SAP security model can either be an asset or a hurdle. Motivated and conscientious individuals streamline the implementation of security controls, while apathetic individuals tend to make the task arduous.
Finally, at the tip of the inverted pyramid is the Concepts level. The SAP Security Concepts can be broken down into access control, data, and application security. These Concepts play a pivotal role in framing the SAP Security Baseline and are the foundation for all other considerations. It is important to note that the SAP Operations Map is a valuable tool to help establish a baseline. This tool is divided into 5 layers, segmented into 16 blocks.2 It helps guide users to develop a holistic SAP Security Baseline when used in conjunction with the inverted pyramid levels.
Audit Observations
The inverted pyramid baseline helps guide organizations use a logical process to assemble information required for secure SAP operations. However, this structured security information also plays another important role in helping steamline platform audits. Remember, auditors are not the enemy. They are a valuable collaboration resource. Organizations must document every action related to processes, configurations, changes, or access logs to prepare for an audit. This documentation gives the auditor clarity and serves as a pivotal reference point in events such as security breaches or audits.
Auditors are not the enemy. They are a valuable collaboration resource.Organizations must document every action related to processes, configurations, changes, or access logs to prepare for an audit. This documentation gives the auditor clarity and serves as a pivotal reference point in events such as security breaches or audits.
When an auditor reviews an SAP system, generally their top 10 observations are:
- Insecure RFC—Remote Function Call (RFC) destinations contain stored credentials. RFC users have privileged authorizations (e.g., SAP_ALL) that can be leveraged for lateral movement in the SAP landscape.
- Patch management—Longstanding, widely known, high severity SAP Security notes are not taken into account, manual corrections are not made and a patch strategy is not implemented.
- Critical authorizations—Critical profiles are assigned to dialog and system users. Essential access rules are missing from the rule book and authorization checks are not included in custom code.
- Change management—Critical objects and tables are transported and direct changes are made in the production or test phases. Program differences are identified between production and nonproduction.
- User IDs—Security-critical activities cannot be traced back to a named user and standard users/authorizations are copied to custom users (e.g., xxxWatch, ZDDIC, ZSAPALL).
- Password—Old password algorithms are used, access to password hashes is not protected, and security policies are overridden.
- Transformation—Security is not embedded and the security baseline is not updated (e.g., with S/4HANA and BTP requirements).
- Gateway To Heaven—No restrictions are set in the Sec_info and Reg_info files to prevent the unauthorized launching of external programs and external connectivity.
- Logging—Critical activity is not logged, log files are incomplete, and audit log filtering is in place.
- Governance—The target operating model is nonexistent, the baseline must be adhered to, and a proper management view is required for decision making.
Conclusion
Securing any SAP environment requires meticulous attention and expertise at every phase. Many enterprises must understand that they have security gaps, especially regarding documentation and organization—and that ignoring these issues will only exacerbate problems. The good news is that well-defined templates exist to help organizations establish SAP security processes that inevitably lead to success. The fundamental underpinnings of success have a solid foundation in establishing clear communications across all departments.
In addition, recognizing and addressing potential vulnerabilities is crucial, as showcased by the audit observations. The detailed insights from audits underscore the need for continual vigilance and adaptation. Organizations can fortify their defenses by heeding these observations and integrating lessons learned, ensuring that their SAP environments are compliant and resilient against ever-evolving threats.
Ivan Mans
Is an experienced SAP technology consultant who has worked in the SAP space since 1997. In 2012, he cofounded SecurityBridge. In his current role as chief technology officer (CTO), he is a motivated driver who inspires people and pushes technology, contributing to the continuous innovation of the SecurityBridge Platform. In recent years, Mans has been a regular speaker at SAP events where he evangelizes about SAP security.
1 SAP, “The History of SAP”
2 SecurityBridge, “SAP Secure Operations Map,” 22 November 2021