System Protection Profile - Industrial Control Systems

**Version 0.91**

**February 4, 2004**

**Prepared for:**

![](media/image1.png){width="3.3430555555555554in"
height="1.3916666666666666in"}

**by**

![](media/image2.jpeg){width="2.25in" height="1.1305555555555555in"}

# Document Control {#document-control .Invisible-1}

# Preparation {#preparation .Invisible-2}

+---------------------+----------------------------+-------------------+
| ## Action {#ac      | ##                         | ## Date {#da      |
| tion .Text-Heading} | Name {#name .Text-Heading} | te .Text-Heading} |
+---------------------+----------------------------+-------------------+
| Prepared by:        | Ron Melton, Terry          | 4 Feb 2004        |
|                     | Fletcher, Matt Earley      |                   |
+---------------------+----------------------------+-------------------+
| Reviewed by:        | Lynne Ambuel, Murray       | 4 Feb 2004        |
|                     | Donaldson                  |                   |
+---------------------+----------------------------+-------------------+

# Release {#release .Invisible-2}

+-------+------------+------------+------------+---------------------+
| ## Ve | ## Date    | ## Chan    | ## Pages   | ## Remarks {#rem    |
| rsion |  Released  | ge Notice  | Affected { | arks .Text-Heading} |
|  {#ve | {#date-rel | {#change-n | #pages-aff |                     |
| rsion | eased .Tex | otice .Tex | ected .Tex |                     |
|  .Tex | t-Heading} | t-Heading} | t-Heading} |                     |
| t-Hea |            |            |            |                     |
| ding} |            |            |            |                     |
+-------+------------+------------+------------+---------------------+
| 0.91  | 4 Feb 2004 | N/A        | All        | SPP populated into  |
|       |            |            |            | new structure. Core |
|       |            |            |            | information         |
|       |            |            |            | chapters (1 to 6)   |
|       |            |            |            | nearing completion. |
|       |            |            |            | Chapters 7 and 8    |
|       |            |            |            | (Application Notes  |
|       |            |            |            | & Rationale) under  |
|       |            |            |            | development.        |
+-------+------------+------------+------------+---------------------+

# Distribution List {#distribution-list .Invisible-2}

+---------------+-------------------+---------------------------------+
| ## Na         | ## Organisa       | ## Title {#title .Text-Heading} |
| me {#name-1 . | tion {#organisati |                                 |
| Text-Heading} | on .Text-Heading} |                                 |
+---------------+-------------------+---------------------------------+
| Keith         | NIST              | PCSRF Program Manager           |
| Stouffer      |                   |                                 |
+---------------+-------------------+---------------------------------+
| PCSRF Members | Various           | Various                         |
+---------------+-------------------+---------------------------------+

TABLE OF CONTENTS

