SAP Audit Guide

for Basis
 This audit guide is designed to assist the
review of middleware components that
support the administration and integration of
SAP applications, commonly referred to as
SAP Basis.

These components are implemented in the NetWeaver

Application Server (AS) and enable SAP applications to
be interoperable between supported operating system
and database platforms.

The specific areas examined in this guide are relevant

parameters, settings, transactions, authorizations and
reports the following areas of the NetWeaver AS:

Network Security

Remote Function Calls (RFC)

Web Services

Password Security

Central User Management (CUA)

Change and Transport Management

Table Maintenance and System Administration

Patch Management

Security Audit Log

Monitoring

The guide is delivered using clear, non-technical terms

to enable financial and operational auditors to
successfully navigate the complexities of SAP security.
Other volumes of this guide deal with SAP controls in
areas such as Financial Accounting, Revenue,
Expenditure, Inventory, and Human Resources.

Network Security

Network-level security for SAP installations should

include surface area reduction. This is applied through
network filtering which limits entry points and therefore
potential avenues of attack against SAP hosts. TCP/IP
ports and protocols should be restricted to the
standard assignments and ranges required by SAP,
configured for each instance on a host. Therefore, the

Basis available services configured for each instance should

be reviewed to ensure unused components are
SAP Audit Guide disabled. Information related to TCP/IP ports used by
SAP applications is available at the SAP Developer
Network (SDN).
 2
Standard network ports required for ABAP services include
32NN (Dispatcher), 33NN (Gateway), 36NN (Message
Server) and 443NN (HTTPS). NN is a placeholder for the
instance number. Common database ports include 1433
(SQL Server),1527 (Oracle) and 4402 (DB2). Java services
typically use the 50000 and above port range. 5NN08 is
used for the Telnet protocol. Telnet can be used for
administration of the J2EE using shell commands and is
accessible by users with the telnet_login security role. This
role should only be assigned to Administrators. The service
is accessible through host 127.0.0.1 (localhost) but should
be disabled in favor of the more secure SSH protocol. FTP
should also be disabled. SSH can be used to support
SFTP.
Access to administrative services such as SSH should only
be permitted from designated subnets or workstations.
This can be applied through properly configured Access
Control Lists (ACLs). ACLs are also required to limit
connections to Gateway Servers, Message Servers and
Management Consoles. This will restrict logons to
approved IP addresses and therefore protect RFC and
server-to-server communications and functions for system
administration. ACL rules should be reviewed for potential
errors and omissions.
Network communications should be encrypted within and
below the application layer to protect the disclosure or
modification of SAP data during transmission. Secure
Network Communication (SNC) should be applied to
encrypt DIAG, RFC, CPIC and other communication paths.
The snc/enable parameter must be set to 1 to apply
encryption. However, SAP application servers can accept
insecure connections even if SNC is enabled. Therefore, it
is important to review SNC parameters for all connection
types to ensure only secure connections are accepted by
servers. The protection level should be set to 3. This will
apply both authentication and encryption. Level 1 is for
authentication only and therefore does not apply
encryption. Application servers should also be configured
to reject insecure RFC connections and attempts to start
programs without SNC protection.
SNC requires the installation of the SAP Cryptographic
Library. Access to the directory storing the Library should
be restricted and access to the cryptographic key tables
should only be granted to users in an appropriately
configured authorization group.
Web-based connections should be secured using HTTPS
(HTTP over SSL/TLS). This includes SAP GUI via HTML,
Enterprise Portal, Management Console and the Internet
Communication Manager (ICM). Unencrypted connections
should be disabled through the appropriate configuration of
the relevant parameters. Single Sign-On tickets should only
sent through HTTPS. Authentication schemes should be
assessed. This includes the default scheme. The use of the
Basic scheme should be avoided since it does not encrypt
authentication data.
VPN over IPSec or SSL should be used to encrypt data in
the network layer when connecting two or more local
networks through untrusted networks. This should be
supported by two factor authentication.
Encryption mechanisms below the application layer must
be transparent to SAP. Transparent Data Encryption for
data at rest can be enabled natively within enterprise-level
databases provided by IBM, Microsoft and Oracle.
Encryption can be applied to specific database columns to
minimize any performance impact. Transport layer
encryption should be applied through SSL v3 to protect
data in transit. Also, SAP recommends locating database
servers in secure network zones protected by packet filters
and application gateways such as SAProuter and the Web
Dispatcher. For SAProuter, IP addresses with access to
SAP systems should be reviewed in the Route Permission
Table. SAP Web Dispatchers should be configured at the
entry point of HTTP(S) requests. This will filter URL requests
to control program execution. URL rules should be
reviewed in the table stored in <ptabfile>. Since URLs are
reviewed on a first match basis, the table should include a
deny-all rule at the end once all the permitted URLs are
defined above. Web Dispatchers should be configured to
support end-to-end SSL. This will ensure that HTTPS
requests are forwarded to application servers without being
decrypted. Requests should be re-encrypted if SSL
termination is enabled.
Remote Function Calls (RFC)
RFCs are used to integrate SAP and non-SAP systems.
They should be closely reviewed since improperly
configured RFCs can lead to the compromise of entire SAP
landscapes. RFC server registration at SAP Gateways
should be restricted to approved IPs. This is performed
through the sec_info and reg_info files and will protect
application servers against callback, hijacking, man-in-the-
middle and other attacks. The files should also be
configured to restrict access to the SAPXPG server.
RFC connections in each system should be examined in the
RFCDES table, accessible through transaction SM59.
Connections, also known as destinations, should be configured
with non-dialog user IDs. Trusted connections or connections
with stored logon credentials should not be used from systems
with lower security classifications to systems with higher security
classifications. Examples would be development to production.
Trust relationships should only exist between systems sharing
the same security classification. Transport Management System
(TMS) destinations are exempted from this rule. Authorization
object S_RFCACL should be used to secure trusted RFC calls.

