X2Rail-1
Project Title:
Start-up activities for Advanced Signalling
and Automation Systems
Starting date:
01/09/2016
Duration in months:
36
Call (part) identifier:
H2020-S2RJU-CFM-2015-01-1
Grant agreement no:
730640
Deliverable D8.1
Selection of the “Secure-by-design” standard
Due date of deliverable
Actual submission date
Organization name of lead contractor for this deliverable
Dissemination level
Revision
Deliverable template version: 02 (09/11/16)
GA 730640
Month 09
17-07-2017
ALS
CO
TMT approval
X2Rail-1 WP8
Deliverable D8.1
Selection of the “Secure-by-design” standard
Authors
Author(s)
Contributor(s)
Alstom Transport S.A. (ALS)
DAZA PASTRANA, Francisco José
HAUSMAN, François
Bombardier Transportation Sweden AB (BTSE)
MARQUES, Tiago
AŽD Praha s.r.o (AZD)
PIDRMAN, Milan
ANSALDO STS S.p.a (ASTS)
SORRENTINO, Giovanni
CAF Signalling S.L. (CAF)
ERDOZAIN, Aitor
OLIVA, Mario
Deutsche Bahn AG (DB)
ESCHBACH, Benedikt
Siemens AG (SIE)
MCLELLAN, Craig
Kapsch (KCC)
BRUCKNER, Berhnhard
Network Rail Infrastructure Ltd. (NR)
HEPBURN, Darren
Fondation de Cooperation Scientifique Railenium (RAILENIUM)
GRANSARD, Christophe
Société Nationale des Chemins de fer Français (SNCF)
GARNIER, Yseult
Trafikverket (TRV)
GAMELAS, Jorge
Thales Transportation Systems GmbH (TTS)
LUTZE, Claudia
GA 730640
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
1. Executive Summary
The present document constitutes the first issue of Deliverable D8.1 “Selection of the ‘Secureby-design’ standard” in the framework of the project titled “Start-up activities for Advanced
Signalling and Automation Systems” (Project Acronym: X2Rail-1; Grant Agreement No 730640).
Secure-by-design means that the component has been designed from the ground up to be
secure. Malicious behaviours against the system are taken for granted and a particular attention
must be paid to minimize impact when a security vulnerability is discovered or on invalid inputs.
Defining a “Secure-by-design” framework for the railway domain has been considered as a key
building block for establishing and assuring security capabilities in the future Railway Security
Architecture.
This deliverable focuses on:
1. Establishing a list of objectives and criteria to assess the essential requirements to be
covered independently of the type of actor (Product Supplier, System Integrator,
Operator or Asset Owner).
2. Identifying and presenting the most relevant parts of the candidate standards able to
cover or be adapted into a Railway Application environment.
3. The compliance of each proposed standard against the agreed evaluation criteria.
Finally, a rationale for the chosen standard framework (ISA/IEC 62443) regarding thoroughly
cyber security aspects is provided.
The choice of the standard framework resulted from this analysis will be used as basis for a
railway dedicated secure-by-design standard that may be amended to take into account railway
specific aspects (e.g. safety, life-cycle, etc.) during the development of railway components.
GA 730640
Page 3 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
2. Table of Contents
1.
EXECUTIVE SUMMARY ................................................................................................................................... 3
2.
TABLE OF CONTENTS ...................................................................................................................................... 4
3.
ABBREVIATIONS AND ACRONYMS ................................................................................................................. 6
4.
BACKGROUND ............................................................................................................................................... 7
5.
OBJECTIVE / AIM ............................................................................................................................................ 8
6.
OVERVIEW ON SECURITY STANDARDS AND FRAMEWORKS ........................................................................... 9
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
7.
SURVEY OF FRAMEWORK CANDIDATES ....................................................................................................... 17
7.1.
7.2.
7.3.
7.4.
7.5.
7.6.
7.7.
7.8.
7.9.
7.10.
8.
IEC/ISA 62443-4 ........................................................................................................................................... 11
ISO/IEC 15408: COMMON CRITERIA ................................................................................................................. 11
ISO/IEC 27034 .............................................................................................................................................. 12
NIST STANDARDS AND NIST CYBER SECURITY FRAMEWORK (CSF) ........................................................................... 13
ANSSI ........................................................................................................................................................... 14
MICROSOFT SDL (VERSION 5.2) ......................................................................................................................... 15
CODING RULE STANDARDS.................................................................................................................................. 15
EVALUATION PROCESS ...................................................................................................................................... 17
EVALUATION CRITERIA ...................................................................................................................................... 17
EVALUATION RESULTS PER STANDARD .................................................................................................................. 19
ISA/IEC 62443-4 ........................................................................................................................................... 20
ISO 15408 (COMMON CRITERIA)....................................................................................................................... 21
ISO/IEC 27034 (INCLUDES 27001/2/5) ............................................................................................................ 22
NIST STANDARDS AND NIST CYBER SECURITY FRAMEWORK (CSF) ........................................................................... 23
ANSSI ........................................................................................................................................................... 24
MICROSOFT SDL.............................................................................................................................................. 25
CODING RULES................................................................................................................................................. 26
CONCLUSION ............................................................................................................................................... 28
APPENDIX A – REFERENCES .................................................................................................................................. 29
9.
APPENDIX B – FURTHER INFORMATION ABOUT STANDARDS ...................................................................... 30
9.1.
ISA/IEC 62443-4 ........................................................................................................................................... 30
9.1.1.
Scope of the standard ........................................................................................................................ 30
9.1.2.
Target audience ................................................................................................................................. 30
9.1.3.
Framework focus................................................................................................................................ 30
9.1.4.
Type of requirements ......................................................................................................................... 31
9.2.
ISA/IEC 15408 .............................................................................................................................................. 34
9.2.1.
Scope of the standard ........................................................................................................................ 34
9.2.2.
Target audience ................................................................................................................................. 38
9.2.3.
Framework focus................................................................................................................................ 38
9.2.4.
Type of requirements ......................................................................................................................... 38
GA 730640
Page 4 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
9.3.
ISO/IEC 27034 (INCLUDES ISO/IEC 27001/2/5) ............................................................................................... 39
9.3.1.
Scope of the standard ........................................................................................................................ 39
9.3.2.
Target audience ................................................................................................................................. 41
9.3.3.
Framework focus................................................................................................................................ 41
9.3.4.
Type of requirements ......................................................................................................................... 42
9.3.5.
ISO/IEC 27001/2/5 ............................................................................................................................. 42
9.4.
NIST CSF & OTHER NIST STANDARDS ................................................................................................................ 44
9.4.1.
Scope of the standard ........................................................................................................................ 44
9.4.2.
Target audience ................................................................................................................................. 46
9.4.3.
Framework focus................................................................................................................................ 47
9.4.4.
Type of requirements ......................................................................................................................... 47
9.5.
ANSSI ........................................................................................................................................................... 49
9.5.1.
Scope of the standard ........................................................................................................................ 49
9.5.2.
Target audience ................................................................................................................................. 50
9.5.3.
Framework focus................................................................................................................................ 50
9.5.4.
Type of requirements ......................................................................................................................... 50
9.6.
MICROSOFT SDL.............................................................................................................................................. 51
9.6.1.
Scope of the standard ........................................................................................................................ 51
9.6.2.
Target audience ................................................................................................................................. 52
9.6.3.
Framework focus................................................................................................................................ 52
9.6.4.
Type of requirements ......................................................................................................................... 52
9.7.
CODING RULES................................................................................................................................................. 53
9.7.1.
Scope of the standard ........................................................................................................................ 53
9.7.2.
Target audience ................................................................................................................................. 54
9.7.3.
Framework focus................................................................................................................................ 54
9.7.4.
Type of requirements ......................................................................................................................... 55
10.
APPENDIX C – COMMENTS ...................................................................................................................... 57
GA 730640
Page 5 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
3. Abbreviations and acronyms
Abbreviation / Acronyms
ANSSI
ASC
ASMP
CAP
CC
CERT
COTS
CWE
CSF
EAL
FW
HW
IACS
ICS
IEC
IEEE
ISA
ISO
JPL
MISRA
NIST
O#
PP
R&D
SAR
SDL
SEI
SFR
SL-C
SL-T
ST
SW
TOE
TS
V&V
GA 730640
Description
Agence National de la Sécurité des Systèmes d’Information
(National Agency for Security in Information Systems)
Application Security Control
Application Security Management Process
Composed Assurance Packages
Common Criteria (ISO/IEC 15408)
Computer Emergency Response Team
Commercial Off-The-Shelf
Common Weakness Enumeration
Cyber Security Framework
Evaluation Assurance Level
Firmware
Hardware
Industrial Automation and Control System
Industrial Control System
International Electrotechnical Commission
Institute of Electrical and Electronics Engineers
International Society of Automation
International Organization for Standardization
Jet Propulsion Laboratory (of NASA)
Motor Industry Software Reliability Association
National Institute of Standards and Technology
Objective number: #
Protection Profile
Research & Development
Security Assurance Requirement
Secure Development Lifecycle
Software Engineering Institute
Security Functional Requirement
Security Level Capability
Security Level Target
Security Target
Software
Target Of Evaluation
Technical Specification
Verification and Validation
Page 6 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
4. Background
The present document constitutes the first issue of Deliverable D8.1 “Selection of the ‘Secureby-design’ standard” in the framework of the Project titled “Start-up activities for Advanced
Signalling and Automation Systems” (Project Acronym: X2Rail-1; Grant Agreement No 730640).
This memo describes the process for the choice of the “secure-by-design” standard framework
by evaluating some of the most common standards, guidelines and best practices in cybersecurity from several international and national organisms, putting special emphasis onto
industry-oriented publications.
The choice of the standard framework resulting from this analysis will be used as basis for
railway dedicated secure-by-design standard that may be amended to take into account railway
specific aspects (e.g. safety, life-cycle, etc.) during the development of railway components.
GA 730640
Page 7 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
5. Objective / Aim
“Security is better built in, not bolt on” is a common and acknowledged statement in the security
domain, that aims to underline the experience of past years that components best can ensure
availability, integrity and confidentiality of data and functions when security is considered from
the ground up.
In general the term secure-by-design encompasses a framework of good design principles,
patterns, processes, functional requirements and many more that enables developers to design,
build and maintain components in a way that security is implicitly considered in each stage of
the development, resulting in a product that is – secure by its design –. Applying secure-bydesign frameworks in a larger domain contributes to establish and improve the security
footprint of a system and furthermore helps to avoid most of today’s security pitfalls.
With respect to the railway applications domain such a comprehensive, unified security
framework providing guidance and best practices for railway suppliers does not yet exist. In
particular with the trend to utilize non-railway-dedicated building blocks such as open protocols,
libraries and COTS software and hardware to build railway specific applications, it is evident that
this shortcoming has to be tackled.
For that reason, defining a secure-by-design framework for the railway domain has been
considered as a key building block for establishing and assuring security capabilities in the future
Railway Security Architecture. The objectives for establishing the secure-by-design standard
framework have been aligned and defined as follows:
(O1) Define a framework of requirements and processes for development, deployment and
maintenance of railway components.
(O2) Ensure that railway components follow the defence-in-depth principle.
(O3) Ensure that security is considered with respect to the threat landscape.
(O4) Ensure a systematic approach to develop and validate security requirements.
(O5) Ensure a systematic approach to assess and manage security defects during lifecycle.
(O6) Ensure clear requirements and responsibilities among stakeholders.
(O7) Ensure coherence with future Railway Security Architecture.
(O8) Ensure a systematic approach to assess the quality assurance level of security
requirements implementation.
(O9) Allow defining several security levels depending on the level of protection provided by the
system under examination and provide an approach to assess it.
GA 730640
Page 8 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
6. Overview on security standards and frameworks
Today the market offers a continuously growing number of security standards and frameworks
in different industries. To analyse and compare different standards and frameworks it has to be
considered that they differ quite significantly in the way they are tackling the security challenge.
A first key in the comparison is to analyse the target audience. The audience, or target scope of
the standard, can range from general companies to enterprises in a specific industry and
furthermore on the organisation level they are focusing on (e.g. specific organisational groups
or divisions such as R&D, Risk Management, Product Development, IT Operations, etc.).
A second key in the comparison is to evaluate the type of requirements a standard is providing
to the target audience. From a requirements perspective, a standard can guide the user with
organisational, procedural and/or product/functional requirements, while the framework focus
provides information about the type of organisation that such requirements are addressed to.
The standards and frameworks evaluated have been developed with certain ways at looking at
the security challenge that has to be considered during the assessment. The different aspects in
which the analyses of the standards have been based on are:
Framework Focus:
Frameworks operate on different levels and may provide guidance for different aspects within
an organisation. Depending on the covered scope, a framework can be categorized as follows:




