The Requirements and Evaluation of System Security Summer

The Requirements and Evaluation of System Security Summer 2008 11 Evaluating Security Systems 1

Computer Security Policy in the Past The Bell-La. Padula Model Non-hierarchical Discretionary policy DAC Hierarchical or Lattice Multilevel security MAC Trusted Computer System Evaluation (TCSEC) -- The Orange Book Do. D 5200. 28 -STD, Department of Defense, December 1985 • to provide technical hardware/firmware/software security criteria and associated technical evaluation methodologies in support of the overall ADP system security policy, evaluation and approval/accreditation responsibilities. Summer 2008 11 Evaluating Security Systems 2

TCSEC: The Orange Book SECURITY POLICY • must be enforced by the system. • rules to determine whether a given subject can gain access to an object. • systems must enforce – mandatory security policy – discretionary security controls (e. g. , need-to-know). Summer 2008 11 Evaluating Security Systems 3

The Orange Book MARKING • Access control labels associated with objects. • label identifies its sensitivity level (classification), and/or modes of access accorded subjects who may access it Summer 2008 11 Evaluating Security Systems 4

The Orange Book IDENTIFICATION • subjects must be identified. • access must be based on who is accessing information and classes of information authorized to access. • identification and authorization information must be securely maintained by the computer system and associated with every element that performs security-relevant action Summer 2008 11 Evaluating Security Systems 5

The Orange Book ACCOUNTABILITY • Audit information must be kept and protected so actions can be traced. • trusted system must record security-relevant events audit log. • capability to select audit events to be recorded to minimize expense of auditing and allow efficient analysis. • Audit data protected from modification and unauthorized destruction to permit detection and after-the-fact investigations of violations. Summer 2008 11 Evaluating Security Systems 6

The Orange Book ASSURANCE • must contain hardware and software mechanisms that can be independently evaluated to provide assurance that it enforces requirements. • collection of controls that perform the functions (typically embedded in the OS to carry out tasks securely). • basis for trust mechanisms clearly documented for independent examination of evidence to evaluate their sufficiency. Summer 2008 11 Evaluating Security Systems 7

The Orange Book CONTINUOUS PROTECTION • mechanisms that enforce the requirements continuously protected against tampering and unauthorized change. • no system is secure if basic hardware and software mechanisms subject to unauthorized modification or subversion. Summer 2008 11 Evaluating Security Systems 8

Levels Dealing with OS factors specified in the Orange Book From minimum D -- no test to show proper design and implementation To verified A – mathematical and scientifically tested

The Orange Book Class D: MINIMAL PROTECTION systems that have been evaluated but failed to meet requirements for higher class. Summer 2008 11 Evaluating Security Systems 10

The Orange Book Class C: DISCRETIONARY PROTECTION Need-to-know and audit capabilities for accountability of subjects and actions they initiate. Class (C 1): Discretionary Security Protection • DAC with Identification and Authentication (passwords) • Assurance (its own domain; testing for bypassing security) • Documentation Summer 2008 11 Evaluating Security Systems 11

The Orange Book Class C Class (C 2): Controlled Access Protection Users accountable for actions (audit trail, resource isolation) – DAC at single user level and no information on prior subject’s action released – Accounting for actions of user on objects Sumer 2008 11 Evaluating Security Systems 12

The Orange Book Class B: MANDATORY PROTECTION Class (B 1): Labeled Security Protection – informal statement of security policy model, data labeling, control over named subjects and objects – capability for accurate labeling of exported information. – flaws found in testing must be removed. Summer 2008 11 Evaluating Security Systems 13

The Orange Book Class B Class (B 2): Structured Protection Clearly defined / documented policy model DAC and MAC Covert channels addressed. Structured into protection-critical and non-critical elements. TCB interface well-defined and design / implementation allow thorough testing Authentication mechanisms strengthened, trusted facility management – system administrator and operator functions, – stringent configuration management controls. Relatively resistant to penetration. Summer 2008 11 Evaluating Security Systems 14

