SAP systems contains business critical and sensitive data that must be protected. Nowadays we have new challenges regarding the protection of this data. Environments are becoming more and more complex, access is possible via the cloud and the systems are distributed across geographical locations. 

Securing the access to SAP systems

News about the threats pass by daily. With GDPR, the fines have increased if there is data loss of personal data and therefore it becomes more attractive for hackers to (try to) steal this valuable personal data. According to reports, like the one from ICO (Data Authority in the UK), the number of breaches is increasing. Many breaches have one thing in common; they are accomplished by compromising the passwords of user accounts. This hacking is often done by social engineering techniques and once the account is hacked, these accounts are used to get access to more privileged accounts. This unauthorized access can easily go undetected for days, weeks or even months, allowing hackers to see and steal information.

In SAP systems you can implement security on different levels. The following topics will discuss the levels of the system parameter settings and the user accounts itself.

Securing by defining System Parameter settings

Let’s have a look how we can get access to the SAP data. At the application level, we have users that log on to the system with their user ID and password. A level of security can be defined via the system parameters. We recommend implementing proper system parameters to provide a basic level of security; such as setting up the length and complexity of the password and by disabling the possibility of multiple logons by the users. These system parameters settings can be adjusted via transaction code RZ10. We recommend including the system parameter settings in your audit and monitoring cycle. Do note that these settings are only applicable for dialog users, it does not apply to system logons.

Securing the User accounts

A user account typically represents a human identity and has a password to restrict access to the account. There usually is a single account password per human user that needs to be memorized by the person. A privileged account can be human or non-human so does not necessarily represent a human being. For example: (standard) SAP application accounts that are often shared by IT staff.

User account risks

Hijacking privileged SAP accounts gives attackers the ability to access critical and sensitive SAP data. An example of privilege account misuse that we have encountered: A dialog user has access to the user ID and password of a service account and uses this service account user to log in and perform tasks. Another example: a dialog user does not have sufficient authorizations to do a certain tasks, but does have access to schedule this as a background job using a background user (with broad authorizations).

To mitigate risks, users need to be restricted to the access they need for their daily tasks, while broader access rights are necessary to solve issues and problems. To solve issues, temporary broad access rights are required. However, granting temporary broad access rights (privileged access) comes with treats:

• Shared accounts and passwords, so you don't know which user has done what (audit trail);
• The risk of breaches (misuse of the broad access rights by users who should not have access to the functionality);
• No clear visibility over who has access to various resources within the SAP system(s), lacking complete control;
• If a procedure does exist, it can be a complex and time-consuming process to grant the access rights to the users;
• Failed audit, because the audit trail is missing.

User Types SAP

• Individual users - these are dialog users (type A), used to login via the SAP GUI;
• Internet users - used for web applications;
• Technical users - here we can distinct Service users (type S), Communication users (type C), System users (type B) and Reference users (type L). Service users are dialog users who can log on using the SAP GUI.

Here's the difference:

Dialog 'A'

A normal “dialog” user is used by one person only for all types of logon. During a dialog logon, the system checks for expired and initial passwords and provides an option to change the password. Multiple dialog logons are checked and logged if necessary.

System 'B'

Use the “system” user type for internal system processes (-> background processing) or system-related processes (-> ALE, workflow, TMS, CUA). Dialog logon (using SAP GUI) is not possible. A user of this type is excluded from the general settings for password validity. Only user administrators can change the password using transaction SU01 (Go to “Change Password”). Multiple logons are allowed.

Communication 'C'

Use users of type “Communication” for dialog-free communication between systems (-> RFC or CPIC). Dialog logon (using SAP GUI) is not possible. The general settings for the validity period of a password apply to users of this type. Users of this type can change their passwords (like dialog users). The dialogs for changing the password must be provided by the caller (RFC/CPIC client). You can use the RFC function module USR_USER_CHANGE_PASSWORD_RFC or the RFC API function RfcOpenEx() to change the password.

Service 'S'

A user of the type “Service” is a dialog user that is available to an anonymous, larger group of users. Generally, this type of user should only be granted very restricted authorizations. For example, service users are used for anonymous system access using an ITS service or a public Web service. Once an individual has been authenticated, a session, that started anonymously using a service user, can be continued as a personal session using a dialog user. During logon, the system does not check for expired and initial passwords. Only the user administrator can change the password. Multiple logon is allowed.

Reference 'L'

Like the service user, a “reference” user is a general user, not assigned to a particular person. You cannot log on using a reference user. The reference user is only used to assign additional authorization(s). Reference users are implemented to equip Internet users with identical authorizations.

