CMSC 426-626: Common Criteria for Computer/IT SystemsCommon CriteriaNIAPSecurity concepts and relationshipsEvaluation concepts & relationshipsCC ProcessCC Protection profile (in Combined Federal Criteria)CC Protection ProfileWhat happens with PP?CC PackageSecurity Target, contd.Security Target (per Comb Fed Crit.)Security TargetSlide 14Classes in Common CriteriaClassesClasses, contd.ComponentsEAL LevelsEAL Levels, contd.1CMSC 426-626:Common Criteria for Computer/IT SystemsProf. Krishna SivalingamOct 23, 20062Common CriteriaCommoncriteria.orgCommoncriteriaportal.org•Lists CC v3.1 (and older versions)Originally released in 1998An International Standards Organisation (ISO) standard for security evaluation of software productsIT product vendors use the CC as a benchmark for product security3NIAPNational 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.cfmOne 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.”4Security concepts and relationshipsFrom CC Part 1 (of v3.1)5Evaluation concepts & relationshipsFrom CC Part 1 (of v3.1)6CC ProcessA user creates Packages or “Protection Profile” for a desired security productThe PP describes the product’s protection needsWritten by the user (e.g. government, banking industry, vendor’s marketing group, product inventor)Describes security aspects needed in an IT product7CC Protection profile (in Combined Federal Criteria)Rationale•Protection policy and regulations•Information protection philosophy•Expected threats•Environmental assumptions•Intended UseFunctionality•Security Features•Security Services•Available security mechanismsAssurance•Profile-specific assurances•Profile-independent assurancesDependencies•Internal•External8CC Protection ProfileIntroductionProduct/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 ObjectivesIT Security Requirements – Functional and AssuranceRationale9What happens with PP?A vendor develops an IT product based on the requirements set in the PPVendor 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 ProfileSecurity Target can also be written independent of a PP and sold along with the IT product10CC PackageA 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 common11Security 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.”12Security Target (per Comb Fed Crit.)Rationale•Implementation fundamentals•Information protection philosophy•Countered Threats•Environmental Assumptions•Intended UseFunctionality•Security features•Security services•Security mechanisms selectedAssurance•Target-specific assurances•Target-independent assurancesDependencies•Internal•External13Security TargetIntroduction: description of the target of evaluation (TOE) at three different abstraction levelsConformance: If the ST is conformant with any PPs or packagesSecurity problem definition: Threats, Assumptions, etc. Security objectives:Extended components definition: describes components not described in Part 2 or Part 3 of CC documentSecurity requirements: Present security objectives in standard requirements formatTOE Summary specifications: How functional requirements are implemented and met and how assurance reqts. Are metRationale: 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?”14From CC Part 1 (of v3.1)15Classes in Common CriteriaFunctionality (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 evaluation16ClassesClasses are broken down into families, which are broken down into components17Classes, contd.18Components19EAL LevelsEAL1: Functionally TestedEAL2: 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. AnalysisEAL3: Methodically Tested & Checked•Use of devt. Environment controls and config. MgtEAL4: 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 WS20EAL Levels, contd.EAL5: Semi-formally Designed and TestedEAL6: Semi-formally Verified Design and TestedEAL7: 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
View Full Document