Organisational Level:
▫ Frameworks considering security activities on a holistic, enterprise-wide scope.
Operational System Level:
▫ The focus of a framework is narrowed down to an operational subsystem or
operational process.
Product/Component Level:
▫ The way of looking is limited to the boundaries of product or component.
Technology Level:
▫ Compared to other levels those frameworks have been built around a certain
technology.
Type of Requirement:
A standard or framework provides guidance in the form of requirements for an organization or
user. Depending on the type and nature, those requirements can be categorized as follows:

Organisational Requirements:
GA 730640
Page 9 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard


▫ Requirements that address the organisational framework conditions and governs
the implementation of security activities.
Procedural Requirements:
▫ Contains requirements such as methodologies that must be followed and/or
constraints that an organisation has to follow.
Product/Component Requirements:
▫ Concludes requirements in terms of features, functionalities, behaviours, etc.
This evaluation is summarised in the following figure, where the standards and frameworks
have been represented in function of the scope of their requirements:
Type of Security Requirement
Organisational
Procedural
Product/Component
Framework Focus
Organisational
Level
Operational system
Level
ANSSI
ISO/IEC 27034
NIST
ISO/IEC 62443-4
Product /
Component
Level
ANSSI
ISO/IEC 15408 (Common Criteria)
Secure by design
framework scope
Microsoft SDL
Codi ng Rules
Coding Rules
Technology Level
International Standards or Frameworks
National Standards, Frameworks or Practices
Company or Industry Practices
Fragmented Standards, Frameworks or Practices
Figure 1 – Coverage of candidate standards against “Secure-by-design” framework scope
As the secure-by-design standard encompasses a framework of good design principles, patterns,
processes, functional requirements and many more that enables developers to design, build and
maintain a secure component/product, the main scope for the secure-by-design standard is to
cover the procedural and product/functional requirements in the context of the
component/product or of the system in operation.
The following sections give a brief overview on a selected list of standards.
GA 730640
Page 10 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
6.1. IEC/ISA 62443-4
IEC/ISA 62443 is a multi-part standard where the part four is the goal of our assessment. ISA/IEC
62443-4 is divided in two parts: ISA/IEC 62443-4-1 – “Secure product development
requirements” and ISA/IEC 62443-4-2 – “Technical security requirements for IACS systems”.
While IEC/ISA 62443-4-1 focuses in defining the overall requirements for an industrial system
during a product development lifecycle, IEC/ISA 62443-4-2 provides the detailed technical
system requirements (SRs) for IACS. Although ISA/IEC 62443-4 parts are focused on product
suppliers, the whole framework standard (ISA/IEC 62443-X) covers other aspects that should be
taken into account to have a deeper understanding of the integration of the components into
the system (ISA/IEC 62443-3), as well as their impact at global and operational level (ISA/IEC
62443-1/2).
The goal of IEC/ISA 62443-4 is to provide a framework to address a secure-by-design, defencein-depth approach to conceive, build, maintain and retire industrial automation and control
products and systems. Application of the framework is intended to provide confidence that the
component, product or system has built-in security capabilities to reach its expected security
level throughout the product’s life-cycle.
The target audience for the development and maintenance of railway security components are
product suppliers (for part 4-1), in particular software development teams for who the standard
specifies a secure development life-cycle (SDL) encompassing security requirements, definition,
secure design and implementation (including coding rules), V&V, defect and patch management,
and product phase-out. This standard provides the process necessary for the product
development from the beginning of its life cycle and introduces security specific measures both
at organizational and technical levels throughout its different phases, providing so the inherent
security sought in the security standards under consideration.
This part of the standard does not address design, installation or operation of the industrial
control system component, rather intends to help implementing a lifecycle under the secure-bydesign principles at product/component level. In addition, the requirements proposed help to
align the development process of a product with the strong security needs of industrial users
such as component providers, asset owners, system integrators and maintenance contractors.
6.2. ISO/IEC 15408: Common Criteria
The ISO/IEC 15408 standard, widely known as Common Criteria (CC), is a framework that guides
in the security assessment of IT products. The system subject to the assessment is defined in CC
as Target of Evaluation (TOE). A TOE is further defined as a set of software, firmware and/or
hardware possibly accompanied by guidance. A Security Target (ST) is a complete and rigorous
GA 730640
Page 11 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
description of a security problem for a certain TOE; it contains among other aspects, the TOE
description, threats, assumptions, security objectives, security requirements, and rationales.
Another important aspect of CC is the Protection Profiles (PP). Whereas an ST always refers to a
specific TOE (specific product), a PP is intended to describe a TOE type (e.g. a firewall). The same
PP may therefore be used as a template for many different STs. In the definition of the ST,
conformance to a certain PP can be addressed.
Security requirements in CC are divided into two groups: the Security Functional Requirements
(SFR) and the Security Assurance Requirements (SAR). The firsts are technical requirements to
be addressed by the TOE in order to counter the threats and fulfil the security objectives. The
SARs, on the other hand, define activities to be carried out to provide assurance in the
correctness of the TOE, i.e. their fulfilment help in reducing vulnerabilities in the TOE by a
correctly defined development process. It is worth highlighting that measures regarding the
operational environment are not addressed in these requirements and consequently the
ISO/IEC 15408 does not consider assessment of those measures; however, it does specify that
such operational environment measures –even if not assessed– should be defined among the
security objectives to be described in the ST.
The ISO/IEC 15408 is divided into three parts. The first part (ISO/IEC 15408-1) contains the
introduction and defines the general model (ST, PP, etc.). The second part (ISO/IEC 15408-2),
defines the set of all the SFR, whereas the third part (ISO/IEC 15408-3) is reserved for the SAR.
Some of the aspects and requirements related to the Security-by-design concept are located in
the third part of the standard.
In summary, ISO/IEC 15408 standard defines a model at organizational and procedural level to
create Protection Profiles which will gather the necessary security requirements for the product
assessed.
6.3. ISO/IEC 27034
ISO/IEC 27034 is a multi-part standard aiming at defining processes for considering security
along the application lifecycle that are in line with other standards of the ISO/IEC family. Rather
than outlining precise security control requirements, this multi-part standard provides
processes to develop a set of Application Security Controls (ASC) called “ASC Library” that
depends on the business, regulatory and technological context of the application. An ASC is
defined, according to the standard, as a data structure containing a precise enumeration and
description of a security activity and its associated verification measurement to be performed at
a specific point in an application's life cycle.
GA 730640
Page 12 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
The requirements and processes specified in ISO/IEC 27034 are not intended to be implemented
in isolation but rather integrated into an organization's existing processes. It introduces
definitions, concepts, principles and procedures involved in application security in order to
establish an Application Security Management Process (ASMP) for an organization. Due to the
detachment with any software life cycle, the ISO/IEC 27034 “Life cycle reference model” is
rather an organisation-specific “software assurance programme” than a proper development
software life cycle. It is aimed at architects, analysts, programmers, testers, IT teams, data base
administrators, etc., who need to know when and which ASCs should be applied, who integrate
ASCs in their activities, who assure that ASCs meet the requirements of associated
measurements, who get access to tools and best practices and who facilitate peer review. It can
also be used by auditors, in order to know the scope and process of verification measurements
for the corresponding ASC.
ISO/IEC 27034 is part of the well-known ISO/IEC 27k series focusing in “Application Security”
and relies on ISO/IEC 27001 for describing the key concepts and security requirements, on
ISO/IEC 27002 for specifying the ASCs and on ISO/IEC 27005 for defining the risk assessment
methodology of the applications. In summary, regarding the secure-by-design scope and due to
the detachment with any software life-cycle, ISO/IEC 27034 “Life cycle reference model” is
rather an organisation-specific “software assurance programme” than the proper secure
development life cycle sought on this study.
6.4. NIST Standards and NIST Cyber Security Framework (CSF)
The “National Institute of Standards and Technology” (NIST) provides a set of publications and
frameworks that are applied to technology. One of the largest areas within NIST is the
Computer Security division. Security publications are split into 3 subsets which have been
reviewed by the X2Rail WP8 group. These are:



