Transcript A Security Business Case for the Common Criteria

A Security Business Case
for the
Common Criteria
Marty Ferris
Ferris & Associates, Inc.
202-234-9683
[email protected]
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 SecurityCentral 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”
?
Security
Gap
Assets
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
CTCPEC
3
NIST’s
MSFR
US
TCSEC
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 WG3
• 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
• Detailed Req’ts
• Requirements for
Protection Profiles
& Security Targets
• Assurance Classes
• Assurance Families
• Assurance
Components
• Detailed Req’ts
• 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 (NonRepudiation) (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 V3.01 EAL3
Firewall in Canada
• CC-based
Evaluations
Underway
• 3 EAL2 Firewalls
– Checkpoint
– CISCO Pix
– Lucent Managed
Firewall
Product evaluations
(cont.)
• “OS” evaluations underway:
–
–
–
–
IBM RS6000 - C2 OS
IBM NT 4.0 - C2 OS
IBM SQL Server - C2 DB
Sybase Anywhere Adaptive Server - C2
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?