463 2 Information Technology Security Evaluation Computer Security

463. 2 Information Technology Security Evaluation Computer Security II CS 463/ECE 424 University of Illinois

IT Security Evaluation • Evaluate a system or system design to determine its resilience to attack • Important for many (perhaps most) IT systems • Discussion in two parts based on the Common Criteria – Model and Assurance Requirements – Functional Requirements 2

463. 2. 1 Model and Assurance Requirements

Common Criteria • The Common Criteria for Information Technology Security Evaluation (CC) establishes a common language for specifying security requirements in IT products and systems as well as a rigorous approach for evaluating security features. • ISO/IEC Standard 15408, copyrights held by 10 governments. • Evolved from US Trusted Computer System Evaluation Criteria (TCSEC aka Orange Book 1983 -1999) and European Information Technology Security Evaluation Criteria (ITSEC, 1991 -2001) 4

General Model Security Concepts 5

General Model Evaluation Concepts 6

Roles and Artifacts Roles Artifacts • Sponsor requests and supports evaluation • Developer produces TOE • Evaluator evaluates PP, ST, or TOE • Evaluation Authority issues certification • Consumer uses evaluation to determine fitness for their application • Security Assurance Requirements (SARs) • Security Functional Requirements (SFRs) • Protection Profile (PP) is an implementation-independent description of security needs • Security Target (ST) is an implementation-dependent statement of security needs • Target Of Evaluation (TOE) 7

Evaluation Stages 8

The Evaluation Assurance Levels (EALs) 1. 2. 3. 4. 5. 6. 7. Functionally tested Structurally tested Methodically tested and checked Methodically designed, tested, and reviewed Semiformally designed and tested Semiformally verified design and tested Formally verified design and tested 9

Example: Linux Evaluation (Part 1 of 3) • TOE: Red Hat Enterprise Linux Version 5. 1 on SGI hardware • Assurance level: EAL 4+ • ST uses these PPs: – Controlled Access Protection Profile (CAPP) mode: no mandatory access control – Labeled Security Protection Profile (LSPP) mode: with role-based and mandatory access control – Role-Based Access Control Protection Profile (RBACPP) [CAPP, LSPP, RBACPP, Red. Hat. ST, Red. Hat. Eval] 10

Example: Linux Evaluation (Part 2 of 3) • Sponsor: SGI • Developers: SGI and Red Hat • Evaluator: atsec Information Security Corporation, a Common Criteria Testing Laboratory (CCTL) • Evaluation Authority: NIST with the National Voluntary Laboratory Assessment Program (NVLAP) – Validators: The Aerospace Corporation and Noblis 11

Example: Linux Evaluation (Part 3 of 3) • Red Hat Enterprise Linux 5 Server. • SGI Altix XE servers (200 and 300 series, Xeon EM 64 T/x 86_64 based). Examples are the Altix XE 250 and Altix XE 320. • SGI Altix 400 and 4000 series (Itanium 2/ia 64 based) consisting of a customer selected combination of the following blade types: Compute/Memory, Memory-only, Base I/O, PCI-X expansion, PCI-Express expansion 12

Common Criteria Parts • • Part 1, Introduction and General Model Part 2, Security Functional Requirements Part 3, Security Assurance Requirements Common Evaluation Methodology [CC 1, CC 2, CC 3, CEM] 13

Security Functional Requirements (SFRs) • The functional requirements are levied on those functions of the TOE that are specifically in support of IT security, and define the desired security behaviour. • Examples: requirements for – identification, – authentication, – security audit, – non-repudiation of origin. 14

Security Assurance Requirements (SARs) • Assurance that the security objectives are achieved by the selected security functions is derived from the following two factors: – confidence in the correctness of the implementation of the security functions, i. e. , the assessment whether they are correctly implemented; and – confidence in the effectiveness of the security functions, i. e. , the assessment whether they actually satisfy the stated security objectives. 15

Lecture Plan • First we discuss SARs, using the development requirements as an illustration. • Second we discuss SFRs, using audit and privacy as illustrations. 16

