Terrie Diaz/ James Arnold 27 September 2007

1. Threats, Policies, and Assumptions in the Common CriteriaWhat is the target of evaluation anyhow? Terrie Diaz/ James Arnold 27 September 2007

2. Topics • Introduction • Approaches and philosophies in describing the security problems • Reuse of and sources of security problem statements; • Proper construction of security problem statements, • specification of threat agents, assets, methods, etc.; • When to use threats vs. organizational security policies; • Emphasis on the security problems directly addressed by the product (described in the ST); and • Handling of security problems only partially addressed by the product • Recommendations and Conclusions Note that the presentation was developed in accordance with Common Criteria version 3.1, but it applies equally to version 2.X as well.

3. Introduction • Security Problem Definition (a.k.a) Security Environment in CCv2.X • Top level statement of the problems to be solved • Threats • Organizational security policies • Assumptions • Security Objectives • Top level statement of how the security problems will be addressed • TOE • Environment • IT Environment distinguished only in CCv2.X

4. Introduction • Different approaches and philosophies in describing the security problems. • Problems addressed by the TOE, introduced by the TOE, related to evaluation of the TOE, and to be addressed outside the TOE • Abstract and general to very detailed and specific • Minimal set of brief statements to a very extensive collection of statements • This presentation will examine security problem presentations and offer recommendations that could help to make security problem statements more consistent in the future.

5. Approaches and philosophies in describing the security problems • Identification of Security Problem • CC intends the security problem to precede the TOE • However, Security Targets are often created from the bottom up • We know what the TOE does and hence the requirements it can satisfy • Those requirements are abstracted into objectives and then security problem statements • The result is often that the security problem tends to lose focus as it strays away from what the TOE was created to solve and into problems related to the TOE itself or its environment, for example • “An administrator’s intentions may become malicious resulting in user or TSF data being compromised” (Medium Robustness Traffic Filter Firewall PP)

6. Approaches and philosophies in describing the security problems • Subjects of Security Problems • The target of the TOE – the TOE was created to solve some security problem and those problems • Primary purpose of the TOE • Must always be represented in the security problem definition • Example • “An unauthorized person may send impermissible information through the TOE which results in the exploitation of resources on the internal network” (Medium Robustness Application Firewall PP) • “A private or secret key is improperly disclosed” (Certificate Issuing and Management Components PP)

7. Approaches and philosophies in describing the security problems • Subjects of Security Problems • The TOE – the TOE brings its own security problems that either it or its environment must solve (e.g., protect itself from tampering) • Secondary purpose of the TOE • Should not be included in the security problem definition • Can be introduced in the form of objectives for the TOE that map to the primary purpose of the TOE • Example • An administrator may incorrectly install or configure the TOE resulting in ineffective security mechanisms

8. Approaches and philosophies in describing the security problems • Subjects of Security Problems • The evaluation of the TOE – while the TOE solves some security problems (as indicated above) there is the issue of the level of assurance it has in so doing • Note that the CC does not require the tracing of assurance requirements to objectives or security problems • Should not be included in the security problem definition • The assurance requirement rationale should address the selection of assurance requirements • Hypothetically the problems addressed by the CC-defined assurance requirements should be fixed and should not be left to be recreated within each Security Target • Example • “Lack of or insufficient tests to demonstrate that all TOE security functions operate correctly (including in a fielded TOE) may result in incorrect TOE behavior being undiscovered thereby causing potential security vulnerabilities” (Consistency Instruction Manual)

9. Approaches and philosophies in describing the security problems • Subjects of Security Problems • The TOE environment – there are security problems that are not addressed by the TOE and are left to be addressed elsewhere • With the exclusion of IT environment objectives in CCv3.1, these should no longer occur • Some historical cases where an overall problem was defined only to show that the TOE fits into the solution by addressing part of the problem while leaving the rest to something else • Example • “A hacker physically interacts with the system to exploit vulnerabilities in the physical environment, resulting in arbitrary security compromises” (Certificate Issuing and Management Components PP)

10. Approaches and philosophies in describing the security problems • The statement of the environment should be a concise statement of the problem being solved by the TOE • Threats • The threats should be based on product type • Certain products imply certain threats • The threats should be limited to the purpose of the TOE • Should not include any threats that would not exists in the absence of the TOE • Self-serving assertions distract the reader

11. Approaches and philosophies in describing the security problems (continued) • Organizational Security policies • Rules, procedures, practices, or guidelines imposed by an organization upon its operations • Example of how the TOE is intended to work • The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by accessing the system. Reference: DODI 8500.2 • Example of out of scope • Must be FIPS certified or CC evaluated • Assumptions • Constrain the evaluation • Articulate elements the TOE requires to fulfill its claims • Connectivity - e.g. interactions with other products • Personnel – e.g. the users that are managing the functions of the TOE as well as the users that using the functions of the TOE • Physical – e.g. a requirement for a backup power supply

12. Reuse of and sources of security problem statements • Validated Protection Profiles • Claim conformance • Borrow content for related technology • NSA PP Development Consistency Guides • Validated Security Targets • Borrow content for related technology • Composite TOE • PPs and Consistency Guides suffer from including problems about the TOE, its evaluation, and its environment. • STs suffer from general inconsistency.

13. Security Problem Definition • Threats to assets which specific protection within the TOE or its environment is required • Threats of Disclosure • Threats to Integrity • Threats to Service • Organizational Security Policies are imposed by the organization controlling the operational environment of the TOE • Rules, process, procedures, standard • Assumptions about the operating environment in which the TOE will be used • Placed on the operational environment • Derived from knowledge of the product and how it is intended to be used

14. Threats • Threat elements • Agent is the entity that can adversely act on assets • Human entity • Employee • Non-employee • Computer Processes • Method of attack • Network • Abuse of privileges • Physical • Asset • TSF Data • User Data • In storage • On the network • Resources • Files

15. Organizational Security Policy • Rules, procedures, or guidelines that are currently imposed or will be by an actual organization or a hypothetical organization. • CCEVS disallowed OSPs when the organization could not be identified with the policy • CCv3.1 allows hypothetical policies • Imposed by the controlling organization or by legislative or regulatory bodies • OSPs can be levied against the TOE or the operational environment, for example • Access Control • Management • Password generation • Encryption

16. When to use threats vs. organizational security policies • In many cases OSP and threat can be interchanged, but there are exceptions where a policy cannot readily become a threat • All products used by the Government must conform to the National Standard for password generation and encryption • In reality OSP and threat are two different abstractions since there can be no threats without first having some policies (at least implied) • OSP - Only users with system administrator privilege and clearance of Department Secret shall be allowed to manage the Department fileserver. • Threat – An unprivileged or uncleared user could take control of the fileserver

17. Assumptions • Identify the things outside the TOE control that the TOE depends on • Physical Assumptions • Restricted access area • Minimize electromagnetic emanations • Personnel Assumptions • Users will be sufficiently trained • Users are approved to have access to the level of information • Connectivity Assumptions • Will not be connected to an untrusted network • Requirement of disk space • Application host requirement • Location

18. Emphasis on the security problems directly addressed by the product (described in the ST) • Security Objectives are a concise and abstract statement of the intended solution to the defined problem • Delving into a complete solution that addresses the problem(s) as well as protecting the solution • Solutions should be focused and minimal • Primary Function • Reason product was developed • Most important function • Protect Primary Function • If primary function not protected, it could fail • Manage Primary Function • Can all be traced to the real purpose of the TOE

19. Handling of security problems only partially addressed by the product • The operational environment implements measures to assist the TOE in providing its security functionality • Protect Functions • Manage Functions • Supports the TOE security functions • e.g. cryptographic operations

20. Recommendations and Conclusions • Consistent security problem statements • Abstract as possible while still representing the problem • Focus on the problem to be solved; minimum set necessary to represent the problem • Expand the solution into security objectives to represent a complete solution

21. Contact Terrie Diaz SAIC Accredited Testing & Evaluation Labs Quality Assurance Director Terrie.L.Diaz@saic.com James Arnold SAIC Accredited Testing & Evaluation Labs AVP/Technical Director James.L.Arnold.Jr@saic.com http://www.saic.com/infosec/common-criteria/