CSAR_Issue_1.0.pdf cybersecurité exigences

C2: RESTRICTED DIFFUSION
REFERENCE IND PROJECT PAGE
02016_16_05952 1.0
1
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.
Technical Document
PSA Cyber Security Assurance Requirements

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.
Reference :
02016_16_05952
Application date:
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 :
Abdelaziz EL AABID
Entity :
DRD/DSEE/CIAE/EERS/ERSP
Date :
01/08/2016
Signature :
Validation(s) :
Name :
Eric DEQUI
Entity :
DRD/DSEE/CIAE/EERS/ERSP
Date :
01/08/2016
Signature :
Approved By :
Name :
Jean De BAUDREIL
Entity :
DRD/DSEE/CIAE
Date :
01/08/2016
Signature :
PSA designation code :

C2: RESTRICTED 02016_16_05952 1.0 3/159
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 4/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 5/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 6/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 7/159
1. Introduction

C2: RESTRICTED 02016_16_05952 1.0 8/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 9/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 &
stakeholders
Description
Consumer
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.
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.
Developers
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.
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.
Evaluator
The evaluator is in charge to provide judgements about the conformance of the
security evidences against the security requirements of this document. The
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 10/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 11/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.
Table 5 - Software assurance sets of requirements
Family
Security Assurance Set of Req.
Sub-Family
Set 1 Set 2 Set 3 Set 4 Set 5 SAL TBD
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.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.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.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.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.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
3. Security Evaluation
4. Life-cycle support
5. Development
6. Guidance
7. Testing

C2: RESTRICTED 02016_16_05952 1.0 12/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:
Table 6 - Software assurance levels (SAL)
Family
Security Assurance Level
Sub-Family
SAL1 SAL2 SAL3 SAL4
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.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.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.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.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.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
7. Testing
3. Security Evaluation
4. Life-cycle support
5. Development
6. Guidance

C2: RESTRICTED 02016_16_05952 1.0 13/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
2. General requirements
- Applicable laws and regulations are identified.
- Actors of the project are identified and their roles are defined.
- Security and design evidences for assurance are identified.
3.1. Security part of the product
description
- Security Part of the Product (SPP) description is provided.
- Physical and Logical scope of the SPP is described.
- SPP environment (hardware / software / firmware items) required by the
SPP is identified.
3.2. Security problem definition
- Security problem definition (SPD) is provided.
- Threats scenarios, Security policies, Assumptions are described.
3.3. Security Objectives
- Security objectives for the SPP and for the operational environment are
defined.
- Security objective rationale is provided (e.g. tracing with Threats
Scenarios, Security policies, Assumptions).
3.4. Security requirements
- Security requirements statements (Assurance, Functional, Other) are
provided.
- Security requirements rationales (Assurance, Functional, Other) are
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
capabilities
The SPP is labelled as a unique reference.
Scope
- A configuration list, identifying uniquely the configuration items, is
provided in the Configuration and Change Management Dossier (CCMD).
- 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 14/159
development
4.4. Embedded COTS
- 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
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).
4.5. Security Survey
- 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.
- 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).
4.6. Flaw remediation
-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
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 15/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.
4.8. Security of the development
environment
All the security measures (physical, procedural, personnel, and other) that
are necessary to protect the availability, integrity and confidentiality of
the SPP during its development and maintenance lifecycle are described.
5.1. Security architecture Nothing required.
5.2. Functional specifications
- 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.
-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
design analysis
Nothing required.
5.4. SPP Design (conception) Nothing required.
5.5. Implementation
representation
Nothing required.
6.1. Operational user guidance
Operational User Guidance describing the operation of security
functionalities of the SPP is provided.
6.2. Preparative procedures
Preparative procedures for the secure installation and acceptance of the
SPP in its operational environment are provided.
7.1. Testing Coverage
- Evidence of the test coverage is provided.
- Evidence of the test coverage show the correspondence between the
tests and the SPP-SF interfaces in the functional specification.
7.2. Testing Depth
- An analysis of the depth of testing is provided
- The analysis of the depth of testing demonstrates the correspondence
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.
7.3. Functional tests
- The SPP-SF is functionally tested and the results are provided in the
V&V dossier.
- 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 16/159
robustness test use cases.
7.4. Independent testing
- The SPP is provided for testing and meets all requirements for content
and presentation of evidence.
- The SPP is partially tested (e.g. test samples) by an independent
evaluator.
8.2. Vulnerability analysis
- 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
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.
description
Refer to Level 1.
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.
3.5. SPP Summary specification
- The SPP summary specification describes how the SPP protects itself
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 17/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.
capabilities
- 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).
- All configuration items are uniquely identify through the CMS.
- 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.
Scope
-The developers of the SPP-SF relevant configuration item are identified
in the configuration list.
- The configuration list includes the following items: the SPP itself; the
evaluation evidence required by the SARs; required by SAL 1 and the parts
that comprise the SPP (including COTS) required by SAL2.
4.3. Tools and techniques for
development (new)
- 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
Dossier (SMDD).
- 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.
4.4. Embedded COTS
- A contract enabling the capability to modify embedded COTS during the
whole product life-cycle is contracted with the consumer.