The Orange Book Class B Class (B 3): Security Domains control all access by subjects to objects and be tamperproof small enough to be analysed and tested (exclude code not essential to security policy enforcement and minimize its complexity). – security administrator supported, audit mechanisms expanded to signal security-relevant events – system recovery procedures required. – system highly resistant to penetration. Summer 2008 11 Evaluating Security Systems 15

The Orange Book Class A: VERIFIED PROTECTION Class (A 1): Verified Design Formal design specification and verification techniques and resulting high degree of assurance that the TCB correctly implemented. Start with a formal model of policy and formal top-level spec. of the design. Mathematical proof that model is consistent with axioms Abstract definitions of functions the TCB performs and of hardware or firmware mechanisms used to support separate execution domains Formal analysis techniques to be used to identify and analyze covert channels. Informal techniques may be used to identify covert timing channels Beyond Class (A 1) [Future dreams / nightmares] Summer 2008 11 Evaluating Security Systems 16

The “Rainbow” Series Trusted Computer System Evaluation criteria (TCSEC) (Orange) Trusted Network Interpretation (TNI) (Red) Password Management Guideline (Light Green) Glossary of Computer Security Terms (Dark Green) Magnetic Remanence Security Guidelines (Dark Blue) Guidance for Applying the Do. D Trusted Computer System Evaluation Criteria in Specific Environments (Yellow) Guidance for applying the TCSEC to specific environments Summer 2008 11 Evaluating Security Systems 17

PROBLEMS: Only for OS-like software on well defined and specified hardware • What if there was a new version of HW or SW? – TOE (Target of Evaluation). • How about other SW or HW such as: – Firewalls, – IDS, – Antivirus, etc

Common Criteria for Information Technology Security Evaluation (CCITSE) January 1996: US, UK, Germany, France, Canada, and the Netherlands released an evaluation standard for a multi-national marketplace. Version 2. 0 published in May 1998 adopted by ISO/IEC JTC 1 as ISO 15408 in June 1999 with minor, mostly editorial modifications in June, 1999. August 1999 CCIMB-99 -031 alligned with the ISO standard Sept 2006 and 2007 CC version consists of: – Part 1: Introduction and general model Release 1 – Part 2: Security functional requirements ] Release 2 – Part 3: Security assurance requirements } see http: //www. commoncriteriaportal. org/ Summer 2008 11 Evaluating Security Systems 19

Who did it? • • • Australia/New Zealand: The Defence Signals Directorate and the Government Communications Security Bureau respectively; Canada: Communications Security Establishment; France: Direction Centrale de la Sécurité des Systèmes d'Information; Germany: Bundesamt für Sicherheit in der Informationstechnik; Japan: Information Technology Promotion Agency Netherlands: Netherlands National Communications Security Agency; Spain: Ministerio de Administraciones Públicas and Centro Criptológico Nacional; United Kingdom: Communications-Electronics Security Group; United States: The National Security Agency and the National Institute of Standards and Technology. Summer 2008 11 Evaluating Security Systems 20

Do they Own it? Legal Notice: They contributed to its development. As the joint holders of the copyright in the Common Criteria for Information Technology Security Evaluation, version 3. 1 Parts 1 through 3, they hereby grant non-exclusive license to ISO/IEC to use CC 3. 1 in the continued development/maintenance of the ISO/IEC 15408 international standard. However, these governmental organisations retain the right to use, copy, distribute, translate or modify CC 3. 1 as they see fit. Summer 2008 11 Evaluating Security Systems 21

Scope of CC and TOE (Target of Evaluation) For evaluation of Security properties of IT products Software, firmware, hardware, or part : -- software application; operating system; −− A software application with an operating system and a workstation; − An operating system with a workstation; − A smart card or integrated circuit; − The cryptographic co-processor of a smart card integrated circuit; − A Local Area Network including all terminals, servers, network equipment and software; − A database application excluding the remote client software normally associated with it; Summer 2008 11 Evaluating Security Systems 22

Summer 2008 11 Evaluating Security Systems 23