[Document Control 2](#document-control)

[Preparation 2](#preparation)

[Release 2](#release)

[Distribution List 2](#distribution-list)

[1 Introduction 9](#introduction)

[1.1 SPP Identification 9](#spp-identification)

[1.2 SPP Overview 9](#spp-overview)

[2 STOE Description 13](#stoe-description)

[2.1 Overview of the System Target of Evaluation (STOE)
13](#overview-of-the-system-target-of-evaluation-stoe)

[2.2 Scope of the STOE 13](#scope-of-the-stoe)

[2.3 Security Features 15](#security-features)

[2.4 Features Outside of Scope 16](#features-outside-of-scope)

[3 STOE Security Environment 17](#stoe-security-environment)

[3.1 Secure Usage Assumptions 17](#secure-usage-assumptions)

[3.2 Threats to Security 17](#threats-to-security)

[3.2.1 Threats Addressed by the STOE 18](#threats-addressed-by-the-stoe)

[3.2.2 Threats Addressed by the Operating Environment
26](#threats-addressed-by-the-operating-environment)

[3.3 Overarching Organizational Security Policies
26](#overarching-organizational-security-policies)

[4 Risks 28](#risks)

[4.1 Risk Categories applicable to the STOE
28](#risk-categories-applicable-to-the-stoe)

[4.2 Risks to the External Operating Environment
33](#risks-to-the-external-operating-environment)

[5 Security Objectives 34](#security-objectives)

[5.1 Security Objectives for the STOE
34](#security-objectives-for-the-stoe)

[5.2 Security Objectives for the External Operating Environment
37](#security-objectives-for-the-external-operating-environment)

[6 IT Security Requirements 38](#it-security-requirements)

[6.1 STOE Security Functional Requirements
38](#stoe-security-functional-requirements)

[6.1.1 Logon Controls: 41](#logon-controls)

[6.1.2 Password Selection 42](#password-selection)

[6.1.3 Authentication Data Protection
43](#authentication-data-protection)

[6.1.4 Replay / Reuse 44](#replay-reuse)

[6.1.5 Session Suspension 44](#session-suspension)

[6.1.6 User Accounts and Profiles 45](#user-accounts-and-profiles)

[6.1.7 Role based access control 45](#role-based-access-control)

[6.1.8 Controls on RBAC Attributes 47](#controls-on-rbac-attributes)

[6.1.9 Firewall access control 47](#firewall-access-control)

[6.1.10 Audit events 48](#audit-events)

[6.1.11 Intrusion detection and response
49](#intrusion-detection-and-response)

[6.1.12 Audit trail protection 50](#audit-trail-protection)

[6.1.13 Audit trail analysis / review 51](#audit-trail-analysis-review)

[6.1.14 TOE Integrity 52](#toe-integrity)

[6.1.15 Data Authentication 53](#data-authentication)

[6.1.16 Data exchange integrity 53](#data-exchange-integrity)

[6.1.17 Functions required to support dependencies
53](#functions-required-to-support-dependencies)

[6.1.18 Secure Communications Channels
54](#secure-communications-channels)

[6.1.19 Management Functions 56](#management-functions)

[6.1.20 Physical Security Requirements
57](#physical-security-requirements)

[6.1.21 Security Event Monitoring 57](#security-event-monitoring)

[6.1.22 Requirements for interfaces between system components
59](#requirements-for-interfaces-between-system-components)

[6.1.23 Requirements for composability and interoperability between
system components
59](#requirements-for-composability-and-interoperability-between-system-components)

[6.1.24 Configuration requirements 59](#configuration-requirements)

[6.2 STOE Security Assurance Requirements
59](#stoe-security-assurance-requirements)

[6.2.1 Configuration Management (ACM) 61](#configuration-management-acm)

[6.2.2 Delivery and Operation (ADO) 63](#delivery-and-operation-ado)

[6.2.3 Guidance Documents (AGD) 64](#guidance-documents-agd)

[6.2.4 Life Cycle Support (ALC) 67](#life-cycle-support-alc)

[6.2.5 Security Awareness (ASA) 69](#security-awareness-asa)

[6.2.6 System O&M Security Controls (ASC)
70](#system-om-security-controls-asc)

[6.2.7 System Architecture (Class ASD)
72](#system-architecture-class-asd)

[6.2.8 Tests (ATE) 76](#tests-ate)

[6.2.9 Vulnerability Assessment (AVA) 77](#vulnerability-assessment-ava)

[6.2.10 Assurance Maintenance (AMA) 77](#assurance-maintenance-ama)

[6.3 Security Requirements for the IT Environment
79](#security-requirements-for-the-it-environment)

[6.4 Security Requirements for the Non-IT Environment
79](#security-requirements-for-the-non-it-environment)

[7 SPP Application Notes 80](#spp-application-notes)

[7.1 SPP Overview 80](#spp-overview-1)

[7.1.1 SPP Purpose 80](#spp-purpose)

[7.1.2 SPP Structure 81](#spp-structure)

[7.1.3 SPP Application 81](#spp-application)

[7.2 SPP Application: System Requirements Specification
81](#spp-application-system-requirements-specification)

[7.2.1 Traditional CC Paradigm 81](#traditional-cc-paradigm)

[7.2.2 Systems Context 81](#systems-context)

[7.3 SPP Application: Risk Management
81](#spp-application-risk-management)

[7.4 SPP Application: SPP 81](#spp-application-spp)

[7.4.1 Refinement of the Security Environment
81](#refinement-of-the-security-environment)

[7.4.2 Risks 82](#risks-1)

[7.4.3 Refinement of the Security Objectives
82](#refinement-of-the-security-objectives)

[7.4.4 Refinement of the IT Security Requirements
82](#refinement-of-the-it-security-requirements)

[7.4.5 Supporting Rationale 82](#supporting-rationale)

[7.5 SPP Application: SST 83](#spp-application-sst)

[7.5.1 STOE Summary Specification 83](#stoe-summary-specification)

[7.5.2 SPP Claims 83](#spp-claims)

[7.5.3 Supporting Rationale 83](#supporting-rationale-1)

[8 Rationale 84](#rationale)

[8.1 Security Risks Rationale 84](#security-risks-rationale-1)

[8.1.1 All Assets, Threats and Vulnerabilities Addressed
84](#all-assets-threats-and-vulnerabilities-addressed)

[8.1.2 Security Risks are Sufficient 85](#security-risks-are-sufficient)

[8.2 Security Objectives Rationale 85](#security-objectives-rationale-1)

[8.2.1 All Assumptions, Threats and Policies Addressed
85](#all-assumptions-threats-and-policies-addressed)

[8.2.2 Security Objectives are Sufficient
86](#security-objectives-are-sufficient)

[8.2.3 Suitability of the Security Objectives to counter identified
Risks
87](#suitability-of-the-security-objectives-to-counter-identified-risks)

[8.2.4 Sufficiency of the Security Objectives to counter identified
Risks
87](#sufficiency-of-the-security-objectives-to-counter-identified-risks)

[8.3 Security Requirements Rationale
88](#security-requirements-rationale)

[8.3.1 Suitability of the Security Requirements
88](#suitability-of-the-security-requirements)

[8.3.2 Sufficiency of the Security Requirements
88](#sufficiency-of-the-security-requirements)

[8.3.3 Satisfaction of Dependencies 89](#satisfaction-of-dependencies)

[8.4 Rationale for Extensions 90](#rationale-for-extensions)

[Appendix A -- Acronyms 91](#appendix-a-acronyms)

**LIST OF TABLES**

[Table 1 --Scope of the STOE 14](#__RefHeading___Toc63689408)

[Table 2 -- Summary of STOE Security Features
15](#__RefHeading___Toc63689409)

[Table 3 -- Secure Usage Assumptions 17](#__RefHeading___Toc63689410)

[Table 4 -- Threat Agents for the STOE 18](#__RefHeading___Toc63689411)

[Table 5 - Vulnerabilities of the STOE 19](#__RefHeading___Toc63689412)

[Table 6 -- Attack Methods against the STOE
20](#__RefHeading___Toc63689413)

[Table 7 -- Assets protected by the STOE
22](#__RefHeading___Toc63689414)

[Table 8 -- Threats countered by the STOE
24](#__RefHeading___Toc63689415)

[Table 9 -- Organizational Security Policies
26](#__RefHeading___Toc63689416)

[Table 10 -- Identified Risk Categories for the STOE
28](#__RefHeading___Toc63689417)

[Table 11 -- Security Objectives for the STOE
34](#__RefHeading___Toc63689418)

[Table 12 -- STOE Security Functional Requirements
38](#__RefHeading___Toc63689419)

[Table 13 -- STOE Security Assurance Requirements
60](#__RefHeading___Toc63689420)

[Table 14 - Mapping of Assets, Threats and Vulnerabilities to Security
Risks 84](#__RefHeading___Toc63689421)

[Table 15 - Mapping of Security Risks to Assets, Threats and
Vulnerabilities 85](#__RefHeading___Toc63689422)

[Table 16 - Sufficiency of Security Risks
85](#__RefHeading___Toc63689423)

[Table 17 - Mapping of Assumptions, Threats, and OSPs to Security
Objectives 85](#__RefHeading___Toc63689424)

[Table 18 - Mapping of Security Objectives to Threats, Policies and
Assumptions 86](#__RefHeading___Toc63689425)

[Table 19 - Sufficiency of Security Objectives
86](#__RefHeading___Toc63689426)

[Table 20 - Mapping of Security Risks to Security Objectives
87](#__RefHeading___Toc63689427)

[Table 21 - Mapping of Security Objectives to Security Risks
87](#__RefHeading___Toc63689428)

[Table 22 - Sufficiency of Security Objectives countering identified
Risks 87](#__RefHeading___Toc63689429)

[Table 23 - Mapping of Security Objectives to Security Requirements
88](#__RefHeading___Toc63689430)

[Table 24 - Mapping of Security Requirements to Security Objectives
88](#__RefHeading___Toc63689431)

[Table 25 - Sufficiency of Security Requirements
89](#__RefHeading___Toc63689432)

[Table 26 - Dependency Analysis 89](#__RefHeading___Toc63689433)

> **Conventions and Terminology**
>
> **Conventions**

The notation, formatting, and conventions used in this System Protection
Profile are consistent with those used in Version 2.1 of the Common
Criteria \[CC\]. Selected presentation choices are discussed here to aid
the System Protection Profile reader. The CC allows several operations
to be performed on functional requirements: The allowable operations
defined in paragraph 2.1.4 of Part 2 of the CC \[CC2\] are *refinement,
selection, assignment* and *iteration.*

-   The assignment operation is used to assign a specific value to an
    unspecified parameter, such as the length of a password. An
    assignment operation is indicated by showing the value in square
    brackets, i.e. \[assignment_value(s)\].

-   The refinement operation is used to add detail to a requirement, and
    thus further restricts a requirement. Refinement of security
    requirements is denoted by **bold text.**

-   The selection operation is picking one or more items from a list in
    order to narrow the scope of a component element. Selections are
    denoted by *[underlined italicized]{.underline}* text.

-   Iterated functional and assurance requirements are given unique
    identifiers by appending to the base requirement identifier from the
    CC an iteration number inside parenthesis, for example,
    FMT_MTD.1.1 (1) and FMT_MTD.1.1 (2) refer to separate instances of
    the FMT_MTD.1 security functional requirement component.

All operations described above are used in this System Protection
Profile. *Italicized text* is used for both official document titles and
text meant to be emphasized more than plain text.

> **Terminology**

The terminology used in the System Protection Profile is that defined in
the Common Criteria \[CC1, CC2\]. A glossary has also been provided in
Appendix A -- Acronyms.

**References**

  ------------------- ---------------------------------------------------
  \[CC\]              Common Criteria for Information Technology Security
                      Evaluation, Version 2.1, August 1999.

  \[CC1\]             Common Criteria Part 1: Introduction and General
                      Model, Version 2.1, CCIB-99-031, August 1999.

  \[CC2\]             Common Criteria Part 2: Security Functional
                      Requirements, Version 2.1, CCIB-99­032, August 1999.

  \[CC3\]             Common Criteria Part 3: Security Assurance
                      Requirements, Version 2.1, CCIB-99­033, August 1999.

  \[CEM\]             Common Evaluation Methodology Part 2: Evaluation
                      Methodology, Version 1.0, CEM­99/045, August 1999.
  ------------------- ---------------------------------------------------

**Document Organization**

**Section 1** provides the introductory material for the System
Protection Profile.

**Section 2** provides general purpose and STOE description.

**Section 3** provides a discussion of the expected environment for the
STOE. This section also defines the set of threats that are to be
addressed by either the technical, operational or management controls
implemented by the STOE or through the environmental controls.

**Section 4** identifies the risks to the STOE that have been derived
from the statement of the security environment defined in section 3.

**Section 5** defines the security objectives for both the STOE and the
STOE environment.

**Section 6** contains the functional and assurance requirements derived
from the Common Criteria, Part 2 and 3 \[CC2, CC3\], respectively that
must be satisfied by the STOE.

**Section 7** contains guidance information for SST authors who would
like to claim conformance to the SPP.

**Section 8** provides a rationale to explicitly demonstrate that the
identified risks to the STOE have been derived from the aspects
identified in the security environment. It also demonstrates how the
security objectives have been derived from each of the identified risks.
The section then explains how the set of requirements are complete
relative to the objectives, and that each security objective is
addressed by one or more component requirements. Arguments are provided
for the coverage of each objective. Section 8 also provides a set of
arguments that address dependency analysis, strength of function issues,
and the internal consistency and mutual supportiveness of the System
Protection Profile requirements.

**Appendix A** documents an acronym list to define frequently used
acronyms applicable to the STOE.

#  {#section .unnumbered}

# Introduction

This introductory section presents *System Protection Profile (SPP)*
identification information and an overview of the SPP.

## SPP Identification

This section provides information needed to identify and control this
SPP. This SPP targets an **extended Evaluation Assurance Level (EAL) 3**
level of assurance for the STOE.

  -------------------- --------------------------------------------------
  **SPP Title:**       System Protection Profile - Industrial Control
                       Systems

  **SPP Version:**     0.91

  **CC Version:**      Common Criteria for Information Technology
                       Security Evaluation, Version 2.1 Final

  **SPP Evaluation:**  National Information Assurance Partnership

  **Author(s):**       National Institute of Standards & Technology

  **Keywords:**        Industrial Control Systems
  -------------------- --------------------------------------------------

## SPP Overview

**SPP Background**

This SPP has been developed as part of the Process Control Security
Requirements Forum (PCSRF) sponsored by the National Institute of
Standards and Technology (NIST). This SPP is intended to provide an ISO
15408 based starting point in formally stating security requirements
associated with industrial control systems (ICS). This SPP includes
security functional requirements (SFRs) and security assurance
requirements (SARs) that extend ISO 15408 to cover issues associated
with systems. These extensions are based on current ISO subcommittee
work to extend ISO 15408 to cover the accreditation of systems and the
evaluation of system protection profiles and system security targets.
These extensions broaden consideration of security controls to include
non-technical controls based on procedural and management functions.

**ICS Background**

Industrial control systems are computer-based systems used to control
industrial processes and physical functions. This SPP covers the
security requirements for a generic ICS. The SPP has been written in
such a way that it may be used as the basis for preparing a System
Security Target for a specific ICS or as the basis for a more detailed
SPP for a sub-class of ICS such as a Supervisory Control and Data
Acquisition System (SCADA). For more discussion of the role of this SPP
refer to section 7.1 of the application notes.

Modern industry and the associated infrastructure is based on our
ability to control electrical, chemical and mechanical transformations
of materials to produce desired results. Industrial control systems are
used to automate these control functions allowing the creation of
industrial processes that are faster, larger and more complex than could
be achieved by non-automated means. In many cases the ICS is also an
integral element of the safe and environmentally acceptable operation of
the industrial process.

There are several varieties of ICS, but all consist of the same basic
elements. As shown in Figure 1 those components are: the controller,
sensors, actuators (or final control elements), and in some cases a
human machine interface (HMI) and a remote diagnostics and maintenance
capability. These components may be in close physical proximity or they
may be distributed with great distances (many miles) between some of the
elements) depending on the specific application. In addition to these
technical elements ICS include a human element including operators,
maintainers and engineers. They also have operating procedures and other
non-technical elements.

A simplified view of the operation of an ICS and the function of the
elements is as follows. The controller implement control algorithms
based on a mathematical model of the process to be controlled and the
control objectives. The sensors sense the state of the process through
measurement of process parameters such as temperature, pressure,
voltage, pH, position, size, etc. The state of the process may change
due to external \"disturbances\", changes in the process inputs such as
feed material, or in response to action initiated by the controller. The
controller processes the sensor information and, based on the control
algorithm and desired state of the process, sends commands to the final
control elements which in turn interact with the controlled process to
affect changes in its state. The final control elements take many
different forms including valves, switches, relays, motors, and so forth
depending on the nature of the process under control. The HMI provides a
means for human operators to monitor the state of the process and the
ICS, to interact with the controller to change the control objective and
may also include manual control options. Similarly there may be a remote
diagnostics and maintenance interface to be used in gathering data used
for diagnostics and maintenance or for other similar activities.

**Need for an ICS SPP**

Several factors have raised concern about the security of industrial
control systems. First, there has been a general trend to replace
specialized control devices, particulalry controllers and communications
elements, with general purpose computer equipment and associated data
communications technology. Second, many companies have chosen to
interconnect their process control networks with their corporate
intranet once they have introduced general-purpose equipment into the
process control system. These two factors introduce all of the potential
vulnerabilities found in the network computing in general, particularly
if there is a path through the corporate intranet to the Internet at
large. Third, for ICS that are broadly distributed a variety of
communications media are used including the public switched telephone
system, wireless communications and the Internet. There are potential
security vulnerabilities associated with each of these communications
paths. Finally, ICS are key components of much of our national critical
infrastructure including the electric power, water and water treatment,
oil and gas production and distribution as well as industrial and
military manufacturing.

To address these vulnerabilities organizations are primarily installing
security retrofits or upgrades to existing their existing ICS. This SPP
is intended to provide a basis for these activities as well as the
design of new systems. In either case, the security functionality should
be implemented based on a risk analysis that determines security
requirements based on an assessment of threats, vulnerabilities and
impacts.

**System Protection Profile - Industrial Control Systems**

The System Protection Profile for Industrial Control Systems (SPP-ICS)
specifies the integrated set of security requirements for industrial
control systems. The integrated set of requirements includes
requirements for operating policies and procedures, requirements for
information technology based system components, requirements for
interfaces and interoperability between system components, and
requirements for the physical environment and protection of the system.

Because the SPP-ICS represents an integrated view of the requirements,
special consideration is given to decomposition of security
functionality and assignment of specific security functions to
sub-systems or components of the overall integrated system. Likewise,
the decomposition or composability of the security functionality is also
considered. The goal of this aspect of analysis and design is to define
security requirements for subsystems or system components at the lowest
possible level while at the same time retaining the required level of
assurance and security functionality for the integrated system as a
whole.

![](media/image3.wmf)As shown in Figure 1 an industrial control system
consists of classes of components for the direct control of a process
(the controller(s), actuators and sensors) a human machine interface and
capabilities for remote diagnostics and maintenance. Although not
represented in the diagram, there are also human elements such as
operators and non-technical elements such as operating procedures.

Figure 1: Generic industrial control system

This system protection profile is written for a generic industrial
control system as a high-level statement of requirements. It provides a
starting point for more specific and detailed statements of requirements
for industrial control systems focused on a specific industry, company,
or component.

# STOE Description

This section provides context for the STOE evaluation by identifying the
system and describing the evaluated configuration.

## Overview of the System Target of Evaluation (STOE)

This section describes the security subsystem of the industrial control
system. The security subsystem includes both the information technology
based components and the non-information technology based elements
implemented via policies and operating procedures. Particular attention
is given to the interaction and dependencies between the security
subsystem and the overall industrial control system.

The STOE focuses on protecting data integrity and system availability
without interfering with safety system functions. Data integrity centers
on protecting data flows to and from the controller and the other ICS
components or subsystems. The STOE is also intended to protect system
availability to assure continuity of operations. Confidentiality beyond
that required to protect the security subsystem itself or to protect
against specific attacks on the ICS is not considered to be a large
risk.

## Scope of the STOE

The STOE consists of the security services and procedures, both
automated and manual, which are designed to meet the security objectives
defined to counter threats to the ICS.

The scope of the STOE is depicted graphically in Figure 2. Boxes with
bold red borders depict the primary system security functions. These
functions are: user authentication services (including user access
control), physical access control, boundary protection, and data /
device authentication. User authentication services control access to
process control related computer systems including the human machine
interface (HMI) and remote diagnostics and maintenance. In addition,
user authentication is used by the physical access control system to
authenticate personnel for physical access. Data / device authentication
is shown as a separate function to emphasize the need for data and
command signal authentication. Note that the corporate intranet is in
the external environment of the STOE.

The blue lines from actuator to controlled process and from controlled
process to sensor indicate that these are physical connections
representing the direct interactions that take place. The rest of the
diagram depicts logical connections. Security controls based on
management and operating procedures are not shown in the Figure.

![](media/image4.wmf)

Figure 2 *Graphical depiction of System Target of Evaluation*

The scope of the STOE includes the technical and non-technical elements
identified in Table 1.

[]{#__RefHeading___Toc63689408 .anchor}Table 1 --Scope of the STOE

+----------------------+-----------------------------------------------+
| **STOE Components**  | **Hardware/Software Components**              |
+----------------------+-----------------------------------------------+
| > **Physical         | > Access control                              |
| > Boundary           |                                               |
| > Protection**       |                                               |
+----------------------+-----------------------------------------------+
| > **Logical Boundary | > Firewall                                    |
| > Protection**       |                                               |
+----------------------+-----------------------------------------------+
| > **Data             | > Authentication service, data / device       |
| > authentication**   | > authenticators                              |
+----------------------+-----------------------------------------------+
| > **User             | > Authentication service, integration with    |
| > Authentication**   | > physical access control                     |
+----------------------+-----------------------------------------------+
| > **Continuity of    | > System backup and recovery, Backup power    |
| > Operations**       |                                               |
+----------------------+-----------------------------------------------+
| > **Operating        | > Backup frequency, password requirements,    |
| > procedures**       | > etc.                                        |
+----------------------+-----------------------------------------------+
| > **Training**       | > Security training, etc.                     |
+----------------------+-----------------------------------------------+
| > **Management       | > Staff selection criteria, disciplinary      |
| > procedures**       | > measures, etc.                              |
+----------------------+-----------------------------------------------+

## Security Features

Editor's Note: The table below will be updated following confirmation of
the security objectives by PCSRF members.

The STOE provides the following security features:

[]{#__RefHeading___Toc63689409 .anchor}Table 2 -- Summary of STOE
Security Features

+----------------------+-----------------------------------------------+
| **Feature**          | **Description**                               |
+----------------------+-----------------------------------------------+
| > **Authentication** | > TBD                                         |
+----------------------+-----------------------------------------------+
| > **Integrity**      | > TBD                                         |
+----------------------+-----------------------------------------------+
| > **Boundary         | > TBD                                         |
| > Protection**       |                                               |
+----------------------+-----------------------------------------------+
| > **Access control** | > TBD                                         |
+----------------------+-----------------------------------------------+
| > **Integration of   | > TBD                                         |
| > access control     |                                               |
| > with user          |                                               |
| > authentication**   |                                               |
+----------------------+-----------------------------------------------+
| > **Backup /         | > TBD                                         |
| > Recovery**         |                                               |
+----------------------+-----------------------------------------------+
| > **Non-interference | > TBD                                         |
| > with safety        |                                               |
| > critical           |                                               |
| > functions**        |                                               |
+----------------------+-----------------------------------------------+
| > **Emergency        | > Emergency power sufficient to allow for     |
| > power**            | > graceful shutdown of the ICS and the        |
|                      | > controlled process in the event that        |
|                      | > primary and secondary power fail.           |
+----------------------+-----------------------------------------------+

## Features Outside of Scope 

Features outside the scope of the defined STOE and thus not evaluated
are:

-   General physical protection outside the scope of the STOE

-   Enterprise intranet protection

-   Protection of \"business\" information and systems other than that
    generated by the ICS while it resides within the ICS.

-   Primary and secondary power

-   General corporate security policies, procedures and training (the
    STOE will only address ICS specific policies, procedures and
    training)

-   TBD

#  {#section-1 .unnumbered}

# STOE Security Environment

> In order to clarify the nature of the security problem that the STOE
> is intended to solve, this section describes the following:

-   Any assumptions about the security aspects of the environment and/or
    of the manner in which the STOE is intended to be used.

-   Any known or assumed threats to the assets against which specific
    protection within the STOE or its environment is required.

-   Any organizational security policy statements or rules with which
    the STOE must comply.

## Secure Usage Assumptions

The following assumptions relate to the operation of the TOE:

[]{#__RefHeading___Toc63689410 .anchor}Table 3 -- Secure Usage
Assumptions

+--------------------+-------------------------------------------------+
| **Name**           | **Description**                                 |
+====================+=================================================+
| > **A              | > In accordance with organizational policy      |
| .PHYSICAL_ACCESS** | > physical access controls are applied at       |
|                    | > designated physical access points throughout  |
|                    | > the system whose perimeters are defined by    |
|                    | > the organization, and personnel with          |
|                    | > authorized access is documented and           |
|                    | > maintained. Entry to secure areas is          |
|                    | > controlled and monitored on a periodic basis. |
+--------------------+-------------------------------------------------+
| >                  | > In accordance with organizational policy,     |
| **A.COMMS_ACCESS** | > physical access to communication media, and   |
|                    | > connections to the media, and services        |
|                    | > allowed to go over the communications media   |
|                    | > (e.g., internet access, e-mail) is            |
|                    | > controlled, as is access to devices that      |
|                    | > display or output system control information. |
+--------------------+-------------------------------------------------+
| > **A.EXTERNAL**   | > The ICS network may have connectivity with    |
|                    | > non-ICS system networks through which         |
|                    | > Internet connectivity is possible.            |
+--------------------+-------------------------------------------------+
| > **A.REMOTE**     | > Remote access to ICS components may be        |
|                    | > available to authorized individuals.          |
+--------------------+-------------------------------------------------+

## Threats to Security

Threats may be addressed either by the STOE or by its intended
environment (for example, using personnel, physical, or administrative
safeguards not provided by the STOE). These two classes of threats are
discussed separately.

Threats are characterized in terms of an identified threat agent, the
attack, and the asset that is the subject of the attack. Threats agents
are described as a combination of expertise, available resources, and
motivation. Attacks are described as a combination of attack methods,
any vulnerabilities exploited, and opportunity.

### Threats Addressed by the STOE

The following sections document the threat agents, attacks and assets
relevant to the STOE. The last section combines all three aspects into a
list of threats to be countered by the STOE.

#### Threat Agents

Threats agents are characterized through a combination of expertise,
available resources, and motivation. The threat agents relevant to the
STOE have been captured below in Table 4.

[]{#__RefHeading___Toc63689411 .anchor}Table 4 -- Threat Agents for the
STOE

+--------------------+-----------+-----------+-----------+-------------+
| > **Threat Agent   | > *       |           |           |             |
| > Label**          | *Descript |           |           |             |
|                    | ion**[^1] |           |           |             |
+====================+===========+===========+===========+=============+
|                    | >         | > **Ex    | > **Re    | > **M       |
|                    |  **Threat | pertise** | sources** | otivation** |
|                    | > Agent** |           |           |             |
+--------------------+-----------+-----------+-----------+-------------+
| >                  | > Trusted | >         | > Su      | > No        |
|  **AGENT.INSIDER** | >         |  Low/High | bstantial | n-malicious |
|                    | employee, |           |           |             |
|                    | > co      |           |           |             |
|                    | ntractor, |           |           |             |
|                    | > vendor  |           |           |             |
|                    | > or      |           |           |             |
|                    | >         |           |           |             |
|                    |  customer |           |           |             |
+--------------------+-----------+-----------+-----------+-------------+
| > **AG             | > Trusted | >         | > Su      | > Malicious |
| ENT.EVIL_INSIDER** | >         |  Low/High | bstantial |             |
|                    | employee, |           |           |             |
|                    | > co      |           |           |             |
|                    | ntractor, |           |           |             |
|                    | > vendor  |           |           |             |
|                    | > or      |           |           |             |
|                    | >         |           |           |             |
|                    |  customer |           |           |             |
|                    | > acting  |           |           |             |
|                    | > inappr  |           |           |             |
|                    | opriately |           |           |             |
+--------------------+-----------+-----------+-----------+-------------+
| > **AGE            | > Former  | >         | >         | > Malicious |
| NT.PRIOR_INSIDER** | > trusted |  Low/High |  Moderate |             |
|                    | >         |           |           |             |
|                    | employee, |           |           |             |
|                    | > co      |           |           |             |
|                    | ntractor, |           |           |             |
|                    | > vendor  |           |           |             |
|                    | > or      |           |           |             |
|                    | >         |           |           |             |
|                    |  customer |           |           |             |
+--------------------+-----------+-----------+-----------+-------------+
| >                  | > Una     | > High    | >         | > Malicious |
| **AGENT.OUTSIDER** | uthorized |           |  Minimal/ |             |
|                    | >         |           | >         |             |
|                    |  external |           | >         |             |
|                    | > party   |           |  Moderate |             |
+--------------------+-----------+-----------+-----------+-------------+
| > **AGENT.NATURE** | > Envi    | > N/A     | > Su      | > N/A       |
|                    | ronmental |           | bstantial |             |
|                    | > sources |           |           |             |
|                    | > of      |           |           |             |
|                    | > threats |           |           |             |
|                    | > such as |           |           |             |
|                    | > ear     |           |           |             |
|                    | thquakes, |           |           |             |
|                    | > flood   |           |           |             |
|                    | > and     |           |           |             |
|                    | > fire    |           |           |             |
+--------------------+-----------+-----------+-----------+-------------+

Evil insiders include those legitimate users on the internal ICS network
who misuse privileges or impersonate higher-privileged users.

Outsiders include those intruders gaining access to the ICS from the
Internet, dialup lines, physical break-ins, or from partner (supplier or
customer) networks linked to the corporate network.

#### Attacks

Attacks are described as a combination of attack methods, any
vulnerabilities exploited, and opportunity.

##### Sources of Vulnerability

The sources of vulnerability applicable to the STOE have been captured
below. Please note that these sources of vulnerability should be further
refined by the SST author to identify specific vulnerabilities
applicable to the their own instantiation of the STOE.

Editor's note: The table below refers to sources or categories of
vulnerabilities applicable to an ICS. It is envisaged that the
categories of vulnerabilities listed below will be refined by the SST
author as each STOE will have vulnerabilities specific to their own
security environment in which the ICS is deployed.

[]{#__RefHeading___Toc63689412 .anchor}Table 5 - Vulnerabilities of the
STOE

+----------------+-------------+--------------------------------------+
| > *            | > **Vuln    | > **Description**                    |
| *Vulnerability | erability** |                                      |
| > Label**      |             |                                      |
+================+=============+======================================+
| > *            | > Use of    | > The use of clear text protocols    |
| *V.PLAINTEXT** | > clear     | > and the transmission of business   |
|                | > text      | > and control data unencrypted over  |
|                | > protocols | > insecure communication channels    |
|                |             | > (e.g. FTP, TELNET).                |
+----------------+-------------+--------------------------------------+
| >              | >           | > The presence of unnecessary system |
| **V.SERVICES** | Unnecessary | > services on key ICS components and |
|                | > services  | > subsystems that may be exploited   |
|                | > enabled   | > to negatively impact on system     |
|                | > on system | > security (e.g. sendmail, finger    |
|                | >           | > services).                         |
|                |  components |                                      |
+----------------+-------------+--------------------------------------+
| > **V.REMOTE** | > Remote    | > Uncontrolled external access to    |
|                | > access    | > the corporate network (e.g.        |
|                | > vuln      | > through the Internet) allowing     |
|                | erabilities | > unauthorized entry to the          |
|                |             | > interconnected ICS network. Also   |
|                |             | > includes vulnerabilities           |
|                |             | > introduced through poor VPN        |
|                |             | > configuration, exposed wireless    |
|                |             | > access points, uncontrolled modem  |
|                |             | > access (e.g. through networked     |
|                |             | > faxes) and weak remote user        |
|                |             | > authentication techniques.         |
+----------------+-------------+--------------------------------------+
| > **V.         | > Poor      | > Business and operational           |
| ARCHITECTURE** | > system    | > requirements impacting on the      |
|                | > a         | > effectiveness of deployed or       |
|                | rchitecture | > planned security measures to       |
|                | > design    | > protect the confidentiality,       |
|                | > leading   | > integrity and availability of the  |
|                | > to        | > ICS and its components. Poor       |
|                | >           | > security architecture may also     |
|                |  weaknesses | > lead to the bypass and tamper of   |
|                | > in system | > ICS security functions.            |
|                | > security  |                                      |
|                | > posture   |                                      |
+----------------+-------------+--------------------------------------+
| > **V          | > Poor      | > Lack of quality processes (e.g.    |
| .DEVELOPMENT** | > system    | > configuration management, quality  |
|                | >           | > testing) leading to errors in      |
|                | development | > system implementation and third    |
|                | > practices | > party products such as buffer      |
|                | > leading   | > overflows and errors in control    |
|                | > to        | > algorithms.                        |
|                | > weakness  |                                      |
|                | > in system |                                      |
|                | > imp       |                                      |
|                | lementation |                                      |
+----------------+-------------+--------------------------------------+
| > **           | >           | > Lack of formal system policies,    |
| V.NOPOLICIES** |  Inadequate | > plans and procedures (e.g. weak    |
|                | > system    | > password policies, no incident     |
|                | > security  | > response plans, irregular          |
|                | > policies, | > compliance audits, poor            |
|                | > plans and | > configuration management policies  |
|                | >           | > and procedures, poor system        |
|                |  procedures | > auditing practices, backup         |
|                |             | > procedures etc).                   |
+----------------+-------------+--------------------------------------+
| > **V.SPOF**   | > Single    | > Poor security architecture design  |
|                | > Points of | > leading to one or more single      |
|                | > Failure   | > points of failure in the ICS and   |
|                |             | > resulting in system                |
|                |             | > unavailability.                    |
+----------------+-------------+--------------------------------------+
| > **           | >           | > Inadequate training on system      |
| V.NOTRAINING** |  Inadequate | > security issues leading to poor    |
|                | > user      | > user security awareness.           |
|                | > training  |                                      |
+----------------+-------------+--------------------------------------+
| >              | > U         | > Unauthorized user access to the    |
| **V.3RDPARTY** | nauthorized | > ICS or its components via a 3^rd^  |
|                | > access to | > party network connection.          |
|                | > ICS via   |                                      |
|                | > 3^rd^     |                                      |
|                | > party     |                                      |
|                | > network   |                                      |
+----------------+-------------+--------------------------------------+
| > **V.NORISK** | > Lack of   | > Inadequate risk assessment         |
|                | > risk      | > activities performed on critical   |
|                | >           | > assets leading to a poor           |
|                |  assessment | > understanding of the security      |
|                |             | > posture of the ICS and the         |
|                |             | > security controls needed to        |
|                |             | > counter security risks to the      |
|                |             | > organization.                      |
+----------------+-------------+--------------------------------------+

##### Attack Descriptions

The generic types of attack relevant to the STOE have been captured
below. Please note that the referenced vulnerabilities have been defined
in the previous section.

[]{#__RefHeading___Toc63689413 .anchor}Table 6 -- Attack Methods against
the STOE

+----------------+------------+------------+------------+------------+
| > **Attack     | > **Des    |            |            |            |
| > Label**      | cription** |            |            |            |
+================+============+============+============+============+
|                | >          | >          | >          | >          |
|                | **Attack** | **Method** |  **Vulnera |  **Opportu |
|                |            |            | bilities** | nity**[^2] |
+----------------+------------+------------+------------+------------+
| > **           | > Un       | > Packet   | > V.       | > Locally  |
| ATTACK.SNIFF** | authorized | > capture  | PLAINTEXT, | > &        |
|                | > traffic  | > tool,    | > V.ARC    | > Remotely |
|                | > analysis | >          | HITECTURE, |            |
|                |            |  keystroke | >          |            |
|                |            | > logger   |  V.REMOTE, |            |
|                |            | > etc      | > V        |            |
|                |            |            | .3RDPARTY, |            |
|                |            |            | > V.NORISK |            |
+----------------+------------+------------+------------+------------+
| > **A          | > Un       | > Packet   | > V.       | > Locally  |
| TTACK.REPLAY** | authorized | > capture  | PLAINTEXT, | > &        |
|                | > replay   | > tool,    | > V.ARC    | > Remotely |
|                | > of       | >          | HITECTURE, |            |
|                | > captured |  keystroke | >          |            |
|                | > traffic  | > logger   |  V.REMOTE, |            |
|                |            | > etc      | > V        |            |
|                |            |            | .3RDPARTY, |            |
|                |            |            | > V.NORISK |            |
+----------------+------------+------------+------------+------------+
| > **           | > Imp      | > Ex       | > V.       | > Locally  |
| ATTACK.SPOOF** | ersonating | ploitation | PLAINTEXT, | > &        |
|                | > an       | > of weak  | >          | > Remotely |
|                | >          | > user     |  V.REMOTE, |            |
|                | authorized | > auth     | > V.ARC    |            |
|                | > user     | entication | HITECTURE, |            |
|                |            | >          | > V.N      |            |
|                |            |  mechanism | OPOLICIES, |            |
|                |            |            | > V        |            |
|                |            |            | .3RDPARTY, |            |
|                |            |            | > V.NORISK |            |
+----------------+------------+------------+------------+------------+
| >              | > O        | > D        | > V        | > Remotely |
| **ATTACK.DOS** | verloading | istributed | .SERVICES, |            |
|                | > the      | > denial   | >          |            |
|                | > network  | > of       |  V.REMOTE, |            |
|                |            | > service  | > V.ARC    |            |
|                |            | > attack   | HITECTURE, |            |
|                |            | > from the | > V.SPOF,  |            |
|                |            | > Internet | > V        |            |
|                |            | > causing  | .3RDPARTY, |            |
|                |            | > system   | > V.NORISK |            |
|                |            | > downtime |            |            |
+----------------+------------+------------+------------+------------+
| > **           | > Operator | > ICS      | > V        | > Locally  |
| ATTACK.ERROR** | > error    | > system   | .SERVICES, |            |
|                |            | > operator | > V.N      |            |
|                |            | > error    | OPOLICIES, |            |
|                |            | > causing  | > V.N      |            |
|                |            | > security | OTRAINING, |            |
|                |            | > breach   | > V.NORISK |            |
+----------------+------------+------------+------------+------------+
| > **A          | > Social   | > U        | > V.N      | > Locally  |
| TTACK.SOCIAL** | > e        | nsolicited | OPOLICIES, | > &        |
|                | ngineering | > contact  | > V.N      | > Remotely |
|                | > of       | > with     | OTRAINING, |            |
|                | >          | > employee | > V.NORISK |            |
|                | authorized | > with the |            |            |
|                | > users    | > intent   |            |            |
|                |            | > of       |            |            |
|                |            | > d        |            |            |
|                |            | iscovering |            |            |
|                |            | > user     |            |            |
|                |            | > c        |            |            |
|                |            | redentials |            |            |
|                |            | > or       |            |            |
|                |            | >          |            |            |
|                |            |  acquiring |            |            |
|                |            | >          |            |            |
|                |            |  sensitive |            |            |
|                |            | > i        |            |            |
|                |            | nformation |            |            |
+----------------+------------+------------+------------+------------+
| > **           | > Virus    | > Virus    | > V        | > Locally  |
| ATTACK.VIRUS** | >          | > p        | .SERVICES, |            |
|                |  infection | ropagation | >          |            |
|                | > of ICS   | > via      |  V.REMOTE, |            |
|                | > system   | > email    | > V.ARC    |            |
|                | >          | > system   | HITECTURE, |            |
|                | components | > or       | > V.N      |            |
|                |            | > Internet | OPOLICIES, |            |
|                |            | >          | > V.N      |            |
|                |            | downloaded | OTRAINING, |            |
|                |            | > content  | > V        |            |
|                |            | > (e.g.    | .3RDPARTY, |            |
|                |            | > Trojan)  | > V.NORISK |            |
+----------------+------------+------------+------------+------------+
| > **AT         | > D        | > File     | > V        | > Locally  |
| TACK.DESTROY** | estruction | > deletion | .SERVICES, | > &        |
|                | > of ICS   | > on       | >          | > Remotely |
|                | > control  | > c        |  V.REMOTE, |            |
|                | > data,    | ompromised | > V.ARC    |            |
|                | > business | > ICS file | HITECTURE, |            |
|                | > data or  | > servers  | > V.N      |            |
|                | > con      |            | OPOLICIES, |            |
|                | figuration |            | > V.N      |            |
|                | > i        |            | OTRAINING, |            |
|                | nformation |            | > V.NORISK |            |
+----------------+------------+------------+------------+------------+
| > **A          | > Mo       | > File     | > V        | > Locally  |
| TTACK.MODIFY** | dification | > mo       | .SERVICES, | > &        |
|                | > of ICS   | dification | >          | > Remotely |
|                | > control  | > on       |  V.REMOTE, |            |
|                | > data,    | > c        | > V.ARC    |            |
|                | > business | ompromised | HITECTURE, |            |
|                | > data or  | > ICS file | > V.N      |            |
|                | > con      | > servers  | OPOLICIES, |            |
|                | figuration |            | > V.N      |            |
|                | > i        |            | OTRAINING, |            |
|                | nformation |            | > V.NORISK |            |
+----------------+------------+------------+------------+------------+
| > **A          | > Bypass   | > Mo       | > V        | > Locally  |
| TTACK.BYPASS** | > of       | dification | .SERVICES, | > &        |
|                | > system   | > of ICS   | >          | > Remotely |
|                | > security | > conf     |  V.REMOTE, |            |
|                | >          | igurations | > V.ARC    |            |
|                |  functions | > of       | HITECTURE, |            |
|                | > and      | >          | > V.NORISK |            |
|                | >          | components |            |            |
|                | mechanisms |            |            |            |
+----------------+------------+------------+------------+------------+
| > **ATT        | >          | > Un       | > V.ARC    | > Locally  |
| ACK.PHYSICAL** | Compromise | authorized | HITECTURE, |            |
|                | > of       | > access   | > V.N      |            |
|                | > poorly   | > to       | OPOLICIES, |            |
|                | > i        | >          | > V.N      |            |
|                | mplemented | physically | OTRAINING, |            |
|                | > and/or   | > secured  | > V.NORISK |            |
|                | >          | > areas    |            |            |
|                | controlled | > housing  |            |            |
|                | > physical | > system   |            |            |
|                | > security | > assets   |            |            |
|                | >          | > (e.g.    |            |            |
|                | mechanisms | >          |            |            |
|                |            |  perimeter |            |            |
|                |            | > security |            |            |
|                |            | > breach)  |            |            |
+----------------+------------+------------+------------+------------+
| > **A          | > Acts of  | > Env      | > V.ARC    | > Locally  |
| TTACK.NATURE** | > nature   | ironmental | HITECTURE, |            |
|                | > causing  | > o        | > V.N      |            |
|                | > system   | ccurrences | OPOLICIES, |            |
|                | > unav     | > such as  | > V.       |            |
|                | ailability | > e        | NOTRAINING |            |
|                |            | arthquake, | > V.SPOF,  |            |
|                |            | > flood    | > V.NORISK |            |
|                |            | > and fire |            |            |
+----------------+------------+------------+------------+------------+

#### Assets

Assets protected by the STOE include the following:

[]{#__RefHeading___Toc63689414 .anchor}Table 7 -- Assets protected by
the STOE

+-------------------------+------------+------------------------------+
| > **Asset Label**       | >          | > **Description**            |
|                         |  **Asset** |                              |
+=========================+============+==============================+
| > **ASSET.ACTUATOR**    | > Actuator | > One or more devices that   |
|                         |            | > receive the controlled     |
|                         |            | > variables from the         |
|                         |            | > controller and feeds them  |
|                         |            | > into the controlled        |
|                         |            | > process for action.        |
+-------------------------+------------+------------------------------+
| > **ASSET.SENSOR**      | > Sensor   | > One or more devices that   |
|                         |            | > sense or detect the value  |
|                         |            | > of a process variable and  |
|                         |            | > generates a signal related |
|                         |            | > to the value (includes the |
|                         |            | > sensing and transmitting   |
|                         |            | > parts of the device).      |
+-------------------------+------------+------------------------------+
| > **ASSET.CONTROLLER**  | >          | > The computer system or     |
|                         | Controller | > components that processes  |
|                         |            | > sensor input, executes     |
|                         |            | > control algorithms and     |
|                         |            | > computes actuator outputs  |
|                         |            | > (e.g. Programmable Logic   |
|                         |            | > Controllers).              |
+-------------------------+------------+------------------------------+
| > **ASSET.HMI**         | > HMI      | > The hardware or software   |
|                         |            | > through which an operator  |
|                         |            | > interacts with a           |
|                         |            | > controller, providing a    |
|                         |            | > user with a view into the  |
|                         |            | > manufacturing process for  |
|                         |            | > monitoring or controlling  |
|                         |            | > the process.               |
+-------------------------+------------+------------------------------+
| > **ASSET.REMOTE**      | > Remote   | > The hardware and software  |
|                         | > D        | > devices responsible for    |
|                         | iagnostics | > diagnostic and maintenance |
|                         | > &        | > activities performed on    |
|                         | > M        | > the ICS from remote        |
|                         | aintenance | > locations (e.g. Remote     |
|                         |            | > Terminal Units,            |
|                         |            | > pcAnywhere). May also      |
|                         |            | > include the communications |
|                         |            | > mechanism or protocol used |
|                         |            | > to access to the ICS (e.g. |
|                         |            | > VPN).                      |
+-------------------------+------------+------------------------------+
| > **ASSET.COMMS**       | > Comm     | > The communications         |
|                         | unications | > infrastructure (including  |
|                         | > Infr     | > equipment) used to bridge  |
|                         | astructure | > the control loop within an |
|                         |            | > ICS. Also includes the     |
|                         |            | > network protocols used to  |
|                         |            | > integrate ICS components   |
|                         |            | > and subsystems (e.g.       |
|                         |            | > Ethernet, wireless, RS-232 |
|                         |            | > etc).                      |
+-------------------------+------------+------------------------------+
| > **ASSET.CTRLPROCESS** | >          | > The process subject to     |
|                         | Controlled | > analysis and control by    |
|                         | > Process  | > the ICS (including the     |
|                         |            | > inputs and outputs to the  |
|                         |            | > process).                  |
+-------------------------+------------+------------------------------+
| > **ASSET.CTRLINFO**    | > Process  | > The process control        |
|                         | > Control  | > information being          |
|                         | > I        | > collected by, processed    |
|                         | nformation | > by, stored on and          |
|                         |            | > transmitted to or from the |
|                         |            | > components that constitute |
|                         |            | > the process control        |
|                         |            | > network                    |
+-------------------------+------------+------------------------------+
| > **ASSET.BUSINFO**     | > Process  | > The process control        |
|                         | > Control  | > business or financial      |
|                         | > Business | > information being created  |
|                         | > I        | > by, processed by, stored   |
|                         | nformation | > on and transmitted to or   |
|                         |            | > from the components that   |
|                         |            | > constitute the process     |
|                         |            | > control network.           |
+-------------------------+------------+------------------------------+

#### Threat Description

Using the description of the threat agents, attacks and assets captured
in the previous sections, each of the threats relevant to the STOE have
been characterized below:

[]{#__RefHeading___Toc63689415 .anchor}Table 8 -- Threats countered by
the STOE

+-------------------+----------+--------------------------------------+
| > **Threat        | > **     | > **Description**                    |
| > Label**         | Threat** |                                      |
+===================+==========+======================================+
| >                 | > Unau   | > An unauthorized individual         |
|  **T.DISCLOSURE** | thorized | > (AGENT.EVIL_INSIDER,               |
|                   | > Inf    | > AGENT.PRIOR_INSIDER,               |
|                   | ormation | > AGENT.OUTSIDER) directs an attack  |
|                   | > Di     | > (ATTACK.SNIFF, ATTACK.SOCIAL) to   |
|                   | sclosure | > acquire sensitive information      |
|                   |          | > (ASSET.COMMS, ASSET.CTRLINFO,      |
|                   |          | > ASSET.BUSINFO) stored on ICS       |
|                   |          | > components.                        |
+-------------------+----------+--------------------------------------+
| > **              | > Unau   | > An unauthorized individual         |
| T.EVIL_ANALYSIS** | thorized | > (AGENT.EVIL_INSIDER,               |
|                   | >        | > AGENT.PRIOR_INSIDER,               |
|                   | Analysis | > AGENT.OUTSIDER) directs an attack  |
|                   |          | > (ATTACK.SNIFF, ATTACK.SOCIAL) to   |
|                   |          | > analyze sensitive information      |
|                   |          | > flows (ASSET.COMMS,                |
|                   |          | > ASSET.CTRLPROCESS, ASSET.CTRLINFO, |
|                   |          | > ASSET.BUSINFO) protected by the    |
|                   |          | > STOE.                              |
+-------------------+----------+--------------------------------------+
| > **T.EV          | > Unau   | > An unauthorized individual         |
| IL_MODIFICATION** | thorized | > (AGENT.EVIL_INSIDER,               |
|                   | > Modi   | > AGENT.PRIOR_INSIDER,               |
|                   | fication | > AGENT.OUTSIDER) directs an attack  |
|                   |          | > (ATTACK.MODIFY, ATTACK.BYPASS,     |
|                   |          | > ATTACK.SNIFF) to modify sensitive  |
|                   |          | > information (ASSET.CTRLPROCESS,    |
|                   |          | > ASSET.CTRLINFO, ASSET.BUSINFO)     |
|                   |          | > stored on ICS components.          |
+-------------------+----------+--------------------------------------+
| > **T.E           | > Unau   | > An unauthorized individual         |
| VIL_DESTRUCTION** | thorized | > (AGENT.EVIL_INSIDER,               |
|                   | > Des    | > AGENT.PRIOR_INSIDER,               |
|                   | truction | > AGENT.OUTSIDER) directs an attack  |
|                   |          | > (ATTACK.DESTROY, ATTACK.BYPASS) to |
|                   |          | > destroy sensitive information      |
|                   |          | > (ASSET.CTRLPROCESS,                |
|                   |          | > ASSET.CTRLINFO, ASSET.BUSINFO)     |
|                   |          | > stored on ICS components.          |
+-------------------+----------+--------------------------------------+
| >                 | > T      | > The tampering of ICS components    |
| **T.CTRL_TAMPER** | ampering | > (ASSET.ACTUATOR, ASSET.SENSOR,     |
|                   | > with   | > ASSET.CONTROLLER, ASSET.HMI,       |
|                   | >        | > ASSET.REMOTE, ASSET.COMMS) by      |
|                   |  control | > malicious individuals              |
|                   | > co     | > (AGENT.EVIL_INSIDER,               |
|                   | mponents | > AGENT.PRIOR_INSIDER,               |
|                   |          | > AGENT.OUTSIDER) via the following  |
|                   |          | > attacks (ATTACK.MODIFY,            |
|                   |          | > ATTACK.BYPASS, ATTACK.PHYSICAL).   |
+-------------------+----------+--------------------------------------+
| >                 | > I      | > An authorized operator             |
| **T.BAD_COMMAND** | ntegrity | > (AGENT.INSIDER) accidentally       |
|                   | > of     | > issues bad commands (ATTACK.ERROR) |
|                   | >        | > resulting in the modification of   |
|                   |  Control | > controlled ICS processes and       |
|                   | >        | > components (ASSET.CTRLPROCESS,     |
|                   | Commands | > ASSET.ACTUATOR, ASSET.SENSOR,      |
|                   |          | > ASSET.CONTROLLER, ASSET.HMI).      |
+-------------------+----------+--------------------------------------+
| > **T.SPOOF**     | >        | > An unauthorized individual         |
|                   | Spoofing | > (AGENT.EVIL_INSIDER,               |
|                   | > le     | > AGENT.PRIOR_INSIDER,               |
|                   | gitimate | > AGENT.OUTSIDER) directs an attack  |
|                   | > users  | > (ATTACK.SNIFF, ATTACK.SPOOF,       |
|                   | > of the | > ATTACK.SOCIAL) to obtain user      |
|                   | > STOE   | > credentials (ASSET.REMOTE,         |
|                   |          | > ASSET.COMMS) stored on ICS server  |
|                   |          | > components to impersonate          |
|                   |          | > authorized users.                  |
+-------------------+----------+--------------------------------------+
| > **T.REPUDIATE** | >        | > An authorized user (AGENT.INSIDER) |
|                   | Identity | > denies having performed an action  |
|                   | > rep    | > (ATTACK.ERROR) on the ICS          |
|                   | udiation | > interactive systems (ASSET.REMOTE, |
|                   |          | > ASSET.COMMS, ASSET.HMI).           |
+-------------------+----------+--------------------------------------+
| > **T.DOS**       | > Denial | > An unauthorized individual         |
|                   | > of     | > (AGENT.EVIL_INSIDER,               |
|                   | >        | > AGENT.PRIOR_INSIDER,               |
|                   |  Service | > AGENT.OUTSIDER) directs an attack  |
|                   |          | > (ATTACK.DESTROY, ATTACK.DOS) that  |
|                   |          | > denies service to valid users by   |
|                   |          | > making ICS components              |
|                   |          | > (ASSET.ACTUATOR, ASSET.SENSOR,     |
|                   |          | > ASSET.CONTROLLER, ASSET.HMI,       |
|                   |          | > ASSET.REMOTE, ASSET.COMMS)         |
|                   |          | > temporarily unavailable or         |
|                   |          | > unusable.                          |
+-------------------+----------+--------------------------------------+
| > **T.PRIVILEGE** | > E      | > An unprivileged individual         |
|                   | levation | > (AGENT.EVIL_INSIDER,               |
|                   | > of     | > AGENT.PRIOR_INSIDER,               |
|                   | > p      | > AGENT.OUTSIDER) directs an attack  |
|                   | rivilege | > (ATTACK.ERROR, ATTACK.SNIFF,       |
|                   |          | > ATTACK.SPOOF, ATTACK.SOCIAL) to    |
|                   |          | > obtain user credentials            |
|                   |          | > (ASSET.REMOTE, ASSET.COMMS) stored |
|                   |          | > on ICS server components to        |
|                   |          | > elevate privileged access to ICS   |
|                   |          | > components for malicious purposes. |
+-------------------+----------+--------------------------------------+
| > **T.            | > Fault  | > Faults generated by the system     |
| NO_FAULT_RECORD** | > D      | > (AGENT.INSIDER) as a consequence   |
|                   | etection | > of operator error and/or security  |
|                   |          | > breach (ATTACK.ERROR) while        |
|                   |          | > performing their routine tasks are |
|                   |          | > not detected nor audited on ICS    |
|                   |          | > interactive systems (ASSET.REMOTE, |
|                   |          | > ASSET.COMMS, ASSET.HMI) for        |
|                   |          | > further analysis and correction.   |
+-------------------+----------+--------------------------------------+
| > **T.DISASTER**  | > System | > A natural disaster (AGENT.NATURE)  |
|                   | > Unavai | > ceases operation of one or more    |
|                   | lability | > components of the ICS              |
|                   | > due to | > (ASSET.ACTUATOR, ASSET.SENSOR,     |
|                   | >        | > ASSET.CONTROLLER, ASSET.HMI,       |
|                   |  Natural | > ASSET.REMOTE, ASSET.COMMS) as a    |
|                   | >        | > consequence of earthquake, fire,   |
|                   | Disaster | > flood or other unpredictable event |
|                   |          | > (ATTACK.NATURE).                   |
+-------------------+----------+--------------------------------------+
| > **T.OUTAGE**    | > System | > A natural disaster, malicious or   |
|                   | > Unavai | > non-malicious individual           |
|                   | lability | > (AGENT.NATURE, AGENT.INSIDER,      |
|                   | > due to | > AGENT.EVIL_INSIDER,                |
|                   | > Power  | > AGENT.PRIOR_INSIDER,               |
|                   | > Outage | > AGENT.OUTSIDER) inadvertently (or  |
|                   |          | > otherwise) causes a power outage   |
|                   |          | > affecting the availability of one  |
|                   |          | > or more components of the ICS      |
|                   |          | > (ASSET.ACTUATOR, ASSET.SENSOR,     |
|                   |          | > ASSET.CONTROLLER, ASSET.HMI,       |
|                   |          | > ASSET.REMOTE, ASSET.COMMS).        |
+-------------------+----------+--------------------------------------+
| > **T.INFECTION** | > Virus  | > An individual (AGENT.INSIDER,      |
|                   | > I      | > AGENT.EVIL_INSIDER,                |
|                   | nfection | > AGENT.PRIOR_INSIDER,               |
|                   |          | > AGENT.OUTSIDER) maliciously or     |
|                   |          | > accidentally introduces a virus to |
|                   |          | > the ICS network (ATTACK.VIRUS)     |
|                   |          | > causing unnecessary system         |
|                   |          | > downtime and corruption of data    |
|                   |          | > (ASSET.ACTUATOR, ASSET.SENSOR,     |
|                   |          | > ASSET.CONTROLLER, ASSET.HMI,       |
|                   |          | > ASSET.REMOTE, ASSET.COMMS,         |
|                   |          | > ASSET.CTRLPROCESS, ASSET.CTRLINFO, |
|                   |          | > ASSET.BUSINFO).                    |
+-------------------+----------+--------------------------------------+
| > **T.            | > Unau   | > An unauthorized individual         |
| PHYSICAL_ACCESS** | thorized | > (AGENT.PRIOR_INSIDER,              |
|                   | >        | > AGENT.OUTSIDER) directs an attack  |
|                   | physical | > (ATTACK.PHYSICAL) to gain physical |
|                   | > access | > access to protected ICS components |
|                   |          | > (ASSET.ACTUATOR, ASSET.SENSOR,     |
|                   |          | > ASSET.CONTROLLER, ASSET.HMI,       |
|                   |          | > ASSET.REMOTE, ASSET.COMMS).        |
+-------------------+----------+--------------------------------------+

### Threats Addressed by the Operating Environment

This SPP has not identified any threats relevant to the operating
environment. Organizational security policy P.ENVIRONMENT assumes that
adequate security controls have been deployed to address the threats
relevant to the STOE operating environment.

## Overarching Organizational Security Policies

This section describes the Overarching Organizational Security Policies
(OOSPs) that define the broader context of the organization which
support and govern the use of a system. These will form part of the
basis for deriving the actual organizational security policies (OSPs) to
be included as part of a specific STOE.

The scope of organizational security policy includes both the
organizational security policies of the organization that has
responsibility for operating the industrial control system as well as
those for any external organizations that the industrial control system
interacts with. Security related organizational policies include the
following:

[]{#__RefHeading___Toc63689416 .anchor}Table 9 -- Organizational
Security Policies

+----------------+-----------------------------------------------------+
| > **Name**     | > **Description**                                   |
+================+=====================================================+
| > **P.EVENT**  | > The organization shall monitor security events to |
|                | > ensure compliance with security policies (e.g.    |
|                | > security incident response plan).                 |
+----------------+-----------------------------------------------------+
| > *            | > The organization shall have in place policies,    |
| *P.PERSONNEL** | > training programs, and reporting and enforcement  |
|                | > mechanisms such that personnel know their         |
|                | > security role in the organization.                |
+----------------+-----------------------------------------------------+
| > **P.IN       | > The organization shall provide an organizational  |
| FRASTRUCTURE** | > structure to establish the implementation of the  |
|                | > security program, in which the policies can be    |
|                | > established, maintained and enforced throughout   |
|                | > the organization.                                 |
+----------------+-----------------------------------------------------+
| > **P.C        | > The organization shall provide management and     |
| ONFIGURATION** | > operational security controls necessary to manage |
|                | > the system's configuration during operations and  |
|                | > evaluate and control changes to ensure that the   |
|                | > system remains secure.                            |
+----------------+-----------------------------------------------------+
| >              | > Adequate physical security shall be provided to   |
| **P.PHYSICAL** | > detect or prevent unauthorized access or          |
|                | > connection to the system and its components.      |
+----------------+-----------------------------------------------------+
| > **P.POLICY** | > The organization and system shall comply with     |
|                | > organizational and regulatory policies and        |
|                | > controls governing the use of, and implemented by |
|                | > the system to ensure secure operations.           |
+----------------+-----------------------------------------------------+
| > **P.ASSETS** | > The organization shall provide documentation of   |
|                | > the system and its components, to understand the  |
|                | > overall security posture.                         |
+----------------+-----------------------------------------------------+
| > **P.SAFETY** | > The organization shall comply with relevant       |
|                | > standards to ensure the safety of the system and  |
|                | > its operators.                                    |
+----------------+-----------------------------------------------------+
| > **P.         | > ICS security controls shall be implemented so as  |
| NO_INTERFERE** | > not to impede the minimum required operational    |
|                | > capabilities of the ICS, and so as to not impede  |
|                | > the safety systems that protect the ICS.          |
+----------------+-----------------------------------------------------+
| >              | > The ICS shall be operated in accordance with a    |
| **P.BUSINESS** | > business continuity policy that addresses the     |
|                | > identification of and response to events that     |
|                | > adversely affect the ability of the ICS to        |
|                | > operate in fulfilling its design goals (e.g.      |
|                | > power outages, acts of nature etc).               |
+----------------+-----------------------------------------------------+
| > **P.RISK**   | > The ICS shall be designed, implemented, and       |
|                | > operated to meet the risk objectives resulting    |
|                | > from a system life-cycle risk management program. |
|                | > The risk management program shall establish a     |
|                | > comprehensive and integrated set of risk          |
|                | > management goals for issues affecting ICS         |
|                | > operation, safety and security.                   |
+----------------+-----------------------------------------------------+
| > **P          | > The STOE operating environment shall have         |
| .ENVIRONMENT** | > adequate security controls to counter those       |
|                | > threats originating from outside of the defined   |
|                | > STOE. The implementation and maintenance of these |
|                | > security controls should be in accordance with    |
|                | > organizational security policies similar to those |
|                | > listed in this table and be selected based on the |
|                | > outcomes of a risk assessment.                    |
+----------------+-----------------------------------------------------+

# Risks

The security risks are a further instantiation of the security problem.
The element of risk is captured by the SPP to determine the relative
importance of the security needs of the STOE and its operating
environment. They guide the specification of the security objectives by
ensuring that only those security needs seen as critical to the
organization are addressed by the STOE or its operating environment.

Each risk is a product of asset value, assessed level of relevant
threats, and associated vulnerabilities (as identified in the previous
section). It represents the potential that a given threat will exploit
vulnerabilities to cause loss or damage to an asset or group of assets,
and hence directly or indirectly to the organization.

Please note that this SPP has not specified the level of risk. Rather,
it is intended that the SST author evaluate and prioritize the level of
each risk according to their own ICS implementation (based on the
combination of the value of each asset to the organization, the impact
and probability rating of each threat successfully exploiting the
identified vulnerabilities, and the effectiveness of existing security
controls). Further guidance on the completion and relevance of this
section can be found in chapter 7.

## Risk Categories applicable to the STOE

The categories of security risks relevant to the STOE are described in
Table 10. The table references the threats, vulnerabilities and assets
identified in the previous chapter.

Editor's Note: At this level of abstraction the SPP has only captured
the categories of risk applicable to the generic ICS described by this
SPP. It is anticipated that future SPPs and SSTs will identify specific
risks relevant to the author's own organizational context, and therefore
expand upon the generic risks presented in this chapter.

Editor's Note: The next version will ensure consistency between the
identified risk categories and the security environment and security
objective chapters.

[]{#__RefHeading___Toc63689417 .anchor}Table 10 -- Identified Risk
Categories for the STOE

+-------------+-------------+--------------+-----------+-------------+
| > **Risk    | > **Risk    | >            | > *       | >           |
| > Category  | > Category  |  **Threats** | *Vulnerab |  **Assets** |
| > Label**   | > De        |              | ilities** |             |
|             | scription** |              |           |             |
+=============+=============+==============+===========+=============+
| > **RI      | > Risks     | > T.         | > V.P     | > ASSE      |
| SK.MANAGE** | >           | BAD_COMMAND, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | >            | > V.      | > AS        |
|             | > with the  | T.REPUDIATE, | SERVICES, | SET.SENSOR, |
|             | > security  | >            | >         | > ASSET.    |
|             | > roles and | T.PRIVILEGE, | V.REMOTE, | CONTROLLER, |
|             | > respo     | > T.NO_F     | >         | >           |
|             | nsibilities | AULT_RECORD, | V.ARCHITE |  ASSET.HMI, |
|             | >           |              | CTUREV.NO | > AS        |
|             |  applicable |              | POLICIES, | SET.REMOTE, |
|             | > to all    |              | > V.NO    | > A         |
|             | > ICS       |              | TRAINING, | SSET.COMMS, |
|             | > users, as |              | > V       | > ASSET.    |
|             | > well as   |              | .3RDPARTY | CTRLPROCESS |
|             | > risks     |              | >         |             |
|             | >           |              |  V.NORISK |             |
|             |  associated |              |           |             |
|             | > with the  |              |           |             |
|             | >           |              |           |             |
|             |  successful |              |           |             |
|             | > imp       |              |           |             |
|             | lementation |              |           |             |
|             | > of the    |              |           |             |
|             | > org       |              |           |             |
|             | anizational |              |           |             |
|             | > security  |              |           |             |
|             | > policies. |              |           |             |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK.   | > Risks     | > T.         | > V.P     | > ASSE      |
| SECPOLICY** | >           | BAD_COMMAND, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | >            | > V.      | > AS        |
|             | > with the  | T.REPUDIATE, | SERVICES, | SET.SENSOR, |
|             | > d         | >            | >         | > ASSET.    |
|             | evelopment, | T.PRIVILEGE, | V.REMOTE, | CONTROLLER, |
|             | >           | > T.NO_F     | >         | >           |
|             | endorsement | AULT_RECORD, | V.ARCHITE |  ASSET.HMI, |
|             | > and       | >            | CTUREV.NO | > AS        |
|             | >           |  T.INFECTION | POLICIES, | SET.REMOTE, |
|             | maintenance |              | > V.NO    | > A         |
|             | > of the    |              | TRAINING, | SSET.COMMS, |
|             | >           |              | > V       | > ASSET.C   |
|             | instruction |              | .3RDPARTY | TRLPROCESS, |
|             | >           |              | >         | > ASSE      |
|             |  stipulated |              |  V.NORISK | T.CTRLINFO, |
|             | > by the    |              |           | > AS        |
|             | > corporate |              |           | SET.BUSINFO |
|             | > security  |              |           |             |
|             | > policies. |              |           |             |
+-------------+-------------+--------------+-----------+-------------+
| > **RIS     | > Risks     | > T          | > V.P     | > ASSE      |
| K.RISKMAN** | >           | .DISCLOSURE, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | > T.EV       | > V.      | > AS        |
|             | > with the  | IL_ANALYSIS, | SERVICES, | SET.SENSOR, |
|             | >           | > T.EVIL_M   | >         | > ASSET.    |
|             |  management | ODIFICATION, | V.REMOTE, | CONTROLLER, |
|             | > of the    | > T.EVIL_    | > V.ARCH  | >           |
|             | > risk      | DESTRUCTION, | ITECTURE, |  ASSET.HMI, |
|             | >           | > T.         | > V.SPOF, | > AS        |
|             |  assessment | CTRL_TAMPER, | > V.NO    | SET.REMOTE, |
|             | > processes | > T.         | POLICIES, | > A         |
|             | > for the   | BAD_COMMAND, | > V.NO    | SSET.COMMS, |
|             | > ICS.      | > T.SPOOF,   | TRAINING, | > ASSET.C   |
|             |             | >            | > V       | TRLPROCESS, |
|             |             | T.REPUDIATE, | .3RDPARTY | > ASSE      |
|             |             | > T.DOS,     | >         | T.CTRLINFO, |
|             |             | >            |  V.NORISK | > AS        |
|             |             | T.PRIVILEGE, |           | SET.BUSINFO |
|             |             | > T.NO_F     |           |             |
|             |             | AULT_RECORD, |           |             |
|             |             | >            |           |             |
|             |             |  T.DISASTER, |           |             |
|             |             | >            |           |             |
|             |             | T.INFECTION, |           |             |
|             |             | > T.PHY      |           |             |
|             |             | SICAL_ACCESS |           |             |
+-------------+-------------+--------------+-----------+-------------+
| > **RI      | > Risks     | > TBD        | >         | > ASSE      |
| SK.COMPLY** | >           |              | V.ARCHITE | T.ACTUATOR, |
|             |  associated |              | CTUREV.NO | > AS        |
|             | > with not  |              | POLICIES, | SET.SENSOR, |
|             | > meeting   |              | > V.NO    | > ASSET.    |
|             | > internal  |              | TRAINING, | CONTROLLER, |
|             | > and       |              | > V       | >           |
|             | > statutory |              | .3RDPARTY |  ASSET.HMI, |
|             | > re        |              | >         | > AS        |
|             | quirements. |              |  V.NORISK | SET.REMOTE, |
|             |             |              |           | > A         |
|             |             |              |           | SSET.COMMS, |
|             |             |              |           | > ASSET.C   |
|             |             |              |           | TRLPROCESS, |
|             |             |              |           | > ASSE      |
|             |             |              |           | T.CTRLINFO, |
|             |             |              |           | > AS        |
|             |             |              |           | SET.BUSINFO |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK.   | > Risks     | >            | > V.P     | > ASSE      |
| ASSETCTRL** | >           | T.REPUDIATE, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | >            | > V.      | > AS        |
|             | > with      | T.PRIVILEGE, | SERVICES, | SET.SENSOR, |
|             | > asset     | >            | >         | > ASSET.    |
|             | > clas      | T.INFECTION, | V.REMOTE, | CONTROLLER, |
|             | sification, | > T.PHY      | > V.ARC   | >           |
|             | >           | SICAL_ACCESS | HITECTURE |  ASSET.HMI, |
|             |  labelling, |              | > V.NO    | > AS        |
|             | > media     |              | POLICIES, | SET.REMOTE, |
|             | >           |              | > V.NO    | > A         |
|             |  management |              | TRAINING, | SSET.COMMS, |
|             | > and       |              | > V       | > ASSET.C   |
|             | > acco      |              | .3RDPARTY | TRLPROCESS, |
|             | untability. |              | >         | > ASSE      |
|             |             |              |  V.NORISK | T.CTRLINFO, |
|             |             |              |           | > AS        |
|             |             |              |           | SET.BUSINFO |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK.   | > Risks     | > T.         | > V.P     | > ASSE      |
| PERSONNEL** | >           | BAD_COMMAND, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | > T.SPOOF,   | > V.      | > AS        |
|             | > with      | >            | SERVICES, | SET.SENSOR, |
|             | > personnel | T.REPUDIATE, | >         | > ASSET.    |
|             | > vetting,  | >            | V.REMOTE, | CONTROLLER, |
|             | > security  | T.PRIVILEGE, | > V.ARCH  | >           |
|             | >           | > T.NO_F     | ITECTURE, |  ASSET.HMI, |
|             |  awareness, | AULT_RECORD, | > V.SPOF, | > AS        |
|             | > training, | >            | > V.NO    | SET.REMOTE, |
|             | >           |  T.DISASTER, | POLICIES, | > A         |
|             |  separation | >            | > V.NO    | SSET.COMMS, |
|             | > of duties | T.INFECTION, | TRAINING, | > ASSET.C   |
|             | > and       | > T.PHY      | > V       | TRLPROCESS, |
|             | > system    | SICAL_ACCESS | .3RDPARTY | > ASSE      |
|             | > usage     |              | >         | T.CTRLINFO, |
|             | >           |              |  V.NORISK | > AS        |
|             | agreements. |              |           | SET.BUSINFO |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK    | > Risks     | > T.PHY      | >         | > ASSE      |
| .PHYSICAL** | >           | SICAL_ACCESS | V.ARCHITE | T.ACTUATOR, |
|             |  associated |              | CTUREV.NO | > AS        |
|             | > with      |              | POLICIES, | SET.SENSOR, |
|             | > u         |              | > V.NO    | > ASSET.    |
|             | nauthorized |              | TRAINING, | CONTROLLER, |
|             | > physical  |              | >         | >           |
|             | > access    |              |  V.NORISK |  ASSET.HMI, |
|             | > and/or    |              |           | > AS        |
|             | > damage to |              |           | SET.REMOTE, |
|             | > system    |              |           | >           |
|             | >           |              |           | ASSET.COMMS |
|             | components. |              |           |             |
+-------------+-------------+--------------+-----------+-------------+
| > **RIS     | > Risks     | > T.DISASTER | > V.A     | > ASSE      |
| K.ENVIRON** | >           |              | RCHITECTU | T.ACTUATOR, |
|             |  associated |              | REV.SPOF, | > AS        |
|             | > with the  |              | > V.NO    | SET.SENSOR, |
|             | > effects   |              | POLICIES, | > ASSET.    |
|             | > of        |              | > V.NO    | CONTROLLER, |
|             | > natural   |              | TRAINING, | >           |
|             | >           |              | >         |  ASSET.HMI, |
|             |  disasters, |              |  V.NORISK | > AS        |
|             | > such as   |              |           | SET.REMOTE, |
|             | > fire,     |              |           | > A         |
|             | > flood and |              |           | SSET.COMMS, |
|             | >           |              |           | > ASSET.C   |
|             | earthquake. |              |           | TRLPROCESS, |
|             |             |              |           | > ASSE      |
|             |             |              |           | T.CTRLINFO, |
|             |             |              |           | > AS        |
|             |             |              |           | SET.BUSINFO |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK.EV | > Risks     | > T          | > V.P     | > ASSE      |
| IL_ACCESS** | >           | .DISCLOSURE, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | > T.EV       | > V.      | > AS        |
|             | > with the  | IL_ANALYSIS, | SERVICES, | SET.SENSOR, |
|             | > illicit   | > T.EVIL_M   | >         | > ASSET.    |
|             | > use,      | ODIFICATION, | V.REMOTE, | CONTROLLER, |
|             | > m         | > T.EVIL_    | > V.ARCH  | >           |
|             | odification | DESTRUCTION, | ITECTURE, |  ASSET.HMI, |
|             | > and       | > T.         | > V.SPOF, | > AS        |
|             | >           | CTRL_TAMPER, | > V.NO    | SET.REMOTE, |
|             | destruction | > T.         | POLICIES, | > A         |
|             | > of        | BAD_COMMAND, | > V.NO    | SSET.COMMS, |
|             | > company   | > T.SPOOF,   | TRAINING, | > ASSET.C   |
|             | > data or   | >            | > V       | TRLPROCESS, |
|             | > in        | T.REPUDIATE, | .3RDPARTY | > ASSE      |
|             | appropriate | > T.DOS,     | >         | T.CTRLINFO, |
|             | > access to | >            |  V.NORISK | > AS        |
|             | > i         | T.PRIVILEGE, |           | SET.BUSINFO |
|             | nformation. | > T.NO_      |           |             |
|             | >           | FAULT_RECORD |           |             |
|             | > Risks     |              |           |             |
|             | >           |              |           |             |
|             |  associated |              |           |             |
|             | > with the  |              |           |             |
|             | > inability |              |           |             |
|             | > to make   |              |           |             |
|             | >           |              |           |             |
|             | individuals |              |           |             |
|             | >           |              |           |             |
|             | accountable |              |           |             |
|             | > for the   |              |           |             |
|             | > actions   |              |           |             |
|             | > they take |              |           |             |
|             | > when      |              |           |             |
|             | > using the |              |           |             |
|             | > systems.  |              |           |             |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK.   | > Risks     | > T          | > V.P     | > AS        |
| NEED2KNOW** | >           | .DISCLOSURE, | LAINTEXT, | SET.REMOTE, |
|             |  associated | > T.EV       | > V.      | > A         |
|             | > with the  | IL_ANALYSIS, | SERVICES, | SSET.COMMS, |
|             | > threat to | > T.SPOOF,   | >         | > ASSET.C   |
|             | >           | >            | V.REMOTE, | TRLPROCESS, |
|             | information |  T.PRIVILEGE | >         | > ASSE      |
|             | > conf      |              | V.ARCHITE | T.CTRLINFO, |
|             | identiality |              | CTUREV.NO | > AS        |
|             | > and       |              | POLICIES, | SET.BUSINFO |
|             | > privacy,  |              | > V.NO    |             |
|             | > u         |              | TRAINING, |             |
|             | nauthorised |              | > V       |             |
|             | >           |              | .3RDPARTY |             |
|             |  disclosure |              | >         |             |
|             | > and clear |              |  V.NORISK |             |
|             | > desk      |              |           |             |
|             | >           |              |           |             |
|             |  practices. |              |           |             |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK.   | > Risks     | > TBD        | > V.      | > ASSE      |
| INTEGRATE** | >           |              | SERVICES, | T.ACTUATOR, |
|             |  associated |              | >         | > AS        |
|             | > with the  |              | V.REMOTE, | SET.SENSOR, |
|             | >           |              | > V.ARCH  | > ASSET.    |
|             | integration |              | ITECTURE, | CONTROLLER, |
|             | > of        |              | > V.SPOF, | >           |
|             | > security  |              | > V.NO    |  ASSET.HMI, |
|             | > r         |              | POLICIES, | > AS        |
|             | equirements |              | > V.NO    | SET.REMOTE, |
|             | > into the  |              | TRAINING, | > A         |
|             | > systems   |              | > V       | SSET.COMMS, |
|             | >           |              | .3RDPARTY | > ASSET.C   |
|             | development |              | >         | TRLPROCESS, |
|             | > cycle and |              |  V.NORISK | > ASSE      |
|             | > the       |              |           | T.CTRLINFO, |
|             | > selection |              |           | > AS        |
|             | > of third  |              |           | SET.BUSINFO |
|             | > party     |              |           |             |
|             | > products. |              |           |             |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK    | > Risks     | > T          | > V.P     | > ASSE      |
| .NETCOMMS** | >           | .DISCLOSURE, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | > T.EV       | > V.      | > AS        |
|             | > with the  | IL_ANALYSIS, | SERVICES, | SET.SENSOR, |
|             | >           | > T.         | >         | > ASSET.    |
|             |  protection | CTRL_TAMPER, | V.REMOTE, | CONTROLLER, |
|             | > of        | > T.SPOOF,   | > V.ARCH  | >           |
|             | > network   | > T.DOS,     | ITECTURE, |  ASSET.HMI, |
|             | > com       | > T.NO_F     | > V.SPOF, | > AS        |
|             | munications | AULT_RECORD, | > V.NO    | SET.REMOTE, |
|             | > at the    | >            | POLICIES, | > A         |
|             | > logical   | T.INFECTION, | > V.NO    | SSET.COMMS, |
|             | > and       | > T.PHY      | TRAINING, | > ASSET.C   |
|             | > physical  | SICAL_ACCESS | > V       | TRLPROCESS, |
|             | > layers.   |              | .3RDPARTY | > ASSE      |
|             |             |              | >         | T.CTRLINFO, |
|             |             |              |  V.NORISK | > AS        |
|             |             |              |           | SET.BUSINFO |
+-------------+-------------+--------------+-----------+-------------+
| > **RIS     | > Risks     | > T          | > V.P     | > ASSE      |
| K.CONNECT** | >           | .DISCLOSURE, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | > T.EV       | > V.      | > AS        |
|             | > with      | IL_ANALYSIS, | SERVICES, | SET.SENSOR, |
|             | >           | > T.EVIL_M   | >         | > ASSET.    |
|             | connections | ODIFICATION, | V.REMOTE, | CONTROLLER, |
|             | > to other  | > T.EVIL_    | > V.ARCH  | >           |
|             | > IT        | DESTRUCTION, | ITECTURE, |  ASSET.HMI, |
|             | > systems.  | > T.         | > V.SPOF, | > AS        |
|             |             | CTRL_TAMPER, | > V.NO    | SET.REMOTE, |
|             |             | > T.SPOOF,   | POLICIES, | > A         |
|             |             | > T.DOS,     | > V.NO    | SSET.COMMS, |
|             |             | >            | TRAINING, | > ASSET.C   |
|             |             | T.PRIVILEGE, | > V       | TRLPROCESS, |
|             |             | > T.NO_F     | .3RDPARTY | > ASSE      |
|             |             | AULT_RECORD, | >         | T.CTRLINFO, |
|             |             | >            |  V.NORISK | > AS        |
|             |             |  T.INFECTION |           | SET.BUSINFO |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK    | > Risks     | > T          | > V.P     | > ASSE      |
| .INTERNET** | >           | .DISCLOSURE, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | > T.EV       | > V.      | > AS        |
|             | > with the  | IL_ANALYSIS, | SERVICES, | SET.SENSOR, |
|             | > use of    | > T.EVIL_M   | >         | > ASSET.    |
|             | > the       | ODIFICATION, | V.REMOTE, | CONTROLLER, |
|             | > Internet  | > T.EVIL_    | > V.ARCH  | >           |
|             | > and email | DESTRUCTION, | ITECTURE, |  ASSET.HMI, |
|             | > services  | > T.         | > V.SPOF, | > AS        |
|             | > both      | CTRL_TAMPER, | > V.NO    | SET.REMOTE, |
|             | > internal  | > T.SPOOF,   | POLICIES, | > A         |
|             | > and       | > T.DOS,     | > V.NO    | SSET.COMMS, |
|             | > external  | >            | TRAINING, | > ASSET.C   |
|             | > to the    | T.PRIVILEGE, | > V       | TRLPROCESS, |
|             | > ICS.      | >            | .3RDPARTY | > ASSE      |
|             |             |  T.INFECTION | >         | T.CTRLINFO, |
|             |             |              |  V.NORISK | > AS        |
|             |             |              |           | SET.BUSINFO |
+-------------+-------------+--------------+-----------+-------------+
| > **RI      | > Risks     | > T          | > V.P     | > ASSE      |
| SK.REMOTE** | >           | .DISCLOSURE, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | > T.EV       | > V.      | > AS        |
|             | > with the  | IL_ANALYSIS, | SERVICES, | SET.SENSOR, |
|             | >           | > T.EVIL_M   | >         | > ASSET.    |
|             |  connection | ODIFICATION, | V.REMOTE, | CONTROLLER, |
|             | > of remote | > T.EVIL_    | > V.ARCH  | >           |
|             | > users to  | DESTRUCTION, | ITECTURE, |  ASSET.HMI, |
|             | > the ICS   | > T.         | > V.SPOF, | > AS        |
|             | > network.  | CTRL_TAMPER, | > V.NO    | SET.REMOTE, |
|             |             | > T.SPOOF,   | POLICIES, | > A         |
|             |             | > T.DOS,     | > V.NO    | SSET.COMMS, |
|             |             | >            | TRAINING, | > ASSET.C   |
|             |             | T.PRIVILEGE, | > V       | TRLPROCESS, |
|             |             | >            | .3RDPARTY | > ASSE      |
|             |             |  T.INFECTION | >         | T.CTRLINFO, |
|             |             |              |  V.NORISK | > AS        |
|             |             |              |           | SET.BUSINFO |
+-------------+-------------+--------------+-----------+-------------+
| > **RI      | > Risks     | > T          | > V.P     | > ASSE      |
| SK.ONLINE** | >           | .DISCLOSURE, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | > T.DOS,     | > V.      | > AS        |
|             | > with the  | > T.NO_F     | SERVICES, | SET.SENSOR, |
|             | > delivery  | AULT_RECORD, | >         | > ASSET.    |
|             | > of online | >            | V.REMOTE, | CONTROLLER, |
|             | > services, |  T.INFECTION | > V.ARCH  | >           |
|             | > including |              | ITECTURE, |  ASSET.HMI, |
|             | > statutory |              | > V.SPOF, | > AS        |
|             | > re        |              | > V.NO    | SET.REMOTE, |
|             | quirements, |              | POLICIES, | > A         |
|             | > security  |              | > V.NO    | SSET.COMMS, |
|             | > issues    |              | TRAINING, | > ASSET.C   |
|             | > and       |              | > V       | TRLPROCESS, |
|             | > controls, |              | .3RDPARTY | > ASSE      |
|             | >           |              | >         | T.CTRLINFO, |
|             |  publishing |              |  V.NORISK | > AS        |
|             | > and       |              |           | SET.BUSINFO |
|             | >           |              |           |             |
|             | third-party |              |           |             |
|             | > security. |              |           |             |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK.   | > Risks     | > T          | > V.P     | > ASSE      |
| OPSMANAGE** | >           | .DISCLOSURE, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | > T.EV       | > V.      | > AS        |
|             | > with      | IL_ANALYSIS, | SERVICES, | SET.SENSOR, |
|             | > managing  | > T.EVIL_M   | >         | > ASSET.    |
|             | > system    | ODIFICATION, | V.REMOTE, | CONTROLLER, |
|             | > changes,  | > T.EVIL_    | > V.ARCH  | >           |
|             | > such as   | DESTRUCTION, | ITECTURE, |  ASSET.HMI, |
|             | > changes   | > T.         | > V.SPOF, | > AS        |
|             | > not       | CTRL_TAMPER, | > V.NO    | SET.REMOTE, |
|             | > approved  | > T.         | POLICIES, | > A         |
|             | > or        | BAD_COMMAND, | > V.NO    | SSET.COMMS, |
|             | > audited   | > T.SPOOF,   | TRAINING, | > ASSET.C   |
|             | >           | >            | > V       | TRLPROCESS, |
|             |  correctly, | T.REPUDIATE, | .3RDPARTY | > ASSE      |
|             | > lack of   | > T.DOS,     | >         | T.CTRLINFO, |
|             | > c         | >            |  V.NORISK | > AS        |
|             | onsultation | T.PRIVILEGE, |           | SET.BUSINFO |
|             | > with      | > T.NO_F     |           |             |
|             | > relevant  | AULT_RECORD, |           |             |
|             | > parties,  | >            |           |             |
|             | > loss of   |  T.DISASTER, |           |             |
|             | > skilled   | >            |           |             |
|             | > people,   | T.INFECTION, |           |             |
|             | > and lack  | > T.PHY      |           |             |
|             | > of        | SICAL_ACCESS |           |             |
|             | > correct   |              |           |             |
|             | > doc       |              |           |             |
|             | umentation. |              |           |             |
|             | >           |              |           |             |
|             | > Risks     |              |           |             |
|             | >           |              |           |             |
|             |  associated |              |           |             |
|             | > with the  |              |           |             |
|             | > use of    |              |           |             |
|             | >           |              |           |             |
|             |  technology |              |           |             |
|             | > for data  |              |           |             |
|             | > and       |              |           |             |
|             | > system    |              |           |             |
|             | > control,  |              |           |             |
|             | > including |              |           |             |
|             | > data      |              |           |             |
|             | >           |              |           |             |
|             | protection, |              |           |             |
|             | > backup,   |              |           |             |
|             | > disaster  |              |           |             |
|             | > recovery, |              |           |             |
|             | >           |              |           |             |
|             |  inadequate |              |           |             |
|             | > security, |              |           |             |
|             | > and       |              |           |             |
|             | > i         |              |           |             |
|             | nsufficient |              |           |             |
|             | > capacity, |              |           |             |
|             | > etc.      |              |           |             |
+-------------+-------------+--------------+-----------+-------------+
| > *         | > Risks     | > T.         | > V.      | > ASSE      |
| *RISK.IDS** | >           | BAD_COMMAND, | SERVICES, | T.ACTUATOR, |
|             |  associated | >            | > V.NO    | > AS        |
|             | > with      | T.REPUDIATE, | POLICIES, | SET.SENSOR, |
|             | > security  | > T.NO_F     | > V.NO    | > ASSET.    |
|             | > auditing, | AULT_RECORD, | TRAINING, | CONTROLLER, |
|             | > security  |              | >         | >           |
|             | > breach    |              |  V.NORISK |  ASSET.HMI, |
|             | > detection |              |           | > AS        |
|             | > and       |              |           | SET.REMOTE, |
|             | > response, |              |           | > A         |
|             | > incident  |              |           | SSET.COMMS, |
|             | > reporting |              |           | > ASSET.    |
|             | > and       |              |           | CTRLPROCESS |
|             | > forensic  |              |           |             |
|             | > evidence  |              |           |             |
|             | > re        |              |           |             |
|             | quirements. |              |           |             |
+-------------+-------------+--------------+-----------+-------------+
| > **RISK.C  | > Risks     | > T.EVIL_    | > V.P     | > ASSE      |
| ONTINUITY** | >           | DESTRUCTION, | LAINTEXT, | T.ACTUATOR, |
|             |  associated | > T.         | > V.      | > AS        |
|             | > with      | CTRL_TAMPER, | SERVICES, | SET.SENSOR, |
|             | > ensuring  | > T.         | >         | > ASSET.    |
|             | > the       | BAD_COMMAND, | V.REMOTE, | CONTROLLER, |
|             | > un        | > T.DOS,     | > V.ARCH  | >           |
|             | interrupted | >            | ITECTURE, |  ASSET.HMI, |
|             | > a         |  T.DISASTER, | > V.SPOF, | > AS        |
|             | vailability | >            | > V.NO    | SET.REMOTE, |
|             | > of all    | T.INFECTION, | POLICIES, | > A         |
|             | > key       | > T.PHY      | > V.NO    | SSET.COMMS, |
|             | > business  | SICAL_ACCESS | TRAINING, | > ASSET.C   |
|             | > resources |              | > V       | TRLPROCESS, |
|             | > required  |              | .3RDPARTY | > ASSE      |
|             | > to        |              | >         | T.CTRLINFO, |
|             | > support   |              |  V.NORISK | > AS        |
|             | > essential |              |           | SET.BUSINFO |
|             | > (or       |              |           |             |
|             | > critical) |              |           |             |
|             | > business  |              |           |             |
|             | >           |              |           |             |
|             | activities. |              |           |             |
+-------------+-------------+--------------+-----------+-------------+

## Risks to the External Operating Environment

This SPP has not identified any risks relevant to the external operating
environment. Organizational security policy P.ENVIRONMENT assumes that
adequate security controls have been deployed to mitigate the risks to
the STOE external operating environment.

# Security Objectives

The security objectives are a concise statement of the intended response
to the security problem. These objectives indicate, at a high level, how
the security problem, as characterized in the \"Security Environment\"
section of the SPP, is to be addressed. Just as some threats are to be
addressed by the STOE and others by its intended environment, some
security objectives are for the STOE and others are for its environment.
These two classes of security objectives are discussed separately.

## Security Objectives for the STOE

The security objectives for the STOE are as described in the following
table.

[]{#__RefHeading___Toc63689418 .anchor}Table 11 -- Security Objectives
for the STOE

+-----------------------+----------------------------------------------+
| > **Objective Label** | > **Objective Description**                  |
+=======================+==============================================+
| > **O.                | > The STOE must provide protection at the    |
| Boundary_Protection** | > physical boundaries of the ICS to prevent  |
|                       | > access to the process control network by   |
|                       | > unauthorized users; and to prevent         |
|                       | > unauthorized access to the ICS and the     |
|                       | > physical plant.                            |
+-----------------------+----------------------------------------------+
| > **O.Risk**          | > ICS risk assessment shall be conducted     |
|                       | > throughout the life-cycle of an ICS, such  |
|                       | > that a documented and approved risk        |
|                       | > assessment process is conducted initially, |
|                       | > and reviewed with each change to the       |
|                       | > manufacturing process or change to the     |
|                       | > ICS; and to ensure that changing           |
|                       | > vulnerabilities do not degrade the         |
|                       | > security of the ICS.                       |
+-----------------------+----------------------------------------------+
| > *                   | > The ICS security functions shall be        |
| *O.Non_Interference** | > implemented in a non-interfering manner    |
|                       | > such behavior of the ICS functions and     |
|                       | > safety functions are able to meet their    |
|                       | > performance constraints.                   |
+-----------------------+----------------------------------------------+
| > **O.Data_Backup**   | > The STOE must include provisions for ICS   |
|                       | > data and control information (including    |
|                       | > executable software and control data) to   |
|                       | > assure the ability for timely recovery to  |
|                       | > an operating state if the ICS is           |
|                       | > compromised or damaged. The data backup    |
|                       | > procedures should follow industry best     |
|                       | > practices including (but not limited to)   |
|                       | > secondary storage locations, testing of    |
|                       | > recovery procedures, and a back up         |
|                       | > interval either driven by configuration    |
|                       | > changes or a specified time interval or a  |
|                       | > combination of both.                       |
+-----------------------+----------------------------------------------+
| > **O.                | > The STOE shall authenticate configuration  |
| Data_Authentication** | > change commands such that configuration    |
|                       | > (control algorithms, set points, limit     |
|                       | > points, etc.) cannot be changed unless the |
|                       | > integrity of the command can be positively |
|                       | > established.                               |
|                       | >                                            |
|                       | > The STOE shall authenticate financial or   |
|                       | > other business critical information sent   |
|                       | > from the STOE to external systems with a   |
|                       | > minimum of a time stamped digital          |
|                       | > signature.                                 |
+-----------------------+----------------------------------------------+
| > **O.Backup_Power**  | > Emergency backup power will be available   |
|                       | > to the ICS with sufficient capacity to     |
|                       | > permit safe and recoverable shutdown of    |
|                       | > the process if external power is lost.     |
+-----------------------+----------------------------------------------+
| > **O.Continuity**    | > The ICS shall ensure continuity of         |
|                       | > operations in accordance with a business   |
|                       | > continuity policy that addresses a known   |
|                       | > set of anticipated events that might       |
|                       | > adversely affect the operational           |
|                       | > capability of the ICS.                     |
+-----------------------+----------------------------------------------+
| > **O.Verify**        | > The ICS components as an integrated system |
|                       | > shall be capable of undergoing             |
|                       | > verification analysis and testing to       |
|                       | > ensure that the ICS:                       |
|                       |                                              |
|                       | -   Meets is security design specification;  |
|                       |                                              |
|                       | -   Is properly installed and integrated;    |
|                       |                                              |
|                       | -   Is properly configured.                  |
+-----------------------+----------------------------------------------+
| > **O.Ownership**     | > Identified roles and responsibilities,     |
|                       | > together with explicit authority to ensure |
|                       | > operational security within the management |
|                       | > infrastructure; an organization wide,      |
|                       | > security infrastructure.                   |
+-----------------------+----------------------------------------------+
| > **O.Migration**     | > The ICS shall have a migration strategy    |
|                       | > providing the capability to govern the     |
|                       | > evolution of the control system throughout |
|                       | > its security operational life cycle. The   |
|                       | > migration strategy shall address at a      |
|                       | > minimum:                                   |
|                       |                                              |
|                       | -   Assessment of new vulnerabilities and    |
|                       |     appropriate/necessary mitigating actions |
|                       |     to control/reduce new vulnerabilities.   |
|                       |     This may include maintenance of the      |
|                       |     current system state (components,        |
|                       |     configuration, patches, etc).            |
|                       |                                              |
|                       | -   The integration between computer         |
|                       |     implemented and personnel implemented    |
|                       |     procedures.                              |
+-----------------------+----------------------------------------------+
| > **O.Compliance**    | > The ICS shall be operated in compliance    |
|                       | > with relevant governing mandates.          |
+-----------------------+----------------------------------------------+
| > **O.Collaborate**   | > Policies governing the roles,              |
|                       | > responsibilities and activities authorized |
|                       | > for individuals not employed by the        |
|                       | > control system operating organization      |
|                       | > shall be developed.                        |
|                       | >                                            |
|                       | > The policies shall establish methods for   |
|                       | > on-site internal, on-site remote, and      |
|                       | > off-site remote access to control system   |
|                       | > resources                                  |
+-----------------------+----------------------------------------------+
| >                     | > The ICS shall provide the capability to    |
|  **O.Access_Control** | > grant or deny access to control system     |
|                       | > resources based upon the action being      |
|                       | > performed, and the authorizations          |
|                       | > associated with authorized subjects.       |
|                       | >                                            |
|                       | > The ICS shall deny unauthorized agents     |
|                       | > access to every control system resource.   |
|                       | >                                            |
|                       | > The ICS shall require that each agent      |
|                       | > authorized to use the control system is    |
|                       | > identified and is provided with            |
|                       | > credentials to authenticate their          |
|                       | > identity.                                  |
|                       | >                                            |
|                       | > The ICS must be able to include knowledge  |
|                       | > of the control system state and/or the     |
|                       | > controlled process state when making an    |
|                       | > access control decision.                   |
|                       | >                                            |
|                       | > The ICS shall include knowledge of time    |
|                       | > and location in the rules for making an    |
|                       | > access control decision.                   |
+-----------------------+----------------------------------------------+
| >                     | > The ICS shall provide the capability to    |
| **O.Comms_Integrity** | > prevent or detect, as required, the loss   |
|                       | > of integrity of the ICS operational        |
|                       | > communications capability.                 |
|                       | >                                            |
|                       | > The ICS shall provide the capability to    |
|                       | > allow information flows only between       |
|                       | > authenticated and authorized endpoints.    |
|                       | >                                            |
|                       | > The ICS shall provide the capability to    |
|                       | > protect information flows from replay,     |
|                       | > substitution or modification.              |
|                       | >                                            |
|                       | > The ICS shall provide the capability to    |
|                       | > allow the recipient of an authorized       |
|                       | > information flow to verify the correctness |
|                       | > of the received information.               |
+-----------------------+----------------------------------------------+
| > **O.Available**     | > The ICS shall have continuity of           |
|                       | > availability of operational capability.    |
|                       | >                                            |
|                       | > The ICS shall be capable of continuing     |
|                       | > operation if a control server is           |
|                       | > unavailable for any reason.                |
|                       | >                                            |
|                       | > The ICS shall be capable of continuing     |
|                       | > operation if the primary communications    |
|                       | > channel is unavailable for any reason.     |
+-----------------------+----------------------------------------------+
| > **                  | > The ICS shall provide the capability to    |
| O.Control_Integrity** | > prevent or detect, as required, the loss   |
|                       | > of integrity of the ICS operational system |
|                       | > configuration and capability.              |
|                       | >                                            |
|                       | > The ICS shall provide the capability to    |
|                       | > restrict access to the functions used to   |
|                       | > establish and maintain the secure          |
|                       | > operational configuration of the ICS.      |
|                       | >                                            |
|                       | > The ICS shall be capable of performing     |
|                       | > self-tests to verify the configuration and |
|                       | > integrity of the security functions of the |
|                       | > ICS.                                       |
|                       | >                                            |
|                       | > The ICS shall provide the capability for   |
|                       | > self-test to be executed on startup, at    |
|                       | > periodic intervals, and on demand.         |
|                       | >                                            |
|                       | > The ICS shall be capable of responding to  |
|                       | > integrity failures.                        |
+-----------------------+----------------------------------------------+

## Security Objectives for the External Operating Environment

This SPP has not identified any security objectives relevant to the
external operating environment. Organizational security policy
P.ENVIRONMENT assumes that adequate security controls have been deployed
to address the security needs outside the scope of the STOE.

# IT Security Requirements

## STOE Security Functional Requirements

This section contains the functional requirements for the STOE. This
includes system security functional requirements and system security
assurance requirements. The requirements are primarily stated as logical
requirements and cover information technology related requirements,
requirements for system security policies and system security related
operating procedures, and integration requirements addressing interfaces
and interoperability between security system components. The functional
requirements are listed in summary form in the table below.

Editor's Note: Table 12 and the text below it outline extensions to the
functional requirements that is building on ISO system work in concert
with NIST work building on security controls.

[]{#__RefHeading___Toc63689419 .anchor}Table 12 -- STOE Security
Functional Requirements

+--------+------------------+------------------------------------------+
| >      |                  |                                          |
|  **No. |                  |                                          |
| > Com  |                  |                                          |
| ponent |                  |                                          |
| > Com  |                  |                                          |
| ponent |                  |                                          |
| >      |                  |                                          |
| Name** |                  |                                          |
+--------+------------------+------------------------------------------+
| > *    |                  |                                          |
| *Class |                  |                                          |
| > FAU: |                  |                                          |
| > A    |                  |                                          |
| udit** |                  |                                          |
+--------+------------------+------------------------------------------+
| > 1    | > FAU_ARP.1      | > Security alarms                        |
+--------+------------------+------------------------------------------+
| > 2    | > FAU_GEN.1      | > Audit data generation                  |
+--------+------------------+------------------------------------------+
| > 3    | > FAU_GEN.2      | > User identity association              |
+--------+------------------+------------------------------------------+
| > 4    | > FAU_SAA.1      | > Potential violation analysis           |
+--------+------------------+------------------------------------------+
| > 5    | > FAU_SAA.2      | > Profile based anomaly detection        |
+--------+------------------+------------------------------------------+
| > 6    | > FAU_SAA.3      | > Simple attack heuristics               |
+--------+------------------+------------------------------------------+
| > 7    | > FAU_SAA.4      | > Complex attack heuristics              |
+--------+------------------+------------------------------------------+
| > 8    | > FAU_SEL.1      | > Selective audit                        |
+--------+------------------+------------------------------------------+
| > *    |                  |                                          |
| *Class |                  |                                          |
| > FCS: |                  |                                          |
| > C    |                  |                                          |
| ryptog |                  |                                          |
| raphic |                  |                                          |
| > sup  |                  |                                          |
| port** |                  |                                          |
+--------+------------------+------------------------------------------+
| > 9    | > FCS_CKM.4      | > Cryptographic key management           |
+--------+------------------+------------------------------------------+
| > 10   | > FCS_COP.1      | > Cryptographic operation                |
+--------+------------------+------------------------------------------+
| > *    |                  |                                          |
| *Class |                  |                                          |
| > FDP: |                  |                                          |
| > User |                  |                                          |
| > data |                  |                                          |
| >      |                  |                                          |
| protec |                  |                                          |
| tion** |                  |                                          |
+--------+------------------+------------------------------------------+
| > 11   | > FDP_ACC.1      | > Subset access control                  |
+--------+------------------+------------------------------------------+
| > 12   | > FDP_ACC.2      | > Complete access control                |
+--------+------------------+------------------------------------------+
| > 13   | > FDP_ACF.1      | > Security attribute based access        |
|        |                  | > control                                |
+--------+------------------+------------------------------------------+
| > 14   | > FDP_DAU.2      | > Data authentication                    |
+--------+------------------+------------------------------------------+
| > 15   | > FDP_IFC.1      | > Subset information flow control        |
+--------+------------------+------------------------------------------+
| > 16   | > FDP_IFC.2      | > Complete information flow control      |
+--------+------------------+------------------------------------------+
| > 17   | > FDP_IFF.1      | > Simple security attributes             |
+--------+------------------+------------------------------------------+
| > 18   | > FDP_RIP.2      | > Full residual information protection   |
+--------+------------------+------------------------------------------+
| > 19   | > FDP_UCT.1      | > Basic data exchange confidentiality    |
+--------+------------------+------------------------------------------+
| > 20   | > FDP_UIT.1      | > Data exchange integrity                |
+--------+------------------+------------------------------------------+
| > 21   | > FDP_UIT.2      | > Source data exchange recovery          |
+--------+------------------+------------------------------------------+
| > *    |                  |                                          |
| *Class |                  |                                          |
| > FIA: |                  |                                          |
| > Id   |                  |                                          |
| entifi |                  |                                          |
| cation |                  |                                          |
| > &    |                  |                                          |
| > Auth |                  |                                          |
| entica |                  |                                          |
| tion** |                  |                                          |
+--------+------------------+------------------------------------------+
| > 22   | > FIA_AFL.1      | > Authentication failure handling        |
+--------+------------------+------------------------------------------+
| > 23   | > FIA_ATD.1      | > User attribute definition              |
+--------+------------------+------------------------------------------+
| > 24   | > FIA_SOS.1      | > Verification of passwords              |
+--------+------------------+------------------------------------------+
| > 25   | > FIA_SOS.2      | > TSF generation of passwords            |
+--------+------------------+------------------------------------------+
| > 26   | > FIA_UAU.1      | > Timing of authentication               |
+--------+------------------+------------------------------------------+
| > 27   | > FIA_UAU.2      | > User authentication before any action  |
+--------+------------------+------------------------------------------+
| > 28   | > FIA_UAU.3      | > Unforgeable authentication             |
+--------+------------------+------------------------------------------+
| > 29   | > FIA_UAU.4      | > Single use authentication mechanisms   |
+--------+------------------+------------------------------------------+
| > 30   | > FIA_UAU.7      | > Protected authentication feedback      |
+--------+------------------+------------------------------------------+
| > 31   | > FIA_UID.1      | > Timing of identification               |
+--------+------------------+------------------------------------------+
| > 32   | > FIA_UID.2      | > User identification before any action  |
+--------+------------------+------------------------------------------+
| > *    |                  |                                          |
| *Class |                  |                                          |
| > FMT: |                  |                                          |
| > Mana |                  |                                          |
| gement |                  |                                          |
| > of   |                  |                                          |
| > fun  |                  |                                          |
| ctions |                  |                                          |
| > in   |                  |                                          |
| >      |                  |                                          |
|  TSF** |                  |                                          |
+--------+------------------+------------------------------------------+
| > 33   | > FMT_MOF.1      | > Management of security functions       |
|        |                  | > behavior                               |
+--------+------------------+------------------------------------------+
| > 34   | > FMT_MOF.2      | > Security function and security policy  |
|        |                  | > mapping                                |
+--------+------------------+------------------------------------------+
| > 35   | > FMT_MSA.1      | > Management of security attributes      |
+--------+------------------+------------------------------------------+
| > 36   | > FMT_MTD.1      | > Management of TSF data                 |
+--------+------------------+------------------------------------------+
| > 37   | > FMT_MTD.4\`    | > Management of TSF data to policy       |
|        |                  | > mapping                                |
+--------+------------------+------------------------------------------+
| > 38   | > FMT_REV.1      | > Revocation                             |
+--------+------------------+------------------------------------------+
| > 39   | > FMT_SAE.1      | > Time limited authorization             |
+--------+------------------+------------------------------------------+
| > 40   | > FMT_SMF.1      | > Security management functions          |
+--------+------------------+------------------------------------------+
| > 41   | > FMT_SMR.1      | > Security roles                         |
+--------+------------------+------------------------------------------+
| > 42   | > FMT_SMR.2      | > Restrictions on security roles         |
+--------+------------------+------------------------------------------+
| > 43   | > FMT_SMR.4      | > Security role to policy mapping        |
+--------+------------------+------------------------------------------+
| > *    |                  |                                          |
| *Class |                  |                                          |
| > FEM: |                  |                                          |
| > Se   |                  |                                          |
| curity |                  |                                          |
| >      |                  |                                          |
|  event |                  |                                          |
| >      |                  |                                          |
| monito |                  |                                          |
| ring** |                  |                                          |
+--------+------------------+------------------------------------------+
| > 44   | > FEM_EDI.1      | > Event definition and identification    |
+--------+------------------+------------------------------------------+
| > 45   | > FEM_EDI.2      | > Interaction of system event monitoring |
|        |                  | > components                             |
+--------+------------------+------------------------------------------+
| > 46   | > FEM_EDI.3      | > Alarm audit requirements               |
+--------+------------------+------------------------------------------+
| > 47   | > FEM_EDI.4      | > Alarm response                         |
+--------+------------------+------------------------------------------+
| > *    |                  |                                          |
| *Class |                  |                                          |
| > FPT: |                  |                                          |
| > Prot |                  |                                          |
| ection |                  |                                          |
| > of   |                  |                                          |
| > the  |                  |                                          |
| >      |                  |                                          |
|  TSF** |                  |                                          |
+--------+------------------+------------------------------------------+
| > 48   | > FPT_AMT.1      | > Abstract machine testing               |
+--------+------------------+------------------------------------------+
| > 49   | > FPT_FLS.1      | > Failure with preservation of secure    |
|        |                  | > state                                  |
+--------+------------------+------------------------------------------+
| > 50   | > FPT_ITA.1      | > Inter-TSF availability within a        |
|        |                  | > defined availability metric            |
+--------+------------------+------------------------------------------+
| > 51   | > FPT_ITC.1      | > Inter-TSF confidentiality during       |
|        |                  | > transmission                           |
+--------+------------------+------------------------------------------+
| > 52   | > FPT_ITI.1      | > Inter-TSF detection of modification    |
+--------+------------------+------------------------------------------+
| > 31   | > FPT_ITI.2      | > Inter-TSF detection and correction of  |
|        |                  | > modification                           |
+--------+------------------+------------------------------------------+
| > 52   | > FPT_PHP.1      | > Passive detection of physical attack   |
+--------+------------------+------------------------------------------+
| > 53   | > FPT_PHP.2      | > Notification of physical attack        |
+--------+------------------+------------------------------------------+
| > 54   | > FPT_PHP.3      | > Resistance to physical attack          |
+--------+------------------+------------------------------------------+
| > 55   | > FPT_PHP.4      | > Domain definition and alarm response   |
+--------+------------------+------------------------------------------+
| > 56   | > FPT_RCV.2      | > Automated recovery                     |
+--------+------------------+------------------------------------------+
| > 57   | > FPT_RCV.3      | > Automated recovery without undue loss  |
+--------+------------------+------------------------------------------+
| > 58   | > FPT_RCV.4      | > Function recovery                      |
+--------+------------------+------------------------------------------+
| > 59   | > FPT_RPL.1      | > Replay detection                       |
+--------+------------------+------------------------------------------+
| > 60   | > FPT_SSP.1      | > Simple trusted acknowledgement         |
+--------+------------------+------------------------------------------+
| > 61   | > FPT_SSP.2      | > Mutual trusted acknowledgement         |
+--------+------------------+------------------------------------------+
| > 62   | > FPT_STM.1      | > Reliable time stamps                   |
+--------+------------------+------------------------------------------+
| > 63   | > FPT_TDC.1      | > Inter-TSF data consistency             |
+--------+------------------+------------------------------------------+
| > 64   | > FPT_TRC.1      | > Internal TSF consistency               |
+--------+------------------+------------------------------------------+
| > 65   | > FPT_TST.1      | > TSF testing                            |
+--------+------------------+------------------------------------------+
| > *    |                  |                                          |
| *Class |                  |                                          |
| > FCM: |                  |                                          |
| > Prot |                  |                                          |
| ection |                  |                                          |
| > of   |                  |                                          |
| >      |                  |                                          |
| System |                  |                                          |
| > Con  |                  |                                          |
| figura |                  |                                          |
| tion** |                  |                                          |
+--------+------------------+------------------------------------------+
| > 66   | > FCM_IDI.1      | > Identification information             |
+--------+------------------+------------------------------------------+
| > 67   | > FCM_IDI.2      | > Change requests and actions            |
+--------+------------------+------------------------------------------+
| > 68   | > FCM_IDI.3      | > Authorizations                         |
+--------+------------------+------------------------------------------+
| > *    |                  |                                          |
| *Class |                  |                                          |
| > FRU: |                  |                                          |
| > Re   |                  |                                          |
| source |                  |                                          |
| > u    |                  |                                          |
| tiliza |                  |                                          |
| tion** |                  |                                          |
+--------+------------------+------------------------------------------+
| > 70   | > FRU_FLT.1      | > Degraded fault tolerance               |
+--------+------------------+------------------------------------------+
| > 71   | > FRU_PRS.1      | > Limited priority of service            |
+--------+------------------+------------------------------------------+
| > 72   | > FRU_PRS.2      | > Full priority of service               |
+--------+------------------+------------------------------------------+
| > *    |                  |                                          |
| *Class |                  |                                          |
| > FTP: |                  |                                          |
| > T    |                  |                                          |
| rusted |                  |                                          |
| > pat  |                  |                                          |
| h/chan |                  |                                          |
| nels** |                  |                                          |
+--------+------------------+------------------------------------------+
| > 73   | > FTP_ITC.1      | > Inter-TSF trusted channel              |
+--------+------------------+------------------------------------------+
| > 74\` | > FTP_ITP.1      | > Trusted path                           |
+--------+------------------+------------------------------------------+

The following sections contain the functional components from the Common
Criteria Part 2 \[CC2\] (CC) with the operations completed. The standard
CC text is in regular font; the text inserted by the System Protection
Profile (SPP) author is in accordance with the conventions described in
at the beginning of this document.

Editor's note: The security functional requirements listed in the above
table will be specified in the next release of this document. Reviewers
should ensure that high-level functionality (as captured by the security
objectives) is consistent with their understanding of the STOE.

### Logon Controls:

**FIA_UID.1 Timing of identification**

Hierarchical to: No other components.

**FIA_UID.1.1 The TSF shall allow \[assignment: *list of TSF-mediated
actions*\] on behalf of the user to be performed before the user is
identified.**

**FIA_UID.1.2 The TSF shall require each user to be successfully
identified before allowing any other TSF-mediated actions on behalf of
that user.**

Dependencies: No dependencies

**FIA_UAU.1 Timing of authentication**

Hierarchical to: No other components.

**FIA_UAU.1.1 The TSF shall allow \[assignment: *list of TSF mediated
actions*\] on behalf of the user to be performed before the user is
authenticated.**

**FIA_UAU.1.2 The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated actions on behalf
of that user.**

Dependencies: **FIA_UID.1 Timing of identification**

**FIA_UAU.2 User authentication before any action**

Hierarchical to: FIA_UAU.1

**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.

Dependencies: **FIA_UID.1 Timing of identification**

**FIA_AFL.1 Authentication failure handling**

Hierarchical to: No other components.

**FIA_AFL.1.1 The TSF shall detect when \[assignment: *number*\]
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 met or surpassed, the TSF shall \[assignment: *list of
actions*\].**

Dependencies: **FIA_UAU.1 Timing of authentication**

**FTP_TRP.1 Trusted path**

Hierarchical to: No other components.

**FTP_TRP.1.1 The TSF shall provide a communication path between itself
and \[selection: *remote, local*\] users that is logically distinct from
other communication paths and provides assured identification of its end
points and protection of the communicated data from modification or
disclosure.**

**FTP_TRP.1.2 The TSF shall permit \[selection: *the TSF, local users,
remote users*\] to initiate communication via the trusted path.**

**FTP_TRP.1.3 The TSF shall require the use of the trusted path for
\[selection: *initial user authentication*, \[assignment: *other
services for which trusted path is required*\].**

Dependencies: No dependencies

**FTA_TSE.1 TOE session establishment**

Hierarchical to: No other components.

**FTA_TSE.1.1 The TSF shall be able to deny session establishment based
on \[assignment: *attributes*\].**

Dependencies: No dependencies

### Password Selection

**FIA_SOS.1 Verification of *passwords***

Hierarchical to: No other components.

**FIA_SOS.1.1 The TSF shall provide a mechanism to verify that
*passwords* meet \[assignment: *a defined quality metric*\].**

Dependencies: No dependencies

**FIA_SOS.2 TSF Generation of *passwords***

Hierarchical to: No other components.

**FIA_SOS.2.1 The TSF shall provide a mechanism to generate *passwords*
that meet \[assignment: *a defined quality metric*\].**

**FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated
*passwords* for \[assignment: *list of TSF functions*\].**

Dependencies: No dependencies

**FMT_SAE.1 Time-limited authorisation**

Hierarchical to: No other components.

**FMT_SAE.1.1 The TSF shall restrict the capability to specify an
expiration time for \[assignment: *list of security attributes for which
expiration is to be supported*\] to \[assignment: *the authorized
identified roles*\].**

**FMT_SAE.1.2 For each of these security attributes, the TSF shall be
able to \[assignment: *list of actions to be taken for each security
attribute*\] after the expiration time for the indicated security
attribute has passed.**

Dependencies: **FMT_SMR.1 Security roles**

**FPT_STM.1 Reliable time stamps**

### Authentication Data Protection

**FIA_UAU.7 Protected authentication feedback**

Hierarchical to: No other components.

**FIA_UAU.7.1 The TSF shall provide only \[assignment: *list of
feedback*\] to the user while the authentication is in progress.**

Dependencies: **FIA_UAU.1 Timing of authentication**

(For passwords)

**FMT_MTD.1Management of TSF data**

Hierarchical to: No other components.

**FMT_MTD.1.1 The TSF shall restrict the ability to \[selection:
*change_default, query, modify, delete, clear*, \[assignment: *other
operations*\]\] the \[assignment: *list of TSF data*\] to \[assignment:
*the authorized identified roles*\].**

Dependencies: **FMT_SMF.1 Specification of management functions**

**FMT_SMR.1 Security roles**

**FPT_RPL.1 Replay detection**

Hierarchical to: No other components.

**FPT_RPL.1.1 The TSF shall detect replay for the following entities:
\[assignment: *list of identified entities*\].**

**FPT_RPL.1.2 The TSF shall perform \[assignment: *list of specific
actions*\] when replay is detected.**

Dependencies: No dependencies

### Replay / Reuse

**FIA_UAU.3 Unforgeable authentication**

Hierarchical to: No other components.

**FIA_UAU.3.1 The TSF shall \[selection: *detect, prevent*\] use of
authentication data that has been forged by any user of the TSF.**

**FIA_UAU.3.2 The TSF shall \[selection: *detect, prevent*\] use of
authentication data that has been copied from any other user of the
TSF.**

Dependencies: No dependencies

**FIA_UAU.4 Single-use authentication mechanisms**

Hierarchical to: No other components.

**FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related
to \[assignment: *identified authentication mechanism(*s)\].**

Dependencies: No dependencies

\-\--These are targeted to preventing replay attacks from captured
control signals\-\--

### Session Suspension

**FTA_SSL.1 TSF-initiated session locking**

Hierarchical to: No other components.

**FTA_SSL.1.1 The TSF shall lock an interactive session after
\[assignment: *time interval of user inactivity*\] by:**

**a) clearing or overwriting display devices, making the current
contents unreadable;**

**b) disabling any activity of the user's data access/display devices
other than unlocking the session.**

**FTA_SSL.1.2 The TSF shall require the following events to occur prior
to unlocking the session: \[assignment: *events to occur*\].**

Dependencies: **FIA_UAU.1 Timing of authentication**

**FTA_SSL.2 User-initiated locking**

Hierarchical to: No other components.

**FTA_SSL.2.1 The TSF shall allow user-initiated locking of the user's
own interactive session,**

**by:**

**a) clearing or overwriting display devices, making the current
contents unreadable;**

**b) disabling any activity of the user's data access/display devices
other than unlocking the session.**

**FTA_SSL.2.2 The TSF shall require the following events to occur prior
to unlocking the session: \[assignment: *events to occur*\].**

Dependencies: **FIA_UAU.1 Timing of authentication**

**FTA_SSL.3 TSF-initiated termination**

Hierarchical to: No other components.

**FTA_SSL.3.1 The TSF shall terminate an interactive session after a
\[assignment: *time interval of user inactivity*\].**

Dependencies: No dependencies

### User Accounts and Profiles

**FMT_MTD.1Management of TSF data**

Hierarchical to: No other components.

**FMT_MTD.1.1 The TSF shall restrict the ability to \[selection:
*change_default, query, modify, delete, clear*, \[assignment: *other
operations*\]\] the \[assignment: *list of TSF data*\] to \[assignment:
*the authorized identified roles*\].**

Dependencies: **FMT_SMF.1 Specification of management functions**

**FMT_SMR.1 Security roles**

(User accounts and User profiles)

**FIA_ATD.1 User attribute definition**

Hierarchical to: No other components.

**FIA_ATD.1.1 The TSF shall maintain the following list of security
attributes belonging to individual users: \[assignment: *list of
security attributes*\].**

Dependencies: No dependencies

(Definition of user security attributes contained in a user profile)

### Role based access control

**FDP_ACC.1 Subset access control**

Hierarchical to: No other components.

**FDP_ACC.1.1 The TSF shall enforce the \[assignment: *access control
SFP*\] on \[assignment: *list of subjects*, *objects, and operations
among subjects and objects covered by the SFP*\].**

Dependencies: **FDP_ACF.1 Security attribute based access control**

**FDP_ACC.2 Complete access control**

Hierarchical to: FDP_ACC.1

**FDP_ACC.2.1** The TSF shall enforce the \[assignment: *access control
SFP*\] on \[assignment: *list of subjects and objects*\] **and all
operations among subjects and objects covered by the SFP.**

**FDP_ACC.2.2 The TSF shall ensure that all operations between any
subject in the TSC and any object within the TSC are covered by an
access control SFP.**

Dependencies: FDP_ACF.1 Security attribute based access control

**FDP_ACF.1 Security attribute based access control**

Hierarchical to: No other components.

**FDP_ACF.1.1 The TSF shall enforce the \[assignment: *access control
SFP*\] to objects based on \[assignment: *security attributes*, *named
groups of security attributes*\].**

**FDP_ACF.1.2 The TSF shall enforce the following rules to determine if
an operation among controlled subjects and controlled objects is
allowed: \[assignment: *rules governing access among controlled subjects
and controlled objects using controlled operations on controlled
objects*\].**

**FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to
objects based on the following additional rules: \[assignment: *rules,
based on security attributes, that explicitly authorize access of
subjects to objects*\].**

**FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to
objects based on the \[assignment: *rules, based on security attributes,
that explicitly deny access of subjects to objects*\].**

Dependencies: **FDP_ACC.1 Subset access control**

**FMT_MSA.3 Static attribute initialization**

**FMT_SMR.1 Security roles**

Hierarchical to: No other components.

**FMT_SMR.1.1 The TSF shall maintain the roles \[assignment: *the
authorized identified roles*\].**

**FMT_SMR.1.2 The TSF shall be able to associate users with roles.**

Dependencies: **FIA_UID.1 Timing of identification**

**FMT_SMR.2 Restrictions on security roles**

Hierarchical to: **FMT_SMR.1**

**FMT_SMR.2.1** The TSF shall maintain the roles: \[assignment: *the
authorized identified roles*\].

**FMT_SMR.2.2** The TSF shall be able to associate users with roles.

**FMT_SMR.2.3 The TSF shall ensure that the conditions \[assignment: *a
single user account is not assigned the two different roles associated
with a two-man rule*\] are satisfied.**

Dependencies: **FIA_UID.1 Timing of identification**

Application Note: FDP_ACF.1 may be used to specify that particular
operations require two distinct roles to authorize the action.
FMT_SMR.2.3 can ensure that a user account cannot be assigned to both
roles (as used above). If there is more than one situation requiring
implementation of a two-man rule the combination should be iterated for
each set of roles.

### Controls on RBAC Attributes

**FMT_MSA.1 Management of security attributes**

Hierarchical to: No other components.

**FMT_MSA.1.1 The TSF shall enforce the \[assignment: *access control
SFP, information flow control SFP*\] to restrict the ability to
\[selection: *change_default, query, modify, delete,* \[assignment:
*other operations*\]\] the security attributes \[assignment: *list of
security attributes*\] to \[assignment: *the authorized identified
roles*\].**

Dependencies: **\[FDP_ACC.1 Subset access control or**

**FDP_IFC.1 Subset information flow control\]**

**FMT_SMF.1 Specification of management functions**

**FMT_SMR.1 Security roles**

### Firewall access control

**FDP_IFC.1 Subset information flow control**

Hierarchical to: No other components.

**FDP_IFC.1.1 The TSF shall enforce the \[assignment: *information flow
control SFP*\] on \[assignment: *list of subjects*, *information, and
operations that cause controlled information to flow to and from
controlled subjects covered by the SFP*\].**

Dependencies: **FDP_IFF.1 Simple security attributes**

**FDP_IFC.2 Complete information flow control**

Hierarchical to: FDP_IFC.1

**FDP_IFC.2.1** The TSF shall enforce the \[assignment: *information
flow control SFP*\] on \[assignment: *list of subjects* and
*information*\] and **all operations that cause that information to flow
to and from subjects covered by the SFP.**

**FDP_IFC.2.2 The TSF shall ensure that all operations that cause any
information in the TSC to flow to and from any subject in the TSC are
covered by an information flow control SFP.**

Dependencies: **FDP_IFF.1 Simple security attributes**

**FDP_IFF.1 Simple security attributes**

Hierarchical to: No other components.

**FDP_IFF.1.1 The TSF shall enforce the \[assignment: *information flow
control SFP*\] based on the following types of subject and information
security attributes: \[assignment: *the minimum number and type of
security attributes*\].**

**FDP_IFF.1.2 The TSF shall permit an information flow between a
controlled subject and controlled information via a controlled operation
if the following rules hold: \[assignment: *for each operation, the
security attribute-based relationship that must hold between subject and
information security attributes*\].**

**FDP_IFF.1.3 The TSF shall enforce the \[assignment: *additional
information flow control SFP rules*\].**

**FDP_IFF.1.4 The TSF shall provide the following \[assignment: *list of
additional SFP capabilities*\].**

**FDP_IFF.1.5 The TSF shall explicitly authorize an information flow
based on the following rules: \[assignment: *rules, based on security
attributes, that explicitly authorize information flows*\].**

**FDP_IFF.1.6 The TSF shall explicitly deny an information flow based on
the following rules: \[assignment: *rules, based on security attributes,
that explicitly deny information flows*\].**

Dependencies: **FDP_IFC.1 Subset information flow control**

**FMT_MSA.3 Static attribute initialization**

### Audit events

**FAU_GEN.1 Audit data generation**

Hierarchical to: No other components.

**FAU_GEN.1.1 The TSF shall be able to generate an audit record of the
following auditable events:**

**a) Start-up and shutdown of the audit functions;**

**b) All auditable events for the \[selection: *minimum, basic,
detailed, not specified*\] level of audit; and**

**c) \[assignment: *other specifically defined auditable events*\].**

**FAU_GEN.1.2 The TSF shall record within each audit record at least the
following**

**information:**

**a) Date and time of the event, type of event, subject identity, and
the outcome (success or failure) of the event; and**

**b) For each audit event type, based on the auditable event definitions
of the functional components included in the PP/ST, \[assignment: *other
audit relevant information*\]**

Dependencies: **FPT_STM.1 Reliable time stamps**

**FAU_GEN.2 User identity association**

Hierarchical to: No other components.

**FAU_GEN.2.1 The TSF shall be able to associate each auditable event
with the identity of the user that caused the event.**

Dependencies: **FAU_GEN.1 Audit data generation**

**FIA_UID.1 Timing of identification**

**FMT_MTD.1Management of TSF data**

Hierarchical to: No other components.

**FMT_MTD.1.1 The TSF shall restrict the ability to \[selection:
*change_default, query, modify, delete, clear*, \[assignment: *other
operations*\]\] the \[assignment: *list of TSF data*\] to \[assignment:
*the authorized identified roles*\].**

Dependencies: **FMT_SMF.1 Specification of management functions**

**FMT_SMR.1 Security roles**

**FAU_SEL.1 Selective audit**

Hierarchical to: No other components.

**FAU_SEL.1.1 The TSF shall be able to include or exclude auditable
events from the set of audited events based on the following
attributes:**

**a) \[selection: *object identity, user identity, subject identity,
host identity, event type*\]**

**b) \[assignment: *list of additional attributes that audit selectivity
is based upon*\].**

Dependencies: **FAU_GEN.1 Audit data generation**

**FMT_MTD.1 Management of TSF data**

### Intrusion detection and response

**FAU_ARP.1 Security alarms**

Hierarchical to: No other components.

**FAU_ARP.1.1 The TSF shall take \[assignment: *list of the least
disruptive actions*\] upon detection of a potential security
violation.**

Dependencies: **FAU_SAA.1 Potential violation analysis**

**FAU_SAA.1 Potential violation analysis**

Hierarchical to: No other components.

**FAU_SAA.1.1 The TSF shall be able to apply a set of rules in
monitoring the audited events and based upon these rules indicate a
potential violation of the TSP.**

**FAU_SAA.1.2 The TSF shall enforce the following rules for monitoring
audited events:**

**a) Accumulation or combination of \[assignment: *subset of defined
auditable events*\] known to indicate a potential security violation;**

**b) \[assignment: *any other rules*\].**

Dependencies: **FAU_GEN.1 Audit data generation**

**FAU_SAA.2 Profile based anomaly detection**

Hierarchical to: FAU_SAA.1

**FAU_SAA.2.1 The TSF shall be able to maintain profiles of system
usage, where an individual profile represents the historical patterns of
usage performed by the member(s) of \[assignment: *the profile target
group*\].**

**FAU_SAA.2.2 The TSF shall be able to maintain a suspicion rating
associated with each user whose activity is recorded in a profile, where
the suspicion rating represents the degree to which the user's current
activity is found inconsistent with the established patterns of usage
represented in the profile.**

**FAU_SAA.2.3 The TSF shall be able to indicate an imminent violation of
the TSP when a user's suspicion rating exceeds the following threshold
conditions \[assignment: *conditions under which anomalous activity is
reported by the TSF*\].**

Dependencies: **FIA_UID.1 Timing of identification**

**FAU_SAA.3 Simple attack heuristics**

Hierarchical to: FAU_SAA.1

**FAU_SAA.3.1 The TSF shall be able to maintain an internal
representation of the following signature events \[assignment: *a subset
of system events*\] that may indicate a violation of the TSP.**

**FAU_SAA.3.2 The TSF shall be able to compare the signature events
against the record of system activity discernible from an examination of
\[assignment: *the information to be used to determine system
activity*\].**

**FAU_SAA.3.3 The TSF shall be able to indicate an imminent violation of
the TSP when a system event is found to match a signature event that
indicates a potential violation of the TSP.**

Dependencies: No dependencies

**FAU_SAA.4 Complex attack heuristics**

Hierarchical to: FAU_SAA.3

**FAU_SAA.4.1** The TSF shall be able to maintain an internal
representation of the **following event sequences of known intrusion
scenarios \[assignment: *list of sequences of system events whose
occurrence are representative of known penetration scenarios*\] and**
the following signature events \[assignment: *a subset of system
events*\] that may indicate a potential violation of the TSP.

**FAU_SAA.4.2** The TSF shall be able to compare the signature events
**and event sequences** against the record of system activity
discernible from an examination of \[assignment: *the information to be
used to determine system activity*\].

**FAU_SAA.4.3** The TSF shall be able to indicate an imminent violation
of the TSP when **system activity** is found to match a signature event
**or event sequence** that indicates a potential violation of the TSP.

Dependencies: No dependencies

### Audit trail protection

**FAU_STG.1 Protected audit trail storage**

Hierarchical to: No other components.

**FAU_STG.1.1 The TSF shall protect the stored audit records from
unauthorised deletion.**

**FAU_STG.1.2 The TSF shall be able to \[selection: *prevent, detect*\]
modifications to the audit records.**

Dependencies: **FAU_GEN.1 Audit data generation**

**FAU_STG.2 Guarantees of audit data availability**

Hierarchical to: FAU_STG.1

**FAU_STG.2.1** The TSF shall protect the stored audit records from
unauthorized deletion.

**FAU_STG.2.2** The TSF shall be able to \[selection: *prevent,
detect*\] modifications to the audit records.

**FAU_STG.2.3 The TSF shall ensure that \[assignment: *metric for saving
audit records*\] audit records will be maintained when the following
conditions occur: \[selection: *audit storage exhaustion, failure,
attack*\].**

Dependencies: FAU_GEN.1 Audit data generation

**FAU_STG.3 Action in case of possible audit data loss**

Hierarchical to: No other components.

**FAU_STG.3.1 The TSF shall take \[assignment: *actions to be taken in
case of possible audit storage failure*\] if the audit trail exceeds
\[assignment: *pre-defined limit*\].**

Dependencies: FAU_STG.1 Protected audit trail storage

**FAU_STG.4 Prevention of audit data loss**

Hierarchical to: FAU_STG.3

**FAU_STG.4.1 The TSF shall \[selection: '*ignore auditable events',
'prevent auditable events, except those taken by the authorized user
with special rights', 'overwrite the oldest stored audit records'*\] and
\[assignment: *other actions to be taken in case of audit storage
failure*\] if the audit trail is full.**

Dependencies: FAU_STG.1 Protected audit trail storage

### Audit trail analysis / review

**FAU_SAR.1 Audit review**

120 This component will provide authorized users the capability to
obtain and interpret the information. In case of human users this
information needs to be in a human understandable presentation. In case
of external IT entities the information needs to be unambiguously
represented in an electronic fashion.

Hierarchical to: No other components.

**FAU_SAR.1.1 The TSF shall provide \[assignment: *authorized users*\]
with the capability to read \[assignment: *list of audit information*\]
from the audit records.**

**FAU_SAR.1.2 The TSF shall provide the audit records in a manner
suitable for the user to interpret the information.**

Dependencies: **FAU_GEN.1 Audit data generation**

**FAU_SAR.2 Restricted audit review**

Hierarchical to: No other components.

**FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit
records, except those users that have been granted explicit
read-access.**

Dependencies: **FAU_SAR.1 Audit review**

**FAU_SAR.3 Selectable audit review**

Hierarchical to: No other components.

**FAU_SAR.3.1 The TSF shall provide the ability to perform \[selection:
*searches, sorting, ordering*\] of audit data based on \[assignment:
*criteria with logical relations*\].**

Dependencies: **FAU_SAR.1 Audit review**

### TOE Integrity

**FPT_PHP.1 Passive detection of physical attack**

Hierarchical to: No other components.

**FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical
tampering that might compromise the TSF.**

**FPT_PHP.1.2 The TSF shall provide the capability to determine whether
physical tampering with the TSF's devices or TSF's elements has
occurred.**

Dependencies: **FMT_MOF.1 Management of security functions behavior**

**FPT_PHP.2 Notification of physical attack**

Hierarchical to: FPT_PHP.1

**FPT_PHP.2.1** The TSF shall provide unambiguous detection of physical
tampering that might compromise the TSF.

**FPT_PHP.2.2** The TSF shall provide the capability to determine
whether physical tampering with the TSF's devices or TSF's elements has
occurred.

**FPT_PHP.2.3 For \[assignment: *list of TSF devices/elements for which
active detection is required*\], the TSF shall monitor the devices and
elements and notify \[assignment: *a designated user or role*\] when
physical tampering with the TSF's devices or TSF's elements has
occurred.**

Dependencies: FMT_MOF.1 Management of security functions behavior

**FPT_PHP.3 Resistance to physical attack**

Hierarchical to: No other components.

**FPT_PHP.3.1 The TSF shall resist \[assignment: *physical tampering
scenarios*\] to the \[assignment: *list of TSF devices/elements*\] by
responding automatically such that the TSP is not violated.**

Dependencies: No dependencies

### Data Authentication

**FDP_DAU.2 Data authentication with identity of guarantor**

Hierarchical to: **FDP_DAU.1**

**FDP_DAU.2.1** The TSF shall provide a capability to generate evidence
that can be used as a guarantee of the validity of \[assignment: *list
of objects or information types*\].

**FDP_DAU.2.2** The TSF shall provide \[assignment: *list of subjects*\]
with the ability to verify evidence of the validity of the indicated
information **and the identity of the user that generated the
evidence.**

Dependencies: **FIA_UID.1 Timing of identification**

### Data exchange integrity

**FDP_UIT.1 Data exchange integrity**

Hierarchical to: No other components.

**FDP_UIT.1.1 The TSF shall enforce the \[assignment: *access control
SFP(s) and/or* i*nformation flow control SFP(s)*\] to be able to
\[selection*: transmit, receive*\] user data in a manner protected from
\[selection: *modification, deletion, insertion, replay*\] errors.**

Dependencies: **\[FDP_ACC.1 Subset access control, or**

**FDP_IFC.1 Subset information flow control\]**

**\[FTP_ITC.1 Inter-TSF trusted channel, or**

**FTP_TRP.1 Trusted path\]**

### Functions required to support dependencies

**FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for
its own use.**

Dependencies: No dependencies

**FDP_ACF.1 Security attribute based access control**

Hierarchical to: No other components.

**FDP_ACF.1.1 The TSF shall enforce the \[assignment: *access control
SFP*\] to objects based on \[assignment: *security attributes*, *named
groups of security attributes*\].**

Dependencies: **FDP_ACC.1 Subset access control**

**FMT_MSA.3 Static attribute initialization**

**FMT_MSA.1 Management of security attributes**

Hierarchical to: No other components.

**FMT_MSA.1.1 The TSF shall enforce the \[assignment: *access control
SFP, information flow control SFP*\] to restrict the ability to
\[selection: *change_default, query, modify, delete,* \[assignment:
*other operations*\]\] the security attributes \[assignment: *list of
security attributes*\] to \[assignment: *the authorized identified
roles*\].**

Dependencies: **\[FDP_ACC.1 Subset access control or**

**FDP_IFC.1 Subset information flow control\]**

**FMT_SMF.1 Specification of management functions**

**FMT_SMR.1 Security roles**

**FMT_MSA.3 Static attribute initialization**

Hierarchical to: No other components.

**FMT_MSA.3.1 The TSF shall enforce the \[assignment: *access control
SFP, information flow control SFP*\] to provide \[selection:
*restrictive, permissive, other property*\] default values for security
attributes that are used to enforce the *SFP*.**

**FMT_MSA.3.2 The TSF shall allow the \[assignment: *the authorized
identified roles*\] to specify alternative initial values to override
the default values when an object or information is created.**

Dependencies: **FMT_MSA.1 Management of security attributes**

**FMT_SMR.1 Security roles**

**FDP_IFC.1 Subset information flow control**

Hierarchical to: No other components.

**FDP_IFC.1.1 The TSF shall enforce the \[assignment: *information flow
control SFP*\] on \[assignment: *list of subjects*, *information, and
operations that cause controlled information to flow to and from
controlled subjects covered by the SFP*\].**

Dependencies: **FDP_IFF.1 Simple security attributes**

**FMT_MOF.1Management of security functions behavior**

Hierarchical to: No other components.

**FMT_MOF.1.1 The TSF shall restrict the ability to \[selection:
*determine the behavior of, disable, enable, modify the behavior of*\]
the functions \[assignment: *list of functions*\] to \[assignment: *the
authorized identified roles*\].**

Dependencies: **FMT_SMF.1 Specification of management functions**

**FMT_SMR.1 Security roles**

### 6.1.18 Secure Communications Channels {#secure-communications-channels .unnumbered}

**FPT_ITA.1 Inter-TSF availability within a defined availability
metric**

Hierarchical to: No other components.

**FPT_ITA.1.1 The TSF shall ensure the availability of \[assignment:
*list types of TSF data*\] provided to a remote trusted product within
\[assignment: *a defined availability metric*\] given the following
conditions \[assignment: *conditions to ensure availability*\].**

Dependencies: No dependencies

**FPT_ITC.1 Inter-TSF confidentiality during transition**

Hierarchical to: No other components.

The TSF shall protect all data transmitted from the TSF to a remote
trusted product from unauthorized disclosure during transmission.

Dependencies: No dependencies

FPT_ITI.1 Inter-TSF detection of modification

Hierarchical to: No other components.

FPT_ITI.1.1 The TSF shall provide the capability to detect modification
of all TSF data during transmission between the TSF and a remote trusted
product within the following metric: \[assignment: *a defined
modification metric*\].

FPT_ITI.1.2 The TSF shall provide the capability to verify the integrity
of all TSF data transmitted between the TSF and a remote trusted product
and perform \[assignment: *action to be taken*\] if modifications are
detected.

Dependencies: No dependencies.

FPT_ITI.2 Inter-TSF detection and correction of modification

Hierarchical to: FPT_ITI.1

FPT_ITI.2.3 The TSF shall provide the capability to correct
\[assignment: *type of modification*\] of all TSF data transmitted
between the TSF and a remote trusted product.

Dependencies: No dependencies.

FPT_SSP.1 Simple trusted acknowledgement

Hierarchical to: No other components.

FPT_SSP.1.1 The TSF shall acknowledge, when requested by another part of
the TSF, the receipt of an unmodified TSF data transmission.

Dependencies: FPT_ITT.1 Basic internal TSF data transfer protection

FTP_SSP.2 Mutual trusted acknowledgement

Hierarchical to: FPT_SSP.1

FTP_SSP.2.2 The TSF shall ensure that the relevant parts of the TSF know
the correct status of transmitted data among its different parts, using
acknowledgements.

Dependencies: FPT_ITT.1 Basic internal data transfer protection.

FPT_STM.1 Reliable time stamps

Hierarchical to: No other components.

The TSF shall be able to provide reliable time stamps for the systems
use.

Dependencies: No dependencies.

FPT_TDC.1 Inter-TSF basic data consistency

Hierarchical to: No other components.

FPT_TDC.1.1 The TSF shall provide the capability to consistently
interpret \[assignment: *list of TSF data types*\] when shared between
the TSF and another trusted product.

FPT_TDC.1.2 The TSF shall use \[assignment: *list of interpretation
rules to be applied by the TSF*\] when interpreting the TSF data from
another trusted IT product.

Dependencies: No dependencies.

FTP_ITC.1 Inter-TSF trusted channel

Hierarchical to: No other components.

FTP_ITC.1.1 The TSF shall provide a communication channel between itself
and a remote trusted product that is logically distinct from other
communication channels and provides assured identification of its end
points and protection of the channel data from modification or
disclosure.

FTP_ITC.1.2 The TSF shall permit \[selection: *the TSF, the remote
trusted product*\] to initiate communication via the trusted channel.

FPT_ITC.1.3 The TSF shall initiate communication via trusted channel for
\[assignment: *list of functions for which a trusted channel is
required*\].

Dependencies: No dependencies.

FTP_TRP.1 Trusted path

Hierarchical to: No other components.

FTP_TRP.1.1 The TSF shall provide a communication path between itself
and \[selection: *remote, local*\] users that is logically distinct from
other communications paths and provides assured identification of its
end points and protection of the communicated data from modification or
disclosure.

FPT_TRP.1.2 The TSF shall permit \[selection: *the TSF, local users,
remote users*\] to initiate communications via the trusted path.

FPTTRP.1.3 The TSF shall require the use of the trusted path for
\[selection: *initial user authentication,* \[assignment: *other
services for which trusted path is required*\]\].

Dependencies: No dependencies.

FDP_ETC.1 Export of user data without security attributes

Hierarchical to: No other components.

FDP_EDP.1.1 The TSF shall enforce the \[assignment: *access control
SFP(s) and/or information flow control SFP(s)*\] when exporting user
data, controlled under the SFP(s), outside the TSC.

FDP_ETC.1.2 The TSF shall export the user data without the user data's
associated security attributes.

### 6.1.19 Management Functions {#management-functions .unnumbered}

**FMT_MOF.2 Security policy and security function mapping**

Hierarchical to: No other components.

**FMT_MOF.2.1 The TSF shall be capable of performing the following
security management**

**functions: \[assignment: list of security management functions to be
provided by**

**the TSF\].**

Dependencies**: No Dependencies**

\<Editor Note: The remaining management functions are extensions to ISO
15408, that is, they are not found in the ISO standard\>

FMT_REV.1 Access revocation

Physical and IT access shall be revoked within \[assignment: *time
span*\] for personnel whose employment or contractual relationship is
terminated or for personnel who are temporarily not actively involved in
process control and operations (for example, workers on strike, workers
on a leave of absence, etc.)

FPT_PHP.5 Backup and Restore

The TSF shall include the capability to backup and restore the system
configuration including critical programs, controller instructions and
parameters, and instructions and parameters for all sensors and
actuators. Backups shall be performed \[assignment: frequency\] and
whenever critical operating parameters \[assignment: identify the
critical operating parameters\] are changed.

FPT_PHP.5 Backup and Restore Self-Testing

The TSF backup and restore procedure shall be able to be self-tested
during regular operations and planned maintenance. Self-Test to be
evoked as part of FPT_TST.1.

### 6.1.20 Physical Security Requirements {#physical-security-requirements .unnumbered}

\<Editor Note: These requirements are extensions to ISO 15408, that is,
they are not found in the ISO standard. \>

PHY_SOB.2 Strength of Boundary Access Control

The TSF shall provide physical access control to critical ICS components
including, but not limited to: control room(s), servers, controller,
sensors, actuators, and the physical plant under control. \<Editor Note:
This requirement is included as an example. Physical security
requirements should be inserted in this section as appropriate to the
specific nature of the target ICS. \>

### 6.1.21 Security Event Monitoring {#security-event-monitoring .unnumbered}

\<Editor Note: These requirements are extensions to ISO 15408, that is,
they are not found in the ISO standard. \>

**FEM_EDI.1 Event Definition and Identification provides that an
automated security event monitoring system be used to monitor, manage,
and report pre-defined security events, which includes the type of event
to be monitored, to include: security event identification, name of
interface or component to be monitored, its physical location within the
system, component name and function, any governing policies, and flow
control of alarm reporting. Event definition specifies the system
security event alarm parameter settings, and values for each pre-defined
security event. It additionally identifies the** **System interface and
component that monitors and reports the events, the system component
that receives the event from the interface, processes it, and transmits
the alarm;** **the location that alarm is to be reported, and the
relationship of the event alarm to the system TSF.**

**FEM_EDI.2 Interaction of system event monitoring components defines
the iinteractions of technical and operational and management security
controls components that support event monitoring associated with the
system environment. Also defines the system environment security
controls event monitoring reporting mechanism from either direct or
indirect interface with the System technical security controls
components that support event monitoring. May be used in conjunction
with FPT_PHP.**

**FEM_EDI.3 Alarm audit requirements define the audit requirements for
the defined alarms.**

**FEM_EDI.4 Alarm response identifies that the alarm response to
authorized pre-defined security event monitoring alarms be obtained and
documented; identifies the roles and responsibilities that are defined
for receipt of alarm and required action, including any timing
constraints (possible roles are specified in FMT_SMR.1); defines
security event alarm reporting procedures and mechanisms for the
exchange of security event alarm information between the System IT and
System environment security controls; and specifies that event alarm
audit data be transformed to a specific format to support real-time
analysis, and into a different useful format for delivery to authorised
users for review (see application notes for FAU_SAA)**

FPT_STM.1 Reliable time stamps

**Hierarchical to: No other components.**

The TSF shall be able to provide reliable time stamps for the systems
use.

**Dependencies: No dependencies.**

### 6.1.22 Requirements for interfaces between system components {#requirements-for-interfaces-between-system-components .unnumbered}

\<Editor Note: These requirements are extensions to ISO 15408, that is,
they are not found in the ISO standard. \>

FPT_PHP.2 Authentication Integration

The TSF shall integrate authentication of user access with
authentication for physical access such that user access is not granted
for a user not identified by the physical access control as being
physically present and such that user access is locked when the physical
access control indicates that the user is no longer physically present.

### 6.1.23 Requirements for composability and interoperability between system components {#requirements-for-composability-and-interoperability-between-system-components .unnumbered}

FPT_PHP.4 Domain Definition and Response to Alarm

The TSF shall identify and define the domains, which comprise the
system, the physical boundary for each domain, and the security
policy(s), which governs each of the domains. The system security alarms
may be tailored for the components being governed by the specific
domain. The definition for each alarm shall be well defined, to include
the alarm threshold, where it is reported, and the requisite system
response.

This section documents any requirements specific to security
composability that have not

### 6.1.24 Configuration requirements {#configuration-requirements .unnumbered}

\<Editor Note: These requirements are extensions to ISO 15408, that is,
they are not found in the ISO standard. \>

FCM_IDI.1 Configuration Change Requests and Actions

The STOE shall be subject to configuration management with an explicit
change control and review process.

## STOE Security Assurance Requirements

This section contains the assurance requirements for the TOE. The
assurance requirements are listed in summary form in Table 13 below,
with more detail on the assurance requirements following the Table. The
general intent of the assurance requirements and associated system
evaluation activities is to confirm that the acceptable level of
residual risk as documented in the SPP is achieved in the operational
system

The baseline evaluation assurance level (EAL) for Industrial Control
Systems is EAL 3+. The \"+\" indicates that the EAL is as defined in ISO
15408 Part 3 with additional assurance requirements. In this case the
additional requirements reflect the assurances associated with design,
development, integration, testing and deployment of a system as opposed
to a component or product. In addition, because the ICS is a system, a
combination of technical and operations and management security control
elements must be considered.

Editor Note: Table 13 and the text below it outline extensions to the
assurance requirements that is building on ISO system work in concert
with NIST work on security controls.

[]{#__RefHeading___Toc63689420 .anchor}Table 13 -- STOE Security
Assurance Requirements

+-------+---------------+----------------------------------------------+
| >     |               |                                              |
| **No. |               |                                              |
| >     |               |                                              |
|  Comp |               |                                              |
| onent |               |                                              |
| >     |               |                                              |
|  Comp |               |                                              |
| onent |               |                                              |
| > N   |               |                                              |
| ame** |               |                                              |
+-------+---------------+----------------------------------------------+
| > **  |               |                                              |
| Class |               |                                              |
| >     |               |                                              |
|  ACM: |               |                                              |
| > Con |               |                                              |
| figur |               |                                              |
| ation |               |                                              |
| > ma  |               |                                              |
| nagem |               |                                              |
| ent** |               |                                              |
+-------+---------------+----------------------------------------------+
| > 1   | > ACM_CAP.3   | > Authorization controls                     |
+-------+---------------+----------------------------------------------+
| > 2   | > ACM_SCP.1   | > TOE CM Coverage                            |
+-------+---------------+----------------------------------------------+
| > 3   | > ACM_OBM.1   | > CM Operational Baseline and Maintenance    |
+-------+---------------+----------------------------------------------+
| > **  |               |                                              |
| Class |               |                                              |
| >     |               |                                              |
|  ADO: |               |                                              |
| > Del |               |                                              |
| ivery |               |                                              |
| > and |               |                                              |
| > O   |               |                                              |
| perat |               |                                              |
| ion** |               |                                              |
+-------+---------------+----------------------------------------------+
| > 4   | > ADO_DEL.1   | > Delivery procedures                        |
+-------+---------------+----------------------------------------------+
| > 5   | > ADO_IGS.1   | > Installation, generation and start-up      |
+-------+---------------+----------------------------------------------+
| > 6   | > ADO_SIC.1   | > Site interoperability check                |
+-------+---------------+----------------------------------------------+
| > **  |               |                                              |
| Class |               |                                              |
| >     |               |                                              |
|  AGD: |               |                                              |
| > Gui |               |                                              |
| dance |               |                                              |
| > d   |               |                                              |
| ocume |               |                                              |
| nts** |               |                                              |
+-------+---------------+----------------------------------------------+
| > 7   | > AGD_ADM.1   | > Administrator guidance                     |
+-------+---------------+----------------------------------------------+
| > 8   | > AGD_USR.1   | > User guidance                              |
+-------+---------------+----------------------------------------------+
| > 9   | > AGD_OCD.1   | > System operational configuration           |
|       |               | > definition guidance                        |
+-------+---------------+----------------------------------------------+
| > **  | > **Life      |                                              |
| Class | > cycle       |                                              |
| >     | > support**   |                                              |
| ALC** |               |                                              |
+-------+---------------+----------------------------------------------+
| > 10  | > ALC_DVS.1   | > Identification of security measures        |
+-------+---------------+----------------------------------------------+
| > 11  | > ALC_FLR.3   | > Systematic flaw remediation                |
+-------+---------------+----------------------------------------------+
| > 12  | > ALC_OPS.1   | > Operational security                       |
+-------+---------------+----------------------------------------------+
| > **  | > **Security  |                                              |
| Class | > awareness** |                                              |
| >     |               |                                              |
| ASA** |               |                                              |
+-------+---------------+----------------------------------------------+
| > 13  | > ASA_PPG.2   | > Verified operational security guidance     |
+-------+---------------+----------------------------------------------+
| > **  | > **O&M       |                                              |
| Class | > security    |                                              |
| >     | > controls**  |                                              |
| ASC** | >             |                                              |
|       | > **mainten** |                                              |
+-------+---------------+----------------------------------------------+
| > 14  | > ASC_PPO.1   | > Verified policy and procedures             |
+-------+---------------+----------------------------------------------+
| > 15  | > ASC_PFA.1   | > Asset records confirmation                 |
+-------+---------------+----------------------------------------------+
| > 16  | > ASC_OIN.1   | > Operational integration                    |
+-------+---------------+----------------------------------------------+
| > **  | > **System    |                                              |
| Class | > A           |                                              |
| >     | rchitecture** |                                              |
| ASD** |               |                                              |
+-------+---------------+----------------------------------------------+
| > 17  | > ASD_SAD.1   | > Operational system architecture design     |
+-------+---------------+----------------------------------------------+
| > 18  | > ASD_IFS.1   | > Operational system interface functional    |
|       |               | > specification                              |
+-------+---------------+----------------------------------------------+
| > 19  | > ASD_SSD.2   | > Subsystem design                           |
+-------+---------------+----------------------------------------------+
| > 20  | > ASD_IMP.1   | > Implementation representation              |
+-------+---------------+----------------------------------------------+
| > 21  | > ASD_COM.1   | > System security concept of operations      |
+-------+---------------+----------------------------------------------+
| > **  |               |                                              |
| Class |               |                                              |
| >     |               |                                              |
|  ATE: |               |                                              |
| > Te  |               |                                              |
| sts** |               |                                              |
+-------+---------------+----------------------------------------------+
| > 22  | > ATE_COV.2   | > Analysis of coverage                       |
+-------+---------------+----------------------------------------------+
| > 23  | > ATE_FUN.1   | > Functional testing                         |
+-------+---------------+----------------------------------------------+
| > 24  | > ATE_IND.2   | > Independent testing- sample                |
+-------+---------------+----------------------------------------------+
| > 25  | > ATE_AST.3   | > Operational testing policy conformance     |
+-------+---------------+----------------------------------------------+
| > **  |               |                                              |
| Class |               |                                              |
| >     |               |                                              |
|  AVA: |               |                                              |
| > Vul |               |                                              |
| nerab |               |                                              |
| ility |               |                                              |
| > As  |               |                                              |
| sessm |               |                                              |
| ent** |               |                                              |
+-------+---------------+----------------------------------------------+
| > 26  | > AVA_SOF.1   | > Strength of STOE security function         |
|       |               | > evaluation                                 |
+-------+---------------+----------------------------------------------+
| > 27  | > AVA_MSU.1   | > Examination of guidance                    |
+-------+---------------+----------------------------------------------+
| > 28  | > AVA_VLA.1   | > Developer vulnerability analysis           |
+-------+---------------+----------------------------------------------+
| > **  |               |                                              |
| Class |               |                                              |
| >     |               |                                              |
|  AMA: |               |                                              |
| >     |               |                                              |
|  Assu |               |                                              |
| rance |               |                                              |
| > Mai |               |                                              |
| ntena |               |                                              |
| nce** |               |                                              |
| >     |               |                                              |
| > *   |               |                                              |
| *Assu |               |                                              |
| rance |               |                                              |
| > Mai |               |                                              |
| ntena |               |                                              |
| nce** |               |                                              |
+-------+---------------+----------------------------------------------+
| > 29  | > ASA_AMP.1   | > Assurance maintenance plan                 |
+-------+---------------+----------------------------------------------+
| > 30  | > AMA_EVD.1   | > Evidence of assurance maintenance          |
+-------+---------------+----------------------------------------------+
| > 31  | > AMA_SIA     | > Security impact analysis                   |
+-------+---------------+----------------------------------------------+

### Configuration Management (ACM)

+---------------+------------------------------------------------------+
| #### Auth     |                                                      |
| orization Con |                                                      |
| trols (ACM_CA |                                                      |
| P.3) {#author |                                                      |
| ization-contr |                                                      |
| ols-acm_cap.3 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | ALC_DVS.1 Identification of security measures        |
+---------------+------------------------------------------------------+
| **A           | The developer shall provide a reference for the TOE. |
| CM_CAP.3.1D** |                                                      |
+---------------+------------------------------------------------------+
| **A           | The developer shall use a CM system.                 |
| CM_CAP.3.2D** |                                                      |
+---------------+------------------------------------------------------+
| **A           | The developer shall provide CM documentation.        |
| CM_CAP.3.3D** |                                                      |
+---------------+------------------------------------------------------+
| **A           | The reference for the STOE shall be unique to each   |
| CM_CAP.3.1C** | version of the TOE.                                  |
+---------------+------------------------------------------------------+
| **A           | The STOE shall be labeled with its reference.        |
| CM_CAP.3.2C** |                                                      |
+---------------+------------------------------------------------------+
| **A           | The CM documentation shall include a configuration   |
| CM_CAP.3.3C** | list **and a plan**.                                 |
+---------------+------------------------------------------------------+
| **A           | The configuration list shall describe the            |
| CM_CAP.3.4C** | configuration items that comprise the TOE.           |
+---------------+------------------------------------------------------+
| **A           | The CM documentation shall describe the method used  |
| CM_CAP.3.5C** | to uniquely identify the configuration items.        |
+---------------+------------------------------------------------------+
| **A           | The CM system shall uniquely identify all            |
| CM_CAP.3.6C** | configuration items.                                 |
+---------------+------------------------------------------------------+
| **A           | **The CM Plan shall describe how the CM system is    |
| CM_CAP.3.7C** | used.**                                              |
+---------------+------------------------------------------------------+
| **A           | **The evidence shall demonstrate that the CM system  |
| CM_CAP.3.8C** | is operating in accordance with the CM Plan.**       |
+---------------+------------------------------------------------------+
| **A           | **The CM documentation shall provide evidence that   |
| CM_CAP.3.9C** | all configuration have been and are being            |
|               | effectively maintained under the CM system.**        |
+---------------+------------------------------------------------------+
| **AC          | **The CM system shall provide measures such that     |
| M_CAP.3.10C** | only authorized changes are made to the              |
|               | configuration items.**                               |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| CM_CAP.3.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+

###  {#section-2 .unnumbered}

+---------------+------------------------------------------------------+
| #### STOE     |                                                      |
| CM Coverage ( |                                                      |
| ACM_SCP.1) {# |                                                      |
| stoe-cm-cover |                                                      |
| age-acm_scp.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | ACC_CAP.3 Authorization controls                     |
+---------------+------------------------------------------------------+
| **A           | **The developer shall provide a list of              |
| CM_SCP.1.1D** | configuration items for the TOE.**                   |
+---------------+------------------------------------------------------+
| **A           | **The list of configuration items shall include the  |
| CM_SCP.1.1C** | following: implementation representation and the     |
|               | evaluation evidence required by the assurance        |
|               | components in the ST.**                              |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| CM_SCP.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| ####          |                                                      |
| Operational B |                                                      |
| aseline & Mai |                                                      |
| ntenance (ACM |                                                      |
| _OBM.1) {#ope |                                                      |
| rational-base |                                                      |
| line-maintena |                                                      |
| nce-acm_obm.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | ACM_CAP.3 Authorization controls                     |
|               |                                                      |
|               | ACM_SCP.1 TOE CM coverage                            |
+---------------+------------------------------------------------------+
| **A           | **The developer/system owner shall use a CM system   |
| CM_OBM.1.1D** | for the initial/most recent evaluated system, which  |
|               | shall be called the "Baseline".**                    |
+---------------+------------------------------------------------------+
| **A           | **The CM system shall track and monitor each change, |
| CM_OBM.1.2D** | proposed and actual to the system Baseline, and its  |
|               | evaluation status.**                                 |
+---------------+------------------------------------------------------+
| **A           | **The CM system shall report the current operational |
| CM_OBM.1.3D** | system configuration baseline.**                     |
+---------------+------------------------------------------------------+
| **A           | **The developer/system owner shall provide CM        |
| CM_OBM.1.4D** | documentation of the Baseline system.**              |
+---------------+------------------------------------------------------+
| **A           | **The CM System shall uniquely identify the System   |
| CM_OBM.1.1C** | TOE Baseline, each associated change, and its        |
|               | evaluation status.**                                 |
+---------------+------------------------------------------------------+
| **AC          | **The CM Plan shall describe how the system baseline |
| M_OBM.1.2.C** | is maintained, and changes to the baseline are       |
|               | tracked and controlled.**                            |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| CM_OBM.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+

### Delivery and Operation (ADO)

###  {#section-3 .unnumbered}

+---------------+------------------------------------------------------+
| ###           |                                                      |
| # Delivery Pr |                                                      |
| ocedures (ADO |                                                      |
| _DEL.1) {#del |                                                      |
| ivery-procedu |                                                      |
| res-ado_del.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The developer shall document procedures for        |
| DO_DEL.1.1D** | delivery of the System TOE or parts of it to the     |
|               | user.**                                              |
+---------------+------------------------------------------------------+
| **A           | **The developer shall use the delivery procedures**. |
| DO_DEL.1.2D** |                                                      |
+---------------+------------------------------------------------------+
| **A           | **The delivery documentation** **shall describe all  |
| DO_DEL.1.1C** | procedures that are necessary to maintain security   |
|               | when distributing versions of the System TOE to a    |
|               | user's site**.                                       |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| DO_DEL.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #### Ins      |                                                      |
| tallation, Ge |                                                      |
| neration and  |                                                      |
| Start-up Proc |                                                      |
| edures (ADO_I |                                                      |
| GS.1) {#insta |                                                      |
| llation-gener |                                                      |
| ation-and-sta |                                                      |
| rt-up-procedu |                                                      |
| res-ado_igs.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The developer shall document procedures necessary  |
| DO_IGS.1.1D** | for the secure installation, generation, and         |
|               | start-up of the System TOE.**                        |
+---------------+------------------------------------------------------+
| **A           | **The installation, generation and start-up          |
| DO_IGS.1.1C** | documentation shall describe the steps necessary for |
|               | secure installation, generation, and start-up of the |
|               | System TOE**.                                        |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| DO_IGS.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall determine that the installation, |
| DO_IGS.1.2E** | generation, and start-up procedures result in a      |
|               | secure configuration.                                |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #### S        |                                                      |
| ite Interoper |                                                      |
| ability Check |                                                      |
|  (ADO_SIC.1)  |                                                      |
| {#site-intero |                                                      |
| perability-ch |                                                      |
| eck-ado_sic.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The developer shall document procedures necessary  |
| DO_SIC.1.1D** | to ensure that components and interfaces that        |
|               | comprise the System TOE, especially those to legacy  |
|               | security controls and interfaces can be started up   |
|               | and interoperate in a secure manner.**               |
+---------------+------------------------------------------------------+
| **A           | **The site interoperability check procedures         |
| DO_SIC.1.1C** | documentation shall describe the steps necessary for |
|               | verification of secure start-up and interoperation   |
|               | of the System TOE in its environment**.              |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| DO_SIC.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall determine that the start-up and  |
| DO_SIC.1.2E** | interoperability check procedures result in a secure |
|               | configuration.                                       |
+---------------+------------------------------------------------------+

### Guidance Documents (AGD)

+---------------+------------------------------------------------------+
| #### Admi     |                                                      |
| nistrator Gui |                                                      |
| dance (AGD_AD |                                                      |
| M.1) {#admini |                                                      |
| strator-guida |                                                      |
| nce-agd_adm.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | ASD_SAD.1 Operational System Architecture Design     |
+---------------+------------------------------------------------------+
| **A           | **The developer shall provide administrator guidance |
| GD_ADM.1.1D** | addressed to system administrative personnel.**      |
+---------------+------------------------------------------------------+
| **A           | **The administrator guidance shall describe the      |
| GD_ADM.1.1C** | administrative functions and interfaces available to |
|               | the administrator of the System TOE.**               |
+---------------+------------------------------------------------------+
| **A           | **The administrator guidance shall describe how to   |
| GD_ADM.1.2C** | administer the System TOE in a secure manner.**      |
+---------------+------------------------------------------------------+
| **A           | **The administrator guidance shall contain warnings  |
| GC_ADM.1.3C** | about functions and privileges that should be        |
|               | controlled in a secure processing environment.**     |
+---------------+------------------------------------------------------+
| **A           | **The administrator guidance shall describe all      |
| GC_ADM.1.4C** | assumptions regarding user behavior that are         |
|               | relevant to secure operation of the TOE.**           |
+---------------+------------------------------------------------------+
| **A           | **The administrator guidance shall describe all      |
| GC_ADM.1.5C** | security parameters under the control of the         |
|               | administrator, indicating secure values, as          |
|               | appropriate.**                                       |
+---------------+------------------------------------------------------+
| **A           | **The administrator guidance shall describe each     |
| GC_ADM.1.6C** | type of security-relevant event relative to the      |
|               | administrative functions that need to be performed,  |
|               | including changing the security characteristics of   |
|               | entities under the control of the TSF.**             |
+---------------+------------------------------------------------------+
| **A           | **The administrator guidance shall be consistent     |
| GC_ADM.1.7C** | with all other documentation supplied for            |
|               | evaluation.**                                        |
+---------------+------------------------------------------------------+
| **A           | **The administrator guidance shall describe all      |
| GC_ADM.1.8C** | security requirements for the IT environment that    |
|               | are relevant to the administrator.**                 |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| GD_ADM.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| ####          |                                                      |
|  User Guidanc |                                                      |
| e (AGD_USR.1) |                                                      |
|  {#user-guida |                                                      |
| nce-agd_usr.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | ASD_SAD.1 Operational System Architecture Design     |
+---------------+------------------------------------------------------+
| **A           | **The developer shall provide user guidance.**       |
| GD_USR.1.1D** |                                                      |
+---------------+------------------------------------------------------+
| **A           | **The user guidance shall describe the functions and |
| GD_USR.1.1C** | interfaces available to the non-administrator users  |
|               | of the System TOE.**                                 |
+---------------+------------------------------------------------------+
| **A           | **The user guidance shall describe the use of        |
| GD_USR.1.2C** | user-accessible security functions provided by the   |
|               | System TOE.**                                        |
+---------------+------------------------------------------------------+
| **A           | **The user guidance shall contain warnings about     |
| GD_USR.1.3C** | user-accessible functions and privileges that should |
|               | be controlled in a secure processing environment.**  |
+---------------+------------------------------------------------------+
| **A           | **The user guidance shall clearly present all user   |
| GD_USR.1.4C** | responsibilities necessary for secure operation of   |
|               | the TOE, including those related to assumptions      |
|               | regarding user behavior found in the statement of    |
|               | the TOE security environment.**                      |
+---------------+------------------------------------------------------+
| **A           | **The user guidance shall be consistent with all     |
| GD_USR.1.5C** | other documentation supplied for evaluation.**       |
+---------------+------------------------------------------------------+
| **A           | **The user guidance shall describe all security      |
| GD_USR.1.6C** | requirements for the IT environment that are         |
|               | relevant to the user.**                              |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| GD_USR.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| ####          |                                                      |
|  System Opera |                                                      |
| tional Config |                                                      |
| uration Defin |                                                      |
| ition Guidanc |                                                      |
| e (AGD_OCD.1) |                                                      |
|  {#system-ope |                                                      |
| rational-conf |                                                      |
| iguration-def |                                                      |
| inition-guida |                                                      |
| nce-agd_ocd.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | ASD_SAD.1 Operational System Architecture Design     |
|               |                                                      |
|               | ASD_COM.1 Operational System Security Concept of     |
|               | Operations                                           |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator/system owner shall        |
| GD_OCD.1.1D** | provide configuration guidance that defines the      |
|               | security relevant configuration parameters that      |
|               | support the integration of the system components and |
|               | that allow the system security functions to          |
|               | implement and enforce the system security concept of |
|               | operations and associated policies.**                |
+---------------+------------------------------------------------------+
| **A           | **The configuration guidance shall describe the      |
| GD_OCD.1.1C** | security configuration parameters available to the   |
|               | system integrator or equivalent users/administrator  |
|               | of the System TOE with that role and                 |
|               | responsibility.**                                    |
+---------------+------------------------------------------------------+
| **A           | **The configuration guidance shall describe the use  |
| GD_OCD.1.2C** | of security parameters configurable by the TOE to    |
|               | implement and enforce the system security            |
|               | policies.**                                          |
+---------------+------------------------------------------------------+
| **A           | **The configuration guidance shall contain warnings  |
| GD_OCD.1.3C** | about configuration accessible functions and         |
|               | privileges that should be controlled in a secure     |
|               | processing environment.**                            |
+---------------+------------------------------------------------------+
| **A           | **The configuration guidance shall clearly present   |
| GD_OCD.1.4C** | all configuration related responsibilities necessary |
|               | for secure operation of the TOE.**                   |
+---------------+------------------------------------------------------+
| **A           | **The user guidance shall be consistent with all     |
| GD_OCD.1.5C** | other documentation supplied for evaluation.**       |
+---------------+------------------------------------------------------+
| **A           | **The configuration guidance shall describe all      |
| GD_OCD.1.6C** | security requirements relative to the System         |
|               | environment.**                                       |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| GD_OCD.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+

### Life Cycle Support (ALC)

+---------------+------------------------------------------------------+
| #### Iden     |                                                      |
| tification of |                                                      |
|  Security Mea |                                                      |
| sures (ALC_DV |                                                      |
| S.1) {#identi |                                                      |
| fication-of-s |                                                      |
| ecurity-measu |                                                      |
| res-alc_dvs.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The developer shall produce development security   |
| LC_DVS.1.1D** | documentation.**                                     |
+---------------+------------------------------------------------------+
| **A           | **The development security documentation shall       |
| LC_DVS.1.1C** | describe all the physical, procedural, personnel,    |
|               | and other security measures that are necessary to    |
|               | protect the confidentiality and integrity of the TOE |
|               | design and implementation in its development         |
|               | environment.**                                       |
+---------------+------------------------------------------------------+
| **A           | **The development security documentation shall       |
| LC_DVS.1.2C** | provide evidence that these security measures are    |
|               | followed during the development and maintenance of   |
|               | the TOE.**                                           |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall confirm that the information   |
| LC_DVS.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.**                          |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall confirm tha the security       |
| LC_DVS.1.2E** | measures are being applied.**                        |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #### S        |                                                      |
| ystematic Fla |                                                      |
| w Remediation |                                                      |
|  (ALC_FLR.3)  |                                                      |
| {#systematic- |                                                      |
| flaw-remediat |                                                      |
| ion-alc_flr.3 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | The developer shall provide flaw remediation         |
| LC_FLR.3.1D** | procedures addressed to TOE developers.              |
+---------------+------------------------------------------------------+
| **A           | The developer shall establish a a procedure for      |
| LC_FLR.3.2D** | accepting and acting upon all reports of security    |
|               | flaws and requests for corrections to those flaws.   |
+---------------+------------------------------------------------------+
| **A           | The developer shall provide remediation guidance     |
| LC_FLR.3.3D** | addressed to TOE users.                              |
+---------------+------------------------------------------------------+
| **A           | The flaw remediation procedures documentation shall  |
| LC_FLR.3.1C** | describe the procedures used to track all reported   |
|               | security flaws in each release of the TOE.           |
+---------------+------------------------------------------------------+
| **A           | The flaw remediation procedures shall require that a |
| LC_FLR.3.2C** | description of the nature and effect of each         |
|               | security flaw be provided, as well as the status of  |
|               | finding a correction to that flaw.                   |
+---------------+------------------------------------------------------+
| **A           | The flaw remediation procedures shall require that   |
| LC_FLR.3.3C** | corrective actions be identified for each of the     |
|               | security flaws.                                      |
+---------------+------------------------------------------------------+
| **A           | The flaw remediation procedures documentation shall  |
| LC_FLR.3.4C** | describe the methods used to provide flaw            |
|               | information, corrections and guidance on corrective  |
|               | actions to TOE users.                                |
+---------------+------------------------------------------------------+
| **A           | The flaw remediation procedures documentation shall  |
| LC_FLR.3.5C** | describe a means by which the developer receives     |
|               | from TOE users reports and enquiries of suspected    |
|               | security flaws in the TOE.                           |
+---------------+------------------------------------------------------+
| **A           | The procedures for processing reported security      |
| LC_FLR.3.6C** | flaws shall ensure that any reported flaws are       |
|               | corrected and the correction issued to TOE users.    |
+---------------+------------------------------------------------------+
| **A           | The procedures for processing reported security      |
| LC_FLR.3.7C** | flaws shall provide safeguards that any correction   |
|               | to these security flaws do not introduce any new     |
|               | flaws.                                               |
+---------------+------------------------------------------------------+
| **A           | The flaw remediation guidance shall describe a means |
| LC_FLR.3.8C** | by which TOE users report to the developer any       |
|               | suspected security flaws in the TOE.                 |
+---------------+------------------------------------------------------+
| **A           | **The flaw remediation procedures shall include a    |
| LC_FLR.3.9C** | procedure requiring timely responses for the         |
|               | automatic distribution of security flaw reports and  |
|               | the associated corrections to registered users who   |
|               | might be affected by the security flaw.**            |
+---------------+------------------------------------------------------+
| **AL          | **The flaw remediation guidance shall describe a     |
| C_FLR.3.10C** | means by which TOE users may register with the       |
|               | developer, to be eligible to receive security        |
|               | reports and corrections.**                           |
+---------------+------------------------------------------------------+
| **AL          | **The flaw remediation guidance shall identify the   |
| C_FLR.3.11C** | specific points of contact for all reports and       |
|               | enquiries about security issues involving the TOE.** |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| LC_FLR.3.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #### Ade      |                                                      |
| quacy of Oper |                                                      |
| ational Secur |                                                      |
| ity Measures  |                                                      |
| (ALC_OPS.2) { |                                                      |
| #adequacy-of- |                                                      |
| operational-s |                                                      |
| ecurity-measu |                                                      |
| res-alc_ops.2 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | ASD_COM.1 Operational System Security Concept of     |
|               | Operations                                           |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator/system owner shall        |
| LC_OPS.2.1D** | produce operations security documentation.**         |
+---------------+------------------------------------------------------+
| **A           | **The operations security documentation shall        |
| LC_OPS.2.1C** | describe all the physical, procedural, personnel,    |
|               | and other security controls measures that are        |
|               | required to protect the integrity of the System TOE  |
|               | implementation in its operational environment.**     |
+---------------+------------------------------------------------------+
| **            | **The operations security documentation shall        |
| ALC_OPS2.2C** | provide evidence that these security control         |
|               | measures are in place, followed, and enforced during |
|               | the operations and maintenance of the System TOE.**  |
+---------------+------------------------------------------------------+
| **A           | **The evidence shall provide support that the        |
| LC_OPS.2.3C** | security control measures, as implemented, provide   |
|               | the required level of protection to maintain         |
|               | effective security of the System TOE.**              |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| LC_OPS.2.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the security        |
| LC_OPS.2.2E** | controls measures are being applied.                 |
+---------------+------------------------------------------------------+

###  {#section-4 .unnumbered}

### Security Awareness (ASA)

+---------------+------------------------------------------------------+
| ##            |                                                      |
| ## Verified O |                                                      |
| perational Se |                                                      |
| curity Guidan |                                                      |
| ce (ASA_PPG.2 |                                                      |
| ) {#verified- |                                                      |
| operational-s |                                                      |
| ecurity-guida |                                                      |
| nce-asa_ppg.2 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The system owner/management shall provide security |
| SA_PPG.2.1D** | policy**                                             |
|               |                                                      |
|               | **and procedure guidance addressed to \[selection:   |
|               | \[assignment:**                                      |
|               |                                                      |
|               | ***appropriate personnel definition*\], *all*\]      |
|               | personnel.**                                         |
+---------------+------------------------------------------------------+
| **A           | **The security policy and procedure guidance shall   |
| SA_PPG.2.1C** | describe the security policies applicable to the     |
|               | system for the target personnel**                    |
+---------------+------------------------------------------------------+
| **A           | **The security policy and procedure guidance shall   |
| SA_PPG.2.2C** | describe how personnel can obtain the full contents  |
|               | of the security policies applicable to the system    |
|               | for the target personnel**                           |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| SA_PPG.2.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall independently verify through   |
| SA_PPG.2.2E** | \[selection: *personnel interviews, sampling the     |
|               | procedures in the security policy and procedure      |
|               | guidance*, \[assignment: *other methods*\]\] the     |
|               | veracity of the contents of the security policy and  |
|               | procedures guidance.**                               |
+---------------+------------------------------------------------------+

### System O&M Security Controls (ASC)

+---------------+------------------------------------------------------+
| #### Security |                                                      |
|  Policy, Proc |                                                      |
| edures and Or |                                                      |
| ganization (A |                                                      |
| SC_PPO.1) {#s |                                                      |
| ecurity-polic |                                                      |
| y-procedures- |                                                      |
| and-organizat |                                                      |
| ion-asc_ppo.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The system owner shall provide operational         |
| SC_PPO.1.1D** | security**                                           |
|               |                                                      |
|               | **documentation.**                                   |
+---------------+------------------------------------------------------+
| **A           | **The security controls documentation shall describe |
| SC_PPO.1.1C** | all the policy, procedural, personnel, and related   |
|               | organisational security controls measures that are   |
|               | necessary to protect the confidentiality and         |
|               | integrity of the operations and maintenance of the   |
|               | System TOE in its operational environment.**         |
+---------------+------------------------------------------------------+
| **A           | **The operations security documentation shall        |
| SC_PPO.1.2C** | provide evidence that these security controls        |
|               | measures are followed during the operation and       |
|               | maintenance of the System TOE.**                     |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| SC_PPO.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall confirm that the security      |
| SC_PPO.1.2E** | controls are being applied.**                        |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #### Phys     |                                                      |
| ical, Facilit |                                                      |
| y and Assets  |                                                      |
| (ASC_PFA.1) { |                                                      |
| #physical-fac |                                                      |
| ility-and-ass |                                                      |
| ets-asc_pfa.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The developer/system owner/integrator shall        |
| SC_PFA.1.1D** | provide**                                            |
|               |                                                      |
|               | **documentation for the physical, facility, and      |
|               | assets that**                                        |
|               |                                                      |
|               | **comprise the System security controls.**           |
+---------------+------------------------------------------------------+
| **A           | **The security controls documentation shall describe |
| SC_PFA.1.1C** | all the physical, facility and assets related        |
|               | security controls measures that are necessary to     |
|               | protect the confidentiality and integrity of the     |
|               | operations and maintenance of the System TOE in its  |
|               | operational environment.**                           |
+---------------+------------------------------------------------------+
| **A           | **The operations security documentation shall        |
| SC_PFA.1.2C** | provide evidence that these physical security        |
|               | controls measures are followed during the operation  |
|               | and maintenance of the System TOE.**                 |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| SC_PFA.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall confirm that the physical      |
| SC_PFA.1.2E** | security controls are being applied effectively.**   |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #### Operat   |                                                      |
| ional Integra |                                                      |
| tion (ASC_OIN |                                                      |
| .1) {#operati |                                                      |
| onal-integrat |                                                      |
| ion-asc_oin.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The developer/system owner/integrator shall        |
| SC_OIN.1.1D** | provide operational**                                |
|               |                                                      |
|               | **security documentation.**                          |
+---------------+------------------------------------------------------+
| **A           | **The operational system security documentation      |
| SC_OIN.1.1C** | shall describe the integrated system security        |
|               | controls; to include IT and physical, policy,        |
|               | procedural, personnel, and other system security     |
|               | measures that are necessary to protect the           |
|               | confidentiality and integrity of the operations and  |
|               | maintenance of the System TOE in its operational     |
|               | environment.**                                       |
+---------------+------------------------------------------------------+
| **A           | **The operations security documentation shall        |
| SC_OIN.1.2C** | provide evidence that the integrated security        |
|               | control measures are followed as part of the         |
|               | operations and maintenance of the System TOE.**      |
+---------------+------------------------------------------------------+
| **A           | **The evidence shall justify the integrated security |
| SC_OIN.1.3C** | measures provide the necessary level of protection   |
|               | to maintain the confidentiality and integrity of the |
|               | System TOE.**                                        |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| SC_OIN.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall confirm that the integrated    |
| SC_OIN.1.2E** | system security measures are being applied.**        |
+---------------+------------------------------------------------------+

### System Architecture (Class ASD)

+---------------+------------------------------------------------------+
| ##            |                                                      |
| ## Operationa |                                                      |
| l System Arch |                                                      |
| itecture Desi |                                                      |
| gn (ASD_SAD.1 |                                                      |
| ) {#operation |                                                      |
| al-system-arc |                                                      |
| hitecture-des |                                                      |
| ign-asd_sad.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator shall provide an          |
| SD_SAD.1.1D** | architecture description.**                          |
+---------------+------------------------------------------------------+
| **A           | **The architecture description shall identify the    |
| SD_SAD.1.1C** | system in terms of its subsystems and critical       |
|               | components and the interfaces and interconnects      |
|               | between the subsystems and critical components.**    |
+---------------+------------------------------------------------------+
| **A           | **The architecture description shall identify the    |
| SD_SAD.1.2C** | super-systems that interact with the system and the  |
|               | interfaces and interconnects between the system and  |
|               | the super-systems.**                                 |
+---------------+------------------------------------------------------+
| **A           | **The architecture description shall describe the    |
| SD_SAD.1.3C** | purpose of the identified subsystems, critical       |
|               | components, interconnects and interfaces of the      |
|               | system.**                                            |
+---------------+------------------------------------------------------+
| **A           | **The architecture description shall describe the    |
| SD_SAD.1.4C** | purpose of the identified interconnects and          |
|               | interfaces from the system to super-systems and      |
|               | shall describe the services from and provided to the |
|               | super-systems.**                                     |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| SD_SAD.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall determine that the             |
| SD_SAD.1.2E** | architecture description is consistent with the      |
|               | interface functional specification.**                |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #### O        |                                                      |
| perational Sy |                                                      |
| stem Interfac |                                                      |
| e Functional  |                                                      |
| Specification |                                                      |
|  (ASD_IFS.1)  |                                                      |
| {#operational |                                                      |
| -system-inter |                                                      |
| face-function |                                                      |
| al-specificat |                                                      |
| ion-asd_ifs.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator shall provide an          |
| SD_IFS.1.1D** | interface functional specification.**                |
+---------------+------------------------------------------------------+
| **A           | **The interface functional specification shall       |
| SD_IFS.1.1C** | describe the operational system security             |
|               | functions.**                                         |
+---------------+------------------------------------------------------+
| **A           | **The interfaces functional specification shall be   |
| SD_IFS.1.2C** | internally consistent.**                             |
+---------------+------------------------------------------------------+
| **A           | **The interface functional specification shall       |
| SD_IFS.1.3C** | identify and describe all the external system        |
|               | security function interfaces, including the          |
|               | behaviour of those interfaces.**                     |
+---------------+------------------------------------------------------+
| **A           | **The interface functional specification shall cover |
| SD_IFS.1.4C** | all the system security functions.**                 |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| SD_IFS.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall determine whether the          |
| SD_IFS.1.2E** | interface functional specification is a complete     |
|               | instantiation of the system security functional      |
|               | requirements.**                                      |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #### S        |                                                      |
| ubsystem Desi |                                                      |
| gn Allocation |                                                      |
|  (ASD_SSD.2)  |                                                      |
| {#subsystem-d |                                                      |
| esign-allocat |                                                      |
| ion-asd_ssd.2 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | ASD_SSD.1 Subsystem design.                          |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator shall provide a subsystem |
| SD_SSD.2.1D** | design.**                                            |
+---------------+------------------------------------------------------+
| **A           | **The subsystem design shall be internally           |
| SD_SSD.2.1C** | consistent.**                                        |
+---------------+------------------------------------------------------+
| **A           | **The subsystem design shall allocate the portion of |
| SD_SSD.2.2C** | the SSF to each represented subsystem in terms of    |
|               | minor and major subsystems.**                        |
+---------------+------------------------------------------------------+
| **A           | **The subsystem design shall describe the security   |
| SD_SSD.2.3C** | functionality provided by each subsystem.**          |
+---------------+------------------------------------------------------+
| **A           | **The subsystem design shall identify all hardware,  |
| SD_SSD.2.4C** | firmware, and software required by the SSF allocated |
|               | to the subsystem.**                                  |
+---------------+------------------------------------------------------+
| **A           | **The subsystem design shall allocate the portion of |
| SD_SSD.2.5C** | the SSF to each represented subsystem in terms of    |
|               | minor and major subsystems.**                        |
+---------------+------------------------------------------------------+
| **A           | **The subsystem design shall identify the interfaces |
| SD_SSD.2.6C** | to the subsystem security functions**.               |
+---------------+------------------------------------------------------+
| **A           | **The subsystem design shall describe the interfaces |
| SD_SSD.2.7C** | to each subsystem, in terms of their purpose and     |
|               | method of use of the effects, exceptions and error   |
|               | messages.**                                          |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| SD_SSD.2.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall determine whether the          |
| SD_SSD.2.2E** | subsystem design is a complete instantiation of the  |
|               | operational system security functional               |
|               | requirements.**                                      |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #### Imple    |                                                      |
| mentation Rep |                                                      |
| resentation ( |                                                      |
| ASD_IMP.1) {# |                                                      |
| implementatio |                                                      |
| n-representat |                                                      |
| ion-asd_imp.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies..                                    |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator shall provide an          |
| SD_IMP.1.1D** | implementation representation of the system          |
|               | design.**                                            |
+---------------+------------------------------------------------------+
| **A           | **The implementation representation shall be         |
| SD_IMP.1.1C** | internally consistent.**                             |
+---------------+------------------------------------------------------+
| **A           | **The implementation representation identify the     |
| SD_IMP.1.2C** | system functionality, and the system components that |
|               | when integrated provide that functionality to the    |
|               | operational system.**                                |
+---------------+------------------------------------------------------+
| **A           | **The implementation representation shall describe   |
| SD_IMP.1.3C** | the security functionality provided by the           |
|               | integration of each component in terms of its        |
|               | specific configuration requirements.**               |
+---------------+------------------------------------------------------+
| **A           | **The implementation representation shall identify   |
| SD_IMP.1.4C** | any hardware, firmware, and software integration and |
|               | configuration issues, as identified, prior to, or    |
|               | during the operational system evaluation, that will  |
|               | need to be revisited.**                              |
+---------------+------------------------------------------------------+
| **A           | **The implementation representation shall identify   |
| SD_IMP.1.5C** | the integrated components and their required         |
|               | configuration to the system security functions**.    |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| SD_IMP.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall determine whether the          |
| SD_IMP.1.2E** | implementation representation is a complete          |
|               | instantiation of the integrated operational system   |
|               | security functional requirements.**                  |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #### Operat   |                                                      |
| ional System  |                                                      |
| Security Conc |                                                      |
| ept of Operat |                                                      |
| ions (ASD_COM |                                                      |
| .1) {#operati |                                                      |
| onal-system-s |                                                      |
| ecurity-conce |                                                      |
| pt-of-operati |                                                      |
| ons-asd_com.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The system owner/management shall provide a system |
| SD_COM.1.1D** | operations policy documents.**                       |
+---------------+------------------------------------------------------+
| **A           | **The system owner/integrator shall incorporate      |
| SD_COM.1.2D** | system policy enforcement requirements and           |
|               | capabilities into the policy documents provided by   |
|               | the system management, and provide the system        |
|               | operations policy documents with the system          |
|               | enforcement capabilities, and their bounds.**        |
+---------------+------------------------------------------------------+
| **A           | **The system concept of operations and enforcement   |
| SD_COM.1.1C** | documents subsystem shall be internally              |
|               | consistent.**                                        |
+---------------+------------------------------------------------------+
| **A           | **The operational system operations policy documents |
| SD_COM.1.2C** | shall identify the system capabilities for           |
|               | enforcement of information flow across the           |
|               | operational system interconnects within the          |
|               | operational system boundaries.**                     |
+---------------+------------------------------------------------------+
| **A           | **The operational system operations policy documents |
| SD_COM.1.3C** | shall identify the system capabilities for           |
|               | enforcement of information flow across the           |
|               | operational system interconnects to external         |
|               | operational systems.**                               |
+---------------+------------------------------------------------------+
| **A           | **The operational system operations policy documents |
| SD_COM.1.4C** | shall identify the system capabilities for           |
|               | enforcement of local and remote access to the        |
|               | operational system.**                                |
+---------------+------------------------------------------------------+
| **A           | **The operational system operations policy documents |
| SD_COM.1.5C** | shall identify the system capabilities for           |
|               | enforcement of access to operational system          |
|               | resources based upon access mediation rules.**       |
+---------------+------------------------------------------------------+
| **A           | **The operational system operations policy documents |
| SD_COM.1.6C** | shall identify the modes of operation provided by    |
|               | the system, and the enforcement mechanisms to        |
|               | provide secure operations in each of the identified  |
|               | system modes of operation.**                         |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| SD_SSD.2.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall determine whether the system   |
| SD_SSD.2.2E** | design is a complete instantiation of the            |
|               | operational system security concept of operations in |
|               | support of the operational mission.**                |
+---------------+------------------------------------------------------+

### Tests (ATE)

+---------------+------------------------------------------------------+
| ###           |                                                      |
| # System Secu |                                                      |
| rity Controls |                                                      |
|  Testing (ATE |                                                      |
| _AST.3) {#sys |                                                      |
| tem-security- |                                                      |
| controls-test |                                                      |
| ing-ate_ast.3 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | AGD_OCD.1 System operational configuration           |
|               | definition.                                          |
|               |                                                      |
|               | AGD_USR.1                                            |
|               |                                                      |
|               | ASD_IFS.1 System interface functional definition     |
|               |                                                      |
|               | ASD_IMP.1 Implementation representation              |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator shall provide evidence of |
| TE_AST.3.1D** | test verification planning.**                        |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator shall provide an analysis |
| TE_AST.3.2D** | of level of detail of integrated security controls   |
|               | testing.**                                           |
+---------------+------------------------------------------------------+
| **A           | **The developer shall provide test documentation and |
| TE_AST.3.3D** | the the System TOE for testing.**                    |
+---------------+------------------------------------------------------+
| **A           | **The analysis of the security controls verification |
| TE_AST.3.1C** | shall demonstrate that the correspondence between    |
|               | the security controls as identified in the SST and   |
|               | the tests identified in the test documentation is    |
|               | complete.**                                          |
+---------------+------------------------------------------------------+
| **A           | **The level of detail analysis shall show that the   |
| TE_AST.3.2C** | integrated security controls tests identified in the |
|               | test documentation are able to sufficiently          |
|               | demonstrate that the system security controls        |
|               | integrated into the System TSF operates in           |
|               | accordance with its high level design.**             |
+---------------+------------------------------------------------------+
| **A           | **The level of detail analysis shall show that the   |
| TE_AST.3.3C** | integrated security controls tests identified in the |
|               | test documentation are able to sufficiently          |
|               | demonstrate that the system security controls        |
|               | integrated into the System TSF; and are a correct    |
|               | implementation.**                                    |
+---------------+------------------------------------------------------+
| **A           | **The System TOE shall be suitable for testing.**    |
| TE_AST.3.4C** |                                                      |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| TE_AST.3.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | **The evaluator shall test a subset of the system    |
| TE_AST.3.2E** | TSF to confirm that the system TOE operates as       |
|               | specified in its intended operational environment.** |
+---------------+------------------------------------------------------+

+---------------+------------------------------------------------------+
| #             |                                                      |
| ### Functiona |                                                      |
| l Testing (AT |                                                      |
| E_FUN.1) {#fu |                                                      |
| nctional-test |                                                      |
| ing-ate_fun.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator shall test the TSF and    |
| TE_FUN.1.1D** | documents the results.**                             |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator shall provide test        |
| TE_FUN.1.2D** | documentation.**                                     |
+---------------+------------------------------------------------------+
| **A           | **The test documentation shall consist of test       |
| TE_FUN.1.1C** | plans, test procedure descriptions, expected test    |
|               | results and actual test results.**                   |
+---------------+------------------------------------------------------+
| **A           | **The test plans shall identify the security         |
| TE_FUN.1.2C** | functions to be tested and describe the goal of the  |
|               | tests to be performed.**                             |
+---------------+------------------------------------------------------+
| **A           | **The test procedure descriptions shall identify the |
| TE_FUN.1.3C** | tests to be performed and describe the scenarios for |
|               | testing each security function. These scenarios      |
|               | shall include any ordering dependencies on the       |
|               | results of other tests.**                            |
+---------------+------------------------------------------------------+
| **A           | **The expected test results shall show the           |
| TE_FUN.1.4C** | anticipated outputs from a successful execution of   |
|               | the tests.**                                         |
+---------------+------------------------------------------------------+
| **A           | **The test results from the developer/integrator     |
| TE_FUN.1.5C** | execution of the tests shall demonstrate that each   |
|               | test security function behaved as specified.**       |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| TE_FUN.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+

### Vulnerability Assessment (AVA)

### Assurance Maintenance (AMA)

+---------------+------------------------------------------------------+
| #### As       |                                                      |
| surance Maint |                                                      |
| enance (AMA_A |                                                      |
| MP.1) {#assur |                                                      |
| ance-maintena |                                                      |
| nce-ama_amp.1 |                                                      |
|  .unnumbered} |                                                      |
+---------------+------------------------------------------------------+
| Dependencies: | No dependencies.                                     |
+---------------+------------------------------------------------------+
| **A           | **The developer/integrator shall provide an AM       |
| MA_AMP.1.1D** | Plan.**                                              |
+---------------+------------------------------------------------------+
| **A           | **The AM Plan shall contain or reference a brief     |
| MA_AMP.1.1C** | description of the TOE including the security        |
|               | functionality it provides.**                         |
+---------------+------------------------------------------------------+
| **A           | **The AM Plan shall identify the certified version   |
| MA_AMP.1.2C** | of the system TOE, and shall reference the           |
|               | evaluation results..**                               |
+---------------+------------------------------------------------------+
| **A           | **The AM Plan shall reference the TOE component      |
| MA_AMP.1.3C** | categorization report for the certified version of   |
|               | the TOE.**                                           |
+---------------+------------------------------------------------------+
| **A           | **The AM Plan shall define the scope of changes to   |
| MA_AMP.1.4C** | the STOE that are covered by the plan.**             |
+---------------+------------------------------------------------------+
| **A           | **The AM Plan shall describe the TOE life-cycle, and |
| MA_AMP.1.5C** | shall identify the current plans for any new         |
|               | releases of the TOE, together with a brief           |
|               | description of any planned changes that are likely   |
|               | to have a significant security impact.**             |
+---------------+------------------------------------------------------+
| **A           | **The AM Plan shall describe the assurance           |
| MA_AMP.1.6C** | maintenance cycle, stating and justifying the        |
|               | planned schedule of AM audits and the target date of |
|               | the next re-evaluation of the TOE.**                 |
+---------------+------------------------------------------------------+
| **A           | **The AM Plan shall identify the individual(s) who   |
| MA_AMP.1.7C** | will assume the role of developer/system owner       |
|               | security analyst for the system TOE.**               |
+---------------+------------------------------------------------------+
| **A           | **The AM Plan shall describe how the                 |
| MA_AMP.1.8C** | developer/system owner security analyst role will    |
|               | ensure that the procedures documented or referenced  |
|               | in the AM Plan are followed.**                       |
+---------------+------------------------------------------------------+
| **A           | **The AM Plan shall describe how the                 |
| MA_AMP.1.9C** | developer/system owner security analyst role will    |
|               | ensure that all developer/integrator actions         |
|               | involved in the analysis of the security impact of   |
|               | changes affecting the TOE are performed correctly.** |
+---------------+------------------------------------------------------+
| **AM          | **The AM Plan shall justify why the identified       |
| A_AMP.1.10C** | developer/system owner security analyst(s) have      |
|               | sufficient familiarity with the security target,     |
|               | functional specification and (where appropriate)     |
|               | high level design of the TOE, and with the           |
|               | evaluation results and all applicable assurance      |
|               | requirements for the certified version of the TOE.** |
+---------------+------------------------------------------------------+
| **AM          | **The AM Plan shall describe or reference the        |
| A_AMP.1.11C** | procedures to be applied to maintain the assurance   |
|               | in the TOE, which shall include the procedures for   |
|               | configuration management, maintenance of assurance   |
|               | evidence, performance of the analysis of the         |
|               | security impact of changes affecting the TOE, and    |
|               | flaw remediation.**                                  |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the information     |
| MA_AMP.1.1E** | provided meets all requirements for content and      |
|               | presentation of evidence.                            |
+---------------+------------------------------------------------------+
| **A           | The evaluator shall confirm that the proposed        |
| MA_AMP.1.2E** | schedules for AM audits and re-evaluation of the TOE |
|               | are acceptable and consistent with the proposed      |
|               | changes to the TOE.                                  |
+---------------+------------------------------------------------------+

## Security Requirements for the IT Environment

The STOE has no requirements for the external IT environment, other than
those stipulated by the organizational security policies (refer to
section 3.3).

## Security Requirements for the Non-IT Environment

The STOE has no requirements for the external non-IT environment, other
than those stipulated by the organizational security policies (refer to
section 3.3).

# SPP Application Notes

Editor's note: To be completed in the next release. Overall structure of
chapter provided for comment.

This section of the document contains supporting information that will
be useful in developing more focused system protection profiles or
security targets for specific classes of industrial control systems, for
example SCADA systems, or for specific applications of industrial
control systems.

## SPP Overview

### SPP Purpose

A system protection profile provides a statement of the security
requirements, generally at an abstract / implementation independent
level but can provide industry specific implementation details to ensure
consistent compliance.

Therefore, for a specific community of interest (e.g. the process
control industry) providing a related family of "constructs" (i.e.
system protection profiles, functional packages, assurance packages,
system security targets) that help to ensure interoperability, provide
for a consistent implementation of security controls, countermeasures
and ensures sufficient assurance (confidence in the ultimate system).

The following diagram illustrates how the Application Notes will
eventually provide the required guidance on how to develop, and the
relationships amongst the family of "constructs" being developed to
support the ICS.

![](media/image5.wmf)

Figure 3 - Relationship between ICS-SPP and other potential SPP\'s and
SST\'s

### SPP Structure

-   SPP structure flowchart

-   SPP concept relationships

-   Integration of risk

-   Importance of risk management

### SPP Application

-   Intended application

-   Application of the ICS-SPP to specific ICS' requirements (e.g.
    SCADA)

-   Completing the SPP for other uses

## SPP Application: System Requirements Specification

### Traditional CC Paradigm

-   Technical nature of TOE Security Functions (TSF)

### Systems Context

-   The need for System Security Functions (SSF)

-   Technical Security Functions (TSF)

-   Policy, Procedural and Physical Functions (PSF)

## SPP Application: Risk Management

-   Importance of risk management

-   Overview of the risk management process (based on the newly revised
    NIST Special Publication 800-30)

-   Integration of the risk management process with the ICS-SPP

    -   Context Establishment

    -   Risk Identification

    -   Risk Analysis (including threat assessment & vulnerability
        assessment)

    -   Risk Evaluation

    -   Risk Treatment

    -   Risk Monitoring

## SPP Application: SPP

This section provides guidance on how to refine the ICS-SPP into further
SPP's for specific ICS systems (e.g. SCADA systems).

### Refinement of the Security Environment

#### Assumptions, Threats and OOSPs

-   Additions

-   Modifications

-   Deletions

#### System Assets

-   Identification of critical assets

#### Vulnerability Analysis

-   Integration with the security environment

-   Refinement during the STOE evaluation

#### Threat Analysis

-   Integration with the security environment

-   Refinement during the STOE evaluation

### Risks

#### Identification of Additional Risks to the System

-   Technical controls

-   Management controls

-   Operational controls

#### Refinement of Identified Risks

-   Additions

-   Modifications

-   Deletions

### Refinement of the Security Objectives

-   Additions

-   Modifications

-   Deletions

### Refinement of the IT Security Requirements

#### Integration of level of risk to the Functional Security Requirements

#### Integration of level of risk to the Assurance Security Requirements

### Supporting Rationale

#### Security Risks Rationale

-   Mapping assets, threats and vulnerabilities to identified risks

-   Sufficiency of security risks

#### Security Objectives Rationale

-   Suitability of the security objectives to counter identified risks

-   Sufficiency of the security objectives to counter identified risks

## SPP Application: SST

This section provides guidance on how to claim conformance to the
ICS-SPP for specific ICS systems.

### STOE Summary Specification

#### Selection of Controls 

-   Management

-   Operational

-   Technical

#### Mitigation of the Risk

-   Risk Treatment: avoidance, reduction of likelihood, reduction of
    impact, risk transference and risk retention.

-   Risk Monitoring: risk management plan

### SPP Claims

#### Conformance to the ICS-SPP

### Supporting Rationale

#### Sufficiency of Controls to meet the Security Objectives

#### Sufficiency of Controls to mitigate the Identified Risks

#  {#section-5 .unnumbered}

# Rationale

Editor's note: To be completed in the next release.

## Security Risks Rationale

The purpose of this rationale is to demonstrate that the identified
security risks are suitable, that is they are sufficient to address the
security needs, and that they are necessary, ie, there are no redundant
security risks.

### All Assets, Threats and Vulnerabilities Addressed

The need to demonstrate that there are no redundant security risks is
satisfied as follows:

-   The first section (Table 14) shows that all of the assets, threats
    to security, and vulnerabilities have been addressed.

-   The second section (Table 15) shows that each security risk
    addresses at least one assumption, policy, and threat combination.

[]{#__RefHeading___Toc63689421 .anchor}Table 14 - Mapping of Assets,
Threats and Vulnerabilities to Security Risks

  ------------------------------------- ---------------------------------
  **Asset/Threat/Vulnerability Label**  **Associated Security Risk**

  A.                                    OE.

  T.                                    O.

  P.                                    O.
  ------------------------------------- ---------------------------------

Table 15 shows that there are no unnecessary IT security risks.

[]{#__RefHeading___Toc63689422 .anchor}Table 15 - Mapping of Security
Risks to Assets, Threats and Vulnerabilities

+----------------------------------+-----------------------------------+
| **Risk Label**                   | **Asset / Threat/ Vulnerability** |
+----------------------------------+-----------------------------------+
| R.                               | ASSET.                            |
|                                  |                                   |
|                                  | T.                                |
|                                  |                                   |
|                                  | V.                                |
+----------------------------------+-----------------------------------+
| R.                               | ASSET.                            |
|                                  |                                   |
|                                  | T.                                |
|                                  |                                   |
|                                  | V.                                |
+----------------------------------+-----------------------------------+
| R.                               | ASSET.                            |
|                                  |                                   |
|                                  | T.                                |
|                                  |                                   |
|                                  | V.                                |
+----------------------------------+-----------------------------------+

### Security Risks are Sufficient

The following arguments are provided in Table 16 to demonstrate the
sufficiency of the Security Risks outlined above.

[]{#__RefHeading___Toc63689423 .anchor}Table 16 - Sufficiency of
Security Risks

  -------------------------------- ------------------------------------------------
  **Asset/Threat/Vulnerability**   **Argument to support Security Risk
                                   sufficiency**

  A.                               

  T.                               

  V.                               
  -------------------------------- ------------------------------------------------

## Security Objectives Rationale

The purpose of this rationale is to demonstrate that the identified
security objectives are suitable, that is they are sufficient to address
the security needs, and that they are necessary, ie, there are no
redundant security objectives.

### All Assumptions, Threats and Policies Addressed

The need to demonstrate that there are no redundant security objectives
is satisfied as follows:

-   The first section (Table 17) shows that all of the secure usage
    assumptions, threats to security, and organizational security
    policies have been addressed.

-   The second section (Table 18) shows that each security objective
    counters at least one assumption, policy, or threat.

[]{#__RefHeading___Toc63689424 .anchor}Table 17 - Mapping of
Assumptions, Threats, and OSPs to Security Objectives

  ------------------------------------- ---------------------------------
  **Threat/Policy/Assumption Label**    **Associated Security Objective**

  A.                                    OE.

  T.                                    O.

  P.                                    O.
  ------------------------------------- ---------------------------------

Table 18 shows that there are no unnecessary IT security objectives.

[]{#__RefHeading___Toc63689425 .anchor}Table 18 - Mapping of Security
Objectives to Threats, Policies and Assumptions

+----------------------------------+-----------------------------------+
| **Objective Label**              | **Threat / Policy/ Assumption**   |
+----------------------------------+-----------------------------------+
| O.                               | A.                                |
|                                  |                                   |
|                                  | T.                                |
|                                  |                                   |
|                                  | P.                                |
+----------------------------------+-----------------------------------+
| O.                               | A.                                |
|                                  |                                   |
|                                  | T.                                |
|                                  |                                   |
|                                  | P.                                |
+----------------------------------+-----------------------------------+
| O.                               | A.                                |
|                                  |                                   |
|                                  | T.                                |
|                                  |                                   |
|                                  | P.                                |
+----------------------------------+-----------------------------------+

### Security Objectives are Sufficient

The following arguments are provided in Table 19 to demonstrate the
sufficiency of the Security Objectives outlined above.

[]{#__RefHeading___Toc63689426 .anchor}Table 19 - Sufficiency of
Security Objectives

  ------------------------------ -------------------------------------------------
  **Assumption/Threat/Policy**   **Argument to support Security Objective
                                 sufficiency**

  A.                             

  T.                             

  P.                             
  ------------------------------ -------------------------------------------------

### Suitability of the Security Objectives to counter identified Risks

The purpose of this section is to show that the security objectives are
suitable to address the identified security risks. Table 20 and Table 21
show that each security objective is necessary, that is, each security
risk is addressed by at least one security objective and vice versa.

[]{#__RefHeading___Toc63689427 .anchor}Table 20 - Mapping of Security
Risks to Security Objectives

  ------------------------------- ---------------------------------------
  **Security Risks**              **Security Objectives**

  R.                              O.

  R.                              O.

  R.                              O.
  ------------------------------- ---------------------------------------

[]{#__RefHeading___Toc63689428 .anchor}Table 21 - Mapping of Security
Objectives to Security Risks

  ------------------------------- ---------------------------------------
  **Security Objective**          **Security Risk**

  O.                              R.

  O.                              R.

  O.                              R.
  ------------------------------- ---------------------------------------

### Sufficiency of the Security Objectives to counter identified Risks

The following table shows that security objectives are sufficient to
counter the security risks, whether in a principal or supporting role.

[]{#__RefHeading___Toc63689429 .anchor}Table 22 - Sufficiency of
Security Objectives countering identified Risks

  ------------- ---------------------------------------------------------
  **Security    **Argument to support sufficiency of Security Objectives
  Risks**       countering identified Risks**

  R.            

  R.            

  R.            
  ------------- ---------------------------------------------------------

##  {#section-6 .unnumbered}

## Security Requirements Rationale

### Suitability of the Security Requirements

The purpose of this section is to show that the identified security
requirements are suitable to meet the security objectives. Table 23 and
Table 24 show that each security requirement is necessary, that is, each
security objective is addressed by at least one security requirement and
vice versa. Note that some objectives are partially satisfied by the
STOE and partially satisfied by the IT environment. Security Objectives
for the STOE are satisfied by Common Criteria functional components.
Security Objectives for the Environment are satisfied by IT requirements
for the environment.

[]{#__RefHeading___Toc63689430 .anchor}Table 23 - Mapping of Security
Objectives to Security Requirements

  ------------------------------- ---------------------------------------
  **Security Objectives**         **Security Requirements**

  O.                              F

  O.                              F

  O.                              F
  ------------------------------- ---------------------------------------

[]{#__RefHeading___Toc63689431 .anchor}Table 24 - Mapping of Security
Requirements to Security Objectives

  ------------------------------- ---------------------------------------
  **Requirements**                **Objective**

  F                               O.

  F                               O.

  F                               O.
  ------------------------------- ---------------------------------------

### Sufficiency of the Security Requirements

The following table shows that security requirements are sufficient to
satisfy the STOE security objectives, whether in a principal or
supporting role.

[]{#__RefHeading___Toc63689432 .anchor}Table 25 - Sufficiency of
Security Requirements

  ------------------ ----------------------------------------------------
  **Objectives**     **Argument to support sufficiency of Security
                     Requirements**

  O.                 

  O.                 

  O.                 
  ------------------ ----------------------------------------------------

### Satisfaction of Dependencies

Table 26 shows the dependencies between the functional requirements. All
of the dependencies are satisfied.

Note that:

> \(H\) indicates the dependency is satisfied through the inclusion of a
> component that is hierarchical to the one required).
>
> (\*) indicates that this dependency is not satisfied by the TOE. Refer
> to the supporting rationale following Table 26.

[]{#__RefHeading___Toc63689433 .anchor}Table 26 - Dependency Analysis

+-------------------+--------------+----------------------+-----------+
| **Component       |              |                      |           |
| Reference         |              |                      |           |
| Requirement       |              |                      |           |
| Dependencies      |              |                      |           |
| Dependency        |              |                      |           |
| Reference**       |              |                      |           |
+-------------------+--------------+----------------------+-----------+
| **Functional      |              |                      |           |
| Requirements**    |              |                      |           |
+-------------------+--------------+----------------------+-----------+
| 1                 | FAU_ARP.1    | FAU_SAA.1            |           |
+-------------------+--------------+----------------------+-----------+
| **Assurance       |              |                      |           |
| Requirements**    |              |                      |           |
+-------------------+--------------+----------------------+-----------+
| 8                 | ACM_CAP.2    | None                 | \-        |
+-------------------+--------------+----------------------+-----------+
| 9                 | ADO_DEL.1    | None                 | \-        |
+-------------------+--------------+----------------------+-----------+
| 10                | ADO_IGS.1    | AGD_ADM.1            |           |
+-------------------+--------------+----------------------+-----------+
| 11                | ADV_FSP.1    | ADV_RCR.1            |           |
+-------------------+--------------+----------------------+-----------+
| 12                | ADV_HLD.1    | ADV_FSP.1, ADV_RCR.1 |           |
+-------------------+--------------+----------------------+-----------+
| 13                | ADV_RCR.1    | None                 | \-        |
+-------------------+--------------+----------------------+-----------+
| 14                | ADV_SPM.1    | ADV_FSP.1            |           |
+-------------------+--------------+----------------------+-----------+
| 15                | AGD_ADM.1    | ADV_FSP.1            |           |
+-------------------+--------------+----------------------+-----------+
| 16                | AGD_USR.1    | ADV_FSP.1            |           |
+-------------------+--------------+----------------------+-----------+
| 17                | ATE_COV.1    | ADV_FSP.1, ATE_FUN.1 |           |
+-------------------+--------------+----------------------+-----------+
| 18                | ATE_FUN.1    | None                 | \-        |
+-------------------+--------------+----------------------+-----------+
| 19                | ATE_IND.2    | ADV_FSP.1,           |           |
|                   |              | AGD_ADM.1,           |           |
|                   |              |                      |           |
|                   |              | AGD_USR.1, ATE_FUN.1 |           |
+-------------------+--------------+----------------------+-----------+
| 20                | AVA_SOF.1    | ADV_FSP.1, ADV_HLD.1 |           |
+-------------------+--------------+----------------------+-----------+
| 21                | AVA_VLA.1    | ADV_FSP.1,           |           |
|                   |              | ADV_HLD.1,           |           |
|                   |              |                      |           |
|                   |              | AGD_ADM.1, AGD_USR.1 |           |
+-------------------+--------------+----------------------+-----------+

The following dependencies are not satisfied in this System Protection
Profile because they are not considered relevant to the STOE for the
provided reasons:

-   TBD

## Rationale for Extensions

TBD

# Appendix A -- Acronyms {#appendix-a-acronyms .unnumbered}

Editor's note: To be completed in next release.

  --------------- -------------------------------------------------------
  CC              Common Criteria

  EAL             Evaluation Assurance Level

  ICS             Industrial Control System

  IT              Information Technology

  NIAP            National Information Assurance Partnership

  NIST            National Institute of Standards and Technology

  NSA             National Security Agency

  PP              Protection Profile

  PSF             Procedural, Policy, Personnel & Physical Security
                  Functions

  SF              Security Function

  SFP             Security Function Policy

  SOF             Strength of Function

  SPP             System Protection Profile

  ST              Security Target

  SST             System Security Target

  STOE            System Target of Evaluation

  TSC             TSF Scope of Control

  TSF             Technical Security Functions

  SSF             System Security Functions

  TSFI            TSF Interface

  TSP             TOE Security Policy
  --------------- -------------------------------------------------------

[^1]: The descriptions for expertise, resources and motivation
    correspond to those defined for "capability of the attacker",
    "resources of the attacker", and "intent of the attacker" from
    Appendix E of NIST Special Publication 800-53: Recommended Security
    Controls for Federal Information Systems.

[^2]: The description for opportunity relates to whether the attack can
    be conducted within the ICS network (locally) or outside the
    protected boundary of the ICS network (remotely).