1 Autumn 2008 TM8104 IT Security Evaluation Guide on the production of Protection Profiles Karin Sallhammar Q2S/NTNU 29/11/2003 Reference: ISO/IEC TR Information technology - Security techniques - Guide on the production of protection profiles and security targets (Editor’s Report)

2 Autumn 2008 TM8104 IT Security Evaluation Outline Introduction The Protection Profile (PP) The development process Guidance on producing a Protection Profile

3 Autumn 2008 TM8104 IT Security Evaluation Definitions and abbreviations DBMS – Database Management System EAL – Evaluation Assurance Level ISO/IEC – ”Common Criteria” OSP – Organisational Security Policies PP – Protection Profile SAR – Security Assurance Requirements SFR – Security Functional Requirements SOF – Strength of Function ST – Security Target TOE – Target of Evaluation TTP – Trusted Third Party

4 Autumn 2008 TM8104 IT Security Evaluation Introduction The purpose of a Protection Profile (PP) is to state a security problem rigorously for a given collection of systems or product – known as Target of Evaluation (TOE) – and to specify implementation-independent security requirement to address that problem. The Guide provides detailed guidance relating to the various parts of a PP or ST, and how they interrelate. In this presentation, I will concentrate on Protection Profiles and NOT Security Targets. However, the guidance for a ST is very similar to the PP guidance.

5 Autumn 2008 TM8104 IT Security Evaluation The Protection Profile (PP)

6 Autumn 2008 TM8104 IT Security Evaluation The development process PPs are often developed in a logical ”top-down” manner 1. define the security concerns 2. identify the security objectives 3. define the IT security requirements During an iterative development process new requirements might surface, due to - new threats may be identified - organisational security policies may change - cost and time constraints may impose changes in division of responsibility between the TOE and its environment - changes in intended attack potential The TOE might be an already developed product – ”bottom-up” approach.

7 Autumn 2008 TM8104 IT Security Evaluation The Protection Profile (PP)

8 Autumn 2008 TM8104 IT Security Evaluation The TOE security environment Purpose: ”define the nature and scope of the definition of the environment in which the TOE is intended to be used and the manner in which it is expected to be employed”

9 Autumn 2008 TM8104 IT Security Evaluation Identify and specify the assumptions ”What assumptions am I making about the TOE security environment and the scope of the security concern?” Aspects relating to the intended usage of the TOE Environmental protection of any part of the TOE Connectivity aspects Personal aspects It is unlikely that you will completely identify all assumptions in a single attempt!

10 Autumn 2008 TM8104 IT Security Evaluation The TOE security environment

11 Autumn 2008 TM8104 IT Security Evaluation Identify and specify the threats ISO/IEC 15408: the PP must contain a description of any threat to the asset against which protection will be required However the statement of threats may be omitted if the security objectives is derived soley from the OSP and assumptions Risk analysis may be an important tool!

12 Autumn 2008 TM8104 IT Security Evaluation Identifying the threats Definition of ”threat” (ISO/IEC 15408): an undesirable event, which is characterised in terms of a threat agent, a presumed attack method, any vulnerabilities that are the foundation for the attack and identification of the asset under attack We need to identify - the assets - the threat agents - the attack methods

13 Autumn 2008 TM8104 IT Security Evaluation Identifying the assets Definition of ”assets” (ISO/IEC 15408): information and resources to be protected by the countermeasures of a TOE Assets typically take the form of information which is stored, processed and transmitted by IT- systems Assets may be external to the TOE (eg. for firewalls)

14 Autumn 2008 TM8104 IT Security Evaluation Identifying the threat agents Threat agents may either be human or non-human To identify human threat agent, consider - who might want to compromise the assets and for what reasons - who could gain access to the IT-system - their possible level of technical expertise, opportunities, resources and motivation Non-human sources of threat and threats unintentionally arising from human sources should also be considered.

15 Autumn 2008 TM8104 IT Security Evaluation Identifying the attack methods Will be based on knowledge about the TOE security environment potential vulnerabilities to the assets which a threat agent could exploit the capabilities of attackers who have access to the TOE security environment A vulnerability analysis of the TOE security environment can be useful. However, it may not identify all vulnerabilities.

16 Autumn 2008 TM8104 IT Security Evaluation Risk analysis Risk analysis may be helpful for threat identification. Such methods may consider The probability and consequence of compromise of the assets, taking into account - the possible attack methods identified - the likelihood of the attack to succeed - the consequences of any damage that may be caused Other constraints, eg. legal requirements and cost

17 Autumn 2008 TM8104 IT Security Evaluation Specifying the threats The specification of threats in a PP should be clear - include the threat agent - include the asset subject to the attack - include the attack method employed Eg: An authorised user of the TOE might gain unauthorized access to information by impersonating another authorised user The specification of threats in a PP should be concise - the threat descriptions should be disjoint - specify all threats at the same level of detail - each threat should be unique labelled for ease of reference

18 Autumn 2008 TM8104 IT Security Evaluation Completing the statement of threats The threats that are of principal interest are those that will be countered by the TOE However, for completeness, the PP may need to include some threats that are not adressed by the TOE, eg - physical attack agains the TOE - abuse of trust by highly privileged users - improper administration and operation of the TOE The PP author can choose whether to include these in the enviromental assumptions or in the statements of threats…

19 Autumn 2008 TM8104 IT Security Evaluation The TOE security environment

20 Autumn 2008 TM8104 IT Security Evaluation Identify and specify the Organisational Security Policies (OSP) An OSP is defined as one or more rules, procedures and practices imposed by an organisation The OSP may be omitted if the security objectives are derived soley from the threats and assumptions Or a combination can be used (but be careful not to restate the same threats) General rule: Specify OSPs where the TOE is intended for use by a specific type of organisation there is a need for the TOE to implement a set of rules that cannot be sensibly included within or implied by a threat description (eg. identification of acces control rules or information flow control rules)

21 Autumn 2008 TM8104 IT Security Evaluation The Protection Profile (PP)

22 Autumn 2008 TM8104 IT Security Evaluation The security objectives The security objectives provide a concise statement of the intended response to the security problem Security objectives for the TOE Security objectives for the environment

23 Autumn 2008 TM8104 IT Security Evaluation Security objectives for the TOE (1)...states what the responsibility of the TOE is in countering the threats and in supporting the OSP. The security objective is intended to be concise. To ”reach” an appropriate level of detail, you need a strict balance between: The security objectives for the TOE should be implementation- independent Ensure that the defined security objectives do not just repeat the information contained within the threats and the OSP When you construct the rationale for the security objectives and the IT security requirements, you will see if you have succeeded..

24 Autumn 2008 TM8104 IT Security Evaluation Security objectives for the TOE (2) Three types of security objective can be identified to address the identified threats: preventive objectives (prevent or limit threats) detective objectives (detect and monitor events) corrective objectives (take action on undesirable events) An example of a preventive security objective is: The TOE will ensure that each user is uniquely identified and that the claimed identity is autheticated, before the user is granted accesss to the TOE facilities.

25 Autumn 2008 TM8104 IT Security Evaluation Security objectives for the environment (1)...will have to be identified to address those aspects of security concerns that the TOE will not (or cannot) be expected to do counter threats that are not countered by the TOE help satisfy OSPs that are not fully satisifed by the TOE ensure that the environmental assumptions are satisfied Eg. non-IT security objective for the environment: objectives for education and training of administrators and users Eg. IT security objective for the environment: a security objective for an underlying operating system to identify and authenticate TOE users.

26 Autumn 2008 TM8104 IT Security Evaluation Security objectives for the environment (2) An appropriate starting point would be to compile a list of security objectives by taking each threat, OSP and assumption that is not fully addressed by the TOE and Add a new security objective for the environment, or If an appropriate one already has been identified, map an existing security object to that aspect The list should be redefined when you formulate the security objectives rationale. The statement of security objective should be reviewed to ensure that the division of responsibilities between the TOE and its environment is appropriate.

27 Autumn 2008 TM8104 IT Security Evaluation The Protection Profile (PP)

28 Autumn 2008 TM8104 IT Security Evaluation The security requirements SFR – identify the requirements for security functions which the TOE must provide to ensure that its security objectives are achieved SAR – identify the required level of assurance in the implementation of the SFRs SR IT-environment – define any functional and assurance requirements to be satisfied by the IT-environment (optional)

29 Autumn 2008 TM8104 IT Security Evaluation Security functional requirements Having defined the security objectives for the TOE in response to the identified security concerns, you need to elaborate how these security objectives are met. This is done by selecting appropriate SFR at a component level. In the selection process it will be helpful to distinguish between principal SFRs – which directly satisfies the identified security objectives for the TOE supporting SFRs – to provide support for the principal SFRs

30 Autumn 2008 TM8104 IT Security Evaluation Selecting SFRs For each security objective for the TOE, identify the principle SFRs which directly satisfy them Once a complete set of principle SFRs has been establish, an iterative process is used to identify a complete set of supporting SFRs. All SFRs should (where possible) be expressed using functional components from Part 2 of ISO/IEC

31 Autumn 2008 TM8104 IT Security Evaluation Identifying supporting SFRs Three stages when identifying the complete set of supporting SFRs Identify the additional SFRs needed to satisfy the dependencies of all principal SFRs Identify any additional SFRs that are necessary to ensure that the security objectives for the TOE are achieved Identify the SFRs needed to satisfy the dependencies of those supporting SFRs selected during stage 2 and 3 (?) This is usually an iterative process! Eg. The PP includes a security objective for the TOE to response on detection of events indicating security violation a principal SFR based on FAU_ARP.1 (Security Alarms) component FAU_ARP.1 has a dependency on FAU_SAA.1 (Potential Violation Analysis) which should also be included as a supporting SFR FAU_SAA.1 has a dependency on FAU_GEN.1 (Audit Data Generation) and so on

32 Autumn 2008 TM8104 IT Security Evaluation Operations on SFRs Permitted operations on SFRs: Assignment – specification of an identified parameter Iteration – multiple use of the same functional component to express different requirements Selection – specification of one or more elements from a given list Refinement – addition of details to the security requirements For ”assignment” and ”selection” the guidance suggest that the operations should be partially completed. The ”iteration” can be used where the clarity of the PP can be enhanched, eg. to break down a complex SFR into distinct functional requirements

33 Autumn 2008 TM8104 IT Security Evaluation Additional advices on SFRs The guide also give advices on: How to specify audit requirements How to specify management requirements How to specify SOF (Strength of Function) How to specify SFRs not included in part 2 of ISO/IEC and so on....

34 Autumn 2008 TM8104 IT Security Evaluation Security Assurance Requirements The selection of SARs will require the balancing if several factors, e.g: the value of the assets to be protected and the perceived risk of compromising those assets technical feasability likely development and evaluation costs perceived market requirement (in the case of products) The selection of the SARs will be relatively straight- forward if choosing an appropriate assurance packet (eg. an EAL). It is possible to include augmented SARs to the packet in order to ensure that the security objectives are satisfied.

35 Autumn 2008 TM8104 IT Security Evaluation Additional advices on SARs The guide also gives advices on: How to perform operations on SARs (iterations and refinements) How to specify SARs not included in Part 3 of ISO/IEC in a PP

36 Autumn 2008 TM8104 IT Security Evaluation Security requirements on the environment.. for meeting the security objectives for the environment. SR on the IT environment. These should be specified, where feasible, using ISO/IEC functional and assurance components SR for the non-IT environment (optional). The guidance did not provide any clear advices (at least to me) on this topic...

37 Autumn 2008 TM8104 IT Security Evaluation The Protection Profile (PP)

38 Autumn 2008 TM8104 IT Security Evaluation PP rationale Purpose: ” to demonstrate that a conformant TOE provides an effective set of IT security countermeasures within the TOE security environment” Security objectives rationale Security requirements rationale

39 Autumn 2008 TM8104 IT Security Evaluation Security objectives rationale First, show that the security objectives are necessary by (eg): Cross-reference the threats, OSPs and assumptions against the security objectives which are intended to adress them. It should be evident that Each security objective covers at least one threat, OSP or asumption Each threat, OSP and assumption is covered by at least one securty objective Secondly, demonstrate that the security objectives are sufficient to meet the security concerns by providing informal arguments to supplement the cross-reference information For each threat, give informal arguments why the identified security objectives will provide for effective countermeasures (detected and recovered, prevented or reduced) towards the threats Similarily, for each identified OSP or assumption, give informal arguments…

40 Autumn 2008 TM8104 IT Security Evaluation Security requirements rationale Show that the IT security requirements (in particular the SFRs) are suitable to meet the identified security objectives and thereby address the security concerns. As with the security objectives, you need to demonstrate that the security requirements are both necessary and sufficient. Cross-reference each security objective for the TOE against the SFR which satisfies it and check that - each SFR addresses at least one security objective - each security objective for the TOE is adressed by at least one SFR Supplement the cross reference-information with informal arguments for the sufficiency.

41 Autumn 2008 TM8104 IT Security Evaluation Security requirements rationale We also need to show that the assurance requirements (SAR) are appropriate for the TOE, ie: sufficient to address the security objectives and thus meet the security concerns not excessive (given the statement of security objectives/concerns) attainable (it should be technically feasible for the TOE to attain the defined assurance requirements) You also have to show that: The strength of functions (SOF) are appropriate The security requirements (in particular the SFRs) are mutually supportive The assurance measures satisfy the assurance requirements (SAR) The IT security functions satisfy the SFRs

42 Autumn 2008 TM8104 IT Security Evaluation The guide also includes PPs for composite and component TOEs Functional packages Assurance packages Appendices - A summary in form of a checklist - Example threats, OSPs, assumptions and security objectives and identifies appropriate ISO/IEC functional components - Special guidance for PPs which implement cryptographic functionality - Application of the guidance in various of contexts, using worked examples for different types of TOE (firewall, DBMS, TTP)

43 Autumn 2008 TM8104 IT Security Evaluation Questions?