Computer Security Security Evaluation

1
Computer SecuritySecurity Evaluation
2
Security Evaluation

• How do you get assurance that your computer
  systems are adequately secure?
• You could trust your software providers.
• You could check the software yourself, but you
  would have to be a real expert.
• You could rely on an impartial security
  evaluation by an independent body.
• Security evaluation schemes have evolved since
  the 1980s currently the Common Criteria are used
  internationally.

3
Objectives

• Examine the fundamental problems any security
  evaluation process has to address.
• Propose a framework for comparing evaluation
  criteria.
• Overview of the major evaluation criteria.
• Assess the merits of evaluated products and
  systems.

4
Agenda

• History
• Framework for the comparison of criteria
• Orange Book
• ITSEC
• Federal Criteria
• Common Criteria
• Quality Standards?
• Summary

5
Security Evaluation History

• TCSEC (Orange Book) criteria for the US defense
  sector, predefined evaluation classes linking
  functionality and assurance
• ITSEC European criteria separating functionality
  and assurance so that very specific targets of
  evaluation can be specified and commercial needs
  can better addressed
• TCSEC and ITSEC no longer in use replaced by the
  
• Common Criteria (CC) http//www.commoncriter
  ia.org/, http//niap.nist.gov/cc-scheme

6
Framework for Security Evaluation

• What is the target of the evaluation?
• What is the purpose of an evaluation?
• What is the method of the evaluation?
• What is the organizational framework for the
  evaluation process?
• What is the structure of the evaluation criteria?
• What are the costs and benefits of evaluation?

7
Target Purpose

• Target of evaluation
• Product off-the-shelf software component to be
  used in a variety of applications has to meet
  generic security requirements
• System collection of products assembled to meet
  the specific requirements of a given application
• Purpose of evaluation
• Evaluation assesses whether a product has the
  security properties claimed for it
• Certification assesses suitability of a product
  (system) for a given application
• Accreditation decide to use a certain system

8
Method

• Evaluations should not miss problems, different
  evaluations of the same product should give the
  same result.
• Product oriented examine and test the product
  better at finding problems.
• Process oriented check documentation product
  development process cheaper and better for
  repeatable results.
• Repeatability and reproducibility often desired
  properties of an evaluation methodology.

9
Organizational Framework

• Public service evaluation by government agency
  can be slow, may be difficult to retain qualified
  staff.
• Private service evaluation facilities usually
  accredited by a certification agency.
• How to make sure that customer pressure does not
  influence evaluation results?
• Contractual relationship between evaluation
  sponsor, product manufacturer, evaluation
  facility?
• Interpretation drift (criteria creep) meaning of
  criteria may change over time and differ between
  evaluators.

10
Structure

• Structure of evaluation criteria
• Functionality security features
• Effectiveness are mechanisms used appropriate
• Assurance thoroughness of analysis
• Orange Book evaluation classes for a given set
  of typical DoD requirements, consider all three
  aspects simultaneously.
• ITSEC flexible evaluation framework that can
  deal with new security requirements the three
  aspects are addressed independently.

11
Costs and Benefits

• Direct costs fees paid for evaluation.
• Indirect costs employee time, training
  evaluators in the use of specific analysis tools,
  impact on development process.
• When evaluating a product, the cost of evaluation
  may be spread over a large number of customers.
• Benefits evaluation may be required, e.g. for
  government contracts marketing argument better
  security?

12
Orange Book

• Developed for the national security sector, but
  intended to be more generally applicable
  provides
• a yardstick for users to assess the degree of
  trust that can be placed in a computer security
  system,
• guidance for manufacturers of computer security
  system,
• a basis for specifying security requirements when
  acquiring a computer security system.
• Security evaluation of the Trusted Computing Base
  (TCB), assumes that there is a reference monitor.
• Developed for systems enforcing multi-level
  security.
• High assurance linked to formal methods, simple
  TCBs, and structured design methodologies
  complex systems tend to fall into the lower
  evaluation classes.

13
Evaluation Classes

• Designed to address typical security
  requirements combine security feature and
  assurance requirements
• Security Policy mandatory and discretionary
  access control
• Marking of objects labels specify the
  sensitivity of objects
• Identification of subjects authentication of
  individual subjects
• Accountability audit logs of security relevant
  events
• Assurance operational assurance refers to
  security architecture, life cycle assurance
  refers to design methodology, testing, and
  configuration management
• Documentation users require guidance on
  installation and use evaluators need test and
  design documentation
• Continuous Protection security mechanisms cannot
  be tampered with.

14
Security Classes

• Four security divisions
• D Minimal Protection
• C Discretionary Protection (need to know)
• B Mandatory Protection (based on labels)
• A Verified Protection
• Security classes defined incrementally all
  requirements of one class automatically included
  in the requirements of all higher classes.
• Class D for products submitted for evaluation
  that did not meet the requirements of any Orange
  Book class.
• Products in higher classes provide more security
  mechanisms and higher assurance through more
  rigorous analysis.

15
C1 Discretionary Security Protection

• Intended for environments where cooperating users
  process data at the same level of integrity.
• Discretionary access control based on individual
  users and/or groups.
• Users have to be authenticated.
• Operational assurance TCB has its own execution
  domain features for periodically validating the
  correct operation of the TCB.
• Life-cycle assurance testing for obvious flaws.
• Documentation Users Guide, Trusted Facility
  Manual (for system administrator), test and
  design documentation.

16
C2 Controlled Access Protection

• Users individually accountable for their actions.
  
• DAC is enforced at the granularity of single
  users.
• Propagation of access rights has to be controlled
  and object reuse has to be addressed.
• Audit trails of the security-relevant events have
  to be kept.
• Testing and documentation covers the newly added
  security features testing for obvious flaws
  only.
• C2 was regarded to be the most reasonable class
  for commercial applications.
• Most major vendors offer C2-evaluated versions of
  their operating systems or database management
  systems.

17
B1 Labelled Security Protection

• Division B for products that handle classified
  data and enforce mandatory Bell-LaPadula policies
  (based on security labels).
• Class B1 for system high environments with
  compartments.
• Issue export of labelled objects to other
  systems or a printer e.g. human-readable output
  has to be labelled.
• To achieve a higher level of assurance an
  informal or formal model of the security policy
  is needed.
• Design documentation, source code, and object
  code have to be analysed all flaws uncovered in
  testing must be removed.
• No strong demands on the structure of the
  TCB---hence multilevel secure Unix systems or
  data managemnnet systems have received B1 rating
• B1 rating for System V/MLS (from AT T),
  operating systems from Hewlett Packard, DEC, and
  Unisys database management systems Trusted
  Oracle 7, INFORMIX-Online/Secure, Secure SQL
  Server.

18
B2 Structured Protection

• Class B2 increases assurance by adding design
  requirements.
• MAC governs access to physical devices.
• Users notified about changes to their security
  levels.
• Trusted Path for login and initial
  authentication.
• Formal model of the security policy and a
  Descriptive Top Level Specification (DTLS) are
  required.
• Modularization as an important architectural
  design feature.
• TCB provides distinct address spaces to isolate
  processes.
• Covert channel analysis required events
  potentially creating a covert channel have to be
  audited.
• Security testing establishes that the TCB is
  relatively resistant to penetration.
• B2 rating for Trusted XENIX (MS) operating system
  (which incorporates the Bell-LaPadula model for
  multilevel security).

19
B3 Security Domain

• B3 systems are highly resistant to penetration.
• New requirements on security management support
  for a security administrator auditing mechanisms
  monitor the occurrence or accumulation of
  security relevant events and issue automatic
  warnings.
• Trusted recovery after a system failure.
• More system engineering efforts for to minimize
  the complexity of the TCB.
• A convincing argument for the consistency between
  the formal model of the security policy and the
  informal Descriptive Top Level Specification.
• B3 rating for versions of Wangs XTS-300 (and
  XTS-200) operating system.

20
A1 Verified Design

• Functionally equivalent to B3 achieves the
  highest assurance level through the use of formal
  methods.
• Evaluation for class A1 requires
• a formal model of the security policy
• a Formal Top Level Specification (FTLS),
• consistency proofs between model and FTLS
  (formal, where possible)
• TCB implementation (in)formally shown to be
  consistent with the FTLS formal covert channels
  analysis continued existence of covert channels
  to be justified, bandwidth may have to be
  limited.
• More stringent configuration management and
  distribution control.
• A1 rating for network components MLS LAN (from
  Boeing) and Gemini Trusted Network Processor
  Secure Communications Protocol (SCOMP) operating
  system (predecessor of XTS-300).

21
Rainbow Series

• The Orange Book is part of a collection of
  documents on security requirements, security
  management, and security evaluation published by
  NSA and NCSC (US National Security Agency and
  National Computer Security Center).
• The documents in this series are known by the
  colour of their cover as the rainbow series.
• Concepts introduced in the Orange Book adapted to
  the specific aspects of computer networks
  (Trusted Network Interpretation, Red Book) of,
  database management systems (Trusted Database
  Management System Interpretation, Lavender/Purple
  Book) etc.

22
ITSEC

• Information Technology Security Evaluation
  Criteria (ITSEC) harmonization of Dutch,
  English, French, and German national security
  evaluation criteria endorsed by the Council of
  the European Union in 1995.
• Builds on lessons learned from using the Orange
  Book intended as a framework for security
  evaluation that can deal with new security
  requirements.
• Breaks the link between functionality and
  assurance.
• Apply to security products and to security
  systems.
• The sponsor of the evaluation determines the
  operational requirements and threats.

23
ITSEC

• The security objectives for the Target of
  Evaluation (TOE) further depend on laws and
  regulations they establish the required security
  functionality and evaluation level.
• The security target specifies all aspects of the
  TOE that are relevant for evaluation security
  functionality of the TOE, envisaged threats,
  objectives, and details of security mechanisms to
  be used.
• The security functions of a TOE may be specified
  individually or by reference to a predefined
  functionality class.
• Seven evaluation levels E0 to E6 express the
  level of confidence in the correctness of the
  implementation of security functions.

24
US Federal Criteria

• Evaluation of products, linkage between function
  and assurance in the definition of evaluation
  classes.
• Protection profiles to overcome the rigid
  structure of the Orange Book five sections of a
  protection profile
• Descriptive Elements name of protection
  profile, description of the problem to be
  solved.
• Rationale justification of the protection
  profile, including threat, environment, and usage
  assumptions, some guidance on the security
  policies that can be supported.
• Functional Requirements protection boundary that
  must be provided by the product.
• Development Assurance Requirements.
• Evaluation Assurance Requirements type and
  intensity of the evaluation.

25
Common Criteria

• Criteria for the security evaluation of products
  or systems, called the Target of Evaluation
  (TOE).
• Protection Profile (PP) a (re-usable) set of
  security requirements, including an EAL should
  be developed by user communities to capture
  typical protection requirements.
• Security Target (ST) expresses security
  requirements for a specific TOE, e.g. by
  reference to a PP basis for any evaluation.
• Evaluation Assurance Level (EAL) define what has
  to be done in an evaluation there are seven
  hierarchically ordered EALs.