Understanding the Common Criteria and the Evaluation Process
advertisement
Undersatnding the CC Evaluation Process What is the Common Criteria (CC) Standard? Understanding the Common Criteria and the Evaluation Process The basis for evaluation of security properties of IT products and systems ISO/IEC Standard 15408 for specifying security requirements Common criteria for information technology security evaluation http://niap.nist.gov/cc-scheme/index.html http://www.commoncriteriaportal.org/ Comprises: Using slides developed by Ruben Prieto-Diaz at JMU Security functional requirements dictionary Security assurance requirements dictionary A method for creating sound security requirements That can be evaluated and tested 2 CC FAQ Where Did the CC Originate? TCSEC = Trusted Computer System Evaluation Criteria (US) What is the CC? Where did the CC originate? How can the CC help my organization? What support does the CC have? Who certifies CC products and systems? How do I buy products that conform to CC? Where do I start? ITSEC = Information Technology Security Evaluation Criteria (Europe) http://niap.nist.gov/cc-scheme/faqs.html 1980s 1990s 3 Orange Book Classes TCSEC (“The Orange Book”) Trusted Computer System Evaluation Criterion Issued under authority of and in accordance with DoD Directive 5200.28, Security Requirements for Automatic Data Processing (ADP) Systems Purpose: to provide technical hardware/firmware/software security criteria and associated technical evaluation methodologies in support of overall ADP system security policy, evaluation and approval/accreditation responsibilities promulgated by DoD 5 Based on slides by Ruben Prieto-Diaz 4 HIGH SECURITY NO SECURITY A1 B3 B2 B1 C2 C1 D Verified Design Security Domains Structured Protection Labeled Security Protection Controlled Access Protection Discretionary Sec.Protection Minimal Protection 6 1 Undersatnding the CC Evaluation Process Orange Book Classes C1,C2 NCSC Rainbow Series -some Titles Unofficial View Simple enhancement of existing systems. No breakage of applications B1 Relatively simple enhancement of existing systems. Will break some applications. B2 Relatively major enhancement of existing systems. Will break many applications. Orange Yellow Red Lavender B3 Failed A1 Orange Book Criticisms A1 Top down design and implementation of a new system from scratch Trusted Computer System Evaluation Criteria Guidance for Applying the Orange Book Trusted Network Interpretation Trusted Database Interpretation Mixes various levels of abstraction in a single document Heavy on confidentiality, does not address integrity or availability Combines functionality and assurance in a single linear rating scale No formal semantics (criteria need to be interpreted) 7 8 Later Standards CTCPEC – Canada ITSEC – European Standard NSTISSP No. 11 Did not define criteria Levels correspond to strength of evaluation Includes code evaluation, development methodology requirements Known vulnerability analysis A national information assurance acquisition policy issued on January 2000 by the NSTISSC. CISR: Commercial outgrowth of TCSEC FC: Modernization of TCSEC FIPS 140: Cryptographic module validation Common Criteria: International Standard SSE-CMM: Evaluates developer, not product • National Security Telecommunications and Information Systems Security Committee. Starting July 1st, 2002, all government acquisitions of IT systems dealing with information security must be evaluated and validated according to the common criteria or equivalent. 9 10 NIAP What are Security Criteria? National Information Assurance Partnership NIST collaborate NIAP NSA NIAP = US Gov. initiative to meet security testing needs of IT producers & consumers. http:/niap.nist.gov 11 Based on slides by Ruben Prieto-Diaz (User view) A way to define Information Technology security requirements for some IT products: Hardware Software Combinations of above (Developer view) A way to describe security capabilities of their specific product (Evaluator view) A tool to measure the confidence we may place in the security of a product. 12 2 Undersatnding the CC Evaluation Process Defining Security Requirements IT Security Requirements Common Criteria (CC) provides a framework for defining security requirements (both features and assurances) in IT products CC protection profiles describe security requirements for a class of IT products (from consumers perspective) CC security targets describe specific security claims by producers of IT products Terminology Protection profile (PP) Security target (ST) Target of evaluation (TOE) “I want” “I will provide” Implementation of ST 13 The Common Criteria defines two types of IT security requirements Functional Requirements Assurance Requirements - for defining security behavior of the IT product or system: • implemented requirements become security functions - for establishing confidence in security functions: • correctness of implementation • effectiveness in satisfying security objectives Examples: •Identification & Authentication •Audit •User Data Protection •Cryptographic Support Examples: •Configuration Management •Life Cycle Support •Tests •Development Security Targets Protection Profile Intended for expression of consumer needs Combination of security functional and security assurance requirements Allows for creation of security standards Assists backwards compatibility Example Protection Profiles (Product Independent) Operating Systems (C2, CS2, RBAC) Firewalls (Packet Filter and Application) Smart cards (Stored value and other) Similar to PP but add: TOE summary specification PP claims Supporting rationale Example Security Targets (Product Specific) Oracle Database Management System Lucent, Cisco, Checkpoint Firewalls See http://niap.nist.gov/cc-scheme/st/ST_VID4005-ST.pdf 15 Protection Profiles (generic) 16 Security Targets (specific) Security Target contents Protection Profile contents Specification • Introduction • TOE General Description • Security Environment • Assumptions • Threats • Organizational security policies • Security Objectives •For product and for environment • Security Requirements • Functional requirements • Assurance requirements • Rationale (for objectives and requirements) Based on slides by Ruben Prieto-Diaz 14 Claims 17 • Introduction • TOE General Description • Security Environment • Assumptions • Threats • Organizational security policies • Security Objectives •For product and for environment • Security Requirements • Functional requirements • Assurance requirements • TOE Summary Specification • PP Claims • Rationale (for objectives and requirements) •(also of possible differences PP vs. ST) 18 3 Undersatnding the CC Evaluation Process Metaphor CCEVS CC Evaluation and Validation Scheme Objective Approach Test Security Properties of Commercial Products Tests performed by Accredited Commercial Laboratories Validity/Integrity of results underwritten by NIAP Results posted for public access Assume you build your house in a nice and safe neighborhood One CCEVS for each certificate sponsoring country Built without thinking about security Concerned with comfort, space, and style Assume years later neighborhood becomes high on crime Need to make house secure 19 20 Metaphor (cont.) Metaphor (cont.) How to make house secure? Ad-hoc: add locks, alarms, etc. as needed Systematic: Analyze neighborhood (environment) Identify threats and vulnerabilities Define house security requirements Implement requirements Assume further Verify requirements coverage You want to sell your house Demonstrate it is secure You are not expert on security Your local fire station has experts that can help you with the systematic approach Security experts have a set of standards and guidelines for assuring a house is secure 21 Metaphor (cont.) CC’s Security Context Assume further 22 City officials mandate that all houses for sale must bear a secure certificate House secure certificates to be provided by local fire station Fire station only has 2 house security experts that know how to do house security evaluations This is exactly the current situation with the common criteria IT evaluation standard 23 Based on slides by Ruben Prieto-Diaz 24 4 Undersatnding the CC Evaluation Process CC’s Evaluation Role The CC as Evaluation Tool 25 26 CC Evaluation: Procedural View The CC Evaluation Process The CC Standard Reference & background Information TOE Documentation Security Framework (may include Protection Profiles PPs) CC Vocabulary & Standards Prepare for Evaluation CC Evaluation Methodology (CEM) Conduct Evaluation Security Target ST Reviewed TOE Documentation Describes Conclude Evaluation CC Evaluation Reports & Certificates CC Evaluation TOE Product Inputs 27 28 Interested Parties Environmental Considerations Interested Parties is a TOE Producer Evaluation User Evaluation Participant is a is a is a Policies Threats Assumptions Sponsor Developer Consultant CC Evaluator Certifier Validator Consumer Product Vendor is a Certified Testing Laboratory (e.g., CygnaCom, SAIC) Personnel Physical Host OS & configuration Certification/Validation Body (e.g., NIAP, NIST, NSA) Evaluator Approver Accreditor 29 Based on slides by Ruben Prieto-Diaz 30 5 Undersatnding the CC Evaluation Process Sample Policies Sample Threats All data collected and produced by the TOE shall only be used for authorized purposes. Administrators must authenticate before accessing any TOE functions or data. The TOE shall provide a set of administrative tools to manage the TOE’s functions and data. Taken from SurfinGate Version 5.6 Security Target http://niap.nist.gov/cc-scheme/CCentries/CCEVS-CCVID405-FinjanSurfinGate.html Malicious mobile code may enter the IT System monitored by the TOE undetected. The TOE may fail to identify malicious mobile code based on data received. The TOE may fail to react to identified or suspected malicious mobile code. An unauthorized user may inappropriately change the configuration of the TOE. An unauthorized user may attempt to remove or destroy data collected and produced by the TOE. 31 32 Sample Assumptions Sample Assumptions Personnel: There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains. The administrators are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the TOE documentation. Physical: The processing resources of the TOE will be located within controlled access facilities, which will prevent unauthorized physical access. The TOE hardware and software critical to security policy enforcement will be protected from unauthorized physical modification. 33 Interpreting Functional Requirement Names Sample Assumptions 34 Host OS & configuration: FAU_GEN.1.2 A firewall will direct all web-based traffic through the SurfinGate product. SurfinGate will be the only application running on its host server. The mail server on the SurfinGate network will accept only outgoing mail from the SurfinGate product and will deliver mail properly. The host operating system will provide a reliable timestamp. Specific Class 35 Based on slides by Ruben Prieto-Diaz Element Number F = Functional A = Assurance Family Name Component Number 36 6 Undersatnding the CC Evaluation Process CC’s Security Functional Classes 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. CC’s Functional Class Structure Security Audit (4) Communication (2) Cryptographic Support (2) User Data Protection (13) Identification and Authentication (6) Security Management (6) Privacy (4) Protection of Security Functions (16) Resource Utilization (3) Access (6) Trusted Path/Channels (2) 37 38 CC’s Security Assurance Classes 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. CC’s Organization of Security Requirements Protection Profile Evaluation (6) Security Target Evaluation (8) Configuration Management (3) Delivery and Operation (2) Development (7) Guidance Documentation (2) Life Cycle (4) Tests (4) Vulnerability Assessment (4) Maintenance of Assurance (4) Class Family Component Describes a specific set of security requirements Smallest selectable set of security requirements 39 40 Approach to Evaluation Evaluation Assurance Levels The principal input to an evaluation is a Security Target. The ST is the basis for agreement between the TOE developers, consumers, and evaluators as to what security a TOE offers. 41 Based on slides by Ruben Prieto-Diaz EAL0 - Inadequate assurance EAL1 - Functionally tested EAL2 - Structurally tested EAL3 - Methodically tested and checked EAL4 - Methodically designed, tested and reviewed EAL5 – Semi-formally designed and tested EAL6 – Semi-formally verified designed and tested EAL7 - Formally verified designed and tested 42 7 Undersatnding the CC Evaluation Process EALs1-4 EALs5-7 EAL1 is the entry level. Up to EAL4 increasing rigor and detail are introduced, but without introducing significantly specialized security engineering techniques. EALs 3-4 commonly requested by governments and security-demanding organizations EAL 4 evaluation typically costs $1 million EAL1-4 can generally be retrofitted to preexisting products (TOEs). TOEs meeting the requirements of these levels will have been designed and developed with the intent of meeting those requirements. At EAL7 there are significant limitations on the practicability of meeting the requirements: Substantial cost impact Require state-of-the-art techniques for formal analysis. 43 Relationship to TCSEC 44 What is a Validation Certificate? National Information Assurance Partnership Common Criteria Certificate TM With respect to assurance, roughly Vendor Name The IT product identified in this certificate has been evaluated at an accredited testing laboratory using the Common Methodology for IT Security Evaluation (Version X) fr conformance to the Common Criteria for IT Security Evaluation (Version X). This certificate applies only to the specific version and release of the product in its evaluated configuration. The product’s functional and assurance security specifications are contained in its security target. The evaluation has been conducted in accordance with the provisions of the NIAP Common Criteria Evaluation and Validation Scheme and the conclusions of the testing laboratory in the evaluation technical report are consistent with the evidence adduced. This certificate is not an endorsement of the IT product by any agency of the U.S. Government and no warranty of the IT product is either expressed or EAL0 and EAL1 ~ D EAL2 ~ C1 EAL3 ~ C2 EAL4 ~ B1 EAL5 ~ B2 EAL6 ~ B3 EAL7 ~ A1 implied. Product Name: Version and Release Numbers: Protection Profile Identifier: Evaluation Platform: Director, Information Technology Laboratory National Institute of Standards and Technology Name of CCTL: Validation Report Number: Date Issued: Assurance Level: Deputy Director for Information Systems Security National Security Agency zValidation that product met Common Criteria requirements for which it was evaluated/tested zNot an NSA, NIST, or NIAP endorsement of the product 45 Common Criteria Mutual Recognition z (Capabilities and Limitations) Parties commit to “recognize the certificates which have been issued by any one of them” Provides a common security specification language for IT products and systems “Recognize” = accept the validity of the evaluation process z Offers great flexibility in tailoring security requirements to specific needs Two Categories of membership: “Certificate Producing” US Canada UK Germany France Australia/ New Zealand “Certificate Consuming” Netherlands Finland Greece Italy 46 Norway Spain Requires some interpretation due to lack of formal specification model Israel 47 Based on slides by Ruben Prieto-Diaz Requires technical expertise in formulating protection profiles and security targets from generic catalogues 48 8
