TM8104 IT Security EvaluationAutumn 20091 Evaluation - the Main Road to IT Security Assurance CC Part 3

TM8104 IT Security Evaluation Autumn 2009 1

Evaluation - the Main Road to IT Security Assurance

CC Part 3


Assurance definition

Asssurance that the claimed security measures of the TOE

areeffective

andimplemented correctly

is derived from knowledge about the- definition

- construction- operation of the TOE


Measuring Assurance

by: Active investigation

of the: TOE

by: Expert evaluators

with increasing emphasis on:

• scope• depth• rigour


Assurance StructureStatements ofRequirements

Technicalspecification

High-Leveldesign

Detaileddesign

Implementation

TOE

Each Assurance Component Consists of:

Developer Actions (.D) Activities to be performed by the developer - shall use, shall provide

Content and Presentation of Evidence (.C)Evidence required for evaluation, what the evidence must demonstrate,and what information the evidence must convey - include, identify, describe, show, demonstrate

Evaluator Actions (.E)Analysis implied by the evidence provided, and by the targetedlevel of assurance - confirm, determine

LowerLevels

ofAbstraction


Organising the requirements

Class

Family

Component

Element

- share a common intent different coverage of security objectives

- share security objectives different in emphasis or rigour

- describes a set of security requirements

- describes indivisible security requirements


Class hierarchy

Assurance classi 1< i < 7

Assurance family1

Assurance family2

Assurance familyn

Assurance component1

Assurance component2

Assurance componentj

Element1

Element2

Elementk

Element1 Element1

Element2 Element2

Elementk Elementk

2 < n < 6

1 < j < 6

1 < k < 21


Assurance classes and families

ASSURANCE CLASS ASSURANCE FAMILY ABBREV. NAME

Configuration managementCM automationCM capabilitiesCM scope

ACM_AUTACM_CAPACM_SCP

Delivery and operation DeliveryInstallation, generation, and start-up

ADO_DELADO_IGS

Development

Functional specificationHigh-level designImplementation representationTSF internalsLow-level designRepresentation correspondence

ADV_FSPADV_HLDADV_IMPADV_INTADV_LLDADV_RCR

Guidance documents Administrator guidanceUser guidance

AGD_ADMAGD_USR

Life cycle supportDevelopment securityFlaw remediationLife cycle definitionTools and techniques

ALC_DVSALC_FLRALC_LCDALC_TAT

TestsCoverageDepthFunctional testsIndependent testing

ATE_COVATE_DPTATE_FUNATE_IND

Vulnerability assessmentCovert channel analysisMisuseStrength of TOE security functionsVulnerability analysis

AVA_CCAAVA_MSUAVA_SOFAVA_VLA


Assurance class ACM

Configuration Management

CM Automation

CM Capabilities

CM Scope

1 2

1

1

2

2

3

3

4

CC Part 3 – page 71/86


Configuration management

- integrity of the TOE

ACM_AUT (2)CM automation establishes the level of automation usedto control the configuration items

ACM_CAP (4)CM capabilities define the characteristics of the CM system

ACM_SCP (3)CM scope indicates the TOE items that need to becontrolled by the CM system


ACM_AUT.1 Partial Configuration Management Automation

Objectives - the automated tools must be able to support the numerous changes that occur during development, and ensure that the changes are authorised

Dependencies - ACM_CAP.3 Authorization Controls

Developer action elements: ACM_AUT.1.1D, ACM_AUT.1.2D

Content and pres. of evidence:1.1C/1.4C

Evaluator action elements: 1.1E


Assurance class ADO

Delivery and Operation

Delivery

Installation, Generation and Start-Up

1 2

1 2

3



Delivery and operation

- secure delivery, installation and operation of the TOE

ADO_DEL (3)Delivery covers the procedures to maintain appropriatesecurity during transfer of the TOE to the user

ADO_IGS (2)Covers secure installation, generation and start-upprocedures


Assurance class ADVDevelopment

Funct. Specification

TSF Internals

1 2 3

1

4

2

5

3

6

High-Level Design 1 2 3 4 5

1 2 3Impl. Representation

Low-Level Design 1 2 3

Repr. Correspondence 1 2 3



Development - 1

- descriptions of the representation of the TSF at various levels of abstraction, and correspondence mappings

ADV_FSP (6)Correspondence and consistency between the TSP, TSP modeland functional specification

ADV_HLD (5)Provides a description of the TSF in terms of major structuralunits

ADV_IMP (3)Description of implementation in terms of source code, firmwareconstruction documentation, hardware drawings, etc.


