1 Common Criteria Ravi Sandhu Edited by Duminda Wijesekera.

1

Common Criteria

Ravi SandhuEdited by Duminda Wijesekera

2

Common Criteria: 1998-present TSEC retired in 2000, CC became de-

facto standard International unification

CC v2.1 is ISO 15408 Flexibility Separation of

Functional requirements Assurance requirements

Marginally successful so far v1 1996, v2 1998, widespread use ???

3

Common Criteria

4

Class, Family, Component, Package

5

Security Functional Requirements Identification and authentication Cryptographic support, Security management, Protecting ToE access and security functions Communication, Privacy, Trusted paths, Channels, User data protection, Resource utilization Audit Forensic analysis

6

Security Assurance Requirements Life cycle support,

1. Pre requirements: Guidance documents2. Requirements analysis for consistency and

completeness3. Vulnerability analysis4. Secure design5. Development6. Testing

Functional, security specifications vulnerability

7. Delivery and operations8. Maintenance

Assurance maintenance Configuration management

7

CC Methodology ToE Security Policy (TSP): set of rules

regulating asset management, protection and distributed in system

ToE Security Function (TSF): HW+SW and firmware used for the correct enforcement of TSP

Protection profile (PP): set of (security) requirments

Security target (ST): set of (security) requirements to be used as a evaluation

8

CC Introductory: Section 1 of 8 ST identification: precisely stated

information required to identify ST ST overview: narrative acceptable as

a a standalone description of the ST CC Conformance:

Claim: a statement of conformance to the CC.

Part 2 conformance: if using only functional requirements

9

CC Product/system description: Section 2 of 8

Describes the ToE, Boundaries

Logical physical

Scope of evaluation

10

CC Product/system family environment: Section 3 of 8

Assumptions of intended usage Threat and their agents Organizational security policy that

must be adhered to in providing protection

11

CC Security objective: Section 4 of 8

Objectives for the product/system: Traceable to identified threats and/or organizational policy

Objectives for the environment: must be traceable to threats not completely encountered by the

system and policies or assumptions not completely met by

the system

12

CC IT Security requirements: Section 5 of 8

Functional security requirements: from CC

Security assurance requirements: must be augmented by the author as addendums to the EAL

13

CC Product/summary specification: Section 6 of 8

A statement of security function and how these are met as functional requirements

A statement of assurance requirements and how these are met as

14

CC PP Claims: Section 7 of 8

Claims of conformance

15

CC Rationale: Section 8 of 8 Explains various aspects of CC Security objective rationale Security requirements rationale Summary specification rationale Rationale for not meeting all

dependencies PP claims rationale: explains the

differences between objectives, requirements and conformance claims

16

Seven Levels of Evaluation EAL1: functionally tested EAL2: structurally tested EAL3: methodically tested and checked EAL4: methodically designed, tested and

reviewed EAL5: semi-formally designed and tested EAL6: semi-formally designed, verified and

tested EAL7: formaly verified, designed and tested

17

The evaluation process Controlled by C Evaluation

Methodology (CEM) and NIST Many labs are accredited by NIST and

charge a fee for evaluation Vendor selects a lab to evaluate the

PP The vendor and the lab negotiates the

process and a schedule and the lab issues a rating

18

Evaluation and testing

Security must be designed in Security can be retrofitted

Impractical except for simplest systems

Evaluation levels Black box Gray box White box

19

EAL, TSEC and ITSEC

20

Future of Testing

Continues to evolve Quality of Protection (QoP): some

research efforts to measure security qualitatively.

21

The SSE-CMM Model 1997-present

System Security Capability Maturity Model

A process oriented model for developing secure systems

Capability models define requirements for processes

CC and its predecessors define requirements for security

22

SSE-CMM Definitions Process capability: the range of

expected results by following the process

Process performance: a measure of the actual results received

Process maturity: the extent to which a process is explicitly defined, managed, measured, controlled and effective

23

Process areas of SSE-CMM Administrator controls Assess impact Asses threat Asses vulnerability Build assurance arguments Coordinate security Monitor system security posture Provide security input Specify security needs Verify and validate security

24

Example: assessing threats

Identify natural threats Identify human threats Identify threat units and measures Access threat agent capability Asses threat likelihood Monitor threats and their

characteristics

25

Five capability maturity levels Represents process maturity1. Performed informally: base processes are

performed2. Planned and tracked: has project-level

definition, planning and performance verification

3. Well-defined: focused on defining, refining a standard practice and coordinating across organization

4. Continuously improving: organizational capability and process effectiveness improved.