Download pdf - STD Security V10

Version: 1.0

June 2009

SAP Standard for Security

Whitepaper

Active Global Support SAP AG

© 2009 SAP AG SAP Standard for SecurityVersion: 1.0

Page 1 of 59


Table of Content

1 Management Summary ........................................................................3

2 SAP Standards for E2E Solution Operations.....................................4

3 Security Standard at a Glance ............................................................7

4 What is the basic concept of the Security Standard .......................10 4.1 Process Flow...................................................................................................10 4.2 People und Roles ............................................................................................12 4.3 Activities for Run SAP operations & optimization ............................................14 4.3.1 Compliance......................................................................................................14

4.3.1.1 Audit ................................................................................................................14

4.3.1.2 Outsourcing .....................................................................................................17

4.3.1.3 Emergency Concept ........................................................................................20 4.3.2 Collaboration Security .....................................................................................23

4.3.2.1 Secure process and people collaboration .......................................................23 4.3.3 Identity and Access Management ...................................................................28

4.3.3.1 User and Authorization Management ..............................................................28

4.3.3.2 Administration Concept ...................................................................................35 4.3.4 Infrastructure Security .....................................................................................39

4.3.4.1 Network, System, Database and Workstation Security ...................................39 4.3.5 Software Lifecycle Security .............................................................................45

4.3.5.1 Secure Application Lifecycle............................................................................45

4.3.5.2 Secure Configuration.......................................................................................50

4.3.5.3 Secure Support................................................................................................53

5 How to measure the success of the implementation ......................56

© 2009 SAP AG SAP Standard for Security Version: 1.0

Page 2 of 59


1 Management Summary Managing complexity, risk, costs as well as skills and resources is at the heart of implement-ing mission critical support for SAP-centric solutions. The complexity rises even further with the trend of out-tasking and out-sourcing of process components. To help customers manage their SAP-centric solutions, SAP provides a comprehensive set of standards for solution op-erations.

Out of this set of standards, the security standard provides best-practices for the secure op-eration of SAP-centric solutions. It is primarily suited for solutions or processes with low or medium security requirements. Elevated requirements demand a detailed, in-depth analysis that is out of scope of this document.

The security measures and processes described in this standard ensure a baseline protec-tion of business critical assets against common threats such as internal or external fraud, virus infections or information leakage, hereby covering common IT scenarios and processes (such as support, outsourcing, collaboration or development scenarios) and addressing com-pliance with regard to the increasing number of national and international regulations.

Main security areas are treated separately to speed-up the initiation of responsible personnel and to serve as a reference document.

Before describing the SAP standard for security in detail, chapter 2 of this document explains briefly the general purpose of the SAP Standards for E2E Solution Operations. Chapter 3 highlights the 10 different security topics that are covered in this paper. After this, chapter 4 describes the relevant activities for targeting these topics are described in more detail. And finally, chapter 5 lists criteria to measure the success of the implementation.


Page 3 of 59


2 SAP Standards for E2E Solution Operations Mission-critical operations are a challenge. While the flexibility of SAP-centric solutions rises, customers have to manage complexity, risks, costs, as well as skills and resources efficiently. Customers have to run and incrementally improve the IT solution to ensure stable operation of the solution landscape. This includes the management of availability, performance, proc-ess and data transparency, data consistency, IT process compliance, and other tasks.

Typically, multiple teams in the customer organization are involved in the fulfillment of these requirements (see Figure 1). They belong to the key organizational areas Business Unit and IT. While the names of the organizations may differ from company to company, their function is roughly the same. They run their activities in accordance with the corporate strategy, cor-porate policies (for example, corporate governance, compliance and security), and the goals of their organizations.

Figure 1 Organizational model for end-to-end solution operations

The different teams specialize in the execution of certain tasks: On the business side, end users use the implemented functionality to run their daily business. Key users provide first level support for their colleagues. Business process champions define how business proc-esses are to be executed. A program management office communicates these requirements to the IT organization, decides on the financing of development and operations, and ensures that the requirements are implemented.

On the technical side, the application management team is in direct contact with the business units. It is responsible for implementing the business requirements and providing support for


Page 4 of 59


end users. Business process operations covers the monitoring and support of the business applications, their integration, and the automation of jobs. Custom development takes care of adjusting the solution to customer-specific requirements and developments. SAP technical operations is responsible for the general administration of systems and detailed system diag-nostics. And the IT infrastructure organization provides the underlying IT infrastructure (net-work, databases …). Further specialization is possible within these organizations as well. For example, there may be individual experts for different applications within SAP technical op-erations.

Efficient collaboration between these teams is required to optimize the operation of SAP-centric solutions. This becomes even more important if customers engage service providers to execute some of the tasks or even complete processes. Customers have to integrate the providers of out-tasking and out-sourcing services closely into the operation of their solutions.

Key prerequisite for efficient collaboration of the involved groups is the clear definition of processes, responsibilities, service level agreements (SLAs), and key performance indicators (KPIs) to measure the fulfillment of the service levels. Based on the experiences gained by SAP Active Global Support while serving more than 40,000 customers, SAP has defined process standards and best practices, which help customers to set up and run End-to-End (E2E) Solution Operations for their SAP-centric solutions. This covers not only applications from SAP but also applications from independent software vendors (ISVs), original equipment manufacturers (OEMs), and custom code applications integrated into the customer solution.

SAP provides the following standards for solution operations:

● Incident Management describes the process of incident resolution

● Exception Handling explains how to define a model and procedures to manage ex-ceptions and error situations during daily business operations

● Data Integrity avoids data inconsistencies in end-to-end solution landscapes

● Change Request Management enables efficient and punctual implementation of changes with minimal risks

● Upgrade guides customers and technology partners through upgrade projects

● SOA Readiness covers both technical and organizational readiness for service-oriented architectures (SOA)

● Root Cause Analysis defines how to perform root cause analysis end-to-end across different support levels and different technologies

● Change Control Management covers the deployment and the analysis of changes

● Solution Documentation and Solution Documentation for Custom Development de-fine the required documentation and reporting regarding the customer solution

● Remote Supportability contains five basic requirements that have to be met to opti-mize the supportability of customer solutions

● Business Process and Interface Monitoring describes the monitoring and supervision of the mission critical business processes

● Data Volume Management defines how to manage data growth


Page 5 of 59


● Job Scheduling Management explains how to manage the planning, scheduling, and monitoring of background jobs

● Transactional Consistency safeguards data synchronization across applications in distributed system landscapes

● System Administration describes how to administer SAP technology in order to run a customer solution efficiently

● System Monitoring covers monitoring and reporting of the technical status of IT solu-tions

● Test Management describes the test management methodology and approach for functional, scenario, integration and technical system tests of SAP-centric Solutions.

● Custom Code Management describes the basic concepts of custom code operation and optimization

● Security describes basic activities to setup, maintain and evolve security measures for the operation and organization of SAP solutions.

Out of this list, this white paper describes the standard for Security.


Page 6 of 59


3 Security Standard at a Glance The Security Standard aims to protect the company’s critical business processes and assets, hereby ensuring compliance to external regulations and standards, such as data protection laws or the Sarbanes Oxley Act (SOX).

It secures the availability and integrity of critical business processes – both company internal processes as well as collaborative processes with customers or other contractors – and pro-tects the confidentiality and integrity of sensitive information.

These objectives are accomplished by addressing 10 different security topics (further de-noted as secure operations tracks) throughout the different phases Design, Setup and Opera-tions & Optimization as described in the Run SAP Methodology for implementing E2E solu-tion operations. Figure 2 illustrates this approach at the example of the secure operations track Audit.

Assessment & Scoping

Handover into Pro-duction Design Setup Operations &

Design activities Setup activities Operation activities

1. Audit 1. Audit 1. Audit

2. … 2. … 2. …

Figure 2 Distinction of security topics throughout all Run SAP phases

If a company has low or medium security requirements, one can follow the best-practice rec-ommendations provided for each secure operations track. In case of elevated security re-quirements, one needs to perform a comprehensive risk analysis in order to select appropri-ate security measures. Such a risk analysis is based on the profound knowledge of the com-pany’s critical business processes and need to be performed during the Design phase.

An overview of all secure operations tracks is given in the Secure Operations Map (see Figure 3), which relates each track to one of the 5 principal areas Compliance, Secure Col-laboration, Identity and Access Management, Infrastructure Security and Software Lifecycle Security. This classification follows the well-known SAP Security Solution Map, which struc-tures the SAP product and service offering with regard to security. Further information about the Security Solution Map can be found in the SAP Developer Network1.

1 https://www.sdn.sap.com/irj/sdn/security © 2009 SAP AG SAP Standard for Security

Version: 1.0 Page 7 of 59


Figure 3: Secure Operations Map

The 10 secure operations tracks of the Secure Operations Map cover the following topics:

1. Audit: Ensure and verify the compliance of a company’s IT infrastructure and opera-tion with internal and external guidelines

2. Outsourcing: Ensure secure operation in IT outsourcing scenarios

3. Emergency Concept: Prepare for and react on emergency situations

4. Secure Process and People Collaboration: Maintain security of process and people collaboration by means of automated business processes or document exchanges

5. User and Authorization Management: Manage IT users, their authorizations and au-thentication

6. Administration Concept: Securely administer all aspects of solutions operation

7. Network, System, Database and Workstation Security: Establish and maintain the security of all infrastructure components

8. Secure Application Lifecycle: Securely develop and maintain the code base of stan-dard and custom business applications

9. Secure Configuration: Establish and maintain a secure configuration of standard and custom business applications

10. Secure Support: Resolve software incidents in a secure manner


Page 8 of 59


It shall be noted that the above-introduced secure operations tracks focus on SAP business solutions. Other security measures being part of a comprehensive and complete security concept, e.g. physical measures that control access to physical facilities or sites, are not cov-ered by this document.

The following prerequisites are required to successfully design, implement and operate a comprehensive IT security concept: Support and commitment from top-level management, personnel with the required security knowledge and skill set and the understanding of the company’s critical business processes.

The management commitment must entail the following aspects:

● A company-wide security policy outlines general security principles and guidelines. This document manifests the company’s commitment to security.

● Dedicated security roles are defined and a clear reporting line is established, the overall responsibility hereby lying at board-level.

● Security responsibles are provided with a dedicated budget.

The understanding of the company’s critical business processes will be one important input for the determination of security and protection requirements, which can be either done fol-lowing a best-practice approach or with help of a comprehensive risk analysis in cases where elevated security requirements are apparent or known. The requirements are the basis for the selection, design, implementation and maintenance of appropriate security measures throughout the different Run SAP phases.


Page 9 of 59


4 What is the basic concept of the Security Standard

4.1 Process Flow

This document focuses on best-practice security-relevant activities that need to be performed during the Operations & Optimization phase. Prerequisite activities of the Design and Setup phase are merely sketched; they are described in more detail in the respective Implementa-tion Methodology documents in the Run SAP roadmap.

Both, the Security Standard as well as the related Implementation Methodology documents are structured according to the Secure Operations Map, which consists of 10 secure opera-tions tracks (see Figure 3).

To address a certain track, the responsible security stakeholders (see section 4.2) may focus on the relevant section in each of these documents. Each section hereby describes important activities, concerned organizational roles, standard and optional SAP tools, as well as rele-vant training activities.

Activities in the Design, Setup and Operations & Optimization phase follow the same pattern, regardless of the actual track (see Figure 4). This pattern complies with the common under-standing of a security process as outlined by international standards such as ISO/IEC 27001:2005 and refinements by national standardization bodies, for instance the Federal Office for Information Security (BSI)2.

Figure 4: The security process for all secure operations tracks

2 https://ssl.bsi.bund.de/english/publications/bsi_standards/standard_100-1_e.pdf © 2009 SAP AG SAP Standard for Security

Version: 1.0 Page 10 of 59


Design Operations

Depending on the criticality of each business process, either a best-practice approach for processes with standard security requirements or a comprehensive risk analysis for critical business and supporting processes need to be followed. The comprehensive risk analysis must describe potential threats, their probability and impact on the company’s business in order to identify the security and protection requirements and to come up with suitable counter measures.

A principal decision for security measures is followed by the creation of more detailed con-cepts that will be implemented in later Run SAP phases. In general, risk analysis and concep-tual work are performed by IT management, security management, data protection office and the management of the respective business units.

Setup Operations

The implementation of the security concepts typically comprises:

● Installation and configuration activities (also of supporting tools that were purchased following the decisions of the Design Phase)

● Definition of appropriate process roles and authorizations

● Configuration of logging tools and definition of thresholds for monitoring tools

● Configuration of project and change management tools for maintenance workflows

● Preparation of KPI collection

● Setup of reporting and alerting lines

These activities are performed by internal units, typically administrator roles, or outsourced to consulting service providers.

The implementation of all security concepts must be thoroughly and independently validated according to a test plan. Successful testing and peer review activities are a basis for the final management approval which is a prerequisite for entering the Handover into Production phase.

The validation of the implementation can be performed by internal units or outsourced to consulting service providers.

Training activities must be planned and scheduled according to the required skill sets of the personnel that maintains and reviews the security measures during the Operations & Optimi-zation phase. Measures that apply to all employees should be rolled-out and related trainings should be offered, the publication of a company-wide security policy being one important cornerstone of that communication.

Operations & Optimization

Dedicated review processes conducted by administrative roles verify the successful enforce-ment of the company’s security policy and ensure that the correct implementation of security


Page 11 of 59


measures is not harmed by changes to systems and applications. Audit processes conducted by internal or external auditors check the compliance of IT operations with internal and exter-nal requirements. External auditors and management must be provided with relevant reports, protocols, data and access to audit facilities.

As far as security related KPIs have been defined, they shall be continuously measured dur-ing operations and evaluated by IT and security management in order to improve the opera-tional processes.

The company’s security policy cannot only be enforced by the implementation and mainte-nance of technical and organizational security controls but requires a general awareness of security among the company’s entire personnel. This awareness must be continuously ad-dressed by appropriate communication and training.