Development - 2

ADV_INT (3)Describes the internal structure of the TSF

ADV_LLD (3)A description of the internal workings of the TSF in terms ofmodules, their interrelationships and dependencies

ADV_RCR (3)Describes the correspondence between the variousdevelopment representations


Assurance class AGD

Guidance Documents

AdministratorGuidance

User Guidance

1

1



Guidance documents

- requirements for user and administrator guidance

AGD_ADM (1)How to configure, maintain and administer the TOE ina correct manner for maximum security

AGD_USR (1)Documentation for the non-administrative user of the TOE


Assurance class ALC

Life Cycle Support

Development Security

Tools and Techniques

1 2

1 2 3

Flaw Remediation 1 2 3 4

1 2 3Life Cycle Definition



Life Cycle Support

- the establishment of discipline and control in the process ofrefinement of the TOE during development and maintenance.

ALC_DVS (2)Concerned with physical, procedural, personell and other security measures used in the development environment to protect the TOE

ALC_FLR (4)Discovered flaws should be tracked and corrected by the developer

ALC_LCD (3)Establishment of a model for developm. and maint. of the TOE

ALC_TAT (3)Selection of tools for development, analysis and impl. of the TOE


Assurance class ATE

Tests

Coverage

Independent Testing

1 2

1 2 3

Depth 1 2 3 4

1Functional Tests

3



Tests

- testing establishes whether the TSF exhibits the propertiesnecessary to satisfy the functional requirements of the PP/ST

ATE_COV (3)Deals with completeness of testing

ATE_DPT (4)Decides the level of detail to which the TOE is tested

ATE_FUN (1)Establishes that the TSF exhibits the properties necessary to satisfy the functional requirements of its PP/ST

ATE_IND (3)Demonstrates that the security functions perform as specified


Assurance class AVA

Vulnerability Assessment

Covert Ch. Analysis

Vulnerability Analysis

1 2

1 2 3

Misuse 1 2

1Strength of TOE funct.

3

4



Vulnerability assessment - 1

- addresses the possible existence of exploitable covert channels,misuse, incorrect configuration of the TOE, and the ability for allsecurity critical mechanisms to withstand direct attacks

AVA_CCA (3)Is carried out to determine the existence and potential capacity ofunintended signalling channels

AVA_MSU (2)Investigates whether the TOE can be configured or used in amanner which is insecure


Vulnerability assessment - 2

AVA_SOF (1)Assessment of the strength of the security mechanisms

AVA_VLA (4)Assessment to determine whether vulnerabilities identifiedcould allow malicious users to violate the TSP


Assurance Family ADV_INT

TSF Internals 1 2 3

Objectives -

Component Levelling -

Application Notes -

- deals with the internal structure of the TSF

modular construction, layering of software, minimization of circular dependencies, minimization of non-TSP enforcing software

based on the amount of structure andminimization required

“portions of the TSF”,interfaces, sub-systems, modulesimplementation units



TSF Internals 1 2 3

ADV_INT.1 Modularity

Dependencies:

ADV_IMP.1 Subset of the implementation of the TSFADV_LLD.1 Descriptive low-level design

Developer Action Elements:

1.1.D The developer shall the design and structure the TSF in a modular fashion that avoids unnecessary interactions between the modules of the design

1.2.D The developer shall provide an architectural description



TSF Internals 1 2 3


Content and presentation of evidence:

1.1.C The architectural description shall identify the modules of the TSF

1.2.C The architectural description shall describe the purpose, interface,parameters and effects of each module of the TSF

1.3.C The architectural description shall describe how the TSF design provides for largely independent modules that avoid unnecessaryinteractions




Evaluator actions:

1.1.E The evaluator shall confirm that the presentation provided meetsall requirements for contents and presentation of evidence

1.2.E The evaluator shall determine the both the low-level design and the implementation representation are in compliance with the architectural description

TSF Internals 1 2 3



TSF Internals 1 2 3

ADV_INT.2 Reduction of complexity

ADV_INT.3 Minimisation of complexity


Assurance levels

Assurance class Assurancefamily

Assurance components by evaluation assurance levelEAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7

Configurationmanagement

ACM_AUTACM_CAPACM_SCP

- - - 1 1 2 21 2 3 4 4 5 5- - 1 2 3 3 3

Delivery andoperation

ADO_DELADO_IGS

- 1 1 2 2 2 31 1 1 1 1 1 1

Development

ADV_FSPADV_HLDADV_IMPADV_INTADV_LLDADV_RCRADV_SPM