SP 800 Series – Computer Security
SP 1800 Series – NIST Cyber Security Practice Guides
SP 500 Series – Computer Systems Technology
Although there are many publications, it became apparent on the review which standards
would be relevant to this work package. Appendix B details a full assessment of the specific
standards and gives an outline on what each standard or publication articulates.
The conclusion from the analysis of this section is that there is a considerable amount of
information detailed within NIST. Each of the standards or publications brings benefit in some
way; however there is no single standard or publication that would be fully applicable to the
work that is being carried out within WP8. NIST publications and standards do provide a good
GA 730640
Page 13 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
level of information detail, although not all of it is relevant to European standards, regulations
and legal requirements. However, upon review and discussion it was agreed that elements of
the NIST library could be used to further develop the secure-by-design framework by
complementing the chosen standard framework if required.
The other element of NIST considered is the NIST Cyber Security Framework (CSF). This
document sets out how organisations could mature in defining levels of security based around
an approach of: Identify, Protect, Detect, Respond and Recover. These key concepts of cyber
security maturity would allow organisations to reference different standards and how they
relate to the key areas identified above and ensure that systems are being protected
appropriately during their whole life cycle.
6.5. ANSSI
ANSSI is the national cybersecurity agency of France. As a national authority, ANSSI reports to
the “Secretary General for Defence and National Security” (“Secrétaire Général de la Défense et
de la Sécurité Nationale” - SGDSN). The SGDSN assists the Prime Minister in fulfilling his
responsibilities in matters of national defence and security. There is no standard as such that
ANSSI has developed specifically for the railway industry. Depending on the nature of the
industrial activity the set of regulations and security rules are different.
The documents of ANSSI are intended for Security Managers, Security Administrators, Auditors,
Developers and Suppliers. ANSSI does not publish any security framework either; it does
however publish sets of regulations, best practices and guidelines that can be used
independently based on the needs of the organisations.
The focus of ANSSI spreads from security management activities to more technical activities
such as network level configurations. As the documents of ANSSI are published as guidelines
and best practices, the requirements are very general (high-level) and the respective
organisations that intend to or must comply with the requirements of ANSSI and the French law
have the responsibility to define more detailed actions.
There are no requirements that ANSSI imposes, however according to the Military Program Act
(Loi de Programmation Militaire - LPM) there are mandatory requirements that Critical
Infrastructure Operators must comply with as is stated in the French law. These high-level legal
requirements include: Identification of critical infrastructure information systems according to
the criteria defined by ANSSI; Notify of security incidents that affect the critical infrastructure
operators; Compliance to predefined security rules defined by French legislation for each critical
infrastructure operators according to specific industry activity, and Auditing exercise by ANSSI in
GA 730640
Page 14 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
order to verify compliance of the security controls that will be conducted by ANSSI experts,
authorised government agencies or qualified suppliers.
The ANSSI also publishes best practice security rules that all critical infrastructure operators
must already have in place or have planned to implement in the future. These include:
Information security policy, Security qualification, Security architecture, Security assurance, Log
management, Detection mechanism, Incident management, Alert management, Crisis
management, Identity & Access management, Privilege management, Defence-in-depth and
Indicators. Most of these concepts can be found on a secure-by-design scope, but as stated
above, ANSSI does not address such principles in form of detailed requirements to be
implemented into a product development life-cycle.
6.6. Microsoft SDL (Version 5.2)
The Security Development Lifecycle (SDL) is a software development process by Microsoft that
helps companies, working (mainly) under a Microsoft development framework, to build more
robust software and address security compliance requirements through seven phases in which
security software practices are defined into the development lifecycle.
The Microsoft SDL framework is intended for the whole software development team. The key
principles for the framework are referred to as SD3+C – Secure by Design, Secure by Default,
Secure in Deployment and Communications. Each of the key principles imposes different
requirements in different phases on the development lifecycle.
From a secure-by-design point of view, the seven phases of the standard cover most of the
requirements necessary to develop a secure software product using a Microsoft development
framework. All these requirements aim to minimize security-related vulnerabilities in the design,
code, and documentation and to detect and eliminate vulnerabilities as early as possible in the
development life cycle. These improvements reduce the number and severity of security
vulnerabilities as well as improve the protection of users’ privacy. Together with the SDL
framework, Microsoft provides also tools able to check and assist in the different phases of the
lifecycle to detect, for example common vulnerabilities and coding errors.
6.7. Coding rule standards
The coding rule standards and technical specifications assessed for X2R WP8 should be
considered as guidelines and best practices into the coding phase of a complete software
development life cycle of product suppliers. Such standards, resources and tools, do not assure
that vendors, developers or manufacturers have developed a secure hardware, rather it shall be
considered as a guideline and support to encourage programmers to follow a uniform set of
GA 730640
Page 15 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
rules and best practices determined by the requirements of the project and organization, rather
than by the programmer’s familiarity or preference. Once established, these standards can be
used as a metric to evaluate source code (using manual or automated processes) to determine
compliance with the standard applied. Therefore, the main target audience for these coding
rules are Software Developers, Project Managers and Testers.
From all elements evaluated for the WP8 (specified in Appendix B of this document), the
technical specification ISO/IEC TS 17961:2013 “C secure” is probably the most spread reference
in secure development for C and C++ programming languages. Most of the standards and
guidelines in secure-coding cover, amend and/or map ISO/IEC TS 17961:2013.
The evaluation of “rules” as useful resources and guides in the coding phase of a secure-bydesign standard framework is divided into “Language standards”, “Secure development
standards, guidelines or technical specifications” and “Secure-coding analysis tools”: the first
establish the definition and requirements of a programming language; the second are focused
on ways to diagnose insecure code and/or provides best practices beyond the requirements of a
language standard in order to avoid known errors and attacks due to flaws in the code; and the
third are examples of software tools able to analyse written code in order to find common
errors, flaws and vulnerabilities automatically. This evaluation also references several wellknown organisms developing their own standards and best practices in coding, as NASA, CERT
or MISRA. Finally, it is mentioned the Common Weakness Enumeration (CWE) database as
currently is one of the main resources used by developers to keep track of new flaws and
vulnerabilities discovered in common devices and/or applications (COTS networking devices, OS,
etc.), therefore providing a “technological watch” in coding topics at product /component level.
GA 730640
Page 16 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
7. Survey of Framework candidates
7.1. Evaluation Process
The procedure pursued for the assessment of existent frameworks for a secure-by-design
standard is:
1. Establish a list of objectives and criteria to assess the essential requirements to be
covered independently of the type of actor (Product Supplier, System Integrator,
Operator or Asset Owner).
2. Identification and presentation of most relevant parts of the candidate standards able to
cover or be adapted into a Railway Application environment.
3. For each candidate standard, compare against the evaluation criteria proposed the level
of coverage in a Railway Application environment.
4. Finally, a rationale for the chosen standard/s regarding carefully cyber security aspects is
provided.
7.2. Evaluation Criteria
The following figure illustrates the product life-cycle considered for this evaluation and the
definition of evaluation criteria.
Figure 2 – V-Model from railway international standard EN50126. © CENELEC
To evaluate the landscape of available standards from international bodies and companies, a list
of criteria has been established to assess the completeness and overlaps of different concepts.
GA 730640
Page 17 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
The criteria listed below aim to set out key requirements on different technical and
organisational aspects and for different stakeholder – suppliers, integrators, operators and asset
owners - that act as a guidance throughout the selection of a secure-by-design standard.
Criteria
Criteria
Type
Objective
coverage
Description
Design and
Development
Development
Process
The proposed standard defines the requirements for the O1/O4/O7
complete design process, from the system design up to the
detailed implementation. These requirements should cover the
technical and organisational aspects and be hardware and
software independent.
Verification
and validation
Development
Process
The proposed standard defines the requirements applicable to O1/O4/O7
the verification and validation process of the security functions.
These requirements shall cover the technical and organisational
aspects and be hardware and software independent.
Security level
Product
Capability
The proposed standard defines several security levels reflecting O9
the level of protection provided by the system under
consideration.
Maturity level
Governance
The proposed standard defines several maturity levels for the O8
implementation of the security functions.
Defence-indepth
Product
Capability
The proposed standard implements, throughout the system, O2
multiple layers of security controls (defence).
Security defect
management
Operational
Process
The proposed standard defines the way to assess and manage
security defects discovered during the development cycle and
after. Both technical and organisational aspects should be
covered.
Patch
management
Operational
Process
The proposed standard defines the requirements applicable to O1/O5
patch management process in order to ensure the security
level. These requirements shall cover the technical or
organisational aspects.
Security
assessment
Governance
The proposed standard shall define or refer a way to assess the O9
security level of equipment.
GA 730640
O1/O3/O5
(threat
landscape
evolution)
Page 18 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Guideline/docu
mentation
Product
Capability
The proposed standard shall define the requirements in terms O1
of documentation and guideline to ensure the security of the
component during its complete life-cycle.
System
integration and
use
Product
Capability
The proposed standard shall consider the integration of the O6
secure components inside wider systems and sub-systems and
the way to exchange the information and exported security
requirements between the different stakeholders (provider,
integrator and final user).
Technological
watch
Governance
The proposed standard shall define requirements to ensure O3/O5
that:


the up-to-date recommended security practices are
implemented during development and maintenance
phases;
the up-to-date threat landscape and vulnerabilities are
used to perform the security assessment during
development and maintenance phases (periodically).
Protection
profile
Product
Capability
The proposed standard shall provide an implementation- O4
independent set of security requirements associated with a
family of products, often referred to as protection profile.
Product life
cycle
Governance
The proposed standard shall cover all life cycle phases from O1/O5
design to validation, as well as its deployment, maintenance
and decommissioning.
7.3. Evaluation Results per Standard
The standards have been evaluated based on the level of compliance against the criteria listed
above. The fulfilment grade is differentiated between:




