; booth
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

booth

VIEWS: 17 PAGES: 79

  • pg 1
									CACR CC Briefing
           Stephen Booth
 Computer and System Security Section
Communications Security Establishment
         Stephen .Booth@cse-cst.gc.ca
            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
November 8, 1999     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
November 8, 1999        CACR Briefing                 4
             CC PPs and STs/TOEs
                       Protection Profile
                         (What I Need)
Customer


Vendor

            Security Target                   Target of Evaluation
             (What I Have)                        (the Product)

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

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

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

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

  November 8, 1999         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
November 8, 1999      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!


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



November 8, 1999         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?
November 8, 1999         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


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


November 8, 1999      CACR Briefing                   19
                   What does it mean?

• Extracts from the MRA document




November 8, 1999         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”




November 8, 1999          CACR Briefing                    21
         CC Document Structure
   • Part 1        Introduction and general model

   • Part 2        Security functional requirements

   • Part 3        Security assurance requirements


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

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


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

November 8, 1999     CACR Briefing          25
CC Functionality
           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

November 8, 1999   CACR Briefing            27
            Requirements Structure
                    Class


Family                                Family


                   Component          Component

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

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

November 8, 1999   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
November 8, 1999    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)
November 8, 1999      CACR Briefing               33
                   Selected FIA families

• FIA_UID:               User identification

• FIA_UAU:               User authentication

• FIA_SOS:               Specification of secrets


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


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


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



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

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



November 8, 1999     CACR Briefing                39
                   FCO Families
• FCO_NRO: Non-repudaition of origin
• FCO_NRR: Non-repudiation of receipt




November 8, 1999      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
November 8, 1999     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
November 8, 1999       CACR Briefing           42
                   FPR: Privacy
• Addresses those functions that protect
  against discovery and misuse of identity by
  others




November 8, 1999      CACR Briefing             43
                   FPR Families
• FPR_ANO: Anonymity
• FPR_PSE: Pseudonymity
• FRP_UNL: Unlinkability
• FPR: Unobservability


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

November 8, 1999    CACR Briefing               45
                   Selected FRU family

  • FRU_RSA:             Resource allocation




November 8, 1999          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
November 8, 1999            CACR Briefing              47
               Selected FPT families
•    FPT_FLS: Fail Secure
•    FPT_RCV: Trusted Recovery
•    FPT_RVM: Reference Mediation
•    FPT_SEP: Domain Separation




November 8, 1999      CACR Briefing    48
                   FTA: TOE Access
• Addresses functional requirements for
  controlling the establishment of a user‟s session




November 8, 1999        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
November 8, 1999   CACR Briefing             50
     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



November 8, 1999   CACR Briefing            51
                   FTP Families
• FTP_ITC: Inter TSF trusted channel
• FTP_TRP: Trusted path
   – a direct path between users and the TSF




November 8, 1999      CACR Briefing            52
     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.)
November 8, 1999      CACR Briefing              53
                   FCS families

• FCS_CKM: Cryptographic key
        management
• FCS_COP:          Cryptographic operation



November 8, 1999      CACR Briefing           54
         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
November 8, 1999    CACR Briefing                  55
     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)
November 8, 1999     CACR Briefing            56
   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

November 8, 1999     CACR Briefing               57
   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



November 8, 1999   CACR Briefing              58
                   CC Assurance
• Configuration              •   Guidance Documents
  Management                 •   Life Cycle Support
• Delivery & Operation       •   Tests
• Development                •   Vulnerability Assessment




November 8, 1999      CACR Briefing                     59
    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)

November 8, 1999    CACR Briefing               60
Assurance Class      Assurance                         Components
                      Family
                                 EAL1   EAL2   EAL3       EAL4         EAL5     EAL6   EAL7
  Configuration      ACM_AUT                               1              1      2      2
  Management         ACM_CAP      1      2       3         4              4      5      5
                     ACM_SCP             1       1         2              2      2      3
   Delivery &        ADO_DEL             1       1         2              2      2      3
   Operation          ADO_IGS     1      1       1         1              1      1      1
  Development        ADV_FSP      1      1       1         2              3      3      4
                     ADV_HLD             1       2         2              3      4      5
                     ADV_IMP                               1              2      3      3
                     ADV_INT                                              1      2      3
                     ADV_LLD                                 1            1      2      2
                     ADV_RCR      1      1       1           1            2      2      3
                     ADV_SPM                                 1            3      3      3
     Guidance        AGD_ADM      1      1       1           1            1      1      1
    documents        AGD_USR      1      1       1           1            1      1      1
Life cycle support   ALC_DVS                     1           1            1      2      2
                     ALC_FLR                   (Flaw remediation procedures )
                     ALC_LCD                                 1            2      2      3
                     ALC_TAT                                 1            1      3      3
      Tests          ATE_COV             1       2           2            2      3      3
                     ATE_DPT                     1           1            2      2      3
                     ATE_FUN             1       1           1            1      2      2
                      ATE_IND     1      2       2           2            2      2      3
  Vulnerability      AVA_CCA                                              1      2      2
   assessment        AVA_MSU                     1           2            2      3      3
                     AVA_SOF             1       1           1            1      1      1
                     AVA_VLA             1       1           2            3      4      4
                      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
   November 8, 1999         CACR Briefing              62
 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
November 8, 1999     CACR Briefing              63
                   EAL1 versus EAL3
• EAL1 (Low Assurance)         • EAL3 (Medium Assurance)
   – “Functionally Tested”        – EAL1 plus…
   – Given a product with         – High Level Design
     Installation, Admin &        – Test
     User Guides.                   Plan, Procedures, Resul
   – Does it do what the            ts, Coverage, Depth, In
     Guides said it would?          dependent
                                  – Misuse, SOF, Obvious
                                    Vulnerabilities
November 8, 1999        CACR Briefing                   64
      Canadian Common Criteria
      Evaluation and Certification
                Scheme



November 8, 1999   CACR Briefing     65
                   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


November 8, 1999      CACR Briefing               66
                   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




November 8, 1999       CACR Briefing          67
                     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
November 8, 1999             CACR Briefing            68
                     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
November 8, 1999              CACR Briefing               69
     CC               A Framework for Commercial
    Based
   Product
   (Phase I)
                       ITS Evaluation and Testing
     and
   System
   (Phase II)
                   •The Canadian CCS will be the first
 Evaluations       program to build on this “foundation” in
     and
Certifications
                   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
November 8, 1999                CACR Briefing                 70
     CC                A Framework for Commercial
    Based
   Product
   (Phase I)
                        ITS Evaluation and Testing
     and
                     Secure
   System
   (Phase II)
                   Electronic     PKI
                    Business                  Biometric
 Evaluations                    Certificate                   System
                    Testing /                  Testing /                    CBA
     and                          Policy                   Vulnerability
                   Approvals?                 Approvals?                   Testing?
Certifications                  Approvals?                  Analysis?

             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
November 8, 1999                    CACR Briefing                              71
    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


November 8, 1999       CACR Briefing             72
             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)


November 8, 1999      CACR Briefing              73
                   The Big Picture
     Vendor          CCEF                 CCS     Consumer

    Produces        Evaluates         Certifies    Acquires

  IT Product       IT Product       Evaluation    Security &
     & ST             & ST           Results      Assurance




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

November 8, 1999    CACR Briefing             75
             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

November 8, 1999                 CACR Briefing                         76
                               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



November 8, 1999                CACR Briefing                  77
                 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
•   November 8, 1999            CACR Briefing                     78
                   Questions?
November 8, 1999     CACR Briefing   79

								
To top
;