ECMS Security Target Issue 1.2 1 THALES COMMUNICATIONS S. A. SECURITY TARGET EXTERNAL COMMUNICATIONS MANAGEMENT SYSTEM Prepared by: IBM Global Services CLEF IBM UK Ltd Meudon House Meudon Avenue Farnborough Hampshire GU14 7NB Date: 15 January 2004 Issue: 1.2 Reference: Thales/ECMS/ST/1.2 ECMS Security Target Issue 1.2 2 ECMS Security Target Issue 1.2 iii REVISION HISTORY Issue Description Date 0.A First Draft 25 March 2003 0.B Second Draft following further discussions with Thales 16 April 2003 0.C Third Draft incorporating changes proposed by DOMUS. 17 July 2003 0.D Forth Draft. Minor modification to Table 7-8 and insertion of TOE version number. Introduction of two IT environment security objectives to address the CB concerns regarding a reference monitor. 28 July 2003 0.E Fifth Draft. Insertion of the SFR for the IT environment session, providing relevant rationales, plus editorial changes to address the CB concerns regarding a reference monitor. 06 August 2003 1.0 First Release 05 January 2004 1.1 Update to first release following discussion with DOMUS 12 January 2004 1.2 Inclusion of password assumption 15 January 2004 ECMS Security Target Issue 1.2 iv TABLE OF CONTENTS Page 1 INTRODUCTION......................................................................................... 1-1 1.1 Identification ................................................................................................... 1-1 1.2 Conformance Claim ........................................................................................ 1-1 1.3 Strength of Functions ...................................................................................... 1-1 1.4 Structure .......................................................................................................... 1-1 2 TOE DESCRIPTION.................................................................................... 2-1 2.1 Introduction ..................................................................................................... 2-1 2.2 Detailed Description........................................................................................ 2-3 2.2.1 Software Components ..................................................................................... 2-3 2.2.2 External Interfaces........................................................................................... 2-3 2.2.3 Architecture..................................................................................................... 2-3 2.2.4 Scope of the Evaluation................................................................................... 2-4 2.2.4.1 The Physical Scope ......................................................................................... 2-4 2.2.4.2 Logical Scope.................................................................................................. 2-4 2.2.5 Security Functions and Services ..................................................................... 2-4 2.2.6 Security Roles ................................................................................................. 2-5 2.2.7 Hardware and Software Requirements............................................................ 2-5 3 TOE SECURITY ENVIRONMENT........................................................... 3-1 3.1 Assumptions.................................................................................................... 3-1 3.1.1 Physical Assumptions ..................................................................................... 3-1 3.1.2 Personnel Assumptions ................................................................................... 3-1 3.1.3 Connectivity Assumptions .............................................................................. 3-2 3.2 Threats............................................................................................................. 3-2 3.3 Organisational Security Policies ..................................................................... 3-2 4 SECURITY OBJECTIVES.......................................................................... 4-1 4.1 TOE Security Objectives................................................................................. 4-1 4.2 Environmental Security Objectives................................................................. 4-1 4.2.1 IT Environmental Security Objectives............................................................ 4-1 4.2.2 Non-IT Environmental Security Objectives.................................................... 4-1 5 IT SECURITY REQUIREMENTS ............................................................. 5-1 5.1 Security Functional Requirements .................................................................. 5-1 5.1.1 Statement of Security Functional Requirements for the TOE......................... 5-1 5.1.1.1 Security Audit (FAU)...................................................................................... 5-1 5.1.1.1.1 Audit Data Generation (FAU_GEN.1)............................................................ 5-1 5.1.1.1.2 User Identity Association (FAU_GEN.2) ....................................................... 5-2 5.1.1.1.3 Audit Review (FAU_SAR.1) .......................................................................... 5-2 5.1.1.1.4 Selectable Audit Review (FAU_SAR.3)......................................................... 5-2 5.1.1.1.5 Protected Audit Trail Storage (FAU_STG.1) ................................................. 5-2 5.1.1.1.6 Action in Case of Possible Audit Data Loss (FAU_STG.3)........................... 5-2 5.1.1.1.7 Prevention of Audit Data Loss (FAU_STG.4)................................................ 5-2 ECMS Security Target Issue 1.2 v 5.1.1.2 User Data Protection (FDP) ............................................................................ 5-3 5.1.1.2.1 Discretionary Access Control Policy (FDP_ACC.1) ...................................... 5-3 5.1.1.2.2 Discretionary Access Control Functions (FDP_ACF.1)................................. 5-3 5.1.1.3 Identification and Authentication (FIA).......................................................... 5-3 5.1.1.3.1 User Attribute Definition (FIA_ATD.1) ......................................................... 5-3 5.1.1.3.2 Authentication (FIA_UAU.1) ......................................................................... 5-3 5.1.1.3.3 Protected Authentication Feedback (FIA_UAU.7)......................................... 5-4 5.1.1.3.4 Identification (FIA_UID.2) ............................................................................. 5-4 5.1.1.3.5 User-Subject Binding (FIA_USB.1) ............................................................... 5-4 5.1.1.4 Security Management (FMT).......................................................................... 5-4 5.1.1.4.1 Static Attribute Initialisation (FMT_MSA.3) ................................................. 5-4 5.1.1.4.2 Security Management Roles (FMT_SMR.1) .................................................. 5-4 5.1.2 Statement of Security Functional Requirements for the IT Environment....... 5-4 5.1.2.1 User Data Protection ....................................................................................... 5-5 5.1.2.1.1 Subset Residual Information Protection (FDP_RIP.1) ................................... 5-5 5.1.2.2 Protection of the TSF ...................................................................................... 5-5 5.1.2.2.1 Non-bypassability of the TSP (FPT_RVM.1)................................................. 5-5 5.1.2.2.2 TSF Domain Separation (FPT_SEP.1)............................................................ 5-5 5.1.2.2.3 Reliable Time Stamps (FPT_STM.1).............................................................. 5-5 5.2 Security Assurance Requirements................................................................... 5-5 5.2.1 Statement of Security Assurance Requirements ............................................. 5-5 5.2.2 Statement of Strength of TOE Security Function ........................................... 5-6 6 TOE SUMMARY SPECIFICATION ......................................................... 6-1 6.1 TOE Security Functions.................................................................................. 6-1 6.2 Assurance Measures........................................................................................ 6-1 7 RATIONALE................................................................................................. 7-1 7.1 Security Objectives Rationale and Traceability.............................................. 7-1 7.1.1 Security Objectives Rationale for Environmental Assumptions..................... 7-1 7.1.2 Organisational Policy Rationale...................................................................... 7-3 7.2 Security Requirements Rationale.................................................................... 7-5 7.2.1 TOE Security Functional Requirements (SFRs) Rationale............................. 7-5 7.2.2 IT environment Security Functional Requirements (SFRs) Rationale............ 7-8 7.2.3 SFR Dependency Rationale ............................................................................ 7-9 7.2.4 Security Assurance Requirements Rationale (SARs) ................................... 7-10 7.3 TOE Summary Specification Rationale ........................................................ 7-11 7.3.1 IT Security Functions Rationale (SFRs) ....................................................... 7-11 8 REFERENCES .............................................................................................. 8-1 ECMS Security Target Issue 1.2 vi ACRONYMS AND ABBREVIATIONS API Application Programme Interface CC Common Criteria CCC Communications Control Centre CCCS Canadian Common Criteria Scheme CCMS Communications Control and Monitoring System CEM Common Methodology for Information Technology Security CIC Combat Information Centre COTS Commercial-Off-The-Shelf EAL Evaluation Assurance Level ECMS External Communications Management System ICMS Internal Communications Management System LAN Local Area Network NATO North Atlantic Treaty Organisation PC Personal Computer PP Protection Profile SARs Security Assurance Requirements SFP Security Functional Policy SFRs Security Functional Requirements ST Security Target TBD To Be Determined TCP/IP Transfer Control Protocol/Internet Protocol Thales Thales Communications S. A. TOE Target of Evaluation TSC TSF Scope of Control TSF TOE Security Function TSP TOE Security Policy ECMS Security Target Issue 1.2 Page 1-1 1 INTRODUCTION 1.1 Identification Title: Security Target External Communications Management System Version 4.1 Release Date: 12 January 2004 Level of Assurance: EAL3 Keywords: Communications Management System 1.2 Conformance Claim The Thales External Communications Management System Version 4.1 is the Target of Evaluation (TOE) for this Common Criteria (CC) Version 2.1 Part 2 and CC Version 2.1 Part 3 conformant evaluation. The TOE conforms to the requirements of the Common Criteria for Information Technology Security Evaluation, August 1999, Version 2.1, CCIMB-99-032 ([CC]), for an Evaluation Assurance Level (EAL) 3 evaluation. 1.3 Strength of Functions The claimed strength of function is medium. 1.4 Structure The structure of this document follows that defined in [CC] Part 1, Annex C: • Section 2 is the TOE description; • Section 3 provides a statement of the TOE security environment; • Section 4 provides the statement of IT security objectives; • Section 5 provides a statement of IT security requirements; • Section 6 provides the TOE summary specification, which includes the detailed specification of the IT functions; and ECMS Security Target Issue 1.2 Page 1-2 • Section 7 provides the rationale for the security objectives, security requirements and TOE summary specification. ECMS Security Target Issue 1.2 Page 2-1 2 TOE DESCRIPTION 2.1 Introduction The External Communications Management System (ECMS) Version 4.1, together with the ICMS (Internal Communications Management System), form the CCMS (Communications Control and Monitoring System) which manages all internal and external communications equipment on the Belgian Navy’s WIELINGEN frigate. The ECMS is a software application that runs on CCMS workstations. It manages the following aspects of the communications system: • Radio equipment such as HF transmitters, HF receivers, V/UHF transceivers and modems • Radio services supported by this equipment offering voice and data communication services. The TOE for this evaluation is the ECMS Host application. ECMS Security Target Issue 1.2 Page 2-2 HOST AP 1752+ AP TRT 76000 Service Manager ALE PP TRC 1752+ TRT 7600 ECMS + RMU N°1 ICMS HOST Service Manager ALE PP ECMS (Remote CCMS) RMU N°2 AP HF6000 AP TRT 7600 RMU N°3 AP HF6000 AP TRG 6031 TMR 6110D TRT 7600 TMR 6912D & TMR 6211S TRG 6031 ECMS Agents Managers Agents Managers (1) (1) (1) (3) (4) (2) (2) (5) (4) (5) (6) AM TRG 6031 HOST AP TRG 6031 Managers délégués (7) (7) Agents Managers Agents Managers Figure 2-1: ECMS Host system ECMS Security Target Issue 1.2 Page 2-3 2.2 Detailed Description 2.2.1 Software Components The TOE software is written in C++. 2.2.2 External Interfaces The TOE has the following external interfaces: • Operator interface – the interface between the operator and the ECMS. This is a graphical user interface which is installed on the CCMS NT workstations; • Radio equipment interface – this interface allows the ECMS to exchange information with the radio equipment; • CCMS workstation interface – the interface to the CCMS workstation’s NT operating system; • ICMS interface – the interface to the ICMS application. This allows the ECMS to exchange monitoring information and commands controlling the radio services, emission control and voice terminal/radio chain allocation. 2.2.3 Architecture The ECMS Host application runs on a PC under the Windows NT operating system. Users interface with the ECMS Host application via the PC’s keyboard and display. The figure below shows the components that make up the ECMS core and the communications devices that are controlled by the ECMS. The red box denotes the ECMS Core or Logical Component. The Host application, or physical component controls all the other applications (e.g. Service Manager, Agent Managers) and is denoted by the black outer box. ECMS Security Target Issue 1.2 Page 2-4 Operator Service Manager Host Delegation Manager Radio Equipment (radio, modem…) Network (Thomnet) Terminal (TOMA) OS ICMS ECMS Agent Manager xxx Agent Proxy xxx ECMS Core Figure 2-2: ECMS Core system 2.2.4 Scope of the Evaluation The scope of this evaluation covers the Host application and its interface with the user. The operating system on which the Host application resides is not included within this evaluation. 2.2.4.1 The Physical Scope The upper inner box in Figure 2-1 marked as “ECMS + RMU No 1” describes the physical scope. It covers the Agent Manager, Service Manager and Host modules, the AP1752+, AP TRT7600 and ALE PP modules as well as interfaces to other systems. 2.2.4.2 Logical Scope The inner red line in Figure 2-2 defines the logical scope as the ECMS Core. It encompasses the Service Manager, Host, Agent Manager and Delegation Manager. 2.2.5 Security Functions and Services The TOE security services under evaluation are: • Enforcement of the ECMS Discretionary Access Control Policy; ECMS Security Target Issue 1.2 Page 2-5 • Audit of specified security events. 2.2.6 Security Roles The following roles are supported by the TOE: • Operator (O), • Chief Operator (C) and • Administrator (A). The specific responsibilities and privileges of the Chief Operator and Operators are a subset of those of the Administrator. User rights are assigned according to the role. Users are able to “handover” their role to another user or to “swap” their role for another role. 2.2.7 Hardware and Software Requirements The ECMS Host application runs on a Microsoft Windows NT4 PC. The following software is used by the ECMS Host application: • JDK 1.2.2 • EXCEED • Microsoft Windows NT4 Service Pack 6a • INGRES II ECMS Security Target Issue 1.2 Page 3-1 3 TOE SECURITY ENVIRONMENT The statement of TOE security environment describes the security aspects of the environment in which the TOE is intended to be used, and the manner in which it is expected to be employed. The statement of TOE security environment therefore identifies the assumptions made on the operational environment and the method of use for the product; defines the threats that the product is designed to counter; and defines the organisational security policies with which the product is designed to comply. 3.1 Assumptions The list of assumptions regarding the security aspects of the environment in which the TOE is intended to be used is presented in the following subsections. 3.1.1 Physical Assumptions It is assumed that the following physical conditions will exist in the environment of the TOE: A.LOCATE The TOE will be located within controlled access facilities which will prevent unauthorised physical access. A.PROTECT The TOE hardware and software will be protected from unauthorised physical modification. 3.1.2 Personnel Assumptions It is assumed that the following personnel conditions will be enforced by the organisation in control of the environment of the TOE: A.MANAGE There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains. A.NO_EVIL_ADM The system administrative personnel are not careless, wilfully negligent, or hostile, and will follow and abide by the instructions provided by the administrator documentation. A.COOP Authorised users possess the necessary authorisation to access at least some of the information managed by the ECMS Security Target Issue 1.2 Page 3-2 TOE and are expected to act in a cooperating manner in a benign environment. A.PASSWORD Authorised users will choose a password that conforms to the length and complexity rules stated in the user guidance. These rules will be consistent with a SOF medium claim for the TOE. 3.1.3 Connectivity Assumptions The following connectivity conditions are assumed: A.PEER Any other system with which the TOE communicates is assumed to be under the same management control and operate under the same security policy constraints. A.CONNECT All connections to peripheral devices reside within the controlled access facilities. Internal communication paths to access points such as terminals are assumed to be adequately protected. A.OS The underlying operating system shall ensure that any information contained in a protected resource is not released when the resource is recycled; protect the TOE software from unauthorised modification and prevent the TSFs from being bypassed. 3.2 Threats There are no explicit threats identified for the TOE. The security objectives are derived from the statement of Organisational Security Policy contained in Section 3.3. 3.3 Organisational Security Policies The organisational security policies are described below. P.AUTHORISED_USERS Only those users who have been authorised to access the information within the system may access the system. P.NEED_TO_KNOW The system must limit the access to, modification of, and destruction of the information in protected resources to ECMS Security Target Issue 1.2 Page 3-3 those authorised users which have a “need to know” for that information. P.ACCOUNTABILITY The users of the system shall be held accountable for their actions within the system. ECMS Security Target Issue 1.2 Page 4-1 4 SECURITY OBJECTIVES 4.1 TOE Security Objectives The Security Objectives of the TOE comprise the following: O.AUTHORISATION The TSF must ensure that only authorised users gain access to the TOE and its resources. O.DAC The TSF must control access to resources based on identity of users. The TSF must allow authorised users to specify which users may access which resources. O.AUDITING The TSF must record the security relevant actions of users of the TOE. The TSF must present this information to authorised administrators. O.MANAGE The TSF must provide all the functions and facilities necessary to support the authorised administrators that are responsible for the management of TOE security. 4.2 Environmental Security Objectives 4.2.1 IT Environmental Security Objectives The IT security objectives for the environment comprise the following: O.RESIDUAL_INFORMATION The underlying operating system must ensure that any information contained in a protected resource is not released when the resource is recycled. O.NO_MOD The underlying operating system must protect the TOE software from unauthorised modification. O.NO_BYPASS The underlying operating system must prevent the TSFs from being bypassed. 4.2.2 Non-IT Environmental Security Objectives The non-IT Environmental Security Objectives comprise the following: ECMS Security Target Issue 1.2 Page 4-2 O.INSTALL Those responsible for the TOE must ensure that the TOE is delivered, installed, managed, and operated in a manner which maintains IT security objectives. O.PHYSICAL Those responsible for the TOE must ensure that those parts of the TOE critical to security policy are protected from physical attack which might compromise IT security objectives, and by siting the TOE network environment in an adequately protected location. All connections to peripheral devices must reside within the controlled access facilities and internal communication paths to access points such as terminals are protected by their physical location. O.CREDEN Those responsible for the TOE must ensure that all access credentials, such as passwords or other authentication information, are protected by the users in a manner that maintains IT security objectives. In addition, users should ensure that their passwords conform to the length and complexity rules stated in the user guidance. These rules will be consistent with a SOF medium claim for the TOE. ECMS Security Target Issue 1.2 Page 5-1 5 IT SECURITY REQUIREMENTS 5.1 Security Functional Requirements 5.1.1 Statement of Security Functional Requirements for the TOE This section contains the security functional requirements for the TOE. The following CC Part 2 components are referenced. Completed definition text (i.e. added text not defined by the CC) is indicated below by italics. 5.1.1.1 Security Audit (FAU) 5.1.1.1.1 Audit Data Generation (FAU_GEN.1) The TSF shall be able to generate an audit record of the following auditable events: FAU_GEN.1.1 (a) Start-up and shutdown of the audit functions; (b) The auditable events listed in Table 5-1 (Auditable Events). The TSF shall record within each audit record at least the following information: FAU_GEN.1.2 (a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event; and (b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, any additional information specified in the “Details” column of Table 5-1 (Auditable Events). Table 5-1: Auditable Events SFR Event Details FAU_STG.3 Actions taken due to exceeding of a threshold. FDP_ACF.1 All requests to perform an operation on an object covered by the SFP. FIA_UAU.1 All successful and unsuccessful use of the authentication mechanism. FIA_UID.2 All successful use of the user identification mechanism including the user identity provided. ECMS Security Target Issue 1.2 Page 5-2 5.1.1.1.2 User Identity Association (FAU_GEN.2) The TSF shall be able to associate each auditable event with the identity of the user that caused the event. FAU_GEN.2.1 5.1.1.1.3 Audit Review (FAU_SAR.1) The TSF shall provide all users with the capability to read all audit information from the audit records. FAU_SAR.1.1 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. FAU_SAR.1.2 5.1.1.1.4 Selectable Audit Review (FAU_SAR.3) The TSF shall provide the ability to perform searches of audit data based on the following attributes: FAU_SAR.3.1 (a) type of event; (b) date. 5.1.1.1.5 Protected Audit Trail Storage (FAU_STG.1) The TSF shall protect the stored audit records from unauthorised deletion. FAU_STG.1.1 The TSF shall be able to prevent modifications to the audit records. FAU_STG.1.2 5.1.1.1.6 Action in Case of Possible Audit Data Loss (FAU_STG.3) The TSF shall generate an alarm to the authorised administrator if the audit trail exceeds 80%. FAU_STG.3.1 5.1.1.1.7 Prevention of Audit Data Loss (FAU_STG.4) The TSF shall overwrite the oldest stored audit records (excluding alarms that have not been cleared) if the audit trail is full. FAU_STG.4.1 ECMS Security Target Issue 1.2 Page 5-3 5.1.1.2 User Data Protection (FDP) 5.1.1.2.1 Discretionary Access Control Policy (FDP_ACC.1) The TSF shall enforce the Discretionary Access Control Policy on all processes acting on the behalf of users. FDP_ACC.1.1 5.1.1.2.2 Discretionary Access Control Functions (FDP_ACF.1) The TSF shall enforce the Discretionary Access Control Policy to objects based on the user identity associated with a subject. FDP_ACF.1.1 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: FDP_ACF.1.2 (a) a rule for each operation which uses either the user identity or the role of a subject as the basis of allowing or denying access. The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none. FDP_ACF.1.3 The TSF shall explicitly deny access of subjects to objects based on the: none. FDP_ACF.1.4 5.1.1.3 Identification and Authentication (FIA) 5.1.1.3.1 User Attribute Definition (FIA_ATD.1) The TSF shall maintain the following list of security attributes belonging to individual users: FIA_ATD.1.1 (a) User Name; (b) Role; (c) Password. 5.1.1.3.2 Authentication (FIA_UAU.1) The TSF shall allow the user identification on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on the behalf of that user. FIA_UAU.1.2 ECMS Security Target Issue 1.2 Page 5-4 5.1.1.3.3 Protected Authentication Feedback (FIA_UAU.7) The TSF shall provide only obscured feedback to the user while the authentication is in progress. FIA_UAU.7 5.1.1.3.4 Identification (FIA_UID.2) The TSF shall require each user to identify itself before allowing any other TSF-mediated actions on the behalf of that user. FIA_UID.2.1 5.1.1.3.5 User-Subject Binding (FIA_USB.1) The TSF shall associate the appropriate user security attributes with subjects acting on the behalf of that user: FIA_USB.1.1 5.1.1.4 Security Management (FMT) 5.1.1.4.1 Static Attribute Initialisation (FMT_MSA.3) The TSF shall enforce the Discretionary Access Control Policy to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.1 The TSF shall allow nobody to specify alternative initial values to override the default values when an object or information is created. FMT_MSA.3.2 5.1.1.4.2 Security Management Roles (FMT_SMR.1) The TSF shall maintain the roles: FMT_SMR.1.1 (a) Operator (O); (b) Chief Operator (C); (c) Administrator (A). The TSF shall be able to associate users with roles. FMT_SMR.1.2 5.1.2 Statement of Security Functional Requirements for the IT Environment This section contains the security functional requirements for the IT environment. The following CC Part 2 components are referenced. Completed ECMS Security Target Issue 1.2 Page 5-5 definition text (i.e. added text not defined by the CC) is indicated below by italics. 5.1.2.1 User Data Protection 5.1.2.1.1 Subset Residual Information Protection (FDP_RIP.1) The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from the following objects: the TOE application. FDP_RIP.1.1 5.1.2.2 Protection of the TSF 5.1.2.2.1 Non-bypassability of the TSP (FPT_RVM.1) The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function within the TSC is allowed to proceed. FPT_RVM.1.1 5.1.2.2.2 TSF Domain Separation (FPT_SEP.1) The TSF shall maintain a security domain for its own execution that protects it from interference and tampering by untrusted subjects. FPT_SEP.1.1 The TSF shall enforce separation between the security domains of subjects in the TSC. FPT_SEP.1.2 5.1.2.2.3 Reliable Time Stamps (FPT_STM.1) The TSF shall be able to provide reliable time stamps for its own use. FPT_STM.1.1 5.2 Security Assurance Requirements 5.2.1 Statement of Security Assurance Requirements The following security assurance requirements are claimed in accordance with the EAL3 requirements stated in [CC] Part 3. Table 5-2: Security Assurance Requirements ACM_CAP.3 Authorisation controls ACM_SCP.1 TOE CM coverage ECMS Security Target Issue 1.2 Page 5-6 ADO_DEL.1 Delivery procedures ADO_IGS.1 Installation, generation, and start-up procedures ADV_FSP.1 Informal functional specification ADV_HLD.2 Security enforcing high-level design ADV_RCR.1 Informal correspondence demonstration AGD_ADM.1 Administrator guidance AGD_USR.1 User guidance ALC_DVS.1 Identification of security measures ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: high-level design ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample AVA_MSU.1 Examination of guidance AVA_SOF.1 Strength of TOE security function evaluation AVA_VLA.1 Developer vulnerability analysis 5.2.2 Statement of Strength of TOE Security Function Strength of function, as a CC concept, applies to probabilistic or permutational mechanisms that are non-cryptographic in nature. This ST claims AVA_SOF.1 applicability for the user identification and authentication SFRs: FIA_UID.2 and FIA_UAU.1 through the user password entry function and its mechanism. The minimum strength of function level for the password entry mechanism is SOF medium. This is achieved through procedural means i.e. the user guidance will inform the user that they have to choose a password of sufficient length and complexity to satisfy a SOF medium rating. ECMS Security Target Issue 1.2 Page 6-1 6 TOE SUMMARY SPECIFICATION 6.1 TOE Security Functions The TOE IT Security Functions and their specifications are listed as follows. AUDIT The TOE performs audit functions by recording all events listed in Table 5-1. DAC The TOE controls access by an identified and authenticated user to those processes whose owner attribute is identical to that of the currently authenticated user. USER_LOGIN The TOE requires the user to identify and authenticate via a user login. The overall strength of function of the TOE IT security functions is SOF medium. Only the USER_LOGIN function is realised by a probabilistic mechanism and the strength of this function is SOF medium on the assumption that the users will choose passwords of sufficient length and complexity to be consistent with this claim. 6.2 Assurance Measures The assurance measures that are provided by the TOE are described below: ACM_CAP TOE releases are uniquely identified with the version number and model identifier. All Configuration Items that comprise the TOE are under Configuration Management and are included on a Configuration List and uniquely identified by part number. ACM_SCP TOE Configuration Management coverage analysis is provided. ADO_DEL The TOE delivery procedures ensure that secure delivery of the TOE is achieved. ADO_IGS Automated installation procedures are adequate to ensure that the user starts the TOE within a secure configuration. ADV_FSP An informal functional specification is supplied for the TOE. ADV_HLD The TOE High Level Design documentation addresses the requirements of ADV_HLD.2 ECMS Security Target Issue 1.2 Page 6-2 ADV_RCR A representational correspondence is supplied. AGD_ADM The administrator’s guide is adequate to provide administrators with the required knowledge to securely configure and maintain the TOE within the environment. AGD_USR The User guidance is adequate to provide the user with the required knowledge to correctly perform login procedures and to provide security awareness of the TOE and its policies. ALC_DVS Identification of security measures in the life cycle documentation is provided. ATE_COV The analysis of coverage for testing is provided to assure completeness of coverage in testing of the TOE. ATE_DPT Testing with respect to the High Level Design is provided. ATE_FUN Functional testing of all security functions is provided in the referenced test plan. ATE_IND The functional testing was performed by an independent third party. AVA_MSU Examination of guidance is provided. AVA_SOF The TOE Strength of Function Analysis addresses the requirements of AVA_SOF.1. AVA_VLA The TOE vulnerability analysis addresses the requirements of AVA_VLA.1. ECMS Security Target Issue 1.2 Page 7-1 7 RATIONALE 7.1 Security Objectives Rationale and Traceability The purpose of this section is to show that the security objectives of the TOE are appropriate to the security problem defined in the security environment section (see Section 1.2). This is accomplished through a set of tables that cross-reference threats, security policies and assumptions against the security objectives that address them. Each threat, policy or assumption is addressed by one or more security objective. Each security objective of the TOE (described in Section 4.1) addresses at least one threat, policy or assumption. An informal argument is provided to show, for each threat, policy or assumption, why the identified security objective provides an effective countermeasure that prevents an attack or mitigates risk to acceptable levels. 7.1.1 Security Objectives Rationale for Environmental Assumptions The following table shows the mapping for each of the security objectives for the environment to the environmental assumptions. Table 7-1: Mapping for each of the Security Objectives Security Objectives Environmental Assumptions O.INSTALL O.PHYSICAL O.CREDEN O.RESIDUAL_INFORMATION O.NO_MOD O.NO_BYPASS A.MANAGE X A.NO_EVIL_ADM X A.COOP X A.LOCATE X A.PASSWORD X A.PROTECT X A.PEER X A.CONNECT X A.OS X X X ECMS Security Target Issue 1.2 Page 7-2 It is clear from the above representation that each environmental security objective addresses at least one environmental assumption and that each environmental assumption is addressed by at least one environmental security objective. The rationale for the environmental assumptions against the environmental security objectives is given in the table below. For each assumption a list of security objectives for the environment is given, followed by an argument stating how each security objective enforces the assumption in question. Table 7-2: Environmental Assumptions Against the Environmental Security Objectives Assumption Security Objective Rationale A.MANAGE O.INSTALL O.INSTALL ensures that the secure state of the system is achieved on initialisation and that management of the system can proceed from a secure state. A.NO_EVIL_ADM O.INSTALL O.INSTALL ensures that those responsible for the system will ensure the installation and management and operation are consistent with IT security objectives. This precludes the actions of a hostile administrator or supervisor. A.PEER O.INSTALL O.INSTALL addresses A.PEER by ensuring that all other systems with which the TOE is connected are under the same management control and operate under the same security policy. A.LOCATE O.PHYSICAL O.PHYSICAL provides for the requirements of A.LOCATE by ensuring that those parts of the TOE critical to security policy are protected from physical attack which might compromise IT security objectives through siting in an adequately protected location. A.PROTECT O.PHYSICAL O.PHYSICAL directly addresses A.PROTECT by ensuring that the TOE hardware and software critical to security policy enforcement will be protected from unauthorised physical modification. A.CONNECT O.PHYSICAL O.PHYSICAL directly addresses A.CONNECT by ensuring that all connections to peripheral devices reside within the controlled access facilities, and that internal communication paths to access points such as terminals are protected by their physical location. A.COOP O.CREDEN O.CREDEN addresses A.COOP by ensuring that authorised users possess the necessary authorisation to access at least some of the information managed by the ECMS Security Target Issue 1.2 Page 7-3 Assumption Security Objective Rationale TOE and are expected to act in a cooperating manner in a benign environment. This includes the requirement that all access credentials, such as passwords or other authentication information, are protected by the users in a manner that maintains IT security objectives. A.PASSWORD O.CREDEN O.CREDEN addresses A.PASSWORD by ensuring that authorised users will select a password conforming to the required length and complexity requirements consistent with a SOF medium claim for the TOE. A.OS O.RESIDUAL_INFORMATION O.NO_MOD O.NO_BYPASS The O.RESIDUAL_INFORMATION, O.NO_MOD and O.NO_BYPASS address the assumptions that the IT environment security objectives and the underlying operating system will ensure that information contained in a protected resource is not released when the resource is recycled, that no unauthorised modifications are made to the TOE software and that the TSF cannot be bypassed. The password policy is as specified in the SOF manual. 7.1.2 Organisational Policy Rationale The mapping between the organisational policies enforced in the TOE Environment and the IT Security Objectives is shown in the table below. Table 7-3: Organisational Policy Rationale Security Objectives Policies O.AUTHORISATION O.MANAGE O.DAC O.AUDITING O.RESIDUAL_INFORMATION O.NO_MOD O.NO_BYPASS P.AUTHORISED_USERS X X X X P.NEED_TO_KNOW X X X X X ECMS Security Target Issue 1.2 Page 7-4 P.ACCOUNTABILITY X X The rationale for the policies against the IT security objectives is given in the table below. For each policy a list of IT security objectives is given, followed by an argument stating how each security objective satisfies the policy in question. Table 7-4: Organisational Policy Organisational Policy Security Objective Rationale P.AUTHORISED_USERS O.AUTHORISATION O.MANAGE O.NO_MOD O.NO_BYPASS P.AUTHORISED_USERS states that only those users authorised to access the information assets of the system may access the system. The policy is implemented by O.AUTHORISATION, and supported by O.MANAGE by requiring authorised administrators to be able to manage the functions. O.NO_MOD and O.NO_BYPASS ensure that the TOE security objectives meeting P.AUTHORISED_USERS cannot be tampered with or bypassed. P.NEED_TO_KNOW O.MANAGE O.DAC O.RESIDUAL_INFORMATIO N O.NO_MOD O.NO_BYPASS P.NEED_TO_KNOW states that the system must limit access to, modification of, and destruction of information to those authorised users having a need-to-know. O.DAC implements this policy. O.MANAGE supports the policy by requiring authorised administrators to manage the functions. O.RESIDUAL_INFORMATION ensures that information is not given to users without a need-to- know when resources are reused. O.NO_MOD and O.NO_BYPASS ensure that the TOE security objectives meeting P.NEED_TO_KNOW cannot be tampered with or bypassed. P.ACCOUNTABILITY O.MANAGE O.AUDITING P.ACCOUNTABILITY requires users of the system to be held accountable for their actions in the system. This policy is implemented by O.AUDITING in ECMS Security Target Issue 1.2 Page 7-5 Organisational Policy Security Objective Rationale requiring the recording of actions in an audit trail. O.MANAGE supports this by requiring the secure management of the audit trail. 7.2 Security Requirements Rationale 7.2.1 TOE Security Functional Requirements (SFRs) Rationale The mapping between the SFRs and the Security Objectives is shown in the table below. The SFRs appear on the left for each row, and corresponding Security Objectives are indicated by an ‘X’ in the appropriate column. Table 7-5: TOE Security Functional Requirements SFR Description O.AUTHORISATION O.DAC O.AUDITING O.MANAGE FAU_GEN.1 Audit Data Generation X FAU_GEN.2 User Identity Association X FAU_SAR.1 Audit Review X X FAU_SAR.3 Selectable Audit Review X X FAU_STG.1 Protected Audit Trail Storage X FAU_STG.3 Action in Case of Possible Audit Data Loss X X FAU_STG.4 Prevention of Audit Data Loss X X FDP_ACC.1 Discretionary Access Control Policy X FDP_ACF.1 Discretionary Access Control Functions X FIA_ATD.1 User Attribute Definition X X FIA_UAU.1 Authentication X FIA_UAU.7 Protected Authentication Feedback X FIA_UID.2 Identification X FIA_USB.1 User-Subject Binding X X ECMS Security Target Issue 1.2 Page 7-6 SFR Description O.AUTHORISATION O.DAC O.AUDITING O.MANAGE FMT_MSA.3 Static Attribute Initialisation X FMT_SMR.1 Security Management Roles X FAU_GEN.1 Audit Data Generation X FAU_GEN.2 User Identity Association X FAU_SAR.1 Audit Review X X FAU_SAR.3 Selectable Audit Review X X FAU_STG.1 Protected Audit Trail Storage X FAU_STG.3 Action in Case of Possible Audit Data Loss X X FAU_STG.4 Prevention of Audit Data Loss X X FDP_ACC.1 Discretionary Access Control Policy X FDP_ACF.1 Discretionary Access Control Functions X FIA_ATD.1 User Attribute Definition X X FIA_UAU.1 Authentication X FIA_UAU.7 Protected Authentication Feedback X FIA_UID.2 Identification X FIA_USB.1 User-Subject Binding X X FMT_MSA.3 Static Attribute Initialisation X FMT_SMR.1 Security Management Roles X The rationale for the SFRs against the security objectives of the TOE is given in the table below. For each security objective of the TOE, a list of assigned SFRs is given, followed by an argument stating how each SFR addresses or satisfies the security objective in question. Table 7-6: TOE SFR security objective Security Objective SFR Rationale O.AUTHORISATION FIA_ATD.1 FIA_UAU.1 FIA_UAU.7 FIA_UID.2 FIA_ATD.1 provides that the TSF maintain the user identifiers, roles, passwords that enable identification and authentication of users. ECMS Security Target Issue 1.2 Page 7-7 Security Objective SFR Rationale FIA_UAU.1 allows only the user identification on behalf of the user to be performed before the user is authenticated. FIA_UAU.7 prevents the disclosure of user password information during login. FIA_UID.2 allows no other actions to be taken by the user prior to user identification. These requirements collectively ensure that only authorised users gain access to the TOE and its resources. O.DAC FDP_ACC.1 FDP_ACF.1 FIA_ATD.1 FIA_USB.1 FMT_MSA.3 FDP_ACC.1 provides that the TOE Discretionary Access Control Policy is enforced and allows authorised users to forward messages to other authorised users, thereby providing discretionary access and ownership transfer between users. FDP_ACF.1 provides that each user identity/role is associated with a controlled subject/object and that protections are carried with it, whenever that subject/object is read, written, deleted and released. FIA_ATD.1 provides that the TSF maintain the user identifiers, roles, passwords that enable identification and authentication of users. FIA_USB.1 associates appropriate user security attributes with subjects acting on the behalf of that user. FMT_MSA.3 enforces discretionary access control by provide restrictive default values for users on creation. O.AUDITING FAU_GEN.1 FAU_GEN.2 FAU_SAR.1 FAU_SAR.3 FAU_STG.1 FAU_STG.3 FAU_STG.4 FIA_USB.1 FPT_STM.1 FAU_GEN.1 and FAU_GEN.2 provide that audit records will be generated for selected events and that the TSF shall be able to associate each auditable event with the identity of the user that caused the event. FAU_SAR.1 provides that the TSF shall provide authorised administrators with the capability to read all audit information from the audit records. FAU_SAR.3 provides that the TSF shall provide the ability to perform searches of specified types on the audit records. FAU_STG.1 provides that the TSF shall protect the stored audit records from unauthorised deletion, and to prevent modifications to the audit records. Thus the integrity of audit records is guaranteed. FAU_STG.3 provides that the TSF shall generate an alarm to the authorised administrator if the audit trail exceeds 80%. FAU_STG.4 ensures that the latest audit records are maintained. FIA_USB.1 associates appropriate user security attributes with subjects acting on the behalf of that user. FPT_STM.1 provides a reliable time stamp to the audit generation, ensuring the accuracy of the time appeared in audit records. O.MANAGE FAU_SAR.1 FAU_SAR.3 FAU_SAR.1 provides that the TSF shall provide authorised administrators with the capability to read all audit information ECMS Security Target Issue 1.2 Page 7-8 Security Objective SFR Rationale FAU_STG.3 FAU_STG.4 FMT_SMR.1 from the audit records. FAU_SAR.3 provides that the TSF shall provide the ability to perform searches of specified types on the audit records. FAU_STG.3 provides that the TSF shall generate an alarm to the authorised administrator if the audit trail exceeds 80%. FAU_STG.4 ensures that the latest audit records are maintained. FMT_SMR.1 provides that the TSF maintain roles and that the roles can be associated by the TSF with users The coverage of the above table against the SFRs satisfies the following properties: • for every security objective of the TOE, there is at least one SFR that satisfies it; • for every SFR, there is at least one security objective of the TOE that it addresses; and • for every security objective of the TOE, an informal argument as to why the identified SFRs are sufficient to meet it is provided. 7.2.2 IT environment Security Functional Requirements (SFRs) Rationale The mapping between the SFRs and the Security Objectives is shown in the table below. The SFRs appear on the left for each row, and corresponding Security Objectives are indicated by an ‘X’ in the appropriate column. Table 7-7: IT environment Security Functional Requirements SFR Description O.RESIDUAL_INFOR MATION O.NO_MOD O.NO_BYPASS O.AUDITING FDP_RIP.1 Subset Residual Information Protection X FPT_RVM.1 Non-bypassability of the TSP X FPT_SEP.1 TSF Domain Separation X FPT_STM.1 Reliable Time Stamp X ECMS Security Target Issue 1.2 Page 7-9 The rationale for the SFRs against the security objectives of the IT environment is given in the table below. For each security objective of the IT environment, a list of assigned SFRs is given, followed by an argument stating how each SFR addresses or satisfies the security objective in question. Table 7-8: SFR security objective Security Objective SFR Rationale O.RESIDUAL_INFO RMATION FDP_RIP.1 FDP_RIP.1 provides that the IT environment would protect residual information contained in resources to be recycled. O.NO_MOD FPT_SEP.1 FPT_SEP.1 provides that the IT environment would maintain the TOE in a secure domain protected from modification. O.NO_BYPASS FPT_RVM.1 FPT_RVM.1 provides that the IT environment would ensure successful invoking of the TSP enforcement functions. 7.2.3 SFR Dependency Rationale The following table shows the dependency analysis of the claimed SFRs for the TOE and the IT environment. The traceability of an SFR dependency is confirmed by selecting an SFR from the left-hand column and noting the columns in which an ‘X’ appears. Each such column determines an SFR that should be included in the claims of Section 5 by way of a dependency rule specified in the CC, Part 2. In the case where an alternative is specified in the CC, at least one of the alternative SFRs has been chosen. By confirming that each column SFR is also a row SFR in the matrix, the property of closure under dependencies is established for Section 5. Note: In this TOE FMT_MSA.3 does not depend on FMT_MSA.1 because role defaults are established by the developer and cannot be amended by users or Administrators. Table 7-9: SFR Dependency Rationale SFR FAU_GEN.1 FAU_SAR.1 FAU_STG.1 FDP_ACC.1 FDP_ACF.1 FDP_RIP.1 FIA_ATD.1 FIA_UAU.1 FIA_UID.2 FMT_MSA.3 FMT_SMR.1 FPT_RVM.1 FPT_SEP.1 FPT_STM.1 FAU_GEN.1 X ECMS Security Target Issue 1.2 Page 7-10 SFR FAU_GEN.1 FAU_SAR.1 FAU_STG.1 FDP_ACC.1 FDP_ACF.1 FDP_RIP.1 FIA_ATD.1 FIA_UAU.1 FIA_UID.2 FMT_MSA.3 FMT_SMR.1 FPT_RVM.1 FPT_SEP.1 FPT_STM.1 FAU_GEN.2 X X FAU_SAR.1 X FAU_SAR.3 X FAU_STG.1 X FAU_STG.3 X FAU_STG.4 X FDP_ACC.1 X FDP_ACF.1 X FDP_RIP.1 FIA_ATD.1 FIA_UAU.1 X FIA_UAU.7 X FIA_UID.2 FIA_USB.1 X FMT_MSA.3 X FMT_SMR.1 X FPT_RVM.1 FPT_SEP.1 FPT_STM.1 7.2.4 Security Assurance Requirements Rationale (SARs) Given the statement of security environment and security objectives contained in this ST, an assurance level of EAL3 is appropriate to capture the moderate level of independently assured protection provided by the TOE. For environments that have an adequate security policy and set of security procedures that address the issues raised in the environmental assumptions (see Section 3.1), the services of the TOE will provide secure discretionary access control and audit services. The vulnerability analysis required by AVA_VLA.1 and strength of function analysis required by AVA_SOF.1 are appropriate for the level of protection claimed by this TOE, and is provided, as referenced in Section 6.2 (see also Section 5.2.2 for claim). ECMS Security Target Issue 1.2 Page 7-11 7.3 TOE Summary Specification Rationale 7.3.1 IT Security Functions Rationale (SFRs) The mapping between the IT security functions and the SFRs is shown in the table below. Table 7-10: IT Security Functions Rationale SFR AUDIT DAC USER_LOGIN FAU_GEN.1 X FAU_GEN.2 X FAU_SAR.1 X FAU_SAR.3 X FAU_STG.1 X FAU_STG.3 X FAU_STG.4 X FDP_ACC.1 X FDP_ACF.1 X FIA_ATD.1 X FIA_UAU.1 X FIA_UAU.7 X FIA_UID.2 X FIA_USB.1 X FMT_MSA.3 X FMT_SMR.1 X The IT security functions appear on the left for each row and the corresponding SFRs are indicated by an ‘X’ in the appropriate column. The detailed traceability of the TSF to the Security Function Requirements follows. The TOE IT Security Functions are referenced to the list of SFRs, described in Section 5, that are provided by the defined IT Security Function. Specifications of IT Security Functions are provided in Section 6.1. A Coverage Mapping is included to describe how the IT Security Functions covers the referenced SFR. ECMS Security Target Issue 1.2 Page 7-12 Table 7-11: IT Security Functions Security Functional Requirement IT Security Function IT Security Function to SFR Coverage Mapping FAU_GEN.1 AUDIT AUDIT creates audit records satisfying the FAU_GEN.1 requirements for auditable events. FAU_GEN.2 AUDIT AUDIT creates audit records satisfying the FAU_GEN.2 requirements for association of auditable events with user name. FAU_SAR.1 AUDIT AUDIT provides everybody with the capability of reading all audit records and presents the records in a manner suitable to interpret. FAU_SAR.3 AUDIT AUDIT provides the ability to perform searches for audit events using event-type and/or dates as keys. FAU_STG.1 AUDIT AUDIT protects audit records from deletion and modification. FAU_STG.3 AUDIT AUDIT generates an alarm to the administrator if the audit trail exceeds 80%. FAU_STG.4 AUDIT AUDIT overwrites the oldest audit records (excluding any alarms that have not been acknowledged) when the audit log is full and generate an alarm to say that it has done so. FDP_ACC.1 DAC DAC provides the TOE DAC policy on all user subjects, message objects and operations between subjects and objects. FDP_ACF.1 DAC DAC enforces the DAC policies specified in FDP_ACF.1. FIA_ATD.1 DAC DAC maintains the required user attributes necessary to correctly mediate all DAC policies. FIA_UAU.1 USER_LOGIN USER_LOGIN does not permit user actions other than user identification to be performed prior to user authentication. FIA_UAU.7 USER_LOGIN USER_LOGIN does not provide explicit feedback to the user while authentication is in progress. FIA_UID.2 USER_LOGIN USER_LOGIN does not permit user actions prior to authentication with the exception of user identification. FIA_USB.1 USER_LOGIN USER_LOGIN provides a binding between user name and auditable events and discretionary access control mediations. FMT_MSA.3 DAC DAC enforces discretionary access control to provide restrictive default values for users on creation. FMT_SMR.1 DAC DAC enforces the security roles: a) Operator; b) Chief Operator & c) Administrator. ECMS Security Target Issue 1.2 Page 7-13 The combined aggregate of the TOE security functions satisfies the set of identified TOE SFRs as shown above. Provided the configuration and maintenance of the TOE is carried out in accordance with organisational policy, environmental assumptions the TOE security functional claims are valid. ECMS Security Target Issue 1.2 Page 8-1 8 REFERENCES CC Common Criteria for Information Technology Security Evaluation, August 1999, Version 2.1, CCIMB-99-032 CEM Common Methodology for Information Technology Security Evaluation, CEM-99/045, Part 2: Evaluation Methodology, Version 1.0, August 1999