RFC users should be configured in accordance with the principle

of least privilege and should be assigned the minimum privileges
required for each connection. Therefore, the SAP_ALL
authorization profile should not be assigned to such users.
Furthermore, authority checks should be enabled through the
proper configuration of the auth/rfc_authority_check parameter.
Anonymous RFC calls should be blocked.

Web Services

Web services provide an alternative integration technology to

RFC. The NetWeaver AS incorporates a Web Service
Framework that includes ABAP and Java runtime environments
for SOAP requests, tools that support UDDI registration and an
Internet Communication Manager (ICM) to manage Web service
calls. Default error messages in the ICM may disclose sensitive
system information including hostname, SSID and instance
number. Therefore, custom error pages should be configured for
the ICM.

Web services are created through the ABAP Object Navigator

and Java Developer Studio. Access to the
SAP_BC_WEBSERVICE_ADMIN role, transaction WSADMIN,
and S_ICF_ADMIN authorization object should be restricted to
approved users. Access to transaction SICF should also be
controlled. This is used to manage services in the Internet
Communication Framework (ICF).

Similar to RFC, some services do not require authentication and

others often contain stored logon data. These services should
be identified and reviewed. SAP recommends disabling the
services specified in Table 1.1 if they do not serve business
requirements. These have known security issues.

Trusted RFC
Password Security
connections should
SAP passwords are stored as one-way hashes in tables USR02,
USH02 and USRPWDHISTORY. There are multiple hashing
not be used between
algorithms used by SAP, each identified by a unique code systems with differing
version. Algorithms are vulnerable to brute force and dictionary
attacks, particularly code versions such as B and F. The risk of security classifications
such attacks should be mitigated by implementing the latest 3
 Upgrade to the latest hashing mechanism,
disable downwards compatibility and delete
redundant hashes
4

can be reviewed in ume.logon.security_policy contained in

/sap/bc/soap/rfc /sap/bc/gui/sap/its/CERTREQ
sapum.properties files. Forbidden passwords should be
/sap/bc/echo /sap/bc/bsp/sap/certreq defined in table USR40. This should include common and
trivial passwords.
/sap/bc/FormToRfc /sap/bc/bsp/sap/certmap
RECOMMENDED
/sap/bc/report /sap/bc/gui/sap/its/CERTMAP PASSWORD PARAMETER SETTING

/sap/bc/xrfc /sap/bc/bsp/sap/bsp_veri login/min_password_lng 8

/sap/bc/xrfc_test /sap/bc/bsp/sap/icf login/min_password_letters 6
/sap/bc/error /sap/bc/IDoc_XML login/min_password_digits 2
/sap/bc/webrfc /sap/bc/srt/Idoc login/min_password_lowercase 1

Table 1.1 SICF Services login/min_password_uppercase 1

password hashing mechanism and disabling downwards login/min_password_specials 2

compatibility. Logons against downwards compatible
hashes should be recorded in the system log if disabling is login/password_max_idle_productive 30
not possible. Redundant hashes should be removed from
login/password_max_idle_initial 5
the tables. Also, access to transaction SE16 should be
restricted to a designated authorization group since this login/password_history_size 12
can be used to extract user tables.
login/password_expiration_time 30
Strong password policies should also be configured to
manage the risk. Parameters can be checked through the Table 1.2 Password Settings
RSPARAM report. Recommended settings for specific
parameters are provided in Table 1.2. The login/ The default password for standard users should be
password_compliance_to_current_policy parameter should changed in all clients. This includes users such as SAP*,
be set to 1 to enforce policies. UME password policies DDIC, EARLYWATCH, SAPCPIC, and TMSADM. Report
should be configured to the same standards even when RSUSR003 will detect if default passwords have not been
ABAP or LDAP systems are used as data sources. They changed. Logons using the SAP* user should disabled .
 5

