1 norshahnizakamalbashah-19112007- CEM v3.1: Chapter 10 Security Target Evaluation.
-
Upload
kathleen-long -
Category
Documents
-
view
215 -
download
0
Transcript of 1 norshahnizakamalbashah-19112007- CEM v3.1: Chapter 10 Security Target Evaluation.
2 norshahnizakamalbashah-19112007-
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)
3 norshahnizakamalbashah-19112007-
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
4 norshahnizakamalbashah-19112007-
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
6 norshahnizakamalbashah-19112007-
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
7 norshahnizakamalbashah-19112007-
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
8 norshahnizakamalbashah-19112007-
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
10 norshahnizakamalbashah-19112007-
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
11 norshahnizakamalbashah-19112007-
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
12 norshahnizakamalbashah-19112007-
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
13 norshahnizakamalbashah-19112007-
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
14 norshahnizakamalbashah-19112007-
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
15 norshahnizakamalbashah-19112007-
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
16 norshahnizakamalbashah-19112007-
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
17 norshahnizakamalbashah-19112007-
• 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
Conformance claims (ASE_CCL)
ASE_CCL.1.1C
ASE_CCL.1.2C
ASE_CCL.1.3C
ASE_CCL.1.4C
ASE_CCL.1.5C
Conformance claims 1
18 norshahnizakamalbashah-19112007-
• 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
Conformance claims (ASE_CCL)
ASE_CCL.1.6C
ASE_CCL.1.7C
ASE_CCL.1.8C
Conformance claims 1
19 norshahnizakamalbashah-19112007-
• 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
Conformance claims (ASE_CCL)
ASE_CCL.1.9C
ASE_CCL.1.10C
Conformance claims 1
20 norshahnizakamalbashah-19112007-
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
21 norshahnizakamalbashah-19112007-
• 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
22 norshahnizakamalbashah-19112007-
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
23 norshahnizakamalbashah-19112007-
• Action ASE_OBJ.1.1E – The statement of security objectives shall describe
the security objectives for the operational environment
Security objectives (ASE_OBJ)
ASE_OBJ.1.1C
Security objectives 1 2
24 norshahnizakamalbashah-19112007-
Security objectives (ASE_OBJ)
• 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
Security objectives 1 2
25 norshahnizakamalbashah-19112007-
• 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
Security objectives (ASE_OBJ)
ASE_OBJ.2.1C
ASE_OBJ.2.2C
ASE_OBJ.2.3C
Security objectives 1 2
26 norshahnizakamalbashah-19112007-
• 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
Security objectives (ASE_OBJ)
ASE_OBJ.2.4C
ASE_OBJ.2.5C
ASE_OBJ.2.6C
Security objectives 1 2
27 norshahnizakamalbashah-19112007-
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
28 norshahnizakamalbashah-19112007-
• 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
Extended components definition (ASE_ECD)
ASE_ECD.1.1C
ASE_ECD.1.2C
ASE_ECD.1.3C
ASE_ECD.1.4C
Extended components definition 1
29 norshahnizakamalbashah-19112007-
• 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
Extended components definition (ASE_ECD)
ASE_ECD.1.5C
Extended components definition 1
30 norshahnizakamalbashah-19112007-
• 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
Extended components definition (ASE_ECD)
ASE_ECD.1-13
Extended components definition 1
31 norshahnizakamalbashah-19112007-
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
32 norshahnizakamalbashah-19112007-
• 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
Security requirements (ASE_REQ)
ASE_REQ.1.1C
ASE_REQ.1.3C
ASE_REQ.1.4C
ASE_REQ.1.5C
ASE_REQ.1.6C
ASE_REQ.1.2C
Security requirements 1 2
33 norshahnizakamalbashah-19112007-
Security requirements (ASE_REQ)
• 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
Security requirements 1 2
34 norshahnizakamalbashah-19112007-
• 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
Security requirements (ASE_REQ)
ASE_REQ.2.1C
ASE_REQ.2.2C
ASE_REQ.2.3C
ASE_REQ.2.4C
ASE_REQ.2.5C
ASE_REQ.2.6C
Security requirements 1 2
35 norshahnizakamalbashah-19112007-
• 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
Security requirements (ASE_REQ)
ASE_REQ.2.7C
ASE_REQ.2.8C
ASE_REQ.2.9C
Security requirements 1 2
36 norshahnizakamalbashah-19112007-
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
37 norshahnizakamalbashah-19112007-
• 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
TOE summary specification 1 2
38 norshahnizakamalbashah-19112007-
• 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
TOE summary specification (ASE_TSS)
ASE_TSS.1-2
TOE summary specification 1 2
39 norshahnizakamalbashah-19112007-
TOE summary specification (ASE_TSS)
• 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
TOE summary specification 1 2
40 norshahnizakamalbashah-19112007-
• 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
TOE summary specification (ASE_TSS)
ASE_TSS.2.1C
ASE_TSS.2.2C
ASE_TSS.2.3C
TOE summary specification 1 2