OK: The standard under consideration covers the criterion as a whole.
High Level: The standard under consideration covers the criterion but without providing
in-depth approach.
Partial: The standard under consideration either covers partially the criterion, or the
criterion is only fulfilled for a part of the standard. Details about the coverage should be
provided in the “Remark column”.
Not OK: The standard under consideration does not take into account the criterion.
GA 730640
Page 19 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
7.4. ISA/IEC 62443-4
ISA/IEC
62443-4
Remarks
Design and Development
OK
ISA/IEC 62443-4-1 Practice 1 – Security management and Practice 3 –
Secure-by-design.
Verification and validation
OK
ISA/IEC 62443-4-1 Practice 1 – Security management and Practice 5 –
Security verification and validation testing.
Criteria
ISA/IEC 62443-1-1 defines the security levels (10.4) as a fundamental
concept (10).
Security level
OK
ISA/IEC 62443-3-2 defines security levels target (SL-T) for zones and
conduits.
ISA/IEC 62443-4-2 defines component requirements based on SLs, the
security capabilities (SL-C) for 4 different product types.
Maturity level
OK
ISA/IEC 62443-1-1 defines the maturity levels (10.2) as a fundamental
concept (10).
ISA/IEC 62443-4-1 implements the concepts of maturity levels.
Defence-in-depth
OK
Security defect management
OK
ISA/IEC 62443-1-1 defines defence-in-depth (9.4) as a general concept
(9).
ISA/IEC 62443-4-1 Practice 1 – Security management, Practice 3 –
Secure-by-design and Practice 8 – Security guidelines.
ISA/IEC 62443-4-1 Practice 1 – Security management and Practice 6 Security defect management.
ISA/IEC 62443-1-1 describes patch management as part of product
and system life-cycle activities.
ISA/IEC TR62443-2-3
management.
Patch management
OK
provides
detailed
guidance
in
patch
ISA/IEC 62443-4-1 Practice 1 – Security Management and Practice 7 –
Security update management.
Requirements to patch management are also defined in ISA/IEC
62443-2-4 and ISA/IEC 62443-2-1 for system integrators and asset
owners/operators.
ISA/IEC 62443-1-1 defines the context model (9.1) and Threat-Risk
Assessment (9.5) as general concepts (9).
Security assessment
OK
ISA/IEC 62443-4-1 Practice 1 – Security management, Practice 2 –
Specification of security requirements and Practice 5 – Security
verification and validation testing.
Addressed in ISA/IEC 62443-2-1 and ISA/IEC 62443-3-2 (risk
assessment) for asset owners/operators.
Guideline/documentation
OK
ISA/IEC 62443-1-1 defines Policies and Procedures (9.6) as general
concept (9) and introduces security documentation, guidelines and
support in security life-cycle (10.1) which is a fundamental concept.
ISA/IEC 62443-4-1 Practice 1 – Security management, Practice 8 –
Security guidelines.
GA 730640
Page 20 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
System integration and use
OK
ISA/IEC 62443-1-1 introduces the principal roles
owner/operator, system integrator and product supplier.
(7)
asset
ISA/IEC 62443-2-1 and ISA 62443-2-4 cover this criterion.
ISA/IEC 62443-1-1 defines life-cycles (10.1) as fundamental concept
(10).
Technological watch
OK
ISA/IEC 62443-4-1 Practice 1 – Security management, Practice 2 –
Specification of security requirements, Practice 3 – Secure-by-design,
Practice 5 – Security verification and validation testing and Practice 6
– Security defect management.
ISA/IEC 62443-4-1 references NIST Protection Profile in bibliography.
ISA/IEC 62443-4-2 references Common Criteria Protection Profiles in
CR 1.14 RE1 and RE2.
Protection profile
OK
ICCF (IACS Cybersecurity Certification Framework) Figure 27 illustrates
the mapping between security objectives and assumptions of ANSSI
short-term protection profile for a PLC to ISA/IEC 62443-4-2
component requirements based on ICCF ICPRO (IACS Component
Cybersecurity Protection Profile) pillar.
ISA/IEC 62443-1-1 defines product and IACS life-cycles (10.1) as
fundamental concept (10).
Product lifecycle
OK
ISA/IEC 62443-4-1 describes product development life-cycle
requirements related to cyber security for products intended for use
in the industrial automation and control systems environment.
7.5. ISO 15408 (Common Criteria)
Criteria
Design and Development
Verification and validation
Security level
GA 730640
ISO 15408
(CC)
Remarks
OK
It defines requirements for the complete design process. However,
requirements, rather than technical or organisational, can be
categorized as procedural (with the corresponding outcome
documentation).
OK
The concepts as verification and validation are not directly addressed,
at least with those names. Instead, there are requirements that
specify how to carry out the evaluation of the ST, and also
requirements on how to perform the tests. In addition, in each SAR
component, there are requirements that apply to the evaluator. As in
the design process, requirements, rather than technical or
organisational, can be categorized as procedural (with the
corresponding outcome documentation).
High-level
CC does not describe security levels as ISA/IEC 62443. CC focuses on
an asset-based certification approach founded on PPs and STs where a
certain set of SFRs are defined, whereas ISA/IEC 62443 has an
scenario-based approach (threat landscape and risk-based) where
security levels are a fundamental principle related to the product
and/or the system partitioned into zones and conduits. Finally, while
CC aims to keep flexibility in the way requirements are defined,
Page 21 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
ISA/IEC 62443 introduces a static pre-defined set of requirements.
OK
The EAL is a kind of maturity level based on the depth in which the
SARs have to be applied. Therefore, the EAL applies to "procedural"
requirements (the SARs).
Defence-in-depth
OK
Not addressed as defence-in-depth, but the security requirements are
applied for the different steps of the development process. In function
of the EAL, more requirements applying to the different layers are
defined.
Security defect management
OK
Addressed under Flaw Remediation (ALC_FLR) assurance family.
Patch management
OK
Addressed under Flaw Remediation (ALC_FLR) assurance family.
Security assessment
OK
The Vulnerability Assessment (AVA) assurance class handles the
vulnerability evaluation and defines how to assess the strength of the
TOE security functions.
Guideline/documentation
OK
It defines the documentation that has to be presented in every lifecycle step. In addition, there is a class (AGD) with specific
requirements related to guidance documents.
System integration and use
OK
Requirements that address how to carry out the composition of
different products is addressed in the standard by the definition of
extra assessment requirements.
Partial
The technological watch concept is not treated in its whole. Only the
vulnerability analysis is addressed under the Vulnerability Analysis
(AVA_VAN) assurance class.
Protection profile
OK
It does define how to define protection profiles and security profiles
(this last named Security Targets).
Product lifecycle
OK
The class (ALC = Life Cycle Support) is defined, but as other class, only
describes requirements to acquire from an external life-cycle
development, it is not a life cycle itself.
Maturity level
Technological watch
7.6. ISO/IEC 27034 (includes 27001/2/5)
ISO/IEC
27034
Remarks
Design and Development
OK
The standard defines processes for the whole Application Lifecycle. But
this standard is focussing mainly on application development.
Verification and validation
OK
It is part of the ASC.
Criteria
Security level
NOK
Security levels can appear depending on the implementation of the
standard, but it is not defined.
Maturity level
NOK
The process and level of maturity are not formally defined by the
ISO/IEC 27034 but the ISO/IEC 21827.
GA 730640
Page 22 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Defence-in-depth
OK
Defence-in-depth
about
technological
context,
application
specifications, application data, organization and user data and roles
and permissions.
Security defect management
OK
Assess and manage security defects discovered during the development
cycle and after.
Patch management
OK
All security and privacy issues identified by the Final Security Review
process are fixed or mitigated.
Security assessment
OK
Addressed in ISO/IEC 27001.
Guideline/documentation
OK
System integration and use
OK
The ASMP addresses the security aspects of provisioning and operating
of applications.
OK
Security and privacy issues identified by the Final Security Review
process are fixed; those that cannot be addressed (e.g. vulnerabilities
posed by design level issues) are logged and corrected in the next
release.
Technological watch
Protection profile
NOK
Product lifecycle
Partial
ISO/IEC 27034 does not provide security profiles or protection profiles.
Mainly organizational and process-oriented.
7.7. NIST Standards and NIST Cyber Security Framework (CSF)
NIST standards
& CSF
Remarks
OK
NIST SP800-160 Nov 16 – section 3.4.5 specifically details the design
definition process and activities and tasks that should be carried out.
OK
NIST SP800-160 Nov 16 – Within section 3.4.5 there is a small section
on maintaining traceability through verification and validation
methods or techniques. There is also section 3.4.9 that details
verification processes in depth.
Security level
OK
NIST SP800-53r4 details the process of risk and how levels of risk can
drive the security measures required. NIST SP 800-160 details that
levels of criticality and assurance must be defined but only at a high
level. There is also a reference in the NIST CSF. Each of these
publications detail the requirement but there is no specific definition
of security levels for products.
Maturity level
High Level
http://csrc.nist.gov/groups/SMA/prisma/security_maturity_levels.html
Defence-in-depth
OK
The NIST CSF details how to apply defence-in-depth for assets, systems
and products.
Security defect management
OK
NIST SP800-160 details system defects and how they can lead to
vulnerabilities – this could also be applied to products.
Criteria
Design and Development
Verification and validation
GA 730640
Page 23 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Patch management
OK
NIST SP800-53r4 and NIST SP800-40 both detail patch management
processes.
Security assessment
OK
NIST SP 800-30r1 (control assessment NIST SP 800-53a)
Guideline/documentation
OK
NIST SP800-160r1 and NIST SP800-53r4 and CSF all detail guidance and
have documentation of product security.
System integration and use
OK
NIST SP800-64r2 and NIST SP800-160 both detail about system
integration and use which could apply to products.
Technological watch
OK
Whole special publication library – too many documents to reference
Protection profile
High Level
NIST SP800-53r4 Appendix H (IEC 15408 requirements mapped to NIST
controls). CSF has references to PP.
Product lifecycle
OK
NIST SP800-160r1 and NIST SP800-64r2 and CSF all discuss about
lifecycle management that could be applied at all levels including
products.
7.8. ANSSI
Criteria
Design and Development
ANSSI
Remarks
High-level
See guideline “Detailed Measures” (3.3), Managing Cybersecurity
for ICS (2.3.2).
See guideline “Classification Method and Key Measures”: Only
security approval (2.3) and audits (2.2.5) are described.
Verification and validation
Partial
A guide concerning how to approve security in 9 steps exists in
French.
See Managing Cybersecurity for ICS (2.3.2) only test phase is
described.
Security level
OK
Maturity level
NOK
Defence-in-depth
OK
Security defect management
OK
See guideline “Classification Method and Key Measures” (3).
See guideline “Detailed
Cybersecurity for ICS (2.2.3)
Measures”
(4.3)
and
Managing
See “Detailed Measures” (3.5 organisational measures and 4.4
technical measures)
See Managing Cybersecurity for ICS (2.2.5)
Patch management
OK
See Managing Cybersecurity for ICS (GP11) and “Detailed
Measures” (4.3.2)
Security assessment
OK
See guideline “Classification Method and Key Measures” (3)
Guideline/documentation
OK
Specific guidelines has been published for ICS; see website
GA 730640
https://www.ssi.gouv.fr/entreprise/bonnes-pratiques
Page 24 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
System integration and use
NOK
Technological watch
OK
See guideline “Classification Method and Key Measures” (2.2.6)
Detailed Measures” (3.3.6 and 3.3.7)
Protection profile
OK
3 types: Short-term, Mid-term (5y) and Long-term (not distributed
publically).
Product lifecycle
NOK
7.9. Microsoft SDL
Criteria
Microsoft SDL
Remarks
Design and Development
Partial
Only at SW level
Verification and validation
Partial
Only at SW level
Security level
Partial
Only at SW level. Addressed through “Bug bars” which are used to
define the severity thresholds of security vulnerabilities (Critical;
Important; Moderate and Low).
Maturity level
Partial
Only at SW level. Addressed through the “SDL Optimization
model” with 4 levels: Basic, Standardized, Advanced and Dynamic.
Defence-in-depth
Partial
Only at SW level. Concept defined in the standard protecting
through the different phases.
Security defect management
Partial
Only at SW level. A threat modelling tool is also proposed in the
standard to help with.
Patch management
Partial
Response to vulnerabilities is part of the development process
solely from the perspective of the Software development.
Security assessment
Partial
Only at SW level. Defined in the standard but no quantitative
methodology is proposed.
Guideline/documentation
OK
System integration and use
Partial
The framework covers the requirement for deployment guides.
System Integration as such is out of scope of the framework.
OK
Microsoft keeps threat modelling and code analysis tools updated.
Last version of the Microsoft SDL framework is 5.2 in 2012.
Technological watch
GA 730640
Page 25 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Protection profile
Product lifecycle
NOK
Partial
Microsoft SDL covers the main development aspects at SW level.
Commissioning, integration or operations is not scope of the
framework.
7.10. Coding rules
Criteria
Coding rules
Design and Development
NOK
Verification and validation
Partial
Security level
NOK
Maturity level
NOK
Defence-in-depth
NOK
Security defect management
NOK
Patch management
NOK
Security assessment
NOK
Guideline/documentation
OK
System integration and use
NOK
Remarks
Verification through secure code analysis tools.
Coding guidelines to implement.
OK
See guideline “Classification Method and Key Measures” (2.2.6)
Detailed Measures” (3.3.6 and 3.3.7). New flaws in code products
can be addressed through monitoring of CWE and OWASP
vulnerabilities/attacks database.
Protection profile
Partial
Certain coding standards and best practices provide different levels
of tests and rules to apply in the code, making available different
software protection profiles.
Complete lifecycle
NOK
Technological watch
GA 730640
Page 26 of 57
X2Rail-1 WP8
Deliverable D8.1
Selection of the “Secure-by-design” standard
ISA/IEC 62443-4
ISO 15408 (CC)
ISO/IEC 27034
NIST
ANSSI
Microsoft SDL
Design and Development
Criteria
OK
OK
OK
OK
High-level
Partial
Coding Rules
NOK
Verification and validation
OK
OK
OK
OK
Partial
Partial
Partial
Security level
OK
High-level
NOK
OK
OK
Partial
NOK
Maturity level
OK
OK
NOK
High-level
NOK
Partial
NOK
Defence in depth
OK
OK
OK
OK
OK
Partial
NOK
Security defect management
OK
OK
OK
OK
OK
Partial
NOK
Patch management
OK
OK
OK
OK
OK
Partial
NOK
Security assessment
OK
OK
OK
OK
OK
Partial
NOK
Guideline/documentation
OK
OK
OK
OK
OK
OK
OK
System integration and use
OK
OK
OK
OK
NOK
Partial
NOK
Technological watch
OK
Partial
OK
OK
OK
OK
OK
Protection profile
OK
OK
NOK
High Level
OK
NOK
Partial
Product lifecycle
OK
OK
Partial
OK
NOK
Partial
NOK
Table 1 – Evaluation criteria coverage overview on candidate standards
GA 730640
Page 27 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
8. Conclusion
The aim of this report has been the selection of a normative framework for settling the basis of
a railway cybersecurity standard to be used as reference to develop secure railway products
under “Secure-by-design” principles.
Taking into account the results of the evaluation process against the objective pursued, four
standards have been selected as potential candidates (covering at least 80% of the identified
criteria):
1.
2.
3.
4.
ISA/IEC 62443-4 complies to all criteria;
ISO/IEC 15408 complies to all but two criteria;
ISO/IEC 27034 complies to all but four criteria;
NIST standards complies to all but two criteria;
In light of the framework focus for the secure-by-design standard, it appears that the ISA/IEC
62443-4 best fits to the standard coverage expectation while non-negligible gaps have been
identified for the three others candidates. Furthermore, NIST standards provide the needed
information but in a quite fragmented way.
In addition, on Figure 1 – Coverage of candidate standards against “Secure-by-design” framework scope
which represents the secure-by-design framework scope, it appears that among the four
candidates, ISA/IEC 62443-4 also best matches our expectations for.
Thus, considering:




