© 2009 EMC Corporation EMC Corporation EMC® VoyenceControl™ v4.1.0 Security Target Evaluation Assurance Level: EAL2+ Document Version: 0.6 Prepared for: Prepared by: EMC Corporation Corsec Security, Inc. 176 South Street Hopkinton, MA 01748 10340 Democracy Lane, Suite 201 Fairfax, VA 22030 Phone: (508) 435-1000 Phone: (703) 267-6050 http://www.emc.com http://www.corsec.com Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 2 of 46 © 2009 EMC Corporation Revision History Version Modification Date Modified By Description of Changes 0.1 2008-11-21 Nathan Lee Initial draft. 0.2 2009-05-15 Christopher Lockard Addressed OR1-5 and CR1-5. 0.3 2009-05-29 Christopher Lockard Further updates based on previous ORs. 0.4 2009-06-23 Christopher Lockard Further updates based on EVC-ASE-INT-CR-5. 0.5 2009-07-21 Christopher Lockard Further updates based on CB-OR-2 0.6 2009-08-06 Christopher Lockard Further updates based on evaluator ORs and CRs. Specification of Solaris 10 (Release 6/06) Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 3 of 46 © 2009 EMC Corporation Table of Contents REVISION HISTORY ................................................................................................................................................2 TABLE OF CONTENTS ............................................................................................................................................3 TABLE OF FIGURES ................................................................................................................................................4 TABLE OF TABLES ..................................................................................................................................................4 1 SECURITY TARGET INTRODUCTION........................................................................................................5 1.1 PURPOSE.........................................................................................................................................................5 1.2 SECURITY TARGET AND TOE REFERENCES....................................................................................................5 1.3 TOE OVERVIEW .............................................................................................................................................6 1.3.1Brief Description of the Components of the TOE ..................................................................................................6 1.3.2TOE Environment..................................................................................................................................................7 1.4 TOE DESCRIPTION .........................................................................................................................................7 1.4.1TOE Physical and Logical Scope ..........................................................................................................................9 1.4.2Physical/Logical Features and Functionality Not Included in the TSF...............................................................11 2 CONFORMANCE CLAIMS............................................................................................................................12 3 SECURITY PROBLEM DEFINITION ..........................................................................................................13 3.1 THREATS TO SECURITY.................................................................................................................................13 3.2 ORGANIZATIONAL SECURITY POLICIES ........................................................................................................13 3.3 ASSUMPTIONS ..............................................................................................................................................14 4 SECURITY OBJECTIVES ..............................................................................................................................15 4.1 SECURITY OBJECTIVES FOR THE TOE...........................................................................................................15 4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ...................................................................15 4.2.1IT Security Objectives..........................................................................................................................................15 4.2.2Non-IT Security Objectives..................................................................................................................................16 5 EXTENDED COMPONENTS DEFINITION ................................................................................................17 6 SECURITY REQUIREMENTS.......................................................................................................................18 6.1.1Conventions.........................................................................................................................................................18 6.2 SECURITY FUNCTIONAL REQUIREMENTS......................................................................................................18 6.2.1Class FAU: Security Audit...................................................................................................................................20 6.2.2Class FDP: User Data Protection.......................................................................................................................22 6.2.3Class FIA: Identification and Authentication......................................................................................................27 6.2.4Class FMT: Security Management ......................................................................................................................28 6.2.5Class FPT: Protection of the TSF .......................................................................................................................30 6.2.6Class FTA: TOE Access ......................................................................................................................................31 6.3 SECURITY ASSURANCE REQUIREMENTS .......................................................................................................32 7 TOE SUMMARY SPECIFICATION..............................................................................................................33 7.1 TOE SECURITY FUNCTIONS..........................................................................................................................33 7.1.1Security Audit ......................................................................................................................................................34 7.1.2User Data Protection...........................................................................................................................................34 7.1.3Identification and Authentication ........................................................................................................................35 7.1.4Security Management ..........................................................................................................................................35 7.1.5Protection of the TSF...........................................................................................................................................35 7.1.6TOE Access..........................................................................................................................................................36 8 RATIONALE.....................................................................................................................................................37 8.1 CONFORMANCE CLAIMS RATIONALE ...........................................................................................................37 8.2 SECURITY OBJECTIVES RATIONALE..............................................................................................................37 8.2.1Security Objectives Rationale Relating to Threats ..............................................................................................37 8.2.2Security Objectives Rationale Relating to Policies..............................................................................................39 Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 4 of 46 © 2009 EMC Corporation 8.2.3Security Objectives Rationale Relating to Assumptions ......................................................................................40 8.3 RATIONALE FOR EXTENDED SECURITY FUNCTIONAL REQUIREMENTS .........................................................40 8.4 RATIONALE FOR EXTENDED TOE SECURITY ASSURANCE REQUIREMENTS..................................................40 8.5 SECURITY REQUIREMENTS RATIONALE........................................................................................................40 8.5.1Rationale for Security Functional Requirements of the TOE Objectives.............................................................40 8.5.2Security Assurance Requirements Rationale .......................................................................................................43 8.5.3Dependency Rationale.........................................................................................................................................44 9 ACRONYMS......................................................................................................................................................46 Table of Figures FIGURE 1 - VOYENCECONTROL ARCHITECTURE.............................................................................................................7 FIGURE 2 - TOE AND TOE ENVIRONMENT.....................................................................................................................9 Table of Tables TABLE 1 - ST AND TOE REFERENCES ............................................................................................................................5 TABLE 2 – CC AND PP CONFORMANCE ........................................................................................................................12 TABLE 3 – THREATS .....................................................................................................................................................13 TABLE 4 – ORGANIZATIONAL SECURITY POLICIES .......................................................................................................13 TABLE 5 – ASSUMPTIONS .............................................................................................................................................14 TABLE 6 – SECURITY OBJECTIVES FOR THE TOE .........................................................................................................15 TABLE 7 – IT SECURITY OBJECTIVES ...........................................................................................................................15 TABLE 8 – NON-IT SECURITY OBJECTIVES...................................................................................................................16 TABLE 9 – TOE SECURITY FUNCTIONAL REQUIREMENTS ............................................................................................18 TABLE 10 – ASSURANCE REQUIREMENTS.....................................................................................................................32 TABLE 11 – MAPPING OF TOE SECURITY FUNCTIONS TO SECURITY FUNCTIONAL REQUIREMENTS.............................33 TABLE 12 – THREATS:OBJECTIVES MAPPING...............................................................................................................37 TABLE 13 – POLICIES:OBJECTIVES MAPPING ...............................................................................................................39 TABLE 14 – ASSUMPTIONS:OBJECTIVES MAPPING .......................................................................................................40 TABLE 15 – OBJECTIVES:SFRS MAPPING.....................................................................................................................40 TABLE 16 – FUNCTIONAL REQUIREMENTS DEPENDENCIES ..........................................................................................44 TABLE 17 – ACRONYMS ...............................................................................................................................................46 Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 5 of 46 © 2009 EMC Corporation 1 Security Target Introduction This section identifies the Security Target (ST), Target of Evaluation (TOE), and the ST organization. The Target of Evaluation is EMC VoyenceControl v4.1.0, and will hereafter be referred to as the TOE throughout this document. The TOE is an automated compliance management, change management, and configuration management solution. 1.1 Purpose This ST contains the following sections to provide mapping of the Security Environment to the Security Requirements that the TOE meets in order to remove, diminish or mitigate the defined threats: Security Target Introduction (Section 1) – Provides a brief summary of the ST contents and describes the organization of other sections within this document. It also provides an overview of the TOE security functions and describes the physical and logical scope for the TOE, as well as the ST and TOE references. Conformance Claims (Section 2) – Provides the identification of any Common Criteria (CC), ST Protection Profile, and Evaluation Assurance Level (EAL) package claims. It also identifies whether the ST contains extended security requirements. Security Problem Definition (Section 3) – Describes the threats, organizational security policies, and assumptions that pertain to the TOE and its environment. Security Objectives (Section 4) – Identifies the security objectives that are satisfied by the TOE and its environment. Extended Components Definition (Section 5) – Identifies new components (extended Security Functional Requirements (SFRs) and extended Security Assurance Requirements (SARs)) that are not included in CC Part 2 or CC Part 3. Security Requirements (Section 6) – Presents the SFRs and SARs met by the TOE. TOE Summary Specification (Section 7) – Describes the security functions provided by the TOE that satisfy the security functional requirements and objectives. Rationale (Section 8) - Presents the rationale for the security objectives, requirements, and SFR dependencies as to their consistency, completeness, and suitability. Acronyms (Section 9) – Defines the acronyms and terminology used within this ST. 1.2 Security Target and TOE References Table 1 - ST and TOE References ST Title EMC Corporation EMC® VoyenceControl™ v4.1.0 Security Target ST Version Version 0.6 ST Author Corsec Security, Inc. Nathan Lee ST Publication Date 2009-08-06 TOE Reference EMC® VoyenceControl™ v4.1.0 build 863 Keywords automated compliance management, change management, configuration management Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 6 of 46 © 2009 EMC Corporation 1.3 TOE Overview The TOE Overview summarizes the usage and major security features of the TOE. The TOE Overview provides a context for the TOE evaluation by identifying the TOE type, describing the product, and defining the specific evaluated configuration. VoyenceControl is an automated compliance management, change management, and configuration management solution. It allows administrators to collaboratively design their network infrastructure while enforcing control over change processes. It also checks for and enforces compliance with corporate and regulatory requirements. End- users (both administrative and non-privileged) primarily use VoyenceControl as the central management “hub” for their IT1 infrastructure – all changes to infrastructure devices are made via VoyenceControl, which performs full auditing and compliance checking of every change and pushes the changes out to the managed devices. 1.3.1 Brief Description of the Components of the TOE VoyenceControl embodies a client-server architecture and consists of four (4) main components: Application and Database Server – The central management “hub” of the product. Also stores the data gathered and generated by the product, including device configuration data and audit data. Advisor Server – Hosts the report generators that analyze the device data stored by the product. Device Server(s) – Communicates with the managed devices on the network on behalf of the Application Server. Management Client (“Thick Client”) – Provides the primary administrative user interface for the product. Each of these components is modular, and can be installed on a server by itself or can be installed together with other components on the same server. The components are shown in Figure 1 below (in the figure, the Database Server and the Application Server are shown installed on the same physical server). VoyenceControl supports the following server operating system (OS) types: Windows Server 2003 Enterprise Edition Service Pack 1 Red Hat Enterprise Linux 5 Server (update 3, x86_64) Red Hat Enterprise Linux 5 Advanced Platform (update 3, x86_64) Solaris 10 (Release 6/06) The TOE requires Java version 1.6 update 12 or later be installed to function. 1 IT – Information Technology Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 7 of 46 © 2009 EMC Corporation Application and Database Server (running on hardware and OS) Remote Authentication Servers Device Server (running on hardware and OS) Advisor Server (running on hardware and OS) Management Workstation (running on hardware and OS) Managed Devices Legend: TACACS+, RADIUS, LDAP Notifications Web Services HTTPS HTTPS Telnet, SSH, SNMP, FTP, TFTP, SCP, HTTPS SNMP, Syslog, TFTP HTTPS (to download Thick Client) HTTPS Communications Interface Subsystem Figure 1 - VoyenceControl Architecture 2 1.3.2 TOE Environment VoyenceControl is a software-only TOE that is installed and deployed on general-purpose server hardware running a general-purpose operating system. 1.4 TOE Description In order to communicate with and manage the devices on the network, VoyenceControl stores the administrative credentials (i.e., username and password) for each device to be managed. Administrators authenticate to VoyenceControl, and then VoyenceControl performs operations on the devices on the administrator’s behalf by accessing the devices on the network using their administrative credentials. Using VoyenceControl in this manner – as the central management “hub” for the devices – helps to ensure that all device configuration changes are audited, and that device configurations remain in compliance with corporate policies. The Report Advisor Server allows administrators to generate highly configurable custom reports about their infrastructure. The TOE Evaluated version of the Report Advisor is 2.2.0 build 561. 2 SQL: Structured Query Language SMTP: Simple Mail Transport Protocol Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 8 of 46 © 2009 EMC Corporation The Application Server is responsible for collecting data about the devices from the Device Servers and storing this information in the Database. It is also responsible for handling all administrative requests by administrators, and for providing data to the Advisors on request. The Device Servers communicate with numerous devices on the network in order to collect status information from them and to push configuration changes from the Application Server to them. The Device Servers do not make any administrative decisions – they simply act on behalf of the Application Server. Communications between the Application Server and the Device Servers are encrypted using Secure Sockets Layer (SSL). The Device Servers can communicate with and manage devices via the following protocols: Simple Network Management Protocol (SNMP) versions 1, 2, and 3 Telnet Secure Shell (SSH) File Transfer Protocol (FTP) Trivial File Transfer Protocol (TFTP) Secure Copy (SCP) Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) Syslog (inbound from devices to the Device Server) Management is performed through these interfaces. This evaluation does not consider the cryptography implemented by these interfaces. VoyenceControl supports both local and remote authentication for TOE operators. For local authentication, hashes of user passwords are stored in the Database for comparison to hashes of entered passwords at the time of login. For remote authentication, RADIUS3 , TACACS+4 and LDAP5 servers (including Active Directory servers) are supported. The RADIUS, TACACS+, and LDAP remote authentication servers are considered part of the operating environment of the TOE. Very granular access control permissions are applied to authenticated users. By default, users have no privileges until privileges are assigned to them (or until they are assigned to a group which has permissions). VoyenceControl provides a rich set of permissions which can be granted to individual users or groups of users, allowing very fine- grained access control distinctions between users. VoyenceControl also generates robust audit logs of every successful event and every failed event in the product – an audit record is generated every time a permission check is performed and every time a login or logout occurs. Although the intended use of VoyenceControl is for device configurations to be stored within VoyenceControl and then pushed out to devices on administrators’ behalves, the product also offers a “cut-through” feature for administrators to use when they desire direct access to a device’s administrative interface. To use the “cut-through” feature, an administrator first logs into VoyenceControl and then tells VoyenceControl to initiate a cut-through to a specific device; VoyenceControl then sets up the appropriate connection for the administrator – for example, by opening a telnet connection to the device and presenting the telnet interface to the administrator. Administration of VoyenceControl is primarily performed through the Management Client, also called the “Thick Client.” The Thick Client is a Java-based utility that is installed on an administrator’s workstation and 3 RADIUS: Remote Authentication Dial-In User Service 4 TACACS: Terminal Access Controller Access-Control System Plus 5 LDAP: Lightweight Directory Access Protocol Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 9 of 46 © 2009 EMC Corporation communicates with the Application Server on the administrator’s behalf. All security-related decisions are made by the Application Server; the Thick Client simply provides the user interface used by the administrator. Administrators can view reports by logging into the Advisor Server using any web browser. 1.4.1 TOE Physical and Logical Scope Figure 2 illustrates the physical and logical scope and boundary of the overall solution and ties together all of the components of the TOE and the constituents of the TOE Environment. Application Server Component (Hardware and OS) Application Server Communication Subsystem Application Server and Database Subsystem Control Daemon Subsystem System Management Subsystem Device Server Component (Hardware and OS) Device Server Subsystem Device Server SysAdmin Subsystem Device Server Communication Subsystem Advisor Server Component (Hardware and OS) Report Advisor Subsystem Management Workstation Component (Hardware and OS) Thick Client Subsystem Web Browser Legend: JDBC HTTP HTTP(S) HTTPS (to download Thick Client) HTTP(S) HTTP Proprietary XML (in HTTP(S)) Proprietary XML (in HTTP(S)) Component Outside TOE Boundary TOE Boundary User User Interface Telnet File I/O SNMP SMTP HTTP(S) Flat File RMI JMS Web Services Web Services File I/O RMI Subsystem External Object Managed Devices Syslog SNMP TFTP Telnet FTP SSH SCP HTTP(S) Remote Authentication Servers Management Network E-Mail Server Telnet / SSH Terminal TACACS+ HTTP SSH RADIUS LDAP Figure 2 - TOE and TOE Environment VoyenceControl is a software-only TOE that is installed and deployed on general-purpose server hardware running a general-purpose operating system. The TOE boundary depicted above includes all of the Application Server subsystems, the Device Server subsystems, the Advisor Server subsystems, and the Thick Client. The server hardware, server operating systems, managed devices, remote authentication servers, and web browser are not included, since they are not provided as part of the product delivery. The TOE requires at least the following specifications to function: Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 10 of 46 © 2009 EMC Corporation a 2GHz6 processor, 1 GB7 of memory, 200 MB8 of storage space, Firefox 1.5 and/or Internet Explorer 6.0 or later, SSH version 2 or later, and Java 1.6.0_12 or later. The TOE runs on Microsoft Windows Server 2003, Red Hat Enterprise Linux 4 or 5, and Solaris 10 (Release 6/06). The specific hardware and software requirements for the TOE can be found in “Step 2: System Requirements” of the EMC VoyenceControl 4.1.0 Installing VoyenceControl on Solaris 10 P/N9 300-008-397 Rev A01, EMC VoyenceControl 4.1.0 Installing VoyenceControl on Red Hat Enterprise Linux 4 and 5 P/N 300-008- 392 Rev A01, and EMC VoyenceControl 4.1.0 Installing VoyenceControl on Windows Server 2003 P/N 300-008-395 Rev A01 documents. 1.4.1.1 Security Audit The TOE performs auditing of all events (whether they succeed or fail), and can be configured to store these events. The TOE audit records contain at least the following information: date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event. 1.4.1.2 User Data Protection The TOE enforces a Management Access Control Policy as well as a Device Information Flow Control Policy. The Management Access Control Policy dictates TOE permissions and their implementation. The Device Information Flow Control Policy describes the interactions TOE users can have with devices based on their roles and permissions. 1.4.1.3 Identification and Authentication The TOE requires that all TOE users are authenticated by the TOE or the TOE environment prior to being granted access to the TOE functionality. 1.4.1.4 Security Management The TOE offers robust and granular permissioning of users, groups, and devices. TOE users are divided into two types: “Admins” are users who administer the TOE; “Users” are users who administer devices, but not the TOE itself. 1.4.1.5 Protection of the TSF The TOE implements a “health checker” daemon that periodically checks the status of all TOE components. If a component is malfunctioning, alerts are sent by the health checker daemon and (if installed on a Linux or Solaris OS) a “watchdog” daemon restarts the malfunctioning process. 6 GHz refers to gigahertz, or one billion cycles per second. 7 GB refers to a gigabyte, or one billion bytes. 8 MB refers to a megabyte, or one million bytes. 9 P/N – Part Number Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 11 of 46 © 2009 EMC Corporation 1.4.1.6 TOE Access The TOE will end the session of any idle user after a configurable period of inactivity. 1.4.2 Physical/Logical Features and Functionality Not Included in the TSF Cryptography used for SSL, SSH, HTTPS, SCP, and RMI over HTTPS The Advisor Server provides two primary reporting “advisors” excluded from the Evaluated version of the TOE: PCI10 Advisor – parses device data stored in the Database and generates a report indicating areas of non- compliance with the Payment Card Industry standard Network Advisor – parses device data stored in the Database and generates a report indicating potential applicable vulnerabilities Java 1.6.0_12, Firefox 1.5, Internet Explorer 6.0, and server-side RADIUS, TACACS+, LDAP, and Active Directory implementation. 10 PCI – Payment Card Industry Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 12 of 46 © 2009 EMC Corporation 2 Conformance Claims This section provides the identification for any CC, Protection Profile (PP), and EAL package conformance claims. Rationale is provided for any extensions or augmentations to the conformance claims. Rationale for CC and PP conformance claims can be found in Section 8.1. Table 2 – CC and PP Conformance Common Criteria (CC) Identification and Conformance Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 2, September 2007; CC Part 2 conformant; CC Part 3 conformant. PP Identification None Evaluation Assurance Level EAL2 augmented with Flaw Remediation (ALC_FLR.1) Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 13 of 46 © 2009 EMC Corporation 3 Security Problem Definition This section describes the security aspects of the environment in which the TOE will be used and the manner in which the TOE is expected to be employed. It provides the statement of the TOE security environment, which identifies and explains all: Known and presumed threats countered by either the TOE or by the security environment Organizational security policies with which the TOE must comply Assumptions about the secure usage of the TOE, including physical, personnel and connectivity aspects 3.1 Threats to Security This section identifies the threats against which the TOE must protect itself. The threat agents are individuals who are not authorized to use the TOE. The threat agents are assumed to: have public knowledge of how the TOE operates possess a basic skill level have limited resources to alter TOE configuration settings have no physical access to the TOE possess a basic level of motivation have a basic attack potential The IT assets requiring protection are the audit data, TOE configuration data, and the managed devices. The following threats are applicable: Table 3 – Threats Name Description T.COMINT An unauthorized individual may attempt to compromise the integrity of the audit data collected and produced by the TOE or TOE configuration data by bypassing a security mechanism. T.FAILURE A component of the TOE software might encounter an error which causes that component to malfunction, causing the TOE to operating in an incorrect or insecure manner. T.PRIVILEGE An unauthorized individual may gain access to the TOE and exploit system privileges to gain access to TOE security functions and data or managed devices. 3.2 Organizational Security Policies An Organizational Security Policy (OSP) is a set of security rules, procedures, or guidelines imposed by an organization on the operational environment of the TOE. The following OSPs are presumed to be imposed upon the TOE or its operational environment by any organization implementing the TOE in the CC evaluated configuration: Table 4 – Organizational Security Policies Name Description P.PASSWORD An authorized TOE user must use a sound password to access the TOE. A user password must have a minimum password length of eight characters and Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 14 of 46 © 2009 EMC Corporation Name Description must contain at least one non-alphanumeric character (from a set of 33), one numeric character (from a set of 10), and two alphabetical characters (from a set of 52, since upper- and lowercase characters are differentiated). 3.3 Assumptions This section describes the security aspects of the intended environment for the evaluated TOE. The operational environment must be managed in accordance with assurance requirement documentation for delivery, operation, and user guidance. The following specific conditions are required to ensure the security of the TOE and are assumed to exist in an environment where this TOE is employed. Table 5 – Assumptions Name Description A.NOEVIL Administrators are non-hostile, appropriately trained, and follow all administrator guidance. A.PHYSICAL Physical security will be provided for the TOE and its environment. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 15 of 46 © 2009 EMC Corporation 4 Security Objectives Security objectives are concise, abstract statements of the intended solution to the problem defined by the security problem definition (see Section 3). The set of security objectives for a TOE form a high-level solution to the security problem. This high-level solution is divided into two part-wise solutions: the security objectives for the TOE, and the security objectives for the TOE’s operational environment. This section identifies the security objectives for the TOE and its supporting environment. 4.1 Security Objectives for the TOE The specific security objectives for the TOE are as follows: Table 6 – Security Objectives for the TOE Name Description O.ACCESS The TOE must allow authorized users to access only appropriate TOE management functions and data, and only appropriate managed devices with appropriate permissions. O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data, ensuring that TOE users with the appropriate privileges, and only those TOE users, can exercise such control. O.AUDIT The TOE must gather audit records of actions on the TOE which may be indicative of misuse. O.IDAUTH The TOE or must be able to identify and authenticate users. O.INTEGR The TOE must ensure the integrity of all audit data. O.PROTECT The TOE must protect itself and the managed devices from unauthorized modifications and access to management functions, audit data, and configuration data. O.TESTS The TOE must perform periodic self-tests to ensure that the TOE is operating properly. 4.2 Security Objectives for the Operational Environment 4.2.1 IT Security Objectives The following IT security objectives are to be satisfied by the environment: Table 7 – IT Security Objectives Name Description OE.IDAUTH The TOE environment must be able to identify and authenticate users prior to allowing access to TOE administrative functions and data. OE.SEP The IT Environment will protect the TOE from external interference or tampering. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 16 of 46 © 2009 EMC Corporation OE.TIME The IT Environment will provide reliable timestamps for the TOE’s use. 4.2.2 Non-IT Security Objectives The following non-IT environment security objectives are to be satisfied without imposing technical requirements on the TOE. That is, they will not require the implementation of functions in the TOE hardware and/or software. Thus, they will be satisfied largely through application of procedural or administrative measures. Table 8 – Non-IT Security Objectives Name Description NOE.NOEVIL TOE users are non-hostile, appropriately trained, and follow all user guidance. NOE.PHYSICAL The TOE will be located within controlled access facilities, which will prevent unauthorized physical access. NOE.PASSWORD TOE users will only use strong passwords to access the TOE. A user password must have a minimum password length of eight characters and must contain at least one non-alphanumeric character (from a set of 33), one numeric character (from a set of 10), and two alphabetical characters (from a set of 52, since upper- and lowercase characters are differentiated). Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 17 of 46 © 2009 EMC Corporation 5 Extended Components Definition There are no extended SFRs or extended SARs met by the TOE. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 18 of 46 © 2009 EMC Corporation 6 Security Requirements This section defines the SFRs and SARs met by the TOE. These requirements are presented following the conventions identified in Section 6.1.1. 6.1.1 Conventions There are several font variations used within this ST. Selected presentation choices are discussed here to aid the Security Target reader. The CC allows for assignment, refinement, selection and iteration operations to be performed on security functional requirements. All of these operations are used within this ST. These operations are performed as described in Parts 2 and 3 of the CC, and are shown as follows: Completed assignment statements are identified using [italicized text within brackets]. Completed selection statements are identified using [underlined italicized text within brackets]. Refinements are identified using bold text. Any text removed is stricken (Example: TSF Data) and should be considered as a refinement. Extended Functional and Assurance Requirements are identified using “EXT_” at the beginning of the short name. Iterations are identified by appending a letter in parentheses following the component title. For example, FAU_GEN.1(a) Audit Data Generation would be the first iteration and FAU_GEN.1(b) Audit Data Generation would be the second iteration. 6.2 Security Functional Requirements This section specifies the SFRs for the TOE. This section organizes the SFRs by CC class. Table 9 identifies all SFRs implemented by the TOE and indicates the ST operations performed on each requirement. Table 9 – TOE Security Functional Requirements Name Description S A R I FAU_GEN.1 Audit data generation   FAU_SAR.1 Audit review   FAU_SAR.3 Selectable audit review   FAU_STG.1 Protected audit trail storage   FDP_ACC.2(a) Complete access control (audit and TOE configuration data)    FDP_ACF.1(a) Security attribute based access control (audit and TOE configuration data)    FDP_ACC.2(b) Complete access control (I&A data)    FDP_ACF.1(b) Security attribute based access control (I&A data)    FDP_IFC.2 Complete information flow control   FDP_IFF.2 Hierarchical security attributes   Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 19 of 46 © 2009 EMC Corporation Name Description S A R I FIA_ATD.1 User attribute definition   FIA_UAU.2 User authentication before any action   FIA_UID.2 User identification before any action   FMT_MOF.1 Management of security functions behaviour   FMT_MSA.1 Management of security attributes   FMT_MSA.3 Static attribute initialisation   FMT_MTD.1 Management of TSF data   FMT_SMF.1 Specification of management functions   FMT_SMR.1 Security roles   FPT_TST.1 TSF testing   FTA_SSL.3 TSF-initiated termination   Note: S=Selection; A=Assignment; R=Refinement; I=Iteration Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 20 of 46 © 2009 EMC Corporation 6.2.1 Class FAU: Security Audit FAU_GEN.1 Audit data generation Hierarchical to: No other components. FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: Start-up and shutdown of the audit functions; All auditable events, for the [not specified] level of audit; and [all user actions]. FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [no other audit relevant information]. Dependencies: FPT_STM.1 Reliable time stamps FAU_SAR.1 Audit review Hierarchical to: No other components. FAU_SAR.1.1 The TSF shall provide [System Admins and Network Admins] with the capability to read [audit information] from the audit records. FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. Dependencies: FAU_GEN.1 Audit data generation FAU_SAR.3 Selectable audit review Hierarchical to: No other components. FAU_SAR.3.1 The TSF shall provide the ability to apply [searching, sorting, and ordering] of audit data based on [user- specified parameters]. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 21 of 46 © 2009 EMC Corporation Dependencies: FAU_SAR.1 Audit review FAU_STG.1 Protected audit trail storage Hierarchical to: No other components. FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorised deletion. FAU_STG.1.2 The TSF shall be able to [prevent] unauthorised modifications to the stored audit records in the audit trail. Dependencies: FAU_GEN.1 Audit data generation Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 22 of 46 © 2009 EMC Corporation 6.2.2 Class FDP: User Data Protection FDP_ACC.2(a) Complete access control (audit and TOE configuration data) Hierarchical to: FDP_ACC.1 Subset access control FDP_ACC.2.1(a) The TSF shall enforce the [Management Access Control SFP11 ] on [subjects: TOE users and managed devices, and objects: audit data and TOE configuration data] and all operations among subjects and objects covered by the SFP. FDP_ACC.2.2(a) The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACF.1(a) Security attribute based access control (audit and TOE configuration data) Hierarchical to: No other components. FDP_ACF.1.1(a) The TSF shall enforce the [Management Access Control SFP] to objects based on the following: [ Subjects: TOE users, managed devices o Security Attributes:  Username  Group memberships  Individual user permissions  Inherited group permissions Objects: audit data and TOE configuration data o Security Attributes:  Permissions ]. FDP_ACF.1.2(a) 11 SFP: Security Function Policy Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 23 of 46 © 2009 EMC Corporation The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [an authorized user can manipulate audit data and/or the TOE configuration if the user has the appropriate permissions]. FDP_ACF.1.3(a) The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none]. FDP_ACF.1.4(a) The TSF shall explicitly deny access of subjects to objects based on the [none]. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACC.2(b) Complete access control (I&A data) Hierarchical to: FDP_ACC.1 Subset access control FDP_ACC.2.1(b) The TSF shall enforce the [I&A Access Control SFP12 ] on [subjects: TOE users and groups, and objects: TOE user credentials and permissions] and all operations among subjects and objects covered by the SFP. FDP_ACC.2.2(b) The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACF.1(b) Security attribute based access control (I&A data) Hierarchical to: No other components. FDP_ACF.1.1(b) The TSF shall enforce the [I&A Access Control SFP] to objects based on the following: [ Subjects: TOE users and groups o Security Attributes:  Username  Group memberships  Individual user permissions 12 SFP: Security Function Policy Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 24 of 46 © 2009 EMC Corporation  Inherited group permissions Objects: TOE user credentials and permissions o Security Attributes:  Usernames  Passwords (if the users are local users)  Group names  Group memberships  Individual user permissions  Group permissions ]. FDP_ACF.1.2(b) The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [an authorized user can manipulate user credentials and permissions if the user has the appropriate permissions]. FDP_ACF.1.3(b) The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: [none]. FDP_ACF.1.4(b) The TSF shall explicitly deny access of subjects to objects based on the [none]. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_IFC.2 Complete information flow control Hierarchical to: FDP_IFC.1 Subset information flow control FDP_IFC.2.1 The TSF shall enforce the [Device Information Flow Control SFP] on [subjects: TOE users, and objects: managed devices] and all operations that cause that information to flow to and from subjects covered by the SFP. FDP_IFC.2.2 The TSF shall ensure that all operations that cause any information in the TOE to flow to and from any subject in the TOE are covered by an information flow control SFP. Dependencies: FDP_IFF.1 Simple security attributes Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 25 of 46 © 2009 EMC Corporation FDP_IFF.2 Hierarchical security attributes Hierarchical to: FDP_IFF.1 Simple security attributes FDP_IFF.2.1 The TSF shall enforce the [Device Information Flow Control SFP] based on the following types of subject and information security attributes: [assignment: l Subjects: o TOE users and managed devices  Security Attributes: Username Group memberships Individual user permissions Inherited group permissions o Managed devices  Security Attributes: Identity Information: management traffic data o Security Attributes:  Destination device ]. FDP_IFF.2.2 The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules, based on the ordering relationships between security attributes hold: [an authorized user can send management traffic to a managed device if the user has the appropriate permissions]. FDP_IFF.2.3 The TSF shall enforce the [none]. FDP_IFF.2.4 The TSF shall explicitly authorise an information flow based on the following rules: [none]. FDP_IFF.2.5 The TSF shall explicitly deny an information flow based on the following rules: [none]. FDP_IFF.2.6 Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 26 of 46 © 2009 EMC Corporation The TSF shall enforce the following relationships for any two valid information flow control security attributes: There exists an ordering function that, given two valid security attributes, determines if the security attributes are equal, if one security attribute is greater than the other, or if the security attributes are incomparable; and There exists a “least upper bound” in the set of security attributes, such that, given any two valid security attributes, there is a valid security attribute that is greater than or equal to the two valid security attributes; and There exists a “greatest lower bound” in the set of security attributes, such that, given any two valid security attributes, there is a valid security attribute that is not greater than the two valid security attributes. Dependencies: FDP_IFC.1 Subset information flow control FMT_MSA.3 Static attribute initialisation Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 27 of 46 © 2009 EMC Corporation 6.2.3 Class FIA: Identification and Authentication FIA_ATD.1 User attribute definition Hierarchical to: No other components. FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [username, group memberships, individual user permissions, inherited group permissions, password (if the user is a local user)]. Dependencies: No dependencies FIA_UAU.2 User authentication before any action Hierarchical to: FIA_UAU.1 Timing of authentication FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. Dependencies: FIA_UID.1 Timing of identification FIA_UID.2 User identification before any action Hierarchical to: FIA_UID.1 Timing of identification FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Dependencies: No dependencies Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 28 of 46 © 2009 EMC Corporation 6.2.4 Class FMT: Security Management FMT_MOF.1 Management of security functions behaviour Hierarchical to: No other components. FMT_MOF.1.1 The TSF shall restrict the ability to [determine the behaviour of, disable, enable, modify the behaviour of] the functions [all functions] to [the users and groups with appropriate permissions]. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MSA.1 Management of security attributes Hierarchical to: No other components. FMT_MSA.1.1 The TSF shall enforce the [Management Access Control SFP and Device Information Flow Control SFP] to restrict the ability to [query, modify, delete] the security attributes [relevant to those SFPs] to [the users and groups with appropriate permissions]. Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow control] FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MSA.3 Static attribute initialisation Hierarchical to: No other components. FMT_MSA.3.1 The TSF shall enforce the [Management Access Control SFP and Device Information Flow Control SFP] to provide [restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the [users and groups with appropriate permissions] to specify alternative initial values to override the default values when an object or information is created. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MTD.1 Management of TSF data Hierarchical to: No other components. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 29 of 46 © 2009 EMC Corporation FMT_MTD.1.1 The TSF shall restrict the ability to [change_default, query, modify, delete] the [audit data and TOE configuration data] to [the users and groups with appropriate permissions]. Dependencies: FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_SMF.1 Specification of management functions Hierarchical to: No other components. FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [security attribute management, TSF data management, and security function management]. Dependencies: No Dependencies FMT_SMR.1 Security roles Hierarchical to: No other components. FMT_SMR.1.1 The TSF shall maintain the roles [System Admin; Network Admin; User Admin; and User]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. Dependencies: FIA_UID.1 Timing of identification Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 30 of 46 © 2009 EMC Corporation 6.2.5 Class FPT: Protection of the TSF FPT_TST.1 TSF testing Hierarchical to: No other components. FPT_TST.1.1 The TSF shall run a suite of self tests [periodically during normal operation] to demonstrate the correct operation of [the TSF]. FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of [[running TSF executable code]]. FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code. Dependencies: No dependencies Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 31 of 46 © 2009 EMC Corporation 6.2.6 Class FTA: TOE Access FTA_SSL.3 TSF-initiated termination Hierarchical to: No other components. FTA_SSL.3.1 The TSF shall terminate an interactive session after a [configurable time interval of user inactivity]. Dependencies: No dependencies Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 32 of 46 © 2009 EMC Corporation 6.3 Security Assurance Requirements This section defines the assurance requirements for the TOE. Assurance requirements are taken from the CC Part 3 and are EAL2 augmented with ALC_FLR.1. Table 10 – Assurance Requirements summarizes the requirements. Table 10 – Assurance Requirements Assurance Requirements Class ADV: Development ADV_ARC.1 Security Architecture Description ADV_FSP.2 Security-enforcing functional specification ADV_TDS.1 Basic design Class AGD: Guidance documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures Class ALC : Life-cycle support ALC_CMC.2 Use of a CM system ALC_CMS.2 Parts of the TOE CM coverage ALC_DEL.1 Delivery Procedures ALC_FLR.1 Basic Flaw Remediation Class ATE: Tests ATE_COV.1 Evidence of coverage ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample Class AVA: Vulnerability assessment AVA_VAN.2 Vulnerability analysis Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 33 of 46 © 2009 EMC Corporation 7 TOE Summary Specification This section presents information to detail how the TOE meets the functional requirements described in previous sections of this ST. 7.1 TOE Security Functions Each of the security requirements and the associated descriptions correspond to the security functions. Hence, each function is described by how it specifically satisfies each of its related requirements. This serves to both describe the security functions and rationalize that the security functions satisfy the necessary requirements. Table 11 – Mapping of TOE Security Functions to Security Functional Requirements TOE Security Function SFR ID Description Security Audit FAU_GEN.1 Audit data generation FAU_SAR.1 Audit review FAU_SAR.3 Selectable audit review FAU_STG.1 Protected audit trail storage User Data Protection FDP_ACC.2(a) Complete access control (audit and TOE configuration data) FDP_ACF.1(a) Security attribute based access control (audit and TOE configuration data) FDP_ACC.2(b) Complete access control (I&A data) FDP_ACF.1(b) Security attribute based access control (I&A data) FDP_IFC.2 Complete information flow control FDP_IFF.2 Hierarchical security attributes Identification and Authentication FIA_ATD.1 User attribute definition FIA_UAU.2 User authentication before any action FIA_UID.2 User identification before any action Security Management FMT_MOF.1 Management of security functions behaviour FMT_MSA.1 Management of security attributes FMT_MSA.3 Static attribute initialisation FMT_MTD.1 Management of TSF data FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 34 of 46 © 2009 EMC Corporation TOE Security Function SFR ID Description Protection of the TSF FPT_TST.1 TSF testing TOE Access FTA_SSL.3 TSF-initiated termination 7.1.1 Security Audit The TOE performs auditing of all events (whether they succeed or fail), and can be configured to store all of these events in the Central Event Log (CEL). The CEL is stored in a database and records all device events, application events, security events, configuration events, logins/logouts, job approvals, and credential changes. The TOE audit records contain at least the following information: date and time of the event, type of event, subject identity, and the outcome (success or failure) of the event. Audit review is performed through the “Event Manager” UI (User Interface). Event Manager provides robust searching and sorting of the audit records to users with the appropriate individual or inherited group permissions. There is no mechanism in the UI for deleting arbitrary audited records. TOE Security Functional Requirements Satisfied: FAU_GEN.1, FAU_SAR.1, FAU_SAR.3, FAU_STG.1. 7.1.2 User Data Protection 7.1.2.1 Management Access Control Policy Management Access Control permissions are implemented in a very granular and hierarchical way. The “subjects” of the Policy are the users and managed devices. Each user has a username, group membership, inherited group permissions, and individual permissions; each managed device has an identity. The “objects” of the Management Access Control Policy are the audit data and TOE configuration data to be managed. Access Control decisions are made based on the “most specific” permission information available for a given subject and a given object – for example, if a user has “allow” permission on a specific device but “deny” permission on the network to which that device belongs, the user will be allowed to perform actions on that particular device but not on other devices in that network (unless he also has device-specific permissions on another device in that network). 7.1.2.2 I&A Access Control Policy I&A Access Control permissions are implemented in a very granular and hierarchical way. The “subjects” of the Policy are the users and user groups. Each user has a username, password (if the user is a local user), group membership, and individual permissions. Each user group has a group name and group permissions. The “objects” of the I&A Access Control Policy are the user and group credentials and permissions to be managed. As with the Management Access Control Policy, Access Control decisions are made based on the “most specific” permission information available for a given subject and a given object. 7.1.2.3 Device Information Flow Control Policy Information Flow Control permissions are also implemented in a very granular and hierarchical way. The “subjects” of the Device Information Flow Control Policy are the users and the managed devices. Each user has a username, group membership, inherited group permissions, and individual permissions; each managed device has an identity. The “information” controlled by the Policy is the management traffic to be sent to the managed devices. Information Flow Control decisions are made based on the “most specific” permission information available for a given potential information flow – for example, if a user has “allow” permission on a specific device but “deny” permission on the other devices on the network to which that device belongs, the user will be allowed to perform Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 35 of 46 © 2009 EMC Corporation actions only on that particular device, unless he also has device-specific permissions on another device in that network. TOE Security Functional Requirements Satisfied: FDP_ACC.2(a), FDP_ACF.1(a), FDP_ACC.2(b), FDP_ACF.1(b), FDP_IFC.2, FDP_IFF.2. 7.1.3 Identification and Authentication The Identification and Authentication function ensures that the TOE user that is requesting a service has provided a valid username and password and is authorized to access that service. For each user, the TOE stores the following security attributes in the database: username, group memberships, individual user permissions, inherited group permissions, and password (if the user is a local user). The TOE can be configured to use a local user database, or to use remote authentication databases (RADIUS, TACACS, TACACS+, or LDAP). This security functionality is the responsibility of the Operational Environment. When a TOE user enters his username and password at a management interface, the information is checked against the local database or sent to the configured remote authentication server. If the provided username and password are valid then the TOE allows the user to access the TOE with the permissions associated with that username. Before identification and authentication, the TOE user is only able to identify and authenticate himself. TOE Security Functional Requirements Satisfied: FIA_ATD.1, FIA_UAU.2, FIA_UID.2. 7.1.4 Security Management The TOE offers very robust and granular permissioning of users, groups, and devices. This allows the TOE to maintain an unbounded number of differently permissioned users and groups. There are two main types of TOE users: “Admins” are users who administer the TOE; “Users” are users who administer devices, but not the TOE itself. The “Admins” user type is further broken down into three general types of Admin: 1. System Admin – has full privileges over all of the TOE 2. Network Admin – has full privileges, but only for the network(s) he is assigned to. 3. User Admin – can create users and groups and assign permissions and roles, but cannot assign anything more privileged than his own privileges. The TOE does not allow users to have null passwords and does not provide anonymous access. Admins can lock any user account at any time. TOE Security Functional Requirements Satisfied: FMT_MOF.1, FMT_MSA.1, FMT_MSA.3, FMT_MTD.1, FMT_SMF.1, FMT_SMR.1. 7.1.5 Protection of the TSF The TOE implements a “health checker” daemon that periodically checks the status of all product components. If a component is malfunctioning, configurable alerts are sent. In addition, if the product is installed on a Linux or Solaris operating system, a “watchdog” daemon periodically checks important TOE processes and restarts them if malfunctions are encountered. TOE Security Functional Requirements Satisfied: FPT_TST.1. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 36 of 46 © 2009 EMC Corporation 7.1.6 TOE Access The TOE will end the session of any idle user after a configurable period of inactivity. TOE Security Functional Requirements Satisfied: FTA_SSL.3. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 37 of 46 © 2009 EMC Corporation 8 Rationale 8.1 Conformance Claims Rationale There are no Protection Profile conformance claims associated with this Security Target. 8.2 Security Objectives Rationale This section provides a rationale for the existence of each threat, policy statement, and assumption that compose the Security Target. Sections 8.2.1, 8.2.2, and 8.2.3 demonstrate the mappings between the threats, polices, and assumptions to the security objectives is complete. The following discussion provides detailed evidence of coverage for each threat, policy, and assumption. 8.2.1 Security Objectives Rationale Relating to Threats Table 12 – Threats:Objectives Mapping Threats Objectives Rationale T.COMINT An unauthorized individual may attempt to compromise the integrity of the audit data collected and produced by the TOE or TOE configuration data by bypassing a security mechanism. O.ACCESS The TOE must allow authorized users to access only appropriate TOE management functions and data, and only appropriate managed devices with appropriate permissions. The O.ACCESS objectives ensure that unauthorized modifications and access to functions and data is prevented. The O.ACCESS objective provides that the TOE must allow authorized operators to access only appropriate TOE functions and data. O.AUDIT The TOE must gather audit records of actions on the TOE which may be indicative of misuse. The O.AUDIT objective provides defense in depth, by requiring the recording and availability of audit records for review by an authorized operator of the TOE. O.IDAUTH The TOE or the TOE environment must be able to identify and authenticate users prior to allowing access to TOE administrative functions and data. The O.IDAUTH objective requires that the TOE must be able to identify and authenticate operators. O.INTEGR The TOE must ensure the integrity of all audit data. This threat is primarily diminished by the O.INTEGR objective, which requires that the TOE ensure the integrity of all audit data. O.PROTECT The TOE must protect itself and the managed devices from unauthorized modifications and access to management functions, audit data, and configuration data. The O.PROTECT objective requires that the TOE protect itself from unauthorized modifications and access to its functions and data. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 38 of 46 © 2009 EMC Corporation Threats Objectives Rationale OE.IDAUTH The OE.IDAUTH objective requires that the TOE environment must be able to identify and authenticate operators prior to allowing access to TOE functions and data. OE.SEP The IT Environment will protect the TOE from external interference or tampering. The OE.SEP objective also supports these objectives by requiring that the IT environment protect the TOE from interference that would prevent it from performing its functions. OE.TIME The IT Environment will provide reliable timestamps for the TOE’s use. The OE.TIME objective supports these objectives by providing for reliable timestamps to be used by the TOE. T.FAILURE A component of the TOE software might encounter an error which causes that component to malfunction, causing the TOE to operating in an incorrect or insecure manner. O.TESTS The TOE must perform periodic self- tests to ensure that the TOE is operating properly. The O.TESTS objective requires that the TOE run a series of tests on its software components to ensure that they are operating correctly. T.PRIVILEGE An unauthorized individual may gain access to the TOE and exploit system privileges to gain access to TOE security functions and data or managed devices. O.ACCESS The TOE must allow authorized users to access only appropriate TOE management functions and data, and only appropriate managed devices with appropriate permissions. The O.ADMIN and O.ACCESS objectives together ensure that policies won’t be subverted or changed by unauthorized users. The O.ACCESS objective provides that the TOE must allow authorized operators to access only appropriate TOE functions and data. O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data, ensuring that TOE users with the appropriate privileges, and only those TOE users, can exercise such control. The O.ADMIN and O.ACCESS objectives together ensure that policies won’t be subverted or changed by unauthorized users. The O.ADMIN objective ensures that only TOE operators with appropriate privileges can manage the functions and data of the TOE. O.AUDIT The TOE must gather audit records of actions on the TOE which may be indicative of misuse. The O.AUDIT objective provides defense in depth, by requiring the recording and availability of audit records for review by an authorized operator of the TOE. O.IDAUTH The TOE must be able to identify and authenticate users prior to allowing access to TOE administrative functions and data. This threat is primarily diminished by the O.IDAUTH objective, which requires that the TOE must be able to identify and authenticate operators prior to allowing access to TOE functions and data. O.PROTECT The TOE must protect itself and the The O.PROTECT objective requires that the TOE protect itself from Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 39 of 46 © 2009 EMC Corporation Threats Objectives Rationale managed devices from unauthorized modifications and access to management functions, audit data, and configuration data. unauthorized modifications and access to its functions and data. OE.SEP The IT Environment will protect the TOE from external interference or tampering. The OE.SEP objective also supports these objectives by requiring that the IT environment protect the TOE from interference that would prevent it from performing its functions. OE.TIME The IT Environment will provide reliable timestamps for the TOE’s use. The OE.TIME objective supports these objectives by providing for reliable timestamps to be used by the TOE. Every Threat is mapped to one or more Objectives in the table above. This complete mapping demonstrates that the defined security objectives counter all defined threats. 8.2.2 Security Objectives Rationale Relating to Policies Table 13 – Policies:Objectives Mapping Policies Objectives Rationale P.PASSWORD An authorized TOE user must use a sound password to access the TOE. A user password must have a minimum password length of eight characters and must contain at least one non-alphanumeric character (from a set of 33), one numeric character (from a set of 10), and two alphabetical characters (from a set of 52, since upper- and lowercase characters are differentiated). NOE.PASSWORD TOE users must use strong passwords that are not susceptible to brute force attacks or dictionary attacks by ensuring the characters that make up their passwords contain many different numeric and alphanumeric characters. NOE.PASSWORD ensures that TOE users use strong passwords to gain access to the TOE. O.IDAUTH The TOE must be able to identify and authenticate users. O.IDAUTH ensures that a user must identify and authenticate before access to the TOE and its managed devices is granted. OE.IDAUTH The OE.IDAUTH objective requires that the TOE environment must be able to identify and authenticate operators prior to allowing access to TOE functions and data. OE.IDAUTH ensures that the TOE environment is able to identify and authenticate operators prior to access to TOE functions and data. Every policy is mapped to one or more Objectives in the table above. This complete mapping demonstrates that the defined security objectives enforce all defined policies. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 40 of 46 © 2009 EMC Corporation 8.2.3 Security Objectives Rationale Relating to Assumptions Table 14 – Assumptions:Objectives Mapping Assumptions Objectives Rationale A.NOEVIL Administrators are non-hostile, appropriately trained, and follow all administrator guidance. NOE.NOEVIL TOE users are non-hostile, appropriately trained, and follow all user guidance. The NOE.NOEVIL objective ensures that TOE users are non-hostile, appropriately trained, and follow all operator guidance. A.PHYSICAL Physical security will be provided for the TOE and its environment. NOE.PHYSICAL The TOE will be located within controlled access facilities, which will prevent unauthorized physical access. The NOE.PHYSCL objective requires that the TOE will be located within controlled access facilities, which will prevent unauthorized physical access. Every assumption is mapped to one or more Objectives in the table above. This complete mapping demonstrates that the defined security objectives uphold all defined assumptions. 8.3 Rationale for Extended Security Functional Requirements There are no extended security functional requirements associated with this Security Target. 8.4 Rationale for Extended TOE Security Assurance Requirements There are no extended TOE security assurance requirements associated with this Security Target. 8.5 Security Requirements Rationale The following discussion provides detailed evidence of coverage for each security objective. 8.5.1 Rationale for Security Functional Requirements of the TOE Objectives Table 15 – Objectives:SFRs Mapping Objective SFR Rationale O.ACCESS The TOE must allow authorized users to access only appropriate TOE management functions and data, and only appropriate managed devices with appropriate permissions. FDP_ACC.2(a) Complete access control (audit and TOE configuration data) The TOE has an access control policy that ensures that only authorized users gain access to TOE functions and data. FDP_ACF.1 (a) Security attribute based access control (audit and The TOE is required to provide authorized users access to TOE functions and data. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 41 of 46 © 2009 EMC Corporation Objective SFR Rationale TOE configuration data) FDP_ACC.2(b) Complete access control (I&A data) The TOE has an access control policy that ensures that only authorized users can modify user credentials and permissions. FDP_ACF.1 (b) Security attribute based access control (I&A data) The TOE is required to provide authorized users the ability to modify user credentials and permissions. FDP_IFC.2 Complete information flow control The TOE has an information flow control policy that ensures that only authorized users gain access to managed devices. FDP_IFF.2 Hierarchical security attributes The TOE is required to provide authorized users access to managed devices. FIA_UAU.2 User authentication before any action The TOE will not give any security sensitive access to a user until the TOE has authenticated the user. FIA_UID.2 User identification before any action The TOE will not give any security sensitive access to a user until the TOE has identified the user. FMT_MOF.1 Management of security functions behaviour The TOE is required to provide the ability to restrict managing the behavior of functions of the TOE to authorized users of the TOE. FMT_MSA.3 Static attribute initialisation Restrictive values for TOE functions and data are provided, and the authorized administrator can change them when an object is created. FMT_MTD.1 Management of TSF data Only authorized users of the System may query and modify TOE data. O.ADMIN The TOE must include a set of functions that allow efficient management of its functions and data, ensuring that TOE users with the appropriate privileges, and only those TOE users, can exercise such control. FMT_MOF.1 Management of security functions behaviour Only those roles defined in FMT_SMR.1 are given the right to control the behavior of the TSF. FMT_MSA.3 Static attribute initialisation Restrictive values for TOE functions and data are provided, and the authorized administrator can change them when a data object is created. FMT_MTD.1 Management of TSF data Only those roles defined in FMT_SMR.1 are given the right to access TSF data. FMT_SMF.1 Specification of management functions Mechanisms exist to enforce the rules defined in FMT_MOF.1, FMT_MTD.1(a), and FMT_MTD.1(b). Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 42 of 46 © 2009 EMC Corporation Objective SFR Rationale FMT_SMR.1 Security roles The TOE defines a set of roles. FTA_SSL.3 TSF-initiated termination The TOE automatically terminates administrative sessions after a configurable period of inactivity. O.AUDIT The TOE must gather audit records of actions on the TOE which may be indicative of misuse. FAU_GEN.1 Audit data generation The requirement meets this objective by ensuring that the TOE maintains a record of defined security related events, including relevant details about the event. FAU_SAR.1 Audit review The TOE must provide the ability to review the audit trail of the system. FAU_SAR.3 Selectable audit review The TOE must provide the ability to search, sort, and order the audit trail of the system. O.IDAUTH The TOE must be able to identify and authenticate users prior to allowing access to TOE administrative functions and data. FIA_ATD.1 User attribute definition Security attributes of subjects used to enforce the authentication policy of the TOE must be defined. FIA_UAU.2 User authentication before any action The TOE will not give any security sensitive access to a user until the TOE has authenticated the user. FIA_UID.2 User identification before any action The TOE will not give any security sensitive access to a user until the TOE has identified the user. FMT_SMR.1 Security roles The TOE must be able to recognize the different user roles that exist for the TOE. O.INTEGR The TOE must ensure the integrity of all audit data. FAU_STG.1 Protected audit trail storage The TOE is required to protect the audit data from unauthorized deletion. FDP_ACF.1 (a) Security attribute based access control (audit and TOE configuration data) Only authorized TOE users with the appropriate permissions may access audit data. FMT_MSA.1 Management of security attributes Only authorized users of the System may query and modify TOE data. FMT_MTD.1 Management of TSF data Only authorized users of the System may query and modify TOE data. O.PROTECT The TOE must protect itself and the managed devices from FDP_ACC.2(a) Complete access control(audit and TOE The TOE has an access control policy that ensures that only authorized users can modify and access TOE functions and data. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 43 of 46 © 2009 EMC Corporation Objective SFR Rationale unauthorized modifications and access to management functions, audit data, and configuration data. configuration data) FDP_ACF.1(a) Security attribute based access control (audit and TOE configuration data) The TOE provides access control functionality to manage access to TOE functions and data. FDP_ACC.2(b) Complete access control (I&A data) The TOE has an access control policy that ensures that only authorized users can modify user credentials and permissions. FDP_ACF.1 (b) Security attribute based access control (I&A data) The TOE is required to provide authorized users the ability to modify user credentials and permissions. FDP_IFC.2 Complete information flow control The TOE has an information flow control policy that ensures that only authorized users gain access to managed devices. FDP_IFF.2 Hierarchical security attributes The TOE provides information flow control functionality to manage access to managed devices. FMT_MOF.1 Management of security functions behaviour The TOE is required to provide the ability to restrict managing the behavior of functions of the TOE to authorized users of the TOE. FMT_MTD.1 Management of TSF data Only authorized users of the System may query and modify TOE data. O.TESTS The TOE must perform periodic self-tests to ensure that the TOE is operating properly. FPT_TST.1 TSF testing The TOE runs a “health checker” daemon which periodically checks all components of the TOE for correct operation. 8.5.2 Security Assurance Requirements Rationale EAL2 was chosen to provide a low to moderate level of assurance that is consistent with good commercial practices. As such, minimal additional tasks are placed upon the vendor assuming the vendor follows reasonable software engineering practices and can provide support to the evaluation for design and testing efforts. The chosen assurance level is appropriate with the threats defined for the environment. While the TOE controls access to devices which might be deployed in a hostile environment, the TOE itself is expected to be in a non-hostile position and embedded in or protected by other products designed to address threats that correspond with the intended environment. At EAL2, the system will have incurred a search for obvious flaws to support its introduction into the non-hostile environment. The augmentation of ALC_FLR.1 was chosen to give greater assurance of the developer’s on-going flaw remediation processes. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 44 of 46 © 2009 EMC Corporation 8.5.3 Dependency Rationale This ST does satisfy all the requirement dependencies of the Common Criteria. Table 16 lists each requirement to which the TOE claims conformance with a dependency and indicates whether the dependent requirement was included. As the table indicates, all dependencies have been met. Table 16 – Functional Requirements Dependencies SFR ID Dependencies Dependency Met Rationale FAU_GEN.1 FPT_STM.1  This dependency is met by the TOE environment. FAU_SAR.1 FAU_GEN.1  FAU_SAR.3 FAU_SAR.1  FAU_STG.1 FAU_GEN.1  FDP_ACC.2( a) FDP_ACF.1  Met by FDP_ACF.1(a). FDP_ACF.1( a) FDP_ACC.1  Although FDP_ACC.1 is not included, the hierarchical SFR FDP_ACC.2(a) is included. This satisfies this dependency. FMT_MSA.3  FDP_ACC.2( b) FDP_ACF.1  Met by FDP_ACF.1(b). FDP_ACF.1( b) FDP_ACC.1  Although FDP_ACC.1 is not included, the hierarchical SFR FDP_ACC.2(b) is included. This satisfies this dependency. FMT_MSA.3  FDP_IFC.2 FDP_IFF.1  Although FDP_IFF.1 is not included, the hierarchical SFR FDP_IFF.2 is included. This satisfies this dependency. FDP_IFF.2 FDP_IFC.1  Although FDP_IFC.1 is not included, the hierarchical SFR FDP_IFC.2 is included. This satisfies this dependency. FMT_MSA.3  FIA_ATD.1 None  FIA_UAU.2 FIA_UID.1  Although FIA_UID.1 is not included, the hierarchical SFR FIA_UID.2 is included. This satisfies this dependency. FIA_UID.2 None  FMT_MOF.1 FMT_SMR.1  FMT_SMF.1  FMT_MSA.1 FDP_ACC.1  Although FDP_ACC.1 is not included, the hierarchical SFRs FDP_ACC.2(a) and FDP_ACC.2(b) are included. This satisfies this dependency. Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 45 of 46 © 2009 EMC Corporation SFR ID Dependencies Dependency Met Rationale FMT_SMF.1  FMT_SMR.1  FMT_MSA.3 FMT_MSA.1  FMT_SMR.1  FMT_MTD.1 FMT_SMF.1  FMT_SMR.1  FMT_SMF.1 None  FMT_SMR.1 FIA_UID.1  Although FIA_UID.1 is not included, the hierarchical SFR FIA_UID.2 is included. This satisfies this dependency. FPT_TST.1 None  FTA_SSL.3 None  Security Target, Version 0.6 August 6, 2009 EMC VoyenceControl v4.1.0 Page 46 of 46 © 2009 EMC Corporation 9 Acronyms Table 17 – Acronyms Acronym Definition CC The Common Criteria for Information Technology Security Evaluation CEL Central Event Log EAL Evaluation Assurance Level FTP File Transfer Protocol GB Gigabyte (one billion bytes) GHz Gigahertz (one billion cycles per second) HTTPS Hypertext Transfer Protocol over SSL IT Information Technology LDAP Lightweight Directory Access Protocol MB Megabyte (one billion bytes) PCI Payment Card Industry P/N Part Number PP Protection Profile OS Operating System OSP Organizational Security Policy RADIUS Remote Authentication Dial-In User Service SAR Security Assurance Requirement SCP Secure Copy SFR Security Functional Requirement SFP Security Function Policy SMTP Simple Mail Transport Protocol SNMP Simple Network Management Protocol SQL Structured Query Language SSH Secure Shell SSL Secure Sockets Layer ST Security Target TACACS+ Terminal Access Controller Access-Control System Plus TFTP Trivial FTP TOE Target of Evaluation TSF TOE Security Function UI User Interface