Comments on figures/models Safeguarding assets is the responsibility of owners. Threat agents may abuse assets: hackers, users (making errors), computer processes and accidents. The owners perceive threats as potential for loss so that value could be reduced. Security-specific ones include: loss of confidentiality, integrity, and availability. Thhreats give rise to risks to assets, based on their likelihood of occurring and impact on the assets when it is realized. Countermeasures are then imposed to reduce the risks. These may be IT (firewalls and smart cards) and non-IT (such as guards and procedures). Owners of assets may be (held) responsible for assets and should be able to defend the decision to accept the risks of exposing the assets to threats. Summer 2008 11 Evaluating Security Systems 24

Further comments Two important elements demonstrate that: − the countermeasures are sufficient: if they do what they claim to do, the threats to the assets are countered; − if they are correct: they do what they claim to do. Many owners lack knowledge, expertise or resources to judge whether countermeasures are enough and correct; they may not wish to rely on the assertions of developers. Consumers may choose to increase their confidence in their countermeasures by ordering an evaluation. Summer 2008 11 Evaluating Security Systems 25

The Security Target and Security Functional Requirements ST: requirements and specifications for evaluation – – – describe assets and threats. state countermeasures (objectives to counter threats). divide countermeasures into: • security objectives: countermeasures for which correctness must be determined; • Non-IT objectives (Operational Environment): guards, procedures SFR: articulate security objectives A correct TOE (meeting SFRs) with a correct operational environment (meeting the security objectives) counter the threats. Summer 2008 11 Evaluating Security Systems 26

Protection Profile (PP) • defines an implementation-independent set of security requirements and objectives for a category of products or systems which meet similar needs for security. • intended to be reusable and define requirements known to be useful and effective. • developed to support definition of functional standards and formulating procurement specifications. • have been developed for many products firewalls, DBMS, etc. Summer 2008 11 Evaluating Security Systems 27

Security Target (ST) • Security objectives and requirements to be used as a basis for the evaluation of a TOE (product or system) • May claim conformance to one or more PP • Defines functional and assurance measures offered to meet the stated requirements • Forms the basis for an evaluation. Summer 2008 11 Evaluating Security Systems 28

Correctness of the TOE A TOE may be incorrectly designed and implemented, and contain errors that lead to vulnerabilities. By exploiting these, attackers may damage or abuse the assets. The vulnerabilities may arise from accidental errors made during development, poor design, addition of malicious code, poor testing etc. The Security Target is a structured description of the activities in Security Assurance Requirements (SAR) formulated in a standard language to ensure exactness and facilitate comparability Summer 2008 11 Evaluating Security Systems 29

Evaluation using CC Two types: • An ST evaluation: sufficiency of the TOE and the operational environment are determined; • A TOE evaluation: correctness of the TOE. Needs design documents and developer test results Apply SAR to evaluate Summer 2008 11 Evaluating Security Systems 30

Protection Profiles and Packages PP Protection Profile: Iimplementation-independent set of security requirements for a TOE that meet user needs. – For users to state their security needs – Can be a reusable Package of SFRs or SARs [not both] EAL Evaluation Assurance Level: An assurance package of components that represents a point on the assurance scale. ------------------------------------Consumers : • State security objectives and requirements for evaluating a TOE an ST • Specify the desired security functionality of a product as a PP and • Select an EAL Summer 2008 11 Evaluating Security Systems 31

How to Obtain a System • An organisation seeking a particular type of IT security product develops their security needs into a PP, evaluates and publishes it; • A developer takes this, writes an ST that claims conformance to the PP and has this ST evaluated; • The developer builds a TOE (or uses an existing one) and has this evaluated against the ST. • the developer can prove that the TOE is conformant to the security needs of the organisation: • The organisation can now acquire the TOE.

Consumers may be able to select a product or else: • State security objectives and requirements for evaluating a TOE an ST • Specify the desired security functionality of a product as a PP and • Select an EAL Summer 2008 11 Evaluating Security Systems 33

