Guidance for developing security and privacy functional requirements based on ISO/IEC 15408

This document provides guidance for: — selecting and specifying security functional requirements (SFRs) from ISO/IEC 15408-2 to protect Personally Identifiable Information (PII); — the procedure to define both privacy and security functional requirements in a coordinated manner; and — developing privacy functional requirements as extended components based on the privacy principles defined in ISO/IEC 29100 through the paradigm described in ISO/IEC 15408-2. The intended audience for this document are: — developers who implement products or systems that deal with PII and want to undergo a security evaluation of those products using ISO/IEC 15408. They will get guidance how to select security functional requirements for the Security Target of their product or system that map to the privacy principles defined in ISO/IEC 29100; — authors of Protection Profiles that address the protection of PII; and — evaluators that use ISO/IEC 15408 and ISO/IEC 18045 for a security evaluation. This document is intended to be fully consistent with ISO/IEC 15408; however, in the event of any inconsistency between this document and ISO/IEC 15408, the latter, as a normative standard, takes precedence.

Lignes directrices pour l'élaboration des exigences fonctionnelles de sécurité et de confidentialité fondées sur l’ISO/IEC 15408

General Information

Status
Published
Publication Date
18-Oct-2018
Current Stage
9020 - International Standard under periodical review
Start Date
15-Oct-2021
Ref Project

Buy Standard

Technical specification
ISO/IEC TS 19608:2018 - Guidance for developing security and privacy functional requirements based on ISO/IEC 15408
English language
48 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

TECHNICAL ISO/IEC TS
SPECIFICATION 19608
First edition
2018-10
Guidance for developing security
and privacy functional requirements
based on ISO/IEC 15408
Lignes directrices pour l'élaboration des exigences fonctionnelles de
sécurité et de confidentialité fondées sur l’ISO/IEC 15408
Reference number
ISO/IEC TS 19608:2018(E)
ISO/IEC 2018
---------------------- Page: 1 ----------------------
ISO/IEC TS 19608:2018(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2018

All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may

be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting

on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address

below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TS 19608:2018(E)
Contents Page

Foreword ..........................................................................................................................................................................................................................................v

Introduction ................................................................................................................................................................................................................................vi

1 Scope ................................................................................................................................................................................................................................. 1

2 Normative references ...................................................................................................................................................................................... 1

3 Terms and definitions ..................................................................................................................................................................................... 1

4 Symbols and abbreviated terms ........................................................................................................................................................... 2

5 Purpose and structure of this document ..................................................................................................................................... 2

6 Requirement definition ................................................................................................................................................................................. 3

6.1 General ........................................................................................................................................................................................................... 3

6.2 Security functional requirements (SFRs) ......................................................................................................................... 4

6.2.1 General...................................................................................................................................................................................... 4

6.2.2 Example of security functional requirements ........................................................................................ 4

6.2.3 The selection, assignment, refinement and iteration operations .......................................... 5

6.2.4 Dependencies between components .............................................................................................................. 6

6.2.5 Structure of security functional components ......................................................................................... 6

6.2.6 List of classes ...................................................................................................................................................................... 6

6.3 Procedure to specify security functional requirements ...................................................................................... 7

6.4 Procedure to develop functional components ............................................................................................................. 8

6.4.1 Procedure ............................................................................................................................................................................... 8

6.4.2 Existing components for privacy requirements in ISO/IEC 15408-2 ................................ 8

6.4.3 Extended components for privacy requirements in published PP/STs and

research papers ................................................................................................................................................................ 9

7 Privacy principles ................................................................................................................................................................................................ 9

7.1 General ........................................................................................................................................................................................................... 9

7.2 Input for extended components ............................................................................................................................................... 9

7.3 Procedure to develop privacy requirements from privacy principles .................................................10

7.4 Extended components for privacy ......................................................................................................................................10

7.4.1 “Consent and choice” principle ........................................................................................................................10

7.4.2 "Purpose legitimacy and specification" principle ............................................................................13

7.4.3 "Collection limitation" principle: Collecting PII .................................................................................13

7.4.4 "Data minimization" and "Use, retention and disclosure limitation" principles ...13

7.4.5 "Openness, transparency and notice" principle .................................................................................17

7.4.6 "Individual participation and access" principle .................................................................................18

7.4.7 "Accuracy and quality" principle .....................................................................................................................18

7.4.8 "Accountability" and "Privacy compliance" principles .................................................................19

7.4.9 "Information Security" principle ....................................................................................................................19

8 Summary of extended components and related privacy principles ............................................................20

8.1 General ........................................................................................................................................................................................................20

8.2 Extended components - general definition .................................................................................................................20

8.2.1 General...................................................................................................................................................................................20

8.2.2 "Consent and choice" principle ........................................................................................................................20

8.2.3 "Data minimization" and "Use, retention and disclosure limitation" principles ...21

8.2.4 "Openness, transparency and notice" principle .................................................................................22

8.2.5 "Individual participation and access" principle: Challenging the accuracy

and completeness of PII ..........................................................................................................................................23

8.2.6 "Accuracy and quality" principle: Updating PII periodically ...................................................23

Annex A (informative) Existing components used for privacy requirements ........................................................25

Annex B (informative) Extended components for privacy in existing Protection Profiles .......................32

Annex C (normative) Example of extended components for privacy ..............................................................................36

© ISO/IEC 2018 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TS 19608:2018(E)

Bibliography .............................................................................................................................................................................................................................48

iv © ISO/IEC 2018 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TS 19608:2018(E)
Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical

Commission) form the specialized system for worldwide standardization. National bodies that are

