SAP security tutorial: Top 10 SAP security implementation steps

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
organization’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.
March 2, 2016 / Blog

What is SAP Security?

ERP Security, SAP Security, SAP Vulnerability, SoD

What is SAP security? A funny thing, we have been dealing with it last 10 years but have
never tried to answer this question in a distinct article before.

What is SAP Security in 2016?

Essentially, SAP Security is a complex set of different areas with different responsibilities.
There are several ways how to separate it into discrete parts to work with. SAP Security can
be divided into application and business layers or platform and customization level. On the
other hand, it can be grouped by approach such as detection and response or organizational
and technical. SAP Security can constitute distinct areas in accordance with platform types
(ABAP, JAVA, and so on).
In fact, SAP Security can be perfectly divided by responsibility into Segregation of Duties,
Custom Code Security, and Application platform security. Each one is commonly a
responsibility of different departments. However, I think a company should have one point of
contact for all those areas and the aim of CISO is to be this person.
The first area is Segregation of Duties and access control. It consists in protection of the
system against users who have insufficient privileges or combination of those privileges. For
example, if some employees have access to critical functionality such as read any table, they
can escalate their privileges by simply looking at a table with passwords. This area is the
most known, however, it’s not as important as others.
The second area is Code security. As you may be aware, programs written in ABAP language
(SAP’s proprietary language to develop extensions to SAP products) can have vulnerabilities
and, more importantly, they can be used as backdoors.
The third and main area is Application platform security. It covers all kinds of vulnerabilities,
misconfigurations, encryption, logging, enabled unnecessary functionality, and other
technical issues. Simply saying, here we deal with all issues that can lead to unauthorized
administrative access to SAP system and in most cases an attacker doesn’t need any SAP
account to conduct an attack.
If we compare these 3 areas, it’s clear that in terms of Cybersecurity the last one plays a vital
role. Of course, it doesn’t mean that you shouldn’t pay attention to other areas at all.
However, imagine the worst-case scenario, you have the weakest access control and SoD
configuration ever, say, you have SAP_ALL access for every user, this issue can only be
exploited by someone who already has an access to the SAP system. However, if a flawless
SoD control is in place, but a company’s portal is exposed to the Internet and has an
authentication bypass vulnerability, hackers can penetrate into the system and cause
irreparable damage.
Segregation of Duties, or SoD
SoD, or Segregation of Duties, is an important factor when dealing with different
responsibilities and job profiles within an enterprise. It means that a set of roles and
responsibilities should be assigned in such way that across an enterprise any individual
should not have end-to-end access rights over any business function. Segregation of duties
provides the assurance that no one has a physical and system access to control all phases of
business process or transaction: from authorization to custody and record keeping. An
individual should not have responsibility for more than one of these three transactions
components: authorizing transactions (approval), recording transactions (accounting), and
handling the related asset (custody). For example, persons who can authorize purchase orders
(Purchasing) should not be capable of processing payments (Accounts Payable).
There are hundreds of SoD examples in different SAP products and Industry solutions. To
analyze SAP system according to those rules, some solutions were introduced including SAP
GRC that can help to solve SoD conflicts. Usually, Risk Management team or SAP Security
team (if it exists in the company) are charged with SoD. Though, this solution is not for
CISOs as it requires an in-depth understanding of SAP authorization concept and detailed
integration with SAP Systems. However, taking into account that critical rights can be used
for privilege escalation and cyber-attacks, CISOs should be able to monitor SoD security as
well.
SAP Custom Code Security
Code security is a quite new area of SAP Cybersecurity comparing to SoD. The first
information about ABAP Security was published in 2002. It was an article about SAP Virus.
However, it is not the only problem of customization which SAP is giving for every customer
in order to be able to customize their SAP Systems. In the beginning, it was possible to
customize SAP only using ABAP. Later, SAP added new platforms; each of them can be
customized. Currently, SAP provides a lot of languages and frameworks to extend
functionality such as ABAP, JAVA, XSJX, and SAP UI5 (for HANA).
ABAP, as mentioned before, can have vulnerabilities left by developers unintentionally. But
it can also be used to write backdoors which can provide malicious functionality such as
sending details of every transaction to a 3rd party via email or even publishing it on Twitter.
Unfortunately, development inside the company is almost uncontrolled. I mean, nobody
knows what developers do in the system, so they can write insecure code, forget to add
checks for access control in the programs, send money to their bank accounts and nobody
will notice it unless looks at their source code. So, the developer is a kind of God but can act
like a devil with this power.
Let me give you one example of these issues. If a user wants to execute a particular
transaction, he writes a transaction name in a menu and the system checks whether he or she
has access to this transaction in his profile. But if a user calls for a transaction in an
extension, the system does not check whether the user who ran this program has the right to
execute the transaction. In order to protect the system from illegitimate transactions by
running such programs, programmers need to implement special checks in code before each
call for transaction or other dangerous action. Thus, great responsibility lies with the
developers. Of course, it is not always easy to keep an eye on the fact that all the necessary
checks are in place, especially when the number of programs is estimated at thousands, and
the number of systems and developers amounts to dozens or hundreds.
It’s clear that there should be some frameworks or tools to check if developers write their
code properly. But how can one check it? What should they look for? When we deal with
web application security the common way is to follow OWASP methodology and to be sure
that top10 most critical issues do not affect your application at least. As for enterprise
applications, it is not a trivial task to understand what issues we need to check. Fortunately,
there is EAS-SEC – a nonprofit organization developed to increase awareness in enterprise
application security. EAS-SEC consists of separate projects, one of which covers code
security. It’s called Enterprise Application Systems Application development guide or simply
EASAD – this guide describes 9 general categories of source code issues for business
languages. Those categories are universal and the same for most of business, applications
such as SAP, Oracle, Microsoft Dynamics, Infor and their custom languages.
Who is responsible for this area? Usually, Custom Code security is under the responsibility of
SAP Developers, which means that they need to test their work themselves. This approach
 doesn’t actually work, as we all know. In my opinion, the responsibility of security of custom