Finally, security objectives and the appropriateness of selected security measures shall be validated on a regular basis to eventually adjust either of them to the company’s changing economic and political environment, changing business processes or technical advancement.

Beyond the validation and fine-tuning of existing security measures, substantial changes to security requirements or the introduction of new security technologies require the iteration of previous Run SAP phases, hereby closing the security lifecycle.

4.2 People und Roles

Table 1 introduces examples of security roles that exist in companies, provides a short char-acterization and the role’s typical activities for use in later sections.

This overview does not claim to be complete and it must not be understood as a recom-mended organizational blue-print. To the contrary, each company rightfully follows its own role concept, depending on criteria such as the company size or structural aspects (e.g. cen-tralized vs. decentralized IT departments).

However, the creation of an actual organizational model of a specific company must comply with Segregation of Duties (SoD) requirements, as imposed by legal regulations such as Sarbanes-Oxley.

Examples for typical activities grouped by roles:

Group Role Typical activities

System Administrator Maintains technical systems, defines backup and recovery concept, performs emergency response process

Technical

Network Administrator Network segmentation, firewall configuration, communication channel encryption


Page 12 of 59



Application Manage-ment

Policy definition on application level, defini-tion of security requirements

Database Administra-tor

Configuration of database, implementing encryption

Test Management Test concepts for in-house or 3rd party de-velopments

Technical

Internal Help Desk Personnel

Management of support connections, han-dling/forwarding of incidents, incident repro-duction on test systems

Security Administrator Defines alerting and emergency response concept

Authorization Adminis-trator

Creates and manages roles

Security Team (technical and op-erational)

User Administrator Creates and manages user, performs risk analysis of user authorization assignment, ensures user appropriate provisioning and de-provisioning of roles

Security Management Policy definition, approval and publication, requirements definition, selection and as-sessment of security measures

Data Protection Office Identification and verification of privacy re-quirements with regard to employees and customers

Auditor, intern Verification of legal (external) or internal requirements

Security Team (legal and technical assessment)

Security Analyst In-depth security assessments

External Auditor Independent inspection of the internal secu-rity compliance


Page 13 of 59



Process Owner (planning of proc-esses)

Business Manage-ment (responsibility)

Identify and document process specific risks, process monitoring, conflict resolution, role design (SoD)

Business Expert (manages imple-mented processes)

IT-Management Budgeting, requirements definition, decision on tools, selection and assessment of secu-rity measures (in accordance with Security Team)

Business

Risk Analyst Comprehensive risk analysis, impact and probability estimations, cost/benefit estima-tions

Table 1: Common security roles

4.3 Activities for Run SAP operations & optimization

In the following sub-chapters, security related activities are described for each secure opera-tions track (Figure 3). This enables the respective stakeholders to focus on specific security topics.

All secure operations tracks shall be considered to ensure a complete coverage regarding the security of SAP Systems.

Security related activities described in this document focus on the operations and optimiza-tion phase as the major phase of the Run SAP standard methodology. Pre-requisite activities of the design and implementation phase are sketched afterwards and described in more de-tail in the corresponding Implementation Methodology documents of the Run SAP roadmap.

4.3.1 Compliance

4.3.1.1 Audit

Audit operations on a periodic basis ensure the effectiveness of security measures. Such evaluations of security processes are performed to provide an assessment of the internal controls regarding the compliance to policies and guidelines. The audit activity should be


Page 14 of 59


performed on multiple levels, from technical and business areas to internal auditors and ex-ternal specialists for security audits and assessments. Finally, a certification for compliance to security standards like ISO 27001 or BSI-Grundschutz can conclude these steps.

Operation activities

Audits are periodic checks of the internal control systems done by expert groups for assess-ments activities. These activities do not substitute regularly controls that concern the security related settings and which are constantly performed by respective administrators but supply additional in depth analysis of vulnerabilities and probable fraud activities. Deliverables of audits are reports and, if necessary, adjusted requirements.

Audit activities comprise (a) an initial check that verifies the auditability of security related configuration settings, (b) core audit activities, and (c) optional in depth security analysis.

(a) Prior to internal or external audit activities, auditors need to check that the security related configuration settings are compliant with the audit requirements, i.e. if the system is audit-able.

If these requirements are not met, later activities necessarily contain gaps and have only limited value (expressiveness). Limitations caused by missing configuration or the scope/features of the system under test must be mentioned in the audit report. Examples of such limitations are not properly configured security monitors, discontinued availably of such monitors during the audit period or a certain lack of visibility imposed by legal regulations.

(b) If these basic settings are valid, internal security auditors perform the following activities to ensure a broad view for the compliance of settings to internal and external regulations, hereby using compliance tools in order to compare the actual situation with the policies:

● Assessment of security relevant workflows and processes within the organization. This comprises operational processes such as the user (de-)provisioning, incident handling, emergency preparations or software lifecycle processes as well as security processes such as risk analysis, authorization conception etc.

● Assessment of security related system properties that indicate security holes:

o Authorization risks, settings and violations

o Appropriate software versions, support packs and patches

o Not implemented security notes (also see SAP Security Notes in the SAP Service Marketplace)

o Configuration settings such as password policies

o Security-related KPIs such as the average lifetime of user passwords or av-erage time to apply security patches and security notes

● Analysis of incident messages or suspicious activities that indicate an actual security breach during the audit period.


Page 15 of 59

http://service.sap.com/securitynotes


(c) Additional in depth security analysis, like penetration tests performed by security analysts, ensure robustness against active attacks and hidden fraud activities. Fraud detection should happen from a technical as well as a business view.

Prerequisites for the above-described operation activities

Prerequisite activity for the above-described security audit process is the initial definition or adjustment of regulations and policies. These adjustments of regulations that result from audits, dependent on the changing processes, system landscape and infrastructure, ensure an appropriate check in future security audits.

In accordance with laws, internal policies and business needs, process owners from all busi-ness areas elaborate relevant security needs as well as regulatory requirements that the business area has to comply with. The data protection officer and IT-Management ensure the valid definition of guidelines with regard to existing laws, policies and technical feasibility for the security of infrastructure and technical operations.

The same stakeholders define (a) logs and traces to be collected, (b) respective log levels and thresholds, (c) monitoring activities and relevant roles, as well as (d) access constraints for log data.

The detailed logging requirements need to be mapped by IT-Management and process own-ers to the systems, solutions and processes in place, implicitly identifying the logging and monitoring tools to be activated and customized during the setup phase. Not only technical logs are subject to internal or external requirements, but also documentation requirements that need to be provided manually, e.g. during incident, change or test management proc-esses.

The actual customizing will be done by technical application and system administrators dur-ing the setup phase. It shall be noted that some logs are collected by default whereas others require explicit activation and adoption to customer needs (e.g. customer-owned business objects and system configuration parameters).

Examples:

1. Legal regulations impose the appropriate logging of changes to business objects or tech-nical settings, such as financial accounts’ master data. This general requirement will be refined with regard to actual logging details, such as date of modification, change initiator etc. Once these details are specified, the actual business solutions with the relevant logs need to be identified prior to performing the actual customizing.

2. More technical examples that are also subject to audits concern other secure operation tracks as, for instance, User and Authorization Management with regard to user provi-sioning or password policies, or Secure Support with regard to the logging of activities conducted by help desk personnel. Such requirements need to be fed into the conception activities of the respective track.

The effectiveness of the actual configuration needs to be validated by internal auditors prior to going live.


Page 16 of 59


See also:

● SAP Service Marketplace: Audit Information System (AIS)

● SAP Help Portal: Auditing and Logging (introduction to SAP NetWeaver AS ABAP logging tools, such as the Audit Information System or the Security Audit Log)

● SAP Help Portal: Security Audit Log of the AS Java

● SAP Training: GRC300 - SAP BusinessObjects Access Control - Implementation and Configuration

● SAP Training: TZGC53 - EPT SAP BusinessObjects Access Control 5.3

● SAP Training: FIN900 - System Audit with SAP

● SAP Training: FIN910 - Management of Internal Controls

● SAP Training: ADM950 - Secure SAP System Management

External links:

● BSI IT-Gundschutz Catalogues 2008: M 2.347 Regelmäßige Sicherheitsprüfungen für SAP Systeme (German only)

● German SAP User Group (DSAG): Audit Guideline for SAP ERP 6.0 (in German only)

● German SAP User Group (DSAG): Data Protection Guidelines for SAP ERP 6.0 (in German only)

4.3.1.2 Outsourcing

Activities that have been identified as being business critical during an initial risk analysis shall not be outsourced, independent of the actual outsourcing scenario. Following a strategic decision that a given activity shall be outsourced, one has several options to select and freely combine the following outsourcing types:

1. In case of infrastructure outsourcing, the hardware and network infrastructure is physically located in the outsourcing delivery organization (e.g. outsourcing of the data center or data stores).

2. In case of application outsourcing, the application is operated and maintained by the outsourcing delivery organization (e.g. outsourcing of basis administration). Activities performed require knowledge about application configuration.

3. In case of support and development outsourcing, the development support of stan-dard and customer-owned applications as well as the development of new applica-tions is done by the outsourcing delivery organization. Activities performed require knowledge about the internal structure of the application.

4. In case of business operations outsourcing, business activities are performed by the outsourcing delivery organization (e.g. outsourcing of HR). Activities performed re-quire knowledge about the business process.


Page 17 of 59

http://service.sap.com/ais

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/8a/a8b5386f64b555e10000009b38f8cf/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/03/37dc4c25e4344db2935f0d502af295/frameset.htm

http://www.sap.com/services/education/catalog/globaltabbedcourse.epx?context=%5b%5b%7cGRC300%7c%7c%7c084%7cG%7c%5d%5d%7c


http://www.sap.com/services/education/catalog/overview/globaltabbedcourse.epx?context=%5b%5b%7cTZGC53%7c%7c%7c084%7cG%7c%5d%5d%7c

http://www.sap.com/services/education/catalog/overview/globaltabbedcourse.epx?context=%5b%5b%7cFIN900%7c%7c%7c062%7cG%7c%5d%5d%7c

http://www.sap.com/services/education/catalog/globaltabbedcourse.epx?context=%5b%5b%7cFIN910%7c%7c%7c044%7cG%7c%5d%5d%7c

http://www.sap.com/services/education/catalog/netweaver/globaltabbedcourse.epx?context=%5b%5bADM_USERSEC%7cADM950%7c%7c%7c%7cG%7c%5d%5d%7c

http://www.bsi.de/gshb/deutsch/m/m02347.htm


http://www.dsag.de/fileadmin/media/Leitfaeden/090421_Pruefleitfaden_ERP06.pdf

http://www.dsag.de/fileadmin/media/Leitfaeden/080909_Datenschutz-Leitfaden.pdf


Following an outsourcing decision, the specific security implications of each type need to be considered. One important aspect is that each outsourcing type implicates access of external personnel to different parts of the composite solution, namely physical access to hardware and network devices, access to the OS and DB or access to the business application itself. For every outsourcing type, appropriate access restrictions need to be implemented (physical protection, encryption, and authorization concept).

With regard to the service provider’s personnel, it should be distinguished whether the iden-tity of the service provider’s employees is known or not. Depending on that knowledge, the provisioning of the user account to the employee must be handled by either the outsourcer or the service provider. In the latter case, dedicated policies must be part of the contractual agreement.


As a basis for outsourcing activities, the authorizations of service employees should be checked on a regular basis by a security administrator. Frequently changing service person-nel causes the need for regular risk assessments and a check for correct de-provisioning of authorizations. The assessment by the security administrator should be focused on:

● Risks the authorizations have caused by SoD conflicts or critical activities

● Limitations and duration period of authorization assignments. A limit in time must al-ways be assigned by the workflow approver

● Periodic reviews and de-provisioning of the authorization assignments. (for holiday weeks or temporal department changes, business driven events like end of quarter closing)

● Monitoring of service level agreements regarding availability, e.g. response time to security related issues and the compliance to contractually fixed security measures

● Abandoned authorizations of former service personnel

● Restrictions for the ability to view mass data tables

● Restrictions for data download abilities of the interface

Auditing of outsourced services regarding all other activities of the standard by internal per-sonnel is mandatory.

An internal Security Administrator should additionally check read logs of critical business data. Reads of larger lists of business data should be checked for the real responsibilities the service personnel is performing on the data.

Security related measures based on the SLAs, security KPIs and the compliance of connec-tion requirements should be monitored periodically by the security analyst.


A prerequisite activity for outsourcing is a detailed risk analysis of the business risk of the outsourcing scenarios and the outsourcing service provider.


Page 18 of 59


In the preparation of a business outsourcing decision, the business area and the outsourcing service delivery organization should be checked for relevant risk categories: force majeure, organizational shortcoming, technical failures, human errors, deliberate acts.

In the delivery process, the service should be permanently monitored for service levels and security measures.

Initially to an outsourcing decision, the risk analyst identifies the relevant standards for out-sourcing scenarios. In cooperation with the business management, the requirements are defined, considering at least the following aspects. These requirements must drive the selec-tion of outsourcing providers and are a basis for a legally binding Service Level Agreement (SLA):

● Hardware and software

o Requirements regarding resource sharing, i.e. restricting the sharing of hardware and software across several customers.

o Usage of certified products (Common Criteria or ITSEC)

o In case of data storage by the service provider: Encryption requirements

● Communication

o Requirements for the network connection to the service provider with regard to the connection type (leased-line, dial-up, VPN etc.), bandwidth and en-cryption.

● Organization and processes

o Required certification of the outsourcing service provider (SAS70, ISO 27001, BSI IT-Grundschutz etc).

o Help desk and emergency processes (including backups, hardware and software redundancy etc)

o Logging and monitoring processes performed by the customer

o Authorization restrictions to the service personnel

