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
Basis SAP Audit Guide
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 available services configured for each instance should be reviewed to ensure unused components are 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
. 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-themiddle 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.
Password Security SAP passwords are stored as one-way hashes in tables USR02, USH02 and USRPWDHISTORY. There are multiple hashing algorithms used by SAP, each identified by a unique code version. Algorithms are vulnerable to brute force and dictionary attacks, particularly code versions such as B and F. The risk of such attacks should be mitigated by implementing the latest
Trusted RFC connections should not be used between systems with differing security classifications
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 sapum.properties files. Forbidden passwords should be defined in table USR40. This should include common and trivial passwords.
/sap/bc/soap/rfc
/sap/bc/gui/sap/its/CERTREQ
/sap/bc/echo
/sap/bc/bsp/sap/certreq
/sap/bc/FormToRfc
/sap/bc/bsp/sap/certmap
/sap/bc/report
/sap/bc/gui/sap/its/CERTMAP
PASSWORD PARAMETER
/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 compatibility. Logons against downwards compatible hashes should be recorded in the system log if disabling is not possible. Redundant hashes should be removed from the tables. Also, access to transaction SE16 should be restricted to a designated authorization group since this can be used to extract user tables.
login/min_password_specials
2
login/password_max_idle_productive
30
login/password_max_idle_initial
5
login/password_history_size
12
login/password_expiration_time
30
Strong password policies should also be configured to manage the risk. Parameters can be checked through the RSPARAM report. Recommended settings for specific parameters are provided in Table 1.2. The login/ password_compliance_to_current_policy parameter should be set to 1 to enforce policies. UME password policies should be configured to the same standards even when ABAP or LDAP systems are used as data sources. They
RECOMMENDED SETTING
Table 1.2 Password Settings The default password for standard users should be changed in all clients. This includes users such as SAP*, DDIC, EARLYWATCH, SAPCPIC, and TMSADM. Report RSUSR003 will detect if default passwords have not been changed. Logons using the SAP* user should disabled .
5 Central User Management (CUA) CUA is the central instance for profile, user and authorization maintenance in SAP landscapes. It is used to distribute and manage user access across all connected systems, known as child or dependent clients, through RFC connections. Transactions SCUA and SCUM are used to define CUA models and fields and therefore, should only be assigned to security administrators. The CUA model should be assessed to ensure that all required systems are administered through the central instance. Access to the transactions specified in table 1.3 used for user management in ABAP systems should be restricted. Relevant authorization objects include S_USER_GRP, S_USER_PRO, S_USER_AUT, S_USER_SYS and S_USER_AGR. For Java systems, access to User Management Engine (UME) actions such as Manage_All, Read_All, Manage_Users, Manage_Groups, and Manage_All_User_Passwords should be controlled. The permission AclSUperUser and Visual Administrator roles used to manage the UME should only be granted to select, authorized administrators. This includes SAP_JAVA_NWADMIN_CENTRAL and SAP_JAVA_NWADMIN_LOCAL. UME permissions and roles should be reviewed in the UMErole.xml file. TRANSACTION
DESCRIPTION
PFCG
Profile Generator
SU01
Maintain User
SU02
Profile Maintenance
SU03
Authorization Maintenance
SU10
User Mass Maintenance
SU20
Maintain Authorization Fields
SU21
Maintain Authorization Objects
SU22
SU12 PO13
Authorization Object usage in transactions Mass Changes to User Master Records Role Assignment to Positions
Table 1.3 User Management Transactions
The assignment of roles should be separated from the modification of roles in ECC 5.0 and above through PRG_CUST settings. This will ensure that an administrator cannot perform both functions. Furthermore, the parameter for authorization object disabling should be monitored to ensure that authorization checks for program execution are enabled. The SAP Menu should be disabled. This menu providers visibility to all transactions available in a client and therefore increases the risk of unauthorized access. The SAP User Menu is preferred since it provides users with information for only those areas to which they have been assigned access. Menu options are configured in the SSM_CUST table. Transaction SUIM should be used to identify users assigned the SAP_NEW profile. The results should be investigated and reviewed with security personnel. The assignment of authorizations for newly created objects to users that do not require such access may indicate underlying issues related to role upgrade procedures.
Change and Transport Management The movement of changes between environments is performed through transports managed by the Transport Management System (TMS). Transports in SAP landscapes should follow a defined path from development, test and production environments. This should be verified through review of transport domains, routes, strategies and workflows in SAP systems within each landscape that act as transport domain controllers. Transport requests and header information are logged in table E070. A sample of changes should be selected from the table and examined to verify compliance with established release management procedures. Samples can also be selected from transport logs available through transaction SE03. Transports for changes to IMG settings and parameters may only be logged in development and test systems. Configuration changes should be locked in production systems. This is achieved through restrictions on the use of transaction SPRO in production and the selection of the parameter 'no changes allowed' for client-specific objects, accessible through transaction SCC4. Certain changes are not transportable and are therefore implemented directly in production clients. Such changes should be documented, pre-approved and performed through special-purpose temporary IDs. Repository and client independent changes 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.
Table Maintenance and System Administration Access to the table maintenance transactions SM30 and SM31, and table browsing functions through SE16, should be restricted to authorized users based on role requirements. This includes the authorization objects S_TABU_CLI and S_TABU_DIS. Authorization groups should be used to control access to critical tables.
Custom programs should be subject to security reviews to detect code-level vulnerabilities
6
7 System administrators should be granted exclusive use of transactions SM49 and SM69 to maintain and perform operating system commands, SM59 to manage RFC destinations, and the following transactions used for batch processing: SM35, SM36, SM37 and SM64. This includes authorization objects S_ADMI_FCD, S_BTCH_ADM, S_BTCH_JOB and S_BDC_MONI.
Patch Management SAP periodically releases patches for software flaws through Security Notes, available at the Service Market Place. Relevant Notes that have not been applied should be identifed through the EarlyWatch report RSECNOTE. Notes with a severity rating of 1 require immediate attention. Notes with a rating of 2, 3 or 4 should be targeted for implementation within 30 days of release. Security Notes may impact interdependencies in SAP environments. Therefore, patches should be applied and tested in non-production environments before they are implemented in production systems.
Security Audit Log The Security Audit Log should be activated and configured to record specific security events such as changes to user 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.
Monitoring Alerts generated by the Security Audit Log for active filters are sent to the Alert Monitor in the Computing Center Management System (CCMS) and should be reviewed by security administrators. CCMS is used to control and monitor system performance. User access to CCMS functions should be closely managed, particularly S_RZL_ADM. This authorization object is used to support an array of system administration programs and tasks including SAPSTART and SAPSTOP. In accordance with SAP recommendations, the security configuration of NetWeaver Application Servers and other components should be regularly monitored to ensure systems remain in a secure state. Layer Seven Security assist customers worldwide to monitor and evaluate SAP platforms. We perform vulnerability assessments for SAP systems using software certified by SAP for integration with NetWeaver Application Servers. The assessments examine over 400 known security vulnerabilities in SAP platforms including many of the areas covered by this guide. According to Gartner Research, vulnerability assessments should be an integral component of integrated security frameworks. They enable organisations to lower the risk of system intrusion, maintain the confidentiality of business information and ensure the authenticity of users. To learn more, please visit www.layersevensecurity.com or speak to a representative at 1-888 995 0993.
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 Westbury Corporate Centre Suite 101 2275 Upper Middle Road Oakville, Ontario L6H 0C3, Canada
Web www.layersevensecurity.com Email [email protected] Telephone 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.