On the Roles tab, you can specify a reference user for additional rights for dialog users. Generally, the application controls the allocation of reference users. You can allocate the name of the reference user using variables. The variables should begin with "$". You assign variables to reference users in transaction SU_REFUSERVARIABLE. This assignment applies to all systems in a CUA landscape. If the assigned reference user does not exist in one of the CUA child systems, the assignment is ignored.

SAP User types vs. Risks

The different types of user types come with different risks. In the table below you can find an overview of different SAP User types vs. the risks involved.

Type	Dialog - A	System - B	Communication - C	Service - S	Reference - L
SAP GUI Access	Yes	No	No	Yes	No
Password Check	Check expired and initial system parameters	No password validity	Check validity	No, check expired and initial password	N/A
Multi logon	Yes, system parameter	Yes	Yes	Yes	N/A
Can change password	Yes	No	No	No	N/A

User types SAP HANA

Database users that correspond to real people. For every person who needs to work with SAP HANA, the user administrator creates a database user. Database users that correspond to real people are dropped when that specific person leaves the organization. This means that any database objects they own are also automatically dropped, and any privileges that they granted are automatically revoked.

Database users can be created with either the CREATE USER or CREATE RESTRICTED USER statement, or using the SAP HANA cockpit.

Standard users

Standard users correspond to users created with the CREATE USER statement. By default, they can create objects in their own schema and read data in system views. Read access to system views is granted by the PUBLIC role, which is granted to every standard user.

Restricted users

Restricted users, which are created with the CREATE RESTRICTED USER statement, initially have no privileges. Restricted users are intended for provisioning users who access SAP HANA through client applications and who are not intended to have full SQL access via an SQL console. If the privileges required to use the application are encapsulated within an application-specific role, then it is necessary to grant the user only this role. In this way, it can be ensured that users have only those privileges that are essential to their work.

Compared to standard database users, restricted users are initially limited in the following ways:

• They cannot create objects in the database as they are not authorized to create objects in their own database schema.
• They cannot view any data in the database as they are not granted the standard PUBLIC role.

They are only able to connect to the database using HTTP/HTTPS. For restricted users to connect via ODBC or JDBC, access for client connections must be enabled by executing the SQL statement ALTER USER <user_name> ENABLE CLIENT CONNECT or enabling the corresponding option for the user in the SAP HANA cockpit. For full access to ODBC or JDBC functionality, users also require the predefined role RESTRICTED_USER_ODBC_ACCESS or RESTRICTED_USER_JDBC_ACCESS.

Before getting started with privileged access management

Ask yourself the following question: What does privilege access in SAP mean in and for your organization? It could for example mean access to sensitive data, configuring the SAP system or deploying patches. You can use your disaster recovery plan to identify which SAP systems are classified as important and then further identify the privilege accounts for these SAP systems. If there is no disaster recovery plan available, maybe there will be a data impact assignment that can be used. Especially after GDPR’s launch in May 2018, we see that many organizations have defined a data impact assignment that classifies the data that is most important to the business.

Implementation scenarios for requesting privileged accounts

Different implementation scenarios are possible, and you should analyze which implementation scenario suits you best. Does every use of the privilege user need to be approved first, or will a select number of users be pre-authorized to use the privilege access (in case of real emergencies that needs to be handled right away or outside of office hours)?

Privileged access management lifecycle

We recommend implementing a lifecycle to continuously support your privilege access management. This lifecycle makes sure that the assignment, usage, monitoring and audit of the users with broad authorizations, are covered.

Define & Discover

Which SAP systems are important? Make sure you don’t forget your development systems. Very often SAP development systems can be used as a back door to access the production system. Make sure your IT security policy covers privilege accounts. Define all privilege accounts and their acceptable use policies. Spread the word, create user awareness about the usage of these accounts. Identify which privilege accounts already exist in the SAP system(s).

After installation of SAP, a number of users with broad access rights will be created like SAP*, DDIC, EARLYWATCH, CAPCPIC, TMSADM. These accounts are defined with standard (well known) passwords. These passwords should be changed. In SAP HANA there will also be the operating system user <SAPSID>ADM and SAPService<sapid>. <SAPSID>ADM has unlimited access to all local resources related to SAP systems, the initial password is specified during installation. The SYSTEM database user is created during the creation of the SAP HANA database. It is the most powerful database user with irrevocable system privileges, for example: the ability to create other database users, or access system tables.

The SYSTEM user of the system database has additional privileges, namely the privileges required for managing tenant databases, for example, creating and dropping databases, changing configuration (*.ini) files of databases, performing database-specific data backups, stopping and starting databases.

The SYSTEM user does not automatically have access to objects created in the SAP HANA repository. The SYSTEM user is not required to update the SAP HANA database system; a less-privileged user can be created for this purpose. However, to upgrade SAP support package stacks, SAP enhancement packages and SAP systems using the Software Update Manager (SUM) and to install, migrate, and provision SAP systems using the Software Provisioning Manager (SWPM), the SYSTEM user is required and needs to be temporarily reactivated for the duration of the upgrade, installation, migration or provisioning. 

