Chapter 21: Evaluating Systems Dr. Wayne Summers Department of Computer Science Columbus State University [email protected] http://csc.colstate.edu/summers
Jan 02, 2016
Chapter 21: Evaluating Systems
Dr. Wayne Summers
Department of Computer Science
Columbus State University
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