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):
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 Rainbow SeriesRainbow 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 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.