CACR CC Briefing - PowerPoint PPT Presentation

slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CACR CC Briefing PowerPoint Presentation
Download Presentation
CACR CC Briefing

play fullscreen
1 / 79
CACR CC Briefing
148 Views
Download Presentation
elie
Download Presentation

CACR CC Briefing

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. CACR CC Briefing Stephen Booth Computer and System Security Section Communications Security Establishment Stephen .Booth@cse-cst.gc.ca

  2. Presentation Objectives • I intend to provide: • an overview of the CC Project • the Current Status of the CC and CEM • a description of the CC MRA • a high level description of the CC - how it is structured • a description of the Canadian CC Scheme CACR Briefing

  3. Terms Used • CC - Common Criteria • CCEF - (CCE Approved) CC Evaluation Facility • CCS - Canadian CC Evaluation and Certification Scheme • CEM - Common Evaluation Methodology • EAL - Evaluation Assurance Level • MRA Mutual Recognition Arrangement • PP - Protection Profile ( what the buyer needs) • ST - Security Target ( what the vendor has) • TOE - Target of Evaluation (the product) • TSF - TOE Security Functions CACR Briefing

  4. CC PPs and STs/TOEs Protection Profile(What I Need) Customer Vendor Security Target(What I Have) Target of Evaluation(the Product) CACR Briefing

  5. History of Evaluation Criteria • ‘83/85: Trusted Computer System Evaluation Criteria (TCSEC) • ‘91: Information Technology Security Evaluation Criteria (ITSEC) • ‘93: Canadian Trusted Computer Evaluation Criteria (CTCPEC) • ‘96: Common Criteria (CC) CACR Briefing

  6. TCSEC • Trusted Computer System Evaluation Criteria (orange book) DoD 5200.28-STD, December 1983 • Four trust rating divisions (classes): • D, C (C1, C2), B (B1, B2, B3), A (A1) • Three basic requirements: • specific security functionality requirement • assurance requirement • documentation requirement CACR Briefing

  7. ITSEC • Information Technology Security Evaluation Criteria (France, Germany, Netherlands and UK) v1.2, 1991 • focus is on assurance regardless of functionality • product evaluated to perform as indicated in documentation CACR Briefing

  8. CTCPEC • Canadian Trusted Computer Product Evaluation Criteria, Version 3.0, Jan. 1993 • two types of requirements are delineated: • functionality requirements • assurance requirements (T-0 to T-7) • functionality: four policy-oriented criteria - Confidentiality, Integrity, Availability and Accountability CACR Briefing

  9. Common Criteria (CC) • Common Criteria Version 1.0 (CC) 31 Jan 1996 • aligned the evaluation criteria of nations (ie. TCSEC, FC (USA), CTCPEC (Canada), ITSEC (Europe), ISO) • compatible with existing evaluation criteria • one product evaluated against it (Milkyway Black Hole firewall) • CC version 2.0 (May 1998) now superceded by • CC Version 2.1 which is identical to ISO 17408 CACR Briefing

  10. CEM • What is the CEM? • Common Methodology for information technology security evaluation • An common understanding of what the CC assurance requirements mean and the minimum work necessary to satisfy them • Supports mutual recognition of evaluation results CACR Briefing

  11. Purpose of the CEM • Defines specific evaluator work units • Common approach to satisfying assurance requirements defined in CC Part 3 • Primary audience is evaluators and certifiers overseeing evaluator work • Counter balances commercial pressures to reduce evaluation effort CACR Briefing

  12. Progress to date on the CEM • Part 1, Introduction and general model, release January 97 • Part 2, Evaluation methodology, first released January 99 (ver 0.6) (1003 comments received) • Part 2, re-released, August 99 (ver 1.0) • Incorporated large majority of comments • Working document for next 12 to 18 months • MRA requirement to use for evaluations commencing Jan 2000 CACR Briefing

  13. Future work on the CEM • Methodology for augmentations beyond predefined assurance packages • Evaluations need not be performed using pre-define assurance packages • Methodology for maintenance of certificates • How to extend evaluation results to future releases • Methodology for high assurance requirements • Current CEM covers assurance requirements in low to medium assurance category CACR Briefing

  14. Mutual Recognition Arrangement • attempted to document a “gentleman’s agreement” to accept each others evaluation results • started as an agreement but that meant it was staffed and signed as an international treaty • fundamental concept of the CC project • if there is no effective MRA then the CC project has failed! CACR Briefing

  15. What do we need for MRA? • Common and agreed upon standard • Common and agreed upon evaluation methodology • Trust / comfort that the other signatories are doing things if not the same way then at least in a consistent way • Willingness of all the partners to take some risks CACR Briefing

  16. What do we have that let us sign MRA? • CC • CEM • require evaluation facilities to be accredited to ISO 25 • require CBs to meet the requirements of ISO 65 • Technical discussion group that meets to talk about how each of our schemes work • a commitment to undergo voluntary periodic assessments • Are we all totally comfortable? CACR Briefing

  17. What do we have that let us sign MRA? • Risk takers and mitigation steps • accepted each other “on faith” and before CEM was completed • we accept EAL 1 to 4 for now • a commitment to make MRA and the CC project work CACR Briefing

  18. MRA Signing • Arrangement on the Mutual Recognition of Common Criteria Certificates in the Field of Information Technology Security • signed October 8,1998 • Germany, UK, Canada, US and France • expanded this year (September )to include the Australasian Scheme CACR Briefing

  19. What does it mean? • Extracts from the MRA document CACR Briefing

  20. MRA Future • expand both signatories and scope ( >EAL 4) • initiatives underway to expand to Europe • work on CEM for higher assurance levels • stepping up the schedule of “voluntary assessments” CACR Briefing

  21. CC Document Structure • Part 1 Introduction and general model • Part 2 Security functional requirements • Part 3 Security assurance requirements CACR Briefing

  22. CC Part 1 • Introduction to the rest of the documents • A general model of evaluation • Common Criteria evaluation results • Structure for expressing requirements and specifications CACR Briefing

  23. CC Part 2 • Class, family, and component structure • Operations • Catalogue of functional requirements • Application notes (housed in a separate volume) CACR Briefing

  24. CC Part 3 • Assurance requirements of the criteria: • CC Assurance Paradigm • Evaluation criteria for PPs (Class APE) • Evaluation criteria for STs (Class ASE) • Catalogue of assurance requirements • Evaluation assurance levels (EALs) CACR Briefing

  25. CC Functionality

  26. Functional Requirements • Describe the desired security behavior of the TOE • Intended to protect confidentiality, integrity and availability of assets, as required • May be customized for inclusion in a PP/ST CACR Briefing

  27. Requirements Structure Class Family Family Component Component Element Element CACR Briefing

  28. Interpreting Functional Requirement Names FIA_UID.1.2 Element Number F=Functional A=Assurance Component Number Family Name Specific Class CACR Briefing

  29. CC Functional Classes (1) • Security audit (FAU) • Communication (FCO) • Cryptographic support (FCS) • User data protection (FDP) • Identification and authentication (FIA) • Security management (FMT) CACR Briefing

  30. CC Functional Classes (2) • Privacy (FPR) • Protection of the TOE Security Functions (FPT) • Resource utilisation (FRU) • TOE access (FTA) • Trusted path/channels (FTP) CACR Briefing

  31. Functional Components • It is the collection of functional components in a PP/ST that defines the functionality • Each component contains a list of evaluatable statements, called “elements” • All elements must be successfully evaluated within a component CACR Briefing

  32. FIA: Identification and authentication • Addresses requirements for functions to establish and verify a claimed user identity • FIA deals with: • user identification and authentication • authentication failures • user attributes (e.g., clearances, roles) • constraints on quality of authentication data (e.g. minimum password size) CACR Briefing

  33. Selected FIA families • FIA_UID: User identification • FIA_UAU: User authentication • FIA_SOS: Specification of secrets CACR Briefing

  34. FAU: Security Audit • Security auditing involves recognising, recording, storing, and analysing information related to security relevant events. • Post event examination of which security events took place, and which user (if applicable) is responsible. CACR Briefing

  35. Selected FAU families • FAU_GEN: Security Audit Data Generation • FAU_SEL: Security Audit Event Selection • FAU_STG: Security Audit Event Storage • FAU_SAR: Security Audit Review • FAU_SAA: Security Audit Analysis CACR Briefing

  36. FMT: Security Management • management of TSF data (e.g. banners) • management of security attributes (ACL’s) • management of functions of the TSF (e.g. selection of functions, setting rules, etc.) • definition of security roles CACR Briefing

  37. Selected FMT families • FMT_MSA: Management of Security Attributes • attribute: used for enforcement of TSP • FMT_MTD: Management of TSF Data • data: created by and for the TOE • FMT_SMR: Security Management Roles CACR Briefing

  38. FCO:Communications • Address the functions that are concerned with assuring the identity of a party participating in a data exchange • proof of origin • proof of receipt CACR Briefing

  39. FCO Families • FCO_NRO: Non-repudaition of origin • FCO_NRR: Non-repudiation of receipt CACR Briefing

  40. FDP: User data protection • Specifies requirements for policies and functions related to user data protection • FDP deals with: • security function policies for user data protection (access control, information flow) • forms of user data protection • off-line storage, import and export • inter-TSF communication CACR Briefing

  41. Selected FDP families • FDP_ACC: Access control policy • FDP_ACF: Access control functions • FDP_RIP: Residual information protection • FDP_ROL: Rollback • FDP_SDI: Stored data integrity CACR Briefing

  42. FPR: Privacy • Addresses those functions that protect against discovery and misuse of identity by others CACR Briefing

  43. FPR Families • FPR_ANO: Anonymity • FPR_PSE: Pseudonymity • FRP_UNL: Unlinkability • FPR: Unobservability CACR Briefing

  44. FRU: Resource utilization • Supports the availability of required resources (processing capability, storage capacity) • FRU deals with: • fault tolerance • prioritization of services • resource allocation CACR Briefing

  45. Selected FRU family • FRU_RSA: Resource allocation CACR Briefing

  46. FPT: Protection of the TOE Security Functions • 3 significant portions of the TSF: • abstract machine • what does the TOE “sit upon” • implementation • the mechanisms that enforce the TSP • TSF data • the transient rules and data of the TOE CACR Briefing

  47. Selected FPT families • FPT_FLS: Fail Secure • FPT_RCV: Trusted Recovery • FPT_RVM: Reference Mediation • FPT_SEP: Domain Separation CACR Briefing

  48. FTA: TOE Access • Addresses functional requirements for controlling the establishment of a user’s session CACR Briefing

  49. FTA Families • FTA_LSA: Limitation on scope of slectable attributes • FTA_MCS: Limitation on multiple concurrent sessions • FTA_SSL: Session locking • FTA_TAB: TOE Access banners • FTA_TAH: TOE Access history • FTA_TSE: TOE Session establishment CACR Briefing