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

4. November 8, 1999CACR Briefing3 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

5. November 8, 1999CACR Briefing4 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

6. November 8, 1999CACR Briefing5 CC PPs and STs/TOEs Protection Profile (What I Need) Target of Evaluation (the Product) Security Target (What I Have) Customer Vendor

7. November 8, 1999CACR Briefing6 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)

8. November 8, 1999CACR Briefing7 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

9. November 8, 1999CACR Briefing8 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

10. November 8, 1999CACR Briefing9 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

11. November 8, 1999CACR Briefing10 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

12. November 8, 1999CACR Briefing11 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

13. November 8, 1999CACR Briefing12 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

14. November 8, 1999CACR Briefing13 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

15. November 8, 1999CACR Briefing14 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

16. November 8, 1999CACR Briefing15 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!

17. November 8, 1999CACR Briefing16 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

18. November 8, 1999CACR Briefing17 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?

19. November 8, 1999CACR Briefing18 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

20. November 8, 1999CACR Briefing19 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

21. November 8, 1999CACR Briefing20 What does it mean? Extracts from the MRA document

22. November 8, 1999CACR Briefing21 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”

23. November 8, 1999CACR Briefing22 CC Document Structure Part 1Introduction and general model Part 2Security functional requirements Part 3Security assurance requirements

24. November 8, 1999CACR Briefing23 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

25. November 8, 1999CACR Briefing24 CC Part 2 Class, family, and component structure Operations Catalogue of functional requirements Application notes (housed in a separate volume)

26. November 8, 1999CACR Briefing25 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)

27. CC Functionality

28. November 8, 1999CACR Briefing27 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

29. November 8, 1999CACR Briefing28 Component Requirements Structure Class Family Element Family Element Component

30. November 8, 1999CACR Briefing29 Interpreting Functional Requirement Names FIA_UID.1.2 F=Functional A=Assurance Specific Class Family Name Component Number Element Number

31. November 8, 1999CACR Briefing30 CC Functional Classes (1) Security audit (FAU) Communication (FCO) Cryptographic support (FCS) User data protection (FDP) Identification and authentication (FIA) Security management (FMT)

32. November 8, 1999CACR Briefing31 CC Functional Classes (2) Privacy (FPR) Protection of the TOE Security Functions (FPT) Resource utilisation (FRU) TOE access (FTA) Trusted path/channels (FTP)

33. November 8, 1999CACR Briefing32 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

34. November 8, 1999CACR Briefing33 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)

35. November 8, 1999CACR Briefing34 Selected FIA families FIA_UID:User identification FIA_UAU:User authentication FIA_SOS:Specification of secrets

36. November 8, 1999CACR Briefing35 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.

37. November 8, 1999CACR Briefing36 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

38. November 8, 1999CACR Briefing37 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

39. November 8, 1999CACR Briefing38 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

40. November 8, 1999CACR Briefing39 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

41. November 8, 1999CACR Briefing40 FCO Families FCO_NRO: Non-repudaition of origin FCO_NRR: Non-repudiation of receipt

42. November 8, 1999CACR Briefing41 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

43. November 8, 1999CACR Briefing42 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

44. November 8, 1999CACR Briefing43 FPR: Privacy Addresses those functions that protect against discovery and misuse of identity by others

45. November 8, 1999CACR Briefing44 FPR Families FPR_ANO: Anonymity FPR_PSE: Pseudonymity FRP_UNL: Unlinkability FPR: Unobservability

46. November 8, 1999CACR Briefing45 FRU: Resource utilization Supports the availability of required resources (processing capability, storage capacity) FRU deals with: –fault tolerance –prioritization of services –resource allocation

47. November 8, 1999CACR Briefing46 Selected FRU family FRU_RSA:Resource allocation

48. November 8, 1999CACR Briefing47 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

49. November 8, 1999CACR Briefing48 Selected FPT families FPT_FLS: Fail Secure FPT_RCV: Trusted Recovery FPT_RVM: Reference Mediation FPT_SEP: Domain Separation

50. November 8, 1999CACR Briefing49 FTA: TOE Access Addresses functional requirements for controlling the establishment of a user’s session

