CSAR Issue 1.0

Technical Document
PSA Cyber Security Assurance Requirements
REFERENCE IND PROJECT PAGE

C2: RESTRICTED DIFFUSION 1
02016_16_05952 1.0
159
© PSA. 2016. ALL RIGHTS RESERVED. CONFIDENTIAL AND PROPRIETARY DOCUMENT.
THIS DOCUMENT AND ALL INFORMATION CONTAINED HEREIN IS THE SOLE PROPERTY OF PSA.. NO INTELLECTUAL PROPERTY RIGHTS ARE GRANTED BY
THE DELIVERY OF THIS DOCUMENT OR THE DISCLOSURE OF ITS CONTENT. THIS DOCUMENT SHALL NOT BE REPRODUCED OR DISCLOSED TO A THIRD
PARTY WITHOUT THE EXPRESS WRITTEN CONSENT OF PSA. THIS DOCUMENT AND ITS CONTENT SHALL NOT BE USED FOR ANY PURPOSE OTHER THAN
THAT FOR WHICH IT IS SUPPLIED.
Reference : Application date:
02016_16_05952 01/08/2016
PSA Cyber Security Assurance Requirements
CONFIDENTIEL C2 : Can be distributed to the relevant people if it is strictly necessary.

Scope:
This document intends to provide the security assurance requirements applicable to PSA security
embedded products.
Author(s) :
Name : Entity : Date : Signature :
Abdelaziz EL AABID DRD/DSEE/CIAE/EERS/ERSP 01/08/2016
Validation(s) :
Eric DEQUI DRD/DSEE/CIAE/EERS/ERSP 01/08/2016
Approved By :
Jean De BAUDREIL DRD/DSEE/CIAE 01/08/2016
PSA designation code :
PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE
C2: RESTRICTED 02016_16_05952 1.0 2/159
THIS DOCUMENT IS THE PROPERTY OF PSA PEUGEOT CITROËN GROUP AND CANNOT BE REPRODUCED OR COMMUNICATES WITHOUT ITS AUTHORIZATION.
About this document
This document intends to provide the security assurance requirements applicable to PSA security
embedded products.
Version management
Issue Date Page Description Author(s)
1.0 01/08/2016 Initial Version Altran: Philippe Barre / Florent Petit
Table 1 - Version management table
The present issue cancels and replaces any previous issue of this document; it will be cancelled and replaced
by any further issue of this document.
For new edition readability, minor form of revision such as orthographic corrections, new numbering of
paragraphs, tables and figures, styles, will not be marked as revised.
Reference or applicable documents

Mark Applicable document Document ID Issue / Date
[AD1] None
Table 2 - Applicable documents table
Mark Reference document Document ID Issue / Date

[RD1] Common Criteria ISO/IEC 15408 V3.1R4
Table 3 - Reference documents table
C2: RESTRICTED 02016_16_05952 1.0 3/159
Contents
1. Introduction .............................................................................................................. 7
1.1. Objectives ............................................................................................................................................. 8
1.2. Audience and applicability .................................................................................................................... 9
1.3. How to use this document................................................................................................................... 10
1.4. Document organization ....................................................................................................................... 10
1.5. Security Assurance Levels Summary..................................................................................................... 11
1.5.1. Security Assurance set of requirements ....................................................................................... 11
1.5.2. Security Assurance Levels ........................................................................................................... 12
1.5.2.1. Security Assurance Level 1 ................................................................................................... 13
2. General requirements .............................................................................................. 26
3. Security evaluation .................................................................................................. 35
3.1. Security part of the product description............................................................................................... 36
3.2. Security problem definition ................................................................................................................. 39
3.3. Security Objectives .............................................................................................................................. 44
3.4. Security requirements ......................................................................................................................... 45
3.5. SPP Summary specification .................................................................................................................. 48
4. Lifecycle management of the development ............................................................... 50

4.1. Lifecycle definition .............................................................................................................................. 51
4.2. Configuration management ................................................................................................................. 54
4.2.1. Configuration management capabilities ...................................................................................... 54
4.2.2. Configuration management Scope ............................................................................................... 65
4.3. Tools and techniques for development ................................................................................................ 68
4.4. COTS .................................................................................................................................................. 74
4.5. Security Survey.................................................................................................................................... 77
4.6. Flaw remediation ................................................................................................................................ 80
4.7. Delivery and acquisition ...................................................................................................................... 87
4.7.1. Delivery ...................................................................................................................................... 87
4.7.1. Acquisition ................................................................................................................................. 90
4.8. Security of the development environment ............................................................................................ 91
5. Development ........................................................................................................... 93
5.1. Security architecture ........................................................................................................................... 95
5.2. Functional specifications ..................................................................................................................... 98
5.3. SPP-SF Internal structure design analysis ........................................................................................... 106
C2: RESTRICTED 02016_16_05952 1.0 4/159
5.4. SPP Design (conception) .................................................................................................................... 109
5.5. Implementation representation ......................................................................................................... 119
6. Guidance .............................................................................................................. 122

6.1. Operational user guidance ................................................................................................................ 123
6.2. Preparative procedures ..................................................................................................................... 128
7. Testing ................................................................................................................. 130

7.1. Testing Coverage .............................................................................................................................. 131
7.2. Testing Depth ................................................................................................................................... 132
7.3. Functional tests ................................................................................................................................ 135
7.4. Independent testing .......................................................................................................................... 139
8. Vulnerability assessment ....................................................................................... 141

8.1. Introduction ...................................................................................................................................... 142
8.1. Attacker’s profiles and expertise ....................................................................................................... 142
8.2. Vulnerability analysis ........................................................................................................................ 144
A. APPENDIX .............................................................................................................. 152

A.1. Structure of requirements ................................................................................................................. 153
A.2. Life-cycle reviews for monitoring ...................................................................................................... 154
A.3. List of abbreviations.......................................................................................................................... 156
A.4. List of terms ..................................................................................................................................... 158
C2: RESTRICTED 02016_16_05952 1.0 5/159
List of tables
Table 1 - Version management table ................................................................................................................ 3
Table 2 - Applicable documents table ............................................................................................................... 3
Table 3 - Reference documents table ................................................................................................................ 3
Table 4 - Security assurance stakeholders ........................................................................................................ 9
Table 5 - Software assurance sets of requirements ......................................................................................... 11
Table 6 - Software assurance levels (SAL)........................................................................................................ 12
Table 7 – Level 1 activities summary ............................................................................................................... 16
Table 10 – Level 4 activities summary ............................................................................................................. 25
Table 11 - Type of attacker .......................................................................................................................... 143
Table 12 - Expertise level of the attacker ...................................................................................................... 143
Table 13 - Means of the attacker .................................................................................................................. 144
Table 14 – Structure of the requirement ........................................................................................................ 153
Table 15 - Acronyms table ........................................................................................................................... 157
Table 16 - Terms table ................................................................................................................................. 159
List of figures
Figure 1: Product Life cycle big picture ........................................................................................................... 27
Figure 2: Evaluation purpose and concepts ..................................................................................................... 36
Figure 3: SPP and SPP-SF overview .................................................................................................................. 37
Figure 4: SPD overview ................................................................................................................................... 40
Figure 5: Security concepts ............................................................................................................................. 41
Figure 6: Threat scenarios parameters ............................................................................................................ 42
Figure 7: Development steps .......................................................................................................................... 94
Figure 8: Subsystems and Modules ............................................................................................................... 110
Figure 9: Life-cycle reviews and deliverables ................................................................................................. 154
C2: RESTRICTED 02016_16_05952 1.0 6/159
1. Introduction
C2: RESTRICTED 02016_16_05952 1.0 7/159
1.1. Objectives
This document addresses the main high level families of “state-of-the-art” security assurance
process that will be applicable for PSA automotive security embedded products. Each requirement
of this document introduces the general security activities required to cover the following main
Security Assurance Objectives:
 Objective 1 (O1): Provide an security organization protecting the assets of the project,
 Objective 2 (O2): Ensure security evaluation capabilities to assess the coherency of the
security needs with regards to the selected security features, their strength and their
quality during the product life cycle.
 Objective 3 (O3): Perform vulnerability analysis and management activities to provide

confidence that the product will be free of exploitable vulnerabilities during its life cycle. It
means that the security features of consumer embedded products cannot be bypassed nor
tampered. It also provide confidence that all COTS (modified or not) part of the product do
not contain any known applicable vulnerability that can impair the consumer embedded
products itself or the equipment connected.
 Objective 4 (O4): Prevent malicious code in embedded products.
 Objective 5 (O5): Provide secure operation by ensuring that installation, operability and
maintenance activities will not impair embedded products security level.
 Objective 6 (O6): Reporting of products’ security vulnerabilities, limitation, deviations and

all security open points in order to manage residual risks at vehicle level.
C2: RESTRICTED 02016_16_05952 1.0 8/159
1.2. Audience and applicability
This document applies to all people involved in PSA automotive security embedded products
development.
The different identified actors and stakeholders are:
Actors &
Description
stakeholders
Wants to ensure that the Security Part of the Product (SPP) fulfils its security
needs, this is the fundamental purpose and justification for the application of
this evaluation process.
Consumer Wants to ensure that the developer has performed due diligence in removing or
avoiding weaknesses that are most critical to the consumer's business and
mission. Related stakeholders include CIOs, CSOs, system administrators, and
end users of the product.
Wants to manage their product assurance expectations for a diverse portfolio of

third-party and/or internally-developed packages whose deployment and secure
operation are important to the consumer’s business and/or mission.
Developers Is in charge of conducting security activities. Performs or supervises risk

analysis. Elaborates security architecture. Designs security mitigations
measures. Evaluates and supervises software code analysis. Conducts validation
& verification & evaluation activities, vulnerability management, technology
watch, crisis management activities, etc.
The evaluator is in charge to provide judgements about the conformance of the

security evidences against the security requirements of this document. The
Evaluator
evaluator is a third-party contracted by the developer. The evaluation activities
should be driven by the developer evaluation strategy shared with PSA.
Table 4 - Security assurance stakeholders
C2: RESTRICTED 02016_16_05952 1.0 9/159
1.3. How to use this document
This document addresses the main topics of “state-of-the-art” security assurance process. The
security assurance activities that will be performed for the product development will be described
in dedicated documents providing traceability and coverage against security assurance
requirements defined in this document.
For convenience the term “developer” will be used in most of the requirements to refer to both
Hardware/Software developers and their managers. It includes the Security officer and the Project
manager.
The term “evaluator” will be used in some requirements when evaluation activities will be
required.
1.4. Document organization
The 1st chapter “Introduction” presents a general introduction to the document.
The 2nd chapter “General requirement” presents the miscellaneous requirements related to
security assurance topics not contained in the following chapters.
The 3rd chapter “Security Evaluation” defines requirements to be able to assess the coherency of
the security needs with regards to the selected security features, their strength and their quality
during the product life cycle.
The 4th chapter “Life-cycle management of the development” provides requirements to mainly
protect the development environment and to ensure the delivery of the product with the
confidence that it will be free of vulnerabilities and malicious code.
The 5th chapter “Development” requirements aims at structuring and representing the security
functionalities at various levels and varying forms of abstraction to ease the evaluation of the
Security Part of the Product.
The 6th chapter “Guidance” provides requirements for operability by ensuring that installation,
operation, maintenance activities will not impair the security level of the software.
The 7th chapter “Testing” provides requirements about testing of the security functional
specification with adequate coverage, depth, method and independency.
The 8th chapter “Vulnerability assessment” provides requirement to limit exploitable vulnerabilities
introduced in the development or the operation of the Security Part of the Product.
C2: RESTRICTED 02016_16_05952 1.0 10/159
1.5. Security Assurance Levels Summary
1.5.1. Security Assurance set of requirements

This document provides some sets of requirements per Familly/Sub-Familly of security assurance thematic.
The requirements, applicable to a given set are identified according to their “component level”
values:
REQ_ID 1 REQ Body
Rationale Author
Assumptions Document
Additional info. Family
Stakeholder Sub-family
Source Applicability
Component Level Scope
Req. Mngt. Ident. Maturity
Imp. Responsible Monitoring
These set of requirements will be used to define the security assurance levels.
Security Assurance Set of Req.
Family Set 1 Set 2 Set 3 Set 4 Set 5 SAL TBD
Sub-Family
2. General requirements 2. General requirements 1 Set 1
3.1. Security part of the product description 1 Set 1
3.2. Security problem definition 1 Set 1
3. Security Evaluation 3.3. Security Objectives 1 Set 1
3.4. Security requirements 1 Set 1
3.5. SPP Summary specification 1 1+2 Set 2
4.1. Lifecycle definition 1+2 Set 1 Set 1
4.2.1. Configuration management capabilities 1 1+2 1+2+3+4 1+2+3+5 1+2+3+5+6 Set 4 Set 2
4.2.2. Configuration management Scope 1+2 1+3+4 1+3+5 1+3+6 1+3+7 Set 4 Set 3
4.3. Tools and techniques for development 1 1+2 1+3 Set 3 Set 4
4.4. Embedded COTS 1 1+2 Set 2 Set 5
4. Life-cycle support
4.5. Security Survey 1 1+2 Set 2
4.6. Flaw remediation 1 1+2 1+2+3 Set 2
4.7.1. Delivery 1 Set 1
4.7.2. Acquisition 1 Set 1
4.8. Security of the development environment 1 1+2 Set 1
5.1. Security architecture 1 Set 1
5.2. Functional specifications 1+2+3+4+5 1+5+6+7+8 1+5+6+7+9 1+5+6+10 1+5+6+10+12 Set 3
5. Development 5.3. SPP-SF Internal structure design analysis 1+2 1+3+4 Set 1
5.4. SPP Design (conception) 1+2+3+4 1+4+5+6 1+4+6+7+8 1+4+6+7+9+11+12 Set 2
5.5. Implementation representation 1+2 Set 1
6.1. Operational user guidance 1 Set 1
6. Guidance
6.2. Preparative procedures 1 Set 1
7.1. Testing Coverage 1+2 1+3+4+5 Set 1
7.2. Testing Depth 1+2 1+3+4 1+5+6 Set 3
7. Testing
7.3. Functional tests 1 1+2 Set 1
7.4. Independent testing 1+2 1+2+3+4 Set 2
8. Vulnerability assessment 8.2. Vulnerability analysis 1+2 1+2+3 1+4 1+5+6 Set 3
Table 5 - Software assurance sets of requirements
C2: RESTRICTED 02016_16_05952 1.0 11/159
1.5.2. Security Assurance Levels
The requirements, applicable to a given security assurance level, have to selected in accordance to
the selected sets for each SAL defined as follows:
Security Assurance Level
Family SAL1 SAL2 SAL3 SAL4
Sub-Family
2. General requirements 2. General requirements Set 1 Set 1 Set 1 Set 1
3.1. Security part of the product description Set 1 Set 1 Set 1 Set 1
3.2. Security problem definition Set 1 Set 1 Set 1 Set 1
3. Security Evaluation 3.3. Security Objectives Set 1 Set 1 Set 1 Set 1
3.4. Security requirements Set 1 Set 1 Set 1 Set 1
3.5. SPP Summary specification Set 1 Set 2 Set 2 Set 2
4.1. Lifecycle definition Set 1 Set 1 Set 1
4.2.1. Configuration management capabilities Set 1 Set 3 Set 4 Set 5
4.2.2. Configuration management Scope Set 1 Set 3 Set 4 Set 5
4.3. Tools and techniques for development Set 1 Set 2 Set 3
4.4. Embedded COTS Set 1 Set 2 Set 2 Set 2
4. Life-cycle support
4.5. Security Survey Set 1 Set 1 Set 2 Set 2
4.6. Flaw remediation Set 1 Set 1 Set 2 Set 3
4.7.1. Delivery Set 1 Set 1 Set 1
4.7.2. Acquisition Set 1 Set 1 Set 1 Set 1
4.8. Security of the development environment Set 1 Set 1 Set 2 Set 2
5.1. Security architecture Set 1 Set 1 Set 1
5.2. Functional specifications Set 1 Set 3 Set 4 Set 5
5. Development 5.3. SPP-SF Internal structure design analysis 1+2 Set 2
5.4. SPP Design (conception) Set 1 Set 2 Set 3 Set 4
5.5. Implementation representation Set 1 Set 1
6.1. Operational user guidance Set 1 Set 1 Set 1 Set 1
6. Guidance
6.2. Preparative procedures Set 1 Set 1 Set 1 Set 1
7.1. Testing Coverage Set 1 Set 2 Set 2 Set 2
7.2. Testing Depth Set 1 Set 1 Set 2 Set 3
7. Testing
7.3. Functional tests Set 1 Set 1 Set 2 Set 2
7.4. Independent testing Set 1 Set 2 Set 2 Set 2
8. Vulnerability assessment 8.2. Vulnerability analysis Set 1 Set 2 Set 3 Set 4
Table 6 - Software assurance levels (SAL)
C2: RESTRICTED 02016_16_05952 1.0 12/159
1.5.2.1. Security Assurance Level 1
LEVEL 1 is applicable where some confidence in correct operation is required, but the threats to
security are not viewed as serious. This level also aims at ensuring the security of the
development environment, preventing inclusion of malware in the embedded code or in the
development tools and disclosure of sensitive information as Intellectual Properties (IP) and
security data.
The covered Security Assurance activities are the following ones:
Family or Sub-Family Security Assurance Level 1 (SAL-1) activities summary
- Applicable laws and regulations are identified.

2. General requirements - Actors of the project are identified and their roles are defined.
- Security and design evidences for assurance are identified.
- Security Part of the Product (SPP) description is provided.
3.1. Security part of the product - Physical and Logical scope of the SPP is described.
description - SPP environment (hardware / software / firmware items) required by the
SPP is identified.
- Security problem definition (SPD) is provided.
3.2. Security problem definition
- Threats scenarios, Security policies, Assumptions are described.
- Security objectives for the SPP and for the operational environment are
defined.
3.3. Security Objectives
- Security objective rationale is provided (e.g. tracing with Threats
Scenarios, Security policies, Assumptions).
- Security requirements statements (Assurance, Functional, Other) are
provided.
- Security requirements rationales (Assurance, Functional, Other) are
3.4. Security requirements
provided.
- Compliance level with the SAR is provided and rationale is provided
- Security requirements are traced to the Security Objectives.
3.5. SPP Summary specification SPP summary specification is provided.
4.1. Lifecycle definition Nothing required.
4.2.1. Configuration management The SPP is labelled as a unique reference.
capabilities
- A configuration list, identifying uniquely the configuration items, is
4.2.2. Configuration management provided in the Configuration and Change Management Dossier (CCMD).
Scope - The configuration list includes the SPP itself and the SAR’s evaluation
evidences.
4.3. Tools and techniques for Nothing required.
C2: RESTRICTED 02016_16_05952 1.0 13/159
development
- COTS (modified or not) that are embedded in the SPP are identified and
described.
- COTS (modified or not) that are used in the development environment,
having possibly an impact on the SPP, are identified.
-The justification of the selection of the COTS, according to consumer’s
4.4. Embedded COTS
security evaluation policies, is provided.
- The demonstration that the editors of embedded COTS and provided
components have a sufficient confidence level about the security
management and the risks of [malicious code]/[vulnerabilities] inclusion
in the SPP, is provided in the COTS Vulnerability Report (CVR).
- A security survey process is implemented.
- The security survey procedures, related to COTS components (modified
or not) that are embedded in the SPP, are described in the Management
and Development Dossier (SMDD).
- The security survey of SPP embedded COTS (modified or not)
vulnerabilities (public) are performed.
4.5. Security Survey
- security survey is performed during an agreed period with the
consumer.
- All parts of the SPP-SF are covered by a security survey process during
an agreed period.
- The security survey outcomes are documented in the Security
Vulnerability Dossier (SVD) and in the Security Compliance Dossier (SCD).
-The flaw remediation process is documented in the Security
Management and Development Dossier (SMDD).
-Flaw remediation procedures addressed to SPP developers are available.
-The flaw remediation procedures documentation describes the
procedures used to track all reported security flaws in each release of the
SPP.
-The flaw remediation procedures require that a description of the nature
4.6. Flaw remediation
and effect of each security flaw be provided, as well as the status of
finding a correction to that flaw.
-The flaw remediation procedures require that corrective or workaround
actions be identified for each of the security flaws.
-The flaw remediation procedures documentation describe the methods
used to provide flaw information, corrections and guidance on corrective
actions to SPP users.
4.7.1. Delivery Nothing required.
4.7.2. Acquisition - Procedures for the acquisition of parts of the SPP from potential
C2: RESTRICTED 02016_16_05952 1.0 14/159
suppliers are described and used.