Role of Developers • Assist in evaluating TOE and identifying the ST satisfied by it. • Can then claim that the TOE conforms to the ST. One or more PPs may provide the requirements of a broad consumer base. • The CC helps determine the responsibilities and actions to help in evaluation of the TOE. It also defines the content and presentation of that evidence. Summer 2008 11 Evaluating Security Systems 34

Evaluators The CC has criteria to be used when forming judgement about the conformance of TOEs to their security requirements. The CC describes the actions to be carried out and the security functions on which to perform them but does not specify procedures to be followed Summer 2008 11 Evaluating Security Systems 35

CC General Model Consumers Part 1: Introduction and General Model Developers Evaluators For background information and reference purposes and for development of requirements and formulating security specifications for TOEs and guidance structure for PPs and STs Part 2: Security For guidance and For reference when Functional reference when interpreting statements Requirements formulating of functional requirements for requirements and security functions formulating functional specifications of TOEs Mandatory statement of evaluation criteria when determining whether TOE* effectively meets claimed security functions Part 3: Security For guidance Assurance when determining Requirements required levels of assurance Mandatory statement of evaluation criteria when determining assurance of TOEs and when evaluating PPs and STs Summer 2008 For reference when interpreting assurance requirements and determining assurance approaches of TOEs 11 Evaluating Security Systems 36

The Seven EALs EAL 1 - functionally tested • when confidence in correct operation is required, but threats are not viewed as serious. • when required to show care has been exercised in protection of personal information, etc. • provides evidence that TOE functions to documentation and provides protection. EAL 2 - Structurally Tested • developer must provide design information and test results. • effort is good commercial practices, so the impact on cost and time should be minimal. • when developers/users require a moderate level security without full development record EAL 3 - Methodically Tested and Checked • developer gains assurance from security engineering at the design stage. • applicable where a moderate level of independent assured security is required. • TOE and its development are investigated without incurring reengineering costs. • independent confirmation of developer test results, • evidence of a developer search for obvious vulnerabilities. • development environment controls and TOE configuration management required. Summer 2008 11 Evaluating Security Systems 37

The Seven EALs EAL 4 - Methodically Designed, Tested and Reviewed • allows developer to maximize assurance based on good commercial development practices. • Though rigorous, do not require substantial specialist knowledge, skills or resources. • retrofitting an existing product line is not feasible beyond this level. • applicable where developers require moderate to high level of independently assured security and willing to incur additional costs. • provides analysis supported by low-level design of the modules and subset of the implementation. Testing supported by search for obvious vulnerabilities. Development controls via life-cycle model, tools, and automated configuration management. EAL 5 - Semiformally Designed and Tested • allows developer to gain maximum assurance based on rigorous commercial development practices, • supported by moderate application of specialized security engineering techniques. • probably designed and developed of achieve this level with small additional costs for rigorous development without special techniques. • applicable where the developer requires a high level of independently assured security without unreasonable security engineering costs. An EAL 5 evaluation provides an analysis which includes all of the implementation. • need a formal model and a semiformal presentation of the functional specification and high level design with a semiformal demonstration of correspondence. • search for vulnerabilities must ensure resistance to penetration attackers with moderate attack potential. • covert channel analysis and modular design required. Summer 2008 11 Evaluating Security Systems 38

The Seven EALs EAL 6 - Semiformally Verified Design and Tested • allows developer gain high assurance from application of techniques in a rigorous development environment and produce a premium TOE for protecting high value assets against high risks. • applicable to development of specialized security TOEs, for application in high risk situations where the value of the protected assets justifies the additional costs. • provides analysis supported by a modular and layered approach to design and a structured presentation of the implementation. • independent search for vulnerabilities must ensure resistance to penetration attackers with a high skills. • search for covert channels must be systematic. • development environment and configuration management controls further strengthened. EAL 7 - Formally Verified Design and Tested • applicable when extreme risk to the TOE or the it is protecting highly valuable assets. • practical application limited to TOEs with focused security needs amenable to extensive formal analysis. • for evaluation, the formal model is supplemented by a formal presentation of the functional specification and high level design, showing correspondence. • evidence of developer “white box” testing and complete, independent confirmation of developer test results required. • complexity of design must be minimized. Summer 2008 11 Evaluating Security Systems 39

