Product Security at SAP
How SAP Applies Security in Our Solutions
to Conform to ISO/IEC 27034
Table of Contents
3
Application Security Lifecycle
4
Application Security Control
5
Organization Normative Framework
8
Application Normative Framework
10 Application Security Management Process
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
11 Glossary and Abbreviations
SAP® solutions support key business processes that demand high security and
robustness, such as scalability and availability. For many years, SAP has developed
and enforced internal processes and standards to meet users’ high expectations.
The secure software development lifecycle (secure SDL) is the framework that
our development organizations use to design and build security into our products.
Primarily, this document addresses our customers
and partners looking for information on how SAP
processes support the development of secure
products in conformance with ISO/IEC 27034.
The document does not require knowledge of the
ISO/IEC 27034 standard, though it may be beneficial. The sections guide the reader through the
concepts and components of ISO/IEC 27034,
describing the requirements and how we implement them. The titles in each section correspond
to the key elements of ISO/IEC 27034. The italicized words correspond to the terms used in the
ISO/IEC 27034 standard. We focus on the essential processes controlled by SAP and what we do
to secure customer-specific solutions.
Our standard development process framework
implements a number of security policies.
It is enriched with security-specific methods
and practices comprising the secure software
development lifecycle, as well as security
requirements and controls.
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
2 / 11
Application Security Lifecycle
As per the reference model of the application
security lifecycle as defined in ISO/IEC 27034-1,1
the core processes at SAP belong to the application
provisioning and operation layer. Our emphasis is
on the provisioning stages of preparation, realiza-
tion, and transition, as well as the operation stages
of utilization and maintenance (see Figure 1). The
other layers – application management, infrastructure management, and application audit – can be
considered as supporting processes.
Figure 1: Scope of Application Security Lifecycle
Application Security Lifecycle Reference Model
Layers
Application
management
Application provisioning management
Core Processes
Outsourcing
Application
provisioning
and operation
Preparation
Development
Application operation management
Transition
Archival
Utilization
Destruction
Acquisition
Infrastructure
management
Application audit
Application provisioning infrastructure management
Application provisioning audit
Preparation
Realization
Transition
Provisioning stages
Application
operation
infrastructure
management
Disposal
Application operation audit
Utilization and
maintenance
Archival
Destruction
Operation stages
Source: ISO/IEC 27034-1:2011(E)
Note: Except for the “Core Processes” overlay, ISO/IEC is responsible for the content in this figure.
1. See also Figure 8 on page 24 of 67 (“ISO/IEC 27034-1:2011 — Information technology — Security techniques — Application
security — Overview and concepts”).
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
3 / 11
Application Security Control
THE ISO EXPECTATION:
An application security control (ASC) is a central
concept in ISO/IEC 27034 and a cornerstone
in the foundation of the secure software development lifecycle. It comprises three essential
Our implementation: At SAP, we make a distinction between two types of ASCs. The first type
relates to the qualities and functions of SAP products, such as secure data transfer and logging of
security events. One of the key differentiators of
this type is that the lifecycle of the controls follows the same lifecycle of the product to which
they belong. The other type of security control
relates to the process steps executed during the
application lifecycle, such as risk assessment.
The lifecycle of these controls is independent of
the application lifecycle.
descriptions: what should be done to meet a
certain security requirement, how this is implemented, and how to verify that the corresponding
risk is mitigated as expected.
According to the differentiation of security control types, we define the ASC libraries as follows:
•• Product standard security is a collection of
security requirements, associated security controls, and corresponding verifications. You can
consider these kinds of security controls as
intrinsic product characteristics, as they are
implementable within the product and have
the same lifecycle.
•• Secure SDL includes the other type of security
controls, which have a lifecycle independent of
the application lifecycle. See further details in the
section “Application Normative Framework.”
At SAP, we make a distinction between two
types of ASCs. The first type relates to the
qualities and functions of SAP products, and
the other type relates to the process steps
executed during the application lifecycle.
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
4 / 11
Organization Normative Framework
THE ISO EXPECTATION:
In ISO/IEC 27034, the organization normative
framework (ONF) is an organization-wide framework comprising normative processes and
elements related to application security.
Particularly, the ONF must include an ONF
committee and an ONF management process,
described in this section.
Our implementation: The normative SAP security
of roles and human resource functions. It defines
framework is based on a number of policies (see
an ISO/IEC 9001–compliant corporate requireFigure 2). Several have specific relevance to secuments framework to safeguard corporate comrity, privacy, and data protection in our products:
pliance through key responsibilities and manda•• Global security policy is binding for all compatory steps in the development process. One of
nies within SAP Group, all SAP employees, and
the mandatory corporate requirements defined
all external parties. Among the topics required
in the policy is “develop secure software.” The
are securing the entire software supply chain,
secure SDL defines and details the high-level
including the relevant suppliers, partners, and
requirement at the executable level.
service providers.
•• Global quality policy sets forth the general
•• Global development policy is an internal policy,
ISO/IEC 9001–compliant framework for SAP
mandatory for all SAP units including affiliates
products, processes, and services.
and acquired companies and binding for all kinds
Every project following the secure software
development lifecycle starts with defining the
application context. This is made up of the
target environment and specification of business
functionality.
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
5 / 11
Figure 2: Secure Software Development Framework
Global security policy
Global development policy
Global quality policy
Standard development process framework
Secure software development lifecycle
Product standard security
Methods and practices
Security requirements and controls
Our standard development process framework
implements these policies. It is enriched with
security-specific methods and practices comprising the secure SDL, as well as security requirements and controls found in our “Product Standard
Security” document.
The secure SDL represents a subset of the ONF
related to application security – that is, the best
practices and methods to be used in the process
of software development to make the process
outcomes secure.
Product standard security considers input from
various sources including:
•• Development, such as better ways to meet
a requirement that results from the evolution
of technologies
•• Customers and partners, such as for market
expectations
•• Lawyers and standards, such as changes
in the privacy regulations
•• Security researchers
Figure 3: Components of the Organization
Normative Framework
Standard development process at SAP
Business context
Process related to application security
Regulatory context
Technological context
Organization
ASC library
Product
standard
security
Application specification repository
Application lifecycle
security reference model
Roles,
responsibilities,
and qualifications
Secure software
development lifecycle
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
6 / 11
The ONF Committee
To keep the ONF up-to-date and adjustable to
the continuously changing environment, our
global security team develops, maintains, and
operationalizes secure SDL, communicates with
internal and external stakeholders, and rolls out
approved changes.
ONF Management Process
THE ISO EXPECTATION:
The ONF management process, as defined in
ISO/IEC 27034-1, is a permanent, organizationwide process that the ONF committee follows to
keep the organization normative framework up-todate and relevant to the organization context.
Our implementation: The responsibility over the
ONF components is split between three teams
(see Figure 3). A dedicated team is in charge of
the standard development process that supports
the ISO/IEC 9001–compliant quality management
system (QMS). From the QMS point of view,
security is one of many product qualities, such
as performance and accessibility.
The security specifics are handled by our global
security team, which is the owner and maintainer
of these key components:
•• Secure software development lifecycle
•• Product standard security
The permanently changing threat landscape and
the rapid evolution of the security domain require
continuous update of both components. The team
performs a formal review of the components twice
a year, based on feedback from our internal development and operation teams as well as from key
external stakeholders such as customers, partners,
and security researchers. Additional incremental
improvements are made outside of the formal revision periods, as needed – for example, to reflect
changes in the laws or technologies or changes
based on an identification of new security controls.
The lifecycle of both components is decoupled from
the lifecycle of applications. Our global security
team also rolls out the changes, such as through
trainings and consulting for the development
teams and decision makers, and provides tools
and infrastructure supporting the secure software development lifecycle.
In parallel with the application development lifecycle and activities of the global security team,
an independent team conducts internal audits to
verify the framework implementation and reports
the results to the SAP Executive Board.
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
7 / 11
Application Normative Framework
THE ISO EXPECTATION:
The international standard defines an application
normative framework (ANF) as a framework
derived from the ONF after application risk
assessment. It comprises selected processes
and elements as required in the context of a
Our implementation: The secure software development lifecycle is such a framework. It is applicable to all kinds of projects and applications at
SAP. Our project teams may further tailor it to fit
the needs of particular organizations, such as for
industry specifics. As an example, project teams
could add the industrial standards for manufacturing and banking to the tailored version of the
particular application. Similar to the ONF and
including the ONF management process, ANF
includes the application security management
process, described below, to manage security
for each application.
development lifecycle, providing a common baseline for all applications in each particular area.
Figure 4 presents the key elements of the life­
cycle as defined by SAP and the corresponding
phases of the application security lifecycle reference model (ASLCRM) from the international
standard (also see Figure 1).
Figure 4: Phases for Secure SDL and Application Security Lifecycle Reference Model
Secure software development lifecycle
Security
research
Security
training
Preparation
Security risk
assessment
Security
planning
Secure
development
Security
testing
Development
Security
validation
Transition
Security
response
Utilization
Application security lifecycle reference model
In addition to the process steps defined in
ISO/IEC 27034, SAP has a dedicated step of
security planning, which is particularly useful
for agile and iterative development processes.
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
8 / 11
Every project following the secure software development lifecycle starts with defining the application
context. This is made up of the target environment
and specification of business functionality typically
in the form of a business case with supporting
detailed documents. That serves as input for a
risk assessment, which project teams use in
specifying the applicable security requirements.
Consequently, the teams refine the project-specific
development process by selecting the specific
controls required to achieve the targeted level of
trust (see Figure 5). Some typical project-specific
decisions may be:
•• Compliance with which specific laws, regulations,
and standards is required and how to achieve it
•• Whether and which specific risk assessments
are required for particular areas of concern,
such as privacy-impact assessment to define
privacy and data-protection requirements
•• Depending on the project-specific technologies,
which static and dynamic code-analysis tools
and their configurations need to apply
Figure 5: Risk-Based Context-Sensitive Derivation of Application Project Security Plan
Global security policy
Global development policy
Global quality policy
Standard development process framework
Application context
Secure software development lifecycle
Product standard security
Methods and practices
Security requirements and controls
Application specification
Target environment
Security risk assessment
Applicable methods and practices
Applicable security requirements and controls
Application project security plan
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
9 / 11
Application Security Management Process
and application normative framework. Then
the plan and framework stay intact until the risk
assessment results are invalidated. This allows the
development organization to put more focus on
value-adding activities. As soon as the application
Compared to the reference application security
specification or target environment is changed, the
management process provided in the international project team repeats the security risk assessment
standard, the process steps have been defined by and adjusts the security plan and the ANF to reflect
SAP with a slightly different granularity. In both
the changes in the application risks as required.
cases, the steps start with specifying the business
requirements and the target environment, which Software development includes implementation
are used for the security risk assessment, defini- and testing of the planned security controls. Before
tion of security requirements, and decision on the we release software to customers, an independent
appropriate application security controls. The proj- group performs security validation. The group
ect team documents the results of these activities acts like the first customer to assess whether the
as a security plan in our terms, which corresponds software has met the market expectations for
to the application’s targeted level of trust.
security. The assessment result corresponds to
the application’s actual level of trust in terms of
In addition to the process steps defined in
ISO/IEC 27034. The independent group commuISO/IEC 27034, SAP has a dedicated step of
nicates any deviations and recommendations for
security planning, which is particularly useful for
the team to handle before the team makes the
agile and iterative development processes. Secu- release decision or as input for the next developrity planning takes the security risk assessment
ment cycle.
results as input to define the initial security plan
Figure 6 shows the structure of the secure software
development lifecycle, which is very similar to the
reference model of the application security management process defined in ISO/IEC 27034-1.
Figure 6: Secure SDL as an Application Security Management Process
Security planning
Security plan
Security risk assessment
Requirements engineering
Secure development
Security testing
Security validation report
Security validation
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
10 / 11
Glossary and Abbreviations
ANF – application normative framework
ASC – application security control
ASLCRM – application security lifecycle reference model
ASMP – application security management process
ONF – organization normative framework
PIA – privacy-impact assessment
QMS – quality management system
Secure SDL –secure software development lifecycle
Before we release software to customers,
an independent group performs security
validation. The group acts like the first
customer to assess whether the software
has met the market expectations for security.
Studio SAP | 41881enUS (16/02)
© 2016 SAP SE or an SAP affiliate company. All rights reserved.
11 / 11
© 2016 SAP SE or an SAP affiliate company. 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 SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for
additional trademark information and notices. Some software products marketed by SAP SE and its
distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,
without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable for
errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company
products and services are those that are set forth in the express warranty statements accompanying such
products and services, if any. Nothing herein should be construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality mentioned
therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy
and possible future developments, products, and/or platform directions and functionality are all subject
to change and may be changed by SAP SE or its affiliated companies at any time for any reason without
notice. The information in this document is not a commitment, promise, or legal obligation to deliver
any material, code, or functionality. All forward-looking statements are subject to various risks and
uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned
not to place undue reliance on these forward-looking statements, which speak only as of their dates, and
they should not be relied upon in making purchasing decisions.