The data protection office has to provide a read access log concept to ensure compliant ac-cess to review data. The system administrator has to ensure that the appropriate read logs are written and archived to be available for reviews.

The general configuration should ensure that only business critical data required for the ser-vice execution is accessible to outsourcing service providers. The configurations are per-formed by the system administrator.

On the basis of a secure configuration the authorization team provides a set of roles and permissions for the service personnel. Service permissions should be restrictive to precisely defined activities and should exclude system configuration as far as possible in the relevant outsourcing business scenario.

For additional security assurance, the outsourcing organization can be audited for their inter-nal IT-security concept and for the effectiveness of the enforcing mechanisms.


Page 19 of 59


See also:

● SAP Help Portal: Using an External Service Desk with SAP Solution Manager

● SAP Application Management services from SAP Consulting: Outsource the man-agement of some or all of your SAP applications

External information:

● Statement on Auditing Standards (SAS) No. 70, Service Organizations

● Federal Office for Information Security (BSI): IT-Gundschutz Catalogues 2005 (B 1.11 – Outsourcing)

● BSI IT-Gundschutz Catalogues 2008: M 2.345 Outsourcing eines SAP Systems (German)

4.3.1.3 Emergency Concept

Emergency management operations concern the handling of business critical events that significantly disrupt or endanger a company’s business operations. Its goal is to permit a timely recovery from emergencies such as, for instance, the disruption of system availability or the detection of a system being compromised.

Emergencies must not be confound with incidents that rather inhibit or disturb individual users to continue their daily tasks and, in general, are not as critical as emergencies. Incidents can be resolved following an incident management process that usually involves the affected end user at one hand side and customer or SAP help desk employees on the other side (see E2E Solution Operations Standard Incident Management).


Emergency management operations comprise activities that concern (a) the continuous preparation for emergencies and (b) the alerting and management of an actual emergency occurrence, hereby following a predefined process.

(a) Preparation activities comprise:

1. System administrators must regularly backup application and configuration data that allows restoring a previous and consistent system state or initializing a replacement system. It should be noted that simple database backups are not sufficient, as SAP systems also rely on configuration files. In addition, it must be ensured that given data backups can be successfully restored. Backup data must be secured against unauthorized access. Periodic verification of fast restore times, media quality and the availability of the eventual encryption keys to the responsible restoring personnel is essential to a comprehensive backup strategy.

2. High availability requirements can lead to the operation of replacement systems that take over if the primary systems are disrupted or compromised. As a result, system administrators need to maintain and update them similarly to primary systems, espe-cially with regard to patches, hot fixes, security notes and custom developments as well as authorizations.


Page 20 of 59

http://help.sap.com/saphelp_sm40/helpdata/en/8a/b0278648ac4f058a7111c3f9b60feb/frameset.htm

http://download.sap.com/services/bysubject/app-mgmt/brochures/download.epd?context=62B3F7EC7BB360C989785B6D679633815BF23B4813116243C47582B90CDF9F4EA7F174C916430A443F183B561CB21365A69472D84300C296

https://www.aicpa.org/Professional+Resources/Accounting+and+Auditing/Authoritative+Standards/auditing_standards.htm

http://www.bsi.de/english/gshb/download/index.htm



3. Emergency user accounts are required in cases when standard administrator ac-counts cannot be used. In contrast to standard administrator accounts, they have comprehensive authorizations and as such must be deactivated during regular op-erations.

4. In order to ensure and assess the effectiveness of the emergency concept and com-prised response processes, emergency situations must be exercised on a regular basis, with or without prior notification of responsible people. Such exercises ensure that, for instance, emergency user passwords are timely divulged to responsible per-sonnel.

(b) The actual management of a given emergency starts with its detection, which can be done by end users, during the various administrative tasks outlined in later sections or in an automated fashion by monitoring tools. Upon detection, the potential emergency needs to be communicated to the responsible person or group (e.g. via email or a central phone number and subsequent dispatching). The communication channels to report alerts for detected emergencies have to follow the guidelines of the emergency concept, especially regarding encryption of the alerting message and the choice of the communication channel to prevent disclosure of critical events to unauthorized personnel.

The responsible hereby relies on documentation that describes (1) how to assess the impact gravity of a given event and (2) an emergency response process that helps overcoming the emergency situation.

The description, how to identify emergency situations, the creation of the response process description and the naming of a responsible person or group must happen during the security design and setup phase. At least the following emergency events must be covered, hereby distinguishing whether the system in question is still operative:

● SAP system is not operative

Disruption of a SAP system, a database system or network connections due to hard-ware failures or resource limits (load).

● SAP system is still operative

o Discovery of critical vulnerabilities, generally resulting in closing the vulner-ability (e.g. by applying a patch) and checking if vulnerability has been al-ready exploited.

Example emergencies are the announcement of an urgent security hot-fix or the discovery of a critical vulnerability in the company’s website.

o Detection that a system is compromised and that certain damage occurred.

This results in the identification, analysis and closure of the vulnerability, the analysis and reparation of damage already occurred and the limitation of fur-ther damage.

Example emergencies are the detection of a virus, denial of service attacks, the loss, divulgation or manipulation of confidential business data and the loss of account information (user management system has been compro-mised).


Page 21 of 59


The response process description that describes how to overcome the emergency situation differs from case to case. However, reoccurring measures are the utilization of the above-mentioned emergency user, the restoring of backups, the switch to a replacement infrastruc-ture or special startup modes of systems and applications (J2EE single-user mode, UNIX run levels etc).

A finishing review of occurred emergency cases should allow the enhancement of the docu-mentation in the emergency handbook. In case of the activation of emergency user sessions or the operation on critical data and system, monitoring of the activities is mandatory and should be enforced by process management tools. Afterwards, the security administrator has to ensure the issuing and reset of emergency user credentials.


All activities of Emergency Management Operations must be developed, described and planned in an emergency concept, which is created during the Run SAP design phase and refined during the setup phase. The identification of the risk and availability requirements by the process owners are the basis for the definition of an emergency concept. The security management aggregates all these emergency scenarios of the process areas and adds tech-nical infrastructure focused emergency scenarios to ensure a complete coverage of possible emergency situations.

The Emergency Concept has to describe:

● Relevant emergency cases, their detection, their impact and the description of ap-propriate response processes.

● Assignment of responsibilities (including deputies) to emergencies and corre-sponding contact information (email addresses, phone numbers, pager etc.)

● Alerting concept to ensure a timely notification of the responsible person in charge of a given emergency.

● Selection of appropriate data sources that help detecting emergency situations and as such allow immediate reaction (e.g. firewall logs, execution of critical transac-tions, CPU and memory monitors). Determination of criteria and thresholds that indi-cate a potential or actual emergency situation. Responsible persons as defined be-fore need to be maintained in the respective monitoring tool.

● Backup and restore concept to describe (a) what data is subject to backups, (b) where and how the data is stored (e.g. on storage media that is physically separated from the original data), (c) how often backups need to be taken, (d) restore and dele-tion procedures, and (e) how to protect access to backup data and (f) procedures for testing backup restore operations, media quality and device availability.

● Replacement concept that describes the replacement infrastructure on network and system level and related procedures.

● Emergency exercise concept to assess the effectiveness and efficiency of the emergency process.


Page 22 of 59


● Emergency user concept that defines special authorizations and assigns them to emergency users for all relevant system components. The passwords of these users must be strong, kept in a safe place, divulged in emergency cases only and changed after every use. A documented procedure explains under which circumstances the credentials can be accessed, how to activate these accounts in emergency cases and how to document usage and activities as required by compliance regulations.

See also:

● SAP Help Portal: User and Role Administration (of NetWeaver AS ABAP)

● SAP Help Portal: User Management (of NetWeaver AS Java) and Activating the Emergency User

● SAP Corporate website: BusinessObjects Access Control

● E2E Solution Operations Standard Incident Management: Defines the process and tool to manage the required collaboration between the involved parties to resolve in-cidents in a timely manner.

● E2E Solution Operations Standard Exception handling: Explains how to define mod-els and procedures to manage exceptions and error situations during daily business operations.

External links:

● BSI IT-Gundschutz Catalogues 2008: M 6.97 Notfallvorsorge für SAP Systeme (German)

● BSI IT-Gundschutz Catalogues 2005: S 6, Safeguard Catalogue Contingency Plan-ning

● BSI IT-Gundschutz Catalogues 2005: B 1.4, Data Backup Policy

4.3.2 Collaboration Security

The secure operations track Secure Process and People Collaboration concerns the security of collaborations in terms of business processes and people interaction. Security aspects of network connections are addressed in the secure operations track Network, System, Data-base and Workstation Security.

4.3.2.1 Secure process and people collaboration

This section covers security aspects of collaboration in the sense of distributed and auto-mated business processes and people collaboration by means of business data exchanges through intranet or internet portals, simple emails, content or document management sys-tems, etc. Such collaboration happens within and across domains. The latter comprises any communication with business partners, including customers, and is subject to legislative regulations and business partner specific policies which need to be enforced. The security of such collaboration must be based on common standards, both in terms of industry standards


Page 23 of 59

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/52/671126439b11d1896f0000e8322d00/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/45/b90177cf2252f8e10000000a1553f7/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/EN/3a/4a0640d7b28f5ce10000000a155106/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/EN/3a/4a0640d7b28f5ce10000000a155106/frameset.htm

http://www.sap.com/solutions/sapbusinessobjects/large/governance-risk-compliance/accessandauthorization/index.epx

https://service.sap.com/%7Esapdownload/011000358700000336602007E/



http://www.bsi.bund.de/english/gshb/download/it-grundschutz-kataloge_2005_pdf_en.zip




(EDIFACT, RosettaNet or CIDX) and security standards for encryption, signatures, authoriza-tion, and authentication protocols.


Operations activities can be distinguished into (a) ongoing maintenance and operation, (b) continuous review of security settings, (c) assessment activities with regard to legal and con-tract-specific policies and guidelines and (d) monitoring and analysis of activity logs and eventual reaction on suspicious log entries.

a) Maintenance and operation of Public Key Infrastructure (PKI), users and authorizations, message-level security and Anti-Virus software

The security administrator maintains the PKI that is used for internal and external collabora-tion processes. This includes the installation of new or updated business partner certificates, the update of the root certification authorities (CA), and the maintenance of certificate revoca-tion lists. In addition to certificate management, the PKI’s integration into server and client-side software needs to be maintained (email clients and servers, SAPGUI etc).

User administrators maintain accounts used by customers and partners in collaboration sce-narios and restrict their authorizations (also see secure operations track User and Authoriza-tion Management). In general, the usage of anonymous accounts must be avoided and prin-cipal propagation of the calling party to the final backend system should be ensured if possi-ble. In cases where this is not possible, appropriate service users must be used.

Security and application administrators need to adapt message-level security measures (such as the signing and encryption of selected payload elements) to changes of the mes-sage schemes. Other maintenance activities to be performed in the SAP NetWeaver Ex-change Infrastructure (XI) Integration Directory concern, for instance, the maintenance of communication channels including authentication schemes, service user credentials or prin-cipal propagation.

With regard to document exchanges in general (upload utilities, mail attachments, attach-ments to Web service messages etc.), system administrators update the signature database of the Anti-Virus software on application level in order to ensure the sanity of any uploaded or exchanged content. To that extent, the SAP Anti Virus Interface allows the integration of 3rd party Anti-Virus software into standard and custom software. Based on updated signature databases, system administrators must ensure periodic and event-based virus checks.

b) Review of security settings

The security administrator needs to review changes on a regular basis and according to a predefined concept and schedule. If change management is used in SAP Solution Manager, it can provide a quick overview of configuration changes that require special attention. The review activities shall be performed according to the segregation of duties principle (with re-gard to the above-mentioned maintenance) and require an appropriate documentation.


Page 24 of 59

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/0f/80243b4a66ae0ce10000000a11402f/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/0f/80243b4a66ae0ce10000000a11402f/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/EN/e3/aa783f181b0866e10000000a114084/frameset.htm


The following settings are of special interest:

● Appropriate log levels that satisfy internal requirements and at the same time do not collide with external requirements and obligations

● Maintenance of account information provided to customers and partners

● Appropriate authorization of service users for backend connections, no usage of dia-log users in Web service and RFC based communication settings

● Authentication settings and certificate management for external interfaces (WS based business processes and collaboration tools)

● Message-level security measures (encryption, signatures) for SAP NetWeaver XI

● Virus signature database of Anti-Virus software (application level) and appropriate configuration and integration in standard and custom software (e.g. for document up-load functionalities)

● Appropriate settings for Secure Store and Forward (SSF), e.g. the maintenance of user SSF information

● Privacy Enhanced Mail (PEM) and Secure Multipart Internet Message Extensions (S/MIME) settings for mail functionalities in SAP systems

c) Policy enforcement

Cross-domain collaboration scenarios that involve external business partners such as con-sumers or suppliers are subject to legislative regulations (e.g. data protection laws) and con-tractual agreements. Such collaboration policies concern, for instance, the tracing of activi-ties, data retention limits and obligations or data segregation requirements.

During operations, the data protection officer and the internal auditors ensure that the above mentioned maintenance activities comply with all policies that result from a company’s vari-ous collaboration scenarios (these policies have been defined during the design phase). This concerns at least the following aspects:

● Integrity, authenticity and confidentiality for data in transit, regarding end-to-end se-curity and communication channel security

● Obligations to check the sanity of submitted data (viruses)

● Authentication schemes

● Requirements concerning the storage of exchanged data and access to it (retention time limits and obligations, encryption, data segregation, user authorizations, data in-tegrity protection)

● Requirements concerning activity logs (level of detail, retention times, anonymization)

In addition to verifying that the company itself fulfills all requirements, their respective en-forcement at the business partner side can be audited, e.g. by 3rd party auditors.


Page 25 of 59

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/53/251a355d0c4d78e10000009b38f83b/frameset.htm


d) Monitoring and review of activity logs

System and security administrators perform periodic monitoring activities to ensure the inter-nal and external fulfillment of the identified policies.