C2: RESTRICTED 02016_16_05952 1.0 18/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.
4.7.1. Delivery (new)
-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
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.
environment
Refer to Level 1.
5.1. Security architecture (new)
- 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
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.
- 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 19/159
non-interfering actions associated with each SPP-SF interface.
5.3. SPP-SF Internal structure
design analysis
Nothing required.
5.4. SPP Design (conception)
- 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
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
representation
Nothing required.
6.1. Operational user guidance Refer to Level 1.
6.2. Preparative procedures Refer to Level 1.
7.1. Testing Coverage
-An analysis of the test coverage in the V&V Dossier (VVD) is provided.
- The analysis of the test coverage demonstrates the correspondence
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.
7.4. Independent testing
- 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-
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.
- 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 20/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
Refer to Level 1.
3.5. SPP Summary specification Refer to Level 2.
4.1. Lifecycle definition Refer to Level 2.
capabilities
- The Configuration Management system provides automated measures
such that only authorized changes are made to the configuration items.
- The Configuration Management system supports the production of the
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.
Scope
- The configuration list includes the following: the SPP itself; the
evaluation evidence required by the SARs; the parts that comprise the SPP
(including COTS); required by SAL2 and the implementation
representation and security flaw reports and resolution status required by
SAL3.
development
The implementation standards that are being applied by the developer of
the SPP are listed and documented.
4.4. Embedded COTS Refer to Level 2.
4.5. Security Survey
- Security survey procedures related to all development tools that can
impact the embedded code of the SPP are described in the Management
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 21/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
Refer to Level 1.
5.1. Security architecture Refer to Level 2.
The functional specification describes
- all actions associated with each SPP-SF Interface.
- all direct error messages that may result from an invocation of each
SPP-SF Interface.
5.3. SPP-SF Internal structure design
analysis (new)
- 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
provided.
- 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
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 22/159
modules.
- The design describes each SFR-supporting or SFR-non-interfering
module in terms of its purpose and interaction with other modules.
5.5. Implementation representation
(new)
- 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.
-The implementation representation defines the SPP-SF to a level of detail
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.
7.2. Testing Depth
-The analysis of the depth of testing demonstrates the correspondence
between the tests in the V&V Dossier (VVD) and the SPP-SF subsystems
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.
7.3. Functional tests
The V&V Dossier (VVD) includes an analysis of the test procedure ordering
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 23/159
LEVEL 4 is Level 3++ when extra assurance is required.
description
Refer to Level 1.
3.5. SPP Summary specification Refer to Level 2.
4.1. Lifecycle definition Refer to Level 2.
capabilities
- 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
changes to the SPP by automated means, including the originator, date,
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.
Scope
- The configuration list includes the following: the SPP itself; the
evaluation evidence required by the SARs; the parts that comprise the SPP;
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 24/159
development
The implementation standards that are being applied by the developer
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.
- 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
Refer to Level 1.
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.
-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.
5.3. SPP-SF Internal structure design
analysis
- The entire SPP-SF is designed and implemented such that it has well-
structured internals.
- The SPP-SF internal structure justification describes the characteristics
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.
-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 25/159
purpose and interaction with other modules.
5.5. Implementation representation Refer to Level 3.
7.1. Testing Coverage Refer to Level 2.
7.2. Testing Depth
- The analysis of the depth of testing demonstrates:
- the correspondence between the tests in the V&V Dossier (VVD) and
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 26/159
2. General requirements