members of ISO or IEC participate in the development of International Standards through technical

committees established by the respective organization to deal with particular fields of technical

activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international

organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the

work. In the field of information technology, ISO and IEC have established a joint technical committee,

ISO/IEC JTC 1.

The procedures used to develop this document and those intended for its further maintenance are

described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for

the different types of document should be noted. This document was drafted in accordance with the

editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).

Attention is drawn to the possibility that some of the elements of this document may be the subject

of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent

rights. Details of any patent rights identified during the development of the document will be in the

Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents).

Any trade name used in this document is information given for the convenience of users and does not

constitute an endorsement.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and

expressions related to conformity assessment, as well as information about ISO's adherence to the

World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso

.org/iso/foreword .html.

This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology,

Subcommittee SC 27, IT Security techniques.

Any feedback or questions on this document should be directed to the user’s national standards body. A

complete listing of these bodies can be found at www .iso .org/members .html.
© ISO/IEC 2018 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/IEC TS 19608:2018(E)
Introduction

ISO/IEC 29100 defines a framework of privacy principles that should be considered when developing

systems or applications that deal with personally identifiable information (PII). This document analyses

those principles and maps them, where possible, to the security functional requirements defined in

ISO/IEC 15408-2. Where such a mapping is not possible, this document derives new security functional

requirements collected in one new class that contains several families of privacy related security

functional components following the guidance for developing new classes, families and components

provided in ISO/IEC 15408-1 and ISO/IEC 15408-2.

This document can also be used as guidance for developing further privacy functional requirements

using the framework of ISO/IEC 15408. The class, families, and components defined in this document

can be extended for cases where the components defined here are not sufficient to express specific

privacy functional requirements.
vi © ISO/IEC 2018 – All rights reserved
---------------------- Page: 6 ----------------------
TECHNICAL SPECIFICATION ISO/IEC TS 19608:2018(E)
Guidance for developing security and privacy functional
requirements based on ISO/IEC 15408
1 Scope
This document provides guidance for:

— selecting and specifying security functional requirements (SFRs) from ISO/IEC 15408-2 to protect

Personally Identifiable Information (PII);

— the procedure to define both privacy and security functional requirements in a coordinated

manner; and

— developing privacy functional requirements as extended components based on the privacy principles

defined in ISO/IEC 29100 through the paradigm described in ISO/IEC 15408-2.
The intended audience for this document are:

— developers who implement products or systems that deal with PII and want to undergo a security

evaluation of those products using ISO/IEC 15408. They will get guidance how to select security

functional requirements for the Security Target of their product or system that map to the privacy

principles defined in ISO/IEC 29100;
— authors of Protection Profiles that address the protection of PII; and
— evaluators that use ISO/IEC 15408 and ISO/IEC 18045 for a security evaluation.

This document is intended to be fully consistent with ISO/IEC 15408; however, in the event of any