In case of suspicious log entries detected by security administrators, security analysts or suitable detection and monitoring tools, it is mandatory to perform a root cause analysis and appropriate resolution procedures to incidents such as:

● Incidents during business process execution

o Suspicious business activities (e.g. business processes triggered on week-ends or during vacation times, extensive download activities)

o Failed authentication attempts on involved systems (e.g. on reverse proxies, integration servers, backend systems)

o Integrity violation (e.g. failed signature checks, caused be expired or revoked signatures, outdated certificate stores, tampering of data in transit etc.)

o Related to data transfer (peaks of virus occurrences, including a classifica-tion and damage potential)

● Incidents or events related to configuration changes

o Suspicious authorization changes

o Key changes (password, certificate, symmetric keys)

Resolution procedures for fraudulent activities performed by internals or business partners can lead to measures such as deactivation of user accounts, criminal prosecution, break of business relationships etc.


Design activities comprise the identification of security requirements, the creation of a col-laboration security concept as well as a review and monitoring concept.

The data protection officer and the security team identify the security requirements for all relevant collaboration scenarios (also see BSI safeguard S 2.340, Observing legal framework conditions). Beside the above-mentioned aspects (protection of data in transit, storage of exchanged data and access control, activity log levels and authentication), such requirements must also concern organizational aspects, such as having dedicated points of contacts in the partner organization, especially for security issues, the necessity of non-disclosure agree-ments and formal obligations concerning the intended and permitted data usage.

All requirements result in internal and external policies, the latter being addressed in mutual agreements between the business partners in terms of contracts or general terms and condi-tions (also see BSI safeguard S 5.88, Agreement regarding the exchange of data with third parties).


Page 26 of 59


Based on policies, a collaboration security concept needs to be defined, including the follow-ing aspects, each to be addressed by the respective stakeholder:

● Network and Communication Security regarding the security of network zones, transport layer security and secure configuration of network components

● Logging for collaboration activities and activities that access exchanged data (for in-stance by internal employees)

● Data classification, data storage and data retention (in terms of minimum retention times as well deletion obligations, e.g. upon request of business partners)

● User, authorization and authentication concept for

o Business partner, including certificate management and possible segregation of user data by, for instance, separate user stores. See also secure opera-tions track Secure Support, where support user accounts are one example of users dedicated to business partners.

o Internal employees with access to business partner data and related logs

o Service users that are used in middleware components (e.g. reverse proxies, enterprise service busses) and on backend systems

● Protection of data in transit by authentification and encryption

● Integration of anti virus software into collaborative application components (e.g. via the SAP Virus Scan Interface)

● Policies for user collaboration, regulating and formalizing direct or indirect exchange of information (through document exchanges, communication via phone etc). These policies need to be rolled-out to the respective end users prior to going live

System and security administrators implement the collaboration security concept, hereby setting up the PKI with an initial set of certificates and integrating and configuring Anti-Virus software for collaborative tools such as Content and Document Management Systems.

During setup, application administrators define the actual data classification dependent of the criticality of the application and designated user group for the data.

They set up logging tools according to internal and external policies, hereby restricting the access to these logs to a pre-defined role that is properly assigned. As such logs as well as the business data itself represent sensitive information, access to these files need to be documented (who accessed the data for what analysis purposes) and may be subject to fur-ther controls such as 4 eyes principle or peer reviews). See BSI safeguards S 2.64, Checking the log files, and S 2.110, Data privacy guidelines for logging procedures for more details.

During the setup phase, the user and authorization manager set up roles and scenarios as required for collaboration. For automated business processes, partner specific user accounts are created, assigned to these roles, communicated to external partners and certificates are exchanged. Required service users are created on backend systems. Roles are built for in-ternal employees that work with exchanged business data and created logs.


Page 27 of 59

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/e3/aa783f181b0866e10000000a114084/frameset.htm


The security administrator sets up the XI Directory including message-level security controls for encryption and signatures, authentication mechanisms for backend systems, and partner connectivity kits.

See also:

● E2E Solution Operations Standard eSOA Readiness: Support the organizations on their way to eSOA and running existing eSOA (i.e. Web Service) scenarios

● SAP Help Portal: Enabling Business-to-Business Processes: Security Aspects

● SAP Help Portal: SAP NetWeaver Process Integration Security Guide

● SAP Help Portal: SAP NetWeaver Collaboration Security Guide

● SAP Help Portal: Web Services Security

● SAP Help Portal: SSF Administration Tasks

● SAP Training: Curriculum: SAP NetWeaver Process Integration - Exchange Infra-structure

● SAP Help Portal: SAP NetWeaver Exchange Infrastructure – Central Monitoring

SAP Help Portal User Types (explains different user types in SAP NetWeaver XI)

● SAP Help Portal Auditing (details the logging of changes to XI design and configura-tion changes as well as actual message exchanges between external or internal ap-plications)

● SAP Help Portal: Virus Scan Interface

● SAP Help Portal: SAP NetWeaver Exchange Infrastructure – Central Monitoring

● SAP Help Portal: Security Configuration at Message Level.

● SAP Help Portal: Certificate Store

External links:

● BSI IT-Gundschutz Catalogues 2005, Safeguard S 2.64, Checking the log files

● BSI IT-Gundschutz Catalogues 2005, Safeguard S 2.110, Data privacy guidelines for logging procedures

4.3.3 Identity and Access Management

4.3.3.1 User and Authorization Management

Employees, customers as well as service delivery personnel have accounts for the IT sys-tems. In addition, technical users are necessary for communication and system maintenance. They differ in terms of provisioning and de-provisioning workflows, the business needs that trigger these workflows, data sources of the user creation, data protection level of the re-quired personal data, and the extend of authorizations the user group will have:


Page 28 of 59

http://service.sap.com/%7Eform/sapnet?_SHORTKEY=01100035870000711194&_SCENARIO=01100035870000000202&_OBJECT=011000358700000336592007E

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/44/5872da82cb6d12e10000000a1553f6/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/f7/c2953fc405330ee10000000a114084/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/c0/a0784104c3127de10000000a155106/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/50/a5d13f83a14d21e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/30/640b378350c976e10000009b38f839/frameset.htm

http://www.sap.com/services/education/catalog/netweaver/curriculum.epx?context=%5b%5bBITPIT1%5d%5d%7c

http://www.sap.com/services/education/catalog/netweaver/curriculum.epx?context=%5b%5bBITPIT1%5d%5d%7c

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/7c/14b5765255e345a9e3f044f1e9bbbf/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/5c/d12940cbf2195de10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/84/6f29658e7aed4c9317b6be03e8b050/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/e3/aa783f181b0866e10000000a114084/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/7c/14b5765255e345a9e3f044f1e9bbbf/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/ea/c91141e109ef6fe10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/23/d12940cbf2195de10000000a1550b0/content.htm




● Internal employees are handled by the human resources department:

o regular employees

o part time employees

o internal help desk employees and internal administrators, which tend to have more wide range authorizations and which’s maintenance require additional security measures (see secure operation tracks Secure Support and Admini-stration Concept)

● External employees, which can have similar roles as internal employees. And cus-tomers, business partners or other stakeholders. All of them have access to IT sys-tems and facilities, controlled by the IT infrastructure

o Collaboration partners with a business focus like customers or business sup-pliers (see secure operations track Secure Process and People Collabora-tion) and all entities involved in the company’s business processes. An in-herent connection from the identity to a user accounts is known internally and is maintained from business units (like in a CRM or SRM system). A common example is personnel of an outsourcing organization (see secure operations track Outsourcing).

o Known personnel to the company like consultants or leased personnel, which is integrated into the companies internal processes (time recording, vacation planning) and which are supposed to use the IT infrastructure (terminals, email, intranet portal), infrastructure access (buildings, canteen), these iden-tities can be handled by the HR department as well.

o A priori anonymous personnel of contractors, which require temporal access to selected systems and applications, will not be managed by the company’s user management system but result in the creation of accounts that will be provisioned and released on explicit request (e.g. external help desk em-ployees, outsourcing service providers). A common example is personnel of external help desks, responsible for incident handling processes, which needs support users for the service delivery organization (see secure opera-tions track Secure Support).


The operation of the identity and access management process comprise activities regarding

a) workflow maintenance by user administrators

b) infrastructure maintenance for the identity storage and authorization distribution and management, mainly performed by the security administrator

c) special authorizations for the administrators themselves (security administrators)

d) integration of a risk analysis in the Identity and Access Management (IAM) work-flows, maintained by security administrators and used by security analysts

e) monitoring of Identity and Access Management (IAM) solutions, performed by secu-rity administrators

f) role maintenance, performed by authorization administrators


Page 29 of 59


The following paragraphs describe the necessary processes to a compliant user and authori-zation management.

a) Workflows and workflow maintenance

End-users should be able to initiate a series of workflows, like:

● account and authorization requests

● change or reset the own password by request and on a periodically basis

● user de-provisioning on timeout or explicit request

Administrators should be able to maintain:

● user synchronizations or transfers from one system to another

● user locks on various systems

● controlled tracing of activities as an incident response

● roles, either business roles or technical authorizations details

The user administrator is responsible for the maintenance of the user workflows and the user store maintenance.

The user should get access to different workflows per user group and destination system for the applications.. The maintained workflow system authorizations to access these distinct workflows based on user groups enables employees and other stakeholders using a self-service to apply for authorizations for the systems they are dedicated to work with. On this basis, the user administrator maintains the following process:

● Users are created and a provisioning process is performed on external triggers or on request in a workflow management system

● Authorizations are granted and removed, based on risk approvals and management decisions which both have to be documented

● Authentication mechanisms (certificate management) are reviewed and rebuilt includ-ing the maintenance of the Single-Sign-On Authentification Architecture with certifi-cate distribution and removal

● The logging and monitoring of all workflow activities, like requests, analysis, approv-als, provisioning and de-provisioning steps should be configured and performed

● De-provisioning processes are performed on a periodically basis, enforcing limit dates of authorizations

All these activities should be performed using an identity management tool to ensure a robust automated process, seamless documentation, reliable and short workflow times, as well as a reviewable process with detailed time stamped entries for every workflow step.


Page 30 of 59


b) Infrastructure Maintenance

Dedicated user management systems, in addition to local user stores of the already existing system landscape, should be employed for the purpose of identity storage and consolidation. These dedicated identity management systems support IAM workflows, risk analysis and compliant role creation and have to be maintained by the system administrator. They should be monitored for availability and administrative access.

The synchronization of different user stores should be maintained periodically by the security administrator. In case of additions of new systems to the system landscape, the system con-nection to risks analysis tools and the user store need an adjustment of the destination sys-tems, which should be considered and defined in the identity management workflow.

The security administrator maintains the Single-Sign-On authentification architecture by managing the certificates and distribution process to the client machines. This procedure will be used for applications with a high number of users and a high number of logins.

c) Authorizations management for administrators

The user group of administrator users should be handled restrictive because their wide range authorizations are often available across many systems. Especially in the case of administra-tor’s, appropriate mechanisms, like the segregation of duties, must be ensured (see secure operations track “administration concept”). Additional logging mechanisms should ensure the correct workflow documentation and auditability. Activities with a high risk should be per-formed in a documented peer review process, demanding additional approvals or introducing an emergency authorization concept which also enables exceptional documented administra-tion sessions with change logs and integrated alerting mechanisms to the responsible risk owners.

d) Risk Analysis

The security administrator is responsible for the operation of risk analysis and performs a series of maintenance and review activities for authorization risks, to ensure compliant au-thorization assignments to the already defined or customized risk rule set. He schedules and monitors periodically risk analysis of all roles and users of the systems for segregation of duties and critical authorizations. Actual authorization risks should therefore periodically be identified by an analysis tool to ensure a complete view of the risk situation for all systems and business areas. An additional periodic review of the risk rule set ensures the effective-ness of all defined risks in the analysis.

Authorization administrators should maintain the roles, based on the knowledge about identi-fied risks, and suggest role withdrawals to the appropriate risk owners. In cases a role with-drawal is not possible, the risk owner could decide to mitigate the risk. This could either be done by documenting the acceptance of the risk for distinct personnel or by a more effective and repeated approval process including internal control reports. On this basis, the commit-ment for periodic reviews of this authorization assignment is obligatory for the risk owner.


Page 31 of 59


The security administrator maintains the risk definitions in a risk analysis tool (e.g. SAP Busi-nessObjects Access Control risk analysis and remediation) according to the identified risks by the respective process owner in the different business units. This is especially relevant for customer transactions and developments.

e) Monitoring of Identity and Access Management (IAM) solutions

For highly critical activities in the system, thresholds and corresponding alerts should be de-fined by the security administrator in order to report critical data changes to the responsible personnel. Periodic manual checks of the following aspects enhance the review with indica-tions for actual suspicious activities:

● Security administrators should periodically review for suspicious events like

o Wide range authorization requests with a determined high risk

o Open, not already executed de-provisioning tasks

o Authorization requests, pending for a long time

o Requests and approvals on weekends or holidays

● If critical activities are currently performed on the system, alert messages have to be analyzed by security administrators and security analysts for business critical threats. If user activities are traced, the user has to be informed accordingly, in compliance to laws and policies.

● The risk owner of wide range authorizations should periodically check for possible role omissions and used authorizations for critical actions.

● User workflow related KPIs, like logins attempts with wrong passwords or repeated user account closings caused by wrong passwords

● By using data from firewalls and system communication logs, high numbers of un-successful (but also successful) logins from a single machine can be detected. Such events can indicate denial of service and password guessing (dictionary) attacks and should be reviewed.

The user provisioning workflow monitoring is performed by the user administrator who is re-sponsible for the synchronization and mapping of user stores. The provisioning decisions itself should be done by the business areas the employee is working for. Security checks should be mandatory integrated into the provisioning workflow.

To ensure correct operation of the identity workflows, the security administrator should review the logs with a focus to probable collisions and erroneous requests.