Specification Styles • Three types of specification style are mandated by this class: – Informal – Semiformal – Formal • The functional specification and TOE design documentation are always written in either informal or semiformal style. • Ambiguity in these specifications is reduced by using an increased level of formality. 17

Informal • An informal specification is written as prose in natural language. • Natural language is used here as meaning communication in any commonly spoken tongue (e. g. Dutch, English, French, German). • An informal specification is not subject to any notational or special restrictions other than those required as ordinary conventions for that language (e. g. grammar and syntax). • While no notational restrictions apply, the informal specification is also required to provide defined meanings for terms that are used in a context other than that accepted by normal usage. 18

Semiformal Specification • A semiformal specification is written in a restricted syntax language and is typically accompanied by supporting explanatory (informal) prose. • The restricted syntax language may be a natural language with restricted sentence structure and keywords with special meanings, or it may be diagrammatic (e. g. data-flow diagrams, state transition diagrams, entity-relationship diagrams, data structure diagrams, and process or program structure diagrams). • Whether based on diagrams or natural language, a set of conventions must be supplied to define the restrictions placed on the syntax. 19

Formal Specification • A formal specification is written in a notation based upon well-established mathematical concepts, and is typically accompanied by supporting explanatory (informal) prose. • These mathematical concepts are used to define the syntax and semantics of the notation and the proof rules that support logical reasoning. • The syntactic and semantic rules supporting a formal notation should define how to recognize constructs unambiguously and determine their meaning. • There needs to be evidence that it is impossible to derive contradictions, and all rules supporting the notation need to be defined or referenced. 20

Security Assurance Requirements • Assurance classes I – Protection Profile (PP) – Security Target (ST) • Assurance classes II – – – Development ADV Guidance documents AGD Life-cycle support ALC Security Target evaluation ASE Tests ATE Vulnerability assessment AVA • Evaluation Assurance Levels (EALs) 21

EAL Definition 22

Protection Profiles (PPs) • A PP defines an implementation-independent set of IT security requirements for a category of TOEs. • Such TOEs are intended to meet common consumer needs for IT security. • Consumers can therefore construct or cite a PP to express their IT security needs without reference to any specific TOE. 23

Security Targets (STs) • An ST contains the IT security requirements of an identified TOE and specifies the functional and assurance security measures offered by that TOE to meet stated requirements. • The ST for a TOE is a basis for agreement between the developers, evaluators and, where appropriate, consumers on the security properties of the TOE and the scope of the evaluation. 24

Development • Development defines requirements for the stepwise refinement of the TOE Security Function (TSF) from the TOE summary specification in the ST down to the actual implementation. 25

Guidance Documents • Guidance documents define requirements directed at the understandability, coverage and completeness of the operational documentation provided by the developer. – For users – For administrators 26

Life Cycle Support • Life-cycle support is an aspect of establishing discipline and control in the processes of refinement of the TOE during its development and maintenance. • Confidence in the correspondence between the TOE security requirements and the TOE is greater if security analysis and the production of the evidence are done on a regular basis as an integral part of the development and maintenance activities. 27

Delivery and Operation • Delivery and operation defines requirements for the measures, procedures, and standards concerned with secure delivery, installation, and operational use of the TOE, ensuring that the security protection offered by the TOE is not compromised during transfer, installation, startup, and operation. 28

Tests • Testing provides assurance that the TSF behaves as described (in the functional specification, TOE design, and implementation representation). 29

Vulnerability Assessment • Vulnerability assessment defines requirements directed at the identification of exploitable vulnerabilities. • Specifically, it addresses those vulnerabilities introduced in the construction, operation, misuse, or incorrect configuration of the TOE. 30

Families, Components, and Elements for Assurance Class II • Each assurance class II (Development, Guidance Documents etc. ) is defined by a hierarchy. • Illustration (from Version 2. 2 of CC) – Class: Development ADV – Family: Functional Specification ADV_FSP – Component: Informal Functional Specification ADV_FSP. 1 – Element: The developer shall provide a functional specification ADV_FSP 1. 1 31

Development Families 32

Development Families and Their Leveling Components The components are numbered in increasing order of formality; functional specification illustrates. 33