- Integrity, non-disclosure and non-repudiation of acquired COTS
(including in any hardware and/or software) with possible impact on the
SPP is guaranteed.
All the security measures (physical, procedural, personnel, and other) that
4.8. Security of the development
are necessary to protect the availability, integrity and confidentiality of
environment
the SPP during its development and maintenance lifecycle are described.
5.1. Security architecture Nothing required.
- A functional specification which describes the SPP Security
functionalities Interfaces (SPP-SFIs) is provided.
- Purpose and method of the interfaces of SFR-enforcing and SFR-
supporting are described. Associated parameters are identified.
5.2. Functional specifications -Rationale for implicit characterization of SFR-non-interfering interfaces
is provided.
-A mapping between SFRs and SPP-SFIs is provided.
- The mapping demonstrates that the SFRs trace to SPP-SF Interfaces in
the functional specification.
5.3. SPP-SF Internal structure Nothing required.
design analysis
5.4. SPP Design (conception) Nothing required.
5.5. Implementation
Nothing required.
representation
Operational User Guidance describing the operation of security
6.1. Operational user guidance
functionalities of the SPP is provided.
Preparative procedures for the secure installation and acceptance of the
6.2. Preparative procedures
SPP in its operational environment are provided.
- Evidence of the test coverage is provided.
7.1. Testing Coverage - Evidence of the test coverage show the correspondence between the
tests and the SPP-SF interfaces in the functional specification.
- An analysis of the depth of testing is provided
- The analysis of the depth of testing demonstrates the correspondence
7.2. Testing Depth between the tests and the SPP-SF subsystems.
- The analysis of the depth of testing demonstrates that all the SPP-SF
subsystems have been tested.
- The SPP-SF is functionally tested and the results are provided in the
V&V dossier.
7.3. Functional tests - V&V documentation (test plan and related strategy, tests objectives, test
procedures, expected and observed test results) is provided.
-The test objectives and related scenarios include positive, negative and
C2: RESTRICTED 02016_16_05952 1.0 15/159
robustness test use cases.

- The SPP is provided for testing and meets all requirements for content
and presentation of evidence.
7.4. Independent testing
- The SPP is partially tested (e.g. test samples) by an independent
evaluator.
- The SPP is provided to an accredited evaluator for vulnerability
evaluation and meets all requirements for content and presentation of
evidence.
- The evaluator performs a vulnerability analysis and provides an
assessment according to consumer’s security audit & evaluation
guidelines.
- The results of the SPP vulnerability analysis activities are provided in the
8.2. Vulnerability analysis
Security Vulnerability Dossier (SVD).
- The evaluator performs a search of public domain sources to identify
potential vulnerabilities in the SPP.
- The evaluator conduct penetration testing, based on the identified
potential vulnerabilities and also SPD, to determine that the SPP is
resistant to attacks performed by an attacker possessing a “Layman” or
“Proficient” expertise level with “Standard” means.
Table 7 – Level 1 activities summary
LEVEL 2 provide a medium assurance level and is typically selected for complex products mainly
based on COTS (like operating systems) in case a higher level is considered to be too costly.
The covered Security Assurance activities are the following ones in addition of Level 1.
Family or Sub-Family SAL 2 activities summary in addition to SAL 1 activities
2. General requirements Refer to Level 1.

3.1. Security part of the product Refer to Level 1.
description
3.2. Security problem definition Refer to Level 1.
3.3. Security Objectives Refer to Level 1.
3.4. Security requirements Refer to Level 1.
- The SPP summary specification describes how the SPP protects itself
3.5. SPP Summary specification
against interference, logical tampering and bypass.
4.1. Lifecycle definition (new) - The Life-cycle model to be used in the development and maintenance of
C2: RESTRICTED 02016_16_05952 1.0 16/159
the SPP is established and described in the V&V documentation.

-The life-cycle model address the needs of control over the development
and maintenance of the SPP.
- Configuration management documentation is available in the
Configuration and Change Management Dossier (CCMD).
- The Configuration Management documentation includes a Configuration
Management Plan (CMP) that describes how the CMS is used for the
development of the SPP.
- Configuration items are managed under a configuration management
system (CMS).
4.2.1. Configuration management - All configuration items are uniquely identify through the CMS.
capabilities - The CMS provides measures such that only authorized changes are
made to the configuration items.
- Evidences of CM system integration in the development, which
demonstrates that all configuration items are maintained under the CMS,
are provided.
- Evidences of CM system integration in the development, which
demonstrates that the CMS is operated in accordance with the CMP, are
provided.
-The developers of the SPP-SF relevant configuration item are identified
in the configuration list.
4.2.2. Configuration management
- The configuration list includes the following items: the SPP itself; the
Scope
evaluation evidence required by the SARs; required by SAL 1 and the parts
that comprise the SPP (including COTS) required by SAL2.
- Each development tool being used for the SPP is identified in the
Security Management and Development Dossier (SMDD).
- All development tools that can impact the embedded code of the SPP
are described, analysed and justified.
- The selected implementation dependent options of each development
tool are documented in the Security Management and Development
4.3. Tools and techniques for
Dossier (SMDD).
development (new)
- Each development tool used for implementation is well-defined.
- The documentation of each development tool unambiguously defines
the meaning of all statements as well as all conventions and directives
used in the implementation.
- The documentation of each development tool unambiguously defines
the meaning of all implementation-dependent options.
- A contract enabling the capability to modify embedded COTS during the
4.4. Embedded COTS
whole product life-cycle is contracted with the consumer.
C2: RESTRICTED 02016_16_05952 1.0 17/159
- It shall be ensured that the COTS supplier apply a “well defined” security
process minimizing the likelihood that delivered COTS contain any known
applicable vulnerabilities with a potential security impact on the SPP.
4.5. Security Survey Refer to Level 1.
4.6. Flaw remediation Refer to Level 1.
-Procedures for the delivery of the SPP or parts of it to the consumer are
documented and used.
- The delivery documentation describes all procedures that are necessary
4.7.1. Delivery (new) to maintain security when distributing versions of the SPP to the
consumer.
- The delivery procedures guarantees the availability, integrity,
confidentiality and non-repudiation of the SPP.
4.7.2. Acquisition Refer to Level 1.
4.8. Security of the development Refer to Level 1.
environment
- The SPP is designed and implemented so that the security features of
the SPP-SF cannot be bypassed.
- The SPP is designed and implemented so that the SPP-SF are self-
protected against tampering by untrusted active entities.
- The SPP implement a secure initialization process of the SPP-SF.
- The SPP security architecture is described. Ii includes the SPP-SF
5.1. Security architecture (new) initialization and shutdown processes, the self-protection against
tampering, the security domains protected by the SPP-SF, the principles
preventing bypass of SPP-SF.
- The security architecture description demonstrates that the SPP-SF:
Initialization and shutdown process is secure Mechanisms against
tampering are secure Prevent bypass of the SFR-enforcing functionalities
Keeps the asset protected by the SFR-enforcing functionalities.
- The functional specification (FS) completely represents the SPP-SF.
- The FS describe the purpose and method of use for all SPP-SF
Interfaces.
- The FS identifies and describes all parameters associated with each SPP-
SF Interfaces.
5.2. Functional specifications - For each SFR-enforcing SPP-SF interface, the functional specification
describes the SFR-enforcing actions associated with the SPP-SF interface.
- For each SFR-enforcing SPP-SF interface, the functional specification
describes direct error messages resulting from SFR-enforcing actions and
exceptions associated with invocation of the SPP-SF interfaces.
- The functional specification summarizes the SFR-supporting and SFR-
C2: RESTRICTED 02016_16_05952 1.0 18/159
non-interfering actions associated with each SPP-SF interface.

5.3. SPP-SF Internal structure
Nothing required.
design analysis
- The design describes the behaviour of each SFR non-interfering
subsystem of the SPP-SF in detail sufficient to determine that it is SFR
non-interfering.
- The design describes the SFR-enforcing behaviour of the SFR-enforcing
5.4. SPP Design (conception) subsystems.
- The design summarizes the behaviour of the SFR-supporting
subsystems.
- The design provides a description of the interactions among all
subsystems of the SPP-SF.
5.5. Implementation
Nothing required.
representation
6.1. Operational user guidance Refer to Level 1.
6.2. Preparative procedures Refer to Level 1.
-An analysis of the test coverage in the V&V Dossier (VVD) is provided.
- The analysis of the test coverage demonstrates the correspondence
7.1. Testing Coverage between the tests and the SPP-SFIs in the functional specification.
- The analysis of the test coverage demonstrates that all SPP-SF interfaces
in the functional specification have been tested.
7.2. Testing Depth Refer to Level 1.
7.3. Functional tests Refer to Level 1.
- The developer provides to the evaluator an equivalent set of resources
to those that were used in the developer's functional testing of the SPP-
7.4. Independent testing SF.
- The evaluator executes a sample of tests in the V&V Dossier (VVD) to
verify the developer test results.
- The evaluator performs an independent vulnerability analysis of the SPP
using the guidance documentation, functional specification, SPP design
and security architecture description to identify potential vulnerabilities in
the SPP.
8.2. Vulnerability analysis - The developer performs a code review on added and modified
embedded software except [COTS software and “trusted” software].
- The evaluator performs a sample of code review covering added and
modified embedded software except [COTS software and “trusted”
software].
C2: RESTRICTED 02016_16_05952 1.0 19/159
LEVEL 3 is adequate for products requiring a high assurance level with a majority of internally-
developed packages allowing a full mastering of security assurance activities. It provides a good
quality-price ratio.

description
3.5. SPP Summary specification Refer to Level 2.
4.1. Lifecycle definition Refer to Level 2.
- The Configuration Management system provides automated measures
such that only authorized changes are made to the configuration items.
4.2.1. Configuration management - The Configuration Management system supports the production of the
capabilities SPP by automated means.
- The Configuration Management plan describes the procedures used to
accept modified or newly created configuration items as part of the SPP.
- The configuration list includes the following: the SPP itself; the
evaluation evidence required by the SARs; the parts that comprise the SPP
Scope (including COTS); required by SAL2 and the implementation
representation and security flaw reports and resolution status required by
SAL3.
4.3. Tools and techniques for The implementation standards that are being applied by the developer of
development the SPP are listed and documented.
4.4. Embedded COTS Refer to Level 2.
- Security survey procedures related to all development tools that can
impact the embedded code of the SPP are described in the Management
4.5. Security Survey and Development Dossier (SMDD).
- All parts of the SPP-SF are covered by a security survey process during
an agreed period.
- A procedure for accepting and acting upon all reports of security flaws
and requests for corrections to those flaws is established.
- Flaw remediation guidance addressed to SPP users is provided.
- Flaw remediation procedures describe means by which the developer
C2: RESTRICTED 02016_16_05952 1.0 20/159
receives from SPP users reports and enquiries of suspected security flaws
in the SPP.
- Procedures for processing reported security flaws ensure that any
reported flaws are remediated and the remediation procedures issued to
SPP users.
- Procedures for processing reported security flaws provide safeguards
that any corrections to these security flaws do not introduce any new
flaws.
-Flaw remediation guidance describes means by which SPP users report to
the developer any suspected security flaws in the SPP.
4.7.1. Delivery Refer to Level 2.
environment
5.1. Security architecture Refer to Level 2.
The functional specification describes
- all actions associated with each SPP-SF Interface.
5.2. Functional specifications
- all direct error messages that may result from an invocation of each
SPP-SF Interface.
- A subset of the SPP-SF is design and implemented such that it has
“well-structured” internal structure.
- A description and justification of the internal structure of the SPP-SF is
5.3. SPP-SF Internal structure design provided.
analysis (new) - The SPP-SF internal structure justification explains the characteristics
used to judge the meaning of “well-structured” internal structure.
- The description of the SPP-SF internal structure demonstrates that the
assigned subset of the SPP-SF is well-structured.
- The SPP-SF is described in terms of modules.
- The design provides:
- a description of each subsystem of the SPP-SF.
- a mapping from the subsystems of the SPP-SF to the modules of the
SPP-SF.
- The design ensures the robustness of SFR-enforcing modules in terms
5.4. SPP Design (conception)
of its SFR-related interfaces.
- The design describes each SFR-enforcing module in terms of its
purpose and relationship with other modules.
- The design describes each SFR-enforcing module in terms of its SFR-
related interfaces return values from those interfaces, interaction with
other modules and called SFR-related interfaces to other SFR-enforcing
C2: RESTRICTED 02016_16_05952 1.0 21/159
modules.
- The design describes each SFR-supporting or SFR-non-interfering
module in terms of its purpose and interaction with other modules.
- The implementation representation for the entire SPP-SF is made
available.
- A mapping between the SPP design description and the sample of the
implementation representation is provided.
5.5. Implementation representation -The implementation representation defines the SPP-SF to a level of detail
(new) such that the SPP-SF can be generated without further design decisions.
- The implementation representation is in a form used by the
development personnel.
- The mapping between the SPP design description and the sample of the
implementation representation is demonstrated.
7.1. Testing Coverage Refer to Level 2.
-The analysis of the depth of testing demonstrates the correspondence
between the tests in the V&V Dossier (VVD) and the SPP-SF subsystems
7.2. Testing Depth and SFR-enforcing modules in the SPP design.
-The analysis of the depth of testing demonstrates that the SFR-enforcing
modules in the SPP design have been tested.
The V&V Dossier (VVD) includes an analysis of the test procedure ordering
7.3. Functional tests
dependencies.
7.4. Independent testing Refer to Level 2.
- The evaluator performs an independent, focused vulnerability analysis
of the SPP using the guidance documentation, functional specification,
SPP design, security architecture description and implementation
representation to identify potential vulnerabilities in the SPP.
- The developer performs a code review on all added and modified
embedded software except “trusted’ software.
- The evaluator performs a sample of code review covering all added and
modified embedded software except “trusted’ software.
- The evaluator conduct penetration testing, based on the identified
resistant to attacks performed by an attacker possessing a “Proficient”
expertise level with “Specialized” means.
C2: RESTRICTED 02016_16_05952 1.0 22/159
LEVEL 4 is Level 3++ when extra assurance is required.

description
3.5. SPP Summary specification Refer to Level 2.
4.1. Lifecycle definition Refer to Level 2.
- The Configuration Management documentation justifies that the
acceptance procedures provide for an adequate and appropriate review of
changes to all configuration items.
- The Configuration Management system ensures that the person
responsible for accepting a configuration item into Configuration
Management is not the person who developed it.
- The Configuration Management system identifies the configuration
items that comprise the SPP-SF.
- The Configuration Management system supports the audit of all
4.2.1. Configuration management changes to the SPP by automated means, including the originator, date,
capabilities and time.
- The Configuration Management system provides an automated means
to identify all other configuration items that are affected by the change of
a given configuration item.
- The Configuration Management system is able to identify the version of
the implementation representation from which the SPP is generated.
- Any code addition or modification is documented and is linked to a
change request.
-The source code is compliant with the description of the code addition
or modification.
- The configuration list includes the following: the SPP itself; the
evaluation evidence required by the SARs; the parts that comprise the SPP;
Scope the implementation representation; security flaw reports and resolution
status; required by SAL 3 and development tools and related information
required by SAL 4.
C2: RESTRICTED 02016_16_05952 1.0 23/159
The implementation standards that are being applied by the developer

4.3. Tools and techniques for
development and by any third-party providers for all parts of the SPP are described and
provided.
4.4. Embedded COTS Refer to Level 2.
4.5. Security Survey Refer to Level 3.
- The flaw remediation procedures includes a procedure requiring timely
response and the automatic distribution of security flaw reports and the
associated corrections to registered users who might be affected by the
security flaw.
4.6. Flaw remediation - The flaw remediation guidance describes means by which SPP users may
register with the developer, to be eligible to receive security flaw reports
and corrections.
- The flaw remediation guidance identifies the specific points of contact
for all reports and enquiries about security issues involving the SPP.
4.7.1. Delivery Refer to Level 2.
environment
5.1. Security architecture Refer to Level 2.
-The functional specification describes all error messages that do not
result from an invocation of a SPP-SF Interface.
5.2. Functional specifications -The functional specification provides a rationale for each error message
contained in the SPP-SF implementation yet does not result from an
invocation of a SPP-SF Interface.
- The entire SPP-SF is designed and implemented such that it has well-
structured internals.
5.3. SPP-SF Internal structure design - The SPP-SF internal structure justification describes the characteristics
analysis used to judge the meaning of “well-structured”.
- The SPP-SF internal structure description demonstrates that the entire
SPP-SF is well- structured.
-The design describes the SPP-SF in terms of modules, designating each
module as SFR-enforcing, SFR-supporting, or SFR-non-interfering.
-The design describes each SFR-enforcing and SFR-supporting module in
terms of its purpose and relationship with other modules.
5.4. SPP Design (conception) -The design describes each SFR-enforcing and SFR-supporting module in
terms of its SFR-related interfaces, return values from those interfaces,
interaction with other modules and called SFR-related interfaces to other
SFR-enforcing or SFR-supporting modules.
-The design describes each SFR-non-interfering module in terms of its
C2: RESTRICTED 02016_16_05952 1.0 24/159
purpose and interaction with other modules.

5.5. Implementation representation Refer to Level 3.
7.1. Testing Coverage Refer to Level 2.
- The analysis of the depth of testing demonstrates:
- the correspondence between the tests in the V&V Dossier (VVD) and
7.2. Testing Depth
the SPP-SF subsystems and modules in the SPP design.
- that all SPP-SF modules in the SPP design have been tested.
7.3. Functional tests Refer to Level 3.
7.4. Independent testing Refer to Level 2.
- The evaluator performs an independent, methodical vulnerability
analysis of the SPP using the guidance documentation, functional
specification, SPP design, security architecture description, organizational
security policies, assumptions about the environment, and
implementation representation to identify potential vulnerabilities in the
SPP.
- The developer performs a code review on all embedded software except
“trusted’ software.
- The evaluator performs a sample of code review covering all embedded
software except “trusted’ software.
- The evaluator conducts penetration testing based on the identified
resistant to attacks performed by an attacker possessing an “Expert”
expertise level with “Specialized” and “Bespoke” means.
C2: RESTRICTED 02016_16_05952 1.0 25/159
2. General requirements
C2: RESTRICTED 02016_16_05952 1.0 26/159
Production life-cycle phase follows the development phase of the product including the security features.
This phase include manufacturing, integration, generation, internal transports, storage, and labelling of
the security part of the system that will be evaluated.
The reviews indicated for the monitoring of the requirements are described in A.2.
Product Life Cycle

Developer’s Responsability Consumer’s and/or User’s Responsability
Operational
Development Environment Environment
Testing
Development Installation
Production
(e.g. Manufacturing, Integration,
Generation, Storage, Labelling) Operation
Delivery Process
Send
Preparation Acceptance
Figure 1: Product Life cycle big picture
PSA_ERSP_SAR_0001-1 The developer shall comply with security assurance requirements (SAR) through a
compliance matrix.
Rationale: O1, O2, O3, O4, O5, O6. Author: PSA Sec Officer
Assumptions: Document: SCD
SAR Compliance matrix must be
Additional info.: used according to the required Family: General Req.
Security Assurance Level (SAL).
Stakeholder: Consumer Sub-family: General Req.
Software, Hardware,
Source: PSA Sec Officer Applicability:
Production means
Component Level: 1 Scope: Equipment
Req. Mngt. Ident.: 10 Maturity: Verbatim
Imp. Responsible: Developer Monitoring: PR
C2: RESTRICTED 02016_16_05952 1.0 27/159
PSA_ERSP_SAR_0002-1 The list of laws and regulations specific to security and applicable to the SPP shall
be documented by the developer.
If Applicable laws and regulation
Assumptions: Document: ALL
exist.
Additional info.: Family: General Req.
Source: PSA Sec Officer Applicability: Software, Hardware
PSA_ERSP_SAR_0003-1 Security Terms shall be used according to the glossary of this document and
Common Criteria and NIST (NISTIR 7298) glossary.
O2, O5, O6. Use a common
Rationale: Author: PSA Sec Officer
language
Assumptions: Document: ALL
Additional info.: NISTIR 7298 Revision 2 is used. Family: General Req.
Software, Hardware,
Production means
PSA_ERSP_SAR_0004-1 The developer shall provide a Security Management and Development Dossier
(SMDD).
Assumptions: Document: SMDD
This document describes the
Additional info.: security assurance strategy, plan, Family: General Req.
approach, activities and process.
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: PR, PDR, CDR.
C2: RESTRICTED 02016_16_05952 1.0 28/159
PSA_ERSP_SAR_0005-1 The developer shall provide a Configuration and Change Management Dossier
(CCMD)
Rationale: O2. Author: PSA Sec Officer
Assumptions: Document: CCMD
Handles versioning of deliverables,
binaries and configuration files,
Additional info.: major product versions, security Family: General Req.
correctives, minor product updates,
COTS and tools used
Software, Hardware,
Production means
PSA_ERSP_SAR_0006-1 The developer shall provide a Security Compliance Dossier (SCD).