Central User Management (CUA) The assignment of roles should be separated from the
modification of roles in ECC 5.0 and above through
CUA is the central instance for profile, user and PRG_CUST settings. This will ensure that an administrator
authorization maintenance in SAP landscapes. It is used to cannot perform both functions. Furthermore, the parameter
distribute and manage user access across all connected
for authorization object disabling should be monitored to
systems, known as child or dependent clients, through ensure that authorization checks for program execution are
RFC connections. Transactions SCUA and SCUM are used enabled. The SAP Menu should be disabled. This menu
to define CUA models and fields and therefore, should only providers visibility to all transactions available in a client and
be assigned to security administrators. The CUA model therefore increases the risk of unauthorized access. The
should be assessed to ensure that all required systems are
SAP User Menu is preferred since it provides users with
administered through the central instance. information for only those areas to which they have been
Access to the transactions specified in table 1.3 used for assigned access. Menu options are configured in the
user management in ABAP systems should be restricted. SSM_CUST table.
Relevant authorization objects include S_USER_GRP, Transaction SUIM should be used to identify users
S_USER_PRO, S_USER_AUT, S_USER_SYS and
assigned the SAP_NEW profile. The results should be
S_USER_AGR. For Java systems, access to User investigated and reviewed with security personnel. The
Management Engine (UME) actions such as Manage_All, assignment of authorizations for newly created objects to
Read_All, Manage_Users, Manage_Groups, and users that do not require such access may indicate
Manage_All_User_Passwords should be controlled. The underlying issues related to role upgrade procedures.
permission AclSUperUser and Visual Administrator roles
used to manage the UME should only be granted to select,
authorized administrators. This includes
Change and Transport Management
SAP_JAVA_NWADMIN_CENTRAL and
SAP_JAVA_NWADMIN_LOCAL. UME permissions and The movement of changes between environments is
roles should be reviewed in the UMErole.xml file. performed through transports managed by the Transport
Management System (TMS). Transports in SAP landscapes
TRANSACTION DESCRIPTION should follow a defined path from development, test and
production environments. This should be verified through
PFCG Profile Generator review of transport domains, routes, strategies and
SU01 Maintain User workflows in SAP systems within each landscape that act
as transport domain controllers. Transport requests and
SU02 Profile Maintenance header information are logged in table E070. A sample of
changes should be selected from the table and examined
SU03 Authorization Maintenance to verify compliance with established release management
procedures. Samples can also be selected from transport
SU10 User Mass Maintenance
logs available through transaction SE03. Transports for
SU20 Maintain Authorization Fields changes to IMG settings and parameters may only be
logged in development and test systems.
SU21 Maintain Authorization Objects
Configuration changes should be locked in production
Authorization Object usage in systems. This is achieved through restrictions on the use of
SU22
transactions transaction SPRO in production and the selection of the
parameter 'no changes allowed' for client-specific objects,
Mass Changes to User Master accessible through transaction SCC4. Certain changes are
SU12
Records not transportable and are therefore implemented directly in
production clients. Such changes should be documented,
PO13 Role Assignment to Positions pre-approved and performed through special-purpose
temporary IDs. Repository and client independent changes
Table 1.3 User Management Transactions should also be disabled in table T000. This will prevent
changes to ABAP code in production.
Critical change control transactions should be locked in
productive environments. This includes SCC0 (Client Copy) and
SCC5 (Client Delete). Locked transactions are maintained
through transaction SM31. Access to this transaction with the
authorization object S_ADMI_FCD and field TLCK (lock/ unlock)
should be restricted.

Sensitive change control authorizations include S_RZL_ADM,

S_TABU_CLI, S_CLNT_IMP, S_IMG_ACTV, S_QUERY,
S_PROGRAM and S_TRANSPORT. The development
authorization S_DEVELOP should only be granted to developers
for sandbox or development environments, not test and
production. This includes the DEBUG object type which can
enable users to bypass authority-checks (see below).

Developers should not have access to transport functions and the

following database utilities: TABT, TABL, INDX, MACO, MCID,
VIEW and SQLT. These objects should be assigned only to
Database Administrators.

Development procedures should include secure ABAP and Java

program development guidelines for the prevention and detection
of common vulnerabilities such as SQL injection, missing
authorizations, directory traversal and backdoors including
hardcoded users. Procedures should be benchmarked against
recognized frameworks such as the OWASP Development Guide.
Standard SAP functions such Code Inspector (CDI) should not be
exclusively relied upon for code reviews. Such tools are not tuned
to detect the wide number of security flaws that could potentially
impact custom SAP programs. Note that non-standard objects
should be referenced with the customer namespace, usually
ranging between Y and Z.