developments, be it either SAP’s ABAP or anything else, should be a CISO’s duty.
SAP Application Platform security, or SAP Cyber Security
Finally, we can discuss the newest and most important area of SAP Security – Security of
Application platform. As you probably remember, the first steps in this area were taken
somewhere in 2006-2007. This area came from the underground in the 2010-2011, and the
market began to actively form in late 2013.
What is SAP Cybersecurity, or SAP Application platform security? Well, in theory, it’s
everything associated with secure configuration of SAP Applications and related systems.
Simply saying, it’s about the security of SAP’s platform without taking into account any
customization such as new access rights or new custom programs. However, sometimes
access control checks for default BASIS functionality are also included into Application
Platform security area as these misconfigurations may be used to perform cyber-attacks. Here
is the list of the most critical areas that should be covered during any SAP Security Audit:
 Infrastructure security (Network, OS, Database)
 SAP Vulnerability check (blackbox, whitebox, greybox)
 Configuration analysis (authorization, encryption, logging)
 Access control checks (By Module, by Application, by Industry)
 Password complexity checks (for different types of stored passwords)
 Connections security (RFC, Trusted connections, PI interfaces)
 Compliance (SAP, EAS-SEC, ISACA, DSAG, PCI, SOX…)
Any vulnerability in Application platform can give an attacker full access to SAP system and
its data. To perform the attack, a cybercriminal doesn’t need to be a legitimate user! They
don’t even need an access to a company’s network, sometimes SAP Systems are available for
remote connection from the Internet!
Who should be responsible for this area is a tough question. SAP BASIS team’s work is
implementing and setting a whole system, they sometimes set up security as well as the
administrators of any other systems, be it Windows or CISCO. However, if there are no team
to control this segment and people who understand the nuances of how to safely configure an
SAP system, it’s hard to expect that the SAP Basis team can provide an adequate level of
safety since they are not an expert in the field of Cybersecurity and are not responsible for
any possible consequences. As a result, responsibility for this area as well as for two others
should lie with CISO.
Conclusion
Well, so what is SAP Security finally? The cybersecurity of the entire SAP landscape
depends on all three areas. However, the market is developing, so customers’ desires are
changing. Here come new fields. First of all, it’s a correlation. Currently, clients don’t want
to implement numerous solutions that provide multiple reports and require a lot of time to
learn. But, most importantly, they want to see the whole picture, not just a list of users with
critical rights and another list of vulnerable programs. As we learned from this article, CISOs
should be responsible for all the listed areas and they want to see the whole picture and
collect security-relevant data about different angles of SAP Security in one solution. The
second important thing is not how the system itself is vulnerable but if it’s possible to hack
other systems connected with this system, and, if so, how many systems it’s possible to hack,
how easy it is and how critical those systems are.
And the last but not least, companies from different industries want to be able to analyze the
security of their industry-specific applications, exact risks associated with their industry and
follow guidelines applicable to their organization. All those needs are relatively new, but we
already heard about those requirements from different analysts, CISOs, risk officers, SAP
security engineers, and others involved in SAP Security.
I hope this post helped you to get to know what SAP Security is and how you can be involved
in this growing world of opportunities