- Compliance with Security
Assurance Requirements according
to the selected Level,
- Compliance with consumers
overall security requirements.
- Compliance with activities
planned in the Security
Management and Development
Dossier (SMDD) and the ones really
Additional info.: performed. Family: General Req.
- Vulnerability statement from the
following activities: Vulnerability
Analysis (security survey, design
analysis outcomes), Design, Code
review (manual or Automatic),
COTS analysis (embedded and
development tools), Security tests
results (functional and intrusion
tests)
Software, Hardware,
Production means
PR, PDR, CDR, TRR, SAR,
Imp. Responsible: Developer Monitoring:
ORR, EIS.
C2: RESTRICTED 02016_16_05952 1.0 29/159
PSA_ERSP_SAR_0007-1 The developer shall provide a Validation & Verification Dossier (VVD)
Rationale: O2, O3, O4, O5, O6. Author: PSA Sec Officer
Assumptions: Document: VVD
This include all the V&V
documents: V&V Strategy, V&V
Additional info.: Plan, V&V Objectives, V&V Family: General Req.
procedures , V&V outcomes and
results.
Software, Hardware,
Production means
PDR, CDR, TRR, SAR, ORR,
EIS.
PSA_ERSP_SAR_0008-1 The developer shall provide a Flaw remediation procedures (FRP)
Rationale: O2, 03. Author: PSA Sec Officer

Assumptions: Document: FRP
Refer to Flaw remediation
requirements.
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: CDR, SAR, ORR, EIS.
PSA_ERSP_SAR_0009-1 The developer shall provide an Operational User Guidance (OUG)

Assumptions: Document: OUG
Refer to Operational User guidance
Additional info.: and preparative procedures Family: General Req.
requirements.
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 30/159
PSA_ERSP_SAR_0010-1 The developer shall provide the following security process evidences:
- Security Management and Development Dossier (SMDD) for PR milestone,
- Configuration and Change Management Dossier (CCMD) for PR milestone,
- Security Compliance Dossier (SCD) for PR milestone,
- Validation & Verification Dossier (VVD) for PDR milestone,
- Flaw remediation procedures (FRP) for CDR milestone,
- Operational User Guidance (OUG) for CDR milestone,
and updated for each following reviews.
Assumptions: Document: N/A
As these deliverables contain
valuable functional and security
information which could be used by
Additional info.: a potential attacker or competitor, Family: General Req.
access must be closely monitored.
Refer to A.2 chapter for deeper
details.
Software, Hardware,
Production means
ORR, EIS.
PSA_ERSP_SAR_0011-1 The developer shall provide a COTS Vulnerability Report (CVR)
Rationale: O2, O3. Author: PSA Sec Officer

Assumptions: Document: CVR
This report provide the outcomes
Additional info.: of COTS selection and COTS Family: General Req.
security survey activities.
Stakeholder: Sub-family: General Req.
Software, Hardware,
Production means
ORR, EIS.
PSA_ERSP_SAR_0012-1 The developer shall provide a Specification & Design Dossier (SDD)

Assumptions: Document: SDD
Additional info.: Including functional specification Family: General Req.
C2: RESTRICTED 02016_16_05952 1.0 31/159
and design description.
Software, Hardware,
Production means
EIS.
PSA_ERSP_SAR_0013-1 The developer shall provide a Security Vulnerability Dossier (SVD)

Assumptions: Document: SVD
This dossier includes Security
Problem definition description and
outcomes. It also include security
Additional info.: vulnerability outcomes from Family: General Req.
security survey and vulnerability
assessment activities (e.g.: code
review, security testing).
Software, Hardware,
Production means
EIS.
PSA_ERSP_SAR_0014-1 The developer shall provide a Secure coding guidelines (SCG)

Assumptions: Document: SCG
This document provides the Secure
Coding policies (e.g. principles,
process for developers, checking
list, coding rules for languages
used, tools). Coding rules scope
could encompass the following
categories: Pre-processor,
declaration and initialization,
expressions, integers, floating
point, arrays, characters and
strings, memory management,
inputs, outputs, environment,
signals, error handling, application
programming Interfaces,
C2: RESTRICTED 02016_16_05952 1.0 32/159
Concurrency, POSIX, etc).
Software, Hardware,
Production means
PDR, CDR.
PSA_ERSP_SAR_0015-1 The developer shall provide the following security technical and design evidences:
- COTS Vulnerability Report (CVR) for PR milestone,
- Specification & Design Dossier (SDD) for PDR milestone,
- Security Vulnerability Dossier (SVD) for PDR milestone,
- Secure coding guidelines (SCG) for PDR milestone,
and updated for each following reviews.
Assumptions: Document: N/A
As these deliverables contain
valuable functional and security
information which could be used by
Additional info.: a potential attacker or competitor, Family: General Req.
access must be closely monitored.
Refer to A.2 chapter for deeper
details.
Software, Hardware,
Production means
ORR, EIS.
PSA_ERSP_SAR_0016-1 The developer shall provide in the SMDD the list of all actors (including sub-
contractors) involved in security activities with a clear definition of their roles and
responsibilities.
Security teams must be identified at
an early stage of the project.
Organisation chart could also be
Additional info.: provided in order to describe the Family: General Req.
security organization of the project.
The organization must show the
weight of security team and their
C2: RESTRICTED 02016_16_05952 1.0 33/159
related influence on the
development of the product.
Software, Hardware,
Production means
PR, PDR
PSA_ERSP_SAR_0017-1 The developer shall designate a security manager to monitor all the security
activities of the supplier teams and the conformity to the SAR.
The supplier’s security manager
has a role of security officer and is
the security focal point for PSA. The
security officer must have a key
role in the development of the
product.
Software, Hardware,
Production means
PR, PDR
C2: RESTRICTED 02016_16_05952 1.0 34/159
3. Security evaluation
C2: RESTRICTED 02016_16_05952 1.0 35/159
The evaluation process is seen as described below by the Common Criteria standard.
Evaluation
Consumer provides
require Confidence
that
are
Countermeasures Sufficient
and
are Therefore
minimize
Correct Risk
and
Therefore to
minimize
Assets
Figure 2: Evaluation purpose and concepts
3.1. Security part of the product description
This activity aims to describe the Security Part of the Product (SPP). Its description is based on a
security breakdown of the product. The description of the usage and major security
functionalities (SPP-SF) of the SPP is intended to give a very general view of what the SPP is
capable of in terms of security.
The main topics of this description are:
 SPP overview that summarise the usage and major security features of the SPP. It also
identifies any non-SPP hardware, firmware, software required by the SPP.
 SPP physical scope that provides a list of hardware, firmware, and software parts that
constitutes the SPP.
 SPP Logical scope which provides information about security features part of the SPP.
Note: When security assurance is needed in term of robustness with external interface, protection
of sensitive information as Intellectual Properties and assurance of some correct operation (e.g.
robustness of some interfaces). In such case, functionalities in the product contributing to these
objectives should be described in the SPP.
C2: RESTRICTED 02016_16_05952 1.0 36/159
Interfaces to IT entities
Functional calls
Interfaces to human user

SPP-SF (Security Functionalities)
Non-SPP-SF
SPP-SFIs to IT entities SPP (Base Component) Boundary
Functional calls
Non-SPP
SPP: Security Part of the Product
SPP-SF: SPP Security functionalities
SPP-SFI: SPP-SF Interfaces
Product boundary
Figure 3: SPP and SPP-SF overview
PSA_ERSP_SAR_0018-1 The developer shall provide in the SDD a description of the SPP.
O2. To describe major security

features of the SPP. To describe the
Rationale: usage of the SPP. To describe Author: PSA Sec Officer
physical and logical scope of the
SPP.
SPP=Security Part of the Product.
The SPP description discusses the
physical and logical scope of the
SPP: a list of all hardware, firmware,
software and guidance parts that
Additional info.: Family: Security evaluation
constitute the SPP. This list should
be described at a level of detail that
is sufficient to give the reader a
general understanding of those
parts.
Stakeholder: Consumer Sub-family: SPP Description
Imp. Responsible: Developer Monitoring: PDR, CDR
PSA_ERSP_SAR_0019-1 The SPP overview shall summarise the usage and major security features of the
C2: RESTRICTED 02016_16_05952 1.0 37/159
SPP.
The list of the security
Additional info.: functionalities is provided and each Family: Security evaluation
functionality is described.
PSA_ERSP_SAR_0020-1 The SPP overview shall identify and describe any non-SPP hardware / software /
firmware items required by the SPP.
O2.To identifies supporting
functions required by the SPP.
If the SPP does not require any
hardware, software or firmware,
Assumptions: this work unit is not applicable and Document: SDD
therefore considered to be
satisfied.
While some SPP are able to run in a

stand-alone way, other SPP
Additional info.: (especially software ones) need Family: Security evaluation
additional hardware, software or
firmware to operate.

PSA_ERSP_SAR_0021-1 The SPP description shall describe the physical scope of the SPP.

The SPP physical scope and
boundaries have to be described in
term of component and
Additional info.: configuration. It could be a list of Family: Security evaluation
hardware components with their
main configuration. A diagram
could support the discussion.
C2: RESTRICTED 02016_16_05952 1.0 38/159
PSA_ERSP_SAR_0022-1 The SPP description shall describe the logical scope of the SPP.

The SPP logical scope has to be
described in term of security
Additional info.: capabilities and interfaces. A Family: Security evaluation
diagram could also support the
discussion.
3.2. Security problem definition
The objective of this activity is to ensure that the security problem intended to be addressed by
the SPP and its operational environment is clearly defined. The description of the Security Problem
Definition (SPD), should address:
 The assumptions about the SPP and its operational environment.
 The threats scenarios addressed to the SPP and its environment,
o The assets that are vital for the SPP operation,
o The threats sources addressed to the SPP environment,
o The applicable threats to the SPP environment,
 The applicable security policies (It could be organizational or technical rules, procedures,
policies, constraints, guidelines and requirements),
 The Security Objectives for the SPP,
 The Security Objectives for the SPP environment.
 Security Objectives tracing to:
o Threats Scenarios,
o Security policies,
o Assumptions.
C2: RESTRICTED 02016_16_05952 1.0 39/159
Note: The security objectives are a concise statement of the intended response (e.g.:
mitigation) to the security problem defined through the security problem definition.
Evaluation of the security objectives is required to demonstrate that the security objectives
adequately and completely address the security problem definition and the division of this
problem between the SPP and its operational environment is clearly defined.
 Security requirements covering Security Functionalities (mainly technical but could be

organizational)
 The Security Assurance Requirements (SARs) describing the expected activities that will be
undertaken to gain assurance in the SPP.
Threats Scenarios Security Policies Assumptions
Security Security
Objectives for the Objectives for the
TOE TOE environnent
Figure 4: SPD overview
PSA_ERSP_SAR_0023-1 The developer shall provide a Security Problem Definition (SPD) in the Security
Vulnerability Dossier (SVD).
The SPD describe Asset, threats,
threats agents, treats sources,
Additional info.: Family: Security Evaluation
Security policies, assumptions
about operational environment, etc.
Stakeholder: Consumer Sub-family: SPD
The security concepts are seen as described below by the Common Criteria.
C2: RESTRICTED 02016_16_05952 1.0 40/159
Consumers value
wish to minimise
impose
Countermeasures
Risk
to reduce
Threats sources that increase

to
give rise to
Threats Assets
to
Wish to abuse and/or may damage
Figure 5: Security concepts
PSA_ERSP_SAR_0024-1 The security problem definition shall describe the threat scenarios addressed to
the SPP.
Threat scenario characteristics
contain the following items: Source
(attacker with means), attack path,
adverse action, consequence, and
asset (supporting/secondary linked
to essential/primary).
C2: RESTRICTED 02016_16_05952 1.0 41/159
Figure 6: Threat scenarios parameters
PSA_ERSP_SAR_0025-1 All threats scenarios shall be described, at least, in terms of a source (threat
agent with means), attack path, adverse action, consequence and targeted
asset(s).
Source=threat agent with an
expertise level and means.
An attack path is a trail crossing
through physical interfaces (e.g.:
plug, HMI, card reader, etc) by
which the attacker can use to
accomplish a given threat scenario.
Additional info.: Adverse action is the technique Family: Security Evaluation
used to enable the threat by
exploiting vulnerabilities and
satisfying prerequisites.
Consequences on the system could
lead to data corruption, disclosure,
deletion, etc. The related impacts
could be safety, operational,
C2: RESTRICTED 02016_16_05952 1.0 42/159
commercial, etc.
Assets are supporting assets (e.g.:
Hardware, Software, Network)
linked with essential asset (e.g.:
functions, services).
PSA_ERSP_SAR_0026-1 The security problem definition shall describe the Security Policies (SPs) applicable
to the SPP.
SPs are security requirements,
security rules, procedures, or
Additional info.: guidelines imposed by an PSA or Family: Security Evaluation
regulation for the SPP or the
operational environment of the SPP.
Software, Hardware,
Production means
PSA_ERSP_SAR_0027-1 The security problem definition shall describe the assumptions about the
operational environment of the SPP.
Assumptions can be done on any
problematic that could have an
impact on the security problem
Additional info.: definition. It could be related to Family: Security Evaluation
physical environment, threat
agents, technical aspects,
operators, connectivity, etc.
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 43/159
3.3. Security Objectives
The security objectives are a concise statement of the intended response to the security problem
defined through the security problem definition.
Evaluation of the security objectives is required to demonstrate that the security objectives
adequately and completely address the security problem definition and that the division of this
problem between the SPP and its operational environment is clearly defined.
PSA_ERSP_SAR_0028-1 The developer shall provide a statement of security objectives for the SPP and for
the operational environment.
O2. To provide a response to the
security problem
The security objectives adequately
and completely address the security
problem definition and that the
division of this problem between
the SPP and its operational
environment is clearly defined.
Stakeholder: Consumer Sub-family: SO
Software, Hardware,
Production means
PSA_ERSP_SAR_0029-1 The developer shall provide rationales for each security objective.
O2. To justify how the security

objectives cover threats targeting
assets, Organizational Security
policies and Assumptions.
The security objectives rationale
must demonstrate how that the
Additional info.: security objectives cover threats, Family: Security Evaluation
organizational security policy and
assumptions.
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 44/159
PSA_ERSP_SAR_0030-1 The security objectives rationale shall trace and demonstrate that all identified
threats in the SPD are countered and all enforced organisational policies are
enforced.
O2. To justify how the security
objectives cover threats targeting
assets, Organizational Security
policies.
The security objectives rationale
must demonstrate how the security
objectives cover threats,
organizational security policy.
Software, Hardware,
Production means
PSA_ERSP_SAR_0031-1 The security objectives rationale shall be coherent with assumptions about the
security environment and constraints.
Constraints could be technical or
organisational.
Software, Hardware,
Production means
3.4. Security requirements

The Security Functions Requirements (SFRs) form a clear, unambiguous and well-defined description of the
expected security behaviour of the SPP.
The Security Assurance Requirements (SARs) form a clear, unambiguous and well-defined description of the
expected activities that will be undertaken to gain assurance in the SPP.
C2: RESTRICTED 02016_16_05952 1.0 45/159
PSA_ERSP_SAR_0032-1 The developer shall provide a statement of security requirements.

All terms used in security
requirements must be accurately
described. This list of requirement
is derived from consumer’s
Additional info.: requirements. It should be Family: Security Evaluation
functional requirement,
organizational requirements and
applicable Security Assurance
requirements of this document.
Stakeholder: Consumer Sub-family: Sec. Reqs.
Software, Hardware,
Production means
PSA_ERSP_SAR_0033-1 The statement of security requirements shall be internally consistent.
O2. To avoid possible conflict with

other requirements.
The requirement must not be in
conflict with other requirements.
The set of SARs and SFRs must be
also coherent.
Software, Hardware,
Production means
PSA_ERSP_SAR_0034-1 The developer shall provide a security requirement rationale.

Rationale should trace Security
Objectives when relevant.
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 46/159
PSA_ERSP_SAR_0035-1 The developer shall describe in the Security Compliance Dossier (SCD) how he
complies with the SARs of this document.
Additional info.: Refer to SAR compliance matrix. Family: Security Evaluation
Software, Hardware,
Production means
PSA_ERSP_SAR_0036-1 For each supplier providing components part of the SPP, the developer shall
describe their means of compliance with the SARs in the Security Compliance
Dossier (SCD).
The means of compliance have to
Additional info.: be done according to the SARs of a Family: Security Evaluation
given Security Assurance level.
Software, Hardware,
Production means
PSA_ERSP_SAR_0037-1 The security requirements shall trace the security objectives for the SPP.

Assumptions: If relevant. Document: SCD
The traceability between security
requirements and security
objectives must be done. At least
one security requirement shall trace
one security objective.
Failure to trace implies that the
security requirements rationale is
incomplete, the security objectives
for the SPP are incomplete, or the
SFR has no useful purpose.
C2: RESTRICTED 02016_16_05952 1.0 47/159
Software, Hardware,
Production means
3.5. SPP Summary specification

The objective for the SPP summary specification is to provide potential consumers of the SPP with a
description of how the SPP satisfies all the SFRs. The SPP summary specification should provide the general
technical mechanisms that the SPP uses for this purpose. The level of detail of this description should be
enough to enable potential consumers to understand the general form and implementation of the SPP.
PSA_ERSP_SAR_0038-1 The developer shall provide a SPP summary specification.
O2. To describe how the SPP

satisfies all SFRs.
The SPP-SF are describes and a
mapping between SPP functions
and SFRs could easily show how the
SFRs satisfies the SPP functions.
Stakeholder: Consumer Sub-family: SPP Summary Spec.
PSA_ERSP_SAR_0039-1 The SPP summary specification shall describe how the SPP meets each SFR.

The objective of each description is

to provide potential consumers of
the SPP with a high-level view
(narrative form) of how the
developer intends to satisfy each
SFR and that the descriptions
therefore should not be overly
detailed.

C2: RESTRICTED 02016_16_05952 1.0 48/159
PSA_ERSP_SAR_0040-1 The SPP summary specification shall describe how the SPP protects itself against
interference and logical tampering.
The description is done, in a
narrative way, not overly detailed.
The components which provide
Additional info.: protection must be clearly Family: Security Evaluation
identified. In case of combination
of several protections, it must also
be described.
PSA_ERSP_SAR_0041-1 The SPP summary specification shall describe how the SPP protects itself against
bypass.
The description is done, in a
narrative way, not overly detailed.
The components which provide
Additional info.: protection must be clearly Family: Security Evaluation
identified. In case of combination
of several protections, it must also
be described.
C2: RESTRICTED 02016_16_05952 1.0 49/159
4. Lifecycle management of the development
C2: RESTRICTED 02016_16_05952 1.0 50/159
4.1. Lifecycle definition
A life-cycle model encompasses the procedures, tools and techniques used to develop and
maintain the SPP. Aspects of the process that may be covered by such a model include design
methods, review procedures, project management controls, change control procedures, test
methods and acceptance procedures.
PSA_ERSP_SAR_0042-1 The developer shall establish a life-cycle model to be used in the development
and maintenance of the SPP.
Life-cycle model implements
Assumptions: Secure Development Plan Document: VVD
guidelines.
Life-cycle covers all phases of the
Product development from
conception to its end of life:
- Project initiation phase (business,
functional and security needs
gathering, commitments definition,
contract elaboration).
- Project feasibility/concept phase
(law and regulations, standards,
applicable security guides and best
practices gathering, project scope
definition, cost benefits analysis,
security risk management plan,
feasibility study, project planning
elaboration, project management
and documentation plan,
Additional info.: establishment of resources needed Family: Life-cycle management
to conduct development project).
- Definition and design phase
(definition of users, functional and
security requirements based upon
the needs gathered in project
initiation phase, creation of
requirements matrix,
transformation of requirements
into complete detailed Product
design document, security
analysis).
- Development (conversion of
design into a complete Product
version, acquisition, installation of
tests environment, application of
security rules, code and program
C2: RESTRICTED 02016_16_05952 1.0 51/159
refining).
- Tests and integration phase (tests
cases, tests files and tests
procedures definition, test
readiness review, procurement
activities, demonstration that the
Product developed conforms to
users, functional and security
requirements (quality and users
reviews), implementation
preparation, resolution of problems
(e.g. defects) identified during tests
phase).
- Operation and maintenance
(Product documentation delivery,
Product administrators and end-
users training Product final version
secure delivery, Product EIS,
Product administrators and end-
users support, incident and crisis
management, in-process reviews,
bug fixing activities, vulnerability
survey, correctives elaboration and
testing activities).
- Disposition (describes end-of-life
Product activities and how data can
be preserved or reused).
Stakeholder: Consumer Sub-family: Life-cycle Definition
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: PR, PDR
PSA_ERSP_SAR_0043-1 The developer shall provide life-cycle definition documentation.

