Ch.18 Evaluating Systems - Part 2 - Hunjoo, Lee Sogang Database Laboratory

Sogang Database Laboratory FIPS 140: 1994-Present FIPS 140-X : security requirement for cryptographic module Each standard defines 4 increasing, qualitative security levels FIPS 140-1 In 1994, US government & Canadian Security Establish (CSE) Evaluation standard for cryptographic modules Cover basic design and documentation, module interfaces, roles, services, physical security, software security, OS security, key management, cryptographic algorithms, electromagnetic interference/electromagnetic compatibility, self-testing FIPS 140-2 In 2001, updated from FIPS 140-1 Sponsored by Cryptographic Module Evaluation (CMV) program authentication, a finite state model, physical security, the operational environment, design assurance, mitigation of other attacks Cryptographic module A set of hardware, firmware, software providing cryptographic logic or processes The evaluation automatically includes the operating system Sogang Database Laboratory

Sogang Database Laboratory FIPS 140-2 Security Levels Security level 1 The lowest level of security cryptographic encryption algorithm = FIPS-approved algorithm No required physical security mechanisms in the module Security level 2 Greater physical security than level 1 Requiring tamper-evident 1) coatings or seals, or pock-resistant locks Role-based authentication Allows software cryptography in multi-user timeshared systems 1) Tamper-evident : 개봉한 흔적이 남는 Sogang Database Laboratory

Sogang Database Laboratory FIPS 140-2 Security Levels Security level 3 Enhanced physical security generally available in many commercial security products Prevent potential intruders’ access to critical security parameters Identity-based authentication as well as stronger requirements for entering and outputting critical security parameters Security level 4 The highest security level Envelope of protection around the cryptographic module Plus functional requirements for Level 3 Sogang Database Laboratory

Sogang Database Laboratory Impacts of FIPS CMV program improved The quality and security of cryptographic modules 164 modules and 332 algorithms had been tested 50% modules : security flaws 95% modules : documentation errors 25% algorithms : security flaws 65% algorithms : documentation errors Before using modules and algorithms, vendors must correct Sogang Database Laboratory

The Common Criteria: 1998-Present Common Criteria (CC) Each Country has different standards One standards from TCSEC(US), CTCPEC & ITSEC(Canada), etc… Standard 15408 of ISO De facto security evaluation standard in US The methodology has 3 parts CC documents CC Evaluation Methodology (CEM) Country-specific methodology (Evaluation Scheme or National Scheme) Overview of methodology Functional requirements Assurance requirements Evaluation Assurance Levels (EALs) Sogang Database Laboratory

The Common Criteria: 1998-Present The CC uses the following terms TOE : Target of Evaluation Definition 18-2. A TOE Security Policy (TSP) is a set of rules that regulate how assets are managed, protected, and distributed within a product or system Definition 18-3. The TOE Security Functions (TSF) is a set of consisting of all hardware, software, and firmware of the product or system that must be relied on for the correct enforcement of the TSP TSF is a generalization of the TCSEC concept of TCB Sogang Database Laboratory

Overview of the Methodology 2 kinds of evaluations Evaluations of protection profiles Evaluations of products or systems against Security Targets (STs) Definition 18-4. A CC protection profile (PP) is an implementation-independent set of security requirements for a category of products/systems that meet specific consumer needs PP consists of 6 sections Introduction Products or System Family Description Product or System Family Security Environment Security objectives IT Security Requirements Rationale Federal Criteria protection profile Sogang Database Laboratory

Overview of the Methodology PP consists of 6 sections (Cont’d) Introduction PP Identification PP Overview : a narrative summary of the PP Products or System Family Description Description of the type and the general IT features of the products Product or System Family Security Environment Assumption about the intended usage and the environment of use Threats to the assets requiring protection, in terms of threat agents, types of attacks, and assets that are the targets of the attacks Organizational security policies Security objectives Security objective for the product or system Security objective for the environment IT Security Requirements The security functional requirements The security assurance requirements Rationale The security objective rationale The security requirements rationale Sogang Database Laboratory

Overview of the Methodology Definition 18-5. A security target (ST) is a set of security requirements and specifications to be used as the basis for evaluation of an identified product or system 2 approaches to developing ST Based on a PP Directly from the CC Sogang Database Laboratory