As a periodically ongoing monitoring activity, the security administrator reviews the complete execution of authorization checks, the performed user provisions and authorization analysis, as well as the authorization alerts and achievements of relevant clipping levels. This regular risk assessment using appropriate monitoring tools ensures the compliant provisioning and de-provisioning of roles as well as user account activation and deactivation.

Risks identified in the automated risk analysis process can be mitigated by the responsible business process owners. Regular checks done by individually assigned responsible em-


Page 32 of 59


ployees for the monitoring activities can ensure the durability of the compliance assurance process also for organizations that are not able to eliminate risks by the change of roles or the withdrawal of role assignments.

f) Role Maintenance

Authorization administrators maintain a custom set of roles for each of the different business units in the organization. On requests by the business units, new roles are created or already assigned roles are customized, analyzed, and eventually changed for the removal of identi-fied authorization risks. In this process of role maintenance, a risk analysis should be inte-grated into a documented role creation workflow to enforce compliant role creations and their maintenance with the avoidance of additional risk, already known to the risk rule set.

To prepare the authorization provisioning process, the technical roles are prepared and ad-justed by the authorization administrators and are bundled to business roles according to the authorization concept and the business need by the application administrators in considera-tion of authorization risks analyzed by compliance tools.

(See secure operations track Administration Concept for more information regarding the au-thorization management of administrators).


The IT management identifies the relevant regulatory requirements for the organization, the current and required IAM processes, and the applications that are in use to store users and authorizations and to perform provisioning and de-provisioning workflows. Dependent on the business needs, technical and regulatory constraints for the Identity and Access Manage-ment process are defined. Minimization of authorization risks and the time for the provisioning workflow are measures to optimize the authorization process on the operational level.

On the basis of these requirements, IT management, internal auditors, the security adminis-trator, and the data protection office define (1) a user administration concept and (2) an au-thorization concept to document the process and constraints.

(1) The user administration concept contains guidelines for:

● user storage, in terms of the physical system location

● data criticality definitions for different user stores containing critical personal data

● constraints for user and authorization workflows

● monitoring requirements for operational security and auditability

● guidelines for naming of users

● password policy

(2) The authorization concept, containing:

● the password policy

● guidelines for naming of roles


Page 33 of 59


● documentation guidelines

● definition of the role creation process including the creation workflow, test and risk check procedures

For each business process, the respective process owners in the different business units have to identify the risks of employee authorizations, such as critical system operations or operations that require segregation of duties. The process owners should also decide who is responsible for the risks and how severe the impact and probability is based on an estimate of the activity frequency.

The security administrator is responsible for the definition of the already identified risks using appropriate tools to enable a schedule for periodic tests. Such periodic checks are mandatory and their omission must be alerted to IT or security management. The security administrator also defines clipping levels (thresholds) for alerting in case of critical system activities or business transactions.

According to these rules, the system administrator implements the authorization workflow, using identity and access management tools, which ensure the compliance with regard to possible authorization risks. Also required de-provisioning tasks, depending on time, em-ployee status changes, or additional system maintenance decisions, should be configured and scheduled for periodical checks.

Password policies in the relevant user management systems (e.g. the User Management Engine of SAP NetWeaver AS Java or the AS ABAB user administration) should be config-ured by the security administrator, following common guidelines regarding password com-plexity (e.g. concerning the minimum length or maximum validity periods) and authorization assignment constraints in compliance with the authorization concept and decisions made by the data protection officer.

Following these guidelines, the security administrator also sets profile parameters regarding e.g. the lifetime of authorization assignments or rules regarding simultaneous logins. Such limitations allow restrictions of known phrases in passwords or the number of old passwords which are not allowed to choose in a password change.

The authorization team defines a set of initial authorizations for different user groups in the business units with respect to minimizing the risk of wrong performed activities in a business process, either by intention or missing knowledge about the process or application details.

The guidelines regarding the authorization handling, workflow usage and password policies should be communicated by IT management to the appropriate administrators and end-users in an easy and effortless documentation. Periodic trainings support the awareness of the employees to follow these guidelines and help to enforce the right behavior in terms of au-thorization specific tasks.

As the system landscape grows over time and more and more Web or non-Web applications are added, managing the passwords for each individual solution becomes a real challenge. The best solution for this problem is the use of Single Sign-On (SSO), where users authenti-cate themselves once with a system and do not need to authenticate with any further system


Page 34 of 59


or application. When using SSO, IT Management has to decide about which SSO authentica-tion method should be used.

See also:

● User Management

o SAP Help Portal: Identity Management

o SAP Help Portal: Integrated User and Access Management (with and without an external directory server)

o SAP Help Portal: User Administration and Identity Management in ABAP Systems

o SAP Help Portal: User Management of the Application Server Java

● SAP Training: Curriculum: Cross Component Role: User & Security Administration

● SAP Training: TZNWIM - User Management by SAP NetWeaver Identity Manage-ment


● SAP Training: GRC310 - SAP BusinessObjects Access Control - Compliant User Provisioning & Enterprise Role Management

● Authentication:

o SAP Help Portal: Authentication on the AS ABAP

o SAP Help Portal: Authentication on the AS Java

o SAP Help Portal: Logon and Password Security in the SAP System

o SAP Help Portal: Using X.509 Client Certificates

o SAP Help Portal: Using Logon Tickets

o SAP Service Marketplace: Media Library Authentication and Singe Sign On

● SAP Service Marketplace: Media Library Access Control

● SAP Service Marketplace: Media Library Authentication and Singe Sign On

● SAP Developer Network: Identity Management for SAP System Landscapes: Archi-tectural Overview

● SAP Service Marketplace: SAP NetWeaver IdM Security Guide

4.3.3.2 Administration Concept

This section describes how authorizations of administrators or other groups with wide range authorizations should be handled. The authorizations of administrator groups need to be secured additionally, as their responsibilities bear significant risks. Example groups are secu-rity administrators, IT administrators, data custodians, auditors, developers, and the data protection office. Additional security measures for these groups concern the identity and ac-


Page 35 of 59

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/81/0e0f61b566dc44bbb4055b3ccd25be/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/42/ea3010b2201bdae10000000a11466f/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/47/fe89a62d204aa7e10000000a421937/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/47/fe89a62d204aa7e10000000a421937/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/48/0d9fe9439612dbe10000000a42189d/frameset.htm

http://www.sap.com/services/education/catalog/netweaver/curriculum.epx?context=%5b%5bADM_USERSEC%5d%5d%7c

http://www.sap.com/services/education/catalog/globaltabbedcourse.epx?context=%5b%5b%7cTZNWIM%7c%7c%7c074%7cG%7c%5d%5d%7c

http://www.sap.com/services/education/catalog/globaltabbedcourse.epx?context=%5b%5b%7cTZNWIM%7c%7c%7c074%7cG%7c%5d%5d%7c





http://help.sap.com/saphelp_nw70ehp1/helpdata/en/02/d4d53aa8a9324de10000000a114084/content.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/f8/9636eedafe8b4589cd6e9e4e73fd3c/content.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/52/6717ed439b11d1896f0000e8322d00/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/b1/07dd3aeedb7445e10000000a114084/content.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/f8/18da3a82f9cc38e10000000a114084/content.htm

http://service.sap.com/%7Eform/sapnet?_SHORTKEY=01100035870000668333&



https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f0ad23d3-3664-2a10-8aa7-e9c3c8616d48

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f0ad23d3-3664-2a10-8aa7-e9c3c8616d48

http://service.sap.com/%7Esapidb/011000358700000065722008E


cess management (IAM) workflows, such as multi-level approvals that enforce a four or six eye principle.

Initial administrator accounts are generated automatically on all levels of infrastructure or application systems. These initial or default accounts should generally not be accessible through standard default passwords and any access to their account data must be restricted. The mechanism for administrator user and password maintenance should be provided by IT management and maintained by the security administrator. Their passwords should be changed periodically and in case of responsibility shifts.


The workflows are very similar to those described in the secure operations track User and Authorization Management, but additional logs and review activities, especially for view ac-cess, are required to mitigate the high risks generated by the activities of these employee groups.

The maintenance of the administration accounts and passwords is under the responsibility of the security administrator. The user administrator makes sure that, if possible, different ad-ministrators get restrictive roles in compliance to segregation of duties requirements. If this is not possible, the administrators should perform a documented peer review process imple-mented by the 4 or 6 eye principle or process integrated approval steps for critical changes.

As an accompanying activity while performing critical authorizations changes, the administra-tors should regularly perform a peer review before using changed configuration in productive systems. Critical authorizations should not permanently be attached to the user but can be quickly requested in a transparent, especially logged user session for every critical activity. Tools like SAP GRC Access Enforcer Superuser Privilege Management enable administra-tors to make their production critical operations reviewable.

The Audit Information System displays an overview of users that have the following critical authorizations on a given SAP system, similar information is also part of the Security Optimi-zation Service:

● Control of User Modes and Work Processes

● Edit of ABAP Programs

● Use the Transport System

● Change Posting Periods

● Change Company Codes

● Change Charts of Accounts

● Call Up RFC Functions

In order to detect segregation of duties violations for administrative users, SAP BusinessOb-jects Access Control Risk Analysis and Remediation can be used.


Page 36 of 59

http://service.sap.com/sos

http://service.sap.com/sos


The Security Administrator as a log reviewer of the production critical system administration activities is responsible to react on dangerous system configuration changes which can ob-struct the productive process or disrupt system security.


During the Design phase, the following activities need to be performed:

a) User administration and authorization concept for IT administrators

b) Definition of review processes

a) User administration and authorization concept for IT administrators

During the secure operations track User and Authorization Management, regulatory require-ments and critical authorization risks have already been defined, both for business operations of regular IT end-users as well as for administrative operations of IT administrator personnel. One aspect, which is commonly checked during audits and which concerns administrator operations, is the handling of emergency users. Typical risks related to administrators com-prise self authorization, thread hiding and log manipulation.

Based on these risks and requirements, a user administration and authorization concept for IT administrators needs to be created by IT and security management. Differences with re-gard to the similar concept for IT end-users concern the following:

Increased use of peer review and approval steps in provisioning processes

Avoidance of self authorization: Administrators must not be able to maintain their own authorizations on productive systems. Authorizations always should be performed by the responsible administrator and an approval process including a risk analysis.

Monitoring requirements for operational security and auditability: Increased logging and log level of critical activities (to be validated by data protection officer)

Password policy: Increased complexity and shorter renewal intervals, accompanied by awareness campaigns to motivate these measures

The emergency authorization concept describes how critical configurations and ur-gent actions can be performed by personnel usually not authorized for it (e.g. depu-ties in case the responsible is not available). This should be handled through man-agement by exception, where critical authorizations are given restrictively, on explicit user request and are subject to dedicated logging. As already mentioned in the se-cure operations track Emergency Concept, the tool SAP BusinessObjects Access Control Superuser Privilege Management (SPM) can facilitate the management of such cases of emergency authorization usage.

Segregation of duties for administration tasks. The authorization administrator should define special restrictive roles for the different administrator groups. The construction of roles and the user provisioning should not be the responsibility of single adminis-trative employees. This prevents self authorizations and enables segregation of du-ties for the critical administration tasks.


Page 37 of 59


Segregation of duties for risk definition: The definition of risk for an automated au-thorization risk assessment should be performed by security administrators. To en-sure a secured software lifecycle and prevent the loss of data, the file system au-thorizations should be divided into the access of different groups. So the download activity of the patches and the actual activation of patches in the system can be separated. The signature check and other error prevention methods can be distrib-uted to different employees.

Authentication requirements for the individual applications and systems (especially productive systems):

o Stronger authentication mechanisms, e.g. X.509 client certificates or biomet-ric solutions for SAP system logon (as offered by SAP-certified partners)

o Reduced support of Single Sign-On for administrative tasks

b) Definition of review processes

Activities of administrators should be reviewed on a more frequent basis than it is the case for regular IT end-users. The definition of dedicated review processes should deal with the fol-lowing aspects:

Responsibility for review activities (hereby considering SoD constraints: reviews must not be performed by the activity responsible)

Schedule and documentation requirements

Tools required (see secure operations track Audit)

Subject to dedicated review activities is the following:

● Access to critical resources

● De-provisioning of users and authorizations

o After emergency cases

o After changes in the job assignment of administrators

● Compliance of authorizations with risk rule sets (created during the risk analysis phase in the tool SAP BusinessObjects Access Control)

● Search for dormant users

Once these activities have been performed and the resulting processes and settings have been thoroughly tested, the actual administrators (that maintain the system during operations, opposed to those responsible for the implementation project) can be provided with their re-spective roles, hereby using the provisioning workflows. Simultaneously, guidelines and password policies must be rolled-out.

See also:

● SAP Service Marketplace: Audit Information System (AIS)

● SAP Help Portal: Auditing and Logging (introduction to SAP NetWeaver AS ABAP logging tools, such as the Audit Information System or the Security Audit Log)


Page 38 of 59

http://service.sap.com/ais

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/8a/a8b5386f64b555e10000009b38f8cf/frameset.htm


● SAP BusinessObjects Access Control


● SAP Training: TZGC53 - EPT SAP BusinessObjects Access Control 5.3

● SAP Training: ADM950 - Secure SAP System Management

● SAP Help Portal: User Authentication (SAP NetWeaver AS ABAP)

4.3.4 Infrastructure Security

4.3.4.1 Network, System, Database and Workstation Security

As a basis for a secure operation, the security of the infrastructure is an inherent component for a secure IT-System and consists of the network infrastructure and the physical systems themselves. Security issues that arise on server and client operating system or on database level can undermine elaborate authorization concepts for business solutions that rely on those infrastructure components.


The operation activities comprise maintenance and review activities, which will be explained on the levels of (a) operating systems, (b) databases, (c) networks and (d) end user worksta-tions. All of these activities shall follow concepts that were defined during the design phase and initially implemented during the setup phase. Those concepts describe documentation needs and schedules. Changes to critical configuration settings must follow a change man-agement concept as described in the secure operations track “Secure Configuration”.

