1 norshahnizakamalbashah-19112007- CEM v3.1: Chapter 10 Security Target Evaluation

1 norshahnizakamalbashah-19112007-

CEM v3.1: Chapter 10

Security Target Evaluation


Content• Introduction• Security assurance components• Assurance Structure• 10 Security Assurance Classes• Class ASE: Security Target Evaluation• Organising the requirements• Application Notes• ST Introduction (ASE_INT)• Conformance claims (ASE_CC)• Security problem definition (ASE_SPD)• Security objectives (ASE_OBJ)• Extended component definition (ASE_ECD)• Security requirements (ASE_REQ)• TOE summary specification (ASE_TSS)


Introduction• Evaluation – a process in which the evidence for

assurance is gathered and analyzed against criteria for functionality and assurance

• Formal evaluation methodology – a technique used to provide measurements of trust based on specific security requirements and evidence of assurance

• Evaluation standards:– Trusted Computer System Evaluation Criteria (TCSEC)

1983-1999– Information Technology Security Evaluation Criteria

(ITSEC)– Common Criteria (CC) 1998-present


Introduction• Common criteria

– CC documents• CC Part 1: Introduction and general model• CC Part 2: Security functional components• CC Part 3: Security assurance components

(Basis for the security assurance requirements expressed in a PP or a ST)

– CC Evaluation Methodology (CEM)– Country-specific evaluation methodology (Evaluation

Scheme/National Scheme)

• CEM – provides detailed guidelines for the evaluation of products and systems at each EAL


Securityassurance

components


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


10 Security Assurance Classes

Protection Profile(APE)

Security Target(ASE)

Maintenanceof Assurance

(CM)

ADV

AGD

ALC

ATE

AVA

AMA

ADO

Assurance for production of

system


ASESecurity Target Evaluation

ASE_INT

ASE_CCL

ASE_SPD

ASE_TSSASE_REQASE_ECD

ASE_OBJ

Class ASE: Security Target evaluation

• It is required to demonstrate that the ST is sound and internally consistent, and if the ST is based on one or more PPs or packages, that the ST is a correct instantiation of these PPs and packages

• These properties are necessary for the ST to be suitable for use as the basis for a TOE evaluation


Class ASE: Security Target evaluation


Class ASESecurity Target evaluation

ASE_INT

ASE_CCL

ASE_SPD

ASE_OBJ

ASE_ECD

ASE_REQ

ASE_TSS

1

1

1

21

1

21

21

1.1E (8)

1.1E (10)

1.1E (4)

2.1E (6)

1.1E (5)1.2E (1)

2.1E (9)

2.1E (3)

2.2E (1)

1.2E (1)

1.1E (1)

1.1E (6)

1.1E (1) 1.2E (1)

ST Introduction

Security problem definition

Security objective

Extended component definition

Security requirements

TOE summary specification

Conformance claims

ST and TOE conform with CCST conform with PP


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


Application notes

• Reusing the evaluation results of certified PPs– The potential for reuse of the result of a certified PP is greater

if the ST does not add threats, OSPs, assumptions, security objectives and/or security requirements to those of the PP

– If the original requirements are internally consistent, the evaluator only has to determine that:

• The set of all new and/or changed requirements is internally consistent, and

• The set of all new and/or changed requirements is consistent with the original requirements

– The evaluator notes in the ETR each case where analyses are not done or only partially done for this reason


ST Introduction Family (ASE_INT)

• Evaluation of sub-activity (ASE_INT.1)– Objectives

• To determine whether the ST and the TOE are correctly identified, whether the TOE is correctly described in a narrative way at three levels of abstraction (TOE reference, TOE overview and TOE description), and whether these three descriptions are consistent with each other

– Input• The ST

ST Introduction 1


ST Introduction (ASE_INT)

• Action ASE_INT.1.1E– The ST introduction shall contain an ST reference, a TOE

reference, a TOE overview and a TOE description– The ST reference shall uniquely identify the ST– The TOE reference shall identify the TOE– The TOE overview shall summarise the usage and major

security features of the TOE– The TOE overview shall identify the TOE type– The TOE overview shall identify any non-TOE

hardware/software/firmware required by the TOE– The TOE description shall describe the physical scope of the

TOE– The TOE description shall describe the logical scope of the TOE

ASE_INT.1.1C

ASE_INT.1.3C

ASE_INT.1.4C

ASE_INT.1.5C

ASE_INT.1.6C

ASE_INT.1.7C

ASE_INT.1.8C

ASE_INT.1.2C

ST Introduction 1


ST Introduction (ASE_INT)

• Action ASE_INT.1.2E– The evaluator shall examine the TOE reference, TOE

overview and TOE description to determine that they are consistent with each other

ASE_INT.1.11

ST Introduction 1


Conformance claims (ASE_CCL)

• Evaluation of sub-activity (ASE_CCL.1)– Objectives

• To determine the validity of various conformance claims. These describe how the ST and the TOE conform to the CC and how the ST conforms to PPs and packages

– Input• The ST• The PP(s) that the ST claims conformance to• The package(s) that the ST claims conformance to

Conformance claims 1


• Action ASE_CCL.1.1E– The conformance claim shall contain a CC conformance claim

that identifies the version of the CC to which the ST and the TOE claim conformance

– The CC conformance claim shall describe the conformance of the ST to CC Part 2 as either CC Part 2 conformant or CC Part 2 extended

– The CC conformance claim shall describe the conformance of the ST to CC Part 3 as either CC Part 3 conformant or CC Part 3 extended

– The CC conformance claim shall be consistent with the extended components definition

– The conformance claim shall identify all PPs and security requirement packages to which the ST claims conformance


ASE_CCL.1.1C

ASE_CCL.1.2C

ASE_CCL.1.3C

ASE_CCL.1.4C

ASE_CCL.1.5C



• Action ASE_CCL.1.1E (cont.)– The conformance claim shall describe any

conformance of the ST to a package as either package-conformant or package-augmented

– The conformance claim rationale shall demonstrate that the TOE type is consistent with the TOE type in the PPs for which conformance is being claimed

– The conformance claim rationale shall demonstrate that the statement of the security problem definition is consistent with the statement of the security problem definition in the PPs for which conformance is being claimed


ASE_CCL.1.6C

ASE_CCL.1.7C

ASE_CCL.1.8C



• Action ASE_CCL.1.1E (cont.)– The conformance claim rationale shall demonstrate

that the statement of security objectives is consistent with the statement of security objectives in the PPs for which conformance is being claimed

– The conformance claim rationale shall demonstrate that the statement of security requirements is consistent with the statement of security requirements in the PPs for which conformance is being claimed


ASE_CCL.1.9C

ASE_CCL.1.10C



Security problem definition (ASE_SPD)

• Evaluation of sub-activity (ASE_SPD.1)– Objectives

• To determine that the security problem intended to be addressed by the TOE and its operational environment is clearly defined

– Input• The ST

Security problem definition 1


• Action ASE_SPD.1.1E – The security problem definition shall describe the

threats– All threats shall be described in terms of a threat

agent, an asset, and an adverse action– The security problem definition shall describe the

OSPs– The security problem definition shall describe the

assumptions about the operational environment of the TOE

Security problem definition (ASE_SPD)

ASE_SPD.1.1C

ASE_SPD.1.2C

ASE_SPD.1.3C

ASE_SPD.1.4C

Security problem definition 1


Security objectives (ASE_OBJ)

• Evaluation of sub-activity (ASE_OBJ.1)– Security objectives are a concise statement of the intended

response to the security problem defined through the Security problem definition (ASE_SPD) family

– Objectives• To determine whether the security objectives for the

operational environment are clearly defined

– Input• The ST

Security objectives 1 2

1 2Security objective for the operational environment

Security objective for the TOE


• Action ASE_OBJ.1.1E – The statement of security objectives shall describe

the security objectives for the operational environment


ASE_OBJ.1.1C




• Evaluation of sub-activity (ASE_OBJ.2)– Objectives

• To determine whether the security objectives adequately and completely address the security problem definition and that the division of this problem between the TOE and its operational environment is clearly defined

– Input• The ST



• Action ASE_OBJ.2.1E – The statement of security objectives shall describe the

security objectives for the TOE and the security objectives for the operational environment

– The security objectives rationale shall trace each security objective for the TOE back to threats countered by that security objective and OSPs enforced by that security objective

– The security objectives rationale shall trace each security objective for the operational environment back to threats countered by that security objective, OSPs enforced by that security objective and assumptions upheld by that security objective


ASE_OBJ.2.1C

ASE_OBJ.2.2C

ASE_OBJ.2.3C



• Action ASE_OBJ.2.1E (cont.)– The security objectives rationale shall demonstrate

that the security objectives counter all threats– The security objectives rationale shall demonstrate

that the security objectives enforce all OSPs– The security objectives rationale shall demonstrate

that the security objectives for the operational environment uphold all assumptions


ASE_OBJ.2.4C

ASE_OBJ.2.5C

ASE_OBJ.2.6C



Extended components definition (ASE_ECD)

• Evaluation of sub-activity (ASE_ECD.1)– Extended security requirements are requirements that are

not based on components from CC Part 2 or CC Part 3, but are based on components: components defined by the ST author

– Objectives• To determine whether extended components have been

clearly and unambiguously defined, and whether they are necessary, i.e. they may not be clearly expressed using existing CC Part 2 or CC Part 3 components

– Input• The ST

Extended components definition 1


• Action ASE_ECD.1.1E– The statement of security requirements shall identify

all extended security requirements– The extended components definition shall define an

extended component for each extended security requirement

– The extended components definition shall describe how each extended component is related to the existing CC components, families, and classes

– The extended components definition shall use the existing CC components, families, classes, and methodology as a model for presentation


ASE_ECD.1.1C

ASE_ECD.1.2C

ASE_ECD.1.3C

ASE_ECD.1.4C



• Action ASE_ECD.1.1E (cont.)– The extended components shall consist of

measurable and objective elements such that conformance or nonconformance to these elements can be demonstrated


ASE_ECD.1.5C



• Action ASE_ECD.1.2E – The evaluator shall examine the extended components

definition to determine that each extended component can not be clearly expressed using existing components


ASE_ECD.1-13



Security requirements (ASE_REQ)

• Evaluation of sub-activity (ASE_REQ.1)– Objectives

• To determine whether the SFRs and SARs are clear, unambiguous and well-defined and whether they are internally consistent

– Input• The ST

Security requirements 1 2

1 2Stated security requirements Derived security requirements


• Action ASE_REQ.1.1E – The statement of security requirements shall describe the SFRs

and the SARs– All subjects, objects, operations, security attributes, external

entities and other terms that are used in the SFRs and the SARs shall be defined

– The statement of security requirements shall identify all operations on the security requirements

– All operations shall be performed correctly– Each dependency of the security requirements shall either be

satisfied, or the security requirements rationale shall justify the dependency not being satisfied

– The statement of security requirements shall be internally consistent


ASE_REQ.1.1C

ASE_REQ.1.3C

ASE_REQ.1.4C

ASE_REQ.1.5C

ASE_REQ.1.6C

ASE_REQ.1.2C




• Evaluation of sub-activity (ASE_REQ.2)– Objectives

• To determine whether the SFRs and SARs are clear, unambiguous and well-defined, whether they are internally consistent, and whether the SFRs meet the security objectives of the TOE

– Input• The ST



• Action ASE_REQ.2.1E – The statement of security requirements shall describe the SFRs

and the SARs– All subjects, objects, operations, security attributes, external

entities and other terms that are used in the SFRs and the SARs shall be defined

– The statement of security requirements shall identify all operations on the security requirements

– All operations shall be performed correctly– Each dependency of the security requirements shall either be

satisfied, or the security requirements rationale shall justify the dependency not being satisfied

– The security requirements rationale shall trace each SFR back to the security objectives for the TOE


ASE_REQ.2.1C

ASE_REQ.2.2C

ASE_REQ.2.3C

ASE_REQ.2.4C

ASE_REQ.2.5C

ASE_REQ.2.6C



• Action ASE_REQ.2.1E (cont.)– The security requirements rationale shall

demonstrate that the SFRs meet all security objectives for the TOE

– The security requirements rationale shall explain why the SARs were chosen

– The statement of security requirements shall be internally consistent


ASE_REQ.2.7C

ASE_REQ.2.8C

ASE_REQ.2.9C



TOE summary specification (ASE_TSS)

• Evaluation of sub-activity (ASE_TSS.1)– Objectives

• To determine whether the TOE summary specification addresses all SFRs, and whether the TOE summary specification is consistent with other narrative descriptions of the TOE

– Input• The ST

TOE summary specification 1 2

1 2TOE summary specification TOE summary specification with architectural design summary


• Action ASE_TSS.1.1E – The TOE summary specification shall describe how

the TOE meets each SFR

TOE summary specification (ASE_TSS)TOE summary specification (ASE_TSS)

ASE_TSS.1.1C



• Action ASE_REQ.1.2E – The evaluator shall examine the TOE summary

specification to determine that it is consistent with the TOE overview and the TOE description


ASE_TSS.1-2




• Evaluation of sub-activity (ASE_TSS.2)– Objectives

• To determine whether the TOE summary specification addresses all SFRs, whether the TOE summary specification addresses interference, logical tampering and bypass, and whether the TOE summary specification is consistent with other narrative descriptions of the TOE

– Input• The ST



• Action ASE_TSS.2.1E – The TOE summary specification shall describe how

the TOE meets each SFR– The TOE summary specification shall describe how

the TOE protects itself against interference and logical tampering

– The TOE summary specification shall describe how the TOE protects itself against bypass


ASE_TSS.2.1C

ASE_TSS.2.2C

ASE_TSS.2.3C



• Action ASE_TSS.2.2E – The evaluator shall examine the TOE summary

specification to determine that it is consistent with the TOE overview and the TOE description


ASE_TSS.2-4


Documents

1 norshahnizakamalbashah-19112007- CEM v3.1: Chapter 10 Security Target Evaluation