Chapter 21: Evaluating Systems

Dr. Wayne Summers

Department of Computer Science

Columbus State University

Summers_wayne@colstate.edu

http://csc.colstate.edu/summers

2Goals of Formal Evaluation

Provide a set of requirements defining the security functionality for the system or product

Provide a set of assurance requirements that delineate the steps for establishing that the system or product meets its functional requirements.

Provide a methodology for determining that the product or system meets the functional requirements based on analysis of the assurance evidence.

Provide a measure of the evaluation result that indicates how trustworthy the product or system is with respect to the security functional requirements defined for it.

3TCSEC: 1983-1999

Trusted Computer System Evaluation Criteria (Orange Book):D, C1, C2, B1, B2, B3, A1

– Emphasized confidentiality

– TCSEC Functional Requirements• Discretionary Access control (DAC) • Object reuse requirements• Mandatory access control (MAC) (>=B1)• Label requirements (>=B1)• Identification and authentication requirements• Trusted path requirements (>=B2)• Audit requirements

4TCSEC: 1983-1999

TSEC Assurance Requirements

– Configuration management (>= B2)

– Trusted distribution (A1)

– TCSEC systems architecture (C1-B3) – mandate modularity, minimize complexity, keep TCB as small and simple as possible

– Design specification and verification (>=B1)

– Testing requirements

– Product documentation requirements

5TCSEC: 1983-1999

TCSEC Evaluation Classes

– C1 – discretionary protection

– C2 – controlled access protection

– B1 – labeled security protection

– B2 – structural protection

– B3 – security domains

– A1 – verified protection

6International Efforts and the ITSEC: 1991-2001 Information Technology Security Evaluation

Criteria - European Standard since 1991 (E0, E1, E2, E3, E4, E5, E6)– Did not include tamperproof reference

validation mechanisms, process isolation, principle of least privilege, well-defined user interface, and requirement for system integrity

– Did require assessment of security measures used for the developer environment during the development and maintenance, submission of code, procedures for delivery, ease of use analysis

7ITSEC

E1 – required a security target, informal description of architecture.

E2 – required informal description of the detailed design, configuration control, distribution control process

E3 – more stringent requirements on detail desing and correspondence between source code and security requirements

E4 – requires formal model of security policy, more rigorous structured approach to architectural and detailed design, and a design level vulnerability analysis

E5 – requires correspondence between detailed desing and source code and source code level vulnerability analysis

E6 – requires extensive use of formal methods

8Common Criteria: 1998-Present

CC – defacto standard for U. S. and many other countries; ISO Standard 15408

– TOE (target of evaluation) product/system that is the subject of the evaluation

– TSP (TOE Security Policy) – set of rules that regulate how assets are managed, protected, and distributed

– TSF (TOE Security Functions) – h’ware, s’ware, and firmware that must be relied on to enforce the TSP (generalization of TCSEC’s trusted computing base (TCB))

9Common Criteria

CC Protection Profile (PP) – implementation independent set of security requirements for a category of products/systems that meet specific consumer needs

– Introduction (PP Identification & PP Overview)

– Product/System Family Description

– Product/System Family Security Environment

– Security Objectives (product/system; environment)

– IT Security Requirements (functional and assurance)

– Rationale (objectives and requirements)

10Common Criteria

Security Target (ST) – set of security requirements and specifications to be used as the basis for evaluation of an identified product/system– Introduction (ST Identification & ST Overview)– Product/System Family Description– Product/System Family Security Environment– Security Objectives (product/system; environment)– IT Security Requirements (functional and assurance)– Product/System Summary Specification– PP Claims (claims of conformance)– Rationale (objectives, requirements, TOE summary

specification, PP claims)

11Common Criteria - Security Functional Requirements

Class FAU: Security Audit

Class FCO: Communication

Class FCS: Cryptographic Support

Class FDP: User Data Protection

Class FIA: Identification and Authentication

Class FMT: Security Management

Class FPR: Privacy

Class FPT: Protection of Security Functions

Class FRU: Resource Utilization

Class FTA: TOE Access

Class FTP: Trusted Path

12Common Criteria - Assurance Requirements

Class APE: Protection Profile Evaluation

Class ASE: Security Target Evaluation

Class ACM: Configuration Management

Class ADO: Delivery and Operation

Class ADV: Development

Class AGD: Guidance Documentation

Class ALC: Life Cycle

Class ATE: Tests

Class AVA: Vulnerability Assessment

Class AMA: Maintenance of Assurance

13Common Criteria – Evaluation Assurance Levels

EAL1: Functionally Tested

EAL2: Structurally Tested

EAL3: Methodically Tested and Checked

EAL4: Methodically Designed, Tested and Reviewed

EAL5: Semiformally Designed and Tested

EAL6: Semiformally Verified Design and Tested

EAL7: Formally Verified Design and Tested

14SSE-CMM: 1997-Present

System Security Engineering Capability Maturity Model – process-oriented methodology for developing secure systems based on SE-CMM

– Assess capabilities of security engineering processes

– Provide guidance in designing and improving them

– Provides an evaluation technique for an organization’s security engineering

15SSE-CMM Model

Process capability – range of expected results that can be achieved by following the process

Process performance – measure of actual results achieved

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

16SSE-CMM Process Areas

Administer Security Controls

Assess Impact

Assess Security Risks

Assess Threat

Assess Vulnerability

Build Assurance Argument

Coordinate Security

Monitor System Security Posture

Provide Security Input

Specify Security Needs

Verify and Validate Security

17SSE-CMM Capability Maturity Levels

Performed Informally – base processes are performed

Planned and Tracked – Project-level definition, planning, and performance verification issues are addressed

Well-Defined – focus on defining and refining standard practice and coordinating it across the organization

Quantitatively Controlled – focus on establishing measurable quality goals and objectively managing their performance

Continuously Improving – organizational capability and process effectiveness are improved