Xceedium GateKeeper Version 3.6 Security Target
Version 1.0
October 11, 2006
Prepared for:
Xceedium, Inc.
30 Montgomery Street
Jersey City, NJ 07302
Prepared By:
Science Applications International Corporation
Common Criteria Testing Laboratory
7125 Columbia Gateway Drive, Suite 300
Columbia, MD 21046
Security Target Version 1.0
1. SECURITY TARGET INTRODUCTION...........................................................................................................4
1.1 SECURITY TARGET, TOE AND CC IDENTIFICATION........................................................................................4
1.2 CONFORMANCE CLAIMS.................................................................................................................................4
1.3 CONVENTIONS, TERMINOLOGY, ACRONYMS ..................................................................................................5
1.3.1 Conventions ...........................................................................................................................................5
1.3.2 Acronyms ...............................................................................................................................................5
2. TOE DESCRIPTION..........................................................................................................................................6
2.1 PRODUCT TYPE...............................................................................................................................................6
2.2 PRODUCT DESCRIPTION..................................................................................................................................6
2.3 PRODUCT FEATURES.......................................................................................................................................6
2.4 SECURITY ENVIRONMENT TOE BOUNDARY...................................................................................................7
2.4.1 Physical Boundaries ..............................................................................................................................7
2.4.2 Logical Boundaries................................................................................................................................8
3. SECURITY ENVIRONMENT...........................................................................................................................9
3.1 THREATS TO SECURITY...................................................................................................................................9
3.1.1 TOE Threats...........................................................................................................................................9
3.2 ORGANIZATION SECURITY POLICIES ..............................................................................................................9
3.3 SECURE USAGE ASSUMPTIONS .......................................................................................................................9
3.3.1 Physical Assumptions ............................................................................................................................9
3.3.2 Personnel Assumptions..........................................................................................................................9
4. SECURITY OBJECTIVES ................................................................................................................................9
4.1 IT SECURITY OBJECTIVES FOR THE TOE......................................................................................................10
4.2 NON-IT SECURITY OBJECTIVES FOR THE ENVIRONMENT .............................................................................10
5. IT SECURITY REQUIREMENTS..................................................................................................................10
5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................10
5.1.1 Audit Requirements..............................................................................................................................11
5.1.2 User Data Protection (FDP) ...............................................................................................................12
5.1.3 Identification and authentication (FIA)...............................................................................................12
5.1.4 Security management (FMT) ...............................................................................................................13
5.1.5 Protection of the TOE security functions (FPT) ..................................................................................14
5.2 IT REQUIREMENTS FOR THE ENVIRONMENT .................................................................................................14
5.3 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................14
5.3.1 Configuration management (ACM) .....................................................................................................15
5.3.2 Delivery and operation (ADO) ............................................................................................................15
5.3.3 Development (ADV).............................................................................................................................15
5.3.4 Guidance documents (AGD)................................................................................................................16
5.3.5 Tests (ATE) ..........................................................................................................................................17
5.3.6 Vulnerability assessment (AVA)...........................................................................................................18
6. TOE SUMMARY SPECIFICATION..............................................................................................................19
6.1 TOE SECURITY FUNCTIONS..........................................................................................................................19
6.1.1 Security Audit.......................................................................................................................................19
6.1.2 User Data Protection...........................................................................................................................19
6.1.3 Identification and Authentication ........................................................................................................20
6.1.4 Security Management ..........................................................................................................................20
6.1.5 Protection of Security Functions .........................................................................................................22
6.2 TOE SECURITY ASSURANCE MEASURES......................................................................................................22
6.2.1 Process Assurance...............................................................................................................................22
6.2.2 Delivery and Guidance........................................................................................................................22
.
2
Security Target Version 1.0
6.2.3 Development ........................................................................................................................................23
6.2.4 Tests.....................................................................................................................................................23
6.2.5 Vulnerability Assessment.....................................................................................................................24
7. PROTECTION PROFILE CLAIMS...............................................................................................................25
8. RATIONALE.....................................................................................................................................................26
8.1 SECURITY OBJECTIVES RATIONALE..............................................................................................................26
8.1.1 Security Objectives Rationale for the TOE and Environment..............................................................26
8.2 SECURITY REQUIREMENTS RATIONALE........................................................................................................27
8.2.1 Security Functional Requirements Rationale ......................................................................................27
8.3 SECURITY ASSURANCE REQUIREMENTS RATIONALE....................................................................................29
8.4 REQUIREMENT DEPENDENCY RATIONALE....................................................................................................29
8.5 EXPLICITLY STATED REQUIREMENTS RATIONALE........................................................................................30
8.6 TOE SUMMARY SPECIFICATION RATIONALE................................................................................................30
8.7 PP CLAIMS RATIONALE................................................................................................................................31
LIST OF TABLES
Table 1 Security Functional Components................................................................................................................11
Table 2 EAL 2 Assurance Components ...................................................................................................................15
Table 3 Environment to Objective Correspondence ..............................................................................................26
Table 4: Security objectives for the non-IT environment mapped to assumptions ............................................27
Table 5 Objective to Requirement Correspondence...............................................................................................28
Table 6 Requirement Dependency Rationales ........................................................................................................30
Table 7 Security Functions vs. Requirements Mapping.........................................................................................31
.
3
Security Target Version 1.0
1. Security Target Introduction
This section identifies the Security Target and Target of Evaluation (TOE) identification, ST conventions, ST
conformance claims, and the ST organization. Xceedium provides the TOE, which is Xceedium GateKeeper
Version 3.6. The TOE is an IT management tool that provides an organization the ability to remotely maintain
multiple network devices (servers, routers, and platforms) via any Java enabled browser, SSL transmission, and
administrator/user/device profiles and access policies.
The Security Target contains the following additional sections:
• Section 2 – Target of Evaluation (TOE) Description
This section gives an overview of the TOE, describes the TOE in terms of its physical and logical
boundaries, and states the scope of the TOE.
• Section 3 – TOE Security Environment
This section details the expectations of the environment, the threats that are countered by
Xceedium and it environment and the organizational policy that the Xceedium must fulfill.
• Section 4 –Security Objectives
This section details the security objectives of the Xceedium and its environment.
• Section 5 – IT Security Requirements
The section presents the security functional requirements (SFR) for Xceedium and IT
Environment that supports the TOE, and details the assurance requirements for EAL2.
• Section 6 – TOE Summary Specification
The section describes the security functions represented in the Xceedium that satisfy the security
requirements.
• Section 7 – Protection Profile Claims
This section presents any Protection Profile claims.
• Section 8 – Rationale
This section closes the ST with the justifications of the security objectives, requirements and TOE
summary specifications as to their consistency, completeness, and suitability.
1.1 Security Target, TOE and CC Identification
ST Title – Xceedium GateKeeper Version 3.6 Security Target
ST Version – Version 1.0
ST Date –October 11, 2006
TOE Identification – Xceedium GateKeeper Version 3.6
CC Identification – Common Criteria for Information Technology Security Evaluation, Version 2.3, August 2005,
ISO/IEC 15408
1.2 Conformance Claims
This TOE is conformant to the following CC specifications:
• Common Criteria for Information Technology Security Evaluation Part 2: Security functional
requirements, Version 2.3, August 2005.
• Part 2 Conformant
• Common Criteria for Information Technology Security Evaluation Part 3: Security assurance
requirements, Version 2.3, August 2005.
• Part 3 Conformant
.
4
Security Target Version 1.0
• Evaluation Assurance Level 2 (EAL2)
1.3 Conventions, Terminology, Acronyms
This section specifies the formatting information used in the Security Target.
1.3.1 Conventions
The following conventions have been applied in this document:
• Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be
applied to functional requirements: iteration, assignment, selection, and refinement.
o Iteration: allows a component to be used more than once with varying operations. In the ST,
iteration is indicated by a letter in parenthesis placed at the end of the component. For example
FDP_ACC.1(a) and FDP_ACC.1(b) indicate that the ST includes two iterations of the
FDP_ACC.1 requirement, a and b.
o Assignment: allows the specification of an identified parameter. Assignments are indicated using
bold and are surrounded by brackets (e.g., [assignment]).
o Selection: allows the specification of one or more elements from a list. Selections are indicated
using bold italics and are surrounded by brackets (e.g., [selection]).
o Refinement: allows the addition of details. Refinements are indicated using bold, for additions,
and strike-through, for deletions (e.g., “… all objects …” or “… some big things …”).
• Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as
captions.
1.3.2 Acronyms
The acronyms used within this Security Target:
ACM Access Control Management
AGD Administrator Guidance Document
CC Common Criteria
CD-ROM Compact Disk Read Only Memory
CM Control Management
DAC Discretionary Access Control
DO Delivery Operation
EAL Evaluation Assurance Level
FIPS Federal Information Processing Standards Publication
GB Gigabyte
I/O Input/Output
NIST National Institute of Standards and Technology
PP Protection Profile
RADIUS Remote Authentication Dial In User Service
SF Security Functions
.
5
Security Target Version 1.0
SFR Security Functional Requirements
ST Security Target
TOE Target of Evaluation
TSF TOE Security Functions
TSP TOE Security Policy
TSC TSF Scope of Control
2. TOE Description
The Target of Evaluation (TOE) is the Xceedium appliance Xceedium GateKeeper 3.6, hereafter referred to as the
TOE. The product is designed by Xceedium, located at, 30 Montgomery Street, Jersey City, NJ 07302.
2.1 Product Type
The TOE is an IT management appliance that provides an organization the ability to remotely maintain multiple
network devices (servers, routers, and platforms) via any Java enabled browser, SSL transmission (using OpenSSL
0.9.7j), and administrator/user/device profiles and access policies.
2.2 Product Description
The TOE is a rack mounted network appliance. The TOE provides remote IT support and monitoring to remote
sites or local office locations via a Java enabled web browser. Common environments for use are hosting/co-
location facilities where network access methods, monitoring, and security are essential. All communications
between the web-browser and TOE is via SSL (encrypted).
An administrator configures user access to network devices. The administrator configures custom module
permissions per user to the specific network devices. User entity includes both account and contact information.
Both an administrator and a user can update the user’s account information for Username, Password, First Name,
Last Name, Phone number, Beeper number, Email address, and other description such as department, location, etc..
The TOE enforces the associations between a user and a device1
. The attributes assigned to this relationship are the
access methods or services available to the user for this device. Every network device can be accessed by various
methods that include: VNC, Telnet, SSH, Intranet Browsing, Web Portal, Universal Port, and etc. Additional
optional capabilities include remote power, console, and IP-based KVM access.
Users and administrators access the TOE, but only administrators can access and set TOE security functions.
Administrators may view logins, user sessions, and reporting; set configuration parameters and conduct maintenance
tasks; create custom access; utilize management features; and set associations between users and devices. All
administrative actions are mediated by the TOE using an access control policy.
The evaluated configuration of Gatekeeper does not support the following product features:
1. Fail Over
2. Radius Server
3. Whole Security Scan
4. Modem
5. SNMP
2.3 Product Features
The TOE implements the following features:
1
The access control policy between users and devices in not the evaluated set of requirements.
.
6
Security Target Version 1.0
• Web-based access to establish VNC, Telnet, SSH, and standard operating system specific GUI sessions to
network devices over TCP/IP.
• Optional remote power, console, and/or IP based KVM management. (Users are able to turn attached
network devices on or off, console into network devices such as routers and switches, and access servers
down to the BIOS level).
• External appliance LCD display for entering initial host connection information or checking on system
configuration.
• Browser access to all types of graphical and text based sessions using Windows, Mac, UNIX, Telnet,
Secure Shell, 3270, and web-based applications accessed via an SSL tunnel to the network server.
• Supported systems platforms: Intel, Mac, Sun, HP, AIX, and IBM
• Supported network devices: Servers, Desktop PC’s, Routers, switches, terminal servers, private branch
exchange (PBX), and other network enabled devices.
• Authentication via TOE web server
• Multiple users can have GUI access to the same Windows, Unix, or Mac systems simultaneously to access
a network device
• Multiple text based UNIX sessions to access a network device
• SSL user communication
• Single Access Port to network devices
• Web interface GUI for administrators and users
• Monitoring, logging, and alert emails for monitored events
2.4 Security Environment TOE Boundary
The TOE includes both physical and logical boundaries.
2.4.1 Physical Boundaries
The TOE is an appliance and as such, its ports are its interfaces. The majority of the TOE’s functioning is
performed via its network port. The network port is used by both administrators and users to access the IT network
environment. This interface is provided by the TOE through a SSL connection. The TOE web server provides an
administrative interface for all TOE management functions. From this GUI interface, the administrator manages user
access.
A second physical boundary is its LCD Panel and four configuration buttons on the front of the TOE. This external
interface allows for basic network configuration of the device out of the box. Once the TOE basic network
configuration has been completed via the LCD Panel and buttons that interface with the configuration firmware, the
device is rebooted, and the web-based configuration of network parameters are completed via an Internet Browser
(any Java-enabled web browser). Once in the evaluated configuration the LCD Panel and buttons are not used and
do not need any further description.
.
7
Security Target Version 1.0
Xceedium GateKeeper TOE in its environment
2.4.2 Logical Boundaries
The logical boundaries of the TOE include the functions of the TOE interfaces.
2.4.2.1 Security Audit
The TOE Web Server generates audit records related to the authentication and management of the TOE that are
stored in the Secure DB. The function records attempts to access the system itself, such as successful and failed
authentication, as well as the actions taken by the user once authenticated. All auditable actions can be found in
Active Logins, Sessions, Logs and Report interface. The Logs Report Parameters screen allows administrator
selection of the specific report information to be generated.
2.4.2.2 User Data Protection
The TOE enforces user access policies by restricting what management functions an authorized administrator may
perform on the TOE. Access is restricted based on the user identifier and privileges associated with the requestor.
2.4.2.3 Identification and Authentication
The TOE requires users to provide unique identification and authentication data (User ID and Password) before any
access to the system is granted. The TOE provides authorized administrator’s the ability to define user device
access.
2.4.2.4 Security Management
The TOE is managed through the Xceedium Admin module interfaces (Config, Services, Sessions, Users, Devices,
Associations) , a SSL virtual desktop web-based interface. Through this interface all TOE management can be
performed, including user management and the configuration of IT devices access functions. This interface is
restricted to authorize administrators, which provides the administrator the ability to set user attributes and
privileges, as well as assign privileges for different levels of administrative access.
.
8
Security Target Version 1.0
Administration functions and programming tasks are done using PERL scripts. A Spadmin daemon accepts input
from specific functions on the web sever and LCD to control system configuration parameters. A TOE monitor
daemon performs a specialized small client monitoring feature. Scripts operate the features of the optional TOE
power, console, and IP based KVM device components.
2.4.2.5 Protection of Security Functions
The TOE generates timestamps for use within the audit trail.
3. Security Environment
The security environment for the functions addressed by this specification includes threats, security policies, and
usage assumptions, as discussed below.
3.1 Threats to Security
3.1.1 TOE Threats
T.PRIVIL An unauthorized user may gain access to the TOE and exploit system privileges to gain access to
TOE security functions and data.
3.2 Organization Security Policies
P.MANAGE The system must provide authorized administrators with utilities to effectively manage the
security functions of the TOE
P.PROTECT The TOE shall be protected from unauthorized accesses and disruptions of TOE data and
functions.
P.AUDIT Users of the system shall be held accountable for their security relevant actions within the system.
3.3 Secure Usage Assumptions
3.3.1 Physical Assumptions
A.LOCATE The processing resources of the TOE will be located within controlled access facilities, which will
prevent unauthorized physical access.
3.3.2 Personnel Assumptions
A.MANAGE There will be one or more competent individuals assigned to manage the TOE and the security of
the information it contains.
A.NOEVIL The authorized administrators are not careless, willfully negligent, or hostile, and will follow and
abide by the instructions provided by the TOE documentation.
4. Security Objectives
This section defines the security objectives for the TOE and its environment. These objectives are suitable to counter
all identified threats and cover all identified organizational security policies and assumptions. The TOE security
objectives are identified with 'O.' inserted at the beginning of the name and the environment objectives are identified
with 'OE.' inserted at the beginning of the name.
.
9
Security Target Version 1.0
4.1 IT Security Objectives for the TOE
The following security objectives are intended to be satisfied by the TOE.
O.PROTECT The TOE must protect itself from unauthorized modifications and access to its functions and data.
O.ACCESS The TOE must allow authorized users to access only appropriate TOE functions and data as
defined by the administrator.
O.AUDIT The TSF must record the security relevant actions of users of the TOE. The TSF must present this
information in a readable format to authorized administrators and ensure that only authorized users
are able to access this information.
O.MANAGE The TOE must provide services that allow effective management of its functions and data.
.O.TIME The TOE provides adequate time stamps for audit records
4.2 Non-IT Security Objectives for the Environment
OE.INSTALL Those responsible for the TOE must ensure that the TOE is delivered, installed, managed, and
operated in a manner that maintains the TOE security objectives.
OE.PERSON Authorized users of the TOE shall be properly trained in the configuration and usage of the TOE
and will follow the guidance provided. These users are not careless, negligent, or hostile.
OE.PHYCAL Those responsible for the TOE must ensure that the parts of the TOE critical to security policy are
protected from physical attack that might compromise the TOE security objectives.
5. IT Security Requirements
This section provides a list of all security functional requirements for the TOE.
5.1 TOE Security Functional Requirements
The following table lists the SFRs.
Security Functional Class Security Functional Components
FAU_GEN.1 Audit Data Generation
Security Audit (FAU)
FAU_SAR.1 Audit Review
FDP_ACC.1 Subset Access Control
User Data Protection (FDP)
FDP_ACF.1 Security attribute based access control
FIA_ATD.1 User attribute definition
FIA_UAU.2 User authentication before any action
FIA_UAU.7 Protected authentication feedback
Identification and authentication (FIA)
FIA_UID.2 User identification before any action
FMT_MOF.1 Management of security functions behavior
Management of security attributes – authentication data
(FMT_MSA.1a)
Management of security attributes – user identity
(FMT_MSA.1b)
FMT_MSA.3 Static attribute initialization
Security management (FMT)
FMT_SMF.1 Specification of management functions
.
10
Security Target Version 1.0
Security Functional Class Security Functional Components
FMT_SMR.1 Security roles
FMT_MTD.1(a)Management of TSF data (security-relevant
privileges)
FMT_MTD.1(b) Management of TSF data (audit data)
Protection of the TSF (FPT) FPT_STM.1 Reliable time stamps
Table 1 Security Functional Components
5.1.1 Audit Requirements
5.1.1.1 Audit Data Generation (FAU_GEN.1)
5.1.1.1.1FAU_GEN.1.1
The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [not specified] level of audit; and
c) [All authentication attempts to the TOE
d) Adding and Removing user accounts
e) Changes to authentication data (passwords)
f) Changes to user attributes and privileges].
5.1.1.1.2FAU_GEN.1.2
The TSF shall record within each audit record at least the following information:
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, [no other additional information]
5.1.1.2 Audit Review (FAU_SAR.1)
5.1.1.2.1FAU_SAR.1.1
The TSF shall provide [authorized administrators] with the capability to read [all audit information] from the
audit records.
5.1.1.2.2FAU_SAR.1.2
The TSF shall provide the audit records in a manner suitable for the user to interpret the information.
.
11
Security Target Version 1.0
5.1.2 User Data Protection (FDP)
5.1.2.1 Subset access control (FDP_ACC.1)
5.1.2.1.1FDP_ACC.1.1
The TSF shall enforce the [Management Access Control SFP] on [subjects: authorized administrators, objects:
the Management Interface, operations: access to Management Interfaces].
5.1.2.2 Security attribute based access control (FDP_ACF.1)
5.1.2.2.1FDP_ACF.1.1
The TSF shall enforce the [Management Access Control SFP] to objects based on the following;
[Subject: user identity and
Object: security privileges].
5.1.2.2.2FDP_ACF.1.2
The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled
objects is allowed: [An authorized user will be granted access to the management interface if their user
identity is assigned the appropriate privilege(s)].
5.1.2.2.3FDP_ACF.1.3
The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [no
additional explicit access rules].
5.1.2.2.4FDP_ACF.1.4
The TSF shall explicitly deny access of subjects to objects based on the [no additional explicit denial rules].
5.1.3 Identification and authentication (FIA)
5.1.3.1 User attribute definition (FIA_ATD.1)
5.1.3.1.1FIA_ATD.1.1
The TSF shall maintain the following list of security attributes belonging to individual users: [user identity,
authentication data, and security privileges].
5.1.3.2 User authentication before any action (FIA_UAU.2)
5.1.3.2.1FIA_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.
5.1.3.3 Protected authentication feedback (FIA_UAU.7)
5.1.3.3.1FIA_UAU.7.1
The TSF shall provide only [obscured feedback] to the user while the authentication is in progress.
.
12
Security Target Version 1.0
5.1.3.4 User identification before any action (FIA_UID.2)
5.1.3.4.1FIA_UID.2.1
The TSF shall require each user to identify itself before allowing any other TSF mediated actions on behalf of that
user.
5.1.4 Security management (FMT)
5.1.4.1 Management of security functions behavior (FMT_MOF.1)
5.1.4.1.1FMT_MOF.1.1
The TSF shall restrict the ability to [disable, enable, modify the behavior of] the functions [access control] to
[authorized administrators].
5.1.4.2 Management of security attributes – authentication data (FMT_MSA.1a)
5.1.4.2.1FMT_MSA.1.1a
The TSF shall enforce the [Management Access Control SFP] to restrict the ability to [modify, delete] the security
attributes [authentication data] to [authorized administrators and users authorized to modify their own
authentication data].
5.1.4.3 Management of security attributes – user identity (FMT_MSA.1b)
5.1.4.3.1FMT_MSA.1.1b
The TSF shall enforce the [Management Access Control SFP] to restrict the ability to [create] the security
attributes [user identity] to [authorized administrators].
5.1.4.4 Static attribute initialization (FMT_MSA.3)
5.1.4.4.1FMT_MSA.3.1
The TSF shall enforce the [Management Access Control SFP] to provide [restrictive] default values for security
attributes that are used to enforce the SFP.
5.1.4.4.2FMT_MSA.3.2
The TSF shall allow the [authorized administrators] to specify alternative initial values to override the default
values when an object or information is created.
5.1.4.5 Specification of Management Functions (FMT_SMF.1)
5.1.4.5.1FMT_SMF.1.1
The TSF shall be capable of performing the following security management functions: [
a) Management of access control
b) Management of audit and log functions].
.
13
Security Target Version 1.0
5.1.4.6 Security roles (FMT_SMR.1)
5.1.4.6.1FMT_SMR.1.1
The TSF shall maintain the roles [authorized administrators, users authorized to update account information
and Configurator].
5.1.4.6.2FMT_SMR.1.2
The TSF shall be able to associate users with roles.
5.1.4.7 Management of TSF data (FMT_MTD.1(a)) (Security-Relevant Privileges)
5.1.4.7.1FMT_MTD.1.1(a)
The TSF shall restrict the ability to [modify, delete/ clear] the [security-relevant privileges for users] to
[authorized administrators].
5.1.4.8 Management of TSF data (FMT_MTD.1(b)) (Audit data)
5.1.4.8.1FMT_MTD.1.1(b)
The TSF shall restrict the ability to [query] the [audit data] to [authorized administrators)].
5.1.5 Protection of the TOE security functions (FPT)
5.1.5.1 Reliable time stamps (FPT_STM.1)
5.1.5.1.1FPT_STM.1.1
The TSF shall be able to provide reliable time stamps for its own use.
5.2 IT Requirements for the Environment
There are no IT requirements for the environment.
5.3 TOE Security Assurance Requirements
The security assurance requirements for the TOE are the EAL 2 components as specified in Part 3 of the Common
Criteria. No operations are applied to the assurance components.
Requirement Class Requirement Component
ACM: Configuration management ACM_CAP.2: Configuration items
ADO: Delivery and operation ADO_DEL.1: Delivery procedures
ADO_IGS.1: Installation, generation, and start-up
procedures
ADV: Development ADV_FSP.1: Informal functional specification
ADV_HLD.1: Descriptive high-level design
ADV_RCR.1: Informal correspondence
demonstration
AGD: Guidance documents AGD_ADM.1: Administrator guidance
AGD_USR.1: User guidance
ATE: Tests ATE_COV.1: Evidence of coverage
.
14
Security Target Version 1.0
ATE_FUN.1: Functional testing
ATE_IND.2: Independent testing - sample
AVA: Vulnerability assessment AVA_SOF.1: Strength of TOE security function
evaluation
AVA_VLA.1: Developer vulnerability analysis
Table 2 EAL 2 Assurance Components
5.3.1 Configuration management (ACM)
5.3.1.1 Configuration items (ACM_CAP.2)
ACM_CAP.2.1d The developer shall provide a reference for the TOE.
ACM_CAP.2.2d The developer shall use a CM system.
ACM_CAP.2.3d The developer shall provide CM documentation.
ACM_CAP.2.1c The reference for the TOE shall be unique to each version of the TOE.
ACM_CAP.2.2c The TOE shall be labelled with its reference.
ACM_CAP.2.3c The CM documentation shall include a configuration list.
ACM_CAP.2.4c The configuration list shall uniquely identify all configuration items that comprise the TOE.
ACM_CAP.2.5c The configuration list shall describe the configuration items that comprise the TOE.
ACM_CAP.2.6c The CM documentation shall describe the method used to uniquely identify the configuration
items.
ACM_CAP.2.7c The CM system shall uniquely identify all configuration items.
ACM_CAP.2.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.2 Delivery and operation (ADO)
5.3.2.1 Delivery procedures (ADO_DEL.1)
ADO_DEL.1.1d The developer shall document procedures for delivery of the TOE or parts of it to the user.
ADO_DEL.1.2d The developer shall use the delivery procedures.
ADO_DEL.1.1c The delivery documentation shall describe all procedures that are necessary to maintain security
when distributing versions of the TOE to a user’s site.
ADO_DEL.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.2.2 Installation, generation, and start-up procedures (ADO_IGS.1)
ADO_IGS.1.1d The developer shall document procedures necessary for the secure installation, generation, and
start-up of the TOE.
ADO_IGS.1.1c The installation, generation and start-up documentation shall describe all the steps necessary for
secure installation, generation and start-up of the TOE.
ADO_IGS.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ADO_IGS.1.2e The evaluator shall determine that the installation, generation, and start-up procedures result in a
secure configuration.
5.3.3 Development (ADV)
5.3.3.1 Informal functional specification (ADV_FSP.1)
ADV_FSP.1.1d The developer shall provide a functional specification.
.
15
Security Target Version 1.0
ADV_FSP.1.1c The functional specification shall describe the TSF and its external interfaces using an informal
style.
ADV_FSP.1.2c The functional specification shall be internally consistent.
ADV_FSP.1.3c The functional specification shall describe the purpose and method of use of all external TSF
interfaces, providing details of effects, exceptions and error messages, as appropriate.
ADV_FSP.1.4c The functional specification shall completely represent the TSF.
ADV_FSP.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ADV_FSP.1.2e The evaluator shall determine that the functional specification is an accurate and complete
instantiation of the TOE security functional requirements.
5.3.3.2 Descriptive high-level design (ADV_HLD.1)
ADV_HLD.1.1d The developer shall provide the high-level design of the TSF.
ADV_HLD.1.1c The presentation of the high-level design shall be informal.
ADV_HLD.1.2c The high-level design shall be internally consistent.
ADV_HLD.1.3c The high-level design shall describe the structure of the TSF in terms of subsystems.
ADV_HLD.1.4c The high-level design shall describe the security functionality provided by each subsystem of the
TSF.
ADV_HLD.1.5c The high-level design shall identify any underlying hardware, firmware, and/or software required
by the TSF with a presentation of the functions provided by the supporting protection mechanisms
implemented in that hardware, firmware, or software.
ADV_HLD.1.6c The high-level design shall identify all interfaces to the subsystems of the TSF.
ADV_HLD.1.7c The high-level design shall identify which of the interfaces to the subsystems of the TSF are
externally visible.
ADV_HLD.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ADV_HLD.1.2e The evaluator shall determine that the high-level design is an accurate and complete instantiation
of the TOE security functional requirements.
5.3.3.3 Informal correspondence demonstration (ADV_RCR.1)
ADV_RCR.1.1d The developer shall provide an analysis of correspondence between all adjacent pairs of TSF
representations that are provided.
ADV_RCR.1.1c For each adjacent pair of provided TSF representations, the analysis shall demonstrate that all
relevant security functionality of the more abstract TSF representation is correctly and completely
refined in the less abstract TSF representation.
ADV_RCR.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.4 Guidance documents (AGD)
5.3.4.1 Administrator guidance (AGD_ADM.1)
AGD_ADM.1.1dThe developer shall provide administrator guidance addressed to system administrative personnel.
AGD_ADM.1.1cThe administrator guidance shall describe the administrative functions and interfaces available to
the administrator of the TOE.
AGD_ADM.1.2cThe administrator guidance shall describe how to administer the TOE in a secure manner.
AGD_ADM.1.3cThe administrator guidance shall contain warnings about functions and privileges that should be
controlled in a secure processing environment.
AGD_ADM.1.4cThe administrator guidance shall describe all assumptions regarding user behaviour that are
relevant to secure operation of the TOE.
AGD_ADM.1.5cThe administrator guidance shall describe all security parameters under the control of the
administrator, indicating secure values as appropriate.
AGD_ADM.1.6cThe administrator guidance shall describe each type of security-relevant event relative to the
administrative functions that need to be performed, including changing the security characteristics
of entities under the control of the TSF.
.
16
Security Target Version 1.0
AGD_ADM.1.7cThe administrator guidance shall be consistent with all other documentation supplied for
evaluation.
AGD_ADM.1.8cThe administrator guidance shall describe all security requirements for the IT environment that are
relevant to the administrator.
AGD_ADM.1.1eThe evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.4.2 User guidance (AGD_USR.1)
AGD_USR.1.1d The developer shall provide user guidance.
AGD_USR.1.1c The user guidance shall describe the functions and interfaces available to the non-administrative
users of the TOE.
AGD_USR.1.2c The user guidance shall describe the use of user-accessible security functions provided by the
TOE.
AGD_USR.1.3c The user guidance shall contain warnings about user-accessible functions and privileges that
should be controlled in a secure processing environment.
AGD_USR.1.4c The user guidance shall clearly present all user responsibilities necessary for secure operation of
the TOE, including those related to assumptions regarding user behaviour found in the statement
of TOE security environment.
AGD_USR.1.5c The user guidance shall be consistent with all other documentation supplied for evaluation.
AGD_USR.1.6c The user guidance shall describe all security requirements for the IT environment that are relevant
to the user.
AGD_USR.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.5 Tests (ATE)
5.3.5.1 Evidence of coverage (ATE_COV.1)
ATE_COV.1.1d The developer shall provide evidence of the test coverage.
ATE_COV.1.1c The evidence of the test coverage shall show the correspondence between the tests identified in the
test documentation and the TSF as described in the functional specification.
ATE_COV.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.5.2 Functional testing (ATE_FUN.1)
ATE_FUN.1.1d The developer shall test the TSF and document the results.
ATE_FUN.1.2d The developer shall provide test documentation.
ATE_FUN.1.1c The test documentation shall consist of test plans, test procedure descriptions, expected test results
and actual test results.
ATE_FUN.1.2c The test plans shall identify the security functions to be tested and describe the goal of the tests to
be performed.
ATE_FUN.1.3c The test procedure descriptions shall identify the tests to be performed and describe the scenarios
for testing each security function. These scenarios shall include any ordering dependencies on the
results of other tests.
ATE_FUN.1.4c The expected test results shall show the anticipated outputs from a successful execution of the
tests.
ATE_FUN.1.5c The test results from the developer execution of the tests shall demonstrate that each tested
security function behaved as specified.
ATE_FUN.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.3.5.3 Independent testing - sample (ATE_IND.2)
ATE_IND.2.1d The developer shall provide the TOE for testing.
ATE_IND.2.1c The TOE shall be suitable for testing.
.
17
Security Target Version 1.0
ATE_IND.2.2c The developer shall provide an equivalent set of resources to those that were used in the
developer’s functional testing of the TSF.
ATE_IND.2.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
ATE_IND.2.2e The evaluator shall test a subset of the TSF as appropriate to confirm that the TOE operates as
specified.
ATE_IND.2.3e The evaluator shall execute a sample of tests in the test documentation to verify the developer test
results.
5.3.6 Vulnerability assessment (AVA)
5.3.6.1 Strength of TOE security function evaluation (AVA_SOF.1)
AVA_SOF.1.1d The developer shall perform a strength of TOE security function analysis for each mechanism
identified in the ST as having a strength of TOE security function claim.
AVA_SOF.1.1c For each mechanism with a strength of TOE security function claim the strength of TOE security
function analysis shall show that it meets or exceeds the minimum strength level defined in the
PP/ST.
AVA_SOF.1.2c For each mechanism with a specific strength of TOE security function claim the strength of TOE
security function analysis shall show that it meets or exceeds the specific strength of function
metric defined in the PP/ST.
AVA_SOF.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
AVA_SOF.1.2e The evaluator shall confirm that the strength claims are correct.
5.3.6.2 Developer vulnerability analysis (AVA_VLA.1)
AVA_VLA.1.1d The developer shall perform a vulnerability analysis.
AVA_VLA.1.2d The developer shall provide vulnerability analysis documentation.
AVA_VLA.1.1c The vulnerability analysis documentation shall describe the analysis of the TOE deliverables
performed to search for obvious ways in which a user can violate the TSP.
AVA_VLA.1.2c The vulnerability analysis documentation shall describe the disposition of obvious vulnerabilities.
AVA_VLA.1.3c The vulnerability analysis documentation shall show, for all identified vulnerabilities, that the
vulnerability cannot be exploited in the intended environment for the TOE.
AVA_VLA.1.1e The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
AVA_VLA.1.2e The evaluator shall conduct penetration testing, building on the developer vulnerability analysis,
to ensure obvious vulnerabilities have been addressed.
.
18
Security Target Version 1.0
6. TOE Summary Specification
This chapter describes the security functions and associated assurance measures.
6.1 TOE Security Functions
Each of the security function descriptions is organized by the security requirements corresponding to the security
function. Hence, each function is described by describing how it specifically satisfies each of its related
requirements. This serves to both describe the security functions and rationalize that the security functions are
suitable to satisfy the necessary requirements.
6.1.1 Security Audit
FAU_GEN.1 Audit Data Generation
The TOE can generate audit records of all the events listed in section 5.1.1.1 as part of the definition of
FAU_GEN.1.1 with the exception of the event for audit startup and shutdown as auditing is always on. Audit
records include at least event time and date, event type, subject identity and outcome (success or failure) as well as
other data specific to the report type such as port, status, address etc. The audit trail is protected so that only an
authorized administrator can access the audit records.
The TOE generates audit data for all authentication attempts to the TOE, including successful and unsuccessful
attempts. The audit function also generates records for the creation, removal and modification of user accounts, as
well as the security-relevant privileges assigned to the accounts. The TOE also records all changes to authentication
data, whether changed by an administrator or the user.
Administrators have access to a sessions screen from which three types of reports can be –Active Logins, Sessions,
or Logs.
• Active Logins (under Sessions-> Manage Sessions link)– lists the users that are presently logged in to the
TOE
• Sessions (under Sessions ->Overview link)– lists the sessions that are presently in use to manage devices
from the TOE
• Logs (under Sessions -> Logs link) – lists the logs of previous transaction made to and/or from the TOE.
.FAU_SAR.1 Audit Review
The TOE presents the audit data in a format viewable by authorized administrators for review. The Report screen
displays the generated report.
6.1.2 User Data Protection
FDP_ACC.1 Subset Access Control
The TOE controls access to the Management interface by limiting access to authorized administrators for all
requests made to the management interface.
FDP_ACF.1 Security Attribute based access control
The TOE maintains a list of users (authorized users and administrators), authentication data and associated security
privileges. A user must successfully authenticate with a valid username and password before any access will be
granted to the administration modules or devices. Based upon the user’s identity, the user is assigned association
privileges, which are then used to provide access to specific management functions controlled by the TOE.
The TOE controls security policies that grant access to administrative functions based upon if a user identify has the
privilege associated with the specific management function. If a user has the correct privilege, access is granted. If
not, access is denied.
.
19
Security Target Version 1.0
6.1.3 Identification and Authentication
FIA_ATD.1 User Attribute Definition
Authorized administrator and user accounts in the TOE have the following attributes: user name, authentication data
(password), and their assigned privileges. The authentication data can be set to required levels using additive
hierarchal strength as defined by the administrator including the following: 0-Require New Password, 0+1-Require
length of X to Y as set by administrator, 1+2-Require Alpha-Numeric, 2+3-Require Upper and Lower Case, 3+4-
Require Special Characters. The evaluated configuration requires level 2. The authentication data is encrypted and
stored inside the TOE.
SSL is used to ensure secure access to the login interface. The TOE controls security policies that grant access to
operations, users, and objects. The TOE makes use of the three types of data entities. User entities relate to the user
accounts, Device entities relate to the devices configured for access or monitoring, and associations are the
relationship entities between users and devices.
A TOE administrator configures custom module permissions per user (a person configured for access to the TOE).
The user entity includes both account (UserId and password) and contact information (First name, Last Name,
Phone number, Beeper number, Email address, other description such as department, location, etc) for a user. Both
an administrator and a user can update the user’s entity information (Username, Password, First Name, Last Name,
Phone number, Beeper number, Email address, other description such as department, location, etc.)
Module permissions determine the features that the user will have access to, and type of user (access and/or
monitor). Typically users have access and monitoring permissions, and administrators have all permissions.
FIA_UAU.2 User Authentication before Any Action and FIA_UID.2 User identification before any action
The Identification and Authentication security function provides for user logon (authorized administrators and
users), and management of user profiles.
The administrative log-in and administration configuration modules allow for Configuration and Administration of
the TOE itself, as well as the permission to create/update/delete Users, Devices, and Associations. Access is
restricted to an administrator. Once authenticated, the administrator creates associations between a specific User
and a specific Device Associations are enforced by the TOE. This includes what devices each user is allowed to
access and/or manage. The association also controls what type of access the user will have to each Device.
The TOE requires users (authorized administrators and users) to provide unique identification and authentication
data (UserId and passwords) before any access to the system is granted. If the password comparison is the same
between the user and TOE stored password, the user is granted access. No administrative or user actions are allowed
until successful authentication as an authorized administrator or user
FIA_UAU.7 Protected authentication feedback
When authentication data is entered into the TOE, the input is obscured to prevent unauthorized viewing of the
entered data.
The TOE GUI Gateway interface uses a standard user name and password command line where the password is
obscured. If the UserId or Password is entered incorrectly, the TOE GUI will display a message stating “Bad User
Id or Password” on the login page allowing the user to make an additional attempt to authenticate. An administrator
can set a parameter in the TOE to allow only X number of “failed login attempts”. If that number is reached, the
user’s ID is disabled and prompts them to contact an administrator. An administrator can also set the TOE to notify
an administrator via email of the event.
6.1.4 Security Management
FMT_MOF.1 Management of security functions behavior
There are two pre-defined administrators in the TOE - Authorized Administrator and Configurator. Different types
of administrators can be created but all users with any ability to manage TOE data are administrators in CC
terminology. The TOE restricts the management of access control to authorized administrators. Only authorized
administrators are able to enable, disable or modify the behavior of administrator accounts.
.
20
Security Target Version 1.0
Authorized administrators control the TSF. A TOE administrator configures custom permissions per user (a person
configured for access to the TOE. The TOE consists of a number of administrative modules, which is a set of button
selections available at the top of the screen on the user’s web browser window each with its own set of features. A
user’s permissions are controlled by their access to the modules. Administrative module permissions determine the
features and devices that the user will have access to.
The user entity includes both account and contact information for a user. Both an administrator and a user can
update the user’s entity information.
Below is a summary of the Administration Modules:
• Sessions – a setting used to manage active logins, to view logs and view/create audit reports. This
privileges typically assigned to the GateKeeper administrators
• Config – a setting allowing this user to utilize the Configuration module features (setting Login, Session
timeouts, Password security level, Password failure limit and Password Change interval), typically assigned
to the TOE administrators
• Services – a setting allowing this user to utilize the Services module features which includes creating
custom access methods to run either their own local clients or launch a URL , typically assigned to the TOE
administrators
• Users – a setting allowing this user to utilize the Users module features which includes create, update and
delete user account and privileges, typically assigned to the TOE operation administrators
• Devices – a setting allowing this user to utilize the Devices module features which includes create, update
and delete devices, typically assigned to the TOE operation administrators
• Associations – a setting allowing this user to utilize the Associations module features which includes
create, update and delete association between users and devices, typically assigned to the TOE
administrators
FMT_MSA.1a and b Management of security attributes
The TOE enforces the Management Access Control SFP in allowing that only authorized administrators to create,
modify, and delete user accounts and authentication data. Users have the ability to change and modify their account
attributes (excluding ID and security relevant privileges) and authentication data.
FMT_MSA.3 Static attribute initialization
The TOE provides restrictive default values to provide enforcement of the Management Access Control SFP, which
can be overridden by authorized administrators when creating new accounts.
FMT_SMF.1 Specification of management functions
The TOE provides the ability to manage user accounts, including the ability to create, delete and modify existing
accounts, to authorized administrators.
The TOE provides an authorized administrator the ability to manage audit and log functions by providing an audit
review capability in the reporting menu. The administrator is also permitted to purge the audit logs.
FMT_MTD.1a Management of TSF Data (Access Control)
The TOE restricts the ability to administer the security-relevant privileges for users to only authorized
administrators.
The TOE restricts the ability to assign modules to users through authorized administrators. All users must change
their default authentication information when they try to access TOE first time. User and administrator can able to
update user account and authentication information. Successful authentication provides administrators to
create/modify/delete services, users, devices and associations. In Create User GUI, administrator able to define or
modify userid and module privileges for user. The Create User interface also provides the authorized administrator
the ability to configure authentication as local..
FMT_MTD.1b Management of TSF Data (Audit Data)
.
21
Security Target Version 1.0
The administration interface provides the abilities for only authorized administrators to perform the following tasks:
To view and query the audit logs
To purge audit logs
FMT_SMR.1 Security Roles
The TOE has two pre-defined roles, Authorized Administrator and Configurator. Authorized Administrator can
define other users each with its own set of privileges. The Configurator is able to access configuration pages
(https://TOEip/config/) to configure addition network information, monitor settings, and purge logs. When a new
user account is created, it can be assigned one or more privileges. User accounts with no administrative privileges
are called users. Users and Administrators are able to view/modify user account (authentication data) and contact
information.
6.1.5 Protection of Security Functions
FPT_STM.1 Reliable timestamp
The TOE includes a hardware time clock within the appliance which is used to stamp all records generated by the
TOE.
6.2 TOE Security Assurance Measures
The following assurance measures are applied to satisfy the Common Criteria EAL2 assurance requirements:
• Process Assurance;
• Delivery and Guidance;
• Design Documentation;
• Tests; and
• Vulnerability Assessment.
6.2.1 Process Assurance
6.2.1.1 Configuration Management
The configuration management measures applied by Xceedium ensure that the TOE and its configuration items are
uniquely identified. Xceedium uses a CM system that ensures changes to the implementation representation are
controlled and that TOE associated configuration item modifications are properly controlled. Xceedium performs
configuration management on the TOE implementation representation, design, tests, vulnerability, delivery, user and
administrator guidance, and the CM documentation. These activities are documented in:
• Xceedium Configuration Management Plan
The Configuration Management assurance measure satisfies the ACM_CAP.2 assurance requirements
6.2.2 Delivery and Guidance
Xceedium provides delivery documentation that explains how the TOE is delivered and procedures to identify the
TOE. These procedures are documented in:
• Xceedium Product Delivery Process
• Xceedium GateKeeperv3.6.0 Administration Guide v3.6.4, August 2006
• Xceedium GateKeeper v3.6.0 Installation Guide, v3.6.3, August 2006
.
22
Security Target Version 1.0
Xceedium provides administrator guidance in the installation and initialization procedures. The installation and
generation procedures, included in the administrator guidance, describe the steps necessary to install Xceedium
products in accordance with the evaluated configuration, detailing how to establish and maintain the secure
configuration.
The administrator guidance is documented in:
• Xceedium GateKeeperv3.6.0 Administration Guide v3.6.4, August 2006
• Xceedium GateKeeper v3.6.0 Installation Guide, v3.6.3, August 2006
• Xceedium GateKeeper v3.6.0 User’s Guide, v3.6.1, July 12, 2006
The Delivery and Guidance assurance measure satisfies the following Assurance requirements:
• ADO_DEL.1;
• ADO_IGS.1;
• AGD_ADM.1; and,
• AGD_USR.1.
6.2.3 Development
The Design Documentation provided for the TOE is provided in these documents:
• Xceedium GateKeeperv3.6.0 Administration Guide v3.6.4, August 2006
• Xceedium GateKeeper v3.6.0 Installation Guide, v3.6.3, August 2006
• Xceedium GateKeeper v3.6.0 User’s Guide, v3.6.2, August 2006
• Xceedium GateKeeper Implementation
• Xceedium GateKeeper System Design
These documents serve to describe the security functions of the TOE to include a description of the TOE TSF in
terms of subsystems, a functional specification of the user-visible interfaces and behavior, and the TOE external
interfaces. The Design Documentation security assurance measure satisfies the following security assurance
requirement:
• ADV_FSP.1;
• ADV_HLD.1; and,
• ADV_RCR.1.
6.2.4 Tests
The Test Documentation is found in the following documents:
• Test Plan Document For Xceedium GateKeeper Version 3.6 Security Functions
• Test Coverage Document For Xceedium GateKeeper Version 3.6
• Test Procedure Document For Xceedium GateKeeper Version 3.6
These documents describe the overall test plan, testing procedures, the tests themselves, including expected and
actual results. In addition, these documents describe how the functional specification has been appropriately tested.
.
23
Security Target Version 1.0
The Tests assurance measure satisfies the following assurance requirements:
• ATE_COV.1;
• ATE_FUN.1; and,
• ATE_IND.2.
6.2.5 Vulnerability Assessment
Each probabilistic or permutational mechanism used by the TOE must satisfy the SOF-Basic requirements. The only
probabilistic or permutational mechanism used in the TOE is the authentication mechanism (FIA_UAU). Xceedium
has performed a strength of function analysis that indicates that the authentication mechanism fulfills at least SOF-
basic. Similarly, Xceedium performed a vulnerability analysis of the TOE to identify weaknesses that can be
exploited in the TOE. Both the strength of function analysis and the vulnerability analysis are documented in:
• Xceedium GateKeeper Vulnerability Analysis
• Xceedium Strength of Function Analysis
The Vulnerability Assessment assurance measure satisfies the following assurance requirements:
• AVA_SOF.1; and,
• AVA_VLA.1.
.
24
Security Target Version 1.0
7. Protection Profile Claims
There are no PP claims for this evaluation.
.
25
Security Target Version 1.0
8. Rationale
This section provides the rationale for completeness and consistency of the Security Target. The rationale addresses
the following areas:
• Security Objectives;
• Security Functional Requirements;
• Security Assurance Requirements;
• TOE Summary Specification;
• Security Functional Requirement Dependencies; and
• Internal Consistency.
8.1 Security Objectives Rationale
This section shows that all secure usage assumptions, organizational security policies, and threats are completely
covered by security objectives. In addition, each objective counters or addresses at least one assumption or
organizational security policy, or threat.
8.1.1 Security Objectives Rationale for the TOE and Environment
This section provides evidence demonstrating the coverage of organizational policies and usage assumptions by the
security objectives.
O.PROTECT
O.ACCESS
O.AUDIT
O.TIME
O.MANAGE
T.PRIVIL X X
P.MANAGE X X
P.PROTECT X X
P.AUDIT X X
Table 3 Environment to Objective Correspondence
8.1.1.1 T.PRIVIL
An unauthorized user may gain access to the TOE and exploit system privileges to gain access to TOE
security functions and data.
The O.ACCESS objective provides for authentication of users prior to any TOE function access thus preventing
unauthorized access. The O.PROTECT objective addresses this threat by providing TOE self-protection.
8.1.1.2 P.MANAGE
The system must provide authorized administrators with utilities to effectively manage the security
functions of the TOE.
The O.MANAGE security objective supports this policy by ensuring that the TOE provides management functions
for the authorized administrators use. The O.ACCESS security objective support this objective by allowing only
.
26
Security Target Version 1.0
authorized users to access the TOE resources. The O.ACCESS supports this policy by only allowing authorized
users to access only appropriate TOE functions and data as defined by the administrator.
8.1.1.3 P. PROTECT
The TOE shall be protected from unauthorized accesses and disruptions of TOE data and functions.
The O.ACCESS objective supports this policy by requiring authentication prior to all access to any data, only
allowing authenticated and authorized users access to the TOE. The O.PROTECT objective addresses this policy by
providing TOE self-protection.
8.1.1.4 P. AUDIT
Users of the system shall be held accountable for their security relevant actions within the system..
The O.AUDIT objective supports this policy by requiring that all security relevant actions are recorded and can be
reviewed by authorized administrators. The O.TIME objective supports this policy by providing a reliable
timestamp that is used in the audit records.
8.1.1.5 Security Objectives for the Non-IT Environment Rationale
Table 4: Security objectives for the non-IT environment mapped to assumptions identifies security objectives
for the non-IT environment in which the TOE is designed to operate and provides a mapping to assumptions that are
made about that environment.
Security Objectives for the Non-IT
Environment
Assumptions
OE.INSTALL A.MANAGE
OE.PERSON A.NOEVIL
OE.PHYCAL A.LOCATE
Table 4: Security objectives for the non-IT environment mapped to assumptions
OE.INSTALL - Ensuring proper installation, management, and operation of the TOE to protect both itself and its
resources addresses the assumption A.MANAGE.
OE.PERSON - This objective ensures that the TOE is operated in a secure manner by competent, non-hostile,
trained personnel, which addresses A.NOEVIL assumption.
OE.PHYCAL - This objective ensures that the TOE is operated in an environment that will protect it from physical
threats and attacks that can disturb and corrupt the information generated. This objective addresses A.LOCATE.
8.2 Security Requirements Rationale
This section provides evidence supporting the internal consistency and completeness of the components
(requirements) in the Security Target. Note that Table 5 indicates the requirements that effectively satisfy the
individual objectives.
The purpose for the environmental objectives is to provide protection for the TOE that cannot be addressed through
IT measures. The defined objectives provide for physical protection of the TOE, proper management of the TOE,
and interoperability requirements on the TOE. Together with the IT security objectives, these environmental
objectives provide a complete description of the responsibilities of TOE in meeting security needs.
8.2.1 Security Functional Requirements Rationale
All Security Functional Requirements (SFR) identified in this Security Target are fully addressed in this section and
each SFR is mapped to the objective for which it is intended to satisfy.
.
27
Security Target Version 1.0
O.PROTECT
O.ACCESS
O.AUDIT
O.TIME
O.MANAGE
FAU_GEN.1 X
FAU_SAR.1 X
FDP_ACC.1 X
FDP_ACF.1 X
FIA_ATD.1 X
FIA_UAU.2 X
FIA_UAU.7 X
FIA_UID.2 X
FMT_MOF.1 X
FMT_MSA.1a X
FMT_MSA.1b X
FMT_MSA.3 X
FMT_SMF.1 X
FMT_SMR.1 X
FMT_MTD.1a X
FMT_MTD.1b X
FPT_STM.1 X
Table 5 Objective to Requirement Correspondence
8.2.1.1 O.PROTECT
The TOE must protect itself from unauthorized modifications and access to its functions and data.
The TOE is required to identify and authenticate all users prior to any access and does not provide any
authentication data feedback to users. [FIA_UAU.2, FIA_UID.2, FIA_UAU.7] The TOE requires that users be
assigned to roles to determine the level of access granted to the TOE. [FMT_SMR.1].
8.2.1.2 O.ACCESS
The TOE must allow authorized users to access only appropriate TOE functions and data as defined by the
administrator.
The TOE must prevent unauthorized users from accessing the administrative interface. [FDP_ACC.1, FDP_ACF.1].
The TOE requires that all users of the TOE be unique and have unique data. [FIA_ATD.1] O.AUDIT
8.2.1.3 O.AUDIT
The TSF must record the security relevant actions of users of the TOE. The TSF must present this
information in a readable format to authorized administrators and ensure that only authorized users are
able to access this information.
.
28
Security Target Version 1.0
The TOE will record security relevant events that include details about the events themselves in an audit trail that
can be reviewed by authorized administrators. [FAU_GEN.1, FAU_SAR.1]
8.2.1.4 O.TIME
The TOE provides adequate time stamps for audit records.
The TSF shall be able to provide reliable time stamps for its own use [FPT_STM.1.1].
8.2.1.5 O.MANAGE
The TOE must provide services that allow effective management of its functions and data.
The TOE must provide the authorized administrators the ability to manage the user accounts of the TOE as well as
authentication data. [FMT_MTD.1a,b] The TOE places restrictions on access to the management interface. These
restrictions include creating new accounts, modifying security roles and authentication data. [FMT_MOF.1,
FMT_MSA.1a, FMT_MSA.1b,, FMT_SMF.1] The TOE ensures restrictive default settings for new user accounts.
[FMT_MSA.3].
8.3 Security Assurance Requirements Rationale
This ST contains the assurance requirements from the CC EAL2 assurance package and is based on good
commercial development practices. This ST has been developed for a generalized environment with a low level of
risk to the assets. The security environment assumes physical protection and the TOE itself offers only a very
limited interface and can only be configured during initialization, offering essentially no opportunity for an attacker
to subvert the security policies without physical access. As such, it is believed that EAL 2 provides an appropriate
level of assurance in the security functions offered by the TOE and that SOF-basic is appropriate for an EAL2 TOE.
8.4 Requirement Dependency Rationale
The ST satisfies all the requirement dependencies of the Common Criteria, except as noted below. Table 6
Requirement Dependency Rationale lists each requirement from Section 5.1 with a dependency and indicates which
requirement was included to satisfy the dependency, if any. For each dependency not included, a justification is
proved.
Functional Component Dependency Included
FAU_GEN.1 FPT_STM.1 YES
FAU_SAR.1 FAU_GEN.1 YES
FDP_ACC.1 FDP_ACF.1 YES
FDP_ACF.1 FDP_ACC.1 YES
FIA_UAU.2 FIA_UID.2 YES (FIA_UID.2)
FIA_UAU.7 FIA_UAU.1 YES (FIA_UAU.2)
FMT_SMF.1 YES
FMT_MOF.1
FMT_SMR.1 Yes
FDP_ACC.1 or
FDP_IFC.1
YES (FDP_ACC.1)
FMT_SMR.1 Yes
FMT_MSA.1
FMT_SMF.1
Yes
FMT_MSA.1 YES
FMT_MSA.3
FMT_SMR.1 YES
.
29
Security Target Version 1.0
Functional Component Dependency Included
FMT_SMF.1 None
FMT_SMR.1 FIA_UID.1 YES (FIA_UID.2)
FMT_SMF.1 YES
FMT_MTD.1
FMT_SMR.1 YES
FPT_STM.1 None
Table 6 Requirement Dependency Rationales
8.5 Explicitly Stated Requirements Rationale
There are no explicitly stated requirements.
8.6 TOE Summary Specification Rationale
Each subsection in Section 6, the TOE Summary Specification, describes a security function of the TOE. Each
description is followed with rationale that indicates which requirements are satisfied by aspects of the corresponding
security function. The set of security functions work together to satisfy all of the security functions and assurance
requirements. Furthermore, all of the security functions are necessary in order for the TSF to provide the required
security functionality.
This Section in conjunction with Section 6, the TOE Summary Specification, provides evidence that the security
functions are suitable to meet the TOE security requirements. The collection of security functions work together to
provide all of the security requirements. . Table 7 Security Functions vs. Requirements Mapping demonstrates
the relationship between security requirements and security functions.
AUDITING
ACCESS
CONTROL
IDENTIFICATION
AND
AUTHENTICATION
SECURITY
MANAGEMENT
SELF
PROTECTION
FAU_GEN.1 X
FAU_SAR.1 X
FDP_ACC.1 X
FDP_ACF.1 X
FIA_ATD.1 X
FIA_UAU.2 X
FIA_UAU.7 X
FIA_UID.2 X
FMT_MOF.1 X
FMT_MSA.1a X
FMT_MSA.1b X
FMT_MSA.3 X
FMT_SMF.1 X
FMT_SMR.1 X
.
30
Security Target Version 1.0
AUDITING
ACCESS
CONTROL
IDENTIFICATION
AND
AUTHENTICATION
SECURITY
MANAGEMENT
SELF
PROTECTION
FMT_MTD.1a X
FMT_MTD.1b X
FPT_STM.1 X
Table 7 Security Functions vs. Requirements Mapping
8.7 PP Claims Rationale
See section 7, Protection Profile Claims.
.
31