Chapter 21: Evaluating Systems Dr. Wayne Summers Department of Computer Science Columbus State University

2 Goals 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.

3 TCSEC:  Trusted Computer System Evaluation Criteria (Orange Book):D, C1, C2, B1, B2, B3, A1 Trusted Computer System Evaluation Criteria –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

4 TCSEC:  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

5 TCSEC:  TCSEC Evaluation Classes –C1 – discretionary protection –C2 – controlled access protection –B1 – labeled security protection –B2 – structural protection –B3 – security domains –A1 – verified protection

6 International Efforts and the ITSEC:  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

7 ITSEC  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

8 Common CriteriaCommon Criteria: 1998-Present  CC – defacto standard for U. S. and many other countries; ISO Standard –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))

9 Common Criteria  CC Protection Profile (PP) – implementation independent set of security requirements for a category of products/systems that meet specific consumer needs –Introduction (PP Indentification & 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)

10 Common 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 Indentification & 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)

11 Common 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

12 Common 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

13 Common 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

14 SSE-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

15 SSE-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

16 SSE-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

17 SSE-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