1 terrie diaz/ james arnold 27 september 2007 threats, policies, and assumptions in the common...
Post on 21-Dec-2015
213 Views
Preview:
TRANSCRIPT
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/
top related