A Security Business Case for the Common Criteria

A Security Business Case for the Common Criteria Marty Ferris & Associates, Inc. 202 -234 -9683 jmferris@erols. com

Outline • Security Problem Overview – Bounding a Moving Target • Role of Standards • Common Criteria

Security Concepts and Relationships Threats Evaluation Owners create value Exposures to Assets reduce require Confidence that Security Functions leads to giving Assurance

Bound the Exposure Problem – Organizational Security Management • Develop Policies and Standards • Develop Operational Security Practices • On-Going Assessment of Security Program

Operational Security Practices Defining “Good Enough” • Risk/Acceptability Model – Security Program as Starting Place – Ongoing assessment and refinement • Marketplace dependence for IT Security Solutions • Security Infrastructures Evolve

Security Infrastructures • Physical Security • “People” Security – Internal Personnel Security – Customer’s Security Role • IT Product, Systems and Services Security • Anomaly Processing – Identification of Security Events

Old Security Infrastructures Application Security Computer Security Communications Security Physical/People

Computer Security. Central Technical Security Infrastructure • Application Security – Smart Cards – Browsers • Virtual Private Networks – Firewalls – IPSec – TLS/SSL • Public Key Infrastructure

New Security Infrastructures Application Security Communications Security Computer Security Physical/People

Bad Security ?

Good Security ?

Security “Reality” ?

} Assets Security Gap Actual Asset Exposure (Reality) Asset Protection Policy (Perceived) } Protected Assets

The Security Management Challenge: Bounding a Moving Target • Building and Maintaining Security Infrastructures • Managing “Security Gaps” • Security Planning – Support both IT Vision and Security Policies – Marketplace dependence – Best Value Solutions

Role of Security Standards • Support Management Process for New IT Services(? ) – Business case for IT Investment – Cost Containment Strategies • • • Requirements and specifications Equivalence and Interoperability Voluntary consensus vs “de facto” Limited operational practices context Compliance assurances

Standards Development Process • Business need driven • Scope – within a business context • Balanced participation – open to buyers and sellers of technology as well as technology experts • Document requirements/specifications • Voting process for consensus and resolving disagreements • Public comment

What is the Common Criteria • International Standard Meta-language for describing IT security requirements – Features and assurances – Supports both buyer “I need” and Seller “I provide” • How “one applies” the Meta language is: – Constituent (Seller or Buyer) dependent • Security Management Tool

Infrastructure Support for Common Criteria • International Registry of Buyer and Seller requirements • Assurances Laboratories for both Buyer and Seller • International Mutual Acceptance of Features and Assurances

Common Criteria Potential Benefits • Better Tool to Bound problem(s) – More accurate definition of requirements – Threat and policy – IT and Non-IT assumptions – Interoperability and equivalence – Features and Assurances

Common Criteria Potential Benefits (cont. ) • Market friendlier • Friendlier to integrating both established and emerging security technologies and practices • Supports buyers IT business case development • Supports Seller’s business case to bring IT services to market

A Brief History of Common Criteria 1985 1990 1997 Canadian Initiatives US TCSEC CTCPEC 3 NIST’s MSFR European National & Regional Initiatives Federal Criteria ITSEC 1. 2 ISO Initiatives Common Criteria Project 1998 ISO Standard

Common Criteria as International Standard • 1990 - Working Group 3, Subcommittee 3, Joint Technical Committee 1 begins addressing IT security • 1993 - Member Nations pool resources and assist WG 3 • Common Criteria (CC) Version 2 provided, May 1998 • CC, Version 2, as International Standard ISO/IEC 15408 being reviewed and voted upon

Overview of Common Criteria Structure Part 3 Security Assurance Requirements Part 2 Security Functional Requirements Part 1 Introduction & Model • Functional Classes • Functional Families • Introduction to Approach • Functional Components • Terms & Model • Assurance Classes • Assurance Families • Assurance Components • Detailed Req’ts • Requirements for Protection Profiles & Security Targets • Eval. Assur. Levels Part 4 Registry of Protection Profiles

Common Criteria Look and Feel • Official title - Common Criteria for Information Technology Security Evaluations • Part 1, Introduction • Part 2, Functional Requirements – Desired information technology security behavior

Common Criteria Look and Feel (cont. ) • Part 3, Assurance Requirements – Measures providing confidence that the Security Functionality is effective and correctly implemented • CC intro at <http: //csrc. nist. gov/cc/info/ccsum/content. htm>

Functional Requirements Classes • FAU -- Security Audit (35) • FCO -- Communication (Non. Repudiation) (4) • FCS -- Cryptographic Support (40) • FDP -- User Data Protection (46) • FIA -- Identification & Authentication (27) • FPR -- Privacy (Anonymity, etc. ) (8) • FPT -- Protection of Trusted Security Functions (43) • FRU -- Resource Utilization (8) • FTA -- TOE Access (11) • FTP -- Trusted Path (2)

Evaluation Assurance Levels • Levels - EAL 1 through 7 – increasing rigor and formalism from 1 up to 7 • Seven classes addressed for each level – Configuration Management – Delivery and operation – Development – Guidance documents – Life-cycle support – Testing – Vulnerability Assessment

Vendor/Customer Requirements • Protection Profiles (PP) – User requirements (“I need”) – Multiple implementations may satisfy • Security Targets (ST) – Vendor claims (“I will provide”) – Implementation specific • Methodology – First, threats and policy stated – then Features and Assurances selected

CC Product Validation and Evaluation Scheme • Targeted to begin in 1999 • Using security specifications from Common Criteria (CC) • Procedures based upon Common Evaluation Methodology (CEM) • Testing and evaluations performed by NVLAP accredited commercial labs • International recognition of evaluations (Mutual Recognition) • Results posted on NIAP’s WWW page

Laboratories • NSA’s TTAP laboratories are the Interim CC labs • ARCA Systems, BAH, COACT, CSC, Cygnacom Solutions, NSTL and SAIC • Will have to reapply for CCEVS accreditation • Mutual Recognition between Canada, France, Germany and UK and US for CC-based evaluations • Netherlands are developing their scheme • Australia and New Zealand applying

Product evaluations As of 19 Oct. 98 • CC-based Evaluation Completed: – ITT Dragonfly EAL 2 Guard – Milkyway Black Hole V 3. 01 EAL 3 Firewall in Canada • CC-based Evaluations Underway • 3 EAL 2 Firewalls – Checkpoint – CISCO Pix – Lucent Managed Firewall

Product evaluations (cont. ) • “OS” evaluations underway: – IBM RS 6000 - C 2 OS – IBM NT 4. 0 - C 2 OS – IBM SQL Server - C 2 DB – Sybase Anywhere Adaptive Server - C 2 DB

Assistance • Classes – schedule on web page (niap. nist. gov) – CC familiarization, 1 day – PP development, 4 days • CC Toolbox – CCDA version 1, (ST), Oct. 98 – PDA version 2, (PP), Dec. 98 – PDA version 1, July 99 – CCDA version 2, Jan. 00

Right Time for Common Criteria?