51. November 8, 1999CACR Briefing50 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

52. November 8, 1999CACR Briefing51 FTP:Trusted Path/Channels Addresses functional requirements for –trusted communications path between users and the TSF and –trusted channel between TSF and other trusted IT products

53. November 8, 1999CACR Briefing52 FTP Families FTP_ITC: Inter TSF trusted channel FTP_TRP: Trusted path –a direct path between users and the TSF

54. November 8, 1999CACR Briefing53 FCS: Cryptographic support Addresses TOEs which employ cryptographic functionality FCS deals with: –cryptographic key generation, distribution, access and destruction –cryptographic operations performed by the TOE (e.g., encryption, decryption, digital signatures, checksums, secure hash, etc.)

55. November 8, 1999CACR Briefing54 FCS families FCS_CKM:Cryptographic key management FCS_COP:Cryptographic operation

56. November 8, 1999CACR Briefing55 FCS_CKM: Cryptographic key management (1) This family supports the management of cryptographic keys throughout their life cycle Each of the components allow for claims to be made that particular standards are met FCS_CKM.1 requires that the TSF generate cryptographic keys; operations are completed for the key generation algorithm and key size

57. November 8, 1999CACR Briefing56 FCS_CKM: Cryptographic key management (2) FCS_CKM.2 defines how the TSF distributes cryptographic keys (operations) FCS_CKM.3 specifies the types of cryptographic access (with associated methods) employed by the TSF (operations) FCS_CKM.4 defines how the TSF destroys cryptographic keys (operations)

58. November 8, 1999CACR Briefing57 FCS_COP: Cryptographic operation (1) This family contains only one component: FCS_COP.1 This family identifies which cryptographic operations (e.g., data encryption, digital signature) are performed by the TOE, and using which cryptographic algorithms, and key sizes

59. November 8, 1999CACR Briefing58 FCS_COP: Cryptographic operation (2) Although strength of cryptographic algorithms is outside the scope of the CC, the correct implementation of the cryptographic algorithms must still be verified by the evaluator

60. November 8, 1999CACR Briefing59 CC Assurance Configuration Management Delivery & Operation Development Guidance Documents Life Cycle Support Tests Vulnerability Assessment

61. November 8, 1999CACR Briefing60 Different Levels of Assurance The CC Provides for 7 different “Evaluation Assurance Levels” (EALs) –Starts at EAL1 (Low Assurance) –EAL3 & EAL4 (Medium Assurance) –EAL5 & EAL6 (High Assurance) –EAL7 (State of the Art)

63. November 8, 1999CACR Briefing62 Objective of EAL 1 Security requirements are traced into the design testing verifies behavior is as expected This provides assurance because; –if a product behaves IAW with security requirements, and –if security requirements are effective to solve security problem, then –product will effectively solve security problem

64. November 8, 1999CACR Briefing63 Why EAL 1 is considered basic So little is known about the product’s design –correct behavior does not mean vulnerability free Nothing is known about the development process –poor development practices often means poor security, or –good security cannot be assured in the absence of good development practices

65. November 8, 1999CACR Briefing64 EAL1 versus EAL3 EAL1 ( Low Assurance ) –“Functionally Tested” –Given a product with Installation, Admin & User Guides. –Does it do what the Guides said it would? EAL3 ( Medium Assurance ) –EAL1 plus… –High Level Design –Test Plan, Procedures, Results, Coverage, Depth, Independent –Misuse, SOF, Obvious Vulnerabilities

66. November 8, 1999CACR Briefing65 Canadian Common Criteria Evaluation and Certification Scheme

67. November 8, 1999CACR Briefing66 CCS Purpose To provide a cost effective, expandable IT security evaluation capability in Canada ensure quality of evaluations improve availability of evaluated products improve efficiency and cost effectiveness of evaluation and certification processes

68. November 8, 1999CACR Briefing67 CCS Framework SCC Accreditation of IT E&T Facilities CSE Approval of CCS ITSEFs >>CCEFs CCEFs will Evaluate IT products CSE will Certify CCEF results

