Top 10 SAP security implementation steps
1. Alignment of SAP configuration settings with organisational policies
A company’s IT security policy should specify mandatory software requirements for things such as minimum password length, password strength, number of password fails allowed before account lockout, etc. These requirements should be followed by all applications, and SAP is no exception. In SAP, these settings are configurable and can be controlled using system parameters. The parameters can be viewed using SAP transaction RSPFPAR.
A company’s IT security policy should specify mandatory software requirements for things such as minimum password length, password strength, number of password fails allowed before account lockout, etc. These requirements should be followed by all applications, and SAP is no exception. In SAP, these settings are configurable and can be controlled using system parameters. The parameters can be viewed using SAP transaction RSPFPAR.
Look for the following, which should all be set to follow the organisation’s predefined rules:
login/password_expiration_time (default 0, recommended 30)
Users are forced to change their SAP password after this number of days.
Users are forced to change their SAP password after this number of days.
login/min_password_lng (default 3, recommended 8+)
Sets the minimum password length.
Sets the minimum password length.
login/fails_to_session_end (default 3, recommended 3)
Number of times a user can enter an incorrect password before SAP ends the session.
Number of times a user can enter an incorrect password before SAP ends the session.
login/fails_to_user_lock (default 12, recommended 5)
Number of times a user can enter an incorrect password before SAP locks the user master records from further logons.
Number of times a user can enter an incorrect password before SAP locks the user master records from further logons.
2. Access to generic user accounts
Like a lot of other application software, SAP comes with a number of generic accounts. These are intended to be used for initial installation and setup purposes, and their passwords are well known. It is therefore critical that these IDs are secured once the initial setup activities have been completed.
Like a lot of other application software, SAP comes with a number of generic accounts. These are intended to be used for initial installation and setup purposes, and their passwords are well known. It is therefore critical that these IDs are secured once the initial setup activities have been completed.
The most critical setup ID is the SAP* ID. Its status, along with that of other generic IDs, can be checked using the SAP report RSUSR003.
The passwords of these generic IDs should be reset, and the high-privileged profiles (SAP_ALL and SAP_NEW) should be removed. It is important to note that the SAP* account can recreate itself with a default and commonly known password when deleted. Accordingly, it is important that the SAP* account is secured but not deleted and system parameter login/no_automatic_user_sapstar is set to = 1.
3. Allocation of wide access profiles
As well as generic IDs, SAP is also delivered with a number of high-privileged generic profiles that give wide access to the system. The allocation of these privileges should only be used in the initial setup of the system and for subsequent emergencies. At other times, support and project team users should have restricted access assigned to them that reflects their day-to-day access requirements.
As well as generic IDs, SAP is also delivered with a number of high-privileged generic profiles that give wide access to the system. The allocation of these privileges should only be used in the initial setup of the system and for subsequent emergencies. At other times, support and project team users should have restricted access assigned to them that reflects their day-to-day access requirements.
The most important high-privileged access profile to be aware of in the SAP system is the SAP_ALL profile. This gives access to all transactions and authorisation objects, and, therefore, to any function or action in the SAP system. It is critical that this profile isn’t allocated on a routine basis. Similarly, the SAP_NEW profile gives access to all transactions and to all new authorisation objects.
Transaction SUIM allows detailed reporting on user access. Organisations can use the report to review the allocation of wide-access profiles to users and, using the ‘Users to Profiles’ report, can display a list of user IDs allocated to the SAP_ALL or SAP_NEW profiles. With this information, user access can be revised and restricted according to need.
4. Support and project team access
SAP is delivered without specific profiles or roles built for support or project team members. It is therefore important to define these to ensure the access of these users is appropriately restricted. In many projects this requirement is overlooked and, consequently, project team members are assigned the SAP_ALL profile or a wide-access profile loosely based on SAP_ALL.
SAP is delivered without specific profiles or roles built for support or project team members. It is therefore important to define these to ensure the access of these users is appropriately restricted. In many projects this requirement is overlooked and, consequently, project team members are assigned the SAP_ALL profile or a wide-access profile loosely based on SAP_ALL.
To ensure support and project team users have been adequately restricted, look for role specifications outlining the access requirements of these users and a set of roles defined for each group. Broadly speaking, at a minimum, roles defined for the following groups should be found:
- Developers
- BASIS Administrators
- Security (Role) Administration
- Security (User) Administration
- Functional / Configuration
A process should also be in place that confirms the roles are correctly defined for the organisation’s needs.
5. Appropriate segregation of duties in role design and access administration processes
Since SAP is an integrated system, there is a risk of internal fraud if incompatible responsibilities are allocated to the same individual. For example, if a user were to have privileges to maintain bank account details and execute the payment run, it might be possible for him or her to bypass controls and divert vendor payments to his or her own account.
Since SAP is an integrated system, there is a risk of internal fraud if incompatible responsibilities are allocated to the same individual. For example, if a user were to have privileges to maintain bank account details and execute the payment run, it might be possible for him or her to bypass controls and divert vendor payments to his or her own account.
Management and monitoring of segregation of duties (SoD) in an SAP environment is an important part of the security process. The relevant SoD risks to the organisation’s business must be defined, and compliance with these rules needs to be embedded into approval and access provisioning processes.
In order to ensure segregation of duties is incorporated into the organisation’s role design and access administration processes, a tool such as SAP GRC Risk Analysis & Remediation (RAR) should be installed to manage these risks. Manual processes can be employed as an alternative in smaller organisations, but the limitations of these processes (e.g. monitoring at role level as opposed to transaction level) should be recognised and managed.
6. Emergency and high-privileged access procedures
Roles should be defined to meet the access requirements of support and project teams on a day-to-day basis. However, it is important that these users have an escalation route available that enables them to get access to extended rights quickly when the appropriate circumstances arise: For example, to debug issues not replicable in a non-production system. This access should be approved by the head of SAP application support (or a similar authority), and be allocated for a defined period and tracked for usage.
Roles should be defined to meet the access requirements of support and project teams on a day-to-day basis. However, it is important that these users have an escalation route available that enables them to get access to extended rights quickly when the appropriate circumstances arise: For example, to debug issues not replicable in a non-production system. This access should be approved by the head of SAP application support (or a similar authority), and be allocated for a defined period and tracked for usage.
Emergency access procedures and processes and the use of tools such as SAP GRC Super User Privilege Management (SPM) can control and monitor the allocation and use of high-privilege access.
7. User access and housekeeping reviews
Ongoing monitoring and review is critical in order to maintain compliance with the organisation’s security policies and to meet the rigorous expectations that internal and external audits have of the SAP systems. SAP system administration processes must include regular reviews of duplicate user IDs, generic accounts, password parameters, etc., as well as the periodic review to check that the access currently allocated is appropriate.
Ongoing monitoring and review is critical in order to maintain compliance with the organisation’s security policies and to meet the rigorous expectations that internal and external audits have of the SAP systems. SAP system administration processes must include regular reviews of duplicate user IDs, generic accounts, password parameters, etc., as well as the periodic review to check that the access currently allocated is appropriate.
Whilst some of the review procedures required in an SAP environment will have activities specific to the SAP system, the majority of such procedures should be present in any well-controlled application environment.
8. Change management procedures
Strict adherence to change-control procedures and a transport path through development, QA/test and production environments is critical to the integrity of the data held in the production environment of an SAP system. SAP has an in-built transport mechanism called Change and Transport System (CTS), and it is important that access to the key transactions used to manage the CTS is restricted to only those administration staff members that require it to perform their roles.
Strict adherence to change-control procedures and a transport path through development, QA/test and production environments is critical to the integrity of the data held in the production environment of an SAP system. SAP has an in-built transport mechanism called Change and Transport System (CTS), and it is important that access to the key transactions used to manage the CTS is restricted to only those administration staff members that require it to perform their roles.
In addition to managing access to the relevant CTS functions, effective change management in the SAP environment will also involve the operation of more generic change management practices. These include documentation and testing of all modifications and the maintenance of an audit trail of business approvals for all changes.
9. Access to sensitive functions
As an integrated system, sensitive administration functionality and business transactions are accessed within the same environment in SAP. It is therefore critical that such sensitive functions are appropriately restricted and only the individuals responsible for these activities are able to access them.
As an integrated system, sensitive administration functionality and business transactions are accessed within the same environment in SAP. It is therefore critical that such sensitive functions are appropriately restricted and only the individuals responsible for these activities are able to access them.
The auditor may be able to provide a list of those functions that should be more carefully restricted, such as the following:
- Access to maintain and create users and roles
- Access to run operating system commands
- Access to transport transactions and objects
- Access to change or create programs
- Access to open and close the system for configuration
- Access to debug programs (allowing users to bypass authorisation checks)
10. Business ownership of security processes
Business ownership of security is vital to ensure there is adequate control placed over who can do what in an SAP system. Only the business can understand the implications of letting a payments clerk also be in charge of paying vendor invoices or employee expense claims, so the business must define whether this activity can be performed. It is essential, therefore, that it is understood which members of staff are allowed access to each SAP function and that access is constantly controlled.
Business ownership of security is vital to ensure there is adequate control placed over who can do what in an SAP system. Only the business can understand the implications of letting a payments clerk also be in charge of paying vendor invoices or employee expense claims, so the business must define whether this activity can be performed. It is essential, therefore, that it is understood which members of staff are allowed access to each SAP function and that access is constantly controlled.
Without adequate understanding and design of the permissions structures, business approvers are not able to make informed approval decisions. It is therefore important that the SAP role design utilised in the environment be simple enough for approvers to understand and the project include an element of training or education for approvers, both in the initial implementation and on an ongoing basis.
Conclusion
The advice above covers only the rudiments of security in an SAP deployment. However, exploring these elements is intended to demonstrate that these SAP security basics are similar to those that should be found in any well-controlled application security environment. Ultimately, SAP is just another business application and, whilst the use of specialist SAP skills is essential to getting things right the first time, it is also important that an organisation’s IT security department embrace its responsibilities in the SAP deployment and not defer all responsibility to SAP specialists.
The advice above covers only the rudiments of security in an SAP deployment. However, exploring these elements is intended to demonstrate that these SAP security basics are similar to those that should be found in any well-controlled application security environment. Ultimately, SAP is just another business application and, whilst the use of specialist SAP skills is essential to getting things right the first time, it is also important that an organisation’s IT security department embrace its responsibilities in the SAP deployment and not defer all responsibility to SAP specialists.