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.