SAP security tutorial: Top 10 SAP security implementation steps

Many organisations see SAP as specialist software requiring similarly specialist resources with SAP experience. Whilst it is true that most organisations require some form of assistance from SAP experts to implement the software, there are a number of ways that in-house security resources and personnel can contribute to the implementation and maintenance of a secure SAP environment.

This brief SAP security tutorial outlines ten key SAP security implementation steps every SAP installation should cover, and considers how an IT security department can contribute to ensuring the organisation has incorporated them.

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.

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.

login/min_password_lng (default 3, recommended 8+)
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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 key is to remember that the CIO is accountable for the overall security and compliance of the enterprise. At this level, there is little room for distinction between general IT security, such as email, firewalls and Web servers, and SAP security, which includes the control of how people access the system, the data they process, and the functionality they execute.  Effective IT departments adopt a similar philosophy by viewing the IT security picture in its entirety across the whole organisation, thereby reducing the risk of breaches of any kind.

About the author:
Richard Hunt is managing director of Turnkey Consulting, a specialist IT security company focused on combining business consulting with technical implementation to deliver information security solutions for SAP systems. The company was founded in 2004 by Hunt and now has offices in the UK, Australia, Germany and the United States, servicing clients in Europe, the US and Asia.

Richard has worked in the IT security industry for more than a decade. His career began as a security consultant at PricewaterhouseCoopers (PwC), where he specialised in SAP security implementations and IT security reviews.  Throughout his career, he has been involved in more than 20 IT security projects working across a range of business processes and industry sectors in the UK, Asia and Australasia.