DEG203350v0.0.9(2015-01-29)

Methods for Testing and Specification (MTS);

Security Assurance Lifecycle

ETSI GUIDE

DEG 203 350 v0.0.9 (2015-01-29)

1

Reference

DEG/MTS-203250

Keywords

Security; Testing; Assurance

ETSI

650 Route des Lucioles

F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C

Association à but non lucratif enregistrée à la

Sous-Préfecture de Grasse (06) N° 7803/88

Important notice

Individual copies of the present document can be downloaded from:

The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at

If you find errors in the present document, please send your comment to one of the following services:

Copyright Notification

No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute yyyy.

All rights reserved.

DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
3GPPTM and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.

Reproduction is only permitted for the purpose of standardization work undertaken within ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

Contents

Intellectual Property Rights

Foreword

1Scope

2References

2.1Normative references

2.2Informative references

3Definitions, symbols and abbreviations

3.1Definitions

3.2Abbreviations

4Security in the system lifecycle

4.1Definition

4.2Approach

4.2.1Contexts

4.2.2Consistency

4.2.3Continual Improvement

4.3Definition of Lifecycle

4.4Lifecycle Phase Security Activities

4.4.1Stakeholder Requirement Definition

4.4.2Requirements Analysis

4.4.3Architectural Design

4.4.4Implementation

4.4.5Integration

4.4.6Verification

4.4.7Transition

4.4.8Validation

4.4.9Operation

4.4.10Maintenance

4.4.11Disposal

5Risk Assessment Workstream

5.1Context

5.2Risk Management Methodology

6Specification Workstream

6.1Approach

6.2Context

6.3Security Architecture Framework

6.2Design dependencies

6.4Security design and implementation processes

6.4.1Asset and Adversity Analysis (AA)

6.4.2Risk Analysis (RA)

6.4.3Vulnerability Analysis (VA)

6.4.4Architectural Reference Model (ARM)

6.4.5Architectural Reference Case (ARC)

6.4.6Architectural Specification Case (ASC)

6.4.7Design and/or Effect Classes

6.4.8System Design

6.4.9Traceable Implementation

6.4.10Integration and Configuration

6.5Assurance and Testing processes

6.5.1Testing

6.5.2Assurance Evidence

6.6Post-implementation processes

6.6.1Commissioning

6.6.2Operation

6.6.3Disposal

7Validation and/or Verification Workstream

7.1Context

7.2Approach

8Assurance Evidence Workstream

8.1Context

8.2Approach

Annex A (informative): Security contexts and principles

Annex B (informative): Security Architectural Components

Annex C (informative): Bibliography

History

Intellectual Property Rights

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSISR000314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSISR000314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

Foreword

This final draft ETSI Guide (EG) has been produced by ETSI Technical CommitteeMethods for Testing and Specification (MTS), and is now submitted for the ETSI standardsMembership Approval Procedure.

1Scope

The present document provides a guide to the application of security capabilities in systems across the lifecycle in such a way to maximise the overall assurance of the capabilities offered by the system’s security measures.

The present document considers the standardisation domain and gives examples of the application of the guidance to the wider development and deployment community.

2References

References are either specific (identified by date of publication and/or edition number or version number) or nonspecific.For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

Referenced documents which are not found to be publicly available in the expected location might be found at

NOTE:While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.

2.1Normative references

The following referenced documents are necessary for the application of the present document.

Not applicable.

2.2Informative references

The following referenced documents arenot necessary for the application of the present document but they assist the user with regard to a particular subject area.

[i.01]ISO/IEC 13335: "Information technology - Guidelines for the management of IT security"

[i.02]BS PAS 754:2014: “Trustworthy Software Framework”

[i.03]ISO/IEC 12207-2008: “Systems and software engineering -- Software life cycle processes”

[i.04]ISO/IEC 15288-2008: “Systems and software engineering -- System life cycle processes”

[i.05]ETSI EG 202 387: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Security Design Guide; Method for application of Common Criteria to ETSI deliverables".

[i.06]ETSI TS 102 165-1 (V4.2.1): "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Methods and protocols; Part 1: Method and proforma for Threat, Risk, Vulnerability Analysis".

[i.07]ETSI TS 102 165-2: " Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Methods and protocols; Part 2: Protocol Framework Definition; Security Counter Measures"

[i.08]ETSI TR 197023: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Security Assurance Profile for Secured Telecommunications Operations"

[i.09]ETSI TR 187 011: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Security; Application of ISO-15408-2 requirements to ETSI standards - guide, method and application with examples"

[i.10]ISO/IEC 15408: "Information technology - Security techniques - Evaluation criteria for IT security"

[i.11]John A. Zachman “A Framework for Information Systems Architecture“, IBM Systems Journal 1987 (G321-5298), Vol 26, No 3

[i.12]ETSI TS 101583:“Security Testing Terminology and Concepts”

[i.13]ISO/IEC 15026-2-2011: “Systems and software engineering -- Systems and software assurance -- Part 2: Assurance case”

3Definitions, symbols and abbreviations

3.1Definitions

For the purposes of the present document, the following terms and definitions apply:

Adversity:Superset of external factors likely to have undesirable effects on software, being the aggregate of the set of hazards (undirected events) and threats (directed, deliberate, hostile acts) [NATO STO]

Defect:Non-fulfilment of an explicit or implicit requirement related to an intended or specified use [BS PAS754:2014]

Deferral:Documented and risk managed decision to not resolve a defect or deviation [BS PAS754:2014]

Deviation:Non-conformity with specification [BS PAS754:2014]

Exploitability Assessment: Comprehensive and directed review of a system for susceptibilities that could be exploited by an attacker

Penetration Test: Comprehensive and directed review of a system by suitably qualified personnel for susceptibilities that could be exploited by an attacker

Risk management: Coordinated activities to direct and control an organization with regard to risk [ISO 22301:2012]

Resilience Testing:Review of a system to assess survivability in the face of realised exploitation attempts

Security Requirement:Specification of the required security for the system [ISO/IEC 27001]

Susceptibility: Existence of a generic vulnerability in a particularimplementation such that it could lead to a failure [BS PAS754:2014]

Susceptibility Review: All activities that explore instantiation of Vulnerabilities in a system

Susceptibility Scan: An automated scan for presence of Vulnerabilities in an instantiated system

Susceptibility Test: Any Validation and/or Verification activity that explores instantiation of Vulnerabilities in a system

System:Combination of interacting elements organized to achieve one or more stated purposes [ISO/IEC 15288]

Threat: A potential for violation of security, which exists when there is a circumstance, capability, action, or event that could cause harm

Vulnerability: Any weakness that can be used to cause a failure in the operation of the software

Vulnerability Review: Consideration of newly reported exploitable Vulnerabilities for relevance as potential Susceptibilities

Weakness: A shortcoming or imperfection in the software code, design, architecture, or deployment that, could, at some point become a vulnerability, or contribute to the introduction of other vulnerabilities

3.2Abbreviations

For the purposes of the present document, the abbreviationsapply:

AA:Asset and Adversity Analysis

ARC:Architectural Reference Case

ARM:Architectural Reference Model

ASC:Architectural Specification Case

DC:Design Class

EA:Enterprise Architecture

EA:Exploitability Assessment

EC:Effect Class

NFR:Non-Functional Requirement

PDCA:Plan Do Check Act

PP:Protection Profile

PT:Penetration Testing

RA:Risk Analysis

RT:Resilience Testing

SAF:Security Architecture Framework

SEF:Security Enforcing Functions

SR:Susceptibility Review

SS:Susceptibility Scan

ST:Susceptibility Testing

TISPAN:Telecommunications and Internet converged Services and Protocols for Advanced Networking

TVRA:Threat, Risk, Vulnerability Analysis

VA:Vulnerability Analysis

VR:Vulnerability Review

4Securityin the system lifecycle

4.1Definition

Security is most often defined as being the ability of a system to give assurance of the following 3 key attributes of a product or service:

  • Confidentiality

-ensuring that information is accessible only to those authorized to have access

  • Integrity

-safeguarding the accuracy and completeness of information and processing methods

  • Availability

-property of beingaccessible and usable on demand by an authorized entity ISO/IEC13335-1[i.01].

Underpinning these attributes are the contained attributes authenticity and authority, and underpinning these is identity.It should be recognised that a single definition of security is largely infeasible without also defining its context and as such to say that a system of product is secure is wrong without defining in some detail the context in which that assurance is given. This differentiates the tools for verification and validation in a security context from the same tools used in a conventional state-machine based model as failure in the security of a system may not be directly related to a specific element, e.g. the authentication protocols used in a system may provably work but the system may be broken if the authentication protocols can be bypassed, thus proof of the correctness of a security measure may be insufficient to give assurance of the security of the system.

4.2Approach

4.2.1Contexts

In order to achieve Security, it needs to be considered in 4 contexts:

  • Governance – the processes and people needed for properly administering secure delivery of a product or service
  • Risk – the factors which could have a deleterious impact on secure delivery of a product or service
  • Controls – the principles and techniques used to reduce the risk to secure delivery of a product or service, which can be further subdivided as:

-Personnel Controls

-Physical Controls

-Procedural Controls

-Technical Controls

  • Compliance – the processes and people needed for ensuring secure delivery of a product or service is proceeding as intended

A summary of Principles for realisation of secure products and services, as derived from UK’s Trustworthy Software Framework (TSF) [i.02] is provided at Annex A.

4.2.2Challenges

System problems are generally characterised as a one of three types:

  • Weaknesses, which are generic classes of potential deficiency in systems, such as buffer overflows in software
  • Vulnerabilities, which can be:

-the existence of a generic weakness in a particular platform, such as a buffer overflow occurring in a specific operating system;

-interactions between multiple elements that bypass intended controls;

-accidental actions of developers that result in defects and errors;

-deliberate actions of developers that bypass intended controls, such as trap doors that permit unauthorised access to the system.

  • Susceptibilities, which are the confirmed presence of one or more vulnerability within an implemented system, such as the presence of an operating system with a buffer overflow defect

Susceptibilities in systems stem from:

  • initial implementation;
  • changes such as from adding new facilities or the correction of detected errors (‘patching’);
  • use of utilities which may be capable of circumventing security measures

4.2.3Consistency

In order to achieve security through an extended lifecycle, a fundamental requirement is for Traceability, with a need for continuity of access to artefacts from earlier lifecycle stages.

In addition, due consideration is needed of Composability, with an understanding of the Risks and Dependencies, Assumptions and Assertions introduced as atomic components are composed into compound packages, packages are composed in compound products, products are composed into compound systems, and systems are composed into compound systems-of-systems.

4.2.4Continual Improvement

All activity to obtain security should be made on the basis of continual improvement, with the Plan-Do-Check-Act (PDCA) cycle[1] illustrated at Figure 1 being recommended as the underlying approach.


Figure 1: PDCA Cycle

4.3Definition of Lifecycle

There are many definitions of the Lifecycle for a product or service, from the very simple (Specification – Realisation – Use) to the complex. Probably the most widely accepted are those produced by ISO/IEC JTC1 SC7 as defined in ISO/IEC 12207 [i.03] and ISO/IEC 15288 [i.04].

As most systems are an amalgam of both software and other functionality, the ISO/IEC 15288 Lifecycle, is regarded as the most applicable for general use, which comprises of 11 phases:

  1. Stakeholder Requirement Definition
  2. Requirements Analysis
  3. Architectural Design
  4. Implementation
  5. Integration
  6. Verification
  7. Transition
  8. Validation
  9. Operation
  10. Maintenance

Maintenance can be considered to be a “mini-lifecycle”, potentially reflecting all preceding stages, and to be carried out successfully access to artefacts from the original development lifecycle will be a fundamental dependency.

  1. Disposal

Figure 2 provided ahigh level mapping of the ISO/IEC 15288 Lifecycle to 4 Security Workstreams:

  • Risk Management
  • Specification
  • Verification and/or Validation
  • Assurance Evidence

Figure 2: Security lifecycle activity diagram

4.4Lifecycle Phase Security Activities

A diverse selection of security activities are therefore required across the 4 Security Workstreams of Risk; Specification; Verification and/or Validation; and Assurance Evidence, which are summarised below and expanded on in the following sections which address the Security Workstreams individually.

4.4.1Stakeholder Requirement Definition

  • Product or System Architecture
  • Development or selection of Architectural Reference Model (ARM)
  • Product Assurance
  • Performance of Adversity (Hazard + Threat) Analysis
  • System Assurance
  • Asset & Adversity (Hazard + Threat) Analysis

4.4.2Requirements Analysis

  • Product or System Architecture
  • Development of Architectural Reference Case (ARC)
  • Selection of appropriate Design and/or Effect Class(es)
  • Product or System Assurance
  • Performance of Vulnerability Analysis

4.4.3Architectural Design

  • Product or System Architecture
  • Development of Architectural Specification Case (ASC)
  • Selection of appropriate Design and/or Effect Pattern(s) or Package(s)
  • Product Architecture
  • Development of Component Design
  • System Architecture
  • Development of System Design
  • Product or System Assurance
  • Performance of Risk Analysis
  • Development of Initial Assurance Case

4.4.4Implementation

  • Product or System Architecture
  • Implementation of selected Security Design(s) and/or Effect(s)
  • Selection of required Components
  • Product Architecture
  • Implementation of required Components
  • Product Assurance
  • Developer test of implemented Components
  • System Assurance
  • Developer review of testing of implemented Components

4.4.5Integration

  • Product or System Architecture
  • Integration of implemented Security Design(s) and/or Effect(s)
  • Integration and configuration of implemented Components
  • System Architecture
  • Integration and configuration of implemented Products
  • Product Assurance
  • Integration test of implemented Components
  • System Assurance
  • Integration review of testing of implemented Components and Products

4.4.6Verification

  • Product or System Assurance
  • Acceptance Test

4.4.7Transition

  • Product or System Architecture
  • Delivery
  • Product or System Assurance
  • Finalisation of Assurance Case
  • Product Assurance
  • Performance of Vulnerability Review
  • System Assurance
  • Performance of SusceptibilityReview(s)

4.4.8Validation

  • Product Assurance
  • Performance of Assurance Review
  • Performance of Release Review
  • System Assurance
  • Performance of Assurance and Acceptance Review
  • Performance of Commissioning Review

4.4.9Operation

  • Product or System Assurance
  • Risk Monitoring
  • System Assurance
  • Performance of Compliance Tests

4.4.10Maintenance

Maintenance can be considered to be a “mini-lifecycle”, potentially reflecting all preceding stages, and to be carried out successfully access to artefacts from the original development lifecycle will be a fundamental dependency.

In particular, consideration is needed of:

  • Product or System Architecture
  • Regular upkeep (Configuration and Patching)
  • Product or System Assurance
  • Revision of Risk Analyses
  • Update of Assurance Case
  • Performance of Compliance Reviews
  • Product Assurance
  • Performance of Assurance and Acceptance Review
  • Performance of Vulnerability Review
  • System Assurance
  • Performance of Susceptibility Review(s)

4.4.11Disposal

  • Product or System Assurance
  • Definition of Decommissioning Process
  • Update of Assurance Case
  • Performance of Compliance Reviews
  • System Assurance
  • Decommissioning Review
  • Disposal Review

ETSI

DEG 203 350 v0.0.9 (2015-01-29)

1

5Risk AssessmentWorkstream

5.1Context

Figure 3: Security activities in Risk Assessment workstream

Figure 3 shows the context of the Risk Assessment Workstream within the overall Architecture and Assurance Framework.

5.2Risk Management Methodology

ETSI have produced a number of documents relating to the Threat, Risk, Vulnerability Analysis (TVRA) processes, as a result of work on Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN), as detailed in EG 202 387 [i.05], TS 102 165-1 [i.06], TS 102 165-1 [i.07], TR 197 023 [i.08] and TS 187 011 [i.09].

The purpose of the TVRA is to determine how open to attack the system, or components of the system are. The resulting security architecture and security mechanisms are intended to maintain the system in a state of acceptable risk by removing the set of vulnerabilities that when attackedwill violate the level of acceptable risk.

As noted in TS 102 165-1 [i.06] one of the keys to a successful TVRA, and also of a successful system design, is the ability to show the relationship of objectives and requirements to the system design.

Figure 4 shows the dependencies between system objectives, system requirements and system design highlighting the interplay of security objectives and requirements.

Figure 4: Relationship between system design, objectives and requirements

For most systems the development of system requirements goes far beyond just security it is essential to ensure that the system design is itself robust and therefore has fully documented requirements across all its aspects.

The primary purpose of an ETSI TVRA is to support and rationalize security standardization, and to support and rationalize system design decisions, where the overall objective of the standard is to minimize risk of exploitation and attack of a compliant system when deployed. In order to consider this fully the TVRA method described in the present document addresses the impact of an attack on the system whereas ISO-15408 [i.10] primarily addresses the resistance to attack of the system. In this view the TVRA method compliments ISO-15408. A particular objective of the TVRA method is to prepare the justifications for security decisions and that may as a result be referenced in a Protection Profile (PP) for the security feature.