I. Overview of the Common Criteria ------------------------------------------ COMMON CRITERIA for IT Security Evaluation From www.commoncriteriaportal.org Purpose: - to allow comparison between security evaluations of IT products by consumers Evaluation in the context of security properties Key terms: def: *Target of Evaluation* (TOE) is Examples: ------------------------------------------ A. TOE ------------------------------------------ TOE REPRESENTATION AND GUIDANCE Represented as: - as source code, - as a boxed product, to be installed - an installed and operational version Guidance: may restrict the configurations allowed ------------------------------------------ What kind of thing could be an example of configuration guidance? B. Evaluation of the TOE ------------------------------------------ EVALUATION Based on Security Targets = Security Requirements Security Target contains: - a threat model (assets, threats) - countermeasures for each threat Countermeasure types: - for the TOE - for the operational environment Countermeasures for the TOE are summarized in ------------------------------------------ For the airline reservation system, what is an example of a countermeasure for the TOE? What is an example of a countermeasure for the operational environment? ------------------------------------------ HOW IS CORRECTNESS OF THE TOE DETERMINED? - Testing - Examining the design - Examining the physical security of the development environment ------------------------------------------ Why would we care about the physical security of the DEVELOPMENT environment? II. Security Requirements Specification in the Common Criteria A. Protection Profiles ------------------------------------------ PROTECTION PROFILE (PP) Describe a type of TOE E.g., firewalls Acts as a contract between consumers and developers Steps: 1. Consumer writes PP IT Necurity Needs --> PP (Threat Model's SFRs) 2. Consumer checks PP for consistency and completeness against SFRs 3. Developer writes Security Target (ST) PP --> ST 4. Developer checks that ST refines the PP 5. Developer builds a system, satisfying the ST ST --> System ------------------------------------------ What is consistency? What is Completeness? What is a refinement? What is meant by satisfction? So, if you need a system satisfying the TOE, can you use the developer's system? ------------------------------------------ PROTECTION PROFILE OUTLINE I. Introduction, A. Reference (title, authors, date) B. TOE overview 1. Usage and Major Security Features 2. TOE Type (name) 3. Available software/hardware/firmware to be used as a basis II. Conformance claims (to other PPs...) III. Security Problem Definition A. Threats B. OSPs = security rules, procedures, guidelines for operation C. Assumptions IV. Security Objectives A. Security Objectives for the TOE B. Security Objectives for the Operational Environment C. Security Objectives Rationale V. Extended Components Definition (not described in CC Parts 2 or 3) VI. Security Requirements A. Security Functional Requirements B. Security Assurance Requirements C. Security Requirements Rationale ------------------------------------------ B. CC Part 2, Security Functional Requirements 1. terms ------------------------------------------ CC PART 2 TERMINOLOGY def: a *subject* is def: an *object* is def: *user data* is def: *TSF data* is - Authentication data - User attributes - Object attributes - Subject attributes - Information attributes ------------------------------------------ 2. classes of security functional requirements a. FAU audit requirements ------------------------------------------ AUDIT REQUIREMENTS (FAU) FROM CC PART 2 Security Alarms FAU_ARP.1.1 The TSF shall take [assignment: list of actions] upon detection of a potential security violation. Security Audit Data Generation FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment: other audit relevant information]. FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event. ------------------------------------------ Is any of that ambiguous? ------------------------------------------ OTHER REQUIREMENTS IN CC PART 2 Auditing (FAU) Security Audit Analysis Anomoly Detection Simple Attack Heuristics Complex Attack Heuristics Audit Review Audit Selection Audit Event Storage Communication (FCO) Non-repudiation of Origin Non-repudiation of Receipt Cryptographic Support (FCS) Cryptographic Key Management Cryptographic Operation User Data Protection (FDP) Access Control Policy Access Control Functions Data Authentication FDP_DAU.1.1 The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of [assignment: list of objects or information types]. FDP_DAU.1.2 The TSF shall provide [assignment: list of subjects] with the ability to verify evidence of the validity of the indicated information. ... Information Flow Control Policy Rollback Stored Data Integrity ------------------------------------------ ------------------------------------------ MORE REQUIREMENTS IN CC PART 2 Identification and Authentication (FIA) ... Security Management (FMT) ... Privacy (FPR) Anonymity Psuedonymity Unlinkability Unobservability Protection of the TSF (FPT) ... Resource Utilization (FRU) ... TOE Access (FTA) ... Trusted Paths/Channels (FTP) ... ------------------------------------------