There are pre-delivered accounts and security authorizations in SAP applications for a variety of reasons. Without the proper control environment, these accounts and authorizations could be improperly leveraged by users, introducing substantial access risks and control violations. This installment of The Usual Suspects of SAP Access risks focuses on the System Authorizations and Accounts best known for:
- Unintended or excessive access
- Misuse of system accounts
- Exploiting Remote Function Call (RFC) configurations and security
Unintended or Excessive Access
Unintended or excessive access is a risk with a potential of many root-causes. We will zoom into a subset of this risk focusing on the pre-delivered SAP system authorizations (roles and profiles) and accounts.
Our SAP profiles house the most granular level of permissions in an SAP application such as S/4HANA. This entails authorization objects, fields, and field values. Profiles were the primary vehicle for delivering authorizations to end users in earlier versions of SAP before the role concept was introduced. The profile concept was not removed in newer versions, instead another layer of security was added in as the security roles now generate and house the profiles. Profiles can still be assigned directly to users although it is not recommended and often a control point. This is an important concept as the flexibility and layers to this model introduces risk and complexities.
Now that we have a baseline of what profiles and roles are, what are the risks with the pre-delivered content? Perhaps the most infamous profile is SAP_ALL as it delivers all authorizations in the environment (with some minor exceptions). This is a standard check for most auditors and documented in control matrices around the world. While SAP_ALL and SAP_NEW are commonly known, there are several other powerful profiles that should be monitored. In the screenshot below, we can see some examples of sensitive profiles assigned directly to a user account in SU01.
Figure 1 – Examples of pre-delivered SAP profiles
Pre-delivered SAP roles, often referred to as “seeded roles”, are traditionally comprised of the permissions to facilitate a specific business process or functionality across a specific module. Often, these roles have inherited segregation of duties (SoD) and critical access violations. Another key consideration are upgrades or enhancements. If the SAP environment is upgraded, these pre-delivered roles are subject to changes as well. This means the underlying authorizations could be updated and cascade to all users assigned with the potential of unintended or excessive access. Just like profiles, it is not recommended to assign standard SAP roles to end users.
Misuse of System Accounts
Within this post “SAP system accounts” refers to the accounts delivered with the SAP environment and not the “System” user type. Examples of these users are DDIC and SAP*. The account SAP* is delivered with the SAP_ALL profile assigned and a default password of PASS. I think you can see where this is going...
In fact, you can easily retrieve default passwords for these accounts in the ‘SAP NetWeaver Application Server for ABAP Security Guide’. The configuration/parameter ‘login/no_automatic_user_sapstar’ should be maintained accordingly as well as this is another intersection of security and configurations. You can evaluate the status of these system accounts and their associated passwords using SUIM or report RSUSR003 as documented in SAP Notes 40689 and 1610103. There is an EarlyWatch Alert report – ‘Default Password of Standard Users’ that can be leveraged to assess this data as well. Below is an example of identifying sensitive profile assignments manually.
Figure 2 – Manual Monitoring and Reporting (SUIM)
Remote Entry and Excessive Access
The SAP Remote Function Call (RFC) is a protocol that enables communication between calling and called environments. There are a variety of RFC types and they can be managed within SAP and non-SAP interfaces. The configurations of the RFC are critical as this can impact how authorization checks are carried out during a call. For example, RFCs can be configured to leverage the current user’s authorizations invoking the call, the authorization of a stored user ID, as well as an option to define a user for authorization checks by maintaining a user ID in the S_RFCACL object.
It is a common practice to “hardcode” a user ID in the logon procedure section when configuring an RFC. It is recommended the user ID maintained follows the principle of least privileged when assigning authorizations. This approach limits that RFC’s capabilities to the intent of the designed call(s). Additionally, RFCs should be inventoried and reviewed on a defined frequency. If an integration or RFC is no longer required, it should be decommissioned to avoid potential misuse in the future.
It is not uncommon to see RFCs mapped to an ID that is assigned SAP_ALL and SAP_NEW to avoid potential authorization issues during operations. This excessive access comes with a risk which is only enhanced with a little bit of knowledge and access. For example, a user could leverage a Business Application Programming Interface (BAPI) to create a user in a remote system, assign that user SAP_ALL, and then access that account without having any access in the called system. This is done by leveraging the RFC’s configured user ID which is also the ID maintained in the change documents. In the example below, you can see the ‘INSIDERDEMO’ user was created and maintained by my ‘RFC_DEMO’ user’s ID as opposed to the calling user ‘CHRIS’.
Figure 3 – Creating a user on a remote system using RFC without proper controls
Tips to Catching the Culprit: System Authorizations and Accounts
As mentioned in the previous post, Configurations, Parameters, and Patching, there will not be a silver bullet or one-size-fits-all approach for the “culprits” highlighted in this series. There are considerations such as control framework(s), policies, and procedures to establish the guardrails of a compliance program, the people/owners/approvers accountable, and the technology to improve the efficiency and effectiveness of overall operations. Below are some approaches to managing these associated risks:
- Establish a password a configuration management program with defined review frequencies.
- Restrict and monitor access accordingly by leveraging an approved critical access and segregation of duties (SoD) ruleset that is reviewed periodically.
- Establish controls for RFCs including population and security reviews (i.e., the validity of the RFC, security model with principle of least privileged, etc.).
- Implement detective and preventative control capabilities to manage access risk with Fastpath Assure modules, including: Segregation of Duties, Identity Manger, Security Designer, and more.
Download your free copy of Succeeding at Managing Enterprise Risk in Today’s Connected World. This eBook covers common areas of cross-platform risk in your SAP environment and how Fastpath can help your organization manage those risks.