1 1 1 2 3 3 4- 1 2 2 3 4 5- - - 1 2 3 3- - - - 1 2 3- - - 1 1 2 21 1 1 1 2 2 3- - - 1 3 3 3

Guidancedocuments

AGD_ADMAGD_USR

1 1 1 1 1 1 11 1 1 1 1 1 1

Life cycle supportALC_DVSALC_FLRALC_LCDALC_TAT

- - 1 1 1 2 2- - - - - - -- - - 1 2 2 3- - - 1 2 3 3

TestsATE_COVATE_DPTATE_FUNATE_IND

- 1 2 2 2 3 3- - 1 1 2 2 3- 1 1 1 1 2 21 1 2 2 2 2 3

Vulnerabilityassessment

AVA_CCAAVA_MSUAVA_SOFAVA_VLA

- - - - 1 2 2- - 1 2 2 3 3- 1 1 1 1 1 1- 1 1 2 3 4 4


Assurance Levels

• EAL1 - Functionally tested• EAL2 - Structurally tested• EAL3 - Methodically tested and checked• EAL4 - Methodically designed, tested, and

reviewed• EAL5 - Semiformally designed and tested• EAL6 - Semiformally verified design and

tested• EAL7 - Formally verified design and tested


Example: EAL3

Objectives:

- to gain maximum assurance from positive security engineering at the design stage

- to obtain a moderate level of independently assured security


Developers have to use: (1 of 17)

ACM_CAP.3 Authorization controls

Dependencies:

ACM_SCP.1 TOE CM coverageALC_DVS.1 Identification of security measures

Developers action elements:

• Provide a reference for the TOE• Use a CM system• Provide CM documentation



ACM_SCP.1 TOE CM Coverage

Dependencies:

ACM_CAP.3 Authorisation controls


Provide CM documentation



ADO_DEL.1 Delivery procedures

Dependencies: None


• document procedures for delivery of the TOE or parts of it to the user• Use the delivery procedures



ADO_IGS.1 Installation, generation and start-up procedures

Dependencies:

AGD_ADM.1 Administrator guidance


Provide document procedures necessary for secureinstallation, generation and start-up of the TOE



ADV_FSP.1 Informal functional specification

Dependencies:

ADV_RCR.1 Informal correspondence specification


•Provide a functional specification•Use a CM system•Provide CM documentation


Developers have to use: ( 6 of 17)

ADV_HLD.2 Security enforcing high-level design

Dependencies:



Provide high-level design of the TSF



ADV_RCR.1 Informal correspondence demonstration

Dependencies: None


Provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided



AGD_ADM.1 Administrator guidance

Dependencies:


Developers action elements: Provide administrator guidance addressed to systemadministrative personnel



AGD_USR.1 User guidance

Dependencies: ADV_FSP.1 Informal functional specification

Developers action elements: Provide user guidance



ALC_DVS.1 Identification of security measures

Dependencies: None


Produce development security documentation



ATE_COV.2 Analysis of coverage Dependencies:

ADV_FSP.1 Informal functional specificationATE_FUN.1 Functional testing


Provide an analysis of the test coverage



ATE_DPT.1 Testing: high-level design Dependencies:

ADV_HLD.1 Descriptive high-level designATE_FUN.1 Functional testing


Provide the analysis of the depth of testing



ATE_FUN.1 Functional testing Dependencies: None


• Test the TSF and document the results• Provide test documentation



ATE_IND.2 Independent testing - sample Dependencies:

ADV_FSP.1 Informal functional specificationAGD_ADM.1 Administrator guidanceAGD_USR.1 User guidanceATE_FUN.1 Functional testing


Provide the TOE for testing



AVA_MSU.1 Examination of guidance Dependencies: ADO_IGS.1 Inst., gen., and start-up proceduresADV_FSP.1 Informal functional specificationAGD_ADM.1 Administrator guidanceAGD_USR.1 User guidance


Provide guidance documentation



AVA_SOF.1 Strength of the TOE Security Function evaluation

Dependencies:

ADV_FSP.1 Informal functional specificationADV_HLD.1 Descriptive high-level design


Provide a strength of TSF analysis for each mechanism identifiedin the ST as having a strength of TOE security claim



AVA_VLA.1 Developer vulnerability analysis

Dependencies: ADV_FSP.1 Informal functional specificationADV_HLD.1 Descriptive high-level designAGD_ADM.1 Administrator guidanceAGD_USR.1 User guidance

Developers action elements: • Perform and document an analysis of the TOE deliverables searching for obvious ways in which a user can violate the TSP• Document the disposition of obvious vulnerabilities