CCM 4350 Week 22. Security Architecture and Engineering. Dr A. Lasebae School of Science and Technology CCM4350 1

Transcription

1 CCM 4350 Week 22 Security Architecture and Engineering Dr A. Lasebae School of Science and Technology CCM4350 1

2 Security Evaluation CCM4350 2

3 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. Authorising members: 16 countries CCM4350 3

4 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. CCM4350 4

5 Session contents History Framework for the comparison of criteria The Orange Book ITSec Common Criteria Quality Standards? Summary CCM4350 5

6 Security Evaluation History TCSec (Orange Book): a predefined evaluation classes linking functionality and assurance (USA Defence Dept.) 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) CCM4350 6

7 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 organisational framework for the evaluation process? What is the structure of the evaluation criteria? What are the costs and benefits of evaluation? CCM4350 7

8 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 CCM4350 8

9 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 but costly! Process oriented: check documentation & product development process; cheaper and better for repeatable results. Repeatability and reproducibility often desired properties of an evaluation methodology. CCM4350 9

10 Organisational 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? Happens quite often!!! Contractual relationship between evaluation sponsor, product manufacturer, evaluation facility? Interpretation drift (criteria creep): meaning of criteria may change over time and differ between evaluators. CCM

11 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. CCM

12 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? CCM

13 Orange Book Developed for the national security sector, but intended to be more generally applicable; it 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. CCM

14 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. CCM

15 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. Visit this web site for more information: ftp://ftp.kernel.org/pub/linux/libs/security/orange- Linux/refs/Orange/OrangeI-II-2.html CCM

16 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. TCB- trusted computing base CCM

17 C2: Controlled Access Protection Users individually accountable for their actions. DAC 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 that are specified in the definition of C2. 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. C2-evaluated versions of most major operating systems or database management systems. CCM

18 B1: Labelled Security Protection Division B for products that handle classified data and enforce mandatory MLS 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. Higher assurance: informal or formal model of the security policy. 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. 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. CCM

19 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). 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 operating system. CCM

20 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 minimise 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. CCM

21 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; SCOMP operating system. CCM

22 Rainbow Series The Orange Book is part of a collection of documents on: security requirements, security management, security evaluation published by NSA and NCSC (US National Security Agency and National Computer Security Centre). 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. CCM

23 Information Technology Security Evaluation Criteria ITSEC: harmonisation 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. CCM

24 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. CCM

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. CCM

26 Common Criteria Protection Profile CC Protection Profile PP introduction TOE description TOE security environment Security objectives IT security requirements PP application notes Rationale PP identification PP overview Assumptions Threats Organisational security policies Security objectives for TOE Security objectives for environment TOE security requirements Security requirements For the IT environment Security objectives rationale Security requirements rationale TOE security functional requirements TOE security assurance requirements CCM

27 CC Assurance Levels EAL1 - functionally tested EAL2 - structurally tested EAL3 - methodically tested and checked EAL4 - methodically designed, tested, and reviewed EAL5 - semiformally designed and tested EAL6 - semiformally verified design and tested EAL7 - formally verified design and tested CCM

28 Assurance Levels EAL1: tester receives the target of evaluation, examines the documentation and performs some tests to confirm the documented functionality; evaluation should not require any assistance from the developer; the outlay for evaluation should be minimal. EAL2: developer provides test documentation and test results from a vulnerability analysis; evaluator reviews documentation and repeats some of these tests; effort required from the developer is small and a complete development record need not be available. CCM

29 Assurance Levels EAL3: developer uses configuration management, documents security arrangements for development, and provides high-level design documentation and documentation on test coverage for review; EAL3 intended for developers who already follow good development practices but do not want to implement further changes to their practices. EAL4: developer provides low-level design and a subset of security functions (TCB) source code for evaluation; secure delivery procedures; evaluator performs an independent vulnerability analysis. Usually EAL4 is the highest level that is economically feasible for an existing product line. CCM

30 Assurance Levels EAL5: developer provides formal model of the security policy, a semiformal high-level design, functional specification, and the full source code of the security functions; covert channel analysis; evaluator performs independent penetration testing. TOE should have been designed and developed with the intent of achieving EAL5 assurance; additional evaluation costs ought not to be large. EAL6: source code well structured, reference monitor must have low complexity; evaluator conducts more intensive penetration testing; cost of evaluation expected to increase. CCM

31 Assurance Levels EAL7: developer provides a formal functional specification and a high-level design, demonstrates correspondence between all representations of the security functions. EAL7 typically only achieved with a TOE that has a tightly focused security functionality and is amenable to extensive formal analysis. CCM

32 CC Evaluated Operating Systems EAL4: Sun Solaris (TM) 8 Operating Environment EAL4: HP-UX (11i) Version EAL4+: AIX 5L for POWER V5.2 Programm Number 5765-E62 EAL3: SGI Trusted IRIX/CMW Version EAL4+: Windows 2000 Professional, Server, and Advanced Server with SP3 and Q Hotfix EAL4: B1/EST-X Version with AIX, Version EAL4: Sun Trusted Solaris Version 8 4/01 EAL4+: Windows 2000 Professional, Server, and Advanced Server with SP3 and Q Hotfix (OS) EAL3: SGI IRIX/CMW Version CCM

33 Windows 2000 Certification Certified Configurations Controlled Access Protection Profile (CAPP) Equivalent to C2 Functional Requirements Covers network operating system functionality Multi-Master Directory Service Active Directory L2TP/IPSEC-Base VPN Windows 2000 Professional VPN Client Windows 2000 Server VPN Services Single Sign-on Other Services Kerberos TLS Software Signature Creation Device Sensitive Data Protection Device (EFS) Network Management Flaw Remediation (MSRC) Desktop management DNS/DHCP Servers CCM

34 Evaluation Methodology Common Evaluation Methodology (CEM) specifies all the steps that have to be followed when validating the assurance requirements in a Security Target. Common Criteria Recognition Agreement (CCRA) provides recognition of evaluations performed in another country; addresses assurance levels EAL1 to EAL4; higher assurance levels are only accepted within a single country. Common Criteria Evaluation and Validation Scheme (CCEVS): national US program for performing security evaluations according to the Common Criteria. CCM

35 Quality Standards Ultimate step towards audit-based evaluation: assess how a product is developed but not the product itself. A company would become a certified producer of secure systems. This approach is popular in the area of quality control: organisations follow the ISO 9000 standard on internal quality management and external quality assurance to vouch for the quality of their products. Some vendors claim that being registered under an ISO 9000 quality seal is a better selling argument than a security certificate for a particular product and that security evaluation should move in this direction. CCM

36 Quality Standards Such a proposal is attractive for companies developing secure systems: the costs of evaluation are much reduced. If the developers of secure systems win in this proposal, will the users of secure systems lose out? This is not a foregone conclusion; certificate is no guarantee that a system cannot be broken. You have to assess each evaluation scheme on its own merits to decide whether individually evaluated products offer more security than products from accredited developers. CCM

37 Summary Security evaluation has been required in some countries by public sector customers. Major O/S and DBMS vendors offer evaluated products. Outside the government sector there has been little enthusiasm for evaluated products. One current exception: smart card software. Persistent problem: products keeps evolving so evaluation often refers to a version no longer in use. CCM