# Presentation: 525701

## Developing Protection Profilesbased on PCSRFSecurity Capabilities Profile for Industrial Control Systems 

## SCP – Next stepProtection Profile(s) for ICS 

**Goal to have first PP(s) for discussion purposes in October timeframe**
**SCP is at least half way there **
**Gathered ICS description and security requirements**
** ****can be used as the basis for PP(s)**
**System-level or component-level?**
**Step-wise development**
**Subset of needed requirements**
**Any subset must be developed with mind of integration into the whole**

## PP as a System SpecificationApplying Protection Profile Concepts

**Develop each section from a logical perspective in terms of the component parts of the system.**
**Address the interaction between components and the interaction between components and their environment**

## Protection Profile

**Standard construct containing a set of requirements against which a Target of Evaluation (TOE) may be assessed, accompanied by a description of the security problem definition that set of requirements addresses**
**Usually a subset of provided solution (security-relevant)**

- Security Problem Definition: High level concept of operations including operational environment and threats, policies being addressed

- Problem partition: security contributions to problem versus ‘someone else’ – objectives

- Requirements: testable requirements for security contribution in standard language for comparability

## EnvironmentSpecification of Trust Relationship with Remote Systems

**Operational environment is comprised on**
**Security contributions from non-IT **
**IT Environment is comprised of **
**IT components that are not part of the TOE but with which the TOE shares a trust relationship**

## IT Environment Concept

**TOE**

- Non-IT environment
- implemented by the physical world

- IT Environment
- implemented by IT capabilities

- The general environment is enclosed inside the square, i.e., the ‘world’

**IT Environment Concept**

**TOE Environment is enclosed inside the circle**

## System vs. Product

**Product  - to be integrated into multiple system environments**
**Assumes environment contributions**
**Evaluation of capabilities to meet the requirements**
**System – ‘in its intended environment’**
**Specific set of environmental contributions**
**All contributions can be confirmed to together meet the operational needs**
- IT
- Physical
- Personnel
- Policies, processes, procedures
**ISO defining a ‘CC for systems’ that includes IT and ‘management’ security contributions**

## ISO 17799 Contents

**Security Policy**
**Organizational Security**
**Asset Classification and Control**
**Personnel Security**
**Physical and Environmental Security**
**Communications and Operations Management**
**Access Control**
**Systems Development and Maintenance**
**Business Continuity Management**
**Compliance**

## ISO 17799 & ISO 15408Comparison

**ISO 17799 – Information Technology – Code of Practice for Information Security Management**
**Addresses ‘end-to-end’ security management**
**Intended to serve as guide for development of organizational specific security management program**
**ISO 15408 – Common Criteria for Information Technology Security Evaluation**
**“****Meta-Standard” for development of security specifications**
- IT functional – what the implementation is to do
- IT assurance – measures taken to very correct implementation

## System of systems

## System of systems

## Composition and DecompositionIllustration

**System Concept**
**Specification**

**Component 1**
**Spec**

**Component 2**
**Spec**

**Component 3**
**Spec**

**Component n**
**Spec**

**. . .**

- Composition

- Decomposition

## System Specification Using Single Protection Profile

- E-Commerce
- System
- PP

## System Specification Using Multiple Protection Profiles

- E-Commerce
- System PP
- Browser
- Component

- E-Commerce
- System PP
- Web Server
- Component

- E-Commerce
- System PP
- Cert Server
- Component

## Logical versus Physical System Description

**Logical – ‘operations view’ with cursory knowledge of physical implementation**
**Allows multiple solutions**
**Can be discussed in terms of operational needs, data flow**
**Different ‘security subsystems’ share physical services**
**Can be esoteric for discussions with designers/implementors**
**Physical – ‘real’ architecture with background knowledge on how the services will use the architecture**
**Easy to define boundaries for provisions from different vendors**
**Clear what the system will ‘look like’**
**Engineers like discussing in physical terms**
**Limits solutions**
**When decompose logical view enough, will always end in physical description**

## Baseline PP with Industry Specific Packages

- Baseline Process Control Protection Profile:
- 	Common specification of ICS requirements, application notes and guidance

- Industry 1
- Added Requirements
- Specific Guidance

- Industry 2 additions

- Etcetera...

- Industry 3

## SCP versus SPP

**SCP contains many elements on the SPP**
**Describes key components**
**Lists some requirements**
**Mixes logical and physical representations**
**Contains logical descriptions with insertions of physical solution**
**New comments introduce further physical into logical space**
**Mixes product requirements (for providers) with system requirements (for plants/sites)**
**Initial pass to include non-IT contributions**

## Security is in the eye of the beholder

**Confidentiality**
**Loss of assets**
**Integrity **
**Trust in authenticity of assets**
**System integrity**
**Data integrity**
**Availability**
**Access to assets**

**Security becomes protection of all critical assets, where ‘critical’ is business case**
**Safety ~ system integrity and/or confidentiality**
**Performance ~ availability**
**Interoperability ~ availability**
**Correctness of processes ~ data integrity**

## Summary – PP approach 

**Define overall architecture (logical or physical)**
**Decompose to a level of granularity where each industry can understand the subsystems as they apply**
**Requirements versus design constraints**
**Choose (small) subset of subsystems and write base PPs capturing common requirements**
**Understand how will recompose **
**Write ‘industry packages’ with differences**
**Requirements**
**Application notes**
**Configuration considerations**