the results of this analysis,
the coverage of framework scope,
the recommendation to use the ISA/IEC 62443 for the implementation of the
cybersecurity in the railway sector by the major international railway organisations and
normative bodies (i.e. UNIFE, CENELEC, etc.) and
that ISA/IEC 62443 is also used as the security risk assessment standard for the task 8.2
of X2Rail:
The ISA/IEC 62443-4-1 – “Secure product development requirements” and ISA/IEC 62443-4-2 –
“Technical security requirements for IACS systems” of the multi-part standard ISA/IEC 62443 is
proposed as the standard framework for the “Secure-by-design standard in the railway domain”.
GA 730640
Page 28 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Appendix A – References
1. ISA/IEC 62443-4-1 “Product development requirements”. Last draft from ISA/IEC used
for this document. http://isa99.isa.org/Public/Documents/ISA-62443-4-1-WD.pdf
2. ISA/IEC 62443-4-2 “Technical security requirements for IACS components”. Last draft
from ISA/IEC used for this document. http://isa99.isa.org/Public/Documents/ISA-624434-2-WD.pdf
3. ISO/IEC 15408:2009 “Common Criteria”. https://www.iso.org/standard/50341.html
4. ISO/IEC 27001:2013 “Information Security Management Systems”.
https://www.iso.org/standard/54534.html
5. ISO/IEC 27005:2011 “Information security risk management”.
https://www.iso.org/standard/56742.html
6. ISO/IEC 27034:2011 “Application security”. https://www.iso.org/standard/44378.html
7. NIST Standards & Other standards. http://csrc.nist.gov/publications/PubsSPs.html
8. ANSSI. “Protection profiles” and “Best practices”.
https://www.ssi.gouv.fr/administration/bonnes-pratiques/
9. Microsoft SDL v5.2 “Security Development Lifecycle”. https://msdn.microsoft.com/enus/library/windows/desktop/cc307406.aspx
10. Coding rules. GOTO Appendix B, section “Coding rules” in this document for multiple
references and links on this subject.
GA 730640
Page 29 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
9. Appendix B – Further information about standards
9.1. ISA/IEC 62443-4
9.1.1. Scope of the standard
In this part of the IEC/ISA 62443 series, it can be found process requirements to assure the
secure development of products in Industrial Control Systems. It specifies a secure development
life-cycle (SDL) including security requirements, definition, secure design and implementation
(including coding guidelines), V&V, defect and patch management, and product phase-out.
9.1.2. Target audience
The target audience are component providers, in special software teams:



Developers and maintainers;
Software Project Managers and
Software Testers (for the tools).
In addition, it could be of great interest also for software acquirers to be able to define the
software requirements to reach higher levels of reliability, robustness and resistance to attacks.
9.1.3. Framework focus
This standard provides the process necessary for the product development from the beginning
of its life cycle and introduces security specific measures both at organizational and technical
levels throughout its different phases, providing so the inherent security sought in the security
standards under consideration. This standard does not address design, installation or operation
of the ICS component rather intends to help in order to implement the secure-by-design
concept. In addition, the requirements proposed help to align the development process of a
product with the strong security needs of industrial users as for example providers of ISA 624432-4 capabilities as asset owners or system integrators and maintainers contractors.
GA 730640
Page 30 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Figure 3 – Automation solution relation between ISA/IEC 62443 standards. © ISA/IEC
9.1.4. Type of requirements
This standard covers most of requirements to address a secure-by-design framework at process,
technical and organisational level through the whole life cycle of a product. The requirements
covered are shown in the following table (BR: Basic Requirements; RE: Requirement
Enhancement):
GA 730640
Page 31 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
GA 730640
Page 32 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Table 2 – Summary of ISA/IEC 62443-4-1 requirements. © ISA/IEC
GA 730640
Page 33 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
9.2. ISA/IEC 15408
9.2.1. Scope of the standard
The ISO/IEC 15408 standard, widely known as Common Criteria (CC), is a framework that guides
in the assessment of IT products in terms of security. Its philosophy is to provide assurance
based upon an evaluation of the IT product. The standard aims at:



Providing the consumers with a tool to identify if the product fulfils their security needs
in a simple way;
Providing the developers with a clear guidance on how to implement their products
from the security perspective, and
Providing the evaluators with clear criteria to assess a product according to security
requirements.
The ISO/IEC 15408 is divided into three parts:



ISO/IEC 15408-1 contains the introduction and defines the general model (Security
Target, Protection Profiles, etc.) in which security has to be handled.
ISO/IEC 15408-2 defines the set of all the Security Functional Requirements
ISO/IEC 15408-3 is reserved for the Security Assurance Requirements (SAR).
When analysing this standard under the umbrella of the Security-by-design, the focus has to be
set on the third part (ISO/IEC 15408-3) of the standard, since the SAR are the measures that
define the requirements to be fulfilled in the process of development of a product.
ISO/IEC 15408 – Part 3
ISO/IEC 15408 provides assurance through active investigation, where by active investigation it
is meant an evaluation of the IT product in order to determine its security properties. Evaluation
techniques can include for example analysis and checking of processes and procedures, their
appliance, analysis of the correspondence between TOE design representations, analysis of
guidance documents, independent functional testing, etc. The idea behind is that greater
assurance results are achieved by means of greater evaluation effort.
All the evaluation techniques are further specified in the set of Security Assurance
Requirements (SAR) described in this ISO/IEC 15408-3. The SAR is a description of how the TOE
is to be evaluated. These requirements are structured in classes. These classes, in turn, are
divided into assurance families, these in components, and finally the components in elements.
An assurance element is a security requirement which, if further divided, would not yield a
GA 730640
Page 34 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
meaningful evaluation result, i.e., it is the smallest security requirement recognized in ISO/IEC
15408. The assurance elements are classified into three groups:



Developer action elements: The activities to be performed by the developer.
Content and presentation of evidence elements: The evidence required what the
evidence shall demonstrate and what information the evidence shall convey.
Evaluator action elements: The activities that shall be performed by the evaluator.
A key aspect in this standard is the Evaluation Assurance Level (EAL). It is a numerical value that
goes from 1 to 7 and that quantifies the assurance of a certain TOE at the end of the evaluation.
Table 3 lists the seven EALs and the assurance implicit by each level.
Level
EAL 1
EAL 2
EAL 3
EAL 4
EAL 5
EAL 6
EAL 7
Meaning
Functionally tested
Structurally tested
Methodically tested and checked
Methodically designed, tested and reviewed
Semi-formally designed and tested
Semi-formally verified design and tested
Formally verified design and tested
Table 3 – Common Criteria Evaluation Assurance Levels (EAL). © ISO/IEC
For a certain class and family, different assurance components apply depending on the EAL
required. The Table 4 – Evaluation assurance level summary. © ISO/IECtaken from the ISO/IEC
15408-3:2008 standard represents this point. The components defined inside a family are
identified by a number starting from 1 and upwards. The number in the table represents for
each family which is the assurance component that has to be followed for each EAL. Thus, for
some families, the same component applies, but for others, the components to be used differ
from one EAL to another. The meaning of each class and family and the elements that form
each component are depicted in the aforementioned standard.
GA 730640
Page 35 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Table 4 – Evaluation assurance level summary. © ISO/IEC
The ISA/IEC 15408 – 3, in addition to defining the assurance level of a single TOE, defines the
Composed Assurance Packages, that consist in three different packages of requirements to be
applied to composed TOEs, which are comprised of components that have gone through TOE
evaluation. In this case, three levels are defined: level A (CAP-A), level B (CAP-B) and level C
(CAP-C). The meaning of each level is defined in Table 5. Depending on the aimed level, different
requirements will apply per each assurance class and family. A summary of the assurance
components to be applied per assurance class and family for each CAP is shown in theTable 6
Table 6 taken from the ISO/IEC 15408-3:2008 standard.
Level
CAP-A
CAP-B
CAP-C
Meaning
Structurally composed
Methodically composed
Methodically composed, tested and reviewed.
Table 5 – Composition Assurance Levels. © ISO/IEC
GA 730640
Page 36 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Table 6 – Composition assurance level summary. © ISO/IEC
The SARs are quite generic requirements. They specify the action to be carried out, but they do
not indicate how to bring them to practice. Some examples of assurance elements
(requirements) are:




The developer shall provide a statement of security objectives.
The developer shall provide a functional specification.
The evaluator shall determine that the functional specification is an accurate and
complete instantiation of the SFR.
The evaluator shall execute all tests in the test documentation to verify the developer
test results.
When defining a ST or PP, a subset of all the SARs has to be selected. The standard provides
some fixed operations that allow the ST/PP writer to modify the SARs (assignment, selection,
iteration and refinement). In addition SARs have dependencies among them, which signifies that
if an ST/PP uses that SAR, it generally needs to use those other SARs as well.
GA 730640
Page 37 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
9.2.2. Target audience
CC is suited for:




Consumers: Through the definition of PP, consumers can satisfy their needs through the
evaluation process described in the standard.
Developers and Product Vendors: complying with a PP, developers and vendors ensure
the requirements needed by users. In addition, companies wanting to validate or certify
their product will find the elements to fulfil for.
Certifiers/Evaluators: third-party companies can provide certificates through
independent evaluation.
Accreditors and approvers: institutions and authorities can define the EAL needed for a
certain IT system to guarantee security functions to be covered.
9.2.3. Framework focus
The ISO/IEC 15408-3 does not provide a concrete secure-by-design procedure that has all the
phases of the development of a product clearly defined. Instead, it defines a big amount of
requirements to be fulfilled from which a subset will be chosen for each ST or PP. In addition,
these requirements are generic and do not specify in a concrete way how to carry out the
different tasks. This means that the secure-by-design principle should be defined taking into
mind all the selected SARs and checking that they are fulfilled. In other words, it gives certain
“freedom” in the definition of the security by design strategy, but on the other hand, it specifies
a big number of procedural requirements to be satisfied by the strategy.
9.2.4. Type of requirements
Target of Evaluation (TOE): is defined as a set of software, firmware and/or hardware possibly
accompanied by guidance. Furthermore, the TOE may be an IT product, a part of an IT product,
a set of IT products, a unique technology that may never be made into a product, or a
combination of these.
A Security Target (ST) is a complete and rigorous description of a security problem for a certain
TOE. It contains among other aspects, the TOE description, threats, assumptions, security
objectives, security requirements, and rationales.
Another important aspect of CC is the Protection Profiles (PP). Whereas an ST always refers to a
specific TOE (a concrete product), a PP is intended to describe a TOE type (e.g. a firewall). The
same PP may therefore be used as a template for many different STs. In the definition of the ST,
conformance to a certain PP can be addressed.
GA 730640
Page 38 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
The security requirements in CC are divided into two groups: the Security Functional
Requirements (SFR) and the Security Assurance Requirements (SAR). The firsts are technical
requirements to be addressed by the TOE in order to counter the threats and fulfil the security
objectives. The SARs, on the other hand, define activities to be carried out to provide assurance
in the correctness of the TOE, i.e. their fulfilment help in reducing vulnerabilities in the TOE by a
correctly defined development process. It is worth highlighting that measures regarding the
operational environment (human security guards, procedures…) are not addressed in these
requirements and consequently the ISO/IEC 15408 does not consider assessment of those
measures. However, it does specify that the operational environment measures, despite not
being assessed, should be defined among the security objectives to be described in the ST.
In summary, ISO/IEC 15408 standard defines a model at organizational and procedural level to
create Protection Profiles which will gather the security requirements for the product assessed.
9.3. ISO/IEC 27034 (includes ISO/IEC 27001/2/5)
Note: ISO/IEC 27001/2/5 analysis is included in section 0.
9.3.1. Scope of the standard
ISO/IEC 27034 is a multi-part standard aiming at defining processes for considering security
along the application lifecycle, that are in line with other standards of the ISO/IEC family. The
standard ISO/IEC 27034 provides guidance for organizations in integrating security into the
processes used for managing their applications and explicitly takes a process-oriented approach
to specifying, designing, developing, testing, implementing and maintaining security functions
and controls in application systems. An overview of how ISO/IEC 27034 is associated with other
ISO/IEC standards is shown in Figure 4 - Relationship to other ISO/IEC standards. © ISO/IEC
GA 730640
Page 39 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Figure 4 - Relationship to other ISO/IEC standards. © ISO/IEC
Rather than outlining precise security control requirements this multi-part standard defines
processes to develop a set of Application Security Controls (ASC Library) depending on the
business, regulatory and technological context of the application. An application security control
is defined, according to the standard, as a data structure containing a precise enumeration and
description of a security activity and its associated verification measurement to be performed at
a specific point in an application's life cycle.
The requirements and processes specified in ISO/IEC 27034 are not intended to be implemented
in isolation but rather integrated into an organization's existing processes.
It has to be noted that at the time of writing the summary, the vast majority of the multi-part
standard, have not yet been published.
GA 730640
Page 40 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Figure 5 – ISO/IEC 27034 scope. © ISO/IEC
9.3.2. Target audience
It is aimed at architects, analysts, programmers, testers, IT teams, data base administrators,
admins, etc., who need to know when and which Application Security Controls should be
applied, who integrate Application Security Controls in their activities, who assure that
Application Security Controls meet the requirements of associated measurements, who get
access to tools and best practices and who facilitate peer review. It can also be used by auditors,
in order to know the scope and process of verification measurements for the corresponding
Application Security Controls, to make audit results repeatable, to identify verification
measurements which can generate supporting evidence to demonstrate that the application has
reached the required level of trust authorized by the management and standardize the
application security verification.
9.3.3. Framework focus
It introduces definitions, concepts, principles and processes involved in application security in
order to establish an Application Security Management Process (ASMP) for an organization. The
standard defines “application security” not as a state of security but as a process an
organization can perform for applying controls and measurements to its applications in order to
manage the risk of using them. Due to the detachment with any Software Life-Cycle, ISO/IEC
27034 “Life cycle reference model” is rather an organisation-specific “software assurance
programme” than a proper development software life cycle.
GA 730640
Page 41 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
9.3.4. Type of requirements
Mainly process-oriented and organizational requirements:









Organization and user’s data
Application data
Roles and permissions
Application specifications
Technological context
Processes involving the application
Application life cycle processes
Regulatory context
Business context
9.3.5. ISO/IEC 27001/2/5
9.3.5.1. Scope of the standard
The standard ISO/IEC 27005:2011 provides guidelines for information security risk management
and is designed to assist the satisfactory implementation of information security based on a risk
management approach.
The standard ISO/IEC 27005:2011 doesn't specify, recommend or even name any specific risk
management method. It does however imply a continual process consisting of a structured
sequence of activities, some of which are iterative:





Establish the risk management context;
Quantitatively or qualitatively assess relevant information risks;
Treat the risks appropriately, using those ‘levels of risk’ to prioritize them;
Keep stakeholders informed throughout the process;
Monitor and review risks, risk treatments.
Figure 6 – Illustration of the continual security risk assessment process.© ISO/IEC provides the
process workflow for the continual risk assessment method proposed.
GA 730640
Page 42 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Figure 6 – Illustration of the continual security risk assessment process.© ISO/IEC
9.3.5.2. Target audience
This standard ISO/IEC 27005:2011 is relevant to managers and staff concerned with information
security risk management within an organization and, where appropriate, external parties
supporting such activities.
This International standard is applicable to all types of organizations (e.g. commercial
enterprises, government agencies, non-profit organizations) which intend to manage risks that
could compromise the organization’s information security.
GA 730640
Page 43 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
9.3.5.3. Framework focus
It introduces definitions, concepts, principles and processes involved in information security risk
management in order to identify organizational needs regarding information security
requirements and to create an effective information security management system (ISMS).
Information security risk management should be a continual process. The process should
establish the external and internal context, assess the risks and treat the risks using a risk
treatment plan to implement the recommendations and decisions.
9.3.5.4. Types of requirements
Mainly process and requirements in information security risk management:








Criteria of risk management approach, risk evaluation, risk acceptance and impact
criteria
Scope and boundaries of information security risk management
Organization for information security risk management
Information security risk assessment process
▫ Risk identification
▫ Risk analysis
▫ Risk evaluation
Information security risk treatment
▫ Risk modification
▫ Risk retention
▫ Risk avoidance
▫ Risk sharing
Information security risk acceptance
Information security risk communication and consultation
Information security risk monitoring and review
9.4. NIST CSF & Other NIST Standards
9.4.1. Scope of the standard
The National Institute of Standards and Technology (NIST) is a United States of America (U.S)
organisation and part of the Department of Commerce. Founded in 1901 it provides
measurement and standard based publications and frameworks that can be applied to the
smallest of technology to the largest and most complex creations. It is broken down into seven
GA 730640
Page 44 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
laboratories with the key one this work stream is focused on being the Information Technology
Laboratory which has a division looking at Computer Security.
Within the general Computer Security domain this is further broken down into elements related
to Cyber Security, with the two key elements that were under consideration as part of the
secure-by-design approach being assessed being:


Cyber-Physical Systems (CPS) or “smart” systems are co-engineered interacting
networks of physical and computational components. These systems will provide the
foundation of our critical infrastructure (e.g., smart grid, transportation), form the basis
of emerging and future smart services (e.g., smart city services), and improve our quality
of life in many areas (e.g., healthcare). ITL’s research helps to remove barriers to
progress in CPS – by advancing measurement, standards, tools, and guidance in areas
such as cybersecurity, privacy, networking, timing, and IT infrastructure. ITL works
closely with industry, government, and academia to advance the technical underpinnings
that are necessary to reap the benefits of CPS.
Cybersecurity - ITL is responsible for developing standards, guidelines, tests, and metrics
for the protection of non-national security federal information and communication
infrastructure. While developed for federal agency use, these resources are frequently
voluntarily used by non-federal organizations, including industry and academia, because
they provide highly adaptable, risk based, and cost-effective approaches to securing
systems. These standards and guidelines are developed in an open and transparent
manner that engages diverse stakeholders and leverages the contributions of diverse
technical experts from around the world. Our security automation project has made
important strides towards standardizing and automating critical information security
elements such as software vulnerabilities and secure configurations. The National
Vulnerability Database, the National Checklist Program, and the technical standards that
support them, are critical components in ensuring that security management is effective
and efficient.
The NIST Computer Security Division has published a number of standards with the main ones
being reviewed as part of this initial piece of work coming under the SP800 and SP1800 series.
At a high level the following standards were reviewed:

NIST SP 800-53r4 Security and Privacy Controls for Federal Information Systems and
Organizations, 2013 Contains 18 control families (similar to ISO 27001/2)
▫ Access control, awareness and training, Audit and Accountability, Security
Assessment and Authorization, Configuration Management, Contingency Planning,
Identification and Authentication, Incident Response, Maintenance, Media
Protection, Physical and Environmental Protection, Planning, Personnel Security,
GA 730640
Page 45 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard





Risk Assessment, System and Services Acquisition, Systems and Communications
Protection, System and Information Integrity, Program Management
NIST SP 800-82r2 Guide to Industrial Control Systems (ICS) Security, 2015
▫ Supervisory Control and Data Acquisition (SCADA) Systems, Distributed Control
Systems (DCS), and Other Control System Configurations such as Programmable
Logic Controllers (PLC)
NIST SP 800-30r1 Guide for Conducting Risk Assessments (2012)
▫ Defines risk assessment fundamentals and process as well as possible methods e.g.
threat assessment, vulnerability assessment, security control assessment covered by
NIST SP 800-53A
▫ It also provides valuable information and templates about threat sources, threat
events, vulnerabilities and predisposing conditions, likelihood of occurrence, impact,
risk determination, informing risk response, risk assessment reports
NIST SP 800-37r1 Guide for Applying the Risk Management Framework to Federal
Information Systems, A Security Life-Cycle Approach (2010)
▫ CATEGORISE system, SELECT controls, IMPLEMENT controls, ASSESS controls,
AUTHORIZE system, MONITOR controls
NIST SP 800-39r1 Managing Information Security Risk, Organization, Mission, and
Information System View (2011)
▫ Describes concept of trust and trustworthiness of systems
NIST SP800-160 is a new standard from NIST (November 2016) that provides security
related implementation guidance for the standard ISO/IEC/IEEE 15288:2015 “Systems
and software engineering – system life cycle processes”.
The other element to this review of NIST standards was to look at the NIST Cyber Security
Framework. This framework builds upon the existing publications and standards and practices
for critical infrastructure organisations to help them better manage and reduce cybersecurity
risk. In addition to helping organisations manage and reduce risks, it was designed to foster risk
and cybersecurity management communications amongst both internal and external
organisational stakeholders.
9.4.2. Target audience
The framework is not designed to fit all organisations and its aim and purpose allows it to be
customised to meet sector and individual organisational needs. Specifically it should not be
implemented as an un-customised checklist or a one-size fits all approach for all critical
infrastructure organisations. If approached in the right manner the Framework will help an
organisation to better understand, manage, and reduce its cyber security risks. It will assist in
GA 730640
Page 46 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
determining which activities are most important to assure critical operations and service
delivery. In turn, that will help to prioritise investments and maximize the impact of each dollar
spent on cybersecurity and provides a common language to address cyber security risk
management; it is especially helpful in communicating inside and outside the organisation. That
includes improving communications, awareness, and understanding between and among IT,
planning, and operating units, as well as senior executives of organisations.
Specifically for NIST 800-160 the target audience is:








Individuals with systems engineering, architecture, design, development, and integration
responsibilities;
Individuals with software engineering, architecture, design, development, integration,
and software maintenance responsibilities;
Individuals with security governance, risk management, and oversight responsibilities;
Individuals with independent security verification, validation, testing, evaluation,
auditing, assessment, inspection, and monitoring responsibilities;
Individuals with system security administration, operations, maintenance, sustainment,
logistics, and support responsibilities;
Individuals with acquisition, budgeting, and project management responsibilities;
Providers of technology products, systems, or services; and
Academic institutions offering systems security engineering and related programs.
9.4.3. Framework focus
Although the NIST publications and standards provides a good level of information detail, not all
of it is relevant to European standards, regulations and legal requirements as it is very U.S.
centric. However, upon review and discussion it was agreed that elements of the NIST library
could be used to further develop the secure-by-design framework by complementing the
chosen framework if required.
Regarding NIST 800-160: it could be used as a guidance to complement ISA/IEC 62443 on those
areas where there is not enough detail. Specifically, it may be usable for the future
development of prototypes related to the cyber security work. The security considerations are
provided as systems security engineering activities and tasks and they are aligned with and
developed as security extensions to the system life cycle processes in ISO/IEC/IEEE 15288 –
“Systems and software engineering – System life cycle processes”.
9.4.4. Type of requirements
The Cyber Security core Framework (NIST CSF) provides a set of activities to achieve specific
cybersecurity outcomes, and references examples of guidance to achieve those outcomes. The
GA 730640
Page 47 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Core is not a checklist of actions to perform. It presents key cybersecurity outcomes identified
by industry as helpful in managing cybersecurity risk. The core comprises the following key
elements (detail sitting behind each sub-category):
Figure 7 – NIST CSF key elements. © NIST
GA 730640
Page 48 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
System Life Cycle Processes
Life Cycle
Stages
Organisation Project
Enabling Processes
Technical Management
Processes
Technical Processes
 Acquisition
 Supply
 Life Cycle Model
Management
 Infrastructure
Management
 Portfolio Management
 Human Resource
Management
 Quality Management
 Knowledge
Management
 Project Planning
 Project Assessment
and Control
 Decision Management
 Risk Management
 Configuration
Management
 Information
Management
 Measurement
 Quality Assurance
 Business or Mission
Analysis
 Stakeholder Needs
and Requirements
Definition
 System
Requirements
Definition
 Architecture
Definition
 Design Definition
 System Analysis
 Implementation
 Integration
 Verification
 Transition
 Validation
 Operation
 Maintenance
 Disposal
