© Crown Copyright (2000)

Module 2.1

Security Requirements

“You Are Here”

M2.1 Security Requirements

M2.2 Development Representations

M2.3 Functional Testing

M2.4 Development Environment

M2.5 Operational Environment

M2.6 Vulnerability Analysis

M2.7 Penetration Testing

M2.8 Assurance Maintenance/Composition

MODULE 2 - ASSURANCE

Introduction

• Security Target– defines scope of security problem– specifies security functions– identifies assurance requirement

• Security Policy Model– required at higher assurance levels

Define the Security Problem

• Assets– what are the protection needs?

• Threats– asset at risk– threat agent– method of attack

• Other constraints on the TOE

Scope the Security Problem

• TOE boundary and interfaces– data in/out – links to underlying systems

• Identify what is assumed:– IT dependencies, e.g. underlying O/S– connectivity to other systems– non-technical aspects (personnel, procedural,

physical)

Specifying Countermeasures

• Security Functions, e.g.– Access Control– Identification & Authentication– Audit

• Non-IT countermeasures, e.g.– physical protection– procedural measures

Identifying the Assurance Requirement

• What assurance is needed to reduce residual risk to assets to acceptable level?– asset value– threats and risk to assets– balance between IT and non-IT

• What practical constraints apply?

Suitability

• Countermeasures mapped to threats– all threats covered– no redundant countermeasures

• Rationale or analysis demonstrating that the specified countermeasures will counter the threats

Specification Styles

• Informal– English

• Semi-formal– restricted notation, e.g. SSADM

• Formal– mathematical concepts, e.g. ‘Z’

Example Informal Specification

• The TOE will prevent read access by a subject in respect of an object whose label is not dominated by the label of the subject.

Example Semi-formal Specification

A subject is permitted to read an object only if:

a) the hierarchical part of the subject label is greater than or equal to that of the object label

and

b) the categories within the object label form a subset of the categories within the subject label.

Example Formal Specification

L1, L2 : class

L1 dominates L2 security-level (L1) security-level (L2) categories (L2) categories (L1)

The Security Function is defined by introducing the function canread:

sub canread obj max-level(sub) dominates level(obj)

Security Policy Models

• Provides a precise and abstract definition of the security policies

• Defines the policy rules and characteristics

• Not all security policies can be modelled

Evaluation Reporting

• Confirm required content is provided

• Confirm specifications exhibit required characteristics

• Confirm absence of ambiguities, inconsistencies, and justify search

• Confirm suitability of countermeasures to address the ‘security problem’

ITSEC Requirements

Aspect E1 E2 E3 E4 E5 E6

Security Target

Informal SEFs

Semiformal SEFs

Formal SEFs

Suitability Analysis

Formal SPM

Informal interpretation of SPM

ITSEC Security Target

Objectives

Assumptions

Threats

SEFs

ITSEC ST

SuitabilityAnalysis

CC Requirements

Aspect EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7

Security Target

Informal SPM

Formal SPM

Protection Profile

SECURITYENVIRONMENT

SECURITYOBJECTIVES

SECURITYREQUIREMENTS

Threats OrganisationalSecurity Policies Assumptions

TOESecurity Objectives

EnvironmentSecurity Objectives

Functional AssuranceIT

Environment

Rationale

Rationale

CC Security Target

SECURITYREQUIREMENTSFunctional Assurance

ITEnvironment

TOE SUMMARYSPECIFICATION

IT SecurityFunctions

AssuranceMeasures

SECURITY ENVIRONMENT

SECURITY OBJECTIVES

Rationale

CC Part 2 Organisation

• Class– e.g. FAU Security audit

• Family– e.g FAU_GEN Security audit data generation

• Component– e.g. FAU_GEN.1 Audit data generation

• Element– e.g. FAU_GEN.1.1

CC Functional Components - 1

• Assignment and selection, e.g.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].

• Refinement, e.g.FMT_MTD.3.1 The TSF shall ensure that only secure values are

accepted for TSF data.

Refinement: the TSF shall ensure that the minimum password length enforced by the TOE is configured to a value of at least 6 characters.

CC Functional Components - 2

• Iteration, e.g.FMT_MTD.1.1;1 The TSF shall restrict the ability to create, delete,

and clear the audit trail to authorised administrators.

FMT_MTD.1.1;2 The TSF shall restrict the ability to modify or observe the set of audited events to authorised administrators.

FMT_MTD.1.1;3 The TSF shall restrict the ability to initialize the authentication data to authorised administrators.

CC Functional Components - 3

• Dependencies, e.g.– FAU_GEN.1 (Audit data generation) depends

on– FPT_STM.1 (Reliable timestamps)

• Mutual support– bypass and tampering attacks– absence of conflict

Summary

• The Security Target provides:– a precise definition of the security problem– a formal statement of the scope of evaluation– a specification of the TOE’s security functions,

to solve the security problem– the baseline for the evaluation of the TOE

• Security Policy Models provide additional clarification of notion of TOE security

Further Reading

ITSEC evaluation

• ITSEC Section 2

• UKSP 05 Part III, Chapters 3-4

CC evaluation

• CC Part 1, Annexes B & C

• CEM Part 2, Chapters 3 and 4

• CC Part 3, Section 10.7 and CEM Part 2, Chapter 8 (ADV_SPM section)

Ideas for Exercise - 1

• For a simple example TOE, identify the content of its security target in terms of:– assets to be protected– threats– environmental assumptions– security functions.

Ideas for Exercise - 2

• Perform a high-level evaluation of an existing security target. Read through the security target and identify where the key aspects are defined:– threats– environmental assumptions– security functions– assurance requirement