Functional Specification Leveling Components • • ADV_FSP. 1 Informal functional specification ADV_FSP. 2 Fully defined external interfaces ADV_FSP. 3 Semiformal functional specification ADV_FSP. 4 Formal functional specification 34

Elements of Informal Func Spec ADV_FSP. 1 • ADV_FSP. 1. 1 D The developer shall provide a functional specification. • ADV_FSP. 1. 1 C The functional specification shall describe the TSF and its external interfaces using an informal style. • ADV_FSP. 1. 2 C The functional specification shall be internally consistent. • ADV_FSP. 1. 3 C The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing details of effects, exceptions and error messages, as appropriate. • ADV_FSP. 1. 4 C The functional specification shall completely represent the TSF. • ADV_FSP. 1. 1 E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. • ADV_FSP. 1. 2 E The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements. 35

Reading • [CC 1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction and general model. Version 3. 1. • [CC 3] Common Criteria for Information Technology Security Evaluation – Part 3: Security assurance requirements. Version 3. 1. • [Red. Hat. Eval] Common Criteria Evaluation and Validation Scheme Validation Report SGI Red Hat Enterprise Linux Version 5. 1, NIST and NSA. Version 1. 0, 2008. 36

Discussion • Is it possible to build a completely secure system? • What is the relationship between security evaluation and risk analysis? 37

463. 2. 2 Functional Requirements

Some Classes of Systems Evaluated using CC • • Access control devices and systems Boundary protection devices and systems Databases Smart cards Key management systems Operating systems Digital signature products 39

Example: Security Audit Review SFR for Linux (Part 1 of 3) • The protection profile provides for a collection of requirements for the TOE. • Here is Audit Review functional requirement FAU_SAR. 1 as given in the Common Criteria: – The TSF shall provide [assignment: authorised users] with the capability to read [assignment: list of audit information] from the audit records. • Here is the instantiation in LSPP: – The TSF shall provide authorized administrators with the capability to read all audit information from the audit records: FAU_SAR. 1. 1 40

Example: Security Audit Review SFR for Linux (Part 2 of 3) • Instantiation of FAU_SAR. 1 in RBACPP: – The TSF shall provide authorized RBAC administrators with the capability to read the following audit information from the audit records: a)Date and Time of Audit Event b)The User. ID responsible for the Event and optionally the role membership which enabled the user to perform the event successfully c)The access control operation and the object on which it was performed. d)The outcome of the event (success or failure) e)The User Session Identifier or Terminal Type 41

Example: Security Audit Review SFR for Linux (Part 3 of 3) • Instantiation of FAU_SAR. 1 in the Linux ST: – The TSF shall provide authorized administrator roles with the capability to read all audit information, including the following, from the audit records: a)Date and Time of Audit Event b)The User. ID responsible for the Event and optionally the role membership which enabled the user to perform the event successfully c)The access control operation and the object on which it was performed. d)The outcome of the event (success or failure) e)The User Session Identifier or Terminal Type 42

Examples of CC Evaluations (Part 1 of 2) • PGP Universal Server with Gateway and Key Management v 2. 9 running on Fedora Core 6 (EAL 2) • Trusted Platform Module Atmel AT 97 SC 3201 (EAL 3+) • Groove Workspace, Groove Enterprise Management Server, and Groove Enterprise Relay Server, Version 2. 5 (EAL 2+) • Oracle Internet Directory 10 g (10. 1. 4. 0. 1) (EAL 4+) • Symantec Endpoint Protection Version 11. 0 (EAL 2+) • S 3 CC 9 LC 16 -bit RISC Microcontroller for Smart Card, Revision 2 (EAL 5+) 43

Examples of CC Evaluations (Part 2 of 2) • TCOS Passport Version 2. 0 Release 2 EAC/SLE 66 CLX 800 PE (EAL 4+) • Marine Core Public Key Infrastructure Framework Version 2. 1 (EAL 4+) • Microsoft Windows Server 2003 SP 2 including R 2, Standard, Enterprise, Datacenter, x 64, and Itanium Editions; Windows XP Professional SP 2 and x 64 SP 2; Windows XP Embedded SP 2 (EAL 4+) • Microsoft Windows Vista and Windows Server 2008 (EAL 1) 44