69. November 8, 1999CACR Briefing68 General requirements for the Competence of Calibration & Testing Laboratories: ISO Guide 25, CAN-P-4 A Framework for Commercial ITS Evaluation and Testing Basic Quality System Management Structure Documented Procedures

70. November 8, 1999CACR Briefing69 General requirements for the Competence of Calibration & Testing Laboratories: ISO Guide 25, CAN-P-4 Guidelines for the Accreditation of ITS Evaluation and Testing Facilities (CAN-P-1591) A Framework for Commercial ITS Evaluation and Testing ITS Knowledge and Skills

71. November 8, 1999CACR Briefing70 General requirements for the Competence of Calibration & Testing Laboratories: ISO Guide 25, CAN-P-4 Guidelines for the Accreditation of ITS Evaluation and Testing Facilities (CAN-P-1591) A Framework for Commercial ITS Evaluation and Testing CC Based Product (Phase I) and System (Phase II) Evaluations and Certifications The Canadian CCS will be the first program to build on this “foundation” in Canada

72. November 8, 1999CACR Briefing71 General requirements for the Competence of Calibration & Testing Laboratories: ISO Guide 25, CAN-P-4 Secure Electronic Business Testing / Approvals? System Vulnerability Analysis? Biometric Testing / Approvals? CBA Testing? Guidelines for the Accreditation of ITS Evaluation and Testing Facilities (CAN-P-1591) A Framework for Commercial ITS Evaluation and Testing CC Based Product (Phase I) and System (Phase II) Evaluations and Certifications PKI Certificate Policy Approvals?

73. November 8, 1999CACR Briefing72 CSE as the Certification Body approve prospective CCEFs provide advice & guidance to the CCEFs monitor the conduct of evaluations certify conformance of evaluation results provide international liaison - the MRA

74. November 8, 1999CACR Briefing73 Certification - 3 Pillars Performance of Evaluator Activities –Independently perform & compare Observation of Evaluator Activities –First hand observe Evaluator Activities Examination of Evaluation deliverables –Approval of final results (e.g. ETR, PCR)

75. November 8, 1999CACR Briefing74 The Big Picture

76. November 8, 1999CACR Briefing75 Summary IT Products Evaluated by a Trusted & Qualified 3rd Party are of Value. The CC is the New World Standard ( ISO 15408 ) The CCS and the CCEF’s are here today to help you acquire Security and Assurance.

77. November 8, 1999CACR Briefing76 Points of Contact / Info CSE & CCS: http://www.cse-cst.gc.ca SCC: http://www.scc.ca/palcan/itset.html EWA: http://www.ewa-canada.com/ –has evaluated at EAL1 http://www.signal9.com/ LGS/Domus: http://www.domus.com/itss/ –is evaluating http://www.winmagic.com/product.html CGI: http://www.cgi.ca/e/solutions/expertise/infosecurity/ –has evaluated at EAL1 http://www.entrust.com/truedelete/index.htm

78. November 8, 1999CACR Briefing77 Links Common Criteria Support Environment –ccse.cesg.gov.uk/ Protection Profiles - WEB site –www.radium.ncsc.mil/tpep/library/protection_profiles –csrc.nist.gov/cc/pp/pplist.htm –www.cesg.gov.uk/cchtml/ippr/ CC Resource WEB sites –http://www.cse.dnd.ca/cse/english/cc.html –ftp://ftp.cse.dnd.ca/pub/criteria –http://csrc.nist.gov/cc

79. November 8, 1999CACR Briefing78 CSE Approved CCEFs  CGI Information Systems and Management Consultants Inc. POC: Mr Andrew Pridham Tel: (613) 234-2155 E-mail: andrew.pridham@cgi.ca  DOMUS ITSL, a division of LGS Group Inc. POC: Mr Bill Dziadyk Tel: (613) 230 - 6285 E-mail: Bill_Dziadyk@LGS.com  EWA - Canada Ltd, POC: Mr Paul Zatychec Tel: (613) 230 - 6067 Ex. 227 E-mail: pzatychec@ewa-canada.com

80. November 8, 1999CACR Briefing79 Questions?