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

2 norshahnizakamalbashah 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 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) – Information Technology Security Evaluation Criteria (ITSEC) – Common Criteria (CC) 1998-present

4 norshahnizakamalbashah 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

5 norshahnizakamalbashah Security assurance components

6 norshahnizakamalbashah Assurance Structure Statements of Requirements Technical specification High-Level design Detailed design 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 targeted level of assurance - confirm, determine Lower Levels of Abstraction

7 norshahnizakamalbashah Security Assurance Classes Protection Profile (APE) Security Target (ASE) Maintenance of Assurance (CM) ADV AGD ALC ATE AVA AMA ADO Assurance for production of system

8 norshahnizakamalbashah ASE Security Target Evaluation ASE_INT ASE_CCL ASE_SPD ASE_TSS ASE_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

9 norshahnizakamalbashah Class ASE: Security Target evaluation

10 norshahnizakamalbashah Class ASE Security Target evaluation ASE_INT ASE_CCL ASE_SPD ASE_OBJ ASE_ECD ASE_REQ ASE_TSS E (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 CC ST conform with PP

11 norshahnizakamalbashah 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 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 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 Introduction1

14 norshahnizakamalbashah 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 Introduction1

15 norshahnizakamalbashah 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 Introduction1

16 norshahnizakamalbashah 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 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 claims1

18 norshahnizakamalbashah 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 claims1

19 norshahnizakamalbashah 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 claims1

20 norshahnizakamalbashah 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 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 definition1

22 norshahnizakamalbashah 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 Security objective for the operational environment Security objective for the TOE

23 norshahnizakamalbashah 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 objectives12

24 norshahnizakamalbashah 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 objectives12

25 norshahnizakamalbashah 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 12

26 norshahnizakamalbashah 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 12

27 norshahnizakamalbashah 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 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 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 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 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 Stated security requirementsDerived security requirements

32 norshahnizakamalbashah 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 12

33 norshahnizakamalbashah 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 12

34 norshahnizakamalbashah 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 12

35 norshahnizakamalbashah 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 12

36 norshahnizakamalbashah 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 TOE summary specification with architectural design summary

37 norshahnizakamalbashah Action ASE_TSS.1.1E – The TOE summary specification shall describe how the TOE meets each SFR TOE summary specification (ASE_TSS) ASE_TSS.1.1C TOE summary specification 12

38 norshahnizakamalbashah 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 12

39 norshahnizakamalbashah 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 12

40 norshahnizakamalbashah 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 12

41 norshahnizakamalbashah 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 TOE summary specification (ASE_TSS) ASE_TSS.2-4 TOE summary specification 12