Example: Security Audit [CC 2] version 2. 2 45

Security Audit Analysis FAU_SAA • Class Behavior (Security Audit): Security auditing involves recognising, recording, storing, and analysing information related to security relevant activities (i. e. activities controlled by the TSP). The resulting audit records can be examined to determine which security relevant activities took place and whom (which user) is responsible for them. • Family Behavior (Security Audit Analysis): This family defines requirements for automated means that analyse system activity and audit data looking for possible or real security violations. This analysis may work in support of intrusion detection, or automatic response to an imminent security violation. 46

FAU_SAA. 1 Potential Violation Analysis • Potential violation analysis: basic threshold detection on the basis of a fixed rule set is required. • Running case study: credit card fraud detection. • Card events reach fraud detection TOE security function which must meet FAU_SAA. 1 functional requirement. 47

FAU_SAA. 2 Profile Based Anomaly Detection • Profile based anomaly detection: the TSF maintains individual profiles of system usage, where a profile represents the historical patterns of usage performed by members of the profile target group. – Use of the credit card during daytime hours after a long pattern of use only on weekends and evenings. – Use of the credit card for unusual purposes such as new types of purchases. 48

FAU_SAA. 3 Simple Attack Heuristics • Simple attack heuristics, the TSF shall be able to detect the occurrence of signature events that represent a significant threat to TSP enforcement. – Think about it for discussion. 49

FAU_SAA. 4 Complex Attack Heuristics • Complex attack heuristics: the TSF shall be able to represent and detect multi-step intrusion scenarios. The TSF is able to compare system events (possibly performed by multiple individuals) against event sequences known to represent entire intrusion scenarios. – Think about it for discussions. 50

Stylized Requirements • 1. 2: Accumulation or combination of [assignment: subset of defined auditable events] known to indicate a potential security violation • My 1. 2: Accumulation or combination of purchase events known to indicate a potential security violation 51

Stylized Requirements • 2. 1 The TSF shall be able to maintain profiles of system usage, where an individual profile represents the historical patterns of usage performed by the member(s) of [assignment: the profile target group]. • 2. 2 The TSF shall be able to maintain a suspicion rating associated with each user whose activity is recorded in a profile, where the suspicion rating represents the degree to which the user’s current activity is found inconsistent with the established patterns of usage represented in the profile. • 2. 3 The TSF shall be able to indicate an imminent violation of the TSP when a user’s suspicion rating exceeds the following threshold conditions [assignment: conditions under which anomalous activity is reported by the TSF]. 52

Stylized Requirements • My 2. 1 The TSF shall be able to maintain profiles of system usage, where an individual profile represents the historical patterns of usage performed by the member(s) of credit card users. • My 2. 3 The TSF shall be able to indicate an imminent violation of the TSP when a user’s suspicion rating exceeds the following threshold conditions: (1) purchases made on weekdays after one year of non-use on weekdays and (2) purchases outside categories represented in last year of use. 53

Privacy FPR 54

Anonymity FPR_ANO • This family ensures that a user may use a resource or service without disclosing the user’s identity. The requirements for anonymity provide protection of the user identity. Anonymity is not intended to protect the subject identity. FPR_ANO. 1 Anonymity, requires that other users or subjects are unable to determine the identity of a user bound to a subject or operation. FPR_ANO. 2 Anonymity without soliciting information enhances the requirements of FPR_ANO. 1 Anonymity by ensuring that the TSF does not ask for the user identity. 55

Pseudonymity FPR_PSE • This family ensures that a user may use a resource or service without disclosing its user identity, but can still be accountable for that use. FPR_PSE. 1 Pseudonymity requires that a set of users and/or subjects are unable to determine the identity of a user bound to a subject or operation, but that this user is still accountable for its actions. FPR_PSE. 2 Reversible pseudonymity, requires the TSF to provide a capability to determine the original user identity based on a provided alias. FPR_PSE. 3 Alias pseudonymity, requires the TSF to follow certain construction rules for the alias to the user identity. 56