Manage & Protect

Proactively manage, monitor, and control the privileged accounts with password protection. Your solution should automatically schedule password rotation; audit, analyze, and manage individual privileged session activity to quickly detect and respond to malicious activity. If privilege accounts are created, they should be created with a least-privilege policy, limiting privileges will not only reduce the risks of misuse of these accounts, but it will also save time while monitoring these accounts.

Standard SAP users

To protect these users from unauthorized use:

• Define a new superuser and deactivate SAP*;
• Change all of the default passwords for these users;
• Assign to the group SUPER, so they can only be modified by administrator who are authorized to change users in the group SUPER;
• Lock DDIC and EARLYWATCH, and unlock them only when necessary.

Do not delete DDIC or its profiles. DDIC is needed for certain tasks in installation and upgrade, software logistics, and for the ABAP dictionary. Deleting it results in loss of functions in these areas.

To make sure everything runs smoothly, give DDIC the authorizations for SAP_ALL during an installation or upgrade and then lock it afterwards. Only unlock when necessary.

To find out which clients you have in your system, display the table T000 using transaction SM30.

Use the report RSUSR003 to make sure that the user SAP* has been created in all clients and that the standard passwords have been changed for SAP*, DDIC (and also the older user SAPCPIC). For more information, see SAP Note 40689.

 

SAP HANA

As the most powerful database user, SYSTEM is not intended for use in production systems. Use it to create less-privileged users for particular purposed, and then deactivate them.

Do not use the SYSTEM user for day-to-day activities. Instead, use this user to create dedicated database users for administrative tasks and to assign privileges to these users. It is recommended that you then deactivate the SYSTEM user. You may temporarily reactivate the SYSTEM user for emergency or bootstrapping tasks. See Deactivate the SYSTEM User

You can still use the SYSTEM user as an emergency user even if it has been deactivated. Any user with the system privilege USER ADMIN can reactivate SYSTEM with the statement ALTER USER SYSTEM ACTIVATE USER NOW. To ensure that an administrator does not do this secretively, it is recommended that you create an audit policy monitoring ALTER USER statements. Also change the password of the SYSTEM user after reactivating it.

Monitor & Detect Usage

Monitor the privileged account activity. When people are aware that they are being monitored, this will reduce the risk of misuse of the privilege account. Monitoring all usage of the privilege users will (probably) be a full-time job, or maybe more. When the request is assigned to the ticketing system, this will make it easier to analyze. High-risk tasks that where performed by the privilege accounts should be stated with warning signs, like different colors. Also monitor if a certain activity is needed on daily basis: and maybe extend the standard authorizations for these users so usage of privilege account is restricted (this whole process costs time).

Detect Usage

Track and alert on user behavior. With up to 80% of breaches involving a compromised user or privileged account, gaining insights into privileged account access and user behavior is a top priority. Ensuring visibility into the access and activity of your privileged accounts in real time will help spot suspected account compromise and potential user abuse.  Behavioral analytics focuses on key data points to establish individual user baselines, including user activity, password access, similar user behavior, and time of access to identify and alert on unusual or abnormal activity.

Respond to Incidents

Prepare an incident response plan in case a privileged account is compromised. When an account is breached, simply changing privileged account passwords or disabling the privileged account is not acceptable. If compromised by an outside attacker, hackers can install malware and even create their own privileged accounts. The incident response plan should at least cover the following topics, so you will know what to do when the breach is discovered:

• Detection of the incident;
• Classification of the incident (CIA);
• Decision on legal actions;
• Hypothesis of affected assets;
• Hypothesis of affected information (risk exposure);
• Assets prioritization;
• Information extraction phase;
• Analysis phase;
• Lessons learned.

Review and Audit

Audit and analyze privileged account usage. Auditors very often want to do an analysis on the usage of the privileged accounts. Here you can ask the auditor the following questions:

• Does the auditor need to perform an audit on the usage of privilege accounts?
• Does the auditor need to perform an audit on the process itself?
• Is the monitoring performed?
• What are the findings?
• And.. Follow up!

Summary

• Create awareness;
• Don't share accounts;
• Write password policy, and implement:
  • Change passwords;
  • Control privilege account creation with formal review and approval process;
  • Restrict access.
• Monitor and report - link to ticketing system;
• Evaluate privileged accounts to set appropriate expiration dates;
• Tooling can support privilege access management.

For the commercial part: CSI Emergency Request is CSI tools' solution for Privilege Access Management for SAP systems. CSI ER provides privileged access to critical assets and meets compliance requirements.