1

Terrie Diaz/Terrie Diaz/

James ArnoldJames Arnold

27 September 2007

Threats, Policies, and Assumptions in the Common Criteria

What is the target of evaluation anyhow?

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 DiazSAIC Accredited Testing & Evaluation Labs

Quality Assurance Director

Terrie.L.Diaz@saic.com

James ArnoldSAIC Accredited Testing & Evaluation Labs

AVP/Technical Director

James.L.Arnold.Jr@saic.com

http://www.saic.com/infosec/common-criteria/