Unlinkability FPR_UNL • This family ensures that a user may make multiple uses of resources or services without others being able to link these uses together. FPR_UNL. 1 Unlinkability, requires that users and/or subjects are unable to determine whether the same user caused certain specific operations. 57

Unobservability FPR_UNO (Part 1 of 2) • This family ensures that a user may use a resource or service without others, especially third parties, being able to observe that the resource or service is being used. FPR_UNO. 1 Unobservability, requires that users and/or subjects cannot determine whether an operation is being performed. FPR_UNO. 2 Allocation of information impacting unobservability, requires that the TSF provide specific mechanisms to avoid the concentration of privacy related information within the TOE. Such concentrations might impact unobservability if a security compromise occurs. 58

Unobservability FPR_UNO (Part 2 of 2) • Further levels FPR_UNO. 3 Unobservability without soliciting information, requires that the TSF does not try to obtain privacy related information that might be used to compromise unobservability. FPR_UNO. 4 Authorised user observability, requires the TSF to provide one or more authorised users with a capability to observe the usage of resources and/or services. 59

Reading • [CC 2] Common Criteria for Information Technology Security Evaluation – Part 2: Security functional requirements. Version 3. 1. – See particularly Chapter 14 Privacy • [Red. Hat. ST] Red Hat Enterprise Linux Version 5. 1 Security Target for CAPP, RBAC and LSPP Compliance, SGI. Version 1. 9, 2008. • [Red. Hat. Eval] Common Criteria Evaluation and Validation Scheme Validation Report SGI Red Hat Enterprise Linux Version 5. 1, NIST and NSA. Version 1. 0, 2008. • [Red. Hat. ST] Red Hat Enterprise Linux Version 5. 1 Security Target for CAPP, RBAC and LSPP Compliance, SGI. Version 1. 9, 2008. • [LSPP] Labeled Security Protection Profile, National Security Agency. Issue 1. b, 8 October 1999. • [Jackson 07] Under Attack: Common Criteria has Loads of Critics but is it Getting a Bum Rap? Government Computer News, 2007. 60

Discussion (Part 1 of 2) • Continue the development of the credit card audit SFR by adding – FAU_SAA. 3 Simple Attack Heuristics: – FAU_SAA. 4 Complex Attack Heuristics 61

FAU_SAA. 3 for Credit Card ST • FAU_SAA. 3. 1 The TSF shall be able to maintain an internal representation of the following signature events [assignment: a subset of system events] that may indicate a violation of the enforcement of the SFRs. • FAU_SAA. 3. 2 The TSF shall be able to compare the signature events against the record of system activity discernible from an examination of [assignment: the information to be used to determine system activity]. • FAU_SAA. 3. 3 The TSF shall be able to indicate a potential violation of the enforcement of the SFRs when a system event is found to match a signature event that indicates a potential violation of the enforcement of the SFRs. 62

FAU_SAA. 4 for Credit Card ST • FAU_SAA. 4. 1 The TSF shall be able to maintain an internal representation of the following event sequences of known intrusion scenarios [assignment: list of sequences of system events whose occurrence are representative of known penetration scenarios] and the following signature events [assignment: a subset of system events] that may indicate a potential violation of the enforcement of the SFRs. • FAU_SAA. 4. 2 The TSF shall be able to compare the signature events and event sequences against the record of system activity discernible from an examination of [assignment: the information to be used to determine system activity]. • FAU_SAA. 4. 3 The TSF shall be able to indicate a potential violation of the enforcement of the SFRs when system activity is found to match a signature event or event sequence that indicates a potential violation of the enforcement of the SFRs. 63

Discussion (Part 2 of 2) • Evaluation is a costly process (often measured in hundreds of thousands of US dollars) -- and the vendor's return on that investment is not necessarily a more secure product. • The effort and time necessary to prepare evaluation evidence and other evaluation-related documentation is so cumbersome that by the time the work is completed, the product in evaluation is generally obsolete. • Industry input, including that from organizations such as the Common Criteria Vendor Forum generally has little impact on the process as a whole. • Evaluation does not cover the actual software just the paperwork. [Jackson 07] 64