Evaluation of a TOE • PP evaluation - carried out against the evaluation criteria for PPs (many available) • ST evaluation - carried out against the evaluation criteria for STs • TOE evaluation - carried out against the evaluation criteria using an evaluated ST as the basis. • Assurance maintenance - carried out under schemes based on the requirements Summer 2008 11 Evaluating Security Systems 40

Evaluated PP http: //niap. nist. gov/cc-scheme/pp/index. html Evaluated and certified in accordance with the provisions of the NIAP Common Criteria Evaluation and Validation Scheme and the Common Criteria Recognition Arrangement (CCRA). The PPs have been evaluated at accredited and licensed/approved evaluation facilities in the U. S. or in one of the other countries (ISO Standard 15408). List includes: antivirus, PKI, switches and routers, firewalls, biometrics, VPN, WLAN, etc. Summer 2008 11 Evaluating Security Systems 41

Significance of vulnerabilities Threat agents will actively seek to exploit opportunities to violate security policies. They may also accidentally trigger security vulnerabilities, causing harm to the organisation. Steps should be taken to prevent vulnerabilities arising in IT products and systems. Vulnerabilities should be: a) eliminated —active steps should be taken to expose and remove or neutralise them; b) minimised —active steps should be taken to reduce, to an acceptable level, the impact of any exercise of a vulnerability; c) monitored —active steps should be taken to ensure that any attempt to exercise a residual vulnerability will be detected so that steps can be taken to limit the damage. Assurance is grounds for confidence that an IT product or system meets its security objectives. The CC provides assurance through active investigation an evaluation of the IT product or system in order to determine its security properties. Summer 2008 11 Evaluating Security Systems 42

Assurance through evaluation Evaluation is the traditional means of gaining assurance and is the basis of the CC approach. Evaluation techniques include: a) analysis and checking of processes and procedures; b) checking that they are being applied; c) analysis of the correspondence between TOE design representations; d) analysis of the design representation against the requirements; e) verification of proofs; f) analysis of guidance documents; g) analysis of functional tests developed and the results provided; h) independent functional testing; i) analysis for vulnerabilities (including flaw hypothesis); j) penetration testing. Summer 2008 11 Evaluating Security Systems 43

HP UX 11 i Common Criteria HP-UX 11 i v 3, running on HP 9000 and HP Integrity platforms, is successfully evaluated against the requirements for EAL 4 Common Criteria (ISO 15408) Assurance Level, augmented by ALC_FLR. 3 (flaw remediation), using the Controlled Access (CAPP) and Role. Based Access Control (RBACPP) Protection Profiles Common Criteria Certification. Summer 2008 11 Evaluating Security Systems 44

IBM and CC May, 2007 - z/OS Version 1 Release 8 certified at EAL 4+ for CAPP and LSPP z/OS Version 1. 8 was evaluated under the CC using the CAPP and the LSPP, at Evaluated Assurance Level 4, augmented by ALC_FLR. 1. --------------------- September 4, 2006 - System z 9 EC & BC Achieve EAL 5 Certification On March 14, 2003, IBM e. Server™ System z® 900 was the first server to be awarded EAL 5 security certification. In the past three years the System z 800, z 990, z 890 and now the z 9 Enterprise Class and Business Class have joined the ranks of this elite group. The architecture is designed to prevent the flow of information among logical partitions on a system, thus helping to ensure that confidential or sensitive data remains within the boundaries of a single partition. The EAL 5 ranking should give companies confidence that they can run many z/OS, z/VM and Linux-based applications containing confidential data on one System z™ server. Summer 2008 11 Evaluating Security Systems 45

Microsoft Security Certification For Windows 2000 October 29, 2002 issue of CRN Microsoft (NSDQ: MSFT) said Tuesday that its Windows 2000 platform had received a certification for Common Criteria certification at EAL 4. Summer 2008 11 Evaluating Security Systems 46