Overview of the Methodology ST consists of 8 sections Introduction (3 parts) ST Identification Precise information used to control and identify the ST and the product/system to which refers it ST Overview A narrative summary of the ST CC Conformance Claim A statement of conformance to the CC Part 2 conformant if it uses only functional requirements found in part 2 of the CC Part 2 extended if it uses extended requirements defined by vendor Part 3 conformant, Part 3 extended Conformant to a PP only if it’s compliant with all parts of the PP Sogang Database Laboratory

Overview of the Methodology ST consists of 8 sections (Cont’d) Products or System Description A description of the TOE as an aid to understanding its security requirements Address the product/system type and the scope and boundaries of the TOE Product or System Family Security Environment Assumptions about the intended usage and environment of use Threats to the assets requiring protection Organizational security policies Security Objectives The security objectives for the product/system The security objectives for the environment Sogang Database Laboratory

Overview of the Methodology ST consists of 8 sections (Cont’d) IT Security Requirements The security functional requirements The security assurance requirements Product or System Summary Specification A statement of security functions and a description of how these functions meet the functional requirements A statement of assurance measures specifying how the assurance requirements are met PP Claims Makes claims of conformance with the requirements of one or more protection profiles Sogang Database Laboratory

Overview of the Methodology ST consists of 8 sections (Cont’d) Rationale The security objective rationale The security requirements rationale The TOE summary specification rationale A rationale for not meeting all dependencies The PP claims rationale Sogang Database Laboratory

Sogang Database Laboratory CC Requirements CC defines Functional & assurance requirements Then, build EALs out of the assurance requirements Functional and assurance requirements are divided into classes based on common purpose Classes are broken into smaller groups (families) Families contain components Definition of detailed requirements Definition of dependent requirements Definition of hierarchy requirements Sogang Database Laboratory

CC Security Functional Requirements 11 classes of security functional requirements Each having one or more families Hierarchical structure - General group - Consisting of families having same contents - Grouping of a set of security requirements - Same security goals in a class - Different strength/closeness Dictate a specific set of security requirements - Same goals in a family - Different strength/closeness Sogang Database Laboratory

CC Security Functional Requirements 11 classes Class FAU : Security Audit, 6 families audit automatic response, audit data generation, audit analysis, audit review, audit event selection, audit event storage Class FCO : Communication, 2 families Nonrepudiation of origin & nonrepudiation of receipt Class FCS : Cryptographic Support, 2 families Cryptographic key management & cryptographic operation Class FDP : User Data Protection, 13 families 2 types of security policies (access control & information flow policies) Sogang Database Laboratory

CC Security Functional Requirements 11 classes (Cont’d) Class FIA : Identification and Authentication, 6 families Authentication failure, user attribute definition, specification of secrets, user authentication, user identification, user/subject binding Class FMT : Security Management, 6 families Management of security attributes, management of TSF data, management of roles, management of functions in TSF, revocation Class FPR : Privacy Anonymity, pseudonymity, unlinkability, unobservability Class FPT : Protection of Security Functions, 16 families Focused on TSF data protection Integrity of the mechanisms and data Sogang Database Laboratory

CC Security Functional Requirements 11 classes (Cont’d) Class FRU : Resource Utilization, 3 families Fault tolerance, resource allocation, priority of service Class FTA : TOE Access, 6 families Functional requirements for management of user sessions Class FTP : Trusted Path, 2 families Inter-TSF trusted channel Trusted path Sogang Database Laboratory

Assurance Requirements 10 security assurance classes Class APE : Protection Profile Evaluation Class ASE : Security Target Evaluation Class ACM : Configuration Management (CM) Class ADO : Delivery and Operation Class ADV : Development Class AGD : Guidance Documentation Class ALC : Life Cycle Class ATE : Tests Class AVA : Vulnerabilities Assessment Class AMA : Maintenance of Assurance 3 : Protection profile, security targets, maintenance of assurance 7 : Assurance Sogang Database Laboratory

