Hewlett Packard Enterprise Development LP Operations Orchestration v10.20 Security Target Evaluation Assurance Level (EAL): EAL2+ Document Version: 0.14 Prepared for: Prepared by: Hewlett Packard Enterprise Development LP Corsec Security, Inc. 3000 Hanover Street Palo Alto, CA 94304 United States of America 13135 Lee Jackson Memorial Hwy, Suite 220 Fairfax, VA 22033 United States of America Phone: +1 (305) 267–4220 Phone: +1 (703) 267–6050 Email: info@hpe.com Email: [email protected]http://www.hpe.com http://www.corsec.com
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
1.3.1 HP OO Product Specification.............................................................................................................................. 5
1.4 TOE OVERVIEW ................................................................................................................................................... 7
1.4.1 TOE Environment ................................................................................................................................................... 7
1.4.2 TOE Evaluated Configuration ............................................................................................................................. 9
1.5 TOE DESCRIPTION .............................................................................................................................................. 9
4.1 SECURITY OBJECTIVES FOR THE TOE .............................................................................................................. 16 4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT .................................................................. 16
4.2.1 IT Security Objectives ......................................................................................................................................... 16
6.2.2 Class FCS: Cryptographic Support ................................................................................................................. 22
6.2.3 Class FDP: User Data Protection .................................................................................................................... 24
6.2.4 Class FIA: Identification and Authentication................................................................................................ 25
6.2.5 Class FMT: Security Management ................................................................................................................. 27
6.2.6 Class FPT: Protection of the TSF ..................................................................................................................... 29
6.2.7 Class FTA: TOE Access ...................................................................................................................................... 30
6.2.8 Class FTP: Trusted Path/Channels ................................................................................................................. 31
7.1.2 Cryptographic Support ....................................................................................................................................... 37
7.1.3 User Data Protection .......................................................................................................................................... 37
7.1.4 Identification and Authentication.................................................................................................................... 38
7.1.6 Protection of the TSF .......................................................................................................................................... 40
7.1.7 TOE Access ............................................................................................................................................................ 40
8.2.2 Security Objectives Rationale Relating to Policies ..................................................................................... 44
8.2.3 Security Objectives Rationale Relating to Assumptions ........................................................................... 44
8.3 SECURITY REQUIREMENTS RATIONALE ........................................................................................................... 45 8.3.1 Rationale for Security Functional Requirements of the TOE Objectives ............................................ 45
Table of Figures FIGURE 1 OPERATIONS ORCHESTRATION V10.20 TOE BOUNDARY ........................................................................... 10
List of Tables TABLE 1 ST AND TOE REFERENCES ...................................................................................................................................... 4
TABLE 2 TOE REQUIREMENTS ................................................................................................................................................ 8
TABLE 3 CC AND PP CONFORMANCE .............................................................................................................................. 13
TABLE 4 THREATS ................................................................................................................................................................. 14 TABLE 5 ASSUMPTIONS ......................................................................................................................................................... 15 TABLE 6 SECURITY OBJECTIVES FOR THE TOE.................................................................................................................. 16 TABLE 7 IT SECURITY OBJECTIVES ...................................................................................................................................... 16
mechanism which enables dynamic execution of flow steps amongst distributed RASes. Workers may
belong to multiple groups simultaneously. In addition, multiple OO RASes may be deployed in a highly-
available configuration by simply adding another RAS and pointing it to the main OO Central instance.
1.3.1.4 OO Content
OO Content refers collectively to the flows, integrations, operations, and process automation libraries in HP
OO. HP OO provides over 5,000 out-of-the-box operations, flows, and integration adapters delivered as a
set of granular content packs. These packs can be used to author complex flows and orchestrate various
services. Additional custom content can be generated by OO users using wizards such as the Web Service
Wizard or developed using the Java and .NET SDKs. HP OO offers content in the areas of cloud
orchestration, security operations, disaster recovery, monitoring, service management, applications, and
security products.
1.4 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 TOE, and defining
the specific evaluated configuration.
The TOE is a software-based ITPA and IT runbook solution for creating and implementing structured and
automated flows over enterprise network, storage, and server deployments. For this evaluation of HP
Operations Orchestration v10.20, the ST will focus on the major software components which work together
to create, deploy, implement, and manage enterprise-scale workflow capabilities. The components of the
HP OO solution which provide the largest impact on the implementation, management, and monitoring of
HP OO are considered for the TOE boundary. In addition to the OO components, the TOE boundary also
includes the Java runtime components necessary for the secure and continuous operation of HP Operations
Orchestration v10.20. The TOE is comprised of the following components:
• Software components: o Operations Orchestration Central – Central component of HP Operations Orchestration
deployment
o Operations Orchestration RAS – Flow execution external to the OO Central
implementation
o RSA BSAFE Crypto-J JSAFE and JCE Software Module v6.1 – FIPS 140-2 Certified
cryptographic library (FIPS Cert # 2057)
o Apache Tomcat Server (Tomcat) – Java-based web server and servlet container providing
a “pure java” web server environment
• Hardware components:
o No hardware components are included as part of the TOE evaluation
1.4.1 TOE Environment HP Operations Orchestration components are installed on a 64-bit Windows Server 2012 R2 Operating
System (OS). Users of OO can access OO Central with a supported web browser12 listed in Table 2.
Access to an external LDAP server and external SAML13 2.0 Identity Provider (IdP) is required by OO
Central in order to provide access to externally authenticated TOE users.
The TOE does not support direct-connect access and requires TOE users to connect to it remotely.
Connections to the TOE by a web browser are secured with an encrypted HTTPS14 connection. The web
browser should be installed on a General Purpose Computer (GPC) workstation that can provide an
uninterrupted network connection.
12 Windows Internet Explorer 10.0 was used for testing the TOE 13 SAML – Security Assertion Markup Language 14 HTTPS – Secure Hyper–Text Transmission Protocol
2 Conformance Claims This section and Table 3 provide 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 3 CC and PP Conformance
Common Criteria (CC) Identification and Conformance
Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, September 2012; CC Part 2 conformant; CC Part 3 conformant; PP claim (none); Parts 2 and 3 Interpretations of the CEM22 as of October 2, 2014 were reviewed, and no interpretations apply to the claims made in this ST.
3 Security Problem 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 to the IT assets against which protection is required by the TOE or by the
security environment. The threat agents are divided into two categories:
• Attackers who are not TOE users: They have public knowledge of how the TOE operates and are
assumed to possess a low skill level, limited resources to alter TOE configuration settings or
parameters and no physical access to the TOE.
• TOE users: They have extensive knowledge of how the TOE operates and are assumed to possess
a high skill level, moderate resources to alter TOE configuration settings or parameters and
physical access to the TOE. (TOE users are, however, assumed not to be willfully hostile to the
TOE.)
Both are assumed to have a low level of motivation. The IT assets requiring protection are the TSF23 and
user data saved on or transitioning through the TOE and the hosts on the protected network. Removal,
diminution and mitigation of the threats are through the objectives identified in Section 4 Security
Objectives. Table 4 below lists the applicable threats.
Table 4 Threats
Name Description
T.MASQUERADE A user or process may masquerade as another entity in order to gain unauthorized access to data or TOE resources.
T.TAMPERING A user or process may be able to bypass the TOE’s security mechanisms by tampering with the TOE or TOE environment.
T.UNAUTH A user may gain access to security data on the TOE, even though the user is not authorized in accordance with the TOE security policy.
T.DATA_COMPROMISE An unauthorized user may read, modify, delay, or destroy security critical TOE data stored on the TOE or being transmitted between physically separated parts of the TOE.
T.ADMIN_ERROR An administrator may incorrectly configure the TOE resulting in ineffective security mechanisms.
T.EXTERNAL_COMPROMISE A malicious user or process may modify the audit data or LDAP data stored in the TOE environment
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 listed in Table 6 below.
Table 6 Security Objectives for the TOE
Name Description
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, may exercise such control.
O.AUDIT The TOE will provide the capability to detect security relevant events, record them to the audit trail, and identify the user which caused the event.
O.AUTHENTICATE The TOE must be able to identify and authenticate users prior to allowing access to TOE administrative functions and data.
O.CRYPTO The TOE will provide FIPS-Approved cryptographic algorithms and procedures to TOE users during operation of the TOE.
O.PROTECT The TOE must ensure the integrity of audit and system data by protecting itself from unauthorized modifications and access to its functions and data.
O.PROTECT_COMM The TOE will provide protected communication channels for administrators, other parts of a distributed TOE, and authorized IT entities.
4.2 Security Objectives for the Operational Environment
This section describes the environmental objectives.
4.2.1 IT Security Objectives Table 7 below lists the IT security objectives that are to be satisfied by the environment.
Table 7 IT Security Objectives
Name Description
OE.TIME The TOE environment must provide reliable timestamps to the TOE.
OE.ENVIRONMENT The TOE environment must provide a compatible Windows or Linux Operating System for the installation of TOE components
OE.TRAFFIC The TOE environment must be implemented such that the distributed TOE components are appropriately located within the same network.
OE.NETWORK The TOE environment must provide a consistent network connection to the TOE.
OE.TRUSTED_ADMIN Trusted TOE Administrators must follow and apply all administrator and configuration guidance.
OE.ACCESS The TOE Environment must prevent unauthorized users from accessing data and resources
4.2.2 Non-IT Security Objectives Table 8 below lists the non-IT environment security objectives that 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.MANAGE Sites deploying the TOE will provide competent, non-hostile TOE administrators who are appropriately trained and follow all administrator guidance. TOE administrators will ensure the system is used securely.
NOE.PHYSICAL The physical environment must be suitable for supporting a computing device in a secure setting.
NOE.COMPATIBLE The TOE environment must provide compatible applications for TOE users.
8.1 Conformance Claims Rationale This Security Target conforms to Part 2 and Part 3 of the Common Criteria for Information Technology
Security Evaluation, Version 3.1 Release 4.
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, policies, and assumptions to the security objectives are 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 18 below provides a mapping of the objects to the threats they counter.
Table 18 Threats: Objectives Mapping
Threats Objectives Rationale
T.MASQUERADE A user or process may masquerade as another entity in order to gain unauthorized access to data or TOE resources.
O.AUTHENTICATE The TOE must be able to identify and authenticate users prior to allowing access to TOE administrative functions and data.
O.AUTHENTICATE satisfies this threat by ensuring that The TOE is able to identify and authenticate users prior to allowing access to TOE administrative functions and data.
O.PROTECT The TOE must ensure the integrity of audit and system data by protecting itself from unauthorized modifications and access to its functions and data.
O.PROTECT satisfies this threat by placing access control policies on TOE data and by presenting a warning banner to users about unauthorized use of the TOE prior to logging in.
T.TAMPERING A user or process may be able to bypass the TOE’s security mechanisms by tampering with the TOE or TOE environment.
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, may exercise such control.
O.ADMIN supports the mitigation of this threat by ensuring that only authorized users may configure the TOE security mechanisms.
O.AUDIT The TOE will provide the capability to detect security relevant events, record them to the audit trail, and identify the user which caused the event.
O.AUDIT satisfies the threat by ensuring that security relevant events that may indicate attempts to tamper with the TOE are recorded.
O.PROTECT The TOE must ensure the integrity of audit and system data by protecting itself from unauthorized modifications and access to its functions and data.
O.PROTECT mitigates this threat by providing mechanisms to protect the TOE data from unauthorized modification.
T.UNAUTH A user may gain access to security data on the TOE, even though the user is not authorized in accordance with the TOE security policy.
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, may exercise such control.
O.ADMIN ensures that access to TOE security data is limited to those users with access to the management functions of the TOE.
O.AUDIT The TOE will provide the capability to detect security relevant events, record them to the audit trail, and identify the user which caused the event.
O.AUDIT ensures that unauthorized attempts to access the TOE are recorded.
O.AUTHENTICATE The TOE must be able to identify and authenticate users prior to allowing access to TOE administrative functions and data.
O.AUTHENTICATE ensures that users are identified and authenticated prior to gaining access to TOE security data.
O.PROTECT The TOE must ensure the integrity of audit and system data by protecting itself from unauthorized modifications and access to its functions and data.
O.PROTECT prevents unauthorized access and modification to security data by enforcing an access control policy.
T.DATA_COMPROMISE An unauthorized user may read, modify, delay, or destroy security critical TOE data stored on the TOE or being transmitted between physically separated parts of the TOE.
O.CRYPTO The TOE will provide FIPS-Approved cryptographic algorithms and procedures to TOE users during operation of the TOE.
O.CRYPTO counters this threat by providing encryption services available to authorized users and/or user applications.
O.PROTECT_COMM The TOE will provide protected communication channels for administrators, other parts of a distributed TOE, and authorized IT entities.
O.PROTECT_COMM counters this threat by providing protected communication channels for administrators, other parts of a distributed TOE, and authorized IT entities.
T.ADMIN_ERROR An administrator may incorrectly configure the TOE resulting in ineffective security mechanisms.
OE.TRUSTED_ADMIN Trusted TOE Administrators must follow and apply all administrator and configuration guidance.
OE.TRUSTED_ADMIN counters this threat by ensuring that administrators follow all administrative guidance.
T.EXTERNAL_COMPROMISE A malicious user or process may modify the audit data or LDAP data stored in the TOE environment
OE.ACCESS The TOE Environment must prevent unauthorized users from accessing data and resources
OE.ACCESS prevents unauthorized access and modification to security data stored in the TOE environment
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 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.
8.2.3 Security Objectives Rationale Relating to Assumptions Table 19 below gives a mapping of assumptions and the environmental objectives that uphold them.
Table 19 Assumptions: Objectives Mapping
Assumptions Objectives Rationale
A.INSTALL The TOE is installed on the appropriate operating system and runtime environment
OE.ENVIRONMENT The TOE environment must provide a compatible Windows or Linux Operating System for the installation of TOE components
OE.ENVIRONMENT satisfies the assumption by ensuring compatible operating systems and Java Runtime Environment is installed prior to the installation of the TOE
OE.TRUSTED_ADMIN Trusted TOE Administrators must follow and apply all administrator and configuration guidance.
OE.TRUTED_ADMIN satisfies this assumption by ensuring TOE Administrators follow and apply all configuration guidance.
A.NETCON The TOE environment provides the network connectivity required to allow the TOE to provide secure routing and switching functions.
OE.TRAFFIC The TOE environment must be implemented such that the distributed TOE components are appropriately located within the same network.
OE.TRAFFIC satisfies the assumption by ensuring the distributed portions of the TOE are implemented within the same network.
OE.NETWORK The TOE environment must provide a consistent network connection to the TOE.
OE.NETWORK satisfies the assumption by ensuring the TOE environment will provide the appropriate connectivity to allow the TOE to perform its function.
A.TIMESTAMP The IT environment provides the TOE with the necessary reliable timestamps.
OE.TIME The TOE environment must provide reliable timestamps to the TOE.
OE.TIME satisfies the assumption that the environment provides reliable timestamps to the TOE.
A.LOCATE The TOE and its environmental components are located within a controlled access facility.
NOE.PHYSICAL The physical environment must be suitable for supporting a computing device in a secure setting.
NOE.PHYSICAL satisfies this assumption by ensuring physical security is provided within the TOE environment to provide appropriate protection to the network resources and to prevent manipulation of data across the network.
A.NOEVIL The users who manage the TOE are non-hostile, appropriately trained, and follow all guidance.
NOE.MANAGE Sites deploying the TOE will provide competent, non-hostile TOE administrators who are appropriately trained and follow all administrator guidance. TOE administrators will ensure the system is used securely.
NOE.MANAGE satisfies the assumption that the users who manage the TOE are non-hostile, appropriately trained and follow all guidance.
A.APPLICATIONS TOE users will use compatible applications in order access the TOE
NOE.COMPATIBLE The TOE environment must provide compatible applications for TOE users.
NOE.COMPATIBLE satisfies the assumption by ensuring that compatible software applications are installed onto the TOE environment for use by TOE users.
A.ENVIRONMENT_ACCESS The users who manage the TOE environment are authorized to access the TOE environment
OE.ACCESS The TOE Environment must prevent unauthorized users from accessing data and resources
OE.ACCESS satisfies the assumption by ensuring that only authorized user are able to access the TOE environment
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 Security Requirements Rationale The following discussion provides detailed evidence of coverage for each security objective.
8.3.1 Rationale for Security Functional Requirements of the TOE Objectives
Table 20 below shows a mapping of the objectives and the SFRs that support them.
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, may exercise such control.
FMT_MOF.1 Management of security functions behaviour
The requirement meets the objective by ensuring that the TOE restricts administrative functions to only those users with the appropriate privileges.
FMT_MSA.1 Management of security attributes
The requirement meets the objective by restricting the ability to perform actions on security attributes to specific users.
FMT_MSA.3 Static attribute initialisation
The requirement meets the objective by providing authorized users the ability to change default security attribute values.
FMT_MTD.1(a) Management of TSF data
The requirement meets the objective by ensuring that the TOE restricts access to TSF data based on the user's role.
FMT_MTD.1(b) Management of TSF data
The requirement meets the objective by ensuring that the TOE restricts access to TSF data based on the user's role.
FMT_SMF.1 Specification of management functions
The requirement meets the objective by ensuring that the TOE includes administrative functions to facilitate the management of the TSF.
FMT_SMR.1 Security roles
The requirement meets the objective by ensuring that the TOE associates users with roles to provide access to TSF management functions and data.
O.AUDIT The TOE will provide the capability to detect security relevant events, record them to the audit trail, and identify the user which caused the event.
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_GEN.2 User Identity Association
The requirement meets this objective by ensuring that the TOE associates each auditable event with an identified TOE user which caused the event.
O.AUTHENTICATE The TOE must be able to identify and authenticate users prior to allowing access to TOE administrative functions and data.
FIA_ATD.1(a) User attribute definition
The requirement meets the objective by associating a username and password to each TOE user
FIA_ATD.1(b) User attribute definition
The requirement meets the objective by associating a username and password to each TOE user
FIA_UAU.2 User authentication before any action
The requirement meets the objective by ensuring that users are authenticated before access to TOE administrative functions is allowed.
FIA_UAU.5 Multiple authentication mechanisms
The requirement meets the objective by providing multiple means of authentication prior to accessing the TOE
FIA_UID.2 User identification before any action
The requirement meets the objective by ensuring that the users are identified before access to TOE administrative functions is allowed.
FMT_MOF.1 Management of security functions behaviour
The requirement meets the objective by ensuring that the TOE authenticates users prior to allowing access to administrative functions to ensure that only those trusted users may manage the security behaviour of the TOE.
FMT_MSA.1 Management of security attributes
The requirement meets the objective by ensuring that the TOE authenticates users prior to allowing access to security attributes to ensure that only those trusted users may manage the security attributes.
FMT_MTD.1(a) Management of TSF data
The requirement meets the objective by ensuring that only authorized users are allowed access to TSF data.
FMT_MTD.1(b) Management of TSF data
The requirement meets the objective by ensuring that only authorized users are allowed access to TSF data.
O.CRYPTO The TOE will provide FIPS-Approved cryptographic algorithms and procedures to TOE users during operation of the TOE.
FCS_CKM.1 Cryptographic key generation
The requirement meets the objective by ensuring that the TOE can generate FIPS-Approved cryptographic keys for use during cryptographic operations.
FCS_CKM.4 Cryptographic key destruction
The requirement meets the objective by ensuring that the TOE destroys cryptographic keys when no longer in use using FIPS-Approved methods
FCS_COP.1 Cryptographic operation
The requirement meets the objective by ensuring that the TOE provides FIPS-Approved confidentiality and integrity services for the TOE.
O.PROTECT The TOE must ensure the integrity of audit and system data by protecting itself from unauthorized modifications and access to its functions and data.
FDP_ACC.2 Complete access control
The requirement meets the objective by enforcing the Central Access Control Policy on all subjects and all named objects and all operations among them. The policy specifies the access rules between all subjects and all named objects controlled by the TOE. While authorized users are trusted to some extent, this requirement ensures only authorized access is allowed to named objects.
FDP_ACF.1 Security attribute based access control
The requirement meets the objective by ensuring that the TOE enforces access control based on the Central Access Control Policy.
FIA_UAU.2 User authentication before any action
The requirement meets the objective by ensuring that the TOE protects itself from unauthorized modification. The TOE does this by ensuring that only authenticated users are allowed access to TOE functions.
FIA_UAU.7 Protected authentication feedback
The requirement meets the objective by preventing password material from being obtained from an unauthorized person, thus protecting from unauthorized access.
The requirement meets the objective by ensuring that the TOE protects itself from unauthorized modification. The TOE does this by ensuring that only identified users are allowed access to TOE functions.
FMT_MOF.1 Management of security functions behaviour
The requirement meets the objective by ensuring that the TOE protects itself from unauthorized modification. The TOE does this by ensuring that only privileged users may manage the security behaviour of the TOE.
FMT_MSA.1 Management of security attributes
The requirement meets the objective by ensuring that the TOE protects itself from unauthorized modification. The TOE does this by ensuring that only authorized users have access to security attributes.
FMT_MSA.3 Static attribute initialisation
The requirement meets the objective by enforcing restrictive default values for security attributes, thus preventing unauthorized access or modification of TSF data
FMT_MTD.1(a) Management of TSF data
The requirement meets the objective by ensuring that the TOE protects itself from unauthorized modification. The TOE does this by ensuring that only authorized users have access to TSF data.
FMT_MTD.1(b) Management of TSF data
The requirement meets the objective by ensuring that the TOE protects itself from unauthorized modification. The TOE does this by ensuring that only authorized users have access to TSF data.
FTA_SSL.3 TSF-initiated Termination
The requirement meets the objective by terminating inactive and unattended sessions and ensuring unauthorized users cannot access the session
The requirement meets the objective by presenting an advisory access banner to user prior to authentication. This prevents unauthorized use of the TOE.
O.PROTECT_COMM The TOE will provide protected communication channels for administrators, other parts of a distributed TOE, and authorized IT entities.
FPT_ITT.1 Basic internal TSF data transfer protection
The requirement meets the objective by protecting data being transferred between TOE components from disclosure and modification.
FTP_ITC.1 Inter-TSF trusted channel
The requirement meets the objective by providing a secure and trusted communications channel between all trusted IT products and the TOE.
FTP_TRP.1 Trusted path
The requirement meets the objective by providing a secure communications path to all users accessing the TOE remotely.
8.3.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
System may monitor a hostile environment, it 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.2 was chosen to give greater assurance of the
developer’s on-going flaw remediation processes.
8.3.3 Dependency Rationale The SFRs in this ST satisfy all of the required dependencies listed in the Common Criteria, applicable PPs,
and SFRs explicitly stated in this ST. Table 21 lists each requirement to which the TOE claims
conformance and indicates whether the dependent requirements are included. As the table indicates, all
FAU_GEN.1 FPT_STM.1 FPT_STM.1 is not included because time stamps are provided by the environment. An environmental objective states that the TOE will receive reliable timestamps.
FAU_GEN.2 FAU_GEN.1 �
FIA_UID.1 � Although FIA_UID.1 is not included, FIA_UID.2, which is hierarchical to FIA_UID.1, is included. This satisfies this dependency.
FCS_CKM.1 FCS_CKM.4 �
FCS_COP.1 �
FCS_CKM.4 FCS_CKM.1 �
FCS_COP.1 FCS_CKM.1 �
FCS_CKM.4 �
FDP_ACC.2 FDP_ACF.1 �
FDP_ACF.1 FMT_MSA.3 �
FDP_ACC.1 �
FIA_ATD.1(a) No dependencies �
FIA_ATD.1(b) No dependencies �
FIA_UAU.2 FIA_UID.1 � Although FIA_UID.1 is not included, FIA_UID.2, which is hierarchical to FIA_UID.1, is included. This satisfies this dependency.
FIA_UAU.5 No dependencies �
FIA_UAU.7 FIA_UAU.1 � Although FIA_UAU.1 is not included, FIA_UAU.2, which is hierarchical to FIA_UAU.1, is included. This satisfies this dependency