CACR CC Briefing Nov8 99

1
(No Transcript)
2
CACR CC Briefing

• Stephen Booth
• Computer and System Security Section
• Communications Security Establishment
• Stephen .Booth_at_cse-cst.gc.ca

3
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

4
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

5
CC PPs and STs/TOEs
Protection Profile(What I Need)
Customer
Vendor
Target of Evaluation(the Product)
Security Target(What I Have)
6
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)

7
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

8
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

9
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

10
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

11
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

12
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

13
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

14
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

15
Mutual Recognition Arrangement

• attempted to document a gentlemans 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!

16
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

17
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?

18
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

19
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

20
What does it mean?

• Extracts from the MRA document

21
MRA Future

• expand both signatories and scope ( gtEAL 4)
• initiatives underway to expand to Europe
• work on CEM for higher assurance levels
• stepping up the schedule of voluntary
  assessments

22
CC Document Structure

• Part 1 Introduction and general model
• Part 2 Security functional requirements
• Part 3 Security assurance requirements

23
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

24
CC Part 2

• Class, family, and component structure
• Operations
• Catalogue of functional requirements
• Application notes (housed in a separate volume)

25
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)

26
CC Functionality

27
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

28
Requirements Structure
Class
Family
Family
Component
Component
Element
Element
29
Interpreting Functional Requirement Names

• FIA_UID.1.2

Element Number
FFunctional AAssurance
Component Number
Family Name
Specific Class
30
CC Functional Classes (1)

• Security audit (FAU)
• Communication (FCO)
• Cryptographic support (FCS)
• User data protection (FDP)
• Identification and authentication (FIA)
• Security management (FMT)

31
CC Functional Classes (2)

• Privacy (FPR)
• Protection of the TOE Security Functions (FPT)
• Resource utilisation (FRU)
• TOE access (FTA)
• Trusted path/channels (FTP)

32
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

33
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)

34
Selected FIA families

• FIA_UID User identification
• FIA_UAU User authentication
• FIA_SOS Specification of secrets

35
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.

36
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

37
FMT Security Management

• management of TSF data (e.g. banners)
• management of security attributes (ACLs)
• management of functions of the TSF (e.g.
  selection of functions, setting rules, etc.)
• definition of security roles

38
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

39
FCOCommunications

• Address the functions that are concerned with
  assuring the identity of a party participating in
  a data exchange
• proof of origin
• proof of receipt

40
FCO Families

• FCO_NRO Non-repudaition of origin
• FCO_NRR Non-repudiation of receipt

41
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

42
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

43
FPR Privacy

• Addresses those functions that protect against
  discovery and misuse of identity by others

44
FPR Families

• FPR_ANO Anonymity
• FPR_PSE Pseudonymity
• FRP_UNL Unlinkability
• FPR Unobservability

45
FRU Resource utilization

• Supports the availability of required resources
  (processing capability, storage capacity)
• FRU deals with
• fault tolerance
• prioritization of services
• resource allocation

46
Selected FRU family

• FRU_RSA Resource allocation

47
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

48
Selected FPT families

• FPT_FLS Fail Secure
• FPT_RCV Trusted Recovery
• FPT_RVM Reference Mediation
• FPT_SEP Domain Separation

49
FTA TOE Access

• Addresses functional requirements for controlling
  the establishment of a users session

50
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

51
FTPTrusted Path/Channels

• Addresses functional requirements for
• trusted communications path between users and the
  TSF and
• trusted channel between TSF and other trusted IT
  products

52
FTP Families

• FTP_ITC Inter TSF trusted channel
• FTP_TRP Trusted path
• a direct path between users and the TSF

53
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.)

54
FCS families

• FCS_CKM Cryptographic key management
• FCS_COP Cryptographic operation

55
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

56
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)

57
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

58
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

59
CC Assurance

• Configuration Management
• Delivery Operation
• Development

• Guidance Documents
• Life Cycle Support
• Tests
• Vulnerability Assessment

60
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)

61
(No Transcript)
62
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

63
Why EAL 1 is considered basic

• So little is known about the products 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

64
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

65
Canadian Common Criteria Evaluation and
Certification Scheme
66
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

67
CCS Framework

• SCC Accreditation of IT ET Facilities
• CSE Approval of CCS ITSEFs gtgtCCEFs
• CCEFs will Evaluate IT products
• CSE will Certify CCEF results

68
A Framework for Commercial ITS Evaluation and
Testing

• Basic Quality System
• Management Structure
• Documented Procedures

General requirements for the Competence of
Calibration Testing Laboratories ISO Guide 25,
CAN-P-4
69
A Framework for Commercial ITS Evaluation and
Testing

• ITS Knowledge and Skills

Guidelines for the Accreditation of ITS
Evaluation and Testing Facilities (CAN-P-1591)
General requirements for the Competence of
Calibration Testing Laboratories ISO Guide 25,
CAN-P-4
70
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

Guidelines for the Accreditation of ITS
Evaluation and Testing Facilities (CAN-P-1591)
General requirements for the Competence of
Calibration Testing Laboratories ISO Guide 25,
CAN-P-4
71
A Framework for Commercial ITS Evaluation and
Testing
CC Based Product (Phase I) and System (Phase
II) Evaluations and Certifications
Secure Electronic Business Testing / Approvals?
Biometric Testing / Approvals?
PKI CertificatePolicy Approvals?
System Vulnerability Analysis?
CBA Testing?
Guidelines for the Accreditation of ITS
Evaluation and Testing Facilities (CAN-P-1591)
General requirements for the Competence of
Calibration Testing Laboratories ISO Guide 25,
CAN-P-4
72
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

73
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)

74
The Big Picture
75
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 CCEFs are here today to help you
  acquire Security and Assurance.

76
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/info
  security/
• has evaluated at EAL1 http//www.entrust.com/trued
  elete/index.htm

77
Links

• Common Criteria Support Environment
• ccse.cesg.gov.uk/
• Protection Profiles - WEB site
• www.radium.ncsc.mil/tpep/library/protection_profil
  es
• 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

78
CSE Approved CCEFs

• CGI Information Systems and Management
  Consultants Inc.
• POC Mr Andrew Pridham Tel [phone]
• E-mail andrew.pridham_at_cgi.ca
• DOMUS ITSL, a division of LGS Group Inc.
• POC Mr Bill Dziadyk Tel (613) 230 - 6285
• E-mail Bill_Dziadyk_at_LGS.com
• EWA - Canada Ltd,
• POC Mr Paul Zatychec Tel (613) 230 - 6067 Ex.
  227
• E-mail pzatychec_at_ewa-canada.com

79
Questions?