To periodically assess a match of the current configuration to the valid risks the IT organiza-tion has, the respective administrator reviews the configuration setting on all levels. Also, all infrastructure components need to be monitored with regard to activity logs, availability and performance, hereby relying on SAP Solution Manager functionality.

Beside such ongoing review and monitoring activities, internal auditors need to audit the in-frastructure setup and configuration with regards to internal and external policies and regula-tions.

A library of all IT infrastructure components must be maintained and always kept up-to-date, including precise information about operating systems, technical software components and business solutions, their support package and patch level. To that respect, SAP Solution Manager offers ITIL compliant processes that support the infrastructure management.

a) Operating system

Maintenance activities on OS level are performed by system administrators and security ad-ministrators and comprise (see also SAP Security under Windows and SAP Security under UNIX/Linux):


Page 39 of 59




http://www.sap.com/services/education/catalog/overview/globaltabbedcourse.epx?context=%5b%5b%7cTZGC53%7c%7c%7c084%7cG%7c%5d%5d%7c


http://help.sap.com/saphelp_nw70/helpdata/EN/eb/4bb638b5358259e10000009b38f8cf/frameset.htm

http://service.sap.com/%7Eform/sapnet?_SHORTKEY=01100035870000401180&_OBJECT=011000358700000485832007E




Verification that previous OS hardening measures are still effective, hereby following the guideline that SAP solutions should be installed on dedicated systems:

● Restriction of operating system services only to the distinct services needed for the SAP System Operation. Deactivation or de-installation of unnecessary services. Sys-tem Administrators are responsible for monitoring suspicious processes.

● Restricted access to SAP specific directories, e.g. the directory used by the SAP NetWeaver AS ABAP Transport Management System (TMS)

● Appropriate user, authorization and authentication management in terms of user stores, user (de-)provisioning, password policies and authentication modules. Any of these must follow the guidelines provided in the secure operations track “User and Authorization Management”.

● The logging of OS security events must be enabled. Those logs as well as all logs written by the SAP Systems on the file system have to be stored in separated folders. Restrictive read only access must only be given to security administrators. Error dumps should be deactivated on productive systems in order to prevent loss of confi-dential information.

On changes of the system environment or if new firmware or patches become available, the system administrator performs regression tests in a test environment and only applies the change to productive systems in case of successful tests. For details about compatibility of SAP Software to applications, consult the Product Availability Matrix in the SAP Support Por-tal.

The system administrator updates the virus signature database of anti virus software, per-forms regular virus checks and analyzes the protocols (also see BSI IT-Grundschutz-Catalogues, safeguard S 2.159, Updating the computer virus scanning programs used, and safeguard S 4.3, Periodic runs of a virus detection program). Upon detection of viruses, root cause and impact analysis must be performed, followed by appropriate resolution procedures (e.g. separation of infected systems from network, quarantine).

System administrators must ensure the data integrity of system critical configuration files and software executables and libraries.

The security administrator searches for abandoned and un-used OS user accounts (e.g. be-longing to employees who changed their position or left the company) that require clarification and appropriate correction. The correction may result in the deactivation or deletion of the account, however, the activity log of that account and the link to the previously assigned em-ployee must be kept.

b) Database

Maintenance activities on database level are performed by database and security administra-tors and comprise (see also SAP NetWeaver 7.0 DB and OS Platform Security Guides):

● Restricted use of database users: Access to databases used by SAP systems should only occur through SAP’s database abstraction layer and authorization concept. The latter would be jeopardized, if database users directly access DB tables with busi-


Page 40 of 59

http://service.sap.com/pam

https://service.sap.com/securityguide


ness data. Any of these must follow the guidelines provided in the secure operations track User and Authorization Management.

● Restricted use of proprietary database tools that can jeopardize the SAP authoriza-tion system. As compensation, SAP Solution Manager offers a series of vendor inde-pendent database monitors and tools (see SAP Solution Manager Database Analy-sis).

● Limitation of database specific functions (e.g. dumping the database to remote sys-tems, as for MSSQL).

● Appropriate logging of security events to protected log tables and/or log files (see OS logging).

● Database usage by different systems or applications that bypass the SAP database abstraction layer must be avoided. Applications that are deployed in AS Java or AS ABAP must be restricted to dedicated tables, e.g. by using correspondingly author-ized database users.

c) Network

Maintenance activities on network level are performed by network and security administrators and comprise – with regard to SAP – the following (see also SAP Help Portal Network and Communication Security):

● Network topology

o Maintenance of an appropriate network topology: Placing SAP servers in dedicated subnets, creating separate security zones - demilitarized zones (DMZ) - protected from each other by properly configured firewall systems.

o Maintenance of an appropriate domain concept: Assigning appropriate sub domains to SAP systems, hereby restricting the visibility of confidential in-formation in cookies, e.g. the SAP Logon ticket.

o Maintenance of application-level gateways and underlying systems: SAProuter for RFC and SAPDIAG connections, SAP Web Dispatcher for HTTP(S).

● OS-level configuration settings

o Limitation of network services started on a SAP system (FTP, mail or others).

o Restricted use of DHCP: The presence of a DHCP mechanism raises the risk of a spoofed IP address association for a SAP Server System. So the usage of static IP addresses is recommended which implies the configuration and management of the address space necessary to connect all existing sys-tems.

o Restriction of non-TCP/IP protocols: To ensure the separation of SAP related network traffic from other network traffic using protocols other then TCP/IP, the handling of these protocols should be deactivated.

o Configuration of SAP or non-SAP cryptographic software for secure network communications (SNC and SSL).


Page 41 of 59

http://help.sap.com/saphelp_smehp1/helpdata/en/f7/51b87f807344eba0ddca2d2174cbee/frameset.htm

http://help.sap.com/saphelp_smehp1/helpdata/en/f7/51b87f807344eba0ddca2d2174cbee/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/fe/a7b5386f64b555e10000009b38f8cf/frameset.htm



● SAP system configuration settings

o Maintenance of RFC connections via transaction SE59, including user cre-dentials and authentication mechanisms.

o Maintenance of system certificates and trusted relationships between SAP systems (for SSO).

o Configuration SAP NetWeaver services such as Internet Communication Framework (ICF).

o Connection to other network servers such as spool servers for printing or message transfer agents (MTA) for email, which may be dedicated to SAP systems, depending on respective requirements (example: usage of dedi-cated email servers for internal and external communications).

d) End-user workstations

Maintenance activities on the level of end-user workstations are performed by system and security administrators and comprise:

● Distribution of software and configuration to end user workstations in order to ensure a consistent landscape of end user client applications, including SAP front-end appli-cations such as the SAPGUI, Interactive Excel (formally known as BEx Analyzer) and others.

● Central monitoring of end user workstations to avoid license conflicts, installation of unauthorized software and vulnerable configuration.

● For secure connections from the end user clients to the application servers, the net-work encryption is mandatory, i.e. HTTPS for browser-based applications and SNC for SAPGUI applications. The latter implies the maintenance of SAP or non-SAP cryptographic software on end user workstations.

● For high security requirements, the end-user application environment (a) can be en-capsulated into virtual machine sessions and only the application server should be accessible from these environments or (b) can have restricted hardware equipment and interfaces and logs its usage.

● Access restriction to SAP installation files on shared drives and usage of the SAP in-stallation server.


As stated in section 3, either a best-practice approach or a comprehensive risk analysis does result in the selection of security measures during the design phase. In case of a comprehen-sive analysis, detailed concepts need to be written for each of the following infrastructure components. In case of a best-practice approach, appropriate measures need be identified and selected (the respective BSI module is provided for each component):

● Operating system (see BSI IT-Grundschutz Catalogues, module B 3.1XX, Server)

● Database (see BSI IT-Grundschutz Catalogues, module B 5.7, Databases)


Page 42 of 59


● Network (see BSI IT-Grundschutz Catalogues, modules B 3.3XX, Network compo-nents and B 4, Security in the network)

● Front-end workstations (see BSI IT-Grundschutz Catalogues, module B 3.2XX, Cli-ents)

● Anti virus protection (see BSI IT-Grundschutz Catalogues, module B 1.6, Computer virus protection concept)

IT management ensures that review and change management procedures for each infra-structure component exist and that these are supported by IT tools, e.g. SAP Solution Man-ager Change Management. Beside the test of changes, checklists (provided by internal audi-tors) ensure that changes happen in a compliant manner and result in a compliant IT infra-structure.

The security team must describe a log concept that entails a description of log levels, log file retention times, log file access restrictions and access procedures. The data protection office contributes to the log concept by ensuring that data protection policies are respected.

During the setup phase, the security concepts are implemented, the corresponding adminis-trator roles are created (also see secure operations track Administration Concept).

See also:

SAP Training: ADM960 - Security in SAP System Environment

SAP Help Portal: SAP Solution Manager System Management

Network

SAP Help Portal: Network and Communication Security

SAP Help Portal: Security Guide RFC / ICF (explains the security aspects that apply to the Internet Communication Framework (ICF) and when using Remote Function Calls (RFC) on the SAP Web Application Server’s ABAP Engine)

SAP Help Portal: Security Settings in the SAP Gateway (explains the security settings for the SAP Gateway, which is used for communication between SAP systems and non-SAP systems, including access control and authorizations)

SAP Help Portal: Security Guide ALE (explains the security aspects that apply when using Application Link Enabling (ALE), which uses RFC technology, to connect multiple SAP systems)

SAP Help Portal: Security Guide Communication Interfaces (provides information on the security aspects of the Integrated Communication Interface (ICI), specifi-cally the relevant security settings required for the Business Communication Bro-ker (BCB) which is part of the ICI)

SAP Help Portal: Security Guide for Connectivity with the J2EE Engine (explains the security aspects involved when using the connectivity technologies with the SAP J2EE Engine, which include security when using the J2EE Connector Archi-tecture (JCA) or the Remote Method Invocation (RMI) and P4 protocols)

SAP Help Portal: Security Aspects for the SAP Web Dispatcher


Page 43 of 59

http://help.sap.com/saphelp_sm40/helpdata/en/25/d6fdbd043441bf8246473b60e9b1d9/frameset.htm


http://help.sap.com/saphelp_smehp1/helpdata/en/f7/edd478213449dba4e49ad601966aab/frameset.htm


http://help.sap.com/saphelp_nw70ehp1/helpdata/en/37/1a9b6a338cca448508f3a48d2d1e2d/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/48/b2096e7895307be10000000a42189b/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/f4/0ea213f35b11d3a6510000e835363f/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/b3/17d13fa69a4921e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/b3/17d13fa69a4921e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/48/9ab29948c673e8e10000000a42189b/content.htm


SAProuter

o SAP Help Portal: SAProuter

SAP Web dispatcher

o SAP Help Portal: SAP Web dispatcher

o SAP Help Portal: Configuring the SAP Web Dispatcher to Support SSL

o SAP Help Portal: Security Information SAP Web Dispatcher

Transport-level security

o SAP Help Portal: Network and Communication Security

o SAP Help Portal: Using the Secure Sockets Layer Protocol with the AS ABAP

o SAP Help Portal: Configuring the Use of SSL on the J2EE Engine

o SAP Help Portal: Configuring SNC on AS ABAP

o SAP Help Portal: Configuring SNC: AS Java AS ABAP

o SAP Help Portal: Configuring the Communication Partners to Use SNC

● Operating System

o SAP Help Portal: Security Guides for the Operating System and Database Platforms

o SAP Service Marketplace: SAP Security under Windows

o SAP Service Marketplace: SAP Security under UNIX/Linux

● Database

o SAP Service Marketplace: SAP NetWeaver 7.0 DB and OS Platform Security Guides

o SAP Help Portal: Database Access Protection – General Recommendations

● Workstation

o SAP Service Marketplace: SAP GUI Scripting Security Guide

o SAP Help Portal: Configuring SNC: SAP GUI AS ABAP

External links:

● US Department of Homeland Security / US-CERT: Securing Your Web Browser


Page 44 of 59

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/4f/992ce8446d11d189700000e8322d00/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/48/8fe37933114e6fe10000000a421937/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/39/09a63d7af20450e10000000a114084/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/48/9ab29948c673e8e10000000a42189b/frameset.htm


http://help.sap.com/saphelp_nw70ehp1/helpdata/en/3a/7cddde33ff05cae10000000a128c20/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/3a/7cddde33ff05cae10000000a128c20/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/f1/2de3be0382df45a398d3f9fb86a36a/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/0d/482bb8013243f1b6e2439091e3022f/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/c3/d2281db19ec347a2365fba6ab3b22b/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/30/6cada0c97a4777a576d6a9b1a8537b/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/68/e927630904c745b1ce486d7c4e13d3/frameset.htm

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/68/e927630904c745b1ce486d7c4e13d3/frameset.htm





http://help.sap.com/saphelp_nw70ehp1/helpdata/en/f1/5bec394543351ce10000000a11402f/frameset.htm


http://help.sap.com/saphelp_nw70ehp1/helpdata/en/7e/6ca46b1ee4468a98280ff00db4d97d/frameset.htm

http://www.us-cert.gov/reading_room/securing_browser/


4.3.5 Software Lifecycle Security

4.3.5.1 Secure Application Lifecycle

The secure operations track Secure Application Lifecycle addresses security aspects of the entire solution lifecycle, i.e. from development to deployment until the final disposal. Its proc-esses ensure that only robust and secure software is used in productive operation.

The following types of software are distinguished throughout this section:

● Standard software from SAP and other software vendors.

● Custom code that extends and adopts standard software to individual needs and which is developed by

o internal development organizations or

o outsourcing service providers (see also secure operations track Outsourcing)

Operations activities

