Notes

Outline

Developing A Common Criteria Protection Profile Overview Preparation Development

Overview What is a PP? What is a ST? How are they used? How are they Related?

Protection Profile Definition Complete Set of Functional and Assurance Requirements to Address an Identified set of Security Objectives Reusable Set - Abstract to be Met by Various Implementations Statements of Wants and Needs

Security Target Definition Developer Response to Statement of Requirements Contains Requirements Similar to PP Specific Set - Based on Implementation Statement of “I Provide”

Protection Profile Usage Users (User Advocates) - State Real-World Requirements Developers - Gauge Market Research/Academia - State Good Security Sets Evaluators - Have Basis to Assess

Security Target Usage Users (User Advocates) - Compare Implementation to Stated Needs Developers - Communicate Provision Evaluators - Basis for Assessing                   - Basis for Resource Allocation

PP/ST Relationship “I want” vs “I provide” Generic vs Specific Requirements vs Specifications ST can be in Response to no PP - Developer states they meet requirements that customer has yet to communicate

Preparation Know the Target Technology Know General Security Objectives Know of Prior Work for Target Technology Build on that work Start from scratch

Protection Profile Structure Descriptive Front Matter Intended (Generic) Security Environment Security Objectives Requirements to Meet Objectives Rationale of How Requirements Meet Objectives

Protection Profile Structure: Descriptive Front Matter PP Name Abstract - Short Description Product Type and its Intended Usage General IT Security Characteristics

Protection Profile Structure: Intended Security Environment Threats Intending to Address/Counter Threat Agent Attack Asset Description of Organizational Security Policies Secure Use Assumptions

Protection Profile Structure: Security Objectives IT Security Objectives “Executive summary” of security capabilities provided by the TOE Drive the Security Function requirements Non-IT Objectives “Executive summary” of constraints on how TOE be operated Ultimately drive the details of the user and administrator documentation

PP Structure: Requirements to Meet Security Objectives Functional Desired Security Behavior of IT that can be observed by Investigating a TOE Assurance

Security Functional Requirements Select Security Functional Requirements Part 2 of the Common Criteria Agreed to as Useful and Evaluatable Tailor Security Functional Requirements Reconcile dependencies among Security Functional Requirements

CC Part 2 Structure Example

Functional Requirements Classes Security Audit (FAU) Communication (FCO) Cryptographic Services (FCS) User Data Protection (FDP) Identification and Authentication (FIA) Security Management (FMT)

Functional Requirements Families Contains Sets of Security Components Components in Family Share Security Objectives Components in Family Differ in Rigor or Emphasis

Functional Requirements Components Smallest Effective Group of Requirements Contains List of Evaluatable Statements called “Elements” Component is like a phrase in natural language Element is like a word in the phrase Component may have multiple “levels” Each could contain more functions, or Each could extend functions to more users

Tailoring SFRs Flexibility to Tailor Functional Requirement Components from Part 2 Through operations Three Types of Operations Assignment Selection Refinement

Assignment Operation Specification of a parameter filled in when component is used “Fill in the Blank” operation Allows PP writer to provide information relating to application of the requirement

Selection Operation Specification of elements selected from a list given in the component “Multiple Choice” operation Allows PP writer to select from a provided list of choices

Refinement Operation Addition of detail to component “Essay Question” operation Allows PP writer to specify additional detail to narrow the scope of a SFR

Rationale for SFRs Chosen Need to Consider Whether: Objectives address environment Requirements address Objectives Consistency Completeness Technical Soundness

Security Assurance Functional Assurance

Security Assurance An attribute of an IT product or system reflecting the confidence that can be placed in the ability of the security features of an IT product or system to enforce the security policy.

Requirements & Operations Choosing Assurance Requirements Part 3 of the Common Criteria Common security assurance measurement scale Operations on Assurance Requirements Refinement Completeness, Consistency & Technical Soundness

Assurance Classes Configuration management (ACM) Delivery and operation (ADO) Development (ADV) Guidance documents (AGD) Life cycle support (ALC) Tests (ATE) Assurance Maintenance (AMA) Vulnerability assessment (AVA)

Predefined Evaluation Assurance Packages Evaluation Assurance Levels (EALs) Uniformly increasing scale, seven levels Assurance obtained is balance of cost and feasibility Achieved by substitution and addition Possible to represent other combinations

Assurance Requirements Composition “Rules” Dependencies On other assurance and functional requirements Hierarchical Relationships Each assurance component level is a strict superset of the lower level(s) Operations Refinement (on components) Augmentation (on assurance packages)

Refinement Operation Refinement e.g. The CM system shall provide an automated means to ensure that only authorized changes are made to the TOE implementation representation. This shall be compatible with SCCS.

Augmentation Operation Flexibility to tailor Assurance Packages Evaluation Assurance Levels from Part 3 Meet specific needs Specify Part 3 assurance component(s) in addition to those in an Assurance Package higher component in the same family component from another family

IT Security Requirements Functional Assurance ……… and there’s more !

Extended Requirements Allowed in a ST and PP Functions and Assurance Flexibility to prescribe requirements not contained in either Part 2 or Part 3