Authority-check statements should be inserted into the source

code of ABAP programs to define the required authorizations,
fields and values required to execute programs. This is performed
to provide a more granular level of security than transaction-level
checks and to protect transactions or function modules that are
called indirectly by other programs. The RSABAPSC program
should be used to trace the authority-check commands in
custom programs and sub programs. Alternatively, transaction
SE93 can be used to identify programs directly and check for
authority-check statements. Users with access to transactions
SE38, SA38, SE80 and SE37 should be identified and reviewed.
These users may have the authority to run programs not secured
by authorization groups.

Custom programs
Table Maintenance and System Administration
should be subject to
Access to the table maintenance transactions SM30 and SM31,
and table browsing functions through SE16, should be restricted security reviews to
to authorized users based on role requirements. This includes the
authorization objects S_TABU_CLI and S_TABU_DIS.
detect code-level
Authorization groups should be used to control access to critical vulnerabilities
tables. 6
 7

System administrators should be granted exclusive use of Monitoring

transactions SM49 and SM69 to maintain and perform
Alerts generated by the Security Audit Log for active filters
operating system commands, SM59 to manage RFC
are sent to the Alert Monitor in the Computing Center
destinations, and the following transactions used for batch
Management System (CCMS) and should be reviewed by
processing: SM35, SM36, SM37 and SM64. This includes
security administrators. CCMS is used to control and
authorization objects S_ADMI_FCD, S_BTCH_ADM,
monitor system performance. User access to CCMS
S_BTCH_JOB and S_BDC_MONI.
functions should be closely managed, particularly
S_RZL_ADM. This authorization object is used to support
an array of system administration programs and tasks
Patch Management
including SAPSTART and SAPSTOP.
SAP periodically releases patches for software flaws In accordance with SAP recommendations, the security
through Security Notes, available at the Service Market configuration of NetWeaver Application Servers and other
Place. Relevant Notes that have not been applied should components should be regularly monitored to ensure
be identifed through the EarlyWatch report RSECNOTE. systems remain in a secure state. Layer Seven Security
Notes with a severity rating of 1 require immediate
assist customers worldwide to monitor and evaluate SAP
attention. Notes with a rating of 2, 3 or 4 should be platforms. We perform vulnerability assessments for SAP
targeted for implementation within 30 days of release. systems using software certified by SAP for integration with
Security Notes may impact interdependencies in SAP NetWeaver Application Servers. The assessments examine
environments. Therefore, patches should be applied and over 400 known security vulnerabilities in SAP platforms
tested in non-production environments before they are
including many of the areas covered by this guide.
implemented in production systems. According to Gartner Research, vulnerability assessments
should be an integral component of integrated security
frameworks. They enable organisations to lower the risk of
Security Audit Log system intrusion, maintain the confidentiality of business
information and ensure the authenticity of users. To learn
The Security Audit Log should be activated and configured
more, please visit www.layersevensecurity.com or speak to
to record specific security events such as changes to user
a representative at 1-888 995 0993.
records and successful and unsuccessful logons, including
those for the user SAP*. These events are recorded in local
files stored on application servers. The default size of log
files is 1,000,000 bytes (<1MB). Therefore, file sizes should
be adjusted in accordance with the volume of events in
each environment. Also, files should be regularly archived
since logging is automatically blocked once the maximum
file size is reached. Static and dynamic filters should be
reviewed for specific clients, users and classes to ensure
that critical events are configured and logged. Access to
transactions SM19 and SM20 for configuring and
maintaining the Security Audit Log should be restricted.
Layer Seven Security empowers organisations to realize the potential of
SAP systems. We serve customers worldwide to secure systems from
cyber threats. We take an integrated approach to build layered controls for
defense in depth

Address Web
Westbury Corporate Centre www.layersevensecurity.com
Suite 101 Email
2275 Upper Middle Road info@layersevensecurity.com
Oakville, Ontario Telephone
L6H 0C3, Canada 1 888 995 0993
© Copyright Layer Seven Security 2013 - All rights reserved.

No portion of this document may be reproduced in whole or in part without the prior written
permission of Layer Seven Security.

Layer Seven Security offers no specific guarantee regarding the accuracy or completeness of the
information presented, but the professional staff of Layer Seven Security makes every reasonable
effort to present the most reliable information available to it and to meet or exceed any applicable
industry standards.

This publication contains references to the products of SAP AG. SAP, R/3, xApps, xApp, SAP
NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and
services mentioned herein are trademarks or registered trademarks of SAP AG in Germany and in
several other countries all over the world. Business Objects and the Business Objects logo,
BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius and other Business
Objects products and services mentioned herein are trademarks or registered trademarks of Business
Objects in the United States and/or other countries.