Additional info.: Family: Life-cycle management
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 52/159
PSA_ERSP_SAR_0044-1 The life-cycle definition documentation shall describe the model used to develop
and maintain the SPP.
Product lifecycle is based on a
continuous amelioration process.
Product life-cycle model is adapted
to fit with consumer needs and
constraints.
The description should include:
- Information about life-cycle
phases and boundaries between
phases.
Additional info.: - Information about procedures, Family: Life-cycle management
tools and techniques used by the
developer for design, coding,
testing, bug-fixing, etc.
- Security governance (processes,
procedures, responsibilities related
to development and maintenance of
the SPP)
- Part of the SPP delivered by sub-
contractors if any.
Software, Hardware,
Production means
PSA_ERSP_SAR_0045-1 The life-cycle model shall address the needs of control over the development and
maintenance of the SPP.
The life-cycle model must provide
features allowing to handle security
management (e.g. flaw
remediation, vulnerability
management, change management,
crisis management, etc)
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 53/159
4.2. Configuration management
Configuration management (CM) is one means for increasing assurance that the SPP meets the
SFRs. CM establishes this by requiring discipline and control in the processes of refinement and
modification of the SPP and the related information.
According to the Security Assurance Level the required Configuration management capabilities
and scope will increase.
4.2.1. Configuration management capabilities
It is required that the developer's Configuration management system have certain capabilities with
the goal to reduce the likelihood that accidental or unauthorised modifications of the
configuration items will occur.
PSA_ERSP_SAR_0046-1 The developer shall provide the SPP and a reference of the SPP.
Rationale: O1. Author: Sec Officer

Configuration management
Stakeholder: Consumer Sub-family:
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0047-1 The SPP shall be labelled with its unique reference.

The SPP may provide a method by
which it can be easily identified. For
example, software SPP may display
its name and version number
Additional info.: during the start-up routine, or in Family: Life-cycle management
response to a command line entry.
A hardware or firmware SPP may be
identified by a part number
physically stamped on the SPP.
C2: RESTRICTED 02016_16_05952 1.0 54/159
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0048-1 The developer shall provide the Configuration Management documentation in the
Configuration and Change Management Dossier (CCMD).
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0049-1 The developer shall use a Configuration Management system.
O3, O4. CM system less susceptible

Rationale: Author: Sec Officer
to human error or negligence.
The CM system selection should be
evaluated according to its
capabilities to manage security (e.g.
access control, integrity control,
confidentiality, capability to cover
SAR).
capabilities
Software, Hardware,
Production means
ORR, EIS
C2: RESTRICTED 02016_16_05952 1.0 55/159
PSA_ERSP_SAR_0050-1 The Configuration Management system shall uniquely identify all configuration
items.
Rationale: O2, O3, O4. Author: Sec Officer
The method of identifying the
configuration items should describe
how configuration items are
uniquely identified.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0051-1 The Configuration Management documentation shall describe the method used to
uniquely identify the configuration items.
O2. CM system less susceptible to
human error or negligence.
Procedures should describe how
the status of each configuration
item can be tracked throughout the
life-cycle of the SPP. The
procedures may be detailed in the
Configuration Management (CM)
plan or throughout the CM
documentation. The information
included should describe: a) the
method how each configuration
item is uniquely identified, such
that it is possible to track versions
of the same configuration item; b)
the method how configuration
items are assigned unique
identifiers and how they are
entered into the CM system; c) the
method to be used to identify
superseded versions of a
configuration item.
capabilities
Source: PSA Sec Officer Applicability: Software, Hardware,
C2: RESTRICTED 02016_16_05952 1.0 56/159
Production means
ORR, EIS
PSA_ERSP_SAR_0052-1 The Configuration Management system shall provide measures such that only
authorized changes are made to the configuration items.
Rationale: O3, O4. Author: Sec Officer
The CM access control
measures described in the CM
plan preventing unauthorized
access to the configuration
items will contribute to fulfil
this requirement. The CM
access control measures must
be effective. The CM access
control measures must not be
bypassed.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0053-1 The Configuration Management documentation shall include a Configuration

Management plan.
Refer to Configuration
Management plan description.
capabilities
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 57/159
ORR, EIS
PSA_ERSP_SAR_0054-1 The Configuration Management plan shall describe how the Configuration
Management system is used for the development of the SPP.
The descriptions contained in a CM
plan include:
- all activities performed in the SPP
development that are subject to
configuration management
procedures (e.g. creation,
modification or deletion of a
configuration item, data-backup,
archiving),
- which means (e.g. tools) have to
be made available,
- usage of tools,
- which objects are taken under
control of CM (dev components,
tools, COTS, design documentation,
source code, etc),
- role and responsibilities of users
performing actions on
configuration items
- CM instances staffing,
- description of the change
management,
- the procedures that are used to
ensure that only authorized
individuals can make changes to
configuration items,
- the procedures that are used to
ensure that concurrency problems
do not occur as a result of
simultaneous changes to
configuration items,
- the evidence that is generated as
a result of application of the
procedures (e.g. records of
description of the change,
configurations items involved by
the change, date and time, user
who has performed the change,
C2: RESTRICTED 02016_16_05952 1.0 58/159
status of the change(pending or
completed)),
- how to control the version and
apply a unique referencing of the
SPP version.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0055-1 The evidence of CM system integration in the development shall demonstrate that
all configuration items are being maintained under the Configuration
Management system.
The Configuration Management
system employed by the developer
should maintain the integrity of the
SPP. The developer should ensure
that for each type of configuration
item (e.g. design documents or
source code modules) contained in
the configuration list there are
examples of the evidence
generated by the procedures
described in the Configuration
Management plan.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0056-1 The evidence of CM system integration in the development shall demonstrate that
the Configuration Management system is being operated in accordance with the
Configuration Management plan.
C2: RESTRICTED 02016_16_05952 1.0 59/159
The output produced by the CM
system should provide the evidence
ensuring that the CM plan is being
applied, and also that all
configuration items are being
maintained by the CM system.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0057-1 The Configuration Management system shall provide automated measures such
that only authorized changes are made to the configuration items.
The CM access control measures
described in the CM plan
preventing unauthorized access to
the configuration items will
Additional info.: contribute to fulfil this Family: Life-cycle management
requirement. The CM access control
measures must be effective. The
CM access control measures must
not be bypassed.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0058-1 The Configuration Management system shall support the production of the SPP by
automated means.
The term “production” applies to
those processes adopted by the
C2: RESTRICTED 02016_16_05952 1.0 60/159
developer to progress the SPP from
the implementation representation
to a state acceptable for delivery to
the end customer.
In the case of a software,
automated means supporting the
production of the SPP could be a
“make” tool (as provided with many
software development tools);
The production support
procedures, in a clearly defined
way, should describe which tools
have to be used to produce the
final SPP from the implementation
representation.
In case of software SPP the
automated production procedures
ensure that all source files and
related libraries are included in the
compiled object code. Moreover,
the procedures should ensure that
compiler options and comparable
other options are defined uniquely.
For hardware SPP, the automatic
production procedures ensure that
the belonging parts are built
together and no parts are missing.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0059-1 The Configuration Management plan shall describe the procedures used to accept
modified or newly created configuration items as part of the SPP.
The descriptions of the acceptance
procedures in the CM plan should
include the developer roles or
individuals responsible for the
acceptance and the criteria to be
used for acceptance. They should
C2: RESTRICTED 02016_16_05952 1.0 61/159
take into account all acceptance
situations that may occur, in
particular: a) accepting an item into
the CM system for the first time, in
particular inclusion of software,
firmware and hardware
components from other
manufacturers into the SPP
(“integration”); b) moving
configuration items to the next
life-cycle phase at each stage of
the construction of the SPP (e.g.
module, subsystem, system); c)
subsequent to transports between
different development sites.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0060-1 The Configuration Management documentation shall justify that the acceptance
procedures provide for an adequate and appropriate review of changes to all
configuration items.
The CM documentation should
make it sufficiently clear that by
following the acceptance
procedures only parts of adequate
quality are incorporated into the
SPP.
capabilities
Software, Hardware,
Production means
ORR, EIS
C2: RESTRICTED 02016_16_05952 1.0 62/159
PSA_ERSP_SAR_0061-1 The Configuration Management system shall ensure that the person responsible
for accepting a configuration item into Configuration Management is not the
person who developed it.
The acceptance procedures

describe who is responsible for
accepting a configuration item. The
person who developed a
configuration item is in no case
responsible for its acceptance.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0062-1 The Configuration Management system shall identify the configuration items that
comprise the SPP-SF.
describe how the CM system
identifies the configuration items
that comprise the SPP-SF.
Configuration items covering
containing SPP-SF and non-SPP-SF
items should be correctly classified
by the CM system.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0063-1 The Configuration Management system shall support the audit of all changes to
the SPP by automated means, including the originator, date, and time.
C2: RESTRICTED 02016_16_05952 1.0 63/159
Audit deal with event detection,
logs and storage.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0064-1 The Configuration Management system shall provide an automated means to

identify all other configuration items that are affected by the change of a given
configuration item.
The CM system identifies all other
configuration items that are
affected by the change of a given
configuration item.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0065-1 The Configuration Management system shall be able to identify the version of the
implementation representation from which the SPP is generated.
describe how the CM system
Additional info.: identifies the version of the Family: Life-cycle management
implementation representation
from which the SPP is generated.
capabilities
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 64/159
ORR, EIS
PSA_ERSP_SAR_0066-1 The developer shall verify that any code addition or modification is documented
and is linked to a change request.
Change management process is
Additional info.: defined in Configuration Family: Life-cycle management
Management Plan.
capabilities
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0067-1 The developer shall verify that the source code is compliant with the description
of the code addition or modification.
Refer to the Configuration
Management Plan.
capabilities
Software, Hardware,
Production means
ORR, EIS
4.2.2. Configuration management Scope
The objective of Configuration Management scope is to identify items to be included as

configuration items and hence placed under the Configuration Management requirements of
Configuration Management capabilities. Applying configuration management to these additional
items provides additional assurance that the integrity of SPP is maintained.
PSA_ERSP_SAR_0068-1 The developer shall provide a configuration list for the SPP in the Configuration
and Change Management Dossier (CCMD).
C2: RESTRICTED 02016_16_05952 1.0 65/159
Configuration items could be
Additional info.: documents or source code Family: Life-cycle management
modules.
scope
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0069-1 The configuration list shall uniquely identify the configuration items

The configuration list contains

sufficient information to uniquely
Additional info.: identify which version of each item Family: Life-cycle management
has been used (typically a version
number).
scope
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0070-1 The configuration list shall include the following: the SPP itself; and the evaluation
evidence required by the SARs.
scope
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: PR, PDR, CDR, TRR, SAR,
C2: RESTRICTED 02016_16_05952 1.0 66/159
ORR, EIS
PSA_ERSP_SAR_0071-1 For each SPP-SF relevant configuration item, the configuration list shall indicate
the developer of the item.
If only one developer is involved in

the development of the TOE, this
Assumptions: task is not applicable, and is Document: CCMD
therefore considered to be
satisfied.

scope
Software, Hardware,
Production means
ORR, EIS
PSA_ERSP_SAR_0072-1 The configuration list shall include the following: the SPP itself; the evaluation
evidence required by the SARs; and the parts that comprise the SPP.
scope
Software, Hardware,
Production means
ORR, EIS
evidence required by the SARs; the parts that comprise the SPP and the
implementation representation.
scope
C2: RESTRICTED 02016_16_05952 1.0 67/159
Software, Hardware,
Production means
ORR, EIS
evidence required by the SARs; the parts that comprise the SPP; and security flaw
reports and resolution status.
scope
Software, Hardware,
Production means
ORR, EIS
evidence required by the SARs; the parts that comprise the SPP; the
implementation representation; security flaw reports and resolution status; and
development tools and related information.
scope
Software, Hardware,
Production means
ORR, EIS
4.3. Tools and techniques for development
Tools and techniques is an aspect of selecting tools that are used to develop, analyse and
implement the SPP. It includes requirements to prevent inaccurate, inconsistent or incorrect
development tools from being used to develop the SPP. This includes, but is not limited to,
C2: RESTRICTED 02016_16_05952 1.0 68/159
programming languages, documentation, implementation standards, and other parts of the SPP
such as supporting runtime libraries.
PSA_ERSP_SAR_0076-1 The developer shall provide in the Security Management and Development
Dossier (SMDD) the documentation identifying each development tool being used
for the SPP.
O1, O3, O4. To assess development
means (e.g. tools) and methods.
Stakeholder: Consumer Sub-family: Tools & Tech.
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: PR, PDR, CDR
PSA_ERSP_SAR_0077-1 The developer shall identify and describe in the Security Management and
Development Dossier (SMDD) all development tools that can impact the
embedded code of the SPP.
Description should comprise at
least the following information:
COTS name, Editor, Vendor (if
different from editor), Version
number, List of patches applied (if
any), List of patches not applied
(and the reason why it was not
applied), the delivery procedure, the
updating procedure, the associated
documents which defined the
selected implementation-dependent
tools options, the choice
justification, the developer control
level, the exposure level.
Software, Hardware,
Production means
PSA_ERSP_SAR_0078-1 The developer shall analyse and justify in the COTS Vulnerability Report (CVR) all
development tools used that can impact the embedded code of the SPP.
C2: RESTRICTED 02016_16_05952 1.0 69/159
O3, O4. The tools exposed to
Rationale: Public known vulnerabilities have to Author: Sec Officer
be identified and analysed.
The analysis must justify how the
development tools could impact or
not the embedded code. It could be
compiler that could affect directly
the code or testing tools that could
misrepresent the result of a test.
Software, Hardware,
Production means
PSA_ERSP_SAR_0079-1 The developer shall provide and document and provide in the Security
Management and Development Dossier (SMDD) the selected implementation
dependent options of each development tool.
The development tools
documentation should include
definitions of implementation-
dependent options that may affect
the meaning of the executable
code, and those that are different
from the standard language as
documented. Where source code is
provided to the evaluator,
information should also be
provided on compilation and
linking options used.
Software, Hardware,
Production means
PSA_ERSP_SAR_0080-1 Each development tool used for implementation shall be well-defined.