C2: RESTRICTED 02016_16_05952 1.0 27/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
Development Environment
Consumer’s and/or User’s Responsability
Developer’s Responsability
Installation
Operation
Operational
Environment
Development
Production
(e.g. Manufacturing, Integration,
Generation, Storage, Labelling)
Delivery Process
Preparation Acceptance
Send
Testing
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
Additional info.:
SAR Compliance matrix must be
used according to the required
Security Assurance Level (SAL).
Family: General Req.
Stakeholder: Consumer Sub-family: General Req.
Source: PSA Sec Officer Applicability:
Software, Hardware,
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 28/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.
Assumptions:
If Applicable laws and regulation
exist.
Document: ALL
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.
Rationale:
O2, O5, O6. Use a common
language
Author: PSA Sec Officer
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
Additional info.:
This document describes the
security assurance strategy, plan,
approach, activities and process.
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: PR, PDR, CDR.

C2: RESTRICTED 02016_16_05952 1.0 29/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
Additional info.:
Handles versioning of deliverables,
binaries and configuration files,
major product versions, security
correctives, minor product updates,
COTS and tools used
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: PR, PDR, CDR.
PSA_ERSP_SAR_0006-1 The developer shall provide a Security Compliance Dossier (SCD).
Additional info.:
- 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
performed.
- 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
Imp. Responsible: Developer Monitoring:
PR, PDR, CDR, TRR, SAR,
ORR, EIS.

C2: RESTRICTED 02016_16_05952 1.0 30/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
Additional info.:
This include all the V&V
documents: V&V Strategy, V&V
Plan, V&V Objectives, V&V
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
Additional info.:
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
Additional info.:
Refer to Operational User guidance
and preparative procedures
requirements.
Software, Hardware,
Production means
Imp. Responsible: Developer Monitoring: CDR, SAR, ORR, EIS.

C2: RESTRICTED 02016_16_05952 1.0 31/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
Additional info.:
As these deliverables contain
valuable functional and security
information which could be used by
a potential attacker or competitor,
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
Additional info.:
This report provide the outcomes
of COTS selection and COTS
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 32/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
Additional info.:
This dossier includes Security
Problem definition description and
outcomes. It also include security
vulnerability outcomes from
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
Additional info.:
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 33/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
Additional info.:
As these deliverables contain
valuable functional and security
information which could be used by
a potential attacker or competitor,
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.
Additional info.:
Security teams must be identified at
an early stage of the project.
Organisation chart could also be
provided in order to describe the
security organization of the project.
The organization must show the
weight of security team and their

C2: RESTRICTED 02016_16_05952 1.0 34/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.
Rationale: O1, O2. Author: PSA Sec Officer
Additional info.:
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 35/159
3. Security evaluation

C2: RESTRICTED 02016_16_05952 1.0 36/159
The evaluation process is seen as described below by the Common Criteria standard.
Evaluation
Confidence
Consumer
Countermeasures Sufficient
Risk
Assets
Correct
are
are
and
Therefore
minimize
and
Therefore
minimize
to
that
provides
require
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 37/159
Product boundary
Non-SPP
SPP (Base Component) Boundary
Non-SPP-SF
SPP-SF (Security Functionalities)
Interfaces to IT entities
Interfaces to human user
Functional calls
SPP-SFIs to IT entities
Functional calls
SPP: Security Part of the Product
SPP-SF: SPP Security functionalities
SPP-SFI: SPP-SF Interfaces
Figure 3: SPP and SPP-SF overview
PSA_ERSP_SAR_0018-1 The developer shall provide in the SDD a description of the SPP.
Rationale:
O2. To describe major security
features of the SPP. To describe the
usage of the SPP. To describe
physical and logical scope of the
SPP.
Additional info.:
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
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.
Family: Security evaluation
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 38/159
SPP.
Additional info.:
The list of the security
functionalities is provided and each
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.
Rationale:
O2.To identifies supporting
functions required by the SPP.
Assumptions:
If the SPP does not require any
hardware, software or firmware,
this work unit is not applicable and
therefore considered to be
satisfied.
Document: SDD
Additional info.:
While some SPP are able to run in a
stand-alone way, other SPP
(especially software ones) need
additional hardware, software or
firmware to operate.
PSA_ERSP_SAR_0021-1 The SPP description shall describe the physical scope of the SPP.
Additional info.:
The SPP physical scope and
boundaries have to be described in
term of component and
configuration. It could be a list of
hardware components with their
main configuration. A diagram
could support the discussion.