Reoccurring operation activities for deployed SAP solutions can be distinguished into (a) maintenance of the system landscape, (b) maintenance of standard software components, (c) maintenance of custom code and (d) periodic review, test and training activities. All activities follow documented concepts and processes that need to be developed during the Run SAP phases design and setup.

a) System landscape maintenance

The initial system landscape that was created during the setup phase is not fixed but subject to constant changes: New application servers are installed; existing ones change their role or are disposed.

Besides configuration and infrastructure aspects, which are addressed in other secure opera-tions tracks, system landscape changes also need to be reflected in deployment and patch management processes, which rely on the Transport Management System (TMS) and the Software Deployment Manager (SDM).

For companies that have their own development organization and develop in Java, the SAP NetWeaver Development Infrastructure (DI) for Java need to be maintained properly, includ-ing the Design Time Repository (DTR) for development resources and the SAP NetWeaver Developer Studio on the individual developer workstations.

Upon removal of application servers or entire solutions, the system administrator must ensure that sensitive business and configuration data being stored in databases or the file system is made inaccessible.


Page 45 of 59

http://help.sap.com/saphelp_nw70/helpdata/en/14/94fc3f8fc2c542e10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/EN/22/a7663bb3808c1fe10000000a114084/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/en/b0/ee3441d95dd92be10000000a1550b0/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/en/75/2475280e8df94997fec921dd271439/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/EN/3c/35c77e3ba72e46b3beae23b37856f1/frameset.htm


b) Standard software component maintenance

The maintenance of software components comprises the installation of support packages and patches. In that context, system administrators must perform the following activities:

● Inform themselves about relevant updates and notes. A list of security relevant notes for SAP software can be accessed via the Service Marketplace.

● Download new software packages from a trusted source and verify their authenticity and integrity.

● Test potential impact of software packages on dedicated test systems prior to install-ing them on productive systems. Such tests must comprise functional regression tests as well as non-functional tests that analyze (1) changes to the application’s au-thorization or security concept, (2) potential damage of existing application data, and (3) the impact on process performance.

The update can be installed on the productive system only upon successful completion of all tests.

c) Custom code maintenance

In case of updates to custom code, which usually implies having access to development documentation and source code, additional tests can be performed. In case of significant changes to custom code, such tests can include (1) design and code reviews, (2) the usage of static source code analysis tools that have more functionality than built-in tools and require expert knowledge or (3) dynamic testing approaches.

d) Periodic review, test and training activities

The security administrator must review change protocols and verify – e.g. with help of check-lists – the correctness of the development infrastructure, including source code repositories, security test tools and communication settings.

The security analyst performs manual security assessments of business solutions or the de-velopment infrastructure, according to a defined security test concept (for example with help of semi-automated vulnerability scanners or by means of penetration tests).

Regular trainings and awareness campaigns must raise the attention and knowledge of de-velopers with regard to secure development techniques.


The above-mentioned maintenance operations require the following preparation during the Run SAP design phase:

a) Definition of security requirements for custom code (with regard to, for instance, log-ging, authorization and authentication concepts, or support of security related stan-dards).


Page 46 of 59

https://service.sap.com/securitynotes


b) Security requirements for outsourced development activities need to be detailed in contractual agreements (including the provision of architecture or design documents and source code).

c) IT and security management elaborate a system architecture and a related change management concept that results in a consistent, reliable and secure productive sys-tem:

Definition of an appropriate system architecture, such as the common three-tier system landscape for SAP systems, consisting of dedicated systems for devel-opment, quality assurance, and production. On that basis, transport groups and transport routes for source code are defined. For AS ABAP, a quality assurance process can be defined as part of the transport route definition.

Definition of processes and documentation requirements for changes of the exist-ing system landscape, including the addition or removal of hardware and soft-ware components.

Definition of review processes, their schedules and responsible roles for review activities for the technical system landscape.

Definition of administrator roles for all systems, including roles for the secured access to archives and backups of deactivated systems.

d) Test and security management define a security test and review concept that covers the following aspects:

Definition of test processes for support packages, patches and hot fixes for stan-dard software, including functional tests and reviews for authorization changes.

Definition of acceptance test processes for outsourced development activities. Definition of quality metrics and their influence on the acceptance approval. Dif-ferences with regard to the availability of source code as well as specification, design and architecture documents need to be considered.

Definition of tester roles for development and quality assurance systems.

Selection of dedicated security test tools to be used in addition to built-in func-tions of AS ABAP (i.e. Code Inspector) and the SAP NetWeaver Developer Stu-dio (JLin).

Preparation of documents that regulate (a) the usage of test tools that are sub-ject to official regulations (such as the EU Cyber Crime Convention or §202c of the German StGB) and for which detailed usage scenarios must be created and approved by security management and (b) the disclosure of security vulnerabili-ties discovered during testing activities, for example by means of non-disclose agreements (NDA) to be signed by the relevant personnel.


Page 47 of 59

http://help.sap.com/saphelp_nw70/helpdata/en/9c/a544c6c57111d2b438006094b9ea64/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/en/9c/a544c6c57111d2b438006094b9ea64/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/en/56/fd3b87d203064aa925256ff88d931b/frameset.htm

http://help.sap.com/saphelp_nw70/helpdata/EN/f7/3d9d3c838436428a154abc3816fd9c/frameset.htm


e) If your organization has a separate development group, IT Management needs to in-clude security aspects into the organization’s development infrastructure and proc-ess:

Security management must define security requirements with regard to the de-velopment infrastructure, e.g. the SAP NetWeaver Development Infrastructure (DI).

Define security related activities for each lifecycle phase, e.g. the specification of security requirements, threat modeling, design or code reviews and tests. Define quality metrics that must be met in order to pass the respective quality gates.

Define a dedicated test concept for in-house developments (hereby re-using elements of the previously discussed test concept, see item c).

Define developer, tester, and administrator roles for all development systems.

Define the duties and activities of security responsibles in the development group, who ensure that defined processes and guidelines are followed.

After the design phase, the following activities must be performed during the setup phase:

a) Setup of the SAP system landscape

The system landscape setup covers the software installation on a given infrastruc-ture, including operating system, network and database as well as the modification of the default configuration. For this, please take a look at the secure operations tracks “Infrastructure” and “Secure Configuration”.

With regard to the distribution of configuration and code changes on AS ABAP, the Transport Management System (TMS) must be set up, hereby following the SAP NetWeaver Application Server ABAP Security Guide, chapter 4. Example controls are the protection of the OS directories used by the TMS or the protection of RFC connections by means of TMS Trusted Services or SNC.

For AS Java, the client and server components of the Software Deployment Manager (SDM) need to be set up, hereby following the SAP NetWeaver Application Server Java Security Guide, chapter 8.4.

b) If your organization has a separate development group, the development infrastruc-ture for the relevant SAP NetWeaver technology stacks need to be setup, including:

The development systems and infrastructure itself, hereby following the SAP Se-curity Guide Security Aspects for Development Technologies. This includes, for instance, the protection of the Design Time Repository or the encryption of com-munication channels between involved components. With regard to secure code, Code Inspector and Checkman must be configured and activated in order to ver-ify ABAP source code. For the SAP NetWeaver Developer Studio, SAP offers a series of JLin security test cases.

The installation of additional security test tools (vulnerability scanners, penetra-tion testing tools etc.) hereby ensuring that access to such tools is restricted to


Page 48 of 59

https://service.sap.com/%7Esapidb/011000358700007280532005E/





http://help.sap.com/saphelp_nw2004s/helpdata/en/56/fd3b87d203064aa925256ff88d931b/frameset.htm

http://help.sap.com/saphelp_nw2004s/helpdata/en/f7/3d9d3c838436428a154abc3816fd9c/frameset.htm


authorized personnel only in compliance to official and internal regulations as de-fined by security management in the design phase.

The setup of a test management tool that helps planning and documenting test activities during operations (e.g. SAP Solution Manager Test Management).

Setup and assignment of identified developer, tester and administrator roles, hereby ensuring segregation of duties.

Development of secure programming guidelines to be rolled-out to the develop-ment organization (also see Secure Programming guideline from SAP). The guideline must address common security bugs such as hard-coded passwords, plain-text transmission of passwords, missing input validation or output encoding etc.

c) Detailing the test and review concepts that have been defined before. This includes the creation of (1) functional test-cases for regression tests and (2) non-functional tests.

See also:

● SAP Support Portal: SAP Standard Change Management (describes the processes for managing software and configuration changes without disrupting the ongoing business)

● SAP Support Portal: SAP Standard Test Management (provides SAP’s best-practice approach for End-to-End (E2E) Test Management)

● SAP Support Portal: SAP Standard Solution Documentation for Custom Develop-ment (describes the content of the required documentation for custom development as well as tools and formats to be used for its delivery)

● SAP Support Portal: SAP Solution Manager Maintenance Optimizer (leads you through the planning, download and implementation of support package stacks)

● SAP Help Portal: Change and Transport System

● SAP Training: Curriculum: Cross Component Role: General Administration

● SAP Training: Curriculum: SAP Testing Tools

● SAP Service Marketplace: SAP NetWeaver Application Server ABAP Security Guide

● SAP Help Portal: Security of the SAP NetWeaver Development Infrastructure

● SAP Developer Network: Secure Programming (information about developing secure applications)

● SAP Support Portal: SAP Software Distribution Center

● SAP Note 927974: SAP Original Software - SHA checksum test

● SAP Support Portal: SAP Installations & Upgrades

● SAP Support Portal: SAP Support Packages and Patches and Schedules for Support Packages


Page 49 of 59

http://help.sap.com/saphelp_smehp1/helpdata/en/2e/e7769b243b4d0993429c71996f985e/frameset.htm

https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/334929d6-0a01-0010-45a9-8015f3951d1a





http://service.sap.com/%7Eform/sapnet?_SHORTKEY=01100035870000689446&_SCENARIO=01100035870000000202&

http://help.sap.com/saphelp_nw70/helpdata/en/14/94fc3f8fc2c542e10000000a1550b0/frameset.htm

http://www.sap.com/services/education/catalog/netweaver/curriculum.epx?context=%5b%5bADM_CTSADMIN%5d%5d%7c

http://www.sap.com/services/education/catalog/curriculum.epx?context=%5b%5bADM_TEST%5d%5d%7c


http://help.sap.com/saphelp_nw70/helpdata/en/3b/ca7d706cc84304ac1a52f7956e80b7/frameset.htm

https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/334929d6-0a01-0010-45a9-8015f3951d1a

https://service.sap.com/swdc

https://service.sap.com/sap/support/notes/927974

http://service.sap.com/instguides

http://service.sap.com/patches

http://service.sap.com/ocs-schedules

http://service.sap.com/ocs-schedules


● SAP Support Portal: SAP Security Notes, SAP Notes Search and Note Assistant (in-stalls specific corrections to SAP solutions; recognizes dependencies on SAP Notes, Support Packages, and already implemented modifications)

● SAP Note 875986: Note Assistant: Important notes

External links:

● BSI IT-Gundschutz Catalogues 2008: M 4.272 Sichere Nutzung des SAP Transport-systems (German)

● BSI IT-Gundschutz Catalogues 2008: M 4.273 Sichere Nutzung der SAP Java-Stack Software-Verteilung (German)

● BSI IT-Gundschutz Catalogues 2008: M 2.349 Sicherheit bei der Software-Entwicklung für SAP Systeme (German)

● US Department of Homeland Security: Security Testing

4.3.5.2 Secure Configuration

Secure configuration of systems is mandatory in productive operations. Caused by the invisi-bility of configuration impact, an appropriate testing process and permanent monitoring is required to ensure a stable system environment, secure processes and an important basis for other business and security related processes.

As such, secure configuration addresses the maintenance of configuration settings in terms of change management and review processes. It ensures that a secure configuration that was created during the setup phase remains secure over time.

This track does not describe detailed configuration settings for individual software compo-nents; please refer to other secure operations tracks for that purpose and to the SAP Security Guidelines.


During operations, the following activities need to be performed:

● System and application administrators maintain configuration settings, hereby follow-ing configuration guidelines and a defined change management process. Such proc-esses are described in the Service Operations book of the IT Infrastructure Library V3 (ITIL). Change Management in the SAP Solution Manager is aligned to these ITIL processes and allows performing changes economically, quickly, and with minimum risk.

With regard to security settings, the change management process must comprise a change and impact description, explicit approvals for critical settings, peer reviewing as well as functional and non-functional tests on dedicated quality assurance sys-tems before the changed configuration is applied to the productive system.


Page 50 of 59

http://service.sap.com/securitynotes

http://service.sap.com/notes

http://service.sap.com/noteassistant

https://service.sap.com/sap/support/notes/875986







https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/testing.html





Depending on the impact and scale of a given configuration change, security analysts may perform an in-depth analysis of the newly configured system.

● Security administrators must periodically review security relevant configuration set-tings of all systems and installed software components.

To that regard, SAP offers security guides for each software solution, providing de-tailed information about a secure solution configuration, default settings, authoriza-tions etc. These guidelines can be found on the SAP Service Marketplace.

Theoretically, dedicated tools on SAP NetWeaver AS Java and AS ABAP (e.g. the Visual Administrator or NetWeaver Administrator) can be used to check the settings of each individual system. However, the complexity of today’s system landscape, the spreading of configuration data, and the required manual effort ask for tool support. To that regard, SAP Solution Manager offers the following functions to facilitate the review of configuration settings:

o The Configuration Validation functionality of the SAP Solution Manager Change Management allows to compare a given system configuration with a reference system (real or virtual), that was defined by security administrators and which has a secure reference configuration. Deviations from the refer-ence system indicate insecure configuration settings which need to be ana-lyzed in more detail.

o The Security Optimization Service (SOS) is available as a SAP Solution Manager self-service and verifies a broad range of security settings for SAP NetWeaver AS ABAP, ranging from authorizations for basis transactions to RFC connections. The SOS self-service should be executed on a regular ba-sis. Selected checks of the Security Optimization Service have also been in-tegrated into the Early Watch Alert (EWA).