Evaluation Assurance Levels 7 levels of assurance EAL1 : Functional Tested Threats are not serious & correct operation EAL2 : Structurally Tested Low to moderate of independent assurance is required EAL3 : Methodically Tested and Checked High-level design and configuration management EAL4 : Methodically Designed, Tested, and Reviewed Low-level design, informal model EAL5 : Semiformally Designed and Tested Full implementation to the inputs for security function analysis EAL6 : Semiformally Verified Design and Tested Structured presentation of the implementation EAL7 : Formally Verified Design and Tested A formal presentation of the functional specification and high-level design Sogang Database Laboratory

Evaluation Assurance Levels Matching of the level of trust of various methodologies TCSEC ITSEC CC Other D E0 No equivalent EAL1 Private testing labs C1 E1 EAL2 OS for FIPS 140-2 L2 C2 E2 EAL3 OS for FIPS 140-2 L3 B1 E3 EAL4 OS fro FIPS 140-3 L4 B2 E4 EAL5 B3 E5 EAL6 A1 E6 EAL7 Sogang Database Laboratory

Comparison between CC & TCSEC Level of trust TCSEC C1 C2 B1 B2 B3 A1 CC EAL2 EAL3 EAL4 EAL5 EAL6 EAL7 DAC MAC Data Integrity Auditing Formally Verified Design Verified Design Sogang Database Laboratory

Sogang Database Laboratory SSE-CMM: 1997-Present System Security Engineering Capability Maturity Model Process-oriented methodology for developing secure systems based on the Software Engineering Capability Maturity Model (SE-CMM) Developed by security experts team from US government & industries ISO standard 21827 in 2002 Similarity between capability model-based and assurance model-based Capability model : how mature a process is, maturity levels CC type : how much assurance is provided, levels of trust Can be used to assess the capability of security engineering processes Can support assurance evidence Increase confidence in the trustworthiness of product/system Sogang Database Laboratory

Sogang Database Laboratory The SSE-CMM Model Processes & maturity levels Processes define what needs to be accomplished by security engineering process Maturity levels categorize how well the process accomplishes its goals. Definition 18-6. A process capability is the range of expected results that can be achieved by following the process. It is a predictor of future project outcomes. Definition 18-7. Process performance is a measure of the actual results achieved. Definition 18-8. Process maturity is the extent to which a process is explicitly defined, managed, measured, controlled, and effective. Sogang Database Laboratory

Sogang Database Laboratory The SSE-CMM Model SSE-CMM contains 11 process areas Administer Security Controls Assess Impact Assess Security Risk Assess Threat Assess Vulnerability Build Assurance Argument Coordinate Security Monitor System Security Posture Provide Security Input Specify Security Needs Verify and Validate Security Sogang Database Laboratory

Sogang Database Laboratory The SSE-CMM Model 11 additional process areas from SE-CMM Ensure Quality Manage Configuration Manage Project Risk Monitor and Control Technical Effort Plan Technical Effort Define Organization’s Systems Engineering Process Improve Organization’s Systems Engineering Process Manage Systems Engineering Support Environment Provide Ongoing Skills and Knowledge Coordinate with Suppliers Sogang Database Laboratory

Sogang Database Laboratory The SSE-CMM Model 5 Capability Maturity Levels increasing process maturity are as follows: Performed informally: perform base processes Planned and tracked: address project-level definition, planning, performance, verification issues Well-defined: focus on defining, refining standard practice and coordinating it across organization Quantitatively controlled: focus on establishing measurable quality goals, objectively managing their performance Continuously improving: improve organizational capability, process effectiveness Sogang Database Laboratory

Sogang Database Laboratory Using the SSE-CMM Begin with process area Identify area goals, base processes If all processes present, determine how mature base processes are Assess them against capability maturity levels May require interacting with those who use the base processes Do this for each process area Level of maturity for area is lowest level of the base processes for that area Tabular representation (called Rating Profile) helps communicate results Sogang Database Laboratory

Sogang Database Laboratory Reference M. Bishop, Introduction to Computer Security, Addison Wesley. Seog Park, et.al., Research on Evaluation Standards of Security Function for Distributed Database Systems, Korea Information Security Agency K.Ferraiolo, et.al., Building a Case for Assurance from Process, proceedings of the 21st National Information Systems Security Conference, pp. 49-61 Sogang Database Laboratory