C2: RESTRICTED 02016_16_05952 1.0 39/159
PSA_ERSP_SAR_0022-1 The SPP description shall describe the logical scope of the SPP.
Additional info.:
The SPP logical scope has to be
described in term of security
capabilities and interfaces. A
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 40/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.
Security Policies
Threats Scenarios Assumptions
Security
Objectives for the
TOE
Security
Objectives for the
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).
Additional info.:
The SPD describe Asset, threats,
threats agents, treats sources,
Security policies, assumptions
about operational environment, etc.
Family: Security Evaluation
Stakeholder: Consumer Sub-family: SPD
The security concepts are seen as described below by the Common Criteria.

C2: RESTRICTED 02016_16_05952 1.0 41/159
Countermeasures
Consumers
Risk
Assets
Threats
that increase
to
to reduce
impose
Threats sources
give rise to
Wish to abuse and/or may damage
to
wish to minimise
value
Figure 5: Security concepts
PSA_ERSP_SAR_0024-1 The security problem definition shall describe the threat scenarios addressed to
the SPP.
Additional info.:
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 42/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).
Additional info.:
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.
Adverse action is the technique
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 43/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.
Additional info.:
SPs are security requirements,
security rules, procedures, or
guidelines imposed by an PSA or
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.
Additional info.:
Assumptions can be done on any
problematic that could have an
impact on the security problem
definition. It could be related to
physical environment, threat
agents, technical aspects,
operators, connectivity, etc.
Software, Hardware,
Production means

C2: RESTRICTED 02016_16_05952 1.0 44/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.
Rationale:
O2. To provide a response to the
security problem
Additional info.:
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.
Rationale:
O2. To justify how the security
objectives cover threats targeting
assets, Organizational Security
policies and Assumptions.
Additional info.:
The security objectives rationale
must demonstrate how that the
security objectives cover threats,
organizational security policy and
assumptions.
Software, Hardware,
Production means

C2: RESTRICTED 02016_16_05952 1.0 45/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.
Rationale:
O2. To justify how the security
objectives cover threats targeting
assets, Organizational Security
policies.
Additional info.:
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.
Additional info.:
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 46/159
PSA_ERSP_SAR_0032-1 The developer shall provide a statement of security requirements.
Additional info.:
All terms used in security
requirements must be accurately
described. This list of requirement
is derived from consumer’s
requirements. It should be
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.
Rationale:
O2. To avoid possible conflict with
other requirements.
Additional info.:
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.
Additional info.:
Rationale should trace Security
Objectives when relevant.
Software, Hardware,
Production means

C2: RESTRICTED 02016_16_05952 1.0 47/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).
Additional info.:
The means of compliance have to
be done according to the SARs of a
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
Additional info.:
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 48/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.
Rationale:
O2. To describe how the SPP
satisfies all SFRs.
Additional info.:
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.
Additional info.:
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 49/159
PSA_ERSP_SAR_0040-1 The SPP summary specification shall describe how the SPP protects itself against
interference and logical tampering.
Additional info.:
The description is done, in a
narrative way, not overly detailed.
The components which provide
protection must be clearly
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.
Additional info.:
The description is done, in a
narrative way, not overly detailed.
The components which provide
protection must be clearly
identified. In case of combination
of several protections, it must also
be described.

C2: RESTRICTED 02016_16_05952 1.0 50/159
4. Lifecycle management of the development

C2: RESTRICTED 02016_16_05952 1.0 51/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.
Assumptions:
Life-cycle model implements
Secure Development Plan
guidelines.
Document: VVD
Additional info.:
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,
establishment of resources needed
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
Family: Life-cycle management

CSAR_Issue_1.0.pdf cybersecurité exigences

CSAR_Issue_1.0.pdf cybersecurité exigences

Recommended

Recommended

More Related Content

Similar to CSAR_Issue_1.0.pdf cybersecurité exigences

Similar to CSAR_Issue_1.0.pdf cybersecurité exigences (20)

More from azrfdstgdgdfh

More from azrfdstgdgdfh (20)

Recently uploaded

Recently uploaded (20)

CSAR_Issue_1.0.pdf cybersecurité exigences