C2: RESTRICTED 02016_16_05952 1.0 70/159
The objective is to determine
whether the developer has used a
well-defined development tools
that yield consistent and
predictable results, and whether
implementation standards have
been applied. Well-defined
development tools are clearly and
completely described.
For example, programming
languages and computer aided
design (CAD) systems that are
based on a standard published by
standards bodies are considered to
be well-defined. Self-made tools
would need further investigation to
clarify whether they are well-
defined.
Software, Hardware,
Production means
PSA_ERSP_SAR_0081-1 The documentation of each development tool shall unambiguously define the
meaning of all statements as well as all conventions and directives used in the
implementation.
The development tool
documentation (e.g. programming
language specifications and user
manuals) should cover all
statements used in the
implementation representation of
the SPP, and for each statement
should provide a clear and
unambiguous definition of the
purpose and effect of that
statement.
The development tool
documentation should define all
conventions and directives used in
the implementation.
The following approach could be
C2: RESTRICTED 02016_16_05952 1.0 71/159
used for searching problems:
- In the language definition,
phrases such as “the effect of this
construct is undefined” and terms
such as “implementation
dependent” or “erroneous” may
indicate ill-defined areas.
- Aliasing (allowing the same piece
of memory to be referenced in
different ways) is a common source
of ambiguity problems.
- Exception handling (e.g. what
happens after memory exhaustion
or stack overflow) is often poorly
defined.
Software, Hardware,
Production means
PSA_ERSP_SAR_0082-1 The documentation of each development tool shall unambiguously define the
meaning of all implementation-dependent options.
The documentation of software
development tools should include
definitions of implementation-
dependent options that may affect
the meaning of the executable
code, and those that are different
from the standard language as
documented. Where source code is
provided to the evaluator,
information should also be
provided on compilation and
linking options used. The
documentation for hardware design
and development tools should
describe the use of all options that
can affect the output from the tools
(e.g. detailed hardware
specifications, or actual hardware).
C2: RESTRICTED 02016_16_05952 1.0 72/159
Software, Hardware,
Production means
PSA_ERSP_SAR_0083-1 The developer shall provide and describe and provide the implementation
standards that are being applied by the developer of the SPP.
Assumptions: Document: SMDD, SCG
The standard references are listed
in the SMDD. The SCG contain the
secure coding rules applicable for
the product development.
The evaluator will examine aspects
of the implementation process to
determine that documented
been applied.
Constructs excluded by the
documented standard should not
be used or if any duly justified.
Software, Hardware,
Production means
PSA_ERSP_SAR_0084-1 The developer shall provide and describe and provide the implementation
standards that are being applied by the developer and by any third-party
providers for all parts of the SPP.
Assumptions: Document: SMDD, SCG
The standard references are listed
in the SMDD. The SCG contain the
secure coding rules applicable for
the product development.
The evaluator will examine aspects
of the implementation process to
determine that documented
been applied.
Constructs excluded by the
C2: RESTRICTED 02016_16_05952 1.0 73/159
documented standard should not
be used or if any duly justified.
Software, Hardware,
Production means
4.4. COTS
COTS are potential sources of vulnerabilities for the SPP and consequently must be fully controlled
by the security assurance process.
PSA_ERSP_SAR_0085-1 The developer shall identify and describe the COTS (modified or not) that are
embedded in the SPP.
Additional info.: COTS name, Editor, Vendor (if Family: Life-cycle management
number.
Stakeholder: Consumer Sub-family: Embedded COTS
Software, Hardware,
Production means
PSA_ERSP_SAR_0086-1 The developer shall identify the COTS (modified or not) that are used in the
development environment having possibly an impact on the SPP.
COTS name, Editor, Vendor (if
number, List of patches applied (if
Additional info.: any), List of patches not applied Family: Life-cycle management
(and the reason why it was not
applied), the delivery procedure,
the updating procedure, the
associated documents which
defined the selected
C2: RESTRICTED 02016_16_05952 1.0 74/159
implementation-dependent tools
options, the choice justification, the
developer control level, the
exposure level.
Software, Hardware,
Production means
PSA_ERSP_SAR_0087-1 The developer shall justify the selection of the COTS according to consumer’s
security evaluation policies.
COTS Evaluation policies guidance
must be followed by the developer.
Software, Hardware,
Production means
PSA_ERSP_SAR_0088-1 The developer shall demonstrate in the COTS Vulnerability Report (CVR) that the
editors of embedded COTS and provided components have a sufficient confidence
level about the security management and the risks of [malicious
code]/[vulnerabilities] inclusion in the SPP.
Key review items are vulnerabilities,
Malicious code, ability to apply
Additional info.: correction, control of the source Family: Life-cycle management
code, delivery procedures, attack
exposure, security survey, etc.
Software, Hardware,
Production means
PSA_ERSP_SAR_0089-1 The developer shall manage SPP embedded COTS under Configuration
C2: RESTRICTED 02016_16_05952 1.0 75/159
Management System.
Refer to configuration management
requirements.
Software, Hardware,
Production means
PSA_ERSP_SAR_0090-1 The developer shall have the capability to modify all embedded COTS during the
whole product life-cycle.
Embedded COTS suppliers have a
defined life-cycle for their products
and provide bug fixing or security
correctives all along the lifetime of
embedded COTS. The capability to
modify embedded COTS during the
whole product life-cycle could be
agreed in a contract.
Software, Hardware,
Production means
PSA_ERSP_SAR_0091-1 The developer shall ensure that the COTS supplier apply a “well defined” security
process minimizing the likelihood that delivered COTS contain any known
applicable vulnerabilities with a potential security impact on the SPP.
“Well defined” should be assessed
Additional info.: according to PSA vulnerabilities Family: Life-cycle management
management policies.
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 76/159
4.5. Security Survey
Security survey procedures describe how to detect new vulnerabilities and modifications of
existing vulnerabilities of the equipment during the whole life cycle of the SPP. The scope of the
security survey encompasses the embedded components and also related development tools
(including testing tools). The security survey process could also be cascaded to third parties
suppliers, in such case dedicated agreement could be required.
PSA_ERSP_SAR_0092-1 The developer shall implement a security survey process.
O3, O4. To detect new applicable

public known vulnerabilities or
modifications of existing public
known vulnerabilities.
The security survey process should
describe how the COTS
vulnerabilities will be followed and
how they will be managed by the
developer and/or the supplier.
The process should include the
following activities:
1 – A security survey strategy is
defined for the overall activity (e.g.
approach, means, etc) and for each
COTS. The strategy implies the
stakeholders and the actors, the
period of survey, the frequency of
survey, the method and tools, the
organisation in charge, etc.
2 – A vulnerability analysis and
assessment process is performed.
The security team should realize
the following activities:
- Apply the chosen method
of security survey in order to find
new vulnerabilities,
- Perform an assessment of
the vulnerabilities, then a review of
vulnerabilities to be patched with
teams impacted by the change,
- Assess the update of the
COTS.
3 – An acceptance review process
is defined implying the relevant
C2: RESTRICTED 02016_16_05952 1.0 77/159
actors in order to validate the
vulnerabilities treatment (e.g.
patched or not patched).
Stakeholder: Consumer Sub-family: Security Survey.
Software, Hardware,
Production means
PSA_ERSP_SAR_0093-1 In the Security Management and Development Dossier (SMDD), the Developer
shall describe the security survey procedures related to COTS (modified or not) or
of its own code that are embedded in the SPP.
Developer own code should be
followed in term of coding practice.
Additional info.: Over the time it has been Family: Life-cycle management
discovered that some coding
practices were unsecure.
Software, Hardware,
Production means
PSA_ERSP_SAR_0094-1 The developer shall survey vulnerabilities (public) of COTS (modified or not) or of
its own code, that are embedded in the SPP.
Scope: Version of COTS higher than
current version (limited to the same
Additional info.: branch), and on current version. Family: Life-cycle management
The period of survey has to be
defined (e.g.: Before and after EIS)
Software, Hardware,
Production means
ORR, EIS, POST EIS.
C2: RESTRICTED 02016_16_05952 1.0 78/159
PSA_ERSP_SAR_0095-1 The developer shall describe in the Security Management and Development
Dossier (SMDD) the security survey procedures related to all development tools
that can impact the embedded code of the SPP.
O1, O2, O3, O4. To monitor new
applicable vulnerabilities or
Rationale: modifications of existing Public Author: Sec Officer
known vulnerabilities. Development
tools include testing tools.
Software, Hardware,
Production means
PSA_ERSP_SAR_0096-1 The developer shall survey vulnerabilities (public) on versions of development

tools impacting the embedded code of the equipment, and used for the project.
O1, O2, O3, O4. To monitor new
applicable vulnerabilities or
modifications of existing Public
known vulnerabilities.
Scope: Version of COTS higher than
current version (limited to the same
Additional info.: branch), and on current version. Family: Life-cycle management
The period of survey has to be
defined (e.g.: Before and after EIS).
Software, Hardware,
Production means
ORR, EIS, POST EIS.
PSA_ERSP_SAR_0097-1 The developer shall survey security vulnerabilities (public) during an agreed
period with the consumer.
O3, O4. The developer must be
Rationale: involved in the security survey Author: Sec Officer
process.
Assumptions: Document: SMDD, VVD
Additional info.: The period of survey could cover Family: Life-cycle management
C2: RESTRICTED 02016_16_05952 1.0 79/159
the product life-cycle or a part of
it.
Software, Hardware,
Production means
PSA_ERSP_SAR_0098-1 The developer shall ensure that all parts of the SPP-SF are covered by a security
survey process during an agreed period.
Assumptions: Document: SMDD, VVD
Third parties suppliers could be
Additional info.: involved in security survey Family: Life-cycle management
procedures.
Software, Hardware,
Production means
PSA_ERSP_SAR_0099-1 The developer shall document security survey outcomes in the Security
Vulnerability Dossier (SVD) and in the Security Compliance Dossier (SCD).
Assumptions: Document: SVD, SCD
Software, Hardware,
Production means
PR, PDR PR, PDR, CDR, TRR,
SAR, ORR, EIS, POST EIS.
Flaw remediation requires that discovered security flaws be tracked and corrected by the
developer. Although future compliance with flaw remediation procedures cannot be determined at
the time of the SPP evaluation, it is possible to evaluate the policies and procedures that a
developer has in place to track and correct flaws, and to distribute the flaw information and
corrections.
C2: RESTRICTED 02016_16_05952 1.0 80/159
PSA_ERSP_SAR_0100-1 The developer shall document the flaw remediation process in the Security
Management and Development Dossier (SMDD).
Stakeholder: Consumer Sub-family: Flaw remediation process.
Software, Hardware,
Production means
PSA_ERSP_SAR_0101-1 The developer shall provide flaw remediation procedures addressed to SPP
developers.
O3, O5, O6. To manage and
remediate security flaws.
Software, Hardware,
Production means
PSA_ERSP_SAR_0102-1 The flaw remediation procedures documentation shall describe the procedures
used to track all reported security flaws in each release of the SPP.
The procedures describe the
actions that are taken by the
developer from the time each
suspected security flaw is reported
to the time that it is resolved. This
Additional info.: includes the flaw's entire time Family: Life-cycle management
frame, from initial detection
through establishing that the flaw
is a security flaw, to resolution of
the security flaw. If a flaw is
discovered not to be security-
C2: RESTRICTED 02016_16_05952 1.0 81/159
relevant, there is no need for the
flaw remediation procedures to
track it further; only an explanation
of why the flaw is not security-
relevant is required.
Software, Hardware,
Production means
PSA_ERSP_SAR_0103-1 The flaw remediation procedures shall require that a description of the nature and
effect of each security flaw be provided, as well as the status of finding a
correction to that flaw.
The procedures identify the actions

that are taken by the developer to
describe the nature and effects of
each security flaw in sufficient
detail to be able to reproduce it.
The description of the nature of a
security flaw addresses whether it
is an error in the documentation, a
flaw in the design of the SPP-SF, a
flaw in the implementation of the
SPP-SF SF, etc. The description of
the security flaw's effects identifies
the portions of the SPP-SF SF that
are affected and how those
portions are affected. For example,
a security flaw in the
implementation might be found
that affects the identification and
authentication enforced by the SPP-
SF by permitting authentication
with the password “BACK DOOR”.
The flaw remediation procedures

identify the different stages of
security flaws. This differentiation
includes at least: suspected
security flaws that have been
reported, suspected security flaws
that have been confirmed to be
C2: RESTRICTED 02016_16_05952 1.0 82/159
security flaws, and security flaws
whose solutions have been
implemented. It is permissible that
additional stages (e.g. flaws that
have been reported but not yet
investigated, flaws that are under
investigation, security flaws for
which a solution has been found
but not yet implemented) be
included.
Software, Hardware,
Production means
PSA_ERSP_SAR_0104-1 The flaw remediation procedures shall require that corrective or workaround
actions be identified for each of the security flaws.
Corrective action may consist of a
repair to the hardware, firmware, or
Additional info.: software portions of the SPP, a Family: Life-cycle management
modification of SPP guidance, or
both.
Software, Hardware,
Production means
PSA_ERSP_SAR_0105-1 The flaw remediation procedures documentation shall describe the methods used
to provide flaw information, corrections and guidance on corrective actions to SPP
users.
The necessary information about
each security flaw consists of its
description, the prescribed
corrective action, and any
associated guidance on
implementing the correction.
C2: RESTRICTED 02016_16_05952 1.0 83/159
Software, Hardware,
Production means
PSA_ERSP_SAR_0106-1 The developer shall establish a procedure for accepting and acting upon all
reports of security flaws and requests for corrections to those flaws.
Software, Hardware,
Production means
PSA_ERSP_SAR_0107-1 The developer shall provide flaw remediation guidance addressed to SPP users.

Software, Hardware,
Production means
PSA_ERSP_SAR_0108-1 The flaw remediation procedures shall describe means by which the developer
receives from SPP users reports and enquiries of suspected security flaws in the
SPP.
Rationale: O3. To manage security flaws. Author: Sec Officer
The procedures ensure that SPP
users have means by which they
can communicate with the SPP
developer. By having means of
contact with the developer, the user
can report security flaws, enquire
about the status of security flaws,
or request corrections to flaws.
C2: RESTRICTED 02016_16_05952 1.0 84/159
This means of contact may be part
of a more general contact facility
for reporting non-security related
problems.
Software, Hardware,
Production means
PSA_ERSP_SAR_0109-1 The procedures for processing reported security flaws shall ensure that any
reported flaws are remediated and the remediation procedures issued to SPP
users.
Rationale: O6. To report security flaws. Author: Sec Officer
The flaw remediation procedures
cover not only those security flaws
discovered and reported by
developer personnel, but also those
reported by SPP users. The
procedures are sufficiently detailed
so that they describe how each
reported security flaw is corrected.
Software, Hardware,
Production means
PSA_ERSP_SAR_0110-1 The procedures for processing reported security flaws shall provide safeguards
that any corrections to these security flaws do not introduce any new flaws.
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 85/159
PSA_ERSP_SAR_0111-1 The flaw remediation guidance shall describe means by which SPP users report to
the developer any suspected security flaws in the SPP.
Software, Hardware,
Production means
PSA_ERSP_SAR_0112-1 The flaw remediation procedures shall include a procedure requiring timely
response and the automatic distribution of security flaw reports and the
associated corrections to registered users who might be affected by the security
flaw.
Rationale: O6. To report security flaws. Author: Sec Officer
Note: the flaw remediation
procedures for zero-day security
flaws could require specific
response. Zero-day attacks happen
during the vulnerability window
that exists in the time between
when vulnerability is first exploited
and when software developers
finish developing and publishing a
patch to that threat.
Software, Hardware,
Production means
PSA_ERSP_SAR_0113-1 The flaw remediation guidance shall describe means by which SPP users may
register with the developer, to be eligible to receive security flaw reports and
corrections.
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 86/159
PSA_ERSP_SAR_0114-1 The flaw remediation guidance shall identify the specific points of contact for all
reports and enquiries about security issues involving the SPP.
Software, Hardware,
Production means
4.7. Delivery and acquisition
4.7.1. Delivery
The concern of delivery is the secure transfer of the finished SPP from the development
environment into the responsibility of the user. The delivery procedures should consider, if
applicable, issues such as:
 ensuring that the SPP received by the consumer corresponds precisely to the evaluated
version of the SPP;
 avoiding or detecting any tampering with the actual version of the SPP;
 preventing submission of a false version of the SPP;
 avoiding unwanted knowledge of distribution of the SPP to the consumer: there might be
cases where potential attackers should not know when and how it is delivered;
 avoiding or detecting the SPP being intercepted during delivery; and
 avoiding the SPP being delayed or stopped during distribution.
The delivery procedures should include the recipient's actions implied by these issues. The
consistent description of these implied actions is examined in the Preparative procedures (refer to
Guidance chapter).
PSA_ERSP_SAR_0115-1 The developer shall document procedures for delivery of the SPP or parts of it to
the consumer.
Additional info.: The delivery documentation Family: Life-cycle management
C2: RESTRICTED 02016_16_05952 1.0 87/159
describes proper procedures to
maintain security of the SPP during
transfer to the consumer.
The delivery procedures should be
applicable across all phases of
delivery from the production
environment to the installation
environment (e.g. packaging,
storage and distribution).
Delivery & Acquisition -
Delivery
Software, Hardware,
Production means
PSA_ERSP_SAR_0116-1 The developer shall use the delivery procedures.

Appropriate procedures are in place
for delivery and all personnel
involved are aware of their
responsibilities.
Delivery
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: SAR, ORR, EIS.
PSA_ERSP_SAR_0117-1 The delivery documentation shall describe all procedures that are necessary to
maintain security when distributing versions of the SPP to the consumer.
The delivery documentation should
cover the entire SPP.
Interpretation of the term
“necessary to maintain security” will
need to consider:
- The nature of the SPP (e.g.
Hardware, Software, other)
- The threats addressed to the SPP
C2: RESTRICTED 02016_16_05952 1.0 88/159
- The security Objectives.
Delivery
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: CDR, TRR, SAR, ORR, EIS.
PSA_ERSP_SAR_0118-1 The delivery procedures shall guarantee the availability, integrity, confidentiality
and non-repudiation of the SPP.
Cryptographic checksums or a
software signature may be used by
the developer to ensure that
tampering or masquerading can be
detected. Tamper proof seals
additionally indicate if the
confidentiality has been broken. For
software SPPs, confidentiality might
be assured by using encryption. If
availability is of concern, a secure
transportation might be required.
Additional info.: Non-repudiation could be used to Family: Life-cycle management
guarantee the authenticity of the
SPP by providing evidence related
to SPP transfer transaction. Non-
repudiation of origin ensures that
the originator of information
cannot successfully deny having
sent the information. Non-
repudiation of receipt ensures that
the recipient of information cannot
successfully deny having received
the information.
Delivery
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: CDR, TRR, SAR, ORR, EIS.
C2: RESTRICTED 02016_16_05952 1.0 89/159
4.7.1. Acquisition
PSA_ERSP_SAR_0119-1 The developer shall document procedures for the acquisition of parts of the SPP
from potential suppliers.
Acquisition
Software, Hardware,
Production means
PSA_ERSP_SAR_0120-1 The developer shall use the acquisition procedures.

Appropriate procedures are in place
for the acquisition and all
personnel involved are aware of
their responsibilities.
Acquisition
Software, Hardware,
Production means
PSA_ERSP_SAR_0121-1 The developer shall ensure that COTS suppliers guarantee integrity, non-
disclosure and non-repudiation of delivered COTS, including in any hardware
and/or software with possible impact on the SPP.
Non-disclosure could be required
Assumptions: for specific items. (e.g. Intellectual Document: SMDD
Property protection).
Applicable to embedded COTS,
Additional info.: development tools, testing tools, Family: Life-cycle management
etc.
Acquisition
Source: PSA Sec Officer Applicability: Software, Hardware,
C2: RESTRICTED 02016_16_05952 1.0 90/159
Production means
4.8. Security of the development environment
Development security is concerned with physical, procedural, personnel, and other security
measures that may be used in the development and maintenance environment to protect the SPP
and its parts. It includes the physical and logical security of the development/maintenance
locations and any related procedures.
PSA_ERSP_SAR_0122-1 The developer shall produce and provide, in the Security Vulnerability Dossier
(SVD), the documentation related to the security of the development environment.
Rationale: O1, O2, O3, O4. Author: Sec Officer
Stakeholder: Consumer Sub-family: Development Security
Software, Hardware,
Production means
PSA_ERSP_SAR_0123-1 The Security Vulnerability Dossier (SVD) shall describe all the physical, procedural,
personnel, and other security measures that are necessary to protect the
availability, integrity and confidentiality of the SPP in its development and
maintenance environment.
Refer to ISO 27002 security
measures. The main chapters are:
- Actors and responsibilities
- Information security policies
- Organization of information
security
- Human resource security
Additional info.: - Asset management (e.g. Asset of Family: Life-cycle management
the project)
- Access control
- Cryptography
- Physical and environmental
security
- Operations security
- Communications security
C2: RESTRICTED 02016_16_05952 1.0 91/159
- System acquisition, development
and maintenance
- Supplier relationships
- Information security incident
management
- Information security aspects of
business continuity management
- Compliance
Software, Hardware,
Production means
PSA_ERSP_SAR_0124-1 The Security Vulnerability Dossier (SVD) shall justify that the security measures
provide the necessary level of protection to maintain the availability, integrity and
confidentiality of the SPP.
Since attacks on the SPP or its
related information are identified in
different stages of the security
Additional info.: activities, measures and procedures Family: Life-cycle management
need to have an appropriate level
necessary to prevent those attacks
or to make them more difficult.
Software, Hardware,
Production means
C2: RESTRICTED 02016_16_05952 1.0 92/159
5. Development
C2: RESTRICTED 02016_16_05952 1.0 93/159
The Development activities encompass families of requirements for structuring and representing
the SPP-SF at various levels and varying forms of abstraction. These families include:
 requirements for the description of the architecture-oriented features of domain

separation, SPP-SF self-protection and non-bypassability,
 requirements for the functional specification description,
 requirements on the internal structure of the SPP-SF, which covers aspects such as
modularity, layering, and reduction of complexity,
 requirements for the description of the design and implementation of the SFRs.
When documenting the security functionality of a SPP, there are two properties that need to be
demonstrated:
 The first property is that the security functionality works correctly; that is, it performs as
specified.
 The second property, and one that is arguably harder to demonstrate, is that the SPP
cannot be used in a way such that the security functionality can be corrupted or bypassed.
These two properties require somewhat different approaches in analysis, and so the families in
Development are structured to support these different approaches.
The families’ Functional specification, SPP design and Implementation representation deal with the
first property: the specification of the security functionality.
The families Security Architecture and SPP-SF Internal Structure deal with the second property: the
specification of the design of the SPP demonstrating that the security functionality cannot be
corrupted or bypassed.
It should be noted that both properties need to be realized: the more confidence one has that the
properties are satisfied, the more trustworthy the SPP is.
Product Security
(Security Problem Objectives
Definition)
Functional Functional Implementation

Design description representation Implementation
Requirements specification
Figure 7: Development steps
C2: RESTRICTED 02016_16_05952 1.0 94/159
5.1. Security architecture
The main properties of the product security architecture are:
 Domain separation which property is whereby the SPP-SF creates separate security domains for each
untrusted active entity to operate on its resources, and then keeps those domains separated from
one another so that no entity can run in the domain of any other.
Security domain separation principle is to prevent the security functions from being bypassed or
tampered with. This confinement allows segregating security functions from other programs in the
SPP environment that could have an adverse effect on the security functions themselves or on the
protected assets.
The concept of domain separation could be seen in the way that an entity having a risk to affect the
security functions and the protected assets. The entity could be as example a program a computer
trying to circumvent security functions and damage protected assets.
Without any restrictions, programs can access, via numerous attack paths including the authorized
ones (e.g. memory access), to security functions and protected assets in order to lead attacks.
Domain separation allows countering attacks in a mutual manner eliminating the need to implement
individual measures for each possible attack path.
This activity aims at describing different kinds of domains supported by the SPP-SF, how they are
defined (i.e. what resources are allocated to each domain) and how the domains are kept separated
so that active entities in one domain cannot tamper with resources in another domain via various
attack paths.
The security functionalities of the SPP imply the creation of security domains. All of the mechanisms
contributing to the domain separation have to be described. The domain separation could be
implemented in a physical or logical way. The description of the security domain separation allows to
understand the efficiency of the separation and to perform a vulnerability analysis.
 Non-bypassability which property is that the security functionality of the SPP is always invoked and
cannot be circumvented.
Non-bypassability is a property so that the security functionality of the SPP (as specified by the SFRs)
is always invoked and also that breach in the design, implementation and configuration does not
exist. As example, if access control to files is specified as a capability of the SPP-SF via an SFR, there
must be no interfaces through which files can be accessed without invoking the SPP-SF's access
control mechanism (such as an interface through which a raw disk access takes place).
This activity aims at describing how the SPP-SF mechanisms cannot be bypassed, it generally
requires a systematic argument based on the SPP-SF and the SPP-SFIs. The description of how the
SPP-SF works (contained in the design decomposition evidence, such as the functional specification,
SPP design documentation) allow understanding what resources are being protected and what
security functions are being provided. No available interface can be used to bypass the SPP, it means
that either the interfaces are unrelated to the SFRs enforcement or relevant security functionalities
are invoked when this interface is used.
C2: RESTRICTED 02016_16_05952 1.0 95/159
 Self-protection which ability is to resist to manipulation from external entities aiming at disabling or
disturbing security services provided by the security architecture.
In such cases, the SPP-SF alone does not protect itself because it depends on the other IT entities to
provide some of the protection. For the purposes of the security architecture description, the notion
of self-protection applies only to the services provided by the SPP-SF through its SPP-SFIs, and not
to services provided by underlying IT entities that it uses.
Self-protection is typically achieved by a variety of means, ranging from physical and logical
restrictions on access to the SPP; to hardware-based means (e.g. memory management
functionality); to software-based means (e.g. boundary checking of inputs on a trusted server;
implement software protection layers that contribute to implement separation of software domains;
delineate user address space from system address space).
 Secure initialization process of the system. Since security functions of a component during start-up
phases are in an initialization phase, they can fail to counter attacks. This phase can be a good
opportunity to lead attacks. As example: If the network communication is activated earlier that the
activation of access control function (e.g. filtering), the risk to bypass this security function is likely.
A server which allows maintenance operation to only authorized administrators may enter in a mode
during start-up which allow unauthorized user to access to administration functions. An
unauthorized user could modify the integrity of a computer by booting on an unauthorized device.
This activity aims at describing the secure behaviour of security functionalities during the
initialization process. It encompasses the needs to maintain the integrity of the initialization process
and to guarantee that the initialization process won’t downgrade the security objectives of the SPP.
PSA_ERSP_SAR_0125-1 The developer shall design and implement the SPP so that the security features of
the SPP-SF cannot be bypassed.
O2, O3. To avoid security
vulnerabilities.
SPP-SF=SPP Security Functionality.
Non-bypassability is a property
that the security functionality of the
SPP-SF (as specified by the SFRs) is
always invoked. But also that
breach in the design and
implementation and configuration
does not exist. As example, avoid
storing secret in persistent memory
Additional info.: without any protective measures. Family: Development
The overall approach used is that
the developer provides a SPP-SF
that meets the above-mentioned
properties, and provides evidence
(in the form of documentation) that
can be analyzed to show that the
properties are indeed met.
Designing and implementing the
SPP so that the security features of
C2: RESTRICTED 02016_16_05952 1.0 96/159
the SPP-SF:
- are segregated from other
functions,
- always a ensure a secure state in
all phase of the system (boot,
shutdown, other) and in case of
failure.
could ease this demonstration.
Stakeholder: Consumer Sub-family: Security Architecture
PSA_ERSP_SAR_0126-1 The developer shall design and implement the SPP-SF with self-protection against
tampering by untrusted active entities.
vulnerabilities.
Additional info.: Family: Development
Source: PSA Sec Officer Applicability: Software, Hardware.
PSA_ERSP_SAR_0127-1 The developer shall design and implement a secure initialization process of the
SPP-SF.
vulnerabilities.
PSA_ERSP_SAR_0128-1 The developer shall provide a security architecture description of the SPP-SF
including:
-The SPP-SF initialization and shutdown processes,
-The self-protection against tampering,
-The security domains protected by the SPP-SF,
C2: RESTRICTED 02016_16_05952 1.0 97/159
-The principles preventing bypass of SPP-SF.
O2. To describe security domains
protected by the SPP-SF. To
demonstrate that the SPP-SF
initialization process is secure. To
demonstrate that the system
Rationale: integrity and secure state in all Author: Sec Officer
phase of the system (boot
sequence, shutdown, etc) is
ensured. To describe protection or
principle against tampering and
bypass of security functionalities.
PSA_ERSP_SAR_0129-1 The security architecture description shall demonstrate that the SPP-SF:
-Initialization and shutdown process is secure,
-Mechanisms against tampering are secure,
-Prevent bypass of the SFR-enforcing functionalities,
-Keeps the asset protected by the SFR-enforcing functionalities.
vulnerabilities.
5.2. Functional specifications

Functional specification describes mainly the SPP-SF and especially related Interfaces (SPP-SFIs). The SPP-SFI
consists of all means by which external entities (or internal entities of the SPP) supply data to the SPP-SF,
receive data from the SPP-SF and invoke services from the SPP-SF.
It does not describe how the SPP-SF processes those service requests, nor does it describe the
communication when the SPP-SF invokes services from its operational environment; this information is
addressed by the SPP design.
C2: RESTRICTED 02016_16_05952 1.0 98/159
PSA_ERSP_SAR_0130-1 The developer shall provide a functional specification in the Specification &
Design Dossier (SDD).
The functional specification states
the purpose of each SFR-enforcing
Additional info.: and SFR-supporting interfaces, Family: Development
their parameters (inputs & outputs)
and also the possible actions.
Stakeholder: Consumer Sub-family: Functional Specification
Source: PSA Sec Officer Applicability: Hardware, Software.
PSA_ERSP_SAR_0131-1 The developer shall provide a mapping from the functional specification to the
SFRs.
The mapping is provided by the
developer to serve as a guide to
Additional info.: whom SFRs are related to which Family: Development
SPP-SFIs. This mapping can be as
simple as a table;
PSA_ERSP_SAR_0132-1 The functional specification shall describe the purpose and method of use for
each SFR-enforcing and SFR-supporting SPP-SF Interfaces.
The purpose of an interface is a
high-level description of the
general goal of the interface.
The interface's method of use
describes how the interface is
supposed to be used.
It is not intended to be a complete
statement of the actions and
results related to the interface, but
rather a statement to help the
C2: RESTRICTED 02016_16_05952 1.0 99/159
reader understand in general what
the interface is intended to be used
for.
PSA_ERSP_SAR_0133-1 The functional specification shall identify all parameters associated with each
SFR-enforcing and SFR-supporting SPP-SF Interfaces.
Parameters are explicit inputs to
and outputs from an interface that
control the behaviour of that
interface. A parameter description
tells what the parameter is in some
meaningful way.
PSA_ERSP_SAR_0134-1 The functional specification shall provide rationale for the implicit categorisation
of interfaces as SFR-non-interfering.
PSA_ERSP_SAR_0135-1 The mapping shall demonstrate that the SFRs trace to SPP-SF Interfaces in the
functional specification.
C2: RESTRICTED 02016_16_05952 1.0 100/159
PSA_ERSP_SAR_0136-1 The functional specification shall completely represent the SPP-SF.
Rationale: O2. Coverage. Author: Sec Officer

PSA_ERSP_SAR_0137-1 The functional specification shall describe the purpose and method of use for all
SPP-SF Interfaces.
The purpose of an interface is a
high-level description of the
general goal of the interface.
The interface's method of use
describes how the interface is
supposed to be used.
Additional info.: It is not intended to be a complete Family: Development
statement of the actions and
results related to the interface, but
rather a statement to help the
reader to understand in general
what the interface is intended to be
used for.
PSA_ERSP_SAR_0138-1 The functional specification shall identify and describe all parameters associated
with each SPP-SF Interfaces.
C2: RESTRICTED 02016_16_05952 1.0 101/159
PSA_ERSP_SAR_0139-1 For each SFR-enforcing SPP-SF interface, the functional specification shall
describe the SFR-enforcing actions associated with the SPP-SF interface.
The description of an interface's
actions describes what the interface
does. These actions might be
related to the SFRs or not.
If an action available through an
interface plays a role in enforcing
any security policy on the SPP (that
is, if one of the actions of the
interface can be traced to one of
the SFRs levied on the SPP-SF), then
that interface is SFR-enforcing.
Interfaces to actions that SFR-
enforcing functionality depends on,
but need only to function correctly
in order for the security policies of
the SPP to be preserved, are termed
SFR-supporting. Interfaces to
actions on which SFR-enforcing
functionality has no dependence
are termed SFR non-interfering.
describe direct error messages resulting from processing associated with the
SFR-enforcing actions.
The error message description
identifies the condition of
Additional info.: generation, what the message is, Family: Development
and the meaning of any error
codes. Different kinds of error
C2: RESTRICTED 02016_16_05952 1.0 102/159
messages are identified: a “direct”
error message is a security-relevant
response through a specific SPP-SFI
invocation. An “indirect” error
cannot be linked to a specific SPP-
SFI invocation because it results
from system-wide conditions (e.g.
resource exhaustion, connectivity
interruptions, etc.). Error messages
that are not security-relevant are
also considered “indirect”.
“Remaining” errors are any other
errors, such as those that might be
referenced within the code.
describe direct error messages resulting from SFR-enforcing actions and
exceptions associated with invocation of the SPP-SF interfaces.
generation, what the message is,
Additional info.: cannot be linked to a specific SPP- Family: Development
“Remaining” errors are any other
C2: RESTRICTED 02016_16_05952 1.0 103/159
PSA_ERSP_SAR_0142-1 The functional specification shall summarize the SFR-supporting and SFR-non-
interfering actions associated with each SPP-SF interface.
PSA_ERSP_SAR_0143-1 The functional specification shall describe all actions associated with each SPP-SF
Interface.
The description of an interface's
actions describes what the interface
does. These actions might be
related to the SFRs or not.
If an action available through an
interface plays a role in enforcing
any security policy on the SPP (that
is, if one of the actions of the
interface can be traced to one of
the SFRs levied on the SPP-SF), then
that interface is SFR-enforcing.
Interfaces to actions that SFR-
enforcing functionality depends on,
but need only to function correctly
in order for the security policies of
the SPP to be preserved, are termed
SFR-supporting. Interfaces to
actions on which SFR-enforcing
functionality has no dependence
are termed SFR non-interfering.
C2: RESTRICTED 02016_16_05952 1.0 104/159
PSA_ERSP_SAR_0144-1 The functional specification shall describe all direct error messages that may
result from an invocation of each SPP-SF Interface.
generation, what the message is,
Additional info.: cannot be linked to a specific SPP- Family: Development
“remaining” errors are any other
PSA_ERSP_SAR_0145-1 The functional specification shall describe all error messages that do not result
from an invocation of a SPP-SF Interface.
PSA_ERSP_SAR_0146-1 The functional specification shall provide a rationale for each error message
contained in the SPP-SF implementation yet does not result from an invocation of
a SPP-SF Interface.
C2: RESTRICTED 02016_16_05952 1.0 105/159
5.3. SPP-SF Internal structure design analysis

This chapter addresses the assessment of the internal structure of the SPP-SF. A SPP-SF whose internal
structure is well-structured, thus easier to implement and less likely to contain flaws that could lead to
vulnerabilities; it is also easier to maintain without the introduction of flaws.
PSA_ERSP_SAR_0147-1 The developer shall design and implement [assignment: subset of the SPP-SF]
such that it has “well-structured” internal structure.
“well-structured” could rely on the
process used for modular
Additional info.: decomposition, coding standards Family: Development
used in the development of the
implementation, etc.
Stakeholder: Consumer Sub-family: Internal Structure.
PSA_ERSP_SAR_0148-1 The developer shall provide a description and justification of the internal
structure of the SPP-SF.
C2: RESTRICTED 02016_16_05952 1.0 106/159
PSA_ERSP_SAR_0149-1 The SPP-SF internal structure justification shall explain the characteristics used to
judge the meaning of “well-structured” internal structure.
Metrics could deal with:
- the process used for modular
decomposition
- coding standards used in the
development of the implementation
- the maximum acceptable level of
inter-module coupling exhibited by
the SPP
- the minimum acceptable level of
cohesion exhibited the modules of
the SPP
- one-to-one correspondence
between the modules identified in
the SPP-SF and the modules
described in the SPP design.
- how the SPP-SF design is a
reflection of the modular
decomposition process
- a justification for all instances
where the coding standards were
not used or met
- a justification for any coupling or
cohesion outside the acceptable
bounds
PSA_ERSP_SAR_0150-1 The description of the SPP-SF internal structure shall demonstrate that the
assigned subset of the SPP-SF is well-structured.
O2, O3. To demonstrate that the
Rationale: security functionality cannot be Author: Sec Officer
corrupted or bypassed.
C2: RESTRICTED 02016_16_05952 1.0 107/159
PSA_ERSP_SAR_0151-1 The developer shall design and implement the entire SPP-SF such that it has well-
structured internal structure.
PSA_ERSP_SAR_0152-1 The SPP-SF internal structure justification shall describe the characteristics used
to judge the meaning of “well-structured”.
PSA_ERSP_SAR_0153-1 The SPP-SF internal structure description shall demonstrate that the entire SPP-SF
is well- structured.
C2: RESTRICTED 02016_16_05952 1.0 108/159
5.4. SPP Design (conception)
The goal of SPP design documentation is to provide sufficient information to determine the SPP-SF boundary,
and to describe how the SPP-SF implements the Security Functional Requirements. The amount and structure
of the design documentation will depend on the complexity of the SPP and the number of SFRs; in general, a
very complex SPP with a large number of SFRs will require more design documentation than a very simple
SPP implementing only a few SFRs.
PSA_ERSP_SAR_0154-1 The developer shall provide the design of the SPP in the Specification & Design
Dossier (SDD).
Stakeholder: Consumer Sub-family: SPP Design
PSA_ERSP_SAR_0155-1 The developer shall provide a mapping from the SPP-SFI of the functional
specification to the lowest level of decomposition available in the SPP design.
A subsystem is a description of the design of a part of the SPP; it helps to provide a high-level description of
what a portion of the SPP is doing and how. As such, a subsystem may be further divided into lower-level
subsystems, or into modules. Very complex SPP might require several levels of subsystems in order to
adequately convey a useful description of how the SPP works. Very simple SPPs, in contrast, might not
require a subsystem level of description; the module might clearly describe how the SPP works.
Description of subsystems and modules can be done in the following way:
 The subsystems and modules are identified with a simple list of what they are.
 Subsystems and modules may be categorised (either implicitly or explicitly) as “SFR-enforcing”,

“SFR-supporting”, or “SFR-non-interfering”;
 A subsystem's behaviour is what it does. The behaviour may also be categorised as SFR-enforcing,
SFR-supporting, or SFR-noninterfering. Note that an SFR-enforcing subsystem can have SFR-
enforcing behaviour as well as SFR-supporting or SFR-non-interfering behaviour.
C2: RESTRICTED 02016_16_05952 1.0 109/159
 A behaviour summary of a subsystem is an overview of the actions it performs (e.g. “The TCP
subsystem assembles IP datagrams into reliable byte streams”).
 A behaviour description of a subsystem is an explanation of everything it does. This description

should be at a level of detail that one can readily determine whether the behaviour has any relevance
to the enforcement of the SFRs.
 A description of interactions among or between subsystems or modules identifies the reason that
subsystems or modules communicate, and characterises the information that is passed. It doesn’t
need to define the information with the same level of detail as an interface specification. For
example, it would be sufficient to say “subsystem X requests a block of memory from the memory
manager, which responds with the location of the allocated memory.
 A description of interfaces provides the details of how the interactions among modules are achieved.
Rather than describing the reason the modules are communicating or the purpose of their
communication (that is, the description of interactions), the description of interfaces describes the
details of how that communication is accomplished, in terms of the structure and contents of the
messages, semaphores, internal process communications, etc.
 The purpose describes how a module provides their functionality. It provides sufficient detail that no
further design decisions are needed.
 A module is otherwise described in terms of whatever is identified in the element.
Subsystems Modules
SPP (Base Component) Boundary
Non-SPP
Product boundary
Figure 8: Subsystems and Modules
PSA_ERSP_SAR_0156-1 The design shall describe the structure of the SPP in terms of subsystems.

The first use of subsystems is to

Additional info.: distinguish the SPP-SF boundary. In Family: Development
general, a subsystem is part of the
C2: RESTRICTED 02016_16_05952 1.0 110/159
SPP-SF if it has the capability
(whether by design or
implementation) to affect the
correct operation of any of the
SFRs.
All of the subsystems of the SPP

must be identified.
PSA_ERSP_SAR_0157-1 The design shall identify all subsystems of the SPP-SF.

The subsystems of the SPP must be
identified and the non-SPP-SF
subsystems are correctly
characterized.
PSA_ERSP_SAR_0158-1 The design shall describe the behaviour of each SFR-supporting or SFR-non-
interfering SPP-SF subsystem in sufficient detail to determine that it is not SFR-
enforcing.
SFR-supporting and SFR-non-
interfering subsystems do not need
to be described in detail as to how
they function in the system.
C2: RESTRICTED 02016_16_05952 1.0 111/159
PSA_ERSP_SAR_0159-1 The design shall summarize the SFR-enforcing behaviour of the SFR-enforcing
subsystems.
SFR-enforcing behaviour refers to
how a subsystem provides the
functionality that implements an
SFR.
PSA_ERSP_SAR_0160-1 The design shall provide a description of the interactions among SFR-enforcing
subsystems of the SPP-SF, and between the SFR-enforcing subsystems of the
SPP-SF and other subsystems of the SPP-SF.
The goal of describing the
interactions between the SFR-
enforcing subsystems and other
Additional info.: subsystems is to help provide the Family: Development
reader a better understanding of
how the SPP-SF performs it
functions.
PSA_ERSP_SAR_0161-1 The mapping shall demonstrate that all SPP-SF Interfaces trace to the behaviour
described in the SPP design that they invoke.
Complete and accurate mapping
from the SPP-SFI described in the
Additional info.: functional specification to the Family: Development
subsystems of the SPP-SF described
in the SPP design.
C2: RESTRICTED 02016_16_05952 1.0 112/159
PSA_ERSP_SAR_0162-1 The design shall ensure the robustness of SFR-enforcing subsystems in terms of
its SFR-related interfaces.
Apply coding rules,
Avoid complexity,
Also, apply controls as the
following examples:
- Check input data values and
length:
- For strings, at least: ASCII
codes, encoding, special
characters, base 64.
- For digits: min and max
applicative values, signed
or not.
- Validate resources availability:
- Check of the amount of
allocated space ;
- Check if the allocation has
succeeded (beware of out of
memory) ;
- Store only the allocated amount
of data.
PSA_ERSP_SAR_0163-1 The design shall describe the behaviour of each SFR non-interfering subsystem of
the SPP-SF in detail sufficient to determine that it is SFR non-interfering.
SFR-non-interfering subsystems do
not need to be described in detail
as to how they function in the
system.
C2: RESTRICTED 02016_16_05952 1.0 113/159
PSA_ERSP_SAR_0164-1 The design shall describe the SFR-enforcing behaviour of the SFR-enforcing
subsystems.
SFR-enforcing behaviour refers to
how a subsystem provides the
functionality that implements an
SFR.
PSA_ERSP_SAR_0165-1 The design shall summarize the behaviour of the SFR-supporting subsystems.

PSA_ERSP_SAR_0166-1 The design shall provide a description of the interactions among all subsystems
of the SPP-SF.
C2: RESTRICTED 02016_16_05952 1.0 114/159
PSA_ERSP_SAR_0167-1 The design shall describe the SPP-SF in terms of modules.

A module is a description of the
implementation. A developer
should be able to implement the
part of the SPP described by the
module with no further design
decisions.
PSA_ERSP_SAR_0168-1 The design shall provide a description of each subsystem of the SPP-SF.
O2. To determine that each

Rationale: subsystem of the SPP-SF describes Author: Sec Officer
its role in the enforcement of SFRs.
If the design is presented solely in

Assumptions: terms of modules, then this work Document: SDD
unit will be considered satisfied.
Enough information must be
present so that a context for
understanding the SFR-related
functionality is provided.
SFR-non-interfering subsystem of
the SPP-SF is described in a way
that it can be determined as SFR-
non-interfering.
An SFR-non-interfering subsystem
is one on which the SFR-enforcing
and SFR-supporting subsystems
have no dependence; that is, they
play no role in implementing SFR
functionality.
C2: RESTRICTED 02016_16_05952 1.0 115/159
PSA_ERSP_SAR_0169-1 The design shall provide a mapping from the subsystems of the SPP-SF to the
modules of the SPP-SF.
If the design is presented solely in
Assumptions: terms of modules, then this work Document: SDD
unit will be considered satisfied.
A simple mapping must show how
Additional info.: the modules of the SPP-SF are Family: Development
allocated to the subsystems.
PSA_ERSP_SAR_0170-1 The design shall ensure the robustness of SFR-enforcing modules in terms of its
SFR-related interfaces.
Apply coding rules,
Avoid complexity,
Also, apply controls as the
following examples:
- Check input data values and
length:
- For strings, at least: ASCII
codes, encoding, special
characters, base 64.
- For digits: min and max
applicative values, signed
or not.
- Validate resources availability:
- Check of the amount of
allocated space ;
- Check if the allocation has
succeeded (beware of out of
memory) ;
- Store only the allocated amount
of data.
C2: RESTRICTED 02016_16_05952 1.0 116/159
PSA_ERSP_SAR_0171-1 The design shall describe each SFR-enforcing module in terms of its purpose and
relationship with other modules.
The purpose of a module provides a
description indicating what function
the module is achieving and how
the module works.
PSA_ERSP_SAR_0172-1 The design shall describe each SFR-enforcing module in terms of its SFR-related
interfaces return values from those interfaces, interaction with other modules and
called SFR-related interfaces to other SFR-enforcing modules.

The SPP design must determine
that the description of the
interfaces presented by each SFR-
enforcing module contain an
Additional info.: accurate and complete description Family: Development
of the SFR-related parameters, the
invocation conventions for each
interface, and any values returned
directly by the interface.
PSA_ERSP_SAR_0173-1 The design shall describe each SFR-supporting or SFR-non-interfering module in

terms of its purpose and interaction with other modules.
Description of the purpose of each

SFR-supporting or SFR-non-
Assumptions: interfering module must be Document: SDD
complete and accurate.
The information provided about the
C2: RESTRICTED 02016_16_05952 1.0 117/159
module's interactions with other
modules to assess whether the
reasons for the module being called
must be consistent with the
module's purpose.
Additional info.: O2. Family: Development

PSA_ERSP_SAR_0174-1 The design shall describe the SPP-SF in terms of modules, designating each
module as SFR-enforcing, SFR-supporting, or SFR-non-interfering.
PSA_ERSP_SAR_0175-1 The design shall describe each SFR-enforcing and SFR-supporting module in
terms of its purpose and relationship with other modules.
PSA_ERSP_SAR_0176-1 The design shall describe each SFR-enforcing and SFR-supporting module in
terms of its SFR-related interfaces, return values from those interfaces,
interaction with other modules and called SFR-related interfaces to other SFR-
enforcing or SFR-supporting modules.
C2: RESTRICTED 02016_16_05952 1.0 118/159
PSA_ERSP_SAR_0177-1 The design shall describe each SFR-non-interfering module in terms of its
purpose and interaction with other modules.
5.5. Implementation representation
The function of the Implementation representation is for the developer to make available the
implementation representation of the SPP in a form that can be analysed by an evaluator. It is and
abstract representation of the SPP-SF, specifically the one that is used to create the SPP-SF itself
without any further design refinement.
Source code or hardware diagrams and/or IC hardware design language code or layout data that
are used to build the actual hardware are examples of parts of an implementation representation.
It is important to note that while the implementation representation must be made available to
the evaluator, this does not imply that the evaluator needs to possess that representation. For
instance, the developer may require that the evaluator review the implementation representation
at a site of the developer's choosing.
PSA_ERSP_SAR_0178-1 The developer shall make available the implementation representation for the
entire SPP-SF.
O2. To be evaluated by an
independent evaluator.
The evaluator samples the
implementation representation to
gain confidence that it is defined at
the appropriate level or not.
Implementation
representation
C2: RESTRICTED 02016_16_05952 1.0 119/159
Imp. Responsible: Developer Monitoring: CDR, TRR.
PSA_ERSP_SAR_0179-1 The developer shall provide a mapping between the SPP design description and
the sample of the implementation representation.

The mapping between the SPP
design description and the sample
should be accurate.
Implementation
representation
PSA_ERSP_SAR_0180-1 The implementation representation shall define the SPP-SF to a level of detail
such that the SPP-SF can be generated without further design decisions.

The implementation representation
must be defined at the appropriate
level.
Additional info.: As example, a pseudo-code level Family: Development
which requires additional design
decisions to be made should not be
suitable.
Implementation
representation
PSA_ERSP_SAR_0181-1 The implementation representation shall be in the form used by the development
personnel.

The implementation representation
is manipulated by the developer in
C2: RESTRICTED 02016_16_05952 1.0 120/159
form that is suitable for
transformation to the actual
implementation. For instance, the
developer may work with files
containing source code, which is
eventually compiled to become part
of the SPP-SF. The developer makes
available the implementation
representation in the form they
use, so that the evaluator may use
automated techniques in the
analysis.
Implementation
representation
Imp. Responsible: Developer Monitoring: PDR, CDR, TRR
PSA_ERSP_SAR_0182-1 The mapping between the SPP design description and the sample of the
implementation representation shall demonstrate their correspondence.
O2. To verify the accuracy of a
portion of the implementation
representation and the SPP design
description.
For parts of the SPP design
description that are interesting, the
must accurately reflects the
description provided in the SPP
design description.
Implementation
representation
C2: RESTRICTED 02016_16_05952 1.0 121/159
6. Guidance
C2: RESTRICTED 02016_16_05952 1.0 122/159
For the secure preparation and operation of the SPP it is necessary to describe all relevant aspects
for the secure handling of the SPP. It also addresses the possibility of unintended incorrect
configuration or handling of the SPP. The guidance documentation should cover all user roles.
6.1. Operational user guidance
Operational user guidance refers to written material that is intended to be used by all types of
users of the SPP in its evaluated configuration: end users, persons responsible for maintaining
and administering the SPP in a correct manner for maximum security, and by others (e.g.
programmers) using the SPP’s external interfaces. Operational user guidance describes the
security functionality provided by the SPP-SF, provides instructions and guidelines (including
warnings), helps to understand the SPP-SF and includes the security-critical information, and the
security-critical actions required, for its secure use. Misleading and unreasonable guidance
should be absent from the guidance documentation, and secure procedures for all modes of
operation should be addressed. Insecure states should be easy to detect.
The operational user guidance provides a measure of confidence that non-malicious users,
administrators, application providers and others exercising the external interfaces of the SPP will
understand the secure operation of the SPP and will use it as intended. The evaluation of the user
guidance includes investigating whether the SPP can be used in a manner that is insecure but that
the user of the SPP would reasonably believe to be secure. The objective is to minimise the risk of
human or other errors in operation that may deactivate, disable, or fail to activate security
functionality, resulting in an undetected insecure state.
PSA_ERSP_SAR_0183-1 The developer shall provide Operational User Guidance describing the operation
of security functionalities of the SPP.
O5. To ensure secure operation of
the SPP.
The objective of operational user
guidance is to described for each
user role, the security functionality
and interfaces provided by the SPP-
SF, provides instructions and
guidelines for the secure use of the
Additional info.: Family: Guidance
SPP. It should address secure
procedures for all modes of
operation, facilitates prevention and
detection of insecure SPP states, or
whether it is misleading or not
guided.
Stakeholder: Consumer Sub-family: Operational User Guidance
C2: RESTRICTED 02016_16_05952 1.0 123/159
Imp. Responsible: Developer Monitoring: CDR, SAR, ORR, EIS
PSA_ERSP_SAR_0184-1 The operational user guidance related to the SPP-SF shall describe at least:
- deployment and initial installation tasks,
- use tasks,
- maintenance tasks,
- actors, their roles, responsibilities and activities,
- temporary and definitively destruction or disposal tasks (e.g. key revocation),
- applicable security policies.
the SPP.
PSA_ERSP_SAR_0185-1 For each user role, the operational user guidance shall describe clearly and
accurately the user accessible functions and privileges that should be controlled
in a secure processing environment, including appropriate warnings.
the SPP.
The configuration of the SPP may

allow different user roles to have
dissimilar privileges in making use
of the different functions of the
SPP. This means that some users
are authorized to perform certain
functions, while other users may
not be so authorized. These
functions and privileges should be
Additional info.: described, for each user role, by Family: Guidance
the user guidance.
The user guidance identifies, for

each user role, the functions and
privileges that must be controlled,
the types of commands required for
them, and the reasons for such
commands. The user guidance
should contain warnings regarding
the use of these functions and
C2: RESTRICTED 02016_16_05952 1.0 124/159
privileges. Warnings should address
expected effects, possible side
effects, and possible interactions
with other functions and privileges.
accurately how to use the available interfaces provided by the SPP in a secure
manner.
the SPP.
The user guidance should provide
advice regarding effective use of
the SPP-SF (e.g. reviewing
Additional info.: password composition practices, Family: Guidance
suggested frequency of user file
backups, discussion on the effects
of changing user access privileges).
accurately the available functions and interfaces, in particular all security
parameters under the control of the user, indicating secure values as appropriate.
the SPP.
The user guidance should contain
an overview of the security
functionality that is visible at the
user interfaces.
Additional info.: The user guidance should identify Family: Guidance
and describe the purpose,
behaviour, and interrelationships of
the security interfaces and
functionality.
C2: RESTRICTED 02016_16_05952 1.0 125/159
For each user-accessible interface,
the user guidance should:
- describe the method(s) by which
the interface is invoked (e.g.
command-line, programming-
language system call, menu
selection, command button);
- describe the parameters to be set
by the user, their particular
purposes, valid and default values,
and secure and insecure use
settings of such parameters, both
individually or in combination;
- describe the immediate SPP-SF
response, message, or code
returned.
PSA_ERSP_SAR_0188-1 For each user role, the operational user guidance shall clearly and accurately
present each type of security-relevant event relative to the user-accessible
functions that need to be performed, including changing the security
characteristics of entities under the control of the SPP-SF.
the SPP.
All types of security-relevant events
are detailed for each user role, such
that each user knows what events
may occur and what action (if any)
he may have to take in order to
maintain security. Security-relevant
events that may occur during
Additional info.: operation of the SPP (e.g. audit trail Family: Guidance
overflow, system crash, updates to
user records, such as when a user
account is removed when the user
leaves the organization) are
adequately defined to allow user
intervention to maintain secure
operation.
C2: RESTRICTED 02016_16_05952 1.0 126/159
PSA_ERSP_SAR_0189-1 The operational user guidance shall clearly and accurately identify all possible
modes of operation of the SPP (including operation following failure or
operational error), their consequences and implications for maintaining secure
operation.
the SPP.
accurately the security measures to be followed in order to fulfil the security
objectives for the operational environment.
the SPP.
The security measures described in
the user guidance should include all
Additional info.: relevant external procedural, Family: Guidance
physical, personnel and connectivity
measures.
C2: RESTRICTED 02016_16_05952 1.0 127/159
6.2. Preparative procedures
Preparative procedures are useful for ensuring that the SPP has been received and installed in a
secure manner as intended by the developer. The requirements for preparation call for a secure
transition from the delivered SPP to its initial operational environment.
PSA_ERSP_SAR_0191-1 The developer shall provide the product, including the SPP, with its preparative
procedures.
O5. To ensure secure reception and
installation of the SPP in its
Rationale: operation environment. To ensure Author: Sec Officer
that the SPP works securely in its
operational environment.
The preparative procedures refer to
all acceptance and installation
procedures that are necessary to
transfer the SPP to a secure
Additional info.: configuration. It defines the Family: Guidance
procedures and steps for the
secure preparation of the SPP with
adequate documentation and then
result in a secure configuration.
Stakeholder: Consumer Sub-family: Preparative procedures
PSA_ERSP_SAR_0192-1 The preparative procedures shall describe all the steps necessary for secure
acceptance of the delivered SPP in accordance with the developer’s delivery
procedures.
O5. To ensure secure reception of
the SPP.
If acceptance procedures are not
Assumptions: applicable this requirement will be Document: OUG
satisfied.
The acceptance procedures should
include as a minimum that the user
has to check that all parts of the SPP
Additional info.: have been delivered in the correct Family: Guidance
version. The acceptance procedures
should reflect the steps the user
has to perform in order to accept
C2: RESTRICTED 02016_16_05952 1.0 128/159
the delivered SPP that are implied
by the developer's delivery
procedures.
PSA_ERSP_SAR_0193-1 The preparative procedures shall describe all the steps necessary for secure
installation of the SPP and for the secure preparation of the operational
environment in accordance with the security objectives for the operational
environment.
O5. To ensure secure installation of
Rationale: the SPP in coherency with expected Author: Sec Officer
operational environment.
The topics that can be addressed
for installation procedures could
be:
- requirements for secure
installation
- requirements for operational
environment
- steps for the user that have to be
performed to reach an operational
SPP in conformity with its evaluated
configuration.
- changing the installation specific
security characteristics of entities
under the control of the SPP-SF
(e.g.: parameters, settings,
passwords);
- handling exception and
problems.
C2: RESTRICTED 02016_16_05952 1.0 129/159
7. Testing
C2: RESTRICTED 02016_16_05952 1.0 130/159
7.1. Testing Coverage
Testing coverage establishes that the security functionalities have been tested against its
functional specification. This is achieved through an examination of developer evidence of
correspondence.
PSA_ERSP_SAR_0194-1 The developer shall provide evidence of the test coverage in the V&V Dossier
(VVD).
Rationale: 02, O3. Author: PSA Sec Officer

Additional info.: Family: Testing
Stakeholder: Consumer Sub-family: Coverage
Imp. Responsible: Developer Monitoring: TRR
PSA_ERSP_SAR_0195-1 The evidence of the test coverage shall show the correspondence between the
tests in the test documentation (VVD) and the SPP-SF interfaces in the functional
specification.

PSA_ERSP_SAR_0196-1 The developer shall provide an analysis of the test coverage in the V&V Dossier
(VVD).

C2: RESTRICTED 02016_16_05952 1.0 131/159
PSA_ERSP_SAR_0197-1 The analysis of the test coverage shall demonstrate the correspondence between
the tests in the V&V Dossier (VVD) and the SPP-SFIs in the functional specification.

PSA_ERSP_SAR_0198-1 The analysis of the test coverage shall demonstrate that all SPP-SF interfaces in
the functional specification have been tested.

Tests report provides evidence that
this requirement has been fulfilled.
7.2. Testing Depth
The testing depth deal with the level of detail to which the SPP-SF are tested by the developer.
The SPP design describes the internal components (e.g. subsystems) and modules of the SPP-SF,
together with a description of their interfaces. Evidence of testing of the SPP design must show
that the internal interfaces have been exercised and seen to behave as described. This may be
achieved through testing via the external interfaces of the SPP-SF, or by testing of the SPP
subsystem or module interfaces in isolation. In cases where some aspects of an internal interface
cannot be tested via the external interfaces, there should be either some justification that these
aspects don’t need to be tested or the internal interface needs to be tested directly. In the latter
case the SPP design needs to be sufficiently detailed in order to facilitate direct testing.
PSA_ERSP_SAR_0199-1
The developer shall provide the analysis of the depth of testing in the V&V
Dossier (VVD).

C2: RESTRICTED 02016_16_05952 1.0 132/159
Stakeholder: Consumer Sub-family: Depth
PSA_ERSP_SAR_0200-1
The analysis of the depth of testing shall demonstrate the correspondence
between the tests in the V&V Dossier (VVD) and the SPP-SF subsystems in the SPP
design.

PSA_ERSP_SAR_0201-1
The analysis of the depth of testing shall demonstrate that all SPP-SF subsystems
in the SPP design have been tested.

PSA_ERSP_SAR_0202-1
between the tests in the V&V Dossier (VVD) and the SPP-SF subsystems and SFR-
enforcing modules in the SPP design.

C2: RESTRICTED 02016_16_05952 1.0 133/159
PSA_ERSP_SAR_0203-1
The analysis of the depth of testing shall demonstrate that the SFR-enforcing
modules in the SPP design have been tested.

PSA_ERSP_SAR_0204-1
between the tests in the V&V Dossier (VVD) and the SPP-SF subsystems and
modules in the SPP design.

PSA_ERSP_SAR_0205-1
The analysis of the depth of testing shall demonstrate that all SPP-SF modules in
the SPP design have been tested.

6
Component Level: Scope: Equipment

C2: RESTRICTED 02016_16_05952 1.0 134/159
7.3. Functional tests
Functional testing performed by the developer provides assurance that the tests in the test
documentation are performed and documented correctly. The correspondence of these tests to
the design descriptions of the SPP-SF is achieved through the Coverage and Depth activities. This
activity minimizes the likelihood of undiscovered flaws.
Procedures for performing tests are expected to provide instructions for using test programs and
test suites, including the test environment, test conditions, test data parameters and values. The
test procedures should also show how the test results are derived from the test inputs.
PSA_ERSP_SAR_0206-1
The developer shall test the SPP-SF and document the results.

Stakeholder: Consumer Sub-family: Func. Tests
PSA_ERSP_SAR_0207-1
The developer shall provide test documentation in the V&V Dossier (VVD).

Imp. Responsible: Developer Monitoring: CDR, TRR, SAR
PSA_ERSP_SAR_0208-1 The V&V Dossier (VVD) shall contain test plan and related strategy, tests
objectives, test procedures, expected and observed test results.

C2: RESTRICTED 02016_16_05952 1.0 135/159
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: CDR, TRR, SAR
PSA_ERSP_SAR_0209-1 The test procedures shall identify the tests to be performed and describe the
scenarios for performing each test, including any ordering dependencies on the
results of other tests.

Sufficient instructions are provided
for any ordering dependencies.
Some steps may have to be
performed to establish initial
conditions. For example, user
accounts need to be added before
they can be deleted. An example of
ordering dependencies on the
results of other tests is the need to
Additional info.: perform actions in a test that will Family: Testing
result in the generation of audit
records, before performing a test to
consider the searching and sorting
of those audit records. Another
example of an ordering
dependency would be where one
test case generates a file of data to
be used as input for another test
case.
Software, Hardware,
Production means
PSA_ERSP_SAR_0210-1 The test objectives and related scenarios shall include positive, negative and
robustness test use cases.

Additional info.: Positive tests: verify that the Family: Testing
C2: RESTRICTED 02016_16_05952 1.0 136/159
security modules meet their
specified security requirements.
Negative test verifies that the
security modules do not anything
that is contrary to their
specifications. Testing must also
verify that it does not have an
adverse effect on any other system.
Robustness tests define additional
tests aiming at demonstrating the
maturity and robustness of the
security modules. These tests
include, as example, but not be
limited to, tests in limit cases and
in combinations of cases, tests with
realistic and under extreme
conditions, ageing tests
(endurance).
PSA_ERSP_SAR_0211-1 The expected test results shall show the anticipated outputs from a successful
execution of the tests.

PSA_ERSP_SAR_0212-1 The observed tests results shall be consistent with the expected test results.

C2: RESTRICTED 02016_16_05952 1.0 137/159
Imp. Responsible: Developer Monitoring: TRR, SAR
PSA_ERSP_SAR_0213-1 The V&V Dossier (VVD) shall include an analysis of the test procedure ordering
dependencies.

Sufficient instructions are provided
for any ordering dependencies.
Some steps may have to be
performed to establish initial
conditions. For example, user
accounts need to be added before
they can be deleted. An example of
ordering dependencies on the
results of other tests is the need to
Additional info.: perform actions in a test that will Family: Testing
result in the generation of audit
records, before performing a test to
consider the searching and sorting
of those audit records. Another
example of an ordering
dependency would be where one
test case generates a file of data to
be used as input for another test
case.
C2: RESTRICTED 02016_16_05952 1.0 138/159
7.4. Independent testing
Independent testing deals with the degree to which there is independent functional testing of the
SPP-SF. Independent functional testing may take the form of repeating the developer's functional
tests (in whole or in part) or of extending the scope or the depth of the developer's tests.
Sampling of developer tests is intended to provide confirmation that the developer has carried out
his planned test schedule on the SPP-SF, and has correctly recorded the results.
PSA_ERSP_SAR_0214-1 The developer shall provide a suitable SPP for independent testing.

Stakeholder: Consumer Sub-family: Independent testing
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: SAR
PSA_ERSP_SAR_0215-1 The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.

Software, Hardware,
Production means
Developer’s Sec Officer with
Imp. Responsible: Monitoring: SAR
possible delegation to third party.
PSA_ERSP_SAR_0216-1 The evaluator shall test a subset of the SPP-SF to confirm that the SPP-SF
operates as specified.

C2: RESTRICTED 02016_16_05952 1.0 139/159
PSA_ERSP_SAR_0217-1 The developer shall provide an equivalent set of resources to those that were
used in the developer's functional testing of the SPP-SF.
Rationale: 02. Author: PSA Sec Officer

Additional info.: In could include production means. Family: Testing
Software, Hardware,
Production means.
PSA_ERSP_SAR_0218-1 The evaluator shall execute a sample of tests in the V&V Dossier (VVD) to verify
the developer test results.

C2: RESTRICTED 02016_16_05952 1.0 140/159
8. Vulnerability assessment
C2: RESTRICTED 02016_16_05952 1.0 141/159
8.1. Introduction
Vulnerability assessment addresses the possibility of exploitable vulnerabilities introduced in the

development or the operation of the SPP.
Vulnerability analysis aims at determining if potential vulnerabilities, during the evaluation of the
development and anticipated operation of the SPP or by other methods, could allow attackers to
compromise the SPP.
8.1. Attacker’s profiles and expertise
Determining an attacker’s profile is an important step of the risk analysis and assessment.
Particular attention has to be paid on the types of attacker, since asset’s protections will be
selected according to these. The hereafter given table illustrates some of them.
EXPERTISE
TYPE OF
MOTIVATION RESULT LEVEL
ATTACKER
ENCOUNTERED
Harmless
 None  Unexpected error or access  Layman
User
 Opportunity
 Personal issues  Interception
 Assault on an employee  Malicious code (e.g. virus, logic
Insider
 Blackmail Browsing of bomb, Trojan horse)
Disgruntled,
proprietary Information  Sale of personal information  Proficient
malicious
 Computer abuse Fraud  System bugs  Expert
employees or
and theft  System intrusion
customers
 Information bribery  System sabotage
 Input of falsified,  Unauthorized system access
corrupted data
Hackers/  Challenge  System intrusion, break-ins  Proficient
Crackers  Rebellion  Unauthorized system access  Expert
 Financial gain
 System intrusion
 Fraud
 System attack (e.g. distributed
 Computer crime (e.g.
denial of service)
Computer cyberstalking)  Proficient
 System penetration
criminals  Fraudulent act (e.g.  Expert
 System tampering
replay, impersonation,
 Disclosure / destruction of
interception)
information
 Spoofing
C2: RESTRICTED 02016_16_05952 1.0 142/159
EXPERTISE
TYPE OF
MOTIVATION RESULT LEVEL
ATTACKER
ENCOUNTERED
 System penetration
 Economic exploitation
 Unauthorized system access
 Competitive advantage  Proficient
Spy (access to classified, proprietary
 Information theft  Expert
Industrial & and/or technology-related
 Intrusion on personal  Multiple
Other Information)
privacy Experts
 Information theft
 Social engineering
 Economic exploitation
 Media hacking
 Reality hacking  Proficient
 Free speech
 Website defacement  Expert
Hacktivism  Human rights
 URL redirections  Multiple
 Freedom of information
 Denial-of-service attack Expert
 Happenings
 Proficient
 Destruction
 Denial of service  Expert
Terrorisms  Revenge
 Information warfare  Multiple
 Extortion
Expert
Defense &  degradation / destruction of
 competitive
homeland vehicles / critical infrastructures /
advantage (national  Multiple
security / assets considered as military
interests) Experts
Government targets
 military advantage
al agencies  homeland security degraded
Table 11 - Type of attacker
The expertise level of the attacker defines the skills required to achieve the attack. It could be
detailed as follows:
EXPERTISE LEVEL OF
DESCRIPTION
THE ATTACKER
Layman is unknowledgeable compared to experts or proficient persons, with
Layman no particular expertise.
Proficient persons are knowledgeable in that they are familiar with the security
Proficient behaviour of the product or system type. Script kiddies are also in this
category.
Experts are familiar with the underlying algorithms, protocols, hardware,
structures, security behaviour, principles and concepts of security employed,
Expert techniques and tools for the definition of new attacks, cryptography, classical
attacks for the product type, attack methods, etc. implemented in the product
or system type.
The level “Multiple Expert” is introduced to allow for a situation, where different
Multiple Expert fields of expertise are required at an Expert level for distinct steps of an attack.
Table 12 - Expertise level of the attacker
C2: RESTRICTED 02016_16_05952 1.0 143/159
Capabilities of the attacker could be is related to equipment, software and other means required
to be able to perform the attack.
EQUIPMENT TOOLBOX DESCRIPTION

Standard equipment is readily available to the attacker, either for the
identification of vulnerability or for an attack. This equipment may be a part of
Standard
the target itself (e.g. a debugger in an operating system), or can be readily
obtained (e.g. Internet downloads, protocol analyser or simple attack scripts).
Specialized equipment is not readily available to the attacker, but could be
acquired without undue effort. This could include purchase of moderate
amounts of equipment (e.g. power analysis tools, use of hundreds of PCs
Specialized linked across the Internet would fall into this category), or development of more
extensive attack scripts or programs. If clearly different test benches consisting
of specialized equipment are required for distinct steps of an attack this would
be rated as bespoke.
Bespoke equipment is not readily available to the public as it may need to be
specially produced (e.g. very sophisticated software), or because the
Bespoke
equipment is so specialized that its distribution is controlled, possibly even
restricted. Alternatively, the equipment may be very expensive.
The level “Multiple Bespoke” is introduced to allow for a situation, where
Multiple Bespoke different types of bespoke equipment are required for distinct steps of an
attack.
Table 13 - Means of the attacker

PSA_ERSP_SAR_0219-1 The developer shall select an accredited evaluator according to consumer’s
security audit & evaluation guidelines.

Security audit & evaluation
Additional info.: Family: Vulnerability assessment
guidelines will be provided by PSA.
Stakeholder: Consumer Sub-family: Vulnerability analysis
PSA_ERSP_SAR_0220-1 The developer shall provide a suitable SPP for vulnerability evaluation.
03, O4. To assess security features.

Rationale: To assess exposure to public know Author: PSA Sec Officer
vulnerabilities.
The evaluator will examine the SPP
Additional info.: to determine that the test Family: Vulnerability assessment
configuration is consistent with the
C2: RESTRICTED 02016_16_05952 1.0 144/159
configuration under evaluation as
defined in the SPP Description and
summary specification.
The SPP may comprise a number of
distinct hardware and software
entities that need to be tested in
accordance with the Security
Problem Definition (SPD), Security
Objectives. Testing tools must be
correctly calibrated.
PSA_ERSP_SAR_0221-1 The developer shall provide the results of the SPP vulnerability analysis activities
in the Security Vulnerability Dossier (SVD).

Including threats addressed to the
SPP, vulnerability analysis from
code review, vulnerability analysis
Additional info.: from COTS analysis and survey. Family: Vulnerability assessment
Vulnerabilities from venerability
analysis. Vulnerabilities from test
activity.
Software, Hardware,
Production means.
PSA_ERSP_SAR_0222-1 The evaluator shall perform a vulnerability analysis according to consumer’s

security audit & evaluation guidelines.

Software, Hardware,
Production means.
C2: RESTRICTED 02016_16_05952 1.0 145/159
Imp. Responsible: Evaluator Monitoring: SAR
PSA_ERSP_SAR_0223-1 The evaluator shall provide an assessment of each SPP-SF according to

consumer’s security audit & evaluation guidelines.

PSA_ERSP_SAR_0224-1 The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.

Software, Hardware,
Production means.
PSA_ERSP_SAR_0225-1 The evaluator shall perform a search of public domain sources to identify

Software, Hardware,
Production means.
C2: RESTRICTED 02016_16_05952 1.0 146/159
PSA_ERSP_SAR_0226-1 The evaluator shall conduct penetration testing, based on the identified potential
vulnerabilities and also SPD, to determine that the SPP is resistant to attacks
performed by an attacker possessing a “Layman” or “Proficient” expertise level
with “Standard” means.
O3. To determine that the SPP is

resistant to attacks performed by
an attacker possessing Basic attack
potential.

PSA_ERSP_SAR_0227-1 The evaluator shall perform an independent vulnerability analysis of the SPP using
the guidance documentation, functional specification, SPP design and security
architecture description to identify potential vulnerabilities in the SPP.

PSA_ERSP_SAR_0228-1 The developer shall perform a code review on added and modified embedded
software except [COTS software and “trusted” software].
03, O4. To detect vulnerabilities. To

avoid malware.

Code review can be done manually
and/or automatically with specific
tools.
Trusted software could be software
with an equivalent security
assurance level.
C2: RESTRICTED 02016_16_05952 1.0 147/159
PSA_ERSP_SAR_0229-1 The evaluator shall perform a sample of code review covering added and modified
embedded software except [COTS software and “trusted” software].
avoid malware.
tools.
assurance level.
PSA_ERSP_SAR_0230-1 The evaluator shall perform an independent, focused vulnerability analysis of the
SPP using the guidance documentation, functional specification, SPP design,
security architecture description and implementation representation to identify
PSA_ERSP_SAR_0231-1 The developer shall perform a code review on all added and modified embedded
avoid malware.
Additional info.: Code review can be done manually Family: Vulnerability assessment
C2: RESTRICTED 02016_16_05952 1.0 148/159
tools.
assurance level.
PSA_ERSP_SAR_0232-1 The evaluator shall perform a sample of code review covering all added and
modified embedded software except “trusted’ software.
avoid malware.
tools.
assurance level.
PSA_ERSP_SAR_0233-1 The evaluator shall conduct penetration testing, based on the identified potential
performed by an attacker possessing a “Proficient” expertise level with
“Specialized” means.
O3. To determine that the SPP is
resistant to attacks performed by
an attacker possessing Enhanced-
Basic attack potential.

C2: RESTRICTED 02016_16_05952 1.0 149/159
PSA_ERSP_SAR_0234-1 The evaluator shall perform an independent, methodical vulnerability analysis of
the SPP using the guidance documentation, functional specification, SPP design,
security architecture description, organizational security policies, assumptions
about the environment, and implementation representation to identify potential
vulnerabilities in the SPP.

PSA_ERSP_SAR_0235-1 The developer shall perform a code review on all embedded software except
“trusted’ software.
avoid malware.
Additional info.: and/or automatically with specific Family: Vulnerability assessment
tools.
PSA_ERSP_SAR_0236-1 The evaluator shall perform a sample of code review covering all embedded
avoid malware.
Additional info.: and/or automatically with specific Family: Vulnerability assessment
tools.
C2: RESTRICTED 02016_16_05952 1.0 150/159
PSA_ERSP_SAR_0237-1 The evaluator shall conduct penetration testing based on the identified potential
performed by an attacker possessing an “Expert” expertise level with “Specialized”
and “Bespoke” means.
O3, O4. To determine that the SPP
is resistant to attacks performed by
an attacker possessing Moderate
attack potential.

C2: RESTRICTED 02016_16_05952 1.0 151/159
A. APPENDIX
C2: RESTRICTED 02016_16_05952 1.0 152/159
A.1. Structure of requirements
The term "SHALL" is used in the requirement to indicate a mandatory requirement and the term "SHOULD"
is used to indicate a recommendation for implementing such a requirement of the document. The Security
Assurance Requirements fields are built with the following structure:
SAR Field Description

The ID of the requirement is defined like this:
 “GEN_ID” General Identifier of the requirement
GEN_ID_aaaa-b  ”aaaa” refers to the number of the requirement
 “b” refers to the issue number of the requirement
Rationale Related to the objectives. Explain why the requirement has been written.
Assumptions Provide assumptions that must be true for the requirement validity.
Provide additional information about the requirement and also provide the point of view
Additional info.
of the evaluator with its expectations.
Stakeholder Owner of the need.
Source Referring to applicable documents and/or connected requirement.
Component Level Security Assurance Component Level
Scope {[Project][Vehicle][System][Sub-System][Equipment][TBD]}.
Req. Mngt. Ident. Identifier for the management of the Requirements.
Maturity {[Verbatim] [Agreed Verbatim][In analysis][Analysed][In validation][Validated]}
Imp. Responsible Responsible for implementation.
Author Real or generic name of the Author.
Output Document in the scope of the requirement. {[SMDD][SVD][CVR][OUG][SCD][CCMD]
Document
[SDD][VVD][FRP][SCG]}
Family The family /sub-family provide descriptive information about the topics covered by the
Sub-family assurance requirement.
Applicability Organization, Software, Hardware, Production means.
Project or product review where the security assurance requirements correctness and
Monitoring
completeness will be described and justified. See A.2 for details.
Table 14 – Structure of the requirement
C2: RESTRICTED 02016_16_05952 1.0 153/159
A.2. Life-cycle reviews for monitoring
For each review, this appendix describes what is expected, in order to understand the presence of asked
documents and associated requirements.
Feasibility/concept Definition & Design Development Tests and integration Operation & maintenance
PR PDR CDR TRR SAR ORR EIS
Security
Management &
Development Version 2 Version 3
Dossier (SMDD)
Version 1
Configuration &
Change Version 2 Version 3 Version 4 Version 5 Version 6 Version 7
Management
Dossier (CCMD)
Version 1
Security
Compliance Version 2 Version 3 Version 4 Version 5 Version 6
Dossier (SCD) Security
process
Version 1
evidences
Validation &
Verification Version 2 Version 3 Version 4 Version 5 Version 6
Dossier (VVD)
Version 1 Flaw
remediation
procedures
Version 2 Version 3 Version 4
(FRP)
Version 1
Operational
Version 2 Version 3 Version 4
User Guidance
(OUG)
Version 1
COTS
Vulnerability
Version 2 Version 3 Version 4 Version 5 Version 6 Version 7
Report (CVR)
Version 1
Specification &
Design Dossier Version 2 Version 3 Version 4 Version 5 Version 6
(SDD)
Version 1
Security
Security
technical
Vulnerability Version 2 Version 3 Version 4
and
Version 5 Version 6
Dossier (SVD) design
evidences
Version 1
Secure coding
guidelines Version 2
(SCG)
Version 1
Figure 9: Life-cycle reviews and deliverables
C2: RESTRICTED 02016_16_05952 1.0 154/159
Theses generic milestones have to be synchronized with automotive development milestones.
PR (Plan Review)
Plan Reviews are an integral part of the design process for large and small projects. It is an
opportunity to discuss code logic with the Commercial plans examiners prior to submitting the
project for review.
In summary, plans should be re-submitted and reviewed for compliance if a permit has been issued
for a project and code related changes to the approved set of plans are required. (NOTE: All scope
changes do not require re-submittal of plans but should be addressed in the field with the Code
Enforcement Official/Field Inspector.)
Preliminary Design Review (PDR)
The PDR demonstrates that the preliminary design meets all system requirements with acceptable
risk and within the cost and schedule constraints and establishes the basis for proceeding with
detailed design. It will show that the correct design options have been selected, interfaces have been
identified, and verification methods have been described.
The following are typical objectives of a PDR:
 Ensure that all system requirements have been allocated, the requirements are complete, and
the flow-down is adequate to verify system performance
 Show that the proposed design is expected to meet the functional and performance
requirements
 Show sufficient maturity in the proposed design approach to proceed to final design
 Show that the design is verifiable and that the risks have been identified, characterized, and
mitigated where appropriate
Test Readiness Review (TRR)
A TRR ensures that the test article (hardware/software), test facility, support personnel, and test
procedures are ready for testing and data acquisition, reduction, and control.
System Acceptance Review (SAR)
The SAR verifies the completeness of the specific end products in relation to their expected maturity
level and assesses compliance to stakeholder expectations. The SAR examines the system, its end
products and documentation, and tests data and analyses that support verification. It also ensures
that the system has sufficient technical maturity to Authorize its shipment to the designated
operational facility or launch site.
Operational Readiness Review (ORR)
The ORR examines the actual system characteristics and the procedures used in the system or end
product's operation and ensures that all system and support hardware, software, personnel,
procedures, and user documentation accurately reflect the deployed state of the system.
Entry Into Service (EIS)
The product gets into EIS when ORR step has ended and the product has been validated. The EIS then
goes until the end of life of the product. This phase includes the support in service of the product
and a continued maintenance of the quality of the product.
C2: RESTRICTED 02016_16_05952 1.0 155/159
A.3. List of abbreviations
The following list includes abbreviations used in this document.
Acronym Definition
ASCII American Standard Code for Information Interchange

CAD Computer Aided Design
CC Common Criteria
CCMD Configuration and Change Management Dossier
CDR Critical Design Review
CIO Chief Information Officer
CM Configuration Management
CMP Configuration Management Plan
CMS Configuration Management System
COTS Commercial Off the Shelf
CSO Chief Security Officer
CVR COTS Vulnerability Report
EIS Entry Into Service
FRP Flaw remediation procedures
FS Functional Specification
HMI Human-Machine Interface
IEC International Electrotechnical Commission
IP Intellectual Property
IS Information System
ISO International Standardization Organization
IT Information Technology
NIST National Institute of Standards and Technology
ORR Operational Review Readiness
OUG Operational User Guide
OUG Operational User Guidance
PDR Preliminary Design Review
PR Plan Review
SAR Security Assurance Requirement
SAR System Acceptance Review
SCD Security Compliance Dossier
SCG Secure coding guidelines
SDD Specification & Design Dossier
SEC Security
SF Security Functionality
SFP Security Function Policy
C2: RESTRICTED 02016_16_05952 1.0 156/159
Acronym Definition
SFR Security Functional Requirement

SMDD Security Management and Development Dossier
SO Security Objective
SP Security Policies
SPD Security Problem Definition
SPP Security Part of the Product
SPP-SF SPP Security Functionality
SPP-SFI SPP-SF Interface
SR Security Requirements
SVD Security Vulnerability Dossier
TBC To Be Confirmed
TBD To Be Defined
TCP Transmission Control Protocol
TRR Test Readiness Review
URL Uniform Resource Locator
V&V Validation & Verification
VVD Validation & Verification Dossier
Table 15 - Acronyms table
C2: RESTRICTED 02016_16_05952 1.0 157/159
A.4. List of terms
The following list includes abbreviations used in this document.
Terms Definition
Analyse Detailed study, precise made to identify the elements that constitute a whole, to
explain, enlighten the problematic.
Asset Everything and everybody you put value in (e.g.: hardware, software, documentation,
data, staff)
Asset Accountable Person in charge of the accounting of assets.
Asset Set of activities dedicated to identification, classification and maintenance of items
Management having value for the organization.
Asset Owner Organization or Person responsible of asset management and associated facilities in its
scope of competency.
Asset project A project asset is anything that the organization put value in at project level.
Attack Exploiting one or more vulnerabilities using an attack method with a given opportunity
Availability The IT resources (system or data) must be available on a timely basis to meet mission
requirements or to avoid substantial losses. Availability also includes ensuring that
resources are used only for intended purposes
Confidentiality Confidentiality is the property that information is not made available or disclosed to
unauthorized individuals, entities, or processes.
Demonstrate Prove by rigorous reasoning, in a way that seems obvious. Demonstrate, prove
something, and set it by deductive reasoning.
Describe Expose the characteristics of something in a narrative way and list its main items.
Identify Specify the nature of something, its type, category, etc, to say what it is.
Information Preservation of confidentiality, integrity and availability of information; in addition,
security other properties such as authenticity, accountability, non-repudiation and reliability can
also be involved.
Information The IS infrastructure is everything that supports the flow and processing of information,
System as network computers, both hardware and software.
infrastructure
Integrity The integrity is the property that the entity has not been modified or deleted in an
unauthorized and undetected manner.
Intruder An entity that gains or attempts to gain access to a system or system resource without
having Authorization to do so.
Justify To establish the validity, necessity, the accuracy of something by providing evidence,
documents.
Procedure Detailed description of a process or a sub-process.
Production means Means used to produce and deliver the final product (e.g.: CD, loads, etc).
Security measure Any action, device procedure, technique, or other measure that reduces the expected
loss resulting from a class of attacks.
Security Policy The security policy addresses constraints on functions and flow among them,
constraints on access by external systems and adversaries including programs and
access to data set up by the security group rules.
Third Party In the context of this document, Third Party refers to suppliers, operators, service
C2: RESTRICTED 02016_16_05952 1.0 158/159
Terms Definition
providers.
Threat The potential of a threat source to exploit vulnerability and cause a threat condition.
Threat Scenario The combination of a target threat condition and a list of causative undesired events
(e.g. threat conditions, vulnerabilities, and operational events) which in some
combination would achieve the target threat condition. For complex threat scenarios,
an attack tree may also be required to summarize the needed combinations.
Threat source Human, natural or environmental threats with the capability and potentiality to
adversely affect the airplane or its occupants
Threat vector Path or tool used by a threat source to perform a threat scenario.
Vulnerability A flaw or weakness in system security procedures, design, implementation, or internal
controls that could be exercised (accidentally triggered or intentionally exploited) and
result in a security breach or a violation of the system's security policy.
Table 16 - Terms table
C2: RESTRICTED 02016_16_05952 1.0 159/159

CSAR Issue 1.0

Uploaded by

Copyright:

Available Formats

You might also like

CSAR Issue 1.0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSAR Issue 1.0

Uploaded by

Copyright:

Available Formats

Technical Document

PSA Cyber Security Assurance Requirements

REFERENCE IND PROJECT PAGE

PSA Cyber Security Assurance Requirements

CONFIDENTIEL C2 : Can be distributed to the relevant people if it is strictly necessary.

Abdelaziz EL AABID DRD/DSEE/CIAE/EERS/ERSP 01/08/2016

Eric DEQUI DRD/DSEE/CIAE/EERS/ERSP 01/08/2016

Jean De BAUDREIL DRD/DSEE/CIAE 01/08/2016

PSA designation code :

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 2/159

Table 1 - Version management table

Reference or applicable documents

Mark Reference document Document ID Issue / Date

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 3/159

4. Lifecycle management of the development ............................................................... 50

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 4/159

6. Guidance .............................................................................................................. 122

7. Testing ................................................................................................................. 130

8. Vulnerability assessment ....................................................................................... 141

A. APPENDIX .............................................................................................................. 152

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 5/159

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 6/159

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 7/159

 Objective 3 (O3): Perform vulnerability analysis and management activities to provide

 Objective 4 (O4): Prevent malicious code in embedded products.

 Objective 6 (O6): Reporting of products’ security vulnerabilities, limitation, deviations and

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 8/159

The different identified actors and stakeholders are:

Wants to manage their product assurance expectations for a diverse portfolio of

Developers Is in charge of conducting security activities. Performs or supervises risk

The evaluator is in charge to provide judgements about the conformance of the

Table 4 - Security assurance stakeholders

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 9/159

1.4. Document organization

The 1st chapter “Introduction” presents a general introduction to the document.

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 10/159

1.5.1. Security Assurance set of requirements

REQ_ID 1 REQ Body

Table 5 - Software assurance sets of requirements

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 11/159

Table 6 - Software assurance levels (SAL)

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 12/159

The covered Security Assurance activities are the following ones:

Family or Sub-Family Security Assurance Level 1 (SAL-1) activities summary

- Applicable laws and regulations are identified.

PSA Cyber Security Assurance Requirements REFERENCE IND PROJECT PAGE

C2: RESTRICTED 02016_16_05952 1.0 13/159