1. 1 Lecture 8 Security Evaluation

2. 2 Contents u Introduction u The Orange Book u TNI-The Trusted Network Interpretation u Information Technology Security Evaluation Criteria u The Common Criteria u Security Analysis

3. 3 What is an Evaluation? u Independent Verification and Validation (IV&V) by an accredited and competent Trusted Third Party u Provides a basis for international Certification against specific formal standards (i.e. CC) by national authorities

4. 4 Evaluation Process Assurance Techniques Independent Evaluations Assurance Produceprovide formal evidence of Privacy Requirements that are Properly Managed Privacy Rights to protect Information Asset Owners Confidence require giving

5. 5 The target of the evaluation u Products, e.g., operating systems, which will be used in a variety of applications and have to meet the generic security requirements. u Systems, i.e., a collection of products assembled to meet the specific requirements of a given application.

6. 6 The purpose of the evaluation u Evaluation: assessing whether a product has the security properties claimed for it. u Certification: assessing whether a product is suitable for a given application. u Accreditation: deciding that a product will be used in a given application.

7. 7 The method of the evaluation u A method must prevent from: u The product is later found to contain a serious flaw u Different evaluations of the same product disagree in their assessment u Product-Oriented: u Examine and test the product. u Different evaluations may give different results. u Process-Oriented: u Look at the documentation and the process of product development. u Easier to achieve repeatable results, but may not be very useful

8. 8 The structure of the evaluation criteria u Functionality: u The security features of a system, e.g., DAC (Discretionary), MAC (Mandate), authentication, auditing u Effectiveness: u The mechanisms used appropriate for the given security requirements? u Assurance: u The thoroughness of the evaluation

9. 9 Organizations of the evaluation process u Government agency: backs the evaluation process and issues the certification u Accredited private enterprise: enforce the consistency of evaluations (repeatability and reproducibility)

10. 10 What Do CC Evaluations Give Us?-Benefits u Confidence & Trust in privacy and security characteristics of products and the processes used to develop and support them (full product life cycle) u Build official assurance arguments u Prove technologies are indeed privacy enhancing as claimed u formal, independently verifiable and repeatable methods u Provide basis for international certification u Provide Certification Report u Differentiate products u Formally support demonstrable due diligence/care

11. 11 The costs of evaluation u Costs: u Fee paid to evaluation; u Time to collect required evidences u Time and money of training of evaluators u Time and efforts of liaising with the evaluation team

12. 12 The Orange Book u Trusted Computer Security Evaluation Criteria (1985) u A yardstick for users to assess the degree of trust that can be placed in a computer security systems; u Guidance for manufacturers of computer security systems; u A basis for specifying security requirements when acquire a computer security system

13. 13 Security and evaluation categories u Security policy: u mandatory and discretionary access control policies expressed in terms of subjects and objects u Marking of objects: u Labels specify the sensitivity of objects u Identification of subjects: u Individual subjects must be identified and authenticated u Accountability: u audit logs of security relevant events have to be kept.

14. 14 Security and evaluation categories (Cont’d) u Assurance: u Operational: architecture u Life cycle: design, test, and configuration management u Documentation: u Required by system managers, users and evaluators u Continuous protection: u Security mechanisms cannot be tampered with.

15. 15 Four security divisions u D: Minimal protection u C: Discretionary protection u B: Mandatory protection u A: Verified protection

16. 16 Orange Book Ratings u D: Minimal Protection u Did not qualify for higher u C1: Discretionary Security Protection u Resources protected by ACLs, memory overwrites prevented u C2: Controlled Access Protection u Access control at user level, clear memory when released u B1: Labeled Security Protection u Users, files, processes, etc, must be labeled u B2: Structured Security Protection u Big step, covert channels, secure kernel, etc. u B3: Security Domains u Auditing, secure crash u A1: Verified Design u Same requirements, more rigorous implementation

17. 17 TNI-The Trusted Network Interpretation-The Red Book u Two kinds of networks u Networks of independent components, with different jurisdictions, policies, management, etc. u Centralized networks with single accredited authority, policy and network trusted computing base u The red book only considers the 2 nd type. u The vulnerability of the communication paths u Concurrent and asynchronous operation of the network components

18. 18 Red book Policy u Security policies deal with secrecy and integrity. u Node names as DAC group identifiers in C1 u Audit trails should log the user of cryptographic keys. u In the red book, integrity refers to u The protection of data and labels against unauthorized modification u The correctness of message transmission, authentication of source and destination of a message. u Labels indicate whether an object had ever been transmitted between nodes

19. 19 Other Security Services in the Red Book u Describe Services u Functionality u Strength: how well it is expected to meet its objective u Assurance: derived from theory, testing, SE practice, validation and verification. u Rating u None u Minimum (C1) u Fair(C2) u Good (B2) u Not offered - present

20. 20 Services in the red book u Communication integrity u Authentication u Communication field integrity u Non-repudiation u Denial of Service u Continuity of operation u Protocol-based protection u Network management u Compromise protection u Data confidentiality u Traffic confidentiality

21. 21 Windows NT security rating u Windows NT is only secure for such purposes (e.g. - "C2 Certified") if: u Run the particular Compaq or Digital hardware models specified by NIST, u Run the particular version of Windows NT (3.50) specified by NIST, u Remove the floppy drive from the computer, and u Remove network connectivity, and u Configure Windows NT as specified by NIST.

22. 22 UNIX security rating u The Unix system is only as secure as the C1 criterion u provides only discretionary security protection (DSP) against browsers or non-programmer users u AT&T, Gould and Honeywell made vital changes to the kernel and file system in order to produce a C2 rated Unix operating system. u Have to sacrifice some of the portability of the Unix system. It is hoped that in the near future a Unix system with an A1 classification will be realized, though not at the expense of losing its valued portability. u http://secinf.net/unix_security/Unix_System_S ecurity_Issues.html

23. 23 ITSEC: Information Technology Security Evaluation Criteria u A harmonized European criteria refers to (1991) u Effectiveness: how well a system is suited for countering the threats envisaged. u And correctness: assurance aspects relating to the development and operation of a system.

24. 24 The Evaluation Process u TOE (Target of Evaluation) u An IT system, part of a system or product that has been identified as requiring security evaluation; ie, that which is being evaluated. u A Target of Evaluation (TOE) is the specific IT product or system that is subject to evaluation. u It is particularly relevant to, and part of the standard terms within, Common Criteria and ITSEC. u A Security Target (ST) contains the IT security objectives and requirements as pertaining to a specific target of evaluation with the definition of its functional and assurance measures. u http://www.itsecurity.com/papers/border.htm

25. 25 Security target u All aspects of the TOE that are relevant for evaluation u Security objectives u Statements about the system environment u Assumptions about the TOE environment u Security functions u Rationale for security functions u Required security mechanisms u Required evaluation level u Claimed rating of the minimum strength of mechanisms u http://www.rycombe.com/itsec.htm http://www.rycombe.com/itsec.htm u Definition (Matt Bishop, 2003): u A security target is a set of security requirements and specifications to be used as the basis for evaluation of an identified product or system.

26. 26 Security Functionality u Security functionality description: u Security objectives: u Why is the functionality wanted? u Security functions: u What is actually done? u Security mechanisms: u How is it done?

27. 27 Security functions in ITSEC u Identification and authentication u Access control u Accountability: record the exercise of rights u Audit: detect and investigate events that might represent threats to security u Object reuse u Accuracy: correctness and consistency of data u Reliability: consistency and availability of service u Data exchange: referring to the International standard ISO 7498-2

28. 28 Security rating in ITSEC u F1: C1 Discretionary security protection u F2: C2 Controlled Access Protection u F3: B1 Labeled Security Protection u F4: B2 Structured Protection u F5: B3 & A1 Security domain and verified design u F6: high integrity u F7: high availability u F8: data integrity during communication u F9: for high confidentiality (cryptographic devices) u F10: for networks with high demands on confidentiality and integrity

29. 29 Assurance of Effectiveness u An assessment of effectiveness should examine u Suitability of functionality u Binding of functionality (compatibility) u Strength of mechanism u Ease of use u Assessment of security vulnerabilities within the construction of the TOE, e.g., ways of bypassing or corrupting security enforcing functions u Assessment of security vulnerabilities within the operation of the TOE.

30. 30 Assurance of Correctness u Seven levels E0-E6 specify the list of documents that have to be provided by the sponsor and the actions to be performed by the evaluator. u Development Process: u Following the stages of a top-down methodology, security requirements, architectural design, detailed design, and implementation are considered. u Development evaluation: u includes configuration control and, from class E2 upwards, developer security, e.g., the confidentiality of documents association. u Operation: u Refers to operational document, including delivery, configuration, star-up and operation.

31. 31 Seven Evaluation classes u E0: fail u E1:a security target and an informal description of the target u E2:+informal description of detailed design, configuration control and a controlled distribution process u E3: + a detailed design and the source code corresponding to the security functions shall be provided u E4: formal model of the security policy; rigorous approach and notation for architectural and detailed design, vulnerability analysis u E5: close correspondence between detailed design and source code, vulnerability based on source code u E6: formal description of the security architecture of the TOE, consistent formal model of security policy, possible to relate portions of the executable form of TOE to the source code

32. 32 Correspondence between Orange Book and ITSEC OBITSEC DE0 C1F1+E1 C2F2+E2 B1F3+E3 B2F4+E4 B3F5+E5 A1F5+E6

33. 33 Common Criteria ISO 15408 u International ISO IT Security standard for formally specifying IT Security Requirements and how these are to be independently evaluated and tested so products may be formally certified as being trustworthy (1991) u 3-Part Standard, plus evaluation methodology u http://www.corsec.com/ccc_faq.php

34. 34 CC Evaluations Involve: u ANALYSIS u Product Documentation u Product Design (Security & Privacy Focus) u Development Processes & Procedures u Operation & Administration Guidance and Procedures u Vulnerability Assessments u TESTING u Independent & Witnessed u Fully Documented & Repeatable u REPORTS u Lead to International Certification

35. 35 Types of Common Criteria evaluations u Categories of Evaluations * Typically as the first step in an EAL. Protection Profile *Security Target Evaluation Assurance Levels (EALs)

36. 36 Scope u Interviews u Full Documentation Review u Independent Testing u Witness of Developer Testing u Observation Reports When Required u Deliverables: u Security/Privacy Target or Protection Profile u Evaluation Technical Report u Certification Report (published by CSE, and recognized by NSA and other Certification Bodies)

37. 37 Protection Profiles u A Protection Profile (PP) is an implementation- independent statement of security requirements that is shown to address threats that exist in a specified environment. u A PP would be appropriate in the following cases: u A consumer group wishes to specify security requirements for an application type u A government wishes to specify security requirements for a class of security products u An organization wishes to purchase an IT system to address its security requirements u A certified protection profile is one that a recognized Certification Body asserts as having been evaluated by a laboratory competent in the field of IT security evaluation to the requirements of the Common Criteria and Common Methodology for Information Technology Security Evaluation.

38. 38 The evaluation process Documentation Preparation ------------------- Vendor Consultant Develop Security Target -------------------- Vendor Consultant or Lab Conduct Evaluation -------------------- Lab Vendor NIAP CCEVS NIAP Issues Certificate -------------------- NIAP CCEVS u Work not necessarily performed by the CCTL: u Documentation preparation u Writing the Security Target u Other consulting u Evaluations must be performed by lab personnel CCTL: Common Criteria Test Labs CCEVS ( Common Criteria Evaluations ) The National Information Assurance Partnership (NIAP) is the governing body for all CCTLs in the U.S.

39. 39 Required evaluation materials u Security Target u TOE (target of evaluation) u Configuration Management documentation u Functionality Specification u High and low level design documentation u User and Administrator’s guides u Life-cycle documentation u Development tool documentation u Security Policy model u Correspondence analyses u Installation and start-up procedures u Delivery procedures

40. 40 Steps in the evaluation process Evaluation assurance levels (EAL)

41. 41 Results of the evaluation process u Outcomes of Common Criteria Testing u In U.S. this follows approval of lab test results u Public posting of ST, validation report, and certificate Validation Certificate

42. 42 How the Process Works 1. Privacy (and security) requirements for a technology and associated claims are precisely specified using the CC 2. Technology is built, documented and tested to these requirements 3. Technology is submitted to nationally accredited labs for evaluation against the standards 4. Evaluation is conducted under the oversight of national authority

43. 43 Process (Continued) 5. Once vendor claims are proven, national authority confers certification and publishes a Certification Report 6. Results are internationally recognized under a Mutual Recognition Arrangement

44. 44 Evaluation assurance levels (EAL) u To meet the great variation in required levels of security within and between both government and commercial interests, there are seven levels of evaluation (EAL-1 through EAL-7). u Only the first four levels can be evaluated by commercial laboratories.

45. 45 EAL (Cont’d) u EAL-1 examines the product and its documentation for conformity, establishing that the Target does what its documentation claims. u EAL-2 tests the structure of the product through an evaluation, which includes the product’s design history and testing. u EAL-3 evaluates a product in design stage, with independent verification of the developer’s testing results, and evaluates the developer’s checks for vulnerabilities, the development environmental controls, and the Target’s configuration management. u EAL-4 is an even greater in-depth analysis of the development and implementation of the Target and may require more significant security engineering costs.

46. 46 EAL (Cont’d) u EALs 5-7 require even more formality in the design process and implementation, analysis of the Target’s ability to handle attacks and prevent covert channels, for products in high- risk environments. u In the United States, evaluation to EALs 5-7 must be done by the National Security Agency (NSA) for the U.S. government.

47. 47 Correspondences OBITSECCC DE0NA EAL1 C1F1+E1EAL2 C2F2+E2EAL3 B1F3+E3EAL4 B2F4+E4EAL5 B3F5+E5EAL6 A1F5+E6EAL7

48. 48 International evaluations history u TCSEC (1980) u Trusted Computer System Evaluation Criteria (U.S.) u ITSEC (1991) u Information Technology Security Evaluation and Certification Scheme (Europe) u CTCPEC (1993) u Canadian Trusted Computer Product Evaluation Criteria (CTCPEC)

49. 49 TCSEC – U.S. (Orange Book) 1985 U.K. Confidence Levels 1989 German Criteria French Criteria Federal Criteria Draft 1993 Canadian Criteria 1993 ITSEC 1991 Common Criteria V1 1996 V2 1998 www.commoncriteria.org International evaluations history

50. 50 Common Criteria participating countries u Certificate producing countries u Australia u New Zealand u Canada u France u Germany u United Kingdom u United States u Certificate consuming countries u Austria u Finland u Greece u Israel u Italy u Netherlands u Norway u Spain u Sweden

51. 51 Security Analysis u Phases: u Identification of the system and its assets u Valuation of the assets u security levels u Identification of vulnerabilities and threats u Valuation of vulnerabilities and threats u Assessment of risks on assets u depending on security levels and misuse likelihoods u stop, if all risks are bearable u Planning and design of countermeasures u Analysis of the extended system u countermeasures are also vulnerable

52. 52 Security Analysis u Common Criteria Trust Concept: u Owner of an asset has to trust countermeasures built up by audits u concept is insufficient since it does not concentrate on parts of the audited system! u Potentially Trusted System Parts: u Principals with access to an asset u all principals may be benevolent u Asset itself u free of vulnerabilities u Countermeasures u sufficient protection u immune against attacks on itself u Reduction of the analysis process by considering trust in system parts

53. 53 Summary u Introduction u The Orange Book u TNI-The Trusted Network Interpretation u Information Technology Security Evaluation Criteria u The Common Criteria u Security Analysis