SAP Standard For Security-Active Global Support - Whitepaper PDF

Version: 1.
0
June 2009
SAP Standard for Security
Whitepaper
Active Global Support

SAP AG
2009 SAP AG SAP Standard for Security Page 1 of 59

Version: 1.0
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

Version: 1.0
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.

Version: 1.0
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
Version: 1.0
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

Version: 1.0
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.

Version: 1.0
3 Security Standard at a Glance

The Security Standard aims to protect the companys 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 & Handover into Pro-

Design Setup Operations &
Scoping duction
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-
panys 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 Network 1 .
1
https://www.sdn.sap.com/irj/sdn/security
Version: 1.0
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 companys 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

Version: 1.0
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
companys 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 companys 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 companys 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.

Version: 1.0
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
Version: 1.0
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 companys 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 companys security policy and ensure that the correct implementation of security

Version: 1.0
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 companys 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 companys 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 companys 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 roles 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
Technical System Administrator Maintains technical systems, defines backup

and recovery concept, performs emergency
response process
Network Administrator Network segmentation, firewall configuration,

communication channel encryption

Version: 1.0
Application Manage- Policy definition on application level, defini-

Technical
ment tion of security requirements
Database Administra- Configuration of database, implementing

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

velopments
Internal Help Desk Management of support connections, han-

Personnel dling/forwarding of incidents, incident repro-
duction on test systems
Security Team Security Administrator Defines alerting and emergency response

(technical and op- concept
erational)
Authorization Adminis- Creates and manages roles
trator
User Administrator Creates and manages user, performs risk

analysis of user authorization assignment,
ensures user appropriate provisioning and
de-provisioning of roles
Security Team Security Management Policy definition, approval and publication,

(legal and technical requirements definition, selection and as-
assessment) 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 Analyst In-depth security assessments
External Auditor Independent inspection of the internal secu-

rity compliance

Version: 1.0
Business Process Owner Identify and document process specific risks,

(planning of proc- process monitoring, conflict resolution, role
esses) design (SoD)
Business Manage-
ment (responsibility)
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)
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
Version: 1.0
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.

Version: 1.0
(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.

Version: 1.0
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 Regelmige Sicherheitsprfungen
fr 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.

Version: 1.0
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 providers personnel, it should be distinguished whether the iden-
tity of the service providers 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.

Version: 1.0
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.
Version: 1.0
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 companys 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.
Version: 1.0
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 companys 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).

Version: 1.0
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.

Version: 1.0
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 fr 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

Version: 1.0
(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 PKIs 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.

Version: 1.0
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 companys 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.

Version: 1.0
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).

Version: 1.0
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.

Version: 1.0
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:

Version: 1.0
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 whichs 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 companys 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 companys
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
Version: 1.0
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.

Version: 1.0
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-
tors, 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.

Version: 1.0
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-
Version: 1.0
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

Version: 1.0
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

Version: 1.0
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
Configuration
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-

Version: 1.0
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.

Version: 1.0
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.

Version: 1.0
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)
Version: 1.0
SAP BusinessObjects Access Control

Configuration
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):
Version: 1.0
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 SAPs database abstraction layer and authorization concept. The
latter would be jeopardized, if database users directly access DB tables with busi-

Version: 1.0
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).

Version: 1.0
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)

Version: 1.0
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 Servers 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

Version: 1.0
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

Version: 1.0
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.

Version: 1.0
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 applications 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).

Version: 1.0
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.

Version: 1.0
e) If your organization has a separate development group, IT Management needs to in-

clude security aspects into the organizations 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
Version: 1.0
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 SAPs 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

Version: 1.0
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 fr 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.

Version: 1.0
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 todays 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-

Version: 1.0
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 SAPs 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

Version: 1.0
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
customers internal help desk personnel, the personnel of a potential external service pro-
vider help desk and SAPs help desk personnel.
Security relevant activities during operations are performed mainly by the customers internal
help desk personnel, which represent the interface to external parties, and comprise the fol-
lowing:
If an incident cannot be solved by the customers 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 (secure@sap.com). 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.

Version: 1.0
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.

Version: 1.0
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)

Version: 1.0
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 companys 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.

Version: 1.0
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 personnels 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.

Version: 1.0
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 organizations maturity depends on the extent and systematic approach with which such
optimizations are performed during the Run SAP phase Operations & Optimization.

Version: 1.0
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.

Version: 1.0

SAP Standard For Security-Active Global Support - Whitepaper PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SAP Standard For Security-Active Global Support - Whitepaper PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Version: 1.

SAP Standard for Security

Active Global Support

2009 SAP AG SAP Standard for Security Page 1 of 59

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.3.1.1 Audit ................................................................................................................14

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

4.3.1.3 Emergency Concept ........................................................................................20

4.3.2.1 Secure process and people collaboration .......................................................23

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

4.3.3.2 Administration Concept ...................................................................................35

4.3.4.1 Network, System, Database and Workstation Security ...................................39

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 Page 2 of 59

2009 SAP AG SAP Standard for Security Page 3 of 59

2 SAP Standards for E2E Solution Operations

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

SAP provides the following standards for solution operations:

2009 SAP AG SAP Standard for Security Page 5 of 59

2009 SAP AG SAP Standard for Security Page 6 of 59

3 Security Standard at a Glance

Assessment & Handover into Pro-

Design activities Setup activities Operation activities

1. Audit 1. Audit 1. Audit

Figure 2 Distinction of security topics throughout all Run SAP phases

Figure 3: Secure Operations Map

2009 SAP AG SAP Standard for Security Page 8 of 59

The management commitment must entail the following aspects:

2009 SAP AG SAP Standard for Security Page 9 of 59

4 What is the basic concept of the Security Standard

4.1 Process Flow

Figure 4: The security process for all secure operations tracks

The implementation of the security concepts typically comprises:

The validation of the implementation can be performed by internal units or outsourced to

Operations & Optimization

2009 SAP AG SAP Standard for Security Page 11 of 59

4.2 People und Roles

Examples for typical activities grouped by roles:

Group Role Typical activities

Technical System Administrator Maintains technical systems, defines backup

Network Administrator Network segmentation, firewall configuration,

2009 SAP AG SAP Standard for Security Page 12 of 59

Group Role Typical activities

Application Manage- Policy definition on application level, defini-

Database Administra- Configuration of database, implementing

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

Internal Help Desk Management of support connections, han-

Security Team Security Administrator Defines alerting and emergency response

User Administrator Creates and manages user, performs risk

Security Team Security Management Policy definition, approval and publication,

Data Protection Office Identification and verification of privacy re-

Auditor, intern Verification of legal (external) or internal

Security Analyst In-depth security assessments

External Auditor Independent inspection of the internal secu-

2009 SAP AG SAP Standard for Security Page 13 of 59

Group Role Typical activities

Business Process Owner Identify and document process specific risks,