Additional checks for SAP NetWeaver AS Java, SAProuter, SAP Internet Transaction Server (ITS) and SAP Business Connector (BC) are available as part of the SOS remote-service, which is delivered by a consultant of SAP support via a remote network connection.

● Security administrators must analyze the security impact of new support packages and patches: Are there new security relevant features, which have been shipped and installed with a support package, that require a change of default values for new con-figuration parameters or the adoption of existing configuration settings?

● Internal Auditors perform periodic audits of the configuration settings and change logs in compliance to the review process, described by IT management.


As a pre-requisite for above mentioned activities, IT management must identify security re-quirements for change management processes in the design phase (see also Run SAP Standard Change Management), hereby anticipating security guidelines (e.g. BSI IT-


Page 51 of 59




http://service.sap.com/ewa



Grundschutz Catalogues safeguard S 4.78, careful modification of configurations, or safe-guard S 2.34, documentation of changes). A corresponding concept needs to be created and implemented in the setup phase, if possible with help of SAP Solution Manager Change Re-quest Management or another appropriate workflow tool. If parts of the system maintenance are outsourced, process requirements and related controls need to be regulated in the ser-vice contract.

IT Management defines the guidelines for secure configuration settings (e.g. recommenda-tions about restrictive activations of automated software activities or session timeouts for users, technical connections, and a blacklist of known configuration settings with vulnerabili-ties, including recommended solutions).

Application administrators must define a test concept that allows the verification of configura-tion changes on test systems, hereby identifying all business processes that need to be sub-ject to regression tests after given system changes. The test concept is refined during the setup phase in terms of concrete test cases, a test management system and the creation of tester roles.

Security administrators must define a review concept that determines the periodicity, scope and responsibility for configuration reviews. Violations to the above-mentioned configuration guidelines can partially be detected with the Security Optimization Service.

IT and security management define the review process for periodic internal audits of the con-figuration settings and change logs according to the guidelines for secure configuration set-tings.

See also:

● SAP Help Portal: Change Management of SAP Solution Manager

● E2E Solution Operations Standard Change Management: Describe the processes for managing software and configuration changes without disrupting the ongoing busi-ness.

● E2E Solution Operations Standard Test Management: Provides SAP’s best-practice approach for End-to-End (E2E) Test Management.

● SAP Service Marketplace: SAP Security Guides

● SAP Training: Curriculum: SAP Solution Manager - Implementation and Operations

● SAP Support Portal: Security Optimization Service

● SAP Support Portal: SAP Standard for System Administration

External information:

● IT Infrastructure Library (ITIL)

● BSI IT-Gundschutz Catalogues 2005: M 2.221, Change Management

● US Department of Homeland Security: Security Testing


Page 52 of 59







http://www.sap.com/services/education/catalog/curriculum.epx?context=%5b%5bSM_IMPLEM%5d%5d%7c



http://www.itil.org/


https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/testing.html


4.3.5.3 Secure Support

Secure Support Operations comprise activities that ensure secure incident processing with regard to internal help desks or external help desks, such as SAP Active Global Support. It deals with topics such as remote service connections or user and authorization management of user accounts created for support consultants.


The incident management processes involves the following actors: The end user who experi-ences an incident on a given SAP system and creates a corresponding incident message, the customer’s internal help desk personnel, the personnel of a potential external service pro-vider help desk and SAP’s help desk personnel.

Security relevant activities during operations are performed mainly by the customer’s internal help desk personnel, which represent the interface to external parties, and comprise the fol-lowing:

● If an incident cannot be solved by the customer’s internal help desk, a help desk em-ployee forwards a given incident message to external service providers. Hereby, the internal help desk employees must ensure that messages with confidential data, be it as part of the problem description or as attachment, do not leave the company. Mes-sages concerning potential security weaknesses can also be sent encrypted to SAP via the security response process ([email protected]). This channel is also available to non-SAP customers, like independent security researchers.

● If the incident resolution requires a remote connection by an external support con-sultant, the internal help desk employee needs to perform several tasks: (1) He iden-tifies a dedicated support user account with sufficient authorizations to investigate the problem. Afterwards, he (2) activates the support user account (e.g. by unlocking it and creating or generating new credentials with a certain complexity) and (3) di-vulges the account details to the external support consultant by putting them into a secure area (but not in the message text). (4) After the incident resolution, the ac-count must be locked again.

● In order to allow remote logon to external support consultants, the help desk em-ployee must open service connections. The validity period of these connections must be determined together with the external consultant.

● In cases where direct system access shall not be given to external support consult-ants, the incident reproduction must happen on dedicated test systems. In that case, the application administrator ensures that a given incident can be reproduced on such systems, for instance by generating appropriate test data.

On top of these activities that all occur during the actual incident handling process, additional maintenance and review activities need to be performed:

● Security and applications administrators must periodically review technical logs and business related logs respectively, both being created during remote service connec-tions.


Page 53 of 59

mailto:[email protected]


● The security administrator maintains and updates dedicated support user accounts to reflect changes in the application and solution landscape, eventually supported by application administrators.


Prerequisite activities performed during the security process phases design and setup are needed to ensure a secure operation of the internal help desk.

During the design phase, the process owner and the security management define security requirements with regard to internal and external help desks. Requirements concern the fol-lowing topics and overlap with what has been discussed in the secure operations track Out-sourcing:

● The remote network connections (e.g. leased line, Internet) and service connections with regard to encryption, its modus operandi (e.g. 4 eyes principle with help of Net-Viewer) and the opening procedure.

● Service Level Agreements (SLA), e.g. the availability of the help desk (24x7), initial reaction times and maximum processing times.

● Policies, e.g. regarding the storage of customer data by support personnel.

Also during the design phase, the process owners and the security administrators develop an activity log concept that clarifies which activities of external support personnel must be logged.

During the setup phase:

● System administrators set-up the previously defined remote connections, hereby configuring, for instance, the SAProuter and its password.

● Security administrators define and create special roles that are suitable to analyze incidents for different applications and components. Those roles are assigned to dedicated support user accounts which will be used by support consultant during the operations phase.

The authorizations of such accounts must follow the least privilege principle. One ex-ample for authorizations that should be assigned carefully on productive systems, are debug authorizations, especially including the possibility to change variables in a de-bug session. In general, the creation of such accounts should follow the guidelines explained in the secure operations track User and Authorization Management.

● System administrators set up the logging facilities according to the activity log con-cept.

● Security administrators create message handling guidelines for employees and es-pecially the internal help desk personnel.

● Authorization administrators provide end users and internal help desk employees all necessary authorizations to access the internal and any external ticket management system.


Page 54 of 59


BusinessObjects Access Control Superuser Privilege Management can facilitate the design of support user accounts as well as the logging of their activities.

See also:

● SAP Support Portal: Remote Connections to SAP Support

● SAP Support Portal: Available Connection Types

● SAP Support Portal: Netviewer (provides application sharing methods for support session with higher security requirements)

● SAP Note 33953: Network providers for connection to SAPNet R/3 Front-end

● SAP Corporate website: BusinessObjects Access Control Superuser Privilege Man-agement

● SAP Corporate website: Report a security vulnerability

● E2E Solution Operations Standard System Monitoring

● SAP Help Portal: SAP Solution Manager and SAP Solution Manager Service Desk

● E2E Solution Operations Standard Incident Management: Defines the process and tool to manage the required collaboration between the involved parties to resolve in-cidents in a timely manner.

● E2E Solution Operations Standard Remote Supportability: Details the architecture for remote support and the process for integrating customer solutions with the SAP Ser-vice Backbone. In addition, it describes how to set up remote supportability for SAP solutions and how to set up a remote connection to SAP Solution Manager.

External links:

● BSI: Sicherheitseigenschaften von Standleitungstechnologien (German) (explains security properties of different network connection types)


Page 55 of 59

https://websmp108.sap-ag.de/%7Eform/sapnet?_SHORTKEY=01100035870000043547&_SCENARIO=01100035870000000202&


http://service.sap.com/netviewer

https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=33953&nlang=E&smpsrv=https%3a%2f%2fwebsmp108%2esap-ag%2ede



http://www.sap.com/security


http://help.sap.com/saphelp_sm40/helpdata/en/45/51fbdbd4941803e10000000a1553f7/frameset.htm

http://help.sap.com/saphelp_sm40/helpdata/en/ff/6ea7a870ac469ea54cedd12666cc5d/frameset.htm

https://websmp207.sap-ag.de/%7Esapdownload/011000358700000336602007E/Incident_Management_10.pdf


http://www.bsi.de/gshb/deutsch/hilfmi/doku/sicherheit_standleitungen.pdf


5 How to measure the success of the implementation This section introduces a series of general criteria that allow organizations to assess and improve the quality or maturity of information security management systems (ISMS) as well as single secure operations tracks as they are used in the E2E Solution Operations Standard Security.

Depending on individual needs and requirements, one should define a set of objectives for each of the 10 security tracks to which the actual situation can be compared to. To that re-gard, each of the 10 security tracks can rightfully have a different set of objectives.

It shall be noted that these criteria (e.g. the formal description of change management work-flows or the existence and publishing of a company-wide security policy) are only enablers; their effectiveness need to be continuously assessed during operations.

The different criteria can be categorized as follows:

a) Process criteria: Concern the quality and type of security related workflows within the company.

b) Organizational criteria: Indicate the commitment and support of security by top-level management

c) Tool criteria: Describe the quality and extent of tool support

d) Measurement and improvement criteria: Describe feedback and improvement cycles

a) Process criteria

A first distinction concerns the availability or non-availability of pre-defined security workflows: Without such workflows, security related activities are performed on an ad-hoc basis, i.e. without a clear concept and procedure description. In such cases, the same type of security incident may result in entirely different mitigations. On the other side, having pre-defined processes for specific incidents results in effective, reliable and controllable mitigation activi-ties that are always performed in the same manner, regardless who actually executes the workflow.

Another quality criterion concerns the motivation of security related activities: In less mature organizations, activities are only performed on immediate need, e.g. in case of an actual se-curity breach, an external audit to be performed or the availability of a new support package to be imported. In such companies, security related activities are primarily reactive or event-driven. More mature companies operate proactively, i.e. they continuously prepare for and plan security activities, without an immediate need but with a planned and controlled sched-ule, e.g. in terms of review processes and internal audits that help verifying the compliance of the company’s security implementation with internal and external requirements.

Also, the documentation of activities is important: More advanced security implementations ensure a comprehensive documentation of security activities, ideally made available through a central information repository that also provides access to all relevant security concepts and, for instance, a full description of the IT infrastructure.


Page 56 of 59


Finally, the coverage of security topics can indicate the security level: More mature compa-nies define security workflows (i.e. maintenance and review processes) for all or most of the secure operations tracks whereas others only describe the most central ones, such as user provisioning.

b) Organizational criteria

In order to build and maintain an effective security process, some organizational measures must be taken:

The existence of a company-wide security policy ensures that top-level management is committed to the objectives, value, scope, and direction of all security activities performed within the company. This policy should be made available to all employees, e.g. by publica-tion on the company internal portal.

In less mature organizations, such a security policy is not available nor a dedicated budget or personnel for the execution of security activities exist. In such cases, security activities are performed by other administrative personnel (e.g. system administrators), which can eventu-ally cause segregation of duties (SoD) conflicts. In more advanced organization, a dedicated budget and personnel exists, either for selected or all security areas.

Another maturity indicator is the existence and periodicity of any communication that helps increasing the personnel’s awareness of security, e.g. awareness campaigns or training ac-tivities.

c) Tool criteria

Other qualitative criteria concern the support of security activities by dedicated tools. Tool support includes workflow systems that enforce and document security workflows during operations. In less mature organizations, workflows may exist on paper but their compliant execution is not enforced. In that context, SAP Solution Manager Change Request Manage-ment and Change Control can provide significant support during operations time.

Other tools concern the monitoring and review of security related information, either in real or near-time, such as Intrusion Detection Systems (IDS) or on periodic bases, such as the SAP Security Optimization Service for the verification of configuration and authorization settings. Incidents detected by monitoring and review tools must trigger respective workflows.

d) Measurement and improvement criteria

Mature organizations ensure not only appropriate budget, personnel, and tool support for pre-defined maintenance and review processes, but also improve the effectiveness and efficiency of the security program in a systematic way.

The improvement of existing processes can be based on KPIs: Their continuous measure-ment and periodic evaluation results in a steady optimization of implemented processes, without the need to iterate the Run SAP phases Design and Setup.


Page 57 of 59

http://help.sap.com/saphelp_smehp1/helpdata/en/2b/614e1cb8204f35b477eac703073589/frameset.htm

http://help.sap.com/saphelp_smehp1/helpdata/en/2b/614e1cb8204f35b477eac703073589/frameset.htm

https://service.sap.com/sos


Bigger optimizations after go-live concern substantial changes to the company's security concept, which require the iteration of all Run SAP phases for the given secure operations track, from Scoping to Hand-over to Production. Such changes improve the company's stan-dard security level by introducing qualitative measures, e.g. the tool support of security proc-esses.

An organization’s maturity depends on the extent and systematic approach with which such optimizations are performed during the Run SAP phase Operations & Optimization.


Page 58 of 59


Copyright 2009 SAP AG. All Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein

may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, SAP Business ByDesign, ByDesign, Part-nerEdge and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned and associated

logos displayed are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. This document is a preliminary ver-sion and not subject to your license agreement or any other agreement with SAP.

This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular

course of business, product strategy, and/or development.

SAP assumes no responsibility for errors or omissions in this document. SAP does not war-rant the accuracy or completeness of the information, text, graphics, links, or other items

contained within this material. This document is provided without a warranty of any kind, ei-ther express or implied, including but not limited to the implied warranties of merchantability,

fitness for a particular purpose, or non-infringement.

SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

This limitation shall not apply in cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any

warranty whatsoever relating to third-party Web pages.


Page 59 of 59