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.commoncriteria.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: User’s 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 Wang’s 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. RainbowSeries • 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.