Concept
Development
Application
Agreement
Processes
Production
Utilization
Support
Retirement
Table 7 – “System Life Cycle Processes” and “Life Cycle Stages” from NIST 800-160. © NIST
9.5. ANSSI
9.5.1. Scope of the standard
ANSSI is the national cybersecurity agency of France. As a national authority, ANSSI reports to
the Secretary General for Defence and National Security (Secrétaire Général de la Défense et de
la Sécurité Nationale - SGDSN). The SGDSN assists the Prime Minister in fulfilling his
responsibilities in matters of national defence and security. There is no standard as such that
ANSSI has developed specifically for the railway industry but the agency regular publishes best
practices and guidelines for the critical infrastructure operators.
GA 730640
Page 49 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
9.5.2. Target audience
The intended audience for ANSSI documents and publications would be a variety of actors in
organisations. Depending on the nature of the industrial activity the set of regulations and
security rules are different. The documents of ANSSI are intended for:





Security Managers
Security Administrators
Auditors
Developers
Suppliers
9.5.3. Framework focus
As mentioned, ANSSI does not publish any framework; it does however publish sets of
regulations, best practices and guidelines that can be used independently based on the needs of
the organisations. The focus spread from security management activities to more technical
activities such as network level configurations. The documents of ANSSI however are publish as
guidelines and best practices, hence the requirements are very highly level and the respective
organisations that intend to or must comply to the requirements of ANSSI and the French law
have the responsibility to define more detailed actions.
9.5.4. Type of requirements
There are no requirements as such that ANSSI imposes, however according to the LPM (Loi de
Programmation Militaire) there are mandatory requirements that Critical Infrastructure
Operators must comply to since it is the French law. These high-level legal requirements include:




Identification of critical infrastructure information systems according to the criteria
defined by ANSSI.
Notifications of security incidents that affect the critical infrastructure operators. The
types of incidents to be notified are defined in the French legislation.
Compliance to predefined security rules defined by French legislation by each critical
infrastructure operators according to specific industry activity.
Auditing exercise by ANSSI to verify compliance of the security controls will be
conducted by ANSSI experts, authorised government agencies or qualified suppliers.
The ANSSI also published best practice security rules that all critical infrastructure operators
must already have in place or have planned to implement in the future. These include:
GA 730640
Page 50 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard













Information security policy
Security qualification
Security architecture
Security assurance
Log management
Detection mechanism
Incident management
Alert management
Crisis Management
Identity & access management
Privilege Management
Defence-in-depth
Indicators
9.6. Microsoft SDL
9.6.1. Scope of the standard
The Security Development Lifecycle (SDL, not to confuse with the Microsoft SDLC “Software
Development Life Cycle) is a software development process that helps companies to build more
robust software and address security compliance requirements through multiple phases in
which security software practices are defined into the development lifecycle. Together with the
SDL framework, Microsoft provides tools able to check and assist in the different phases of the
lifecycle (Threat Modelling tool, set of Code Security Analysers, etc.).
From a secure-by-design point of view, the seven phases of the standard cover most of the
requirements necessary to develop a secure software product under Microsoft framework.
These phases are:







Training
Requirements
Design
Implementation
Verification
Release
Response
GA 730640
Page 51 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
9.6.2. Target audience
The Microsoft Security Development Lifecycle framework is intended for the whole software
development team, including:




Analysts
Developers
Testers
Project Managers
9.6.3. Framework focus
The key principles for the framework are referred to as SD3+C – Secure by Design, Secure by
Default, Secure in Deployment and Communications. Each of the key principles imposes
different requirements in different phases on the development lifecycle. All of those
requirements aim to minimize security-related vulnerabilities in the design, code, and
documentation and to detect and eliminate vulnerabilities as early as possible in the
development life cycle. These improvements reduce the number and severity of security
vulnerabilities and improve the protection of users’ privacy.
9.6.4. Type of requirements
The types of requirements defined in the standard for every phase are:








Recommended trainings for target audience
Security requirements and recommendations
Privacy requirements and recommendations
Resources for further documentation in requirements
Process to adapt SDL to Development methodologies (Agile)
Technical coding rules
Examples of Security Bug Bars (Security levels of SDL)
Checklists for software development methodology
GA 730640
Page 52 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Figure 8 - Secure software development process model at Microsoft. © Microsoft
9.7. Coding rules
9.7.1. Scope of the standard
Due to the multiple existent languages for any particular system that manufacturers may use to
program its software, there have been only referenced standards and tools for three of the
main languages used in Industrial Control Systems: C, C++ and ADA.
Such standards, resources and tools, does not assure to a vendor developers or manufacturers
have developed a secure hardware, rather it shall be considered as a guideline and support to
encourage programmers to follow a uniform set of rules and guidelines determined by the
requirements of the project and organization, rather than by the programmer’s familiarity or
preference. Once established, these standards can be used as a metric to evaluate source code
(using manual or automated processes) to determine compliance with the standard.
Of all standards evaluated the technical specification ISO/IEC TS 17961:2013 “C secure” is the
most accepted reference in secure development. It is focused in C, but it can be used in most of
cases to C++ language due to its strong relation. Most of standards and guidelines in securecoding cover amend and/or map ISO/IEC TS 17961:2013 as MISRA (Motor Industry Software
Reliability Association) guidelines or NASA, which at the same time hierarchically complies with
MISRA practices.
Note: Some coding practices are already enforced by the EN 50128 “Software for Railway control
and protection systems” standard in order to comply with the targeted Safety Integrity Levels
(SIL).
GA 730640
Page 53 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
Table 8 - Comparison of ISO/IEC TS 17961 with other standards. © ISO/IEC
The CWE (Common Weakness Enumeration) set of software weaknesses allow to enable
effective discussion, description, selection and use of software security tools and services that
can find these weaknesses in source code and operational systems.
CERT (a Software Engineering Institute division) is developing secure-coding standards for
commonly used programming languages such as C, C++, and Java through a broad-based
community effort that includes members of the software development and software security
communities. CERT and CWE maintains a “secure-coding relationship” where CWE provides a
comprehensive repository of know weaknesses, while CERT secure-coding standards identify
insecure programming constructs that, if present in code, could expose a weakness or
vulnerability in the software. They publish numerous tools for a range of activities and checklists
in secure-coding.
9.7.2. Target audience
The main target audience for these coding rules are mainly Software Developers, Software
Project Managers and Software Testers (for the tools). In addition, it could be of great interest
also for software acquirers to be able to define the software requirements to reach higher levels
of reliability, robustness and resistance to attacks.
9.7.3. Framework focus
The standards and technical specifications evaluated should be used as reference on software
development lifecycles and not as a global standard to follow for any software development
team.
GA 730640
Page 54 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
9.7.4. Type of requirements
Firstly, it must be differenced the concept of “Language” standard with “Secure development”
standard, guideline, best practices or technical specification. The former establish the definition
and requirements of a programming language, the latter are based in diagnose to insecure code
and/or provides best practices beyond the requirements of a language standard to avoid known
errors or attacks due to flaws in code.
Language standards
These standards do not provide guideline to secure-coding. Just requirements when
programming in such languages:



Standard in C language (C11): ISO/IEC 9899:2011
Standard in C++ language: ISO/IEC 14882:2014
Standard in ADA language: ISO/IEC 8652:1995/Amd 1:2007
Secure development standards guidelines and resources
Today’s most standardised reference in secure development is the following technical
specification:

ISO/IEC TS17961:2013 “C secure” specifies rules for secure-coding in the C programming
language and includes code examples for each rule.
Additionally:

ISO/IEC TR 24731-1/2 provides alternative functions for the C Library (as defined in
ISO/IEC 9899:1999) that promote safer, more secure programming and also contains
functions that address insecurities with the C input-output facilities.
From MISRA:




MISRA C:2012: Guidelines for the Use of the C Language in Critical Systems
MISRA C++:2008: Guidelines for the Use of the C++ Language in Critical Systems
Guidelines for safety analysis of vehicle based programmable systems. Link:
https://www.misra.org.uk/Publications/tabid/57/Default.aspx
Many others in MISRA site: https://www.misra.org.uk
From NASA:

JPL Institutional Coding Standard for the C Programming Language (2009). Link:
http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
From CERT:
GA 730640
Page 55 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard

SEI CERT C/C++ Coding Standard (2016 Edition) identifying the root causes of today’s
most widespread software vulnerabilities, how they can be exploited, the potential
consequences, and secure alternatives.
Secure code analysis tools (sample)
Commercial solutions:





Astrée (tailored towards safety-critical embedded code) used by Airbus. Link:
https://www.absint.com/
CodeSonar (focused on embedded, M2M, and IoT equipment markets) used by NASA.
Link: https://www.grammatech.com/products/codesonar
Coverity (used by USA Gov., NASA, CERN, etc.). Link: http://www.coverity.com/
AdaTEST 95 is a unit and integration testing tool, enabling developers to verify standard
compliant or business critical code on host native and embedded target platforms. Link:
https:/www.qa-systems.com/tools/adatest-95/deep-code-coverage/
GNATcoverage is a specialized tool that analyses and reports program coverage. Link:
http://www.adacore.com/gnatcoverage/
Free solutions from CERT Division (Software Engineering Institute):




Clang Thread Safety Analysis mainly used to declare and enforce thread safety policies
in C and C++ programs. Link: http://www.cert.org/secure-coding/tools/clang-threadsafety-analysis.cfm
Compiler-Enforced Buffer Overflow Elimination is a research prototype that prevents
buffer overflows in multithreaded code and has additional features not found in other
memory safety mechanisms. Link: http://www.cert.org/secure-coding/tools/compilerenforced-buffer-overflow-elimination.cfm
Rosecheckers performs static analysis on C/C++ source files. It is designed to enforce the
rules in the CERT C Coding standard. Link: http://www.cert.org/securecoding/tools/rosecheckers.cfm
Secure Coding Validation is a suite set of tests developed to validate the rules defined in
ISO/IEC TS 17961. Link: http://www.cert.org/secure-coding/tools/validation-suite.cfm
GA 730640
Page 56 of 57
X2Rail-1
Deliverable D8.1
Selection of the “Secure-by-design” standard
10. Appendix C – Comments
Figures and tables added from ISA/IEC 62443 series have the permission from ISA to be used in
this document.
The evaluation of the ISA/IEC 62443-4-1 and ISA/IEC 62443-4-2 has been done with the most
current published document: “Draft 3, Edit 11, March 2016” for ISA/IEC 62443-4-1, and “Draft 4,
Edit 1 from January 12, 2017” for ISA/IEC 62443-4-2.
GA 730640
Page 57 of 57