Vous êtes sur la page 1sur 10

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 specic 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 nancial 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 ltering 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, congured for each instance on a host. Therefore, the available services congured 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).

Basis
SAP Audit Guide

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 congured 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 modication 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 congured 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 congured 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 conguration 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 specic 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 lters 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 congured at the entry point of HTTP(S) requests. This will lter URL requests to control program execution. URL rules should be reviewed in the table stored in <ptable>. Since URLs are reviewed on a rst match basis, the table should include a deny-all rule at the end once all the permitted URLs are dened above. Web Dispatchers should be congured 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 congured 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 les and will protect application servers against callback, hijacking, man-in-themiddle and other attacks. The les should also be congured 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 congured with non-dialog user IDs. Trusted connections or connections with stored logon credentials should not be used from systems with lower security classications to systems with higher security classications. Examples would be development to production. Trust relationships should only exist between systems sharing the same security classication. 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 congured in accordance with the principle of least privilege and should be assigned the minimum privileges required for each connection. Therefore, the SAP_ALL authorization prole should not be assigned to such users. Furthermore, authority checks should be enabled through the proper conguration 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 congured 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 identied and reviewed. SAP recommends disabling the services specied 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 identied 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 classications

Upgrade to the latest hashing mechanism, disable downwards compatibility and delete redundant hashes
4
/sap/bc/soap/rfc /sap/bc/echo /sap/bc/FormToRfc /sap/bc/report /sap/bc/xrfc /sap/bc/xrfc_test /sap/bc/error /sap/bc/webrfc Table 1.1 SICF Services 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. Strong password policies should also be congured to manage the risk. Parameters can be checked through the RSPARAM report. Recommended settings for specic 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 congured to the same standards even when ABAP or LDAP systems are used as data sources. They /sap/bc/gui/sap/its/CERTREQ /sap/bc/bsp/sap/certreq /sap/bc/bsp/sap/certmap /sap/bc/gui/sap/its/CERTMAP /sap/bc/bsp/sap/bsp_veri /sap/bc/bsp/sap/icf /sap/bc/IDoc_XML /sap/bc/srt/Idoc can be reviewed in ume.logon.security_policy contained in sapum.properties les. Forbidden passwords should be dened in table USR40. This should include common and trivial passwords. PASSWORD PARAMETER login/min_password_lng login/min_password_letters login/min_password_digits login/min_password_lowercase login/min_password_uppercase login/min_password_specials login/password_max_idle_productive login/password_max_idle_initial login/password_history_size login/password_expiration_time 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 .
RECOMMENDED SETTING

8 6 2 1 1 2 30 5 12 30

5
Central User Management (CUA) CUA is the central instance for prole, 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 dene CUA models and elds 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 specied 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 le. TRANSACTION PFCG SU01 SU02 SU03 SU10 SU20 SU21 SU22 DESCRIPTION Prole Generator Maintain User Prole Maintenance Authorization Maintenance User Mass Maintenance Maintain Authorization Fields Maintain Authorization Objects Authorization Object usage in transactions Mass Changes to User Master Records Role Assignment to Positions The assignment of roles should be separated from the modication 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 congured in the SSM_CUST table. Transaction SUIM should be used to identify users assigned the SAP_NEW prole. 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 dened path from development, test and production environments. This should be veried through review of transport domains, routes, strategies and workows 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. Conguration 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-specic 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.

SU12 PO13

Table 1.3 User Management Transactions

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 eld 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 aws 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 dene the required authorizations, elds 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 identied 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

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. Monitoring Alerts generated by the Security Audit Log for active lters 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 conguration 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 certied 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 condentiality of business information and ensure the authenticity of users. To learn more, please visit www.layersevensecurity.com/consulting or speak to a representative at 1-888 995 0993.

Patch Management SAP periodically releases patches for software aws 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 congured to record specic 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 les stored on application servers. The default size of log les is 1,000,000 bytes (<1MB). Therefore, le sizes should be adjusted in accordance with the volume of events in each environment. Also, les should be regularly archived since logging is automatically blocked once the maximum le size is reached. Static and dynamic lters should be reviewed for specic clients, users and classes to ensure that critical events are congured and logged. Access to transactions SM19 and SM20 for conguring and maintaining the Security Audit Log should be restricted.

Layer Seven Security


About Us Layer Seven Security specialize in SAP security. The company serves customers across the globe to protect SAP systems against internal and external threats and comply with industry and statutory reporting requirements. It fuses technical expertise with business acumen to deliver unparalleled implementation, consulting & audit services targeted at managing risks in contemporary SAP systems. Layer Seven Security employs a distinctive approach to SAP risk management that examines and manages vulnerabilities at the platform, application, program and client level. Through partnerships with leading software developers, the company is able to develop SAP systems with defense in depth and perform integrated security assessments that improve the quality and lower the cost of SAP audits. Layer Seven Security leverage leading SAP-certied solutions to provide comprehensive and rapid results covering risks in every component of SAP landscapes. Address Westbury Corporate Centre Suite 101 2275 Upper Middle Road East Oakville, Ontario L6H 0C3, Canada Web www.layersevensecurity.com Email info@layersevensecurity.com 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 specic 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.

Vous aimerez peut-être aussi