1 cmsc 426-626: common criteria for computer/it systems prof. krishna sivalingam oct 23, 2006
TRANSCRIPT
![Page 1: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/1.jpg)
1
CMSC 426-626:Common Criteria for Computer/IT Systems
Prof. Krishna Sivalingam
Oct 23, 2006
![Page 2: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/2.jpg)
2
Common Criteria
Commoncriteria.org Commoncriteriaportal.org
• Lists CC v3.1 (and older versions)
Originally released in 1998 An International Standards Organisation
(ISO) standard for security evaluation of software products
IT product vendors use the CC as a benchmark for product security
![Page 3: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/3.jpg)
3
NIAP
National Information Assurance Partnership (NIAP) is a joint venture between NIST (nist.gov) and NSA (nsa.gov)
Goal: “increase the level of consumer trust in information systems and networks” from http://www.nsa.gov/ia/industry/niap.cfm
One service: Common Criteria Evaluation and Validation Scheme (CCEVS) that “focuses on meeting the security testing, evaluation, and assessment needs of both IT products and consumers.”
![Page 4: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/4.jpg)
4
Security concepts and relationships
From CC Part 1 (of v3.1)
![Page 5: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/5.jpg)
5
Evaluation concepts & relationships
From CC Part 1 (of v3.1)
![Page 6: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/6.jpg)
6
CC Process
A user creates Packages or “Protection Profile” for a desired security product
The PP describes the product’s protection needs
Written by the user (e.g. government, banking industry, vendor’s marketing group, product inventor)
Describes security aspects needed in an IT product
![Page 7: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/7.jpg)
7
CC Protection profile (in Combined Federal Criteria)
Rationale• Protection policy and
regulations
• Information protection philosophy
• Expected threats
• Environmental assumptions
• Intended Use Functionality
• Security Features
• Security Services
• Available security mechanisms
Assurance• Profile-specific assurances
• Profile-independent assurances
Dependencies• Internal
• External
![Page 8: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/8.jpg)
8
CC Protection Profile
Introduction Product/System Family Description: Generic
description of family of products. Product/System Family Security Environment –
intended use, environment of use, threats to assets, organizational security policies, etc.
Security Objectives IT Security Requirements – Functional and
Assurance Rationale
![Page 9: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/9.jpg)
9
What happens with PP?
A vendor develops an IT product based on the requirements set in the PP
Vendor then prepares a “security target” document that describes the security and assurance aspects of the product.• Can relate Security Target to Specs. In the
Protection Profile
Security Target can also be written independent of a PP and sold along with the IT product
![Page 10: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/10.jpg)
10
CC Package
A package is a named set of security requirements. A package is either • a functional package, containing only SFRs (Security
Functional Requirements) or
• an assurance package, containing only SARs (Security Assurace Requirements)
• But, not both.
Examples of Assurance packages are the EALs (Evaluation Assurance Level), than run from EAL1 (lowest) through EAL7 (highest)• EAL1 through EAL4 are most common
![Page 11: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/11.jpg)
11
Security Target, contd.
From CC, part I:
“The Security Target begins with describing the assets and the threats to those assets. The Security Target then describes the countermeasures (in the form of Security Objectives) and demonstrates that these countermeasures are sufficient to counter these threats: if the countermeasures do what they claim to do, the threats are countered.”
![Page 12: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/12.jpg)
12
Security Target (per Comb Fed Crit.)
Rationale• Implementation
fundamentals
• Information protection philosophy
• Countered Threats
• Environmental Assumptions
• Intended Use Functionality
• Security features
• Security services
• Security mechanisms selected
Assurance• Target-specific assurances
• Target-independent assurances
Dependencies• Internal
• External
![Page 13: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/13.jpg)
13
Security Target Introduction: description of the target of evaluation (TOE) at three
different abstraction levels Conformance: If the ST is conformant with any PPs or packages Security problem definition: Threats, Assumptions, etc. Security objectives: Extended components definition: describes components not
described in Part 2 or Part 3 of CC document Security requirements: Present security objectives in standard
requirements format TOE Summary specifications: How functional requirements are
implemented and met and how assurance reqts. Are met Rationale: Sec Objectives Rationale, Sec. Reqts. Rationale, TOE
Summary Spec. Rationale, etc.
Before and during evaluation, ST states “what is to be evaluated?” After evaluation, ST states “what was evaluated?”
![Page 14: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/14.jpg)
14From CC Part 1 (of v3.1)
![Page 15: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/15.jpg)
15
Classes in Common Criteria
Functionality (11)• Security audit (FAU)• Communications (FCO)• Crypto support (FCS)• User data protection (FDP)• Identification &
Authentication (FIA)
• Sec. Mgmt (FMT)• Privacy (FPR)• Protection of trusted
security functions (FPT)• Resource utilization (FRU)• Trusted Path (FTP)
• TOE Access (FTA)
Assurance (10)• Configuration Management• Delivery and operation• Development• Guidance documents• Life-cycle support
• Testing• Vulnerability Assessment• Maintenance of Assurance• Protection profile evaluation• Security target evaluation
![Page 16: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/16.jpg)
16
Classes
Classes are broken down into families, which are broken down into components
![Page 17: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/17.jpg)
17
Classes, contd.
![Page 18: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/18.jpg)
18
Components
![Page 19: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/19.jpg)
19
EAL Levels
EAL1: Functionally Tested EAL2: Structurally Tested; Applicable to systems
with low-moderate assurance needs, but not enough development record (e.g legacy systems)• Based on High-Level Design Analysis & Sec. Fn. Analysis
EAL3: Methodically Tested & Checked• Use of devt. Environment controls and config. Mgt
EAL4: Methodically Designed, Tested & Reviewed• Includes Low-level design, complete interface description,
and subset of implementation• Informal model of security policy• Windows 2000, XP, Red Hat Enterprise Linux (RHEL)
Version 4 Update 1 AS and Red Hat Enterprise Linux (RHEL) Version 4 Update 1 WS
![Page 20: 1 CMSC 426-626: Common Criteria for Computer/IT Systems Prof. Krishna Sivalingam Oct 23, 2006](https://reader036.vdocuments.net/reader036/viewer/2022083005/56649f115503460f94c2399f/html5/thumbnails/20.jpg)
20
EAL Levels, contd.
EAL5: Semi-formally Designed and Tested EAL6: Semi-formally Verified Design and
Tested EAL7: Formally Verified Design and Tested
• Formal functional spec. and high-level design
• Implementation representation be used as testing basis
• Independent confirmation of developer’s test results
• Extremely high-risk situations and requires substantial security engineering