inconsistency between this document and ISO/IEC 15408, the latter, as a normative standard, takes

precedence.
2 Normative references

The following documents are referred to in the text in such a way that some or all of their content

constitutes requirements of this document. For dated references, only the edition cited applies. For

undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 15408-1, Information technology — Security techniques — Evaluation criteria for IT security —

Part 1: Introduction and general model

ISO/IEC 15408-2, Information technology — Security techniques — Evaluation criteria for IT security —

Part 2: Security functional components

ISO/IEC 18045, Information technology — Security techniques — Methodology for IT security evaluation

ISO/IEC 29100, Information technology — Security techniques — Privacy framework
3 Terms and definitions

For the purposes of this document, the terms and definitions given in ISO/IEC 15408 -1, ISO/IEC 18045,

ISO/IEC 29100 and the following apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

— ISO Online browsing platform: available at https: //www .iso .org/obp
© ISO/IEC 2018 – All rights reserved 1
---------------------- Page: 7 ----------------------
ISO/IEC TS 19608:2018(E)
— IEC Electropedia: available at https: //www .electropedia .org/
3.1
privacy functional component

extended component that serves as a standard template on which to base privacy functional requirements

(3.3) for TOEs
3.2
privacy requirement

requirement, stated in a standardized language, which is meant to contribute to achieving the technical

privacy controls for a TOE based on privacy functional requirements (3.3)
3.3
privacy functional requirement
PFR

translation of the technical privacy controls for the TOE into a standardised language based on privacy

functional components (3.1)
4 Symbols and abbreviated terms
The following abbreviated terms are used in this document.
MRTD Machine Readable Travel Document
OSP Organizational Security Policy
PIA Privacy Impact Assessment
PII Personally Identifiable Information
PP Protection Profile
SPD Security problem definition
SFR Security Functional Requirement
ST Security Target
TOE Target Of Evaluation
TRA Threat Risk Assessment
TSF TOE Security Functionality
5 Purpose and structure of this document

Research shows that security and privacy should be considered from the beginning of the development

life cycle for IT products, systems and applications in order to avoid expensive rework and reduce

potential problems.

Security and privacy should also complement and mutually reinforce each other. The degree of

protection should depend on the sensitivity of data and the linkability of data to personal identifiers.

Therefore, successful implementation of security and privacy depends on defining accurate and

complete requirements for both in a coordinated manner from the start of the development.

ISO/IEC 15408-2 defines a catalogue of security functional requirements (SFRs). ISO/IEC TR 15446

also provides detailed guidance on how to specify SFRs for a Target Of Evaluation (TOE). Developers

can refer to these documents to specify SFRs to protect PII and other assets.
2 © ISO/IEC 2018 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TS 19608:2018(E)

There are currently no ISO/IEC documents that specifically support privacy friendly design of IT

products, systems and applications. Guidance on deriving privacy functional requirements from the

privacy principles described in ISO/IEC 29100, as well as a procedure for defining both SFRs and

privacy functional requirements in a collaborative manner is, therefore, missing.

This document aims to fill this gap and provide guidance for developers on how to:

a) select and specify SFRs from ISO/IEC 15408-2 to protect personally identifiable information (PII)

(this guidance refers to ISO/IEC 15408 and ISO/IEC TR 15446);

b) develop new privacy functional requirements, as extended components, based on the privacy

principles defined in ISO/IEC 29100 using the paradigm described in ISO/IEC 15408-2. (This

guidance is the main focus of this document); and
c) conduct both of the above steps in a coordinated manner.

Clause 6 provides an introduction to SFRs — what they are, when and how they can be used to specify

accurate and complete security requirements.

Clause 7 explains the privacy principles defined in ISO/IEC 29100 and what privacy requirements can

be derived from these principles. These privacy requirements are formulated as privacy functional

components in Clause 8.
Clause 8 lists the privacy functional components developed in this document.

Annex A lists the security functional components in ISO/IEC 15408-2 that address privacy threats.

Annex B provides examples of PPs that define extended components to specify privacy requirements.

Annex C defines the extended privacy functional components in the format required by ISO/IEC 15408-1.

6 Requirement definition
6.1 General

Requirement definition is the first step in developing IT products, applications and systems. Security

requirements are derived to address security threats that shall be countered or to address specific

regulations or policies for the protection of PII. How far those regulations and policies are addressed

by the target of evaluation (TOE) and which requirements are assumed to be addressed by the

environment in which the TOE operates, are expressed by specifying security objectives for the TOE

and assumptions for the TOE environment. The security objectives, which are often very general, are

addressed by security requirements, which can be implemented and tested.

In ISO/IEC 15408, security requirements are expressed in the form of SFRs in the protection profile

(PP) or security target (ST). The author of a ST or PP explains how the SFRs address the security

objectives defined for the TOE. These SFRs are the core of TOE evaluations because evaluators examine

these specifications and the TOE design documents in order to determine that they are a complete and

accurate instantiation of SFRs of the TOE. Evaluators also test whether the TOE operates according to

these specifications and the design or not. TOE evaluations also include a vulnerability analysis, based

on the SFRs, in order to help the identification of vulnerabilities in the TOE. Therefore, SFRs shall be

accurate, testable and traceable so that the TOE evaluations can be conducted objectively.

While there can be occasions where privacy and security objectives are the same, they are not always

aligned. As explained in ISO/IEC 15408-1, security objectives can be derived from a threat analysis

or from organizational security policies. Whereas these policies can also define privacy requirements

which are typically derived from an analysis of relevant legislation, regulation and any organizational

privacy policies that can be in place.

ISO/IEC 15408 defines a vulnerability as a weakness in the TOE that can be used to violate the security

objectives or SFRs in some environment that satisfies the assumptions defined for the TOE environment.

© ISO/IEC 2018 – All rights reserved 3
---------------------- Page: 9 ----------------------
ISO/IEC TS 19608:2018(E)

A vulnerability analysis therefore focuses on the detection of scenarios where the security objectives

are not met although all SFRs are correctly implemented and all assumptions made for the TOE

environment are satisfied.

EXAMPLE Examples of such vulnerabilities are implementation side effects like incomplete parameter

validation or design side effects like covert communication channels that can be used to obtain information in

violation of a defined information flow policy.

The following subclauses provide readers with minimum knowledge of the concept of SFRs so that

readers can understand the content of this document, minimizing the need to refer to other documents.

Most of descriptions in the following subclauses are extracted as a summary from ISO/IEC 15408 and

ISO/IEC TR 15446.
6.2 Security functional requirements (SFRs)
6.2.1 General

The TOE implements security functions to protect its assets from unauthorized disclosure, modification,

or loss of use. SFRs are the requirements for those security functions that the TOE security functionality

(TSF) shall provide.
NOTE The TSF is the part of the TOE that implements the SFRs.

ISO/IEC 15408-1 provides a framework to define SFRs, in a standardized language in order to ensure

exactness and facilitate the comparability of security requirements. ISO/IEC 15408-2 then provides a

catalogue of security functional components which are the basis for the SFRs. PP/ST authors select an

appropriate set of security functional components from this catalogue for their TOE and tailor these

security functional components through operations (see 6.2.3) in order to meet their needs and to

ensure that the specification of security requirements in the form of SFRs is complete.

TOE evaluations determine if the TOE actually meets the all of these SFRs through the evaluation

activities defined in ISO/IEC 18045.

NOTE Evaluation activities include the review of the PP/ST, specification, functional testing and vulnerability

analysis.

The catalogue of SFRs defined in ISO/IEC 15408-2 covers many aspects of security functionality but also

allows for the specification of additional SFRs that are not in this catalogue. The framework provided in

ISO/IEC 15408-1 shall be used to define additional SFRs for a security functionality that is not covered

by the SFRs defined in ISO/IEC 15408-2.
6.2.2 Example of security functional requirements

Figure 1 gives an example of a security functional component provided in ISO/IEC 15408-2.

EXAMPLE 1
FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication

FIA_AFL.1.1 The TSF shall detect when [selection: [assignment: positive integer number]], an administrator

configurable positive integer within [assignment: range of acceptable values] unsuccessful authentication

attempts occur related to [assignment: list of authentication events].

FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been [selection: met,

surpassed], the TSF shall [assignment: list of actions].
Figure 1 — Security functional component for authentication failure handling
4 © ISO/IEC 2018 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC TS 19608:2018(E)

FIA_AFL.1 is a component for authentication failure handling. This component requires that the TSF

be able to terminate the session establishment process after a specified number of unsuccessful user

authentication attempts. It also requires that, after termination of the session establishment process,

the TSF be able to disable the user account or the point of entry from which the attempts were made

until an administrator-defined condition occurs.
EXAMPLE 2 An example of a point of entry is a work station.
6.2.3 The selection, assignment, refinement and iteration operations

ISO/IEC 15408 permits a degree of flexibility in the way the SFRs are specified by allowing PP/ST

authors to tailor the security requirement appropriately. In FIA_AFL.1, PP/ST authors can specify

appropriate variables and actions after the word "assignment:" and select appropriate elements from

several items specified after the word "selection:" to complete the security requirement.

EXAMPLE 1 If the TOE needs to lockout telnet administrator's login after 3 unsuccessful login attempts, PP/ST

authors assign and select appropriate values or items as follows:

FIA_AFL.1.1 The TSF shall detect when [3] unsuccessful authentication attempts occur related to [authentication

of the telnet administrator].

FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been [met], the TSF shall

[lockout the telnet administrator’s login].
Figure 2 — A completed SFR for authentication failure handling

PP/ST authors can also tailor the requirement using the refinement operation under the following

restrictions:

a) a TOE meeting the refined requirement also meets the unrefined requirement in the context of the

PP/ST (i.e. a refined requirement must be “stricter” than the original requirement); and

b) refinement shall be related to the original component.
EXAMPLE 2 An example of a valid refinement is shown in Figure 3.
In ISO/IEC 15408-2;

FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-

mediated actions on behalf of that user.”
being refined to:

FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated by username/password before

allowing any other TSF-mediated actions on behalf of that user.
Figure 3 — Example of the refined SFR for timing of authentication

The PP/ST authors can use the same functional component to express two or more distinct

requirements for the TOE. Each iteration of a component shall be different from all other iterations of

that component, which is realized by completing assignments and selections in a different way, or by

applying refinements to it in a different way.

ISO/IEC 15408 does not provide any other methods to tailor the SFRs other than selection, assignment,

and refinement operations. However, there can be security requirements for the TOE that existing

components in ISO/IEC 15408-2 cannot cover. In this case, new components (extended components)

shall be defined in the PP/ST.
© ISO/IEC 2018 – All rights reserved 5
---------------------- Page: 11 ----------------------
ISO/IEC TS 19608:2018(E)
6.2.4 Dependencies between components

Dependencies can exist between security functional components. Dependencies arise when a

component is not self-sufficient and relies on the presence of another component to provide security

functionality.

EXAMPLE 1 As shown in Figure 1, FIA_AFL.1 has a dependency to "FIA_UAU.1 Timing of authentication" that

is a component for user authentication because the TOE must authenticate users before detecting unsuccessful

authentication attempts.

EXAMPLE 2 In FAU_GEN.1 (Audit data generation) and FPT_STM.1 (Reliable time stamps). FAU_GEN.1 requires

that for audit record generation and has a dependency to FPT_STM.1 because FAU_GEN.1 requires the inclusion

of the date and time of the event in each audit record. Such time stamps must be reliable in order to provide the

correct date and time of the event.

If FIA_AFL.1 is selected in the PP/ST, then the PP/ST authors shall either include FIA_UAU.1 in the PP/

ST or provide a justification as to why the PP/ST does not contain FIA_UAU.1. The same is true for FAU_

GEN.1 and FPT_STM.1.
6.2.5 Structure of security functional components

In ISO/IEC 15408-2 the security functional components are organized into hierarchical structures:

— classes; consisting of
— families; consisting of
— components; consisting of
— elements.

ISO/IEC 15408-2 contains classes of families and components, which are rough groupings on the basis

of related function or purpose.
EXAMPLE

Two elements, FIA_AFL.1.1 and FIA_AFL.1.2, belong to the security functional component FIA_AFL.1. FIA_AFL.1

belongs to the FIA_AFL family that contains requirements for defining values for some number of unsuccessful

authentication attempts and TSF actions in cases of authentication attempt failures. T

...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.