.xml

<?xml version="1.0" encoding="UTF-8" ?><root><Name>Core Business Application - SAP Security Maturity Model</Name><ShortName>CBAS-SAPSMM</ShortName><Version>0.8</Version><Description>The SAP Security Maturity Model is a definition of controls to help SAP using organizations, security professionals,  service providers, tool vendors to define, test and verify the security of business critical SAP infrastructures.</Description><Controls><item><Shortcode>DT-P-AE-M01-003</Shortcode><Security_Function> DT</Security_Function><CSF_Category> Anomalies and Events</CSF_Category><Technology> SAP ERP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
System logs:

Identifying and collecting system problems through system logs is important to enabling the system to run with good performance. Maintaining the healthiness of your system and keeping it running avoids any service disruptions that may be caused by errors.

</Description><Implementation>
Whether your organization is running a UNIX or Windows host, systems logs should be checked on a regular basis. It is recommended to send the logs to a central location to avoid any logs that might overwritten once the buffer is full; especially in Windows hosts.

Alerts can be configured when a certain event occurs or a threshold is reached, this helps automate the review process of system logs and reduces workload from administrators. Sending logs to a central location helps to achieve setting up alerts.

</Implementation><Verification><item></item><item>- Check system logs through the SM21 transaction</item><item>- Configure alerts for certain events such as rollbacks and system error messages to reactively respond and fix issues</item></Verification><References></References></item><item><Shortcode>PT-P-AC-M01-001</Shortcode><Security_Function> Protect</Security_Function><CSF_Category> Identity Management, Authentication and Access Control</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Authorization, permission, and access for SAP standard users must properly be secured and configured within the operating system in use.
</Description><Implementation>
Like local users and domain users on a Windows machine, SAP standard users must have the appropriate permissions and authorizations within the OS.

- Restrict access to root, SAPsid, and dbsid users on each system  
- Lock dbsid user from all application serves after initial installation
- SAPsid should not have any rights for interactive logon

Note: SAP systems must not be installed on domain controllers
</Implementation><Verification><item></item><item>- Verify SAP system is not install on the domain controller</item><item>- Verify that all restrictions for SAP users are in place</item><item></item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A16 Implementation of security requirements for the Windows (S) operating system / Umsetzung von Sicherheitsanforderungen für das Betriebssystem Windows (S)</item><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A17 Implementation of security requirements for the Unix (S) operating system / Umsetzung von Sicherheitsanforderungen für das Betriebssystem Unix (S)</item><item>- CIS CSC 3, 5, 12, 14, 15, 16, 18</item><item>- COBIT 5 DSS05.04</item><item>- ISA 62443-2-1:2009 4.3.3.7.3</item><item>- ISA 62443-3-3:2013 SR 2.1</item><item>- ISO/IEC 27001:2013 A.6.1.2, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5</item><item>- NIST SP 800-53 Rev. 4 AC-1, AC-2, AC-3, AC-5, AC-6, AC-14, AC-16, AC-24</item></References></item><item><Shortcode>PT-I-IP-M01-001</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> SAP ABAP</Technology><Maturity_Level> 1</Maturity_Level><IPAC></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
To properly secure the Remote Function Call (RFC) interface used as a communication interface between SAP systems, all RFC connections, RFC authorizations, and RFC interfaces must be considered.
</Description><Implementation>
For all RFC connections, a uniform administrative guideline must be available; ownership and usage of the RFC connection should be clearly documented. A complete inventory must also be defined and documented for all RFC connections.

Any RFC connections that are not in use must be deleted. (Documentation should reflect the same)

</Implementation><Verification><item></item><item>- [ ] Determine if an RFC connection is in use through using the RFC runtime monitor transaction SRTM or the workload monitor transaction ST03N</item><item>- [ ] Delete any RFC connections not in use</item><item>- [ ] Guidelines in regards to existing RFC connections are available and up to date</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A8 Securing the SAP RFC interface/ Absicherung der SAP-RFC-Schnittstelle</item><item>- SAP Security Baseline Template V2.0: 2.3.2.3</item></References></item><item><Shortcode>PT-I-PT-M01-003</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Protective Technology</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>I</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Any communication with or between different SAP systems must be encrypted. The Secure Network Communication (SNC) enables you to encrypt communications between different systems.

SNC can only be used with SAP protocols, any other internet protocols should be protected by enabling TLS.
</Description><Implementation>
Make sure you have knowledge and understanding of the Public Key Infrastructure (PKI) before moving forward.

The control illustrates how to configure the SAProuter to use SNC.

- Download and extract the CommonCryptoLib from SAP support portal

- Set the environment variable SNC_LIB = \&lt;path to the CommonCryptoLib\&gt;

- Set the environment variable SECUDIR = \&lt;saprouter directory\&gt;/sec

- Sign a certificate for your SAProuter through a Certificate Authority (CA) you trust or through SAP

- Generate your Personal Security Environment (PSE) files by running the following command where you placed your SAProuter files. *sapgenpse get_pse -v -a sha256WithRsaEncryption -s 2048 -r \&lt;csrfile\&gt; -p local.pse -x \&lt;password\&gt; &quot;CN=\&lt;YOUR SPECIFIC CN\&gt;&quot;*. The \&lt;csrfile\&gt; is the file name of your choosing that will be used for your Certificate Signing Request (CSR)

- Submit the \&lt;csrfile\&gt; file to your Certificate Authority (CA) to receive the certificate to proceed

-  Copy content of the received certificate to a file on your SAProuter system and import with the following command *sapgenpse import_own_cert -c \&lt;certca\&gt; -r \&lt;root CA certificate\&gt; -p local.pse*. The \&lt;certca\&gt; is the file received from your CA and \&lt;root CA certificate\&gt; is the root certificate from the CA

- Generate the credentials file with the following command *sapgenpse seclogin -p local.pse \&lt;pse password\&gt;*

- Test to check whether everything is configured and installed correctly *sapgenpse get_my_name -v -n Issuer*

- Set an ACL in your saprouttab file to allow SNC connections

- Start the SAProuter using its SNC name

In order to secure communications with external SAP products, such as SAP Single Sign-On, you should refer to the security notes for that specific product.

Note: Prior to SAP NetWeaver 7.40, SNC tab is only shown if the snc/enable parameter is enabled
</Implementation><Verification><item></item><item>- Verify whether everything is configured and installed correctly *sapgenpse get_my_name -v -n Issuer*</item><item>- Verify ACL file (saprouttab) to verify if SNC connections are allowed</item><item></item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A18 Disconnection of unsafe communication/ Abschaltung von unsicherer Kommunikation</item><item>- CIS CSC 8, 12, 15</item><item>- COBIT 5 DSS05.02, APO13.01</item><item>- ISA 62443-3-3:2013 SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6</item><item>- ISO/IEC 27001:2013 A.13.1.1, A.13.2.1, A.14.1.3</item><item>- NIST SP 800-53 Rev. 4 AC-4, AC-17, AC-18, CP-8, SC-7, SC-19, SC-20, SC-21, SC-22, SC-23, SC-24, SC-25, SC-29, SC-32, SC-36, SC-37, SC-38, SC-39, SC-40, SC-41, SC-43</item></References></item><item><Shortcode>DT-P-AE-M01-007</Shortcode><Security_Function> DT</Security_Function><CSF_Category> Anomalies and Events</CSF_Category><Technology> SAP ERP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
User information system:

Important tool for both internal and external audit. It helps identifying anomalies in different lists found in the user information tool.
</Description><Implementation>
It is recommended to regularly check the different information available through the user information system to keep your SAP system in compliance with internal policies or external regulations as well as determining any changes that have not been internally approved.

Usage:
- Maintenance of critical authorizations and authorization combinations
- Assess list of users that are assigned to critical or high classification authorizations
- Asses which transactions contained in specific roles
- Compare roles, users, profiles, and authorizations in a single system or across systems
- Assess display change documents for the authorization profile of users, security policies, and central user administration (CUA) settings

</Implementation><Verification><item></item><item></item></Verification><References><item>- [SAP Support](https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-US/52/671261439b11d1896f0000e8322d00/content.htm?no_cache=true)</item></References></item><item><Shortcode>IY-C-RA-M01-003</Shortcode><Security_Function> IY</Security_Function><CSF_Category> Risk Assessment</CSF_Category><Technology> ABAP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>C</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Protection of security sensitive data.

SAP systems contain large volumes of business-critical data. The SAP standard system provides various mechanisms to protect this critical data against unauthorized access.
However, errors in custom developments can enable unauthorized accesses and data leakage. If an employee obtains unauthorized access to data, he can subsequently transfer this data to an environment that is no longer controllable by the company.

</Description><Implementation>
1. The specification of the change includes a concise description of the required data protection adjustments according to the change.

2. As part of code change review process all custom code has to be checked to carry that:
  - Business-critical data must also be protected by the program against unauthorized access.
  - Company rules and, in particular, legal regulations must be complied with. Like:
    -	Handling of login data These requirements for the protection of data must be complied with especially during the processing and administration of login data. This includes, in addition to login tokens, passwords and other possible authentication factors, also user names and identity information relating to users. Authentication features must satisfy the requirements of the strictest confidentiality when saved, transferred and during input. For example:
      - Saving of passwords in the source text of programs is an infringement of this requirement.
      - The plain text display of passwords on login screens is an infringement of this requirement.
      - Saving of passwords in plain text in database tables or in the data system is an infringement of this requirement.
    identity information must be protected with particular care against unauthorized, and unreasonable  also in log and event data created by the software.
</Implementation><Verification><item></item><item>- Review if data protection requirements are specified and documented, and their verification is documented in the test protocol of the change.</item><item>- Audit if the source code review is carried out and documented on all custom code changes for the correct implementation of data protection criteria.</item></Verification><References><item></item><item>- CIS CSC 4</item><item>- COBIT 5 APO12.01, APO12.02, APO12.03, APO12.04</item><item>- ISA 62443-2-1:2009 4.2.3, 4.2.3.9, 4.2.3.12</item><item>- ISO/IEC 27001:2013 Clause 6.1.2</item><item>- NIST SP 800-53 Rev. 4 RA-3, SI-5, PM-12, PM-16</item><item>- OWASP ASVS 2.0 V8.3.1, V8.3.4</item></References></item><item><Shortcode>PT-A-AC-M01-011</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Identity Management, Authentication and Access Control</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>A</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Single Sign-On (SSO) is recommended to be configured when multiple SAP systems are running in the organization&apos;s environment. SSO can simplify the process of managing and configuring user authorization to multiple systems and applications. Allowing a single user to access multiple applications comes with its own security risks and threats; a secure configuration of the issued logon tickets must be in place to avoid potential threats.  
</Description><Implementation>
In order to protect issued logon tickets during transport, in ABAP based systems, the below profile parameters are required to be in place.  

- [ ] Use HTTPS by setting login/ticket_only_by_https = 1
- [ ] To make sure that the login ticket is sent back to the creating host set login/ticket_only_to_host = 1
- [ ] Declare a cookie as HTTPonly by setting icf/set_HTTPonly_flag_on_cookies = 1 or 3, this denies access to the issued cookie from the clients web browser by other applications such as applets, plug-ins and so on.


Note: This control assumes that SSO is already configured and used in the organization.
</Implementation><Verification><item></item><item>- [ ] Verify if HTTPS profile parameter is set by checking login/ticket_only_by_https</item><item>- [ ] Verify that only the creating host receives the logon ticket by checking login/ticket_only_to_host</item><item>- [ ] Verify if the profile parameter icf/set_HTTPonly_flag_on_cookies = 1 or 3</item><item></item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A31 Configuration of SAP Single Sign-On (S) / Konfiguration von SAP Single-Sign-On (S)</item><item>- SAP Security Baseline Template V2.1: 2.3.2.4.1</item></References></item><item><Shortcode>PT-A-AC-M01-001</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Identity Management, Authentication and Access Control</CSF_Category><Technology> SAP ABAP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>A</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
SAP user administration should be only allowed to administrators that are identified by the organization and have the appropriate rights to handle the creation, deletion, assigning roles and profiles, and password management of users.
</Description><Implementation>
Rights to administer users in SAP should only be given to users that have the same job role or identified by the organization(1).

Logging and monitoring SAP administrators allows easier identification of administrative misuse.

(1) - Most user administrators are from the IT department in organizations. Some organizations leave the user administration to HR, which is more preferable.

</Implementation><Verification><item></item><item>- Identify SAP user administrators and verify that these roles are given to only allowed users</item><item>- Logs are available to verify the misuse of administrative actions</item><item>- Monitoring is available to detect any misuse with user administration</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A5 Configuration and protection of the SAP user administration / Konfiguration und Absicherung der SAP-Benutzerverwaltung</item><item>- SAP Security Baseline Template V2.1: 2.3.1</item><item>- CIS CSC 1, 5, 15, 16</item><item>- COBIT 5 DSS05.04, DSS06.03</item><item>- ISA 62443-2-1:2009 4.3.3.5.1</item><item>- ISA 62443-3-3:2013 SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9</item><item>- ISO/IEC 27001:2013 A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3</item><item>- NIST SP 800-53 Rev. 4 AC-1, AC-2, IA-1, IA-2, IA-3, IA-4, IA-5, IA-6, IA-7, IA-8, IA-9, IA-10, IA-11</item></References></item><item><Shortcode>PT-P-DS-M01-003</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Data Security</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
To reduce the amount of information disclosed during reconnaissance by adversaries, it is recommended to remove any system version information or detailed error logs that can be gathered to exploit possible vulnerabilities that might arise from this information.
</Description><Implementation>
To remove any version from your organization&apos;s SAP Java system set the UseServerHeader setting to false in both the HTTP provider service (global configuration of dispatcher) and server nodes.

</Implementation><Verification><item></item><item>- [ ] Set UserServerHeader to false in the HTTP provider service in the global configuration of dispatcher</item><item>- [ ] Set UserServerHeader to false in the server nodes</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A1 Secure configuration of the SAP ABAP stack (B) / Sichere Konfiguration des SAP-ABAP-Stacks (B)</item><item>- SAP Security Baseline Template V2.1: 2.2.1.2.2</item></References></item><item><Shortcode>PT-I-IP-M01-005</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
RFC gateways are commonly found on ABAP, Java and stand-alone systems. Securing access for the different RFC services mitigates unauthenticated and un-authorized access from taking place.
</Description><Implementation>
Profile parameters should be set for the different systems to restrict access from different RFC connections.

Profile parameters:

1. gw/sec_info to be set to absolute filename of secinfo (ACL file)
2. gw/reg_info to be set to absolute filename of reginfo (ACL file)
3. gw/reg_no_conn_info set to 1 or higher odd numbers
4. gw/acl_mode set to 1 (initial security environment), if gateway access lists do not exist or not linked to the profile parameters, setting this profile parameter can break connections.
5. gw/monitor set to 1 (monitoring to be set to local access only)
6. gw/sim_mode set to 0 (can temporarily be set to 1 to test ACL files, and find missing entries to be added to the ACL. Do not keep the value to 1)
7. gw/rem_start set to disable or SSH_SHELL (An acceptable method to allow the start of programs via the RFC gateway)
</Implementation><Verification><item></item><item>- Profile parameters are set as per the implementation section</item><item>- Missing entries are detected and added to the access control list (see no. 6 in implementation section)</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A8 Securing the SAP RFC interface/ Absicherung der SAP-RFC-Schnittstelle</item><item>- SAP Security Baseline Template V2.0: 2.3.2.3.1</item><item>- SAP Note 1480644</item><item>- SAP Note 1408081</item><item>- SAP Note 1444282</item><item>- SAP Note 1298433</item><item>- SAP Note 64016</item><item>- SAP Note 1689663</item></References></item><item><Shortcode>DT-P-AE-M01-006</Shortcode><Security_Function> DT</Security_Function><CSF_Category> Anomalies and Events</CSF_Category><Technology> SAP ERP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Read access logging:

An important tool used to monitor and record any read access to classified or sensitive data found in SAP systems. The tool helps when investigating a security breach or information leak.  

</Description><Implementation>
The below configuration steps are required to be in place to monitor and configure read access logging (RAL).

1. Identify what type of data to log through the read access logging
2. Declare a purpose for logging the data to help identify data of regulatory relevance
3. Define the interfaces to monitor by RAL channels
4. Define the log domains of the different channels
5. Define a condition for the application to log the data

</Implementation><Verification><item></item><item>- Configure and monitor the read access logging through the SRALMANAGER transaction</item></Verification><References></References></item><item><Shortcode>IY-C-RA-M01-002</Shortcode><Security_Function> IY</Security_Function><CSF_Category> Risk Assessment</CSF_Category><Technology> ABAP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>C</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Testability of ABAP software implementations.

A central security concept in the SAP standard system is the separation of development, test and productive systems.
The test system plays an important role here. In the test system, the decision is made as to whether an application satisfies the requirements of the company. In this process, both functional and non-functional quality aspects of the application are checked. For a quality check to provide reliable results, it is not sufficient for the tester to have comprehensive expertise in the quality assurance field. The application itself must also be testable. This means that a tester can run the application for test purposes and that, in cases of doubt, the tester can analyse the source code of the application.

If specific functionality in an application cannot be run (by a tester) in the test system, the tester cannot determine whether it satisfies the quality requirements. In this case, unchecked code would be transferred to a productive system exposing unverified risk to the system.
</Description><Implementation>
1. All custom developments that are to be used in systems processing productive data must be testable. This means that all functionality is documented and can be analysed and run in a test system.

2. Custom developments that should not be used in systems processing productive data shall not be deployed to according systems

3. As part of code change review process all custom code has to be checked to carry that:
  - security requirements are implemented with standardized and traceable procedures. Concealment is not a valid security strategy.
  - The change implements an architecture and uses interfaces in such a way that implemented security mechanisms for the protection of your business logic cannot be circumvented by side-effects or by reusing components of the change&apos;s implementation.
  - No part of the implementation uses code code obfuscation like the ABAP code hiding feature available up the ABAP release 7.4x
  - The implementation does not limit to run code based on system variables like sy-mandt and sy-sysid, providing the information to an ABAP program on the executing system in which it is currently being run if testing can&apos;t simulate the target system accordingly.
</Implementation><Verification><item></item><item>- [ ] Review if test execution criteria, and path are specified and documented, and their execution is documented in the test protocol of the change.</item><item>- [ ] Audit if the source code review is carried out and documented on all custom code changes for the correct implementation of testability in the change.</item></Verification><References><item></item><item>- CIS CSC 4</item><item>- COBIT 5 APO12.01, APO12.02, APO12.03, APO12.04</item><item>- ISA 62443-2-1:2009 4.2.3, 4.2.3.9, 4.2.3.12</item><item>- ISO/IEC 27001:2013 Clause 6.1.2</item><item>- NIST SP 800-53 Rev. 4 RA-3, SI-5, PM-12, PM-16</item><item>- BSI APP (February 2020) 4.6 A16, A21</item></References></item><item><Shortcode>PT-A-AC-M01-010</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Identity Management, Authentication and Access Control</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>A</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
SAP standard users are required to be managed and securely configured to avoid any misuse to SAP systems. This includes changing default passwords and restricting standard users.
</Description><Implementation>
The below standard user, found in HANA, are required to be managed and securely configured: (The Verification of Control section will help organizations have the basic requirements to secure the user)
1. SYSTEM

</Implementation><Verification><item></item><item>- SYSTEM</item><item>  - Administrator users have been created</item><item>  - SYSTEM user to be deactivated</item><item>  - Do not restrict the valid time range of user SYSTEM</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A4 Configuration and protection of the SAP user administration / Konfiguration und Absicherung der SAP-Benutzerverwaltung</item><item>- SAP Security Baseline Template V2.1: 2.3.1.2.2</item></References></item><item><Shortcode>PT-P-DS-M01-002</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Data Security</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
To reduce the amount of information disclosed during reconnaissance by adversaries, it is recommended to remove any system version information or detailed error logs that can be gathered to exploit possible vulnerabilities that might arise from this information.
</Description><Implementation>
To remove any detailed errors from your organization&apos;s SAP ABAP system set the login/show_detailed_errors profile parameter to 0.

Use the below parameters to view and change parameters:

- RZ11 transaction: to view information about parameters
- RZ10 transaction: to view and change profile parameters
- RSPARAM report to view parameters (use transaction SA38)

</Implementation><Verification><item></item><item>- [ ] profile parameter login/show_detailed_errors=0</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A1 Secure configuration of the SAP ABAP stack (B) / Sichere Konfiguration des SAP-ABAP-Stacks (B)</item><item>- SAP Security Baseline Template V2.1: 2.2.1.2.1</item></References></item><item><Shortcode>DT-P-AE-M01-002</Shortcode><Security_Function> DT</Security_Function><CSF_Category> Anomalies and Events</CSF_Category><Technology> SAP ERP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Security audit logs:

Identifying and collecting security-related activities is important for evidence collection following a security incident or event. The security audit log might contain sensitive data that needs to be stored and encrypted properly.  
</Description><Implementation>
Activating security audit logs depends on which logs your organization wants to collect. Available logs are shown below:

- Successful and unsuccessful dialog logon attempts
- Successful and unsuccessful RFC logon attempts
- RFCs to function modules
- Changes to user master records
- Successful and unsuccessful transaction starts
- Successful and unsuccessful report starts
- Changes to the audit configuration
- Activation and deactivation of the HTTP security session management or instances in which HTTP security sections were hard-exited
- File downloads
- Access to the file system that coincides with the valid logical paths and file names specified in the system  (particularly helpful in an analysis phase to determine where access to files takes place before activating the actual validation)
- ICF recorder entries or changes to the administration settings
- The use of digital signature validations performed by the system
- Viruses found by the Virus Scan Interface
- Errors that occur in the Virus Scan Interface
- Unsuccessful password checks for a specific user in a specific client

Personal identifiable information can be found in certain security audit logs, make sure to follow any data protection regulations your organizations falls under when storing personal information.

Alerts can be configured when a certain event occurs or a threshold is reached, this helps automate the review process of security audit logs and reduces workload from administrators. Sending logs to a central location helps to achieve setting up alerts.
</Implementation><Verification><item></item><item>- Configure alerts for important events to reactively respond to security events</item><item></item></Verification><References></References></item><item><Shortcode>PT-I-PT-M01-002</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Protective Technology</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>I</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
When using SAPGUI or RFC connections to access published SAP systems that pertain to your organizations, from the internet, or different external networks, SAProuter must be properly configured to allow and deny traffic. The SAProuter must also work hand-in-hand with the firewall to adopt different access rules and allow a multi-access control architecture.
</Description><Implementation>
Implementing secure connections from external networks or the internet requires continuous tuning and adjustments to deny unauthorized access to SAP systems. The below implementation is a baseline to allow organizations to implement secure connections to their internal systems.

- Configure your firewall to allow only one port, 32NN, where NN is the organization&apos;s instance number for the SAProuter
- Configure SNC(1) to allow and authorize SAP support to login to your system securely. (This is mainly for support purposes)
- Configure an implicit deny on the last line of the ACL file (routtab file), (Deny all traffic with the following rule D * * *)
- Configure authorized connections using SAPGUI to use SAProuter for connection
- In case a connection from unmanaged devices is required configure a specific authorized connections by using a secure password (Update routtab file for example P * * 3201 secure_password, allows requests to port 3201 if a password is used)
- Continuous monitoring of the dev_route log. This will enable security teams to tune their ACLs according to their needs


(1) - Reference control PT-I-PT-M01-003 to configure and enable SNC
</Implementation><Verification><item></item><item>- Verify ACL file (routtab) to allocate any unwanted or misconfigured rules</item><item>- Verify that an implicit deny is avaiable in the ACL file (i.e. D * * *)</item><item>- Verify that a secure password is configured for authorized traffic</item><item>- Verify that connections coming from SAPGUI are configured to us the SAProuter</item><item>- Verify that the firewall is configured to allow the one port number for SAProuter</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A3 Network Security/ Netzsicherheit</item><item>- CIS CSC 8, 12, 15</item><item>- COBIT 5 DSS05.02, APO13.01</item><item>- ISA 62443-3-3:2013 SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6</item><item>- ISO/IEC 27001:2013 A.13.1.1, A.13.2.1, A.14.1.3</item><item>- NIST SP 800-53 Rev. 4 AC-4, AC-17, AC-18, CP-8, SC-7, SC-19, SC-20, SC-21, SC-22, SC-23, SC-24, SC-25, SC-29, SC-32, SC-36, SC-37, SC- 38, SC-39, SC-40, SC-41, SC-43</item></References></item><item><Shortcode>PT-P-PT-M01-010</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Protective Technology</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Securing malicious or unrecognized access to the application servers through the message server is critical to maintaining the integrity, availability, and confidentiality of different requests between application servers of an SAP system working as a cluster.
</Description><Implementation>
A network device acting as a rogue application servers can pose a high risk to the organization if communication is allowed to legitimate application servers.

Access control lists (ACLs) must be configured for the message server to contain and defend against attacks on the trust relationship between legitimate application servers.

- Profile parameter ms/acl_info is created in the default profile and refers to a valid ACL file.
- ACL file should not contain an entry for to allow all hosts (i.e. HOST=* is critical)
- Split ports on message server for internal (1) and external communication (2)
- Profile parameter rdisp/msserv_internal defines the internal ports to use
- Block communication from external to the port defined in profile parameter rdisp/msserv_internal
- Deny external monitoring of the message server though setting the profile parameter ms/monitor=0
- Deny external administration of the message server though setting the profile parameter ms/admin_port=0

(1) - Internal communication is for communication between different application serves in the organization

(2) - External communication is for communication with the users/clients
</Implementation><Verification><item></item><item>- Verify the ACLs for the message server fro the profile parameter ms/acl_info</item><item>- Verify that HOST=* is not defined in the ACL</item><item>- Verify that ports are split for internal and external traffic and that the firewall is blocking communication to the internal port for all hosts not belonging to the system cluster.</item><item>- Verify that profile parameter ms/monitor=0</item><item>- Verify that profile parameter ms/admin_port=0</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A9 Protection and monitoring of the message server (B) / Absicherung und Überwachung des Message-Servers (B)</item><item>- SAP Security Baseline Template V2.1: 2.2.1.4, 2.2.1.4.1, 2.2.1.4.2</item></References></item><item><Shortcode>PT-P-IP-M01-012</Shortcode><Security_Function> Protect</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Strengthening and hardening the OS running the organization&apos;s SAP system is critical to securing your SAP implementation and network.
</Description><Implementation>
If your organization deploys other application on Linux, there should already be a defined baseline when deploying Linux machines. With that in mind, the below are a few areas to keep in mind while hardening SAP systems running on Linux.

 - Prohibit root logons remotely 
 - Remove unneeded services and accounts
 - Remove any unneeded Linux applications, features, roles, and components
 - Disable the use of X window systems (SAP applications do not require it)
 - Do not use telnet or FTP for file transfer  
 - Updates to be applied regularly
 - Avoid using SUID/SGID with potentially vulnerable programs
 - Files are created with the appropriate permission through configuring the default file mask
 - Regularly check signatures and keys on downloaded applications or patches

It is recommended to follow the organization&apos;s baseline, if it exists, for securing Linux machines.

If your organization is using SUSE Linux for hosting SAP applications, below are additional points to consider:

- Install and configure the SUSE security checker (seccheck) to enable notifications of any security changes
</Implementation><Verification><item></item><item>- Verify that unwanted applications, services, features, roles, and components are removed</item><item>- Verify if file permissions are properly configured</item><item>- Verify that telnet and FTP are not in use</item><item>- Verify that security updates are done regularly  </item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A16 Implementation of security requirements for the Windows (S) operating system / Umsetzung von Sicherheitsanforderungen für das Betriebssystem Windows (S)</item></References></item><item><Shortcode>PT-PA-IP-M01-002</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> Process &amp; Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item><item>A</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
 Standard user allowed to access SAP systems should be properly managed and configured. This will allow organizations to follow the least privilege principle.
</Description><Implementation>
Default passwords for the standard users should be changed and the companies password policy(1) should be applied. This applies in particular to the users defined during installation (list according to SAP name proposal):
- J2EE_ADM_\&lt;SID\&gt;
- J2EE_GST_\&lt;SID\&gt; 
- SAPJSF_\&lt;SID\&gt;
- Administrator
- Guest
- pcd_service
- ume_service
- SAP\*

Standard users that are not required should be deleted or disabled.

Standard user IDs such as EARLYWATCH should not exist in any client.

Self registration should not be allowed and turned off for better access control.

(1) Password policies changes across different organizations depending on several criteria&apos;s such criticality of the industry, local or federal laws, security standards that are mandatory to the industry and so on  
</Implementation><Verification><item></item><item>- Default password for standard user IDs are changed</item><item>- Password policy is applied properly across SAP systems</item><item>- Standard user IDs are deleted and disabled when not in use</item><item>- User self registration is turned off</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A4 Protection of the delivered SAP standard user IDs / Absicherung der ausgelieferten SAP-Standardbenutzer-Kennungen</item><item>- SAP Security Baseline Template V2.0: 2.3.1</item></References></item><item><Shortcode>PT-P-IP-M01-013</Shortcode><Security_Function> Protect</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Strengthening and hardening the OS running the organization&apos;s SAP system is critical to securing your SAP implementation and network. The windows operating system is quite famous for its abundance of vulnerabilities found daily.  
</Description><Implementation>
If your organization runs a Windows environment, there should already be a defined baseline when deploying Windows machines. With that in mind, the below are a few areas to keep in mind while hardening SAP systems running on Windows OS.

 - Disable or secure remote desktop
 - Remove unneeded services and accounts
 - Remove any unneeded Windows applications, features, roles, and components
 - Local administrator accounts to be disabled or secured  
 - Updates to be applied regularly

It is recommended to follow the organization&apos;s baseline, if it exists, for securing Windows machines.
</Implementation><Verification><item></item><item>- Verify that unwanted applications, services, features, roles, and components are removed</item><item>- Verify that local administrators accounts are disable or properly secure</item><item>- Verify that security updates are done regularly  </item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A16 Implementation of security requirements for the Windows (S) operating system / Umsetzung von Sicherheitsanforderungen für das Betriebssystem Windows (S)</item></References></item><item><Shortcode>PT-P-IP-M01-003</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> Process / Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
To reduce any potential threats found in vulnerable SAP systems and maintain the organization&apos;s required security level, security professionals must regularly update security and software updates.

</Description><Implementation>
SAP Security Notes are usually released every second Tuesday of every month. These notes help in mitigating discovered vulnerabilities throughout SAP systems.

Places to get the latest SAP security notes and support packages:
- SAP Software Update Manager (license is required)
- SAP Patch Management tool (start with SPAM transaction; it will require a maintenance certificate)
- Identify SAP security notes for the system by using SNOTE transaction
- SAP Security Notes found in the SAP Support Launchpad

It is necessary to follow a patch management process [1] in order to maintain the availability and integrity of production systems.

[1] - It is recommended create a patch management process, if there is no process already existing in your organization; the process should also be applied to non-SAP solutions.
</Implementation><Verification><item></item><item>- Schedule a regular patching process to SAP systems</item><item>- Create/Follow a patch management process to maintain integrity and availability of SAP systems</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A1 Secure configuration of the SAP ABAP stack (B) / Sichere Konfiguration des SAP-ABAP-Stacks (B)</item><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A10 Regular implementation of security corrections [specialist department] (B) / Regelmäßige Implementierung von Sicherheitskorrekturen [Fachabteilung] (B)</item><item>- SAP Security Baseline Template V2.0: 2.2.2.1, 2.2.2.1.1, 2.2.2.1.2, 2.2.2.1.2, 2.2.2.1.3</item></References></item><item><Shortcode>PT-P-PT-M01-001</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Protective Technology</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Security Audit Logs (SAL) are important to be activated and properly configured throughout the entire SAP environment. This help security teams identify and detect potential threats that might affect their environment.
</Description><Implementation>
It is important to activate and properly configure profile parameters pertaining to security audit logs. The following parameters help to do so:

- Use transaction RSAU_CONFIG or SM19 to set the required parameters
- rsau/enable = 1
- Specify the location of the security audit log by setting the rsau/local/file
- rsau/integrity = 1
- rsau/log_peer_address = 1 (note: the parameter can cause warnings, but these can be ignored without any problems)
- rsau/selection_slots ≥ 10 5
- rsau/user_selection = 1
- Specify the maximum length of the log by setting the rsau/max_diskspace_local

The following minimal settings of the security audit log must be implemented:

- Auditing should be active
- Active filter with generic user selection for all critical events
- Log protection format active

It is recommended to send the logs to a centralized log server to better analyze and filter logs. This will also help in maintaining the size on the actual system.

With transaction RSAU_CONFIG, further parameters can be configured depending on your organizations requirements.

Note: Reference DT-P-AE-M01-002 controls for identifying available logs that can be collected for your requirements
</Implementation><Verification><item></item><item>- Verify that security audit logs are enabled by checking the rsau/enable parameter</item><item>- Verify that security audit logs minimal settings are configured</item><item>- Verify if all events are for critical users, such as SAP*, DDIC, SAPCPIC, emergency and support users, are collected and audited for all clients</item><item>- Verify if all critical events for all clients are collected and audited</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A21 Configuration of the Security Audit Log (S) / Konfiguration des Security Audit Logs (S)</item><item>- SAP Security Baseline Template V2.1: 2.4.3.1.1</item><item>- CIS CSC 1, 3, 5, 6, 14, 15, 16</item><item>- COBIT 5 APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01</item><item>- ISA 62443-2-1:2009 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4</item><item>- ISA 62443-3-3:2013 SR 2.8, SR 2.9, SR 2.10, SR 2.11, SR 2.12</item><item>- ISO/IEC 27001:2013 A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1</item><item>- NIST SP 800-53 Rev. 4 AU Family</item></References></item><item><Shortcode>PT-C-IP-M01-001</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> SAP ABAP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>C</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Implementing custom code in the organization should have a defined change management process. This enables organizations to determine whether custom applications should be used as a replacement to existing applications or removed from the organization.
</Description><Implementation>
A standard and defined change management process should cover the controls, defined below, when delivering or handling custom applications that will be, or already, integrated with the organizations SAP ecosystem(1).

(1) - This can be amended to the organizations change management if exists
</Implementation><Verification><item></item><item>- [ ] Implementing policies that clearly define the installation of custom applications</item><item>- [ ] Modifying custom code to be limited and only done when necessary</item><item>- [ ] Changes are tested to avoid any impact on operations</item><item>- [ ] Installation and removal of custom applications properly documented and tracked</item><item>- [ ] A Secure Software Development Lifecycle (SSDLC) defined when customizing, changing, developing, and integrating application</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A26 Protection of the customer&apos;s own code in the SAP ERP system (S) / Schutz des kundeneigenen Codes im SAP-ERP-System (S)</item><item>- CIS CSC 3, 11</item><item>- COBIT 5 BAI01.06, BAI06.01</item><item>- ISA 62443-2-1:2009 4.3.4.3.2, 4.3.4.3.3</item><item>- ISA 62443-3-3:2013 SR 7.6</item><item>- ISO/IEC 27001:2013 A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4</item><item>- NIST SP 800-53 Rev. 4 CM-3, CM-4, SA-10</item></References></item><item><Shortcode>PT-P-IP-M01-010</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> Process / Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Setting a strong password policy is essential to protect from unauthorized access to your systems caused by stolen credentials or hashes. A weak password policy can result in several threats to the company, ranging from gaining access to sensitive information to corrupting an entire system.
</Description><Implementation>
Below helps organization&apos;s set a password policy for ABAP systems:

- Set minimum password length (1) with the UME property ume.logon.security_policy.password_min_length &gt;= 12
- Increase maximum password lengthe with the UME property ume.logon.security_policy.password_max_length (default is only 14)
- Set an expiry for passwords to be changed with UME property ume.logon.security_policy.password_expire_days &lt;= 90
- Define a password history size with the UME property ume.logon.security_policy.password_history &gt;= 5
- To enforce users to comply with the password policy set UME property ume.logon.security_policy.enforce_policy_at_logon = TRUE
- Set maximum login attempts by UME property ume.logon.security_policy.lock_after_invalid_attempts &lt;= 5
- Deny the use of old passwords in new passwords by setting the UME property ume.logon.security_policy.oldpass_in_newpass_allowed = FALSE
- Allow users to change their own password ume.logon.security_policy.password_change_allowed = TRUE
- Define a list of well-known passwords that are not allowed to be used by users through ume.logon.security_policy.password_impermissible
- Deny the use of user IDs as part of the password by setting the UME propertyume.logon.security_policy.userid_in_password_allowed = FALSE


Setting password complexity:
- Set UME propoerty ume.logon.security_policy.password_alpha_numeric_required &gt;= 1
- Set UME ume.logon.security_policy.password_mix_case_required &gt;= 1
- Set UME ume.logon.security_policy.password_special_char_required &gt;= 1


(1) - SAP baseline recommends a minimum length of 8 characters. Our recommendation and research on cracking passwords, a minimum length of 8 characters can be easily broken with today&apos;s machines.
</Implementation><Verification><item></item><item>- Verify a that a password policy is in place with the recommended values in the implementation section</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A13 SAP password security (S) / SAP-Passwortsicherheit (S)</item><item>- SAP Security Baseline Template V2.1: 2.3.2.2, 2.3.2.2.2</item></References></item><item><Shortcode>PT-A-AC-M01-009</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Identity Management, Authentication and Access Control</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>A</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
SAP standard users are required to be managed and securely configured to avoid any misuse to SAP systems. This includes changing default passwords and restricting standard users.
</Description><Implementation>
The below standard users, found in ABAP systems, are required to be managed and securely configured: (The Verification of Control section will help organizations have the basic requirements to secure these users)
1. SAP*
2. DDIC
3. SAPCPIC
4. TMSADM
5. EARLYWATCH
6. Users creates by the SAP solution manager

</Implementation><Verification><item></item><item>- SAP*</item><item>  - Must exist in all clients</item><item>  - Must be locked in all clients</item><item>  - Default password must be changed</item><item>  - Must belong to the group SUPER in all clients</item><item>  - No profile should be assigned (especially SAP_ALL)</item><item>  - login/no_automatic_user_sapstar profile parameter must be set to 1</item><item></item><item>- DDIC</item><item>  - Default password must be changed</item><item>  - Must belong to the group SUPER in all clients</item><item></item><item>- SAPCPIC</item><item>  - Delete if user not required</item><item>  - If required, default password must be changed</item><item>  - Must belong to the group SUPER in all clients</item><item></item><item>- TMSADM</item><item>  - Default password must be changed</item><item>  - Should only exist in client 000</item><item>  - Must belong to the group SUPER in client 000</item><item>  - Authorization profile S_A.TMSADM should only be assigned</item><item></item><item>- EARLYWATCH</item><item>  - The user should not exist in any client</item><item></item><item>- Other users created by the SAP Solution Manager (SOLMAN_BTC, CONTENTSERV, SMD_BI_RFC, SMD_RFC, SMDAGENT_SAPSolutionManagerSID, SMD_ADMIN, SMD_AGT, SAPSUPPORT, SOLMAN_ADMIN)</item><item>  - Default password must be change</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A4 Configuration and protection of the SAP user administration / Konfiguration und Absicherung der SAP-Benutzerverwaltung</item><item>- SAP Security Baseline Template V2.1: 2.3.1</item></References></item><item><Shortcode>PT-P-IP-M01-014</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> SAP HANA</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
SAP database contains critical information and data for different departments within an organization. The data must always be backed up, protected through encryption, maintained and reviewed on regular basis, and tested regularly.   
</Description><Implementation>
Database system backups and tenant backups are required to be done on a scheduled and consistent manner. A full database should be done on a weekly basis, and a differential or incremental backup throughout the week.
</Implementation><Verification><item></item><item>- A full database backup scheduled on a weekly bases</item><item>- Differential or incremental backups scheduled daily throughout the weekly</item></Verification><References><item>- CIS CSC 10</item><item>- COBIT 5 APO13.01, DSS01.01, DSS04.07</item><item>- ISA 62443-2-1:2009 4.3.4.3.9</item><item>- ISA 62443-3-3:2013 SR 7.3, SR 7.4</item><item>- ISO/IEC 27001:2013 A.12.3.1, A.17.1.2, A.17.1.3, A.18.1.3</item><item>- NIST SP 800-53 Rev. 4 CP-4, CP-6, CP-9</item></References></item><item><Shortcode>PT-P-IP-M01-004</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> Process / Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
The organization is responsible to properly document and comply with the defined security guidelines when installing an SAP ERP system.
</Description><Implementation>
Security guidelines for different SAP functional units, technology, or specific areas such as authorizations must be aligned with SAPs security guides.

It is important to document all security-relevant measures that have been included in the installation or current deployment.

The operating system chosen for hosting SAP-systems should be hardened and secured adequately as per the organization&apos;s security policies.
</Implementation><Verification><item></item><item>- Verify security guidelines documentation for installed SAP systems</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A11 Secure installation of a SAP ERP system (S) / Sichere Installation eines SAP-ERP-Systems (S)</item></References></item><item><Shortcode>PT-P-PT-M01-007</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Protective Technology</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Security Audit Logs (SAL) are important to be activated and properly configured throughout the entire SAP environment. This help security teams identify and detect potential threats that might affect their environment.
</Description><Implementation>
It is important to activate and properly configure the UME properties pertaining to security audit logs. The following parameters help to do so:

- ume.secaudit.get_object_name = TRUE
- ume.secaudit.log_actor = TRUE
- ume.logon.security_policy.log_client_hostaddress = TRUE
- ume.logon.security_policy.log_client_hostname = FALSE (requires DNS lookup, which impacts system performance)
- enable.xml.hardener = TRUE

It is recommended to change the level of information being logged according to the protection needs of the application. The minimal severity level should be set to *&quot;Info&quot;*.
</Implementation><Verification><item></item><item>- Verify that security audit logs UME properties are configured</item><item>- Verify what is being logged by logging into the Netweaver Administrator and then navigate to -&gt; Troubleshooting -&gt; Logs and Traces -&gt; Log Configuration, from Show filed choose &apos;Logging Categories&apos;</item><item>- Verify the log level settings for the severity level to be logged.</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A21 Configuration of the Security Audit Log (S) / Konfiguration des Security Audit Logs (S)</item><item>- SAP Security Baseline Template V2.1: 2.4.3.1.2</item><item>- CIS CSC 1, 3, 5, 6, 14, 15, 16</item><item>- COBIT 5 APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01</item><item>- ISA 62443-2-1:2009 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4</item><item>- ISA 62443-3-3:2013 SR 2.8, SR 2.9, SR 2.10, SR 2.11, SR 2.12</item><item>- ISO/IEC 27001:2013 A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1</item><item>- NIST SP 800-53 Rev. 4 AU Family</item></References></item><item><Shortcode>PT-P-IP-M01-005</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> Process / Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Setting a strong password policy is essential to protect from unauthorized access to your systems caused by stolen credentials or hashes. A weak password policy can result in several threats to the company, ranging from gaining access to sensitive information to corrupting an entire system.
</Description><Implementation>
Below helps organization&apos;s set a password policy for ABAP systems:

- Set minimum password length (1) with the profile parameter login/min_password_lng &gt;= 12
- Set a maximum number of days a password can be unused with profile parameter login/password_max_idle_initial (set between 1 to 14)
- Set an expiry for passwords to be changed with profile parameter login/password_expiration_time &lt;= 90
- Define a password history size with the profile parameter login/password_history_size &gt;= 5
- Do not store passwords for old kernels to interpret by setting profile parameter login/password_downwards_compatibility=0
- To enforce users to comply with the password policy set profile parameter login/password_compliance_to_current_policy=1
- Remove old downward compatible password hashes in fields BCODE and PASSCODE from the USR02 table
- Set maximum login attempts by profile parameter login/fails_to_user_lock &lt;= 5
- Disable auto unlock by profile parameter login/failed_user_auto_unlock = 0
- Setting a maximum period for an unused productive password to stay valid by profile parameter login/max_idle_productive &lt;= 90
- Deny logging in with initial or expired user accounts by setting profile parameter icf/reject_expired_passwd = 1
- Deny logging in with initial or expired user accounts via RFC by setting profile parameter rfc/reject_expired_passwd = 1
- Disable password login when the organization is using other authentication methods with the profile parameter login/disable_password_logon &gt; 0
- When using Single Sign-on (SSO) authentication method it is mandatory to check whether a users passwords needs changing with the profile parameter login/password_change_for_SSO
- Define a period of time (measured in days) that a user is able to change their password again with the profile parameter login/password_change_waittime &gt; 0
- Set the hashing algorithm and encoding for new password with the profile parameter login/password_hash_algorithm = encoding=RFC2307, algorithm=iSSHA-512, iterations=15000, saltsize=256 (Profile parameter login/password_downwards_compatibility should not equal to 5 or the hashing algorithm profile parameter will not make sense)

Setting password complexity:
- Set profile parameter login/min_password_digits &gt;= 1
- Set profile parameter login/min_password_letters &gt;= 1
- Set profile parameter login/min_password_lowercase &gt;= 1
- Set profile parameter login/min_password_uppercase &gt;= 1
- Set profile parameter login/min_password_specials &gt;= 1
- Set profile parameter login/min_password_diff &gt;= 3


(1) - SAP baseline recommends a minimum length of 8 characters. Our recommendation and research on cracking passwords, a minimum length of 8 characters can be easily broken with today&apos;s machines.
</Implementation><Verification><item></item><item>- Verify a that a password policy is in place with the recommended values in the implementation section</item><item>- Verify if table USR02 contains old downward compatible password hashes in fields BCODE and PASSCODE</item><item></item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A13 SAP password security (S) / SAP-Passwortsicherheit (S)</item><item>- SAP Security Baseline Template V2.1: 2.3.2.2, 2.3.2.2.1</item><item>- SAP Note 1458262</item></References></item><item><Shortcode>AllControls.txt</Shortcode><Security_Function> DT</Security_Function><CSF_Category> Anomalies and Events</CSF_Category><Technology> SAP ERP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
The organization is responsible for defining policies and procedures when identifying, collecting, acquiring, and preserving data that is used for evidence.
</Description><Implementation>
Areas of acquiring important logs within the organization&apos;s SAP ERP:

1. Security audit log - DT-P-AE-M01-002
2. System log - DT-P-AE-M01-003
3. Table logging - DT-P-AE-M01-004
4. Workload Monitor - DT-P-AE-M01-005
5. Read Access Logging - DT-P-AE-M01-006
6. User Information System -  DT-P-AE-M01-007

Each area is used to extract and analyze data for different activities that occur in the system.

Note: each area is described in its respective control
</Implementation><Verification><item></item><item>- [ ] A policy has been defined and created to identify, collect, acquire and preserve information from different log tools</item><item></item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A32 Real-time recording and alarming of irregular processes (H) / Echtzeiterfassung und Alarmierung von irregulären Vorgängen (H)</item><item>---</item><item>Security Function: DT</item><item>Category: Anomalies and Events</item><item>Technology: SAP ERP</item><item>Maturity Level: 1</item><item>IPAC: Platform (P)</item><item>Defender: Process</item><item>Prerequisite: DT-P-AE-M01-001</item><item>---</item></References></item><item><Shortcode>PT-PA-IP-M01-001</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> Process &amp; Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item><item>A</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
 Standard user allowed to access SAP systems should be properly managed and configured. This will allow organizations to follow the least privilege principle.
</Description><Implementation>
Default passwords for the standard users should be changed and the companies password policy(1) should be applied.

Standard users that are not required should be deleted or disabled.

Obsolete standard users such as EARLYWATCH should not exist in any client.

Self registration should not be allowed and turned off for better access control.

(1) Password policies changes across different organizations depending on several criteria&apos;s such criticality of the industry, local or federal laws, security standards that are mandatory to the industry and so on  
</Implementation><Verification><item></item><item>- Default password for standard user IDs are changed</item><item>- Password policy is applied properly across SAP systems</item><item>- Standard users are deleted and disabled when not in use</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A4 Protection of the delivered SAP standard user IDs / Absicherung der ausgelieferten SAP-Standardbenutzer-Kennungen</item><item>- SAP Security Baseline Template V2.0: 2.3.1</item></References></item><item><Shortcode>PT-P-IP-M01-001</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Identity Management, Authentication and Access Control</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>A</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Access to SAP databases must be protected from unauthorized access and misuse.  
</Description><Implementation>
SAP business users are not to be allowed to access the SAP database. Removing other identities and users from accessing the database allows the principle of least privilege, separation of duties, and need to know.

Check the transaction log file for unneeded accounts. The transaction file can be viewed by executing R3trans -d.

Users that are allowed to access the database are limited to only the tables that allows them to complete their job.
</Implementation><Verification><item></item><item>- SAPR3, SAPSID, or SAPABAP1 disabled to access the database</item><item>- Users not required to access the database are removed</item><item>- Data manipulation only given to SAP support</item><item>- Users that are required to access the database are not to be given permissions to Table USR\*, Table T000, SAPUSER, RFCDES, PA\*, HCL\*, and any other tables not required to get their job done</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A7 Securing the SAP database/ Absicherung der SAP-Datenbanken</item></References></item><item><Shortcode>IY-C-RA-M01-001</Shortcode><Security_Function> IY</Security_Function><CSF_Category> Risk Assessment</CSF_Category><Technology> ABAP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>C</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Access &amp; Authorization

ABAP uses a mostly explicit authorization model. This means that an authorization check only takes place if a program carries out the check explicitly itself. In other words: If there is no explicit authorization check in the code, there is no check as to whether a user is actually authorized.
In custom-developed code, authorization checks are frequently overlooked. This means that the authorization concept has no effect. This leads to compliance infringements, which can have serious consequences in the event of an audit. For this reason, it is critically important that authorization checks are carried out in custom developments by the programs themselves wherever necessary, and that all authorization checks are also correctly programmed from a formal perspective.
In addition to the lack of authorization checks, the structuring of program components can also influence the viability of the authorization concept. For example, you should query how executable modules are comprised under the assumption that interface authorizations are not, or can&apos;t be assigned granular for the exposed business functionality.
Authorization checks are typically the most frequent security error in ABAP custom developments.
</Description><Implementation>
1. The specification of the change includes a concise description of the authorization requirement adjustments according to the change.
2. As part of code change review process all custom code has to be checked to carry that:
  - All authorization checks using the SAP standard mechanisms. This typically means that, either:
    - the command AUTHORITY-CHECK OBJECT or
    - a module, which has been specially developed for checking a specific authorization (such as the SAP function module &apos;AUTHORITY_CHECK_DATASET&apos;),
    - or an access declaration by the Data Access Control (DAC) language for Core Data Services (CDS) must be used.
  - All direct executable modules implement explicit access restrictions at the execution start checking on user permissions to start the module
  - Before the command CALL TRANSACTION is carried out, an authorization check should take place to ensure that the current user is actually authorized to start the transaction. In case a transaction is called with the attempt of only providing limited access to the transaction&apos;s functionality, for example with predefined selection values and the addition SKIP FIRST SCREEN it can be reasonable not to carry out an authorization check for user permissions of starting the transaction, as this may requires unnecessary high privileges for the user.
  - The implementation verifies the user&apos;s authorization as close as possible to the execution of the protected business function.
  - The implementation handles the result of the verification of user&apos;s authorizations to permit legitimate access and execution and prohibit other by the verification of return codes like sy-subrc and authorization exceptions according to the checks implementation.
</Implementation><Verification><item></item><item>- [ ] Review if negative and positive access control testing is specified and the execution documented in the test protocol of the change.</item><item>- [ ] Audit if the source code review is carried out and documented on all custom code changes for the correct implementation of user access control in the change.</item><item></item></Verification><References><item></item><item>- CIS CSC 4</item><item>- COBIT 5 APO12.05, APO13.02</item><item>- ISO/IEC 27001:2013 Clause 6.1.3</item><item>- NIST SP 800-53 Rev. 4 PM-4, PM-9</item><item>- BSI APP (February 2020) 4.6 A1, A2, A3, A6, A7</item><item>- OWASP ASVS 2.0 V4.1.3, V4.1.4, V4.1.5</item></References></item><item><Shortcode>DT-P-AE-M01-005</Shortcode><Security_Function> DT</Security_Function><CSF_Category> Anomalies and Events</CSF_Category><Technology> SAP ERP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Workload monitor:

The workload monitor helps with analyzing system statistics in SAP systems. An important part of the workload monitor is its capability to collect activities performed by users against the system. This avoids repudiation and helps in analyzing changes or security events that caused an incident to take place.
</Description><Implementation>
Workload monitor is deactivated by default, and needs to be activated when investigating events or incidents caused by users.

Tracking user activity may not be permitted in different parts of the world. Make sure to follow any data protection regulations your organizations falls under when tracking use activity.
</Implementation><Verification><item></item><item>- Start the workload monitor using the STO3N transaction</item></Verification><References></References></item><item><Shortcode>PT-A-AC-M01-013</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Identity Management, Authentication and Access Control</CSF_Category><Technology> SAP ABAP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>A</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Access control policies and specific guidelines pertaining to authorization restrictions and passwords should be regularly issued, verified, audited, and revoked where necessary.
</Description><Implementation>
It is important to create policies and guidelines which addresses the different authorizations and password policies in place.

- [ ] Create an access control policy to define users and their respective user groups
- [ ] Create a strong SAP password policy for all users
- [ ] Guidelines on setting a strong password should be created for users to follow 

Note: Controls PT-P-IP-M01-005 and PT-P-IP-M01-010 can assist with building a strong SAP password policy
</Implementation><Verification><item></item><item>- [ ] Verify that authorizations and access to SAP systems are documented</item><item>- [ ] Verify that users are assigned to their respective user groups as per their job roles</item><item>- [ ] Verify that a strong password policy is in place and implemented</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A19 Definition of the security guidelines for user / Definition der Sicherheitsrichtlinien für Benutzer</item><item>- CIS CSC 3, 5, 12, 14, 15, 16, 18</item><item>- COBIT 5 DSS05.04</item><item>- ISA 62443-2-1:2009 4.3.3.7.3</item><item>- ISA 62443-3-3:2013 SR 2.1</item><item>- ISO/IEC 27001:2013 A.6.1.2, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5</item><item>- NIST SP 800-53 Rev. 4 AC-1, AC-2, AC-3, AC-5, AC-6, AC-14, AC-16, AC-24</item></References></item><item><Shortcode>PT-P-PT-M01-008</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Protective Technology</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Security Audit Logs (SAL) are important to be activated and properly configured throughout the entire SAP environment. This help security teams identify and detect potential threats that might affect their environment.
</Description><Implementation>
It is important to activate and properly configure the audit trail for HANA in the SAP HANA Administration Console. The following parameters help to do so:

- global_auditing_state = true in global.ini file, section auditing configuration
- Audit policies should be configured as per the companies security requirements
- Set the default_audit_trail_type = SYSLOGPROTOCOL or CSTABLE in global.ini file, section auditing configuration. More information on Audit Trail Layout can be found [here](https://help.sap.com/docs/SAP_HANA_PLATFORM/b3ee5778bc2e4a089d3299b82ec762a7/0a57444d217649bf94a19c0b68b470cc.html)

Note: Critical users must be monitored
</Implementation><Verification><item></item><item>- Verify that security audit logs are enabled by checking the parameter global_auditing_state = true in global.ini file, section auditing configuration</item><item>- Verify if all events are for critical users are collected and audited</item><item>- Verify that the CSVFILE is not used to log security-critical information</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A21 Configuration of the Security Audit Log (S) / Konfiguration des Security Audit Logs (S)</item><item>- SAP Security Baseline Template V2.1: 2.4.3.1.3</item><item>- CIS CSC 1, 3, 5, 6, 14, 15, 16</item><item>- COBIT 5 APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01</item><item>- ISA 62443-2-1:2009 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4</item><item>- ISA 62443-3-3:2013 SR 2.8, SR 2.9, SR 2.10, SR 2.11, SR 2.12</item><item>- ISO/IEC 27001:2013 A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1</item><item>- NIST SP 800-53 Rev. 4 AU Family</item></References></item><item><Shortcode>IY-C-RA-M01-005</Shortcode><Security_Function> IY</Security_Function><CSF_Category> Risk Assessment</CSF_Category><Technology> ABAP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>C</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Use of protective mechanisms

The SAP standard system provides companies with various mechanisms to protect their data. For this reason, the security strategies of many companies are based on the knowledge that the mechanisms in the SAP standard systems provide a solid foundation and are not (or should not be) compromised.
These mechanisms include:
- Client/tenant separation
- Identity management
- Roles and authorizations management
- Separation of development, test and production
- Logging of security events
</Description><Implementation>
1. As part of code change review process all custom code has to be checked to carry that:
    - it must not undermine the security mechanisms of the SAP standard system.
    - If the SAP standard system has earmarked a security mechanism for specific tasks, then this security mechanism should also be used in change&apos;s custom code.
    - In the target system release, in which the application is to be run, the ABAP code shouldn&apos;t use any obsolete language elements.
    - The coding should be tested using the extended syntax check and any deficits should be eliminated.
    - Customer-specific database tables should generally be delivered for disallowing manual data maintenance by SAP standard tools. If manual table maintenance is required, then a maintenance application (maintenance view) should be created.
</Implementation><Verification><item></item><item>- [ ] Audit if the source code review is carried out and documented on all custom code changes to verify the correct use of protective mechanisms.</item></Verification><References><item></item><item>- CIS CSC 4</item><item>- COBIT 5 APO12.01, APO12.02, APO12.03, APO12.04</item><item>- ISA 62443-2-1:2009 4.2.3, 4.2.3.9, 4.2.3.12</item><item>- ISO/IEC 27001:2013 Clause 6.1.2</item><item>- NIST SP 800-53 Rev. 4 RA-3, SI-5, PM-12, PM-16</item></References></item><item><Shortcode>DT-P-AE-M01-001</Shortcode><Security_Function> DT</Security_Function><CSF_Category> Anomalies and Events</CSF_Category><Technology> SAP ERP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
The organization is responsible for defining policies and procedures when identifying, collecting, acquiring, and preserving data that is used for evidence.
</Description><Implementation>
Areas of acquiring important logs within the organization&apos;s SAP ERP:

1. Security audit log - DT-P-AE-M01-002
2. System log - DT-P-AE-M01-003
3. Table logging - DT-P-AE-M01-004
4. Workload Monitor - DT-P-AE-M01-005
5. Read Access Logging - DT-P-AE-M01-006
6. User Information System -  DT-P-AE-M01-007

Each area is used to extract and analyze data for different activities that occur in the system.

Note: each area is described in its respective control
</Implementation><Verification><item></item><item>- A policy has been defined and created to identify, collect, acquire and preserve information from different log tools</item><item></item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A32 Real-time recording and alarming of irregular processes (H) / Echtzeiterfassung und Alarmierung von irregulären Vorgängen (H)</item></References></item><item><Shortcode>PT-P-DS-M01-005</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Data Security</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
A directory/path traversal attacks can allow unauthorized access to files or directories by manipulating applications that are using physical or logical file names as input. This will allow attackers to read or write to sensitive/critical files that can lead to information disclosure and other attacks that may further exploit the system.
</Description><Implementation>
The following steps help mitigate vulnerabilities where an attacker can manipulate file names to read or write from different application servers.

- Update your kernel to the latest security patch level
- Verify any logical file names and file path definitions from the reports RSFILECR or RSFILENA to determine the required changes
- Profile parameter abap/path_normalizartion should be activated (value 1)
- Paths must be normalized (see SAP note 1497003 for normalizing file paths) if authorization object S_DATASET is used
- Paths must be normalized if table SPTH contains any entries
- If the user interface allows input of logical file names then define aliases for the logical file names being used

Note: Make sure to first implement the changes on the testing environment before applying to production systems. This will avoid any errors or service disruptions to the production systems.
</Implementation><Verification><item></item><item>- Identify logical file names from the RSFILENA report</item><item>- Identify logical file names and file path definitions from the RSFILECR</item><item>- Verify that profile parameter abap/path_normalization is not deactivated</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A1 Secure configuration of the SAP ABAP stack (B) / Sichere Konfiguration des SAP-ABAP-Stacks (B)</item><item>- SAP Security Baseline Template V2.1: 2.2.1.3.1</item><item>- SAP note 1497003</item></References></item><item><Shortcode>PT-I-PT-M01-001</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Protective Technology</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>I</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
SAP network implementations should be managed, monitored, and controlled to protect information in applications and systems.

The control involves the need to securely configure the SAP Router and Web Dispatcher to act as an application-level gateways in the DMZ zone.
</Description><Implementation>
External traffic:

The SAP router and web dispatcher should be available in the demilitarized (DMZ) zone in order to filter appropriate traffic before being routed through another firewall.  

Internal traffic:

SAP systems should be placed on a separate subnet within the internal network. This allows an easier way to manage network access policies for SAP systems.

Governance:

The architecture of SAP systems should be properly documented which should include but not limited to connections, communications, data flow, users and used protocols.

</Implementation><Verification><item></item><item>- SAP Router and Web dispatcher placed in DMZ zone</item><item>- ACLs are in place to filter unwanted traffic</item><item>- Only necessary ports are allowed to access the network.  </item><item>- SAP systems are on a separate subnet inside the organization</item><item>- Documentation providing an illustrative view of the SAP architecture</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A3 Network Security/ Netzsicherheit</item><item>- CIS CSC 8, 12, 15</item><item>- COBIT 5 DSS05.02, APO13.01</item><item>- ISA 62443-3-3:2013 SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6</item><item>- ISO/IEC 27001:2013 A.13.1.1, A.13.2.1, A.14.1.3</item><item>- NIST SP 800-53 Rev. 4 AC-4, AC-17, AC-18, CP-8, SC-7, SC-19, SC-20, SC-21, SC-22, SC-23, SC-24, SC-25, SC-29, SC-32, SC-36, SC-37, SC- 38, SC-39, SC-40, SC-41, SC-43</item></References></item><item><Shortcode>IY-C-RA-M01-004</Shortcode><Security_Function> IY</Security_Function><CSF_Category> Risk Assessment</CSF_Category><Technology> ABAP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>C</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Prevention of injection vulnerabilities

Injection vulnerabilities refer to situations where a adversary introduces control characters and/or commands via the data channel (input) into an application. A successful attack can have a damaging impact on the scheduled program sequence as a result of unexpected commands.
Depending on the type of injection, an attacker can gain complete control of the affected SAP system. For the ABAP programming language this includes in particular implementations with:
- Access to the file system from file servers, or from the SAP operating systems for exchanges, or for processing of data takes place. With the number of interfaces (applications), the risk increases for each individual interface of receiving compromised data for processing, or of generating such data itself through faulty input.

- Using operating system commands via ABAP programs. The system access is carried out in the context of the SAP-system service user. This user necessarily has extensive privileges in the operating system. Considering the resulting overall risk, ABAP code that executes operating system commands should receive special protection.

- Using dynamic ABAP language features and database access. The options for using dynamic ABAP programming and access to databases have many uses. However, they are also associated with particular risks. If dynamic programming is necessary, these risks must be accounted for by the developer through the use of special protective measures.
</Description><Implementation>
1. As part of change review process the implementation&apos;s design has to be verified to against the the following properties:
    - During processing of input, a sufficient plausibility check must normally be carried out. This is referred to as “input validation”. Input validation not only provides basic security protection (since control characters and special characters are ineffective in most data fields and can be removed) but it also improves the data quality in general. Input validation should be implemented in such a way that the inputs are compared with a list of permitted values, that is, using the “allowlist filter” approach.
    - Special care should be taken if user input is mixed with control characters or language elements (semantics) and the result is then processed or executed as a whole. In this case, all the control characters in the data, which are relevant in the context, must be rendered harmless. This operation is referred to as “output encoding” or “sanitisation” depending on the output context.
      The implementation of the following measures in particular should be validated:
      - Indirection: The execution of critical code should be decoupled as much as possible from input
      - Plausibility: Range checks, allowlists and/or denylists should be used to restrict the input&apos;s value range to plausible values.
      - Context validation: Before execution, control logic must run which sufficiently check the execution authorization of the program, user and input.
      - Traceability: Consideration should be given to logging the execution of sensitive business logic for the user&apos;s context, execution time, and input sufficiently.
      - Equivalence: For dynamically executed code, the same level of control  must run as for an equivalent static implementation complying with the in the case of correct static implementation of the code execution.

2. As part of the change testing process all implementations has to be verified for protection against input based attacks as when suitable ABAP techniques being used in the implementation.
    - Directory &amp; file traversal.
    - Operating system command injection.
    - SQL injection.
    - Forceful browsing
    - ABAP code injection.
</Implementation><Verification><item></item><item>- [ ] Audit if the source code review is carried out and documented on all custom code changes to identify injection &amp; sanitisation vulnerabilities.</item><item>- [ ] Audit if the change has been sufficiently tested and documented for the above vulnerabilities.</item></Verification><References><item></item><item>- CIS CSC 4</item><item>- COBIT 5 APO12.01, APO12.02, APO12.03, APO12.04</item><item>- ISA 62443-2-1:2009 4.2.3, 4.2.3.9, 4.2.3.12</item><item>- ISO/IEC 27001:2013 Clause 6.1.2</item><item>- NIST SP 800-53 Rev. 4 RA-3, SI-5, PM-12, PM-16</item><item>- OWASP ASVS 2.0 V5.1, V5.3</item><item>- BSI APP (February 2020) 4.6 A7, A8, A11, A13, A18</item></References></item><item><Shortcode>PT-IP-PT-M01-001</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> Process / Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
SAP GUI allows users to directly access different SAP applications from their own workstations, this functionality adds another security concern towards SAP applications when it is not managed or configured as per the security guidelines.
</Description><Implementation>
SAP GUI is continuously being updated for different issues and vulnerabilities, which makes it very important to include updates for SAP GUI with the organizations patch cycles. 

- Regularly update SAP GUI to all clients  

Note: PT-IP-PT-M01-002 provides detailed information on securing SAP GUI
</Implementation><Verification><item></item><item>- Verify if SAP GUI is included in the organizations patch management</item><item>- Verify that SAP GUI is up-to-date in clients PCs</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A20 Secure SAP GUI settings/ Sichere SAP-GUI-Einstellungen</item><item>- SAP Security Baseline Template V2.1: 2.2.2.1.4</item></References></item><item><Shortcode>DT-P-AE-M01-004</Shortcode><Security_Function> DT</Security_Function><CSF_Category> Anomalies and Events</CSF_Category><Technology> SAP ERP</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Table logging:

Identifying and collecting logs to identify changes in critical tables is necessary to maintain the integrity of data available in different tables.

</Description><Implementation>
Activate the table logging in the profile parameter rec/client. It is recommended to set this parameter to log from all clients within your SAP environment.

As a rule of thumb, choose tables that are either classified with the highest protection level or choose tables depending on the criticality of data found in them.

Alerts can be configured when a certain event occurs or a threshold is reached, this helps automate the review process of table logging and reduces workload from administrators. Sending logs to a central location helps to achieve setting up alerts.
</Implementation><Verification><item></item><item>- Set the rec/client parameter to enable logging</item><item>- Set the rec/client parameter to collect from all clients</item><item>- Define tables to be logged using transaction SE13</item><item>- Use transaction SCU3 to get an overview of all tables that have table logging enabled and the changes to these tables</item><item>- Configure alerts for important events to reactively respond to any changes in tables</item></Verification><References></References></item><item><Shortcode>PT-A-AC-M01-012</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Identity Management, Authentication and Access Control</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>A</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Single Sign-On (SSO) is recommended to be configured when multiple SAP systems are running in the organization&apos;s environment. SSO can simplify the process of managing and configuring user authorization to multiple systems and applications. Allowing a single user to access multiple applications comes with its own security risks and threats; a secure configuration of the issued logon tickets must be in place to avoid potential threats.  
</Description><Implementation>
In order to protect issued logon tickets during transport, in Java based systems, the below profile parameters are required to be in place.  

- Use HTTPS by setting ume.logon.security.enforce_secure_cookie = true
- Set an expiry for the issued ticket by setting login.ticket_lifetime ≤ 8 (hh:mm)
- Declare a cookie as HTTPonly by setting ume.logon.httponlycookie = true, this denies access to the issued cookie from the clients web browser by other applications such as Javascript access, plug-ins and so on.


Note: This control assumes that SSO is already configured and used in the organization.
</Implementation><Verification><item></item><item>- Verify if HTTPS profile parameter is set by checking ume.logon.security.enforce_secure_cookie = true</item><item>- Verify if an expiry exists for issued logon tickets by verifying login.ticket_lifetime ≤ 8</item><item>- Verify if the profile parameter ume.logon.httponlycookie = true</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A31 Configuration of SAP Single Sign-On (S) / Konfiguration von SAP Single-Sign-On (S)</item><item>- SAP Security Baseline Template V2.1: 2.3.2.4.2</item></References></item><item><Shortcode>PT-I-IP-M01-006</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Information Protection Processes and Procedures</CSF_Category><Technology> RFC Connections</Technology><Maturity_Level> 1</Maturity_Level><IPAC></IPAC><Defender><item>Process</item></Defender><Prerequisites></Prerequisites><Description>
Managing RFC connections between different systems of different classification levels is required in order to mitigate privilege escalation to sensitive or production systems.
</Description><Implementation>
As a rule of thumb, connections from lower classification systems, such as development or test systems, to high classification systems, such as production systems, should not use a trusted system logon or store user credentials of the target system.
Connectivity configuration data is the only thing that can be stored in the different systems. Accordingly, the logon must be performed by means of the respective user in the target system by authentication.

</Implementation><Verification><item></item><item>- Authentication is required on every connection from lower to higher classification system</item><item>- To determine RFC connections that store user credentials use the RSRFCCHK report in all systems locally</item><item>- Restrict authorization to maintain RFC destinations in transaction SM59 by strictly controlling  authorization  object S_RFC_ADM</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A8 Securing the SAP RFC interface/ Absicherung der SAP-RFC-Schnittstelle</item><item>- SAP Security Baseline Template V2.0: 2.3.2.3</item></References></item><item><Shortcode>PT-P-PT-M01-009</Shortcode><Security_Function> PT</Security_Function><CSF_Category> Protective Technology</CSF_Category><Technology> Technology</Technology><Maturity_Level> 1</Maturity_Level><IPAC><item>P</item></IPAC><Defender></Defender><Prerequisites></Prerequisites><Description>
Securing malicious or unrecognized access to the application servers through the message server is critical to maintaining the integrity, availability, and confidentiality of different requests between application servers of an SAP system working as a cluster.

Applicable for ABAP and Java systems.
</Description><Implementation>
A network device acting as a rogue application servers can pose a high risk to the organization if communication is allowed to legitimate application servers.

Access control lists (ACLs) must be configured for the message server to contain and defend against attacks on the trust relationship between legitimate application servers.

- ACL file should not contain an entry for to allow all hosts (i.e. HOST=* is critical)
- Split ports on message server for internal (1) and external communication (2)
- Profile parameter rdisp/msserv_internal defines the internal ports to use
- Block communication from external to the port defined in profile parameter rdisp/msserv_internal
- Deny external monitoring of the message server though setting the profile parameter ms/monitor=0
- Deny external administration of the message server though setting the profile parameter ms/admin_port=0

(1) - Internal communication is for communication between different application serves in the organization

(2) - External communication is for communication with the users/clients
</Implementation><Verification><item></item><item>- Verify the ACLs for the message server fro the profile parameter ms/acl_info</item><item>- Verify that HOST=* is not defined in the ACL</item><item>- Verify that ports are split for internal and external traffic and that the firewall is blocking communication to the internal port for all hosts not belonging to the system cluster.</item><item>- Verify that profile parameter ms/monitor=0</item><item>- Verify that profile parameter ms/admin_port=0</item></Verification><References><item>- BSI APP.4.2 SAP-ERP-System, APP.4.2.A9 Protection and monitoring of the message server (B) / Absicherung und Überwachung des Message-Servers (B)</item><item>- SAP Security Baseline Template V2.1: 2.2.1.4, 2.2.1.4.1, 2.2.1.4.2</item></References></item></Controls><Requirements></Requirements></root>