1 / 30

Common Criteria

Common Criteria. IT Security Evaluation By Sandeep Joshi. List of Terms…. List of Terms…. List of Terms. History…. Originated out of three standards ITSEC (Information Technology Security Evaluation Criteria)

frederick
Download Presentation

Common Criteria

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Common Criteria IT Security Evaluation By Sandeep Joshi Southern Methodist University

  2. List of Terms… Southern Methodist University

  3. List of Terms… Southern Methodist University

  4. List of Terms Southern Methodist University

  5. History… • Originated out of three standards • ITSEC (Information Technology Security Evaluation Criteria) • European Standard, developed in early 1990s, by UK, France, the Netherlands, and Germany • TCSEC (Trusted Computer System Evaluation Criteria) • Widely known as “Orange Book” Southern Methodist University

  6. History… • TCSEC (Trusted Computer System Evaluation Criteria) • Issued by United States Government National Computer Security Council, as DoD standard 5200.28-STD, December 1985 • CTCPEC (Canadian Trusted Computer Product Evaluation Criteria) Southern Methodist University

  7. History… First Draft (Version 1.0) was published in January 1996 for comments • Version 2.0 was published in 1998, and was accepted by ISO as an Final Committee Draft (FCD) document • Version 2.0 became ISO standard sometime in June 1999 with minor, mostly editorial modifications. Southern Methodist University

  8. History • Two versions of CCs were released since then… • Version 2.1 was released in August 1999, and now accepted as ISO-15408 standard • Version 2.2, the newest version, released this year (2004). Southern Methodist University

  9. Why should we use the CC? • What support does CC have? • What guarantees do CC-certified/validated products provide? • Where should we start, if we want to achieve CC-certificate/validation for our product? Southern Methodist University

  10. What support does CC have?.. • National security and standards organizations within Canada, France, Germany, Netherlands, UK and USA worked in collaboration to replace their existing security evaluation criteria (SEC) Southern Methodist University

  11. What support does CC have? • Acceptance by ISO will ensure that CC rapidly becomes the world standard for security specification and evaluation • Wider choice for evaluated products for consumers • Greater understanding of consumer requirements • Greater access to markets for developers Southern Methodist University

  12. What guarantees products will provide? • A sound basis for confidence that security measures are appropriate to meet a given threat and that they are correctly implemented • Quantifies/measures the extent to which security has been assessed • Includes an assurance scale, called as Evaluation Assurance Level (EAL) Southern Methodist University

  13. Who could be affected? Developers Vendors Common Criteria Accreditors Certifiers Approvers Evaluators Consumers Southern Methodist University

  14. What is CC? • Overview • Building Blocks • Security and Functional Requirements • Security Assurance Requirements • Protection Profiles (PP) • Security Targets (ST) Southern Methodist University

  15. Overview… Southern Methodist University

  16. Overview Southern Methodist University

  17. Building Blocks… • Security Functional Requirements • Grouped into 11 classes • Members of each class shares common focus, but differ in emphasis • Audit, Cryptographic Support, Communication, User Data Protection, Identification and Authentication, Security Management, Privacy, Protection of TOE security functions, Resource Utilization, TOE Access, Trusted Path/Channels Southern Methodist University

  18. Building Blocks • Audit class contains 6 families dealing with various aspects of auditing • data generation, analysis, event storage etc. • Each family contains one or more components • Audit data generation has 2 components • 1 dealing with generation of audit records • 2 dealing with association of user with auditable event Southern Methodist University

  19. Security Assurance Requirements… • Grouped into Classes  Families  Components • In all 8 basic classes and two special classes for PPs and STs • Configuration Management, Guidance Documents, Vulnerability Assessment, Delivery and Operation, Life Cycle Support, Assurance Maintenance, Development, Tests Southern Methodist University

  20. Security Assurance Requirements… • Provides 7 predefined assurance packages • Known as Evaluation Assurance Levels (EAL) • Raising scale of assurance • From EAL1 to EAL7 Southern Methodist University

  21. Security Assurance Requirements… • EAL1: Functionally Tested • Provides evaluation of product as made available to user • Independent testing against specification • Examination of guidance documents • EAL2: Structurally Tested • Applicable where developer/user need low  moderate level of assurance • For example, legacy systems • EAL3: Methodically Tested and Checked • Provides analysis supported by “gray box” testing • Selective confirmation of test results Southern Methodist University

  22. Security Assurance Requirements… • EAL4: Methodically Designed, Tested and Reviewed • Low level analysis of design, and subset of implementation • Independent search for vulnerability • EAL5: Semi-formally Designed and Testes • Analysis of complete implementation • Supplemented by formal model • Semiformal presentation of functional model, and high level design • Search for vulnerability must ensure resistance etc Southern Methodist University

  23. Security Assurance Requirements • EAL6: Semi-formally Verified design and Tested • Analysis with modular and layered approach to design and implementation • Plus EAL5 and lower level testing • EAL7: Formally Verified design and Tested • Evaluation of formal model with, • formal presentation of formal specification • Evidence of “white-box” testing Southern Methodist University

  24. Protection Profiles… • What is Protection Profile? • Essentially an implementation independent statement of security requirements that is shown to address threats that exists in a specified environment Southern Methodist University

  25. Protection Profiles… What it contains? Introduction  PP Identification, PP Overview TOE Description TOE Security Environment  Assumptions, Threats, Organizational Security Policies Security Objectives  For TOE, For Environment IT Security Requirements  TOE Security Requirements Functional Assurance  Security Requirements for IT environment PP Application Notes Rationale  Objectives, Requirements Southern Methodist University

  26. Protection Profiles • When would you want a PP? • When setting standards for particular product type • A government wishes to specify security requirements for a class of security products, like firewalls, etc. • Or, a firm needs an IT system that addresses its security issues Southern Methodist University

  27. Security Targets… • What is Security Target? • A basis against which evaluation is performed • Contains security threats, objectives, requirements, summary specification of functions and assurance measures • When is ST Needed? • When submitting product for evaluation Southern Methodist University

  28. Security Targets… What are the contents of ST Document? Introduction  ST Identification, ST Overview, CC conformance TOE Description TOE Environment  Assumptions, Threats, Organizational Security Policies Security Objectives  For TOE, For environment IT Security Requirements  TOE Security Requirements  Functional, Assurance  Security Requirements for IT environment TOE Summary Specification TOE Security Function, Assurance Measures PP Claims  PP Reference, PP Refinement, Additions Rationale Security Objective Rationale Security Requirements Rationale TOE Summary Specification PP Claims Rationale Southern Methodist University

  29. Reference • http://csrc.nist.gov/cc/ Southern Methodist University

  30. Questions!!! Southern Methodist University

More Related