Security Target: Concepteers Teleconsole Family Version 2.0 Concepteers Security Target Concepteers Teleconsole™ Family Version 2.0 Document Version 1.2 June 22, 2011 Document Version 1.2 © Concepteers Page 1 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 Prepared For: Concepteers Concepteers, LLC 121 Newark Ave, Suite 204 Jersey City, NJ 07302 www.concepteers.com Abstract Prepared By: APEXASSURANCE GROUP Apex Assurance Group, LLC 530 Lytton Avenue, Ste. 200 Palo Alto, CA 94301 www.apexassurance.com This document provides the basis for an evaluation of a specific Target of Evaluation (TOE), the Teleconsole Family Version 2.0. This Security Target (ST) defines a set of assumptions about the aspects of the environment, a list of threats that the product intends to counter, a set of security objectives, a set of security requirements and the IT security functions provided by the TOE which meet the set of requirements. Document Version 1.2 © Concepteers Page 2 0f42 Security Target: Concepteers Teleconsole Family Version 2.0 Table of Contents 1 Introduction .. 1.1 ST Reference. 1.2 TOE Reference. 1.3 Document Organization... 1.4 Document Conventions 1.5 Document Terminology 1.6 TOE Overview.. 1.7 TOE Description... 1.7.1 Physical Boundary .. 1.7.2 Logical Boundary 2 Conformance Claims... 2.1 CC Conformance Claim. 2.2 PP Claim... 2.3 Package Claim. 2.4 Conformance Rationale... 3 Security Problem Definition 3.1 Threats ... 3.2 Organizational Security Policies 3.3 Assumptions .... 4 Security Objectives. un 4.1 Security Objectives for the TOE .. 4.2 Security Objectives for the Operational Environment... 4.3 Security Objectives Rationale... 5 Extended Components Definition 5.1 Definition of Extended Components... 6 Security Requirements .. 6.1 Security Functional Requirements 6.1.1 Security Audit (FAU) 6.12 Cryptographic Support (FCS). 6.1.3 Information Flow Control (FDP) 6.14 Identification and Authentication (FIA) .... 6.2 Security Management (FMT).. 6.2.2 Protection of the TSF (FPT) 6.2.3 Trusted Path/Channels (FTP) 6.3 Security Functional Requirements for the IT Environment ... 6.4 CC Component Hierarchies and Dependencies.. 6.5 Security Assurance Requirements .... 6.6 Security Requirements Rationale... 6.6.1 Security Functional Requirements... 6.6.2 Sufficiency of Security Requirements Document Version 1.2 © Concepteers Page 3 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 6.6.3 Security Assurance Requirements ... 6.6.4 Security Assurance Requirements Rationale .... 6.6.5 Security Assurance Requirements Evidence 7 TOE Summary Speci 71 7.2 7.3 7.4 7.5 7.6 7.7 tion ..... TOE Security Functions... Security Audit . Cryptographic Support User Data Protection Identification and Authenticatio! Security Management . Protection of the TSF... Document Version 1.2 © Concepteers Page 4 0f42 Security Target: Concepteers Teleconsole Family Version 2.0 List of Tables Table 1 — ST Organization and Section Descriptions ... 6 Table 2 — Acronyms Used in Security Target .8 Table 3 — Evaluated Configuration for the TOE ..... 8 Table 4 - Logical Boundary Descriptions... Table 5 — Threats Addressed by the TOE..... Table 6 — Assumptions... Table 7 — TOE Security Objectives Table 8 — Operational Environment Security Objectives Table 9 — Mapping of Assumptions, Threats, and OSPs to Security Objectives .... Table 10 - Mapping of Objectives to Threats... Table 11 - Mapping of Threats, Policies, and Assumptions to Objectives Table 12 — TOE Security Functional Requirements... Table 13 - Auditable Events .... Table 14 — Cryptographic Operations.... Table 15 - Management of TSF data. Table 16 - TOE SFR Dependency Rationale.... Table 17 - Mapping of TOE Security Functional Requirements and Objectives.... Table 18 - Rationale for TOE SFRs to Objectives Table 19 - Rationale for TOE Objectives to SFRs Table 20 - Security Assurance Requirements at EAL3 ... Table 21 - Security Assurance Rationale and Measures List of Figures Figure 1- TOE Boundary.. Document Version 1.2 © Concepteers Page 5 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 1 Introduction This section identifies the Security Target (ST), Target of Evaluation (TOE), Security Target organization, document conventions, and terminology. It 1.1 ST Reference also includes an overview of the evaluated product. ST Title Security Target: Concepteers Teleconsole Family Version 2.0 ST Revision 1.2 ST Publication Date June 22, 2011 Author Apex Assurance Group 1.2 TOE Reference TOE Reference Concepteers Teleconsole Family Version 2.0 Build 1407 1.3 Document Organization This Security Target follows the following format: SECTION | TITLE DESCRIPTION 1 Introduction Provides an overview of the TOE and defines the hardware and software that make up the TOE as well as the physical and logical boundaries of the TOE 2 Conformance Claims Lists evaluation conformance to Common Criteria versions, Protection Profiles, or Packages where applicable 3 Security Problem Definition Specifies the threats, assumptions and organizational security policies that affect the TOE 4 Security Objectives Defines the security objectives for the TOE/operational environment and provides a rationale to demonstrate that the security objectives satisfy the threats 5 Extended Components Describes extended components of the evaluation (if any) Definition 6 Security Requirements Contains the functional and assurance requirements for this TOE 7 TOE Summary Specification Identifies the IT security functions provided by the TOE and also identifies the assurance measures targeted to meet the assurance requirements. Table 1 — ST Organization and Section Descriptions Document Version 1.2 © Concepteers Page 6 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 1.4 Document Conventions The notation, formatting, and conventions used in this Security Target are consistent with those used in Version 3.1 of the Common Criteria. Selected presentation choices are discussed here to aid the Security Target reader. The Common Criteria allows several operations to be performed on functional requirements: The allowable operations defined in Part 2 of the Common Criteria are refinement, selection, assignment and iteration. The assignment operation is used to assign a specific value to an unspecified parameter, such as the length of a password. An assignment operation is indicated by showing the value in square brackets, i.e. [assignment_value(s)]. The refinement operation is used to add detail to a requirement, and thus further restricts a requirement. Refinement of security requirements is denoted by bold text. Any text removed is indicated with a strikethrough format (Example: TSF). The selection operation is picking one or more items from a list in order to narrow the scope of a component element. Selections are denoted by italicized text. Iterated functional and assurance requirements are given unique identifiers by appending to the base requirement identifier from the Common Criteria an iteration number inside parenthesis, for example, FMT_MTD.1.1 (1) and FMT_MTD.1.1 (2) refer to separate instances of the FMT_MTD.1 security functional requirement component. When not embedded in a Security Functional Requirement, italicized text is used for both official document titles and text meant to be emphasized more than plain text. 1.5 Document Terminology The following table describes the acronyms used in this document: TERM DEFINITION AES Advanced Encryption Standard ANSI American National Standards Institute CAVP Cryptographic Algorithm Validation Program cc Common Criteria version 3.1 EAL Evaluation Assurance Level FIPS Federal Information Processing Standard NTP Network Time Protocol OSP Organizational Security Policy RFC Request for Comment RSA Rivest Shamir Adelman SA Security Association SFP Security Function Policy SFR Security Functional Requirement Document Version 1.2 © Concepteers Page 7 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 SSH Secure Shell SSL Secure Sockets Layer ST Security Target TDES Triple Data Encryption Standard TOE Target of Evaluation TLS Transport Layer Security TSF TOE Security Function VPN Virtual Private Network Table 2 - Acronyms Used in Security Target 1.6 TOE Overview The TOE is Concepteers Teleconsole Family Version 2.0. The TOE provides secure remote access to internal equipment and network resources. The TOE acts as a secure application-layer gateway that intermediates all requests between remote computers and internal resources. All requests from remote computers to the TOE and from the TOE to remote computers are encrypted using SSL/HTTPS encryption. All unencrypted requests (e.g. HTTP) are redirected to HTTPS, which ensures the connection is encrypted. Users gain authenticated access to authorized resources via an extranet session hosted by the TOE. Each request is subject to administratively defined access control and authorization policies before the request is forwarded to an internal resource. 1.7 TOE Description 1.7.1 Physical Boundary The TOE is a software TOE and is defined as the Teleconsole Family Version 2.0. In order to comply with the evaluated configuration, the following components must be used: COMPONENT VERSION/MODEL NUMBER Software Version 2.0 Build 1407, which includes FIPS 140-2 Level 2 validated firmware (certificate number in process) Hardware (IT Environment) Teleconsole TCS6U4W, Teleconsole E Table 3 - Evaluated Configuration for the TOE The TOE interfaces are comprised of the following: 1. Network interfaces which pass traffic 2. Management interface through which handle administrative actions. The TOE boundary is shown below: Document Version 1.2 © Concepteers Page 8 0f42 Security Target: Concepteers Teleconsole Family Version 2.0 Appliance TC Operating System Berner x == DT ! = Protected _Connection via Intranet EN nur System Management Platform î = Internal Interface ; = External Interface | = TOE Component = IT Environment Component Figure 1- TOE Boundary 1.7.2 Logical Boundary This section outlines the boundaries of the security functionality of the TOE; the logical boundary of the TOE includes the security functionality described in the following sections. TSF Security Audit DESCRIPTION The TOE generates audit records for security events. The administrator and read-only administrator are the only roles with access to the audit trail and have the ability to view the audit trail. Cryptographic Support The TOE supports secure communications between users and the TOE. This encrypted traffic prevents modification and disclosure of user information. Cryptographic operations are provided by a FIPS 140-2 Level 2 validated cryptographic hardware/firmware module. While the appliance hardware is in the IT Environment, the firmware providing cryptographic operations is part of the TOE. User Data Protection The TOE provides an information flow security policy. The security policy limits traffic to resource types to specific user roles. Identification and Authentication All users are required to perform identification and authentication before any information flows are permitted. Additionally, administrators must be authenticated before performing any administrative functions. Document Version 1.2 © Concepteers Page 9 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 TSF DESCRIPTION Security Management | The TOE provides a wide range of security management functions. Administrators can configure the TOE, manage users, the information flow policy, and audit among other routine maintenance activities. Protection of the TSF The TOE provides a secure connection between users and peer devices. Traffic is protected from disclosure and modification. Audit data is timestamped. Table 4 — Logical Boundary Descriptions 1.7.2.1 TOE Guidance The following guidance documentation will be provided as part of the TOE: * Operational User Guidance and Preparative Procedures Supplement: Concepteers Teleconsole Family Version 2.0 * Quick Install Guide: Teleconsole Secure Remote Diagnostic Access Gateway ® Administration Manual: Teleconsole Secure Remote Diagnostic Access Gateway Document Version 1.2 © Concepteers Page 10 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 2 Conformance Claims 2.1 CC Conformance Claim The TOE is Common Criteria Version 3.1 Revision 3 (July 2009) Part 2 conformant and Part 3 conformant. 2.2 PP Claim The TOE does not claim conformance to any registered Protection Profile. 2.3 Package Claim The TOE claims conformance to the EAL3 assurance package defined in Part 3 ofthe Common Criteria Version 3.1 Revision 3 (July 2009). The TOE does not claim conformance to any functional package. 2.4 Conformance Rationale No conformance rationale is necessary for this evaluation since this Security Target does not claim conformance to a Protection Profile. Document Version 1.2 © Concepteers Page 11 0f42 Security Target: Concepteers Teleconsole Family Version 2.0 3 Security Problem Definition In order to clarify the nature of the security problem that the TOE is intended to solve, this section describes the following: ® Any known or assumed threats to the assets against which specific protection within the TOE or its environment is required * Any organizational security policy statements or rules with which the TOE must comply * Any assumptions about the security aspects of the environment and/or of the manner in which the TOE is intended to be used. This chapter identifies assumptions as A.assumption, threats as T.threat and policies as P.policy. 3.1 Threats The following are threats identified for the TOE and the IT System the TOE monitors. The TOE itself has threats and the TOE is also responsible for addressing threats to the environment in which it resides. The assumed level of expertise of the attacker for all threats is unsophisticated. The TOE addresses the following threats: THREAT DESCRIPTION T.AUDACC Persons may not be accountable for the actions that they conduct because the audit records are not reviewed, thus allowing an attacker to modify the behavior of TSF data without being detected. T.AUDFUL An unauthorized person may cause audit records to be lost or prevent future records from being recorded by taking actions to exhaust audit storage capacity, thus masking an attackers actions. T.MEDIAT An unauthorized person may send impermissible information through the TOE which results in the exploitation of resources on the internal network. T.NOAUTH An unauthorized person may attempt to bypass the security of the TOE so as to access and use security functions and/or non-security functions provided by the TOE. T.OLDINF An unauthorized person may gather residual information from a previous information flow or internal TOE data by monitoring the padding of the information flows from the TOE. T.PROCOM An unauthorized person or unauthorized external IT entity may be able to view, modify, and/or delete security related information or information properties sent between a remotely located authorized administrator and the TOE. T.REPLAY An unauthorized person may replay valid identification and authentication data obtained while monitoring the TOE’s network interface to access functions provided by the TOE. Document Version 1.2 © Concepteers Page 12 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 THREAT DESCRIPTION T.SELPRO An unauthorized person may read, modify, or destroy security critical TOE configuration data. T.TUSAGE The TOE may be inadvertently configured, used and administered in an insecure manner by either authorized or unauthorized persons. Table 5 - Threats Addressed by the TOE The IT Environment does not explicitly addresses any threats. 3.2. Organizational Security Policies The TOE is not required to meet any organizational security policies. 3.3 Assumptions This section describes the security aspects of the environment in which the TOE is intended to be used. The TOE is assured to provide effective security measures in a co-operative non-hostile environment only if it is installed, managed, and used correctly. The following specific conditions are assumed to exist in an environment where the TOE is employed. ASSUMPTION DESCRIPTION A.GENPUR There are no general-purpose computing capabilities (e.g., the ability to execute arbitrary code or applications) and storage repository capabilities on the TOE. A.NOEVIL Authorized administrators are non-hostile and follow all administrator guidance; however, they are capable of error. A.PHYSEC The processing resources of the TOE will be located within controlled access facilities, which will prevent unauthorized physical access. A.PUBLIC The TOE does not host public data. A.SINGEN Information cannot flow among the internal and external networks unless it passes through the TOE. Table 6 - Assumptions Document Version 1.2 © Concepteers Page 13 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 4 Security Objectives 4.1 Security Objectives for the TOE The IT security objectives for the TOE are addressed below: OBJECTIVE DESCRIPTION O.ACCOUN The TOE must provide user accountability for information flows through the TOE and for authorized administrator use of security functions related to audit. O.AUDREC The TOE must provide a means to record a readable audit trail of security- related events, with accurate dates and times, and a means to search the audit trail based on relevant attributes. O.ENCRYP The TOE must protect the confidentiality of its dialogue with an authorized administrator and/or user through encryption. O.IDAUTH The TOE must uniquely identify and authenticate the claimed identity of all users, before granting a user access to TOE functions. O.MEDIAT The TOE must mediate the flow of all information from users on an external network to resources on an internal network, and must ensure that residual information from a previous information flow is protected and not transmitted in any way. O.SECFUN The TOE must provide functionality that enables an authorized administrator to use the TOE security functions, and must ensure that only authorized administrators are able to access such functionality. O.SECKEY The TOE must provide the means of protecting the confidentiality of cryptographic keys when they are used to encrypt/decrypt traffic flows. O.SECSTA Upon initial start-up of the TOE or recovery from an interruption in TOE service, the TOE must not compromise its resources or those of any connected network. O.SELPRO The TOE must protect itself against attempts by unauthorized users to bypass, deactivate, or tamper with TOE security functions. O.SINUSE The TOE must prevent the reuse of authentication data for users attempting to authenticate at the TOE from a connected network. Table 7 — TOE Security Objectives 4.2 Security Objectives for the Operational Environment The security objectives for the operational environment are addressed below: OBJECTIVE DESCRIPTION OE.ADMTRA Authorized administrators are trained to appropriately install, configure, and maintain the TOE within its evaluated configuration according to the installation and guidance documents for the TOE. OE.GENPUR There are no general-purpose computing capabilities (e.g., the ability to execute arbitrary code or applications) and storage repository capabilities on the TOE. Document Version 1.2 © Concepteers Page 14 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 OE.GUIDAN The TOE must be delivered, installed, administered, and operated in a manner that maintains security. OE.PHYSEC Those responsible for the TOE must ensure that those parts of the TOE critical to the security policy are protected from any physical attack. OE.PUBLIC The TOE does not host public data. OE.SINGEN Information cannot flow among the internal and external networks unless it passes through the TOE. Table 8 - Operational Environment Security Objectives 4.3 Security Objectives Rationale This section provides the summary that all security objectives are traced back to aspects of the addressed assumptions, threats, and Organizational Security Policies. THREATS/ ASSUMPTIONS , — let EE RO EEE CLS PE TE OBJECTIVES O.ACCOUN O.AUDREC v O.ENCRYP v O.IDAUTH v O.MEDIAT v v O.SECFUN v O.SECKEY v O.SECSTA v O.SELPRO v v O.SINUSE v OE.ADMTRA v v OE.GENPUR v OE.GUIDAN v OE.PHYSEC v OE.PUBLIC v OE.SINGEN v Table 9 - Mapping of Assumptions, Threats, and OSPs to Security Objectives Document Version 1.2 © Concepteers Page 15 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 4.3.1.1 Rationale for Security Threats to the TOE T.AUDACC This threat is completely countered by * O.ACCOUN which ensures the TOE provides user accountability for information flows through the TOE and for Administrator use of security functions related to audit. * O.AUDREC which ensures The TOE provides a means to record a readable audit trail of security-related events, with accurate dates and times, and a means to search the audit trail based on relevant attributes T.AUDFUL This threat is completely countered by * O.SECFUN which ensures the TOE provides functionality that enables an Administrator to use the TOE security functions and also ensures that only Administrators are able to access such functionality * O.SELPRO which ensures the TOE must protect itself against attempts by unauthorized users to bypass, deactivate, or tamper with TOE security functions. T.MEDIAT This threat is completely countered by * O.MEDIAT which ensures the TOE mediates the flow of all information from users on an external network to resources on an internal network T.NOAUTH This threat is completely countered by * O.IDAUTH which ensures the TOE uniquely identifies and authenticates the claimed identity of all users before granting a user access to TOE functions. T.OLDINF This threat is completely countered by * O.MEDIAT which ensures that residual information from a previous information flow is protected and not transmitted T.PROCOM This threat is completely countered by * O.ENCRYP which ensures the TOE protects the confidentiality of its dialogue with an Administrator through encryption * O.SECKEY which ensures the TOE provides the means of protecting the confidentiality of cryptographic keys when they are used to encrypt/decrypt traffic flows T.REPLAY This threat is completely countered by * O.SINUSE which the TOE prevents the reuse of authentication data for users attempting to authenticate at the TOE from a connected network T.SELPRO This threat is completely countered by * O.SECSTA which ensures the TOE does not compromise its resources or those of any connected network upon initial start-up or recovery from an interruption in TOE service * O.SELPRO which ensures the TOE protects itself against attempts by unauthorized users to bypass, deactivate, or tamper with TOE security functions Document Version 1.2 © Concepteers Page 16 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 THREAT RATIONALE T.TUSAGE This threat is completely countered by * OE.ADMTRA which ensures the operational environment provides well- trained administrators to appropriately install, configure, and maintain the TOE within its evaluated configuration according to the installation and guidance documents for the TOE. * OE.GUIDAN which ensures the operational environment provides a secure manner of TOE delivery, installation, administration, and operation Table 10 - Mapping of Objectives to Threats 4.3.1.2 Rationale for Security Objectives of the TOE OBJECTIVE RATIONALE O.ACCOUN This security objective is necessary to counter the threat: T.AUDACC because it requires that users are accountable for information flows as well as management function. O.AUDREC This security objective is necessary to counter the threat: T.AUDACC by requiring a readable audit trail and a means to search the information contained in the audit trail. O.ENCRYP This security objective is necessary to counter the threat T.PROCOM by requiring that an operator use encryption when performing administrative functions on the TOE remotely. O.IDAUTH This security objective is necessary to counter the threat: T.NOAUTH because it requires that users be uniquely identified before accessing the TOE. O.MEDIAT This security objective is necessary to counter the threats: T.MEDIAT and T.OLDINF which have to do with getting impermissible information to flow through the TOE. This security objective requires that all information that passes through the networks is mediated by the TOE and that no residual information is transmitted. O.SECFUN This security objective is necessary to counter the threat T.AUDFUL by requiring that the TOE provides functionality that ensures that only authorized users have access to the TOE security functions. O.SECKEY The objective mitigates the threat of data modification or disclosure by ensuring that cryptographic keys are generated sufficiently, kept confidential, and destroyed property (T.PROCOM) O.SECSTA This security objective ensures that no information is comprised by the TOE upon startup or recovery and thus counters the threat T.SELPRO. O.SELPRO This security objective is necessary to counter the threats: T.SELPRO and T.AUDFUL because it requires that the TOE protect itself from attempts to bypass, deactivate, or tamper with TOE security functions. O.SINUSE This security objective is necessary to counter the threats: T.REPLAY because it requires that the TOE prevent the reuse of authentication data so that even if valid authentication data is obtained, it will not be used to mount an attack. Document Version 1.2 © Concepteers Page 17 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 OBJECTIVE RATIONALE OE.ADMTRA This non-IT security objective is necessary to counter the threat T.TUSAGE and support the assumption A.NOEVIL because it ensures that authorized administrators receive the proper training in the correct configuration, installation and usage of the TOE. OE.GENPUR There are no general-purpose computing capabilities (e.g., the ability to execute arbitrary code or applications) and storage repository capabilities on the TOE. (A.GENPUR) OE.GUIDAN This non-IT security objective is necessary to counter the threat: T.TUSAGE because it requires that those responsible for the TOE ensure that it is delivered, installed, administered, and operated in a secure manner. OE.PHYSEC The objective to provide physical protection for the TOE supports the assumption that the TOE will be located within controlled access facilities, which will prevent unauthorized physical access (A.PHYSEC). OE.PUBLIC The TOE does not host public data. (A.PUBLIC) OE.SINGEN Information cannot flow among the internal and external networks unless it passes through the TOE. (A.SINGEN) Table 11 - Mapping of Threats, Policies, and Assumptions to Objectives Document Version 1.2 © Concepteers Page 18 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 5 Extended Components Definition 5.1 Definition of Extended Components There are no extended components in this Security Target. Document Version 1.2 © Concepteers Page 19 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 6 Security Requirements The security requirements that are levied on the TOE and the IT environment are specified in this section of the ST. 6.1 Security Functional Requirements The functional security requirements for this Security Target consist of the following components from Part 2 of the CC, which are summarized in the following table: SS HEADING CLASS_FAMILY DESCRIPTION Security Audit FAU_GEN.1 Audit Data Generation FAU_SAR.1 Audit Review FAU_STG.1 Protected Audit Trail Storage Cryptographic Support FCS_CKM.1 Cryptographic Key Generation FCS_CKM.2 Cryptographic Key Distribution FCS_CKM.4 Cryptographic Key Destruction FCS_COP.1 Cryptographic Operation User Data Protection FDP_IFC.1 Subset Information Flow Control FDP_IFF.1 Simple Security Attributes Identification and FIA_ATD.1 User attribute definition Authentication FIA_SOS.1 Verification of secrets FIA_UAU.2 User authentication before any action FIA_UID.2 User identification before any action Security Management FMT_MOF.1 Management of Security Functions Behavior FMT_MSA.1 Management of Security Attributes FMT_MSA.2 Secure Security Attributes FMT_MSA.3 Static Attribute Initialization FMT_SAE.1 Time-limited authorization FMT_MTD.1 Management of TSF Data FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles Protection ofthe TSF FPT_STM.1 Reliable Time Stamps Trusted Path/Channels FTP_TRP.1 Trusted Path Table 12 - TOE Security Functional Requirements 6.1.1 Security Audit (FAU) 6.1.1.1 FAU_GEN.1 - Audit Data Generation FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: Document Version 1.2 © Concepteers Page 20 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 a) Start-up and shutdown of the audit functions; b) All auditable events for the [not specified] level of audit; and c) [The events in column two of Table 13 — Auditable Events] FAU_GEN.1.2 The TSF shall record within each audit record at last the following information: a) Date and time of the event, type of event, subject identity (if applicable), 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, [information specified in column two of Table 13 — Auditable Events]. oi FMT_SMR.1 EVENT Modifications to the group of users that are part of a role. DETAIL: The identity of the Administrator performing the modification and the user identity being associated with a role FIA_UID.2 All use of the user identification mechanism. None FIA_UAU.2 Any use of the user authentication mechanism. None FDP_IFF.1 All decisions on requests for information flow. The presumed addresses of the source and destination subject. FPT_STM.1 Changes to the time. The identity of the Administrator performing the operation FMT_MOF.1 Use of the functions listed in this requirement pertaining to audit with the exception for viewing information flow security policy rules (FMT_MOF.1 b), user attribute values (FMT_MOF.1 c), and audit trail data (FMT_MOF.1 f). The identity of the Administrator performing the operation Table 13 - Auditable Events Document Version 1.2 © Concepteers Page 21 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 6.1.1.2 FAU_SAR.1 - Audit Review FAU_SAR.1.1 The TSF shall provide [an Administrator, Read-only Administrator, and Limited ‚Administrator roles] with the capability to read [all audit information] from the audit records. FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the information. 6.1.1.3 FAU_STG.1 - Protected Audit Trail Storage FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorized deletion. FAU_STG.1.2 The TSF shall be able to [prevent] unauthorized modifications to the audit records in the audit trail. 6.1.2 Cryptographic Support (FCS) 6.1.2.1 FCS_CKM.1 - Cryptographic Key Generation FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [ANSI X9.31] and specified cryptographic key sizes [128-, 192-, or 256-bit AES key and 168-bit TDES key] that meet the following: [FIPS 197 for AES and FIPS 46-3 for TDES]. 6.1.2.2 FCS_CKM.2 - Cryptographic Key Distribution FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [RSA or DSA] that meets the following: [TLS v1.2 specification RFC 5246]. 6.1.2.3 FCS_CKM.4 - Cryptographic Key Destruction FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [overwrite] that meets the following: [Federal Information Processing Standard 140 requirements for key zeroization]. 6.1.2.4 FCS_COP.1 - Cryptographic Operation FCS_COP.1.1 The TSF shall perform [the operations described below] in accordance with a specified cryptographic algorithm [multiple algorithms in the modes of operation described below] and cryptographic key sizes [multiple key sizes described below] that meet the following: [multiple standards described below]. Document Version 1.2 © Concepteers Page 22 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 GORITHM KEY SIZE IN CAVP (MODE) CLS CERTIFICATE STANDARD Encryption AES 128, 192, 1544 / 1547 | FIPS 197 and 256 Decryption | TDES 168 1014/1017 | FIPS 46-3 Hashing SHA-1 160 1369 / 1374 | FIPS 180-3 SHA-224 224 SHA-256 256 SHA-384 384 SHA-512 512 Digital DSA Modulus 476 / 479 FIPS 186-3 Signatures Size: 1024 RSA Modulus 747 / 752 ANSI X9.31 Size: 1024 PKCS #1 v1.5 RSASSA-PSS Random ANSI X9.31 Not 832 / 836 ANSI X9.31 Number Applicable Generation Table 14 — Cryptographic Operations 6.1.3 Information Flow Control (FDP) 6.1.3.1 FDP_IFC.1 - Subset Information Flow Control FDP_IFC.1.1 The TSF shall enforce the [Authenticated User SFP] on [Subjects: unauthenticated external IT entities that send and receive packets through the TOE to one another, Information: network packets sent through the TOE from one subject to another, and Operations: permit, deny, or reject routing of information]. 6.1.3.2 FDP_IFF.1 - Simple Security Attributes FDP_IFF.1.1 Document Version 1.2 The TSF shall enforce the [Authenticated User SFP] based on the following types of subject and information security attributes: [Subject security attributes: ° Role Information security attributes: © Concepteers Page 23 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 FDP_IFF.1.2 FDP_IFF.1.3 FDP_IFF.1.4 FDP_IFF.1.5 + Resource type]. The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: [ ® Auser’srole is permitted to access the requested resource type]. The TSF shall enforce the [No additional rules]. The TSF shall explicitly authorize an information flow based on the following rules: [No additional rules]. The TSF shall explicitly deny an information flow based on the following rules: [No additional rules]. 6.1.4 Identification and Authentication (FIA) 6.1.4.1 FIA_ATD.1 - FIA_ATD.1.1 User Attribute Definition The TSF shall maintain the following list of security attributes belonging to individual users: [identity, association of a human user with a role, password, enabled/disabled account]. 6.1.4.2 FIA_SOS.1 - Verification of secrets FIA_SOS.1.1 6.1.4.3 FIA_UAU.2 - FIA_UAU.2.1 Document Version 1.2 The TSF shall provide a mechanism to verify that secrets meet [ 1. Minimum of eight (8) characters, 2. Minimum of one (1) to three (3) numeric characters, 3. Minimum of one (1) to three (3) alphabetic characters, 4. Combination of both uppercase and lowercase alphabetic characters, and 5. Different from the previously used password]. User Authentication before Any Action The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. © Concepteers Page 24 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 6.1.4.4 FIA_UID.2 - User Identification before Any Action FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. 6.2 Security Management (FMT) 6.2.1.1 FMT_MOF.1 - Management of Security Functions Behavior FMT_MOF.1.1 The TSF shall restrict the ability to [determine the behavior of, disable, enable, modify the behavior of] the functions [ 1. Start-up and shutdown; 2. Create, delete, modify, and view information flow security policy rules that permit or deny information flows; 3. Create, delete, modify, and view user attribute values defined in FIA_ATD.1; 4. Enable and disable external IT entities from communicating to the TOE; 5. Modify and set the time and date; 6. Review the audit trail;] to [the Administrator role]. 6.2.1.2 FMT_MSA.1 - Management of security attributes FMT_MSA.1.1 The TSF shall enforce the [Authenticated User SFP] to restrict the ability to [query, modify, delete] the security attributes [information flow security policy rules that permit or deny information flows and user attribute values defined in FIA_ATD.1] to [the Administrator role]. 6.2.1.3 FMT_MSA.2 - Secure Security Attributes FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for [security attributes listed with Authenticated User SFP]. 6.2.1.4 FMT_MSA.3 - Static Attribute Initialization FMT_MSA.3.1 The TSF shall enforce the [Authenticated User SFP] to provide [restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the [the Administrator role] to specify alternative initial values to override the default values when an object or information is created. Document Version 1.2 © Concepteers Page 25 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 6.2.1.5 FMT_SAE.1- FMT_SAE.1.1 FMT_SAE.1.2 Time-limited Authorization The TSF shall restrict the capability to specify an expiration time for [passwords] to [the Administrator role]. For each of these security attributes, the TSF shall be able to [prompt the authenticated entity to change their password before allowing access to the User or Administrator interfaces of the TOE] after the expiration time for the indicated security attribute has passed. 6.2.1.6 FMT_MTD.1 - Management of TSF Data FMT_MTD.1.1 The TSF shall restrict the ability to control the [data described in the table below] to [the Administrator role]: CHANGE ATA DEFAULT UERY MODIFY | DELETE CLEAR Authenticated User v v v v v SFP Audit Logs v User Account v v v Attributes Date/Time v v Table 15 - Management of TSF data 6.2.1.7. FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 Document Version 1.2 The TSF shall be capable of performing the following security management functions: [ a) Start-up and shutdown; b) Create, delete, modify, and view information flow security policy rules that permit or deny information flows; c) Create, delete, modify, and view user attribute values defined in FIA_ATD.1; d) Enable and disable external IT entities from communicating to the TOE; e) Modify and set the time and date; f) Archive, clear, and review the audit trail]. © Concepteers Page 26 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 6.2.1.8 FMT_SMR.1 Security Roles FMT_SMR.1.1 The TSF shall maintain the roles [Administrator, Limited Administrator, Read- Only Administrator, and User]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. 6.2.2 Protection ofthe TSF (FPT) 6.2.2.1 FPT_STM.1 Reliable Time Stamps FPT_STM.1.1 The TSF shall be able to provide reliable time stamps. 6.2.3 Trusted Path/Channels (FTP) 6.2.3.1 FTP_TRP.1 -Trusted Path FTP_TRP.1.1 The TSF shall provide acommunication path between itself and [remote] users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data [from modification or disclosure}. FTP_TRP.1.2 The TSF shall permit [remote users] to initiate communication via the trusted path. FTP_TRP.1.3 The TSF shall require the use of the trusted path for [initial user authentication, [and all further communication after authentication]. 6.3 Security Functional Requirements for the IT Environment There are no Security Functional Requirements for the IT Environment. 6.4 CC Component Hierarchies and Dependencies This section of the ST demonstrates that the identified SFRs include the appropriate hierarchy and dependencies. The following table lists the TOE SFRs and the SFRs each are hierarchical to, dependent upon and any necessary rationale. SFR HIERARCHICAL TO DEPENDENCY RATIONALE FAU_GEN.1 No other FPT_STM.1 Satisfied components FAU_SAR.1 No other FAU_GEN.1 Satisfied components Document Version 1.2 © Concepteers Page 27 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 SFR HIERARCHICAL T{ DEPENDEN RATIONALE FAU_STG.1 No other FAU_GEN.1 Satisfied components FCS_CKM.1 No other FCS_CKM.2 or Satisfied components FCS_COP.1 FCS_CKM.4 FCS_CKM.2 No other FDP_ITC.1 or Satisfied components FDP_IDC.2 or FCS_CKM.1 FCS_CKM.4 FCS_CKM.4 No other FDP_ITC.1 or Satisfied components FDP_IDC.2 or FCS_CKM.1 FCS_COP.1 No other FDP_ITC.1 or Satisfied components FDP_IDC.2 or FCS_CKM.1 FCS_CKM.4 FDP_IFC.1 No other FDP_IFF.1 Satisfied components FDP_IFF.1 No other FDP_IFC.1 Satisfied components FMT_MSA.3 FIA_ATD.1 No other None n/a components FIA_SOS.1 No other None n/a components FIA_UAU.2 No other FIA_UID.1 Satisfied components FIA_UID.2 FIA_UID.1 None n/a FMT_MOF.1 No other FMT_SMF.1 Satisfied components FMT_SMR.1 FMT_MSA.1 No other FDP_ACC.1 or Satisfied components FDP_IFC.1 FMT_SMF.1 FMT_SMR.1 FMT_MSA.2 No other FDP_ACC.1 or Satisfied components FDP_IFC.1 FMT_MSA.1 FMT_SMR.1 FMT_MSA.3 No other FMT_MSA.1 Satisfied components FMT_SMR.1 FMT_MTD.1 No other FMT_SMF.1 Satisfied components FMT_SMR.1 FMT_SAE.1 No other FMT_SMR.1 Satisfied components FPT_STM.1 FMT_SMF.1 No other None n/a components Document Version 1.2 © Concepteers Page 28 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 SFR HIERARCHI DEPENDEN FMT_SMR.1 No other FIA_UID.1 Satisfied components FPT_STM.1 No other None n/a components FTP_TRP.1 No other None n/a components Table 16 — TOE SFR Dependency Rationale 6.5 Security Assurance Requirements The Security Assurance Requirements for this evaluation are listed in Section 6.6.3 — Security Assurance Requirements. 6.6 Security Requirements Rationale 6.6.1 Security Functional Requirements The following table provides the correspondence mapping between security objectives for the TOE and the requirements that satisfy them. OBJECTIVE cas Pan CAL o © O.SECKEY O.ENCRYP O.SELPRO O.AUDREC O.ACCOUN O.SECFUN O.SINUSE FAU_GEN.1 FAU_SAR.1 FAU_STG.1 v v FCS_CKM.1 FCS_CKM.2 FCS_CKM.4 FCS_COP.1 v FDP_IFC.1 v FDP_IFF.1 v FIA_ATD.1 v v FIA_SOS.1 v SEN SN Document Version 1.2 © Concepteers Page 29 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 OBJECTIVE FIA_UAU.2 fa Fe u CRE ET) o Oo Oo O.SELPRO O.AUDREC O.ACCOUN O.SECFUN O.SINUSE FIA_UID.2 FMT_MOF.1 FMT_MSA.1 FMT_MSA.2 FMT_MSA.3 FMT_MTD.1 ANN ASIANA WANN FMT_SAE.1 FMT_SMF.1 FMT_SMR.1 SSSSSNNNNN FPT_STM.1 v FTP_TRP.1 v Table 17 - Mapping of TOE Security Functional Requirements and Objectives 6.6.2 Sufficiency of Security Requirements The following table presents a mapping of the rationale of TOE Security Requirements to Objectives. SFR RATIONALE FAU_GEN.1 This component outlines what data must be included in audit records and what events must be audited. This component traces back to and aids in meeting the following objectives: O.AUDREC and O.ACCOUN. FAU_SAR.1 This component ensures that the audit trail is understandable. This component traces back to and aids in meeting the following objective: O.AUDREC. FAU_STG.1 This component is chosen to ensure that the audit trail is protected from tampering. Only the Administrator is permitted to do anything to the audit trail. This component traces back to and aids in meeting the following objectives: O.SELPRO and O.SECFUN. FCS_CKM.1 This component ensures that cryptographic keys and parameters are generated with standards-based algorithms (O.SECKEY). FCS_CKM.2 This component provides secure key distribution to remote trusted IT products (users or other instances of TOE). The TOE to perform authentication using digital certificates, ensuring the source is trusted (O.SECKEY). Document Version 1.2 © Concepteers Page 30 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 SFR FCS_CKM.4 Ve Eas This component ensures that the cryptographic keys and parameters are safely destroyed when their lifetime ends or when the Administrator forces generation of new keys. Keys are zeroized in accordance with FIPS 140-2 specifications (O.SECKEY). FCS_COP.1 This component ensures that when all users communicate with the TOE remotely from an internal or external network that robust algorithms are used to encrypt such traffic. This component traces back to and aids in meeting the following objective: O.ENCRYP. FDP_IFC.1 This component identifies the entities involved in the Authenticated User SFP (i.e., users sending information to other users and vice versa). This component traces back to and aids in meeting the following objective: O.MEDIAT. FDP_IFF.1 This component identifies the attributes of the users sending and receiving the information in the Authenticated User SFP, as well as the attributes for the information itself. Then the policy is defined by saying under what conditions information is permitted to flow. This component traces back to and aids in meeting the following objective: O.MEDIAT. FIA_ATD.1 This component exists to provide users with attributes to distinguish one user from another, for accountability purposes and to associate the role chosen in FMT_SMR.1 with a user. This component traces back to and aids in meeting the following objectives: O.IDAUTH and O.SINUSE. FIA_SOS.1 This component exists to ensure that passwords generated by users can be verified to meet the defined minimum password strength requirements. This component traces back to and aids in meeting the following objective: O.IDAUTH. FIA_UAU.2 This component requires successful authentication of a role before having access to the TSF and as such aids in meeting O.IDAUTH. FIA_UID.2 This component requires successful identification of a role before having access to the TSF and as such aids in meeting O.IDAUTH and O.ACCOUN. Document Version 1.2 © Concepteers Page 31 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 SFR FMT_MOF.1 Ve Eas This component was chosen to consolidate all TOE management/administration/security functions. This component traces back to and aids in meeting the following objectives: O.SECFUN and O.SECSTA. FMT_MSA.1 This component restricts the ability to modify, delete, or query the parameters for the Authenticated User SFP to an Administrator, and as such aids in meeting O.ENCRYP. It also assists in effective management, and as such aids in meeting O.MEDIAT, O.SECSTA, and O.SECFUN. FMT_MSA.2 This component ensures that only secure values are accepted for the configuration parameters associated with the Authenticated User SFP, and as such aids in meeting O.ENCRYP. It also assists in effective management, and as such aids in meeting O.MEDIAT, O.SECSTA, and O.SECFUN. FMT_MSA.3 This component ensures that the TOE provides a default restrictive policy for the information flow control security rules, yet allows an Administrator to override the default restrictive values with permissive values. This component traces back to and aids in meeting the following objectives: O.ENCRYP, O.MEDIAT, O.SECSTA, and O.SECFUN. FMT_MTD.1 This component restricts the ability to modify the Authenticated User SFP, and as such aids in meeting O.ENCRYP, O.MEDIAT, O.SECSTA, and O.SECFUN. This component restricts the ability to modify identification and authentication data, and as such aids in meeting O.IDAUTH, O.MEDIAT, O.SECSTA, and O.SECFUN. This component restricts the ability to modify the date and time, and as such contributes to meeting O.MEDIAT, O.SECSTA, and O.SECFUN. This component restricts the ability to modify the data relating to TOE access locations, and as such contributes to meeting O.MEDIAT, O.SECSTA, and O.SECFUN. FMT_SAE.1 The component provides the capability for an Administrator to specify an expiration time on a user’s password. This component traces back to and aids in meeting the following objective: O.SECFUN. FMT_SMF.1 This component was chosen in an attempt to consolidate all TOE management/administration/security functions. This component traces back to and aids in meeting the following objective: O.SECFUN. FMT_SMR.1 This component ensures that roles are available to allow for varying levels of administration capabilities and restricts access to perform TSF relevant functionality depending on the role assigned to an authorized administrator. This component traces back to and aids in meeting the following objective: O.SECFUN. FPT_STM.1 FAU_GEN.1 depends on this component. It ensures that the date and time on the TOE is dependable. This is important for the audit trail. This component traces back to and aids in meeting the following objective: O.AUDREC. FTP_TRP.1 This component works with the encryption provided in the FCS_COP.1 requirement to ensure that user authentication data or other user data is protected from disclosure and modification. This component traces back to and aids in meeting the following objective: O.ENCRYP. Table 18 - Rationale for TOE SFRs to Objectives Document Version 1.2 © Concepteers Page 32 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 The following table presents a mapping of the rationale of TOE Objectives to Security Requirements: OBJECTIVE RATIONALE O.ACCOUN This objective is completely satisfied by ® FAU_GEN.1 which outlines what events must be audited ¢ FIA_UID.2 ensures that users are identified to the TOE O.AUDREC This objective is completely satisfied by ® FAU_GEN.1 which outlines what events must be audited * FAU_SAR.1 which requires that the audit trail can be read * _FPT_STM.1 ensures that reliable time stamps are provided for audit records O.ENCRYP This objective is completely satisfied by * FCS_COP.1 which ensures robust algorithms are used to support encrypted communications between users and The TOE ® FMT_MSA.1 which restricts the ability to modify, delete, or query the parameters for the Authenticated User SFP to an Administrator ® FMT_MSA.2 which ensures that only secure values are accepted for the configuration parameters associated with the Authenticated User SFP ® FMT_MSA.3 which ensures that there is a default deny policy for the information flow control security rules. ¢ FMT_MTD.1 which restricts the ability to modify the Authenticated User SFP, restricts the ability to modify identification and authentication data, restricts the ability to delete audit logs, restricts the ability to modify the date and time, restricts the ability to modify the data relating to TOE access locations ¢ FTP_TRP.1 which ensures all communications between users and The TOE is encrypted via a secure connection using encryption & decryption algorithms O.IDAUTH This objective is completely satisfied by ¢ FIA_ATD.1 which exists to provide users with attributes to distinguish one user from another, for accountability purposes, and to associate roles with users * FIA_SOS.1 which specifies metrics for authentication, and aids in meeting objectives to restrict access. * FIA_UAU.2 which ensures that users are authenticated to the TOE ¢ FIA_UID.2 which ensures that users are identified to the TOE ¢ FMT_MTD.1 which restricts the ability to modify the Authenticated User SFP, restricts the ability to modify identification and authentication data, restricts the ability to delete audit logs, restricts the ability to modify the date and time, restricts the ability to modify the data relating to TOE access locations Document Version 1.2 © Concepteers Page 33 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 OBJECTIVE RATIONALE O.MEDIAT This objective is completely satisfied by ¢ FDP_IFC.1 which ensures the TOE supports an authenticated user information flow policy that controls who can send and receive network traffic *¢ FDP_IFF.1 which ensures Authenticated User SFP limits information flow based on user roles and resource types ® FMT_MSA.1 which restricts the ability to modify, delete, or query the parameters for the Authenticated User SFP to an Administrator ® FMT_MSA.2 which ensures that only secure values are accepted for the configuration parameters associated with the Authenticated User SFP ® FMT_MSA.3 which ensures that there is a default deny policy for the information flow control security rules. ¢ FMT_MTD.1 which restricts the ability to modify the Authenticated User SFP, restricts the ability to modify identification and authentication data, restricts the ability to delete audit logs, restricts the ability to modify the date and time, restricts the ability to modify the data relating to TOE access locations O.SECFUN This objective is completely satisfied by * FAU_STG.1 which ensures only the authorized administrator has access to the logs * = FMT_MOF.1 which ensures the ability to perform security management functions is restricted to an Administrator ® FMT_MSA.1 which restricts the ability to modify, delete, or query the parameters for the Authenticated User SFP to an Administrator ® FMT_MSA.2 which ensures that only secure values are accepted for the configuration parameters associated with the Authenticated User SFP ® FMT_MSA.3 which ensures that there is a default deny policy for the information flow control security rules. *¢ = FMT_MTD.1 which restricts the ability to modify the Authenticated User SFP, restricts the ability to modify identification and authentication data, restricts the ability to delete audit logs, restricts the ability to modify the date and time, restricts the ability to modify the data relating to TOE access locations * = FMT_SAE.1 which allows the Administrator to set expiration times for user passwords * FMT_SMF.1 lists the security management functions that must be controlled. * _FMT_SMR.1 defines the roles on which access decisions are based. O.SECKEY This objective is completely satisfied by ® FCS_CKM.1 which ensures that cryptographic keys and parameters are generated with standards-based algorithms + FCS_CKM.2 which provides secure key distribution to remote trusted IT products + FCS_CKM.4 which ensures that the cryptographic keys and parameters are safely destroyed. Document Version 1.2 © Concepteers Page 34 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 OBJECTIVE RATIONALE O.SECSTA This objective is completely satisfied by * = FMT_MOF.1 which ensures the ability to perform security management functions is restricted to an authorized Administrator ® FMT_MSA.1 which restricts the ability to modify, delete, or query the parameters for the Authenticated User SFP to an Administrator ® FMT_MSA.2 which ensures that only secure values are accepted for the configuration parameters associated with the Authenticated User SFP ® FMT_MSA.3 which ensures that there is a default deny policy for the information flow control security rules. *¢ = FMT_MTD.1 which restricts the ability to modify the Authenticated User SFP, restricts the ability to modify identification and authentication data, restricts the ability to delete audit logs, restricts the ability to modify the date and time, restricts the ability to modify the data relating to TOE access locations O.SELPRO This objective is completely satisfied by * FAU_STG.1 which ensures only the authorized administrator has access to the logs O.SINUSE This objective is completely satisfied by ¢ FIA_ATD.1 which exists to provide users with attributes to distinguish one user from another, for accountability purposes, and to associate roles with users Table 19 — Rationale for TOE Objectives to SFRs 6.6.3 Security Assurance Requirements The assurance security requirements for this Security Target are taken from Part 3 of the CC. These assurance requirements compose an Evaluation Assurance Level 3 (EAL3). The assurance components are summarized in the following table: CLASS HEADING SS_FAMILY DESCRIPTION ADV: Development ADV_ARC.1 Security Architecture Description ADV_FSP.3 Functional Specification with Complete Summary ADV_TDS.2 Architectural Design AGD: Guidance Documents AGD_OPE.1 Operational User Guidance AGD_PRE.1 Preparative Procedures ALC: Lifecycle Support ALC_CMC.3 Authorization Controls ALC_CMS.3 Implementation representation CM coverage ALC_DEL.1 Delivery Procedures ALC_DVS.1 Identification of Security Measures ALC_LCD.1 Developer defined life-cycle model ASE: Security Target Evaluation | ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives Document Version 1.2 © Concepteers Page 35 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 ASS_FAMIL DESCRIPTION ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE: Tests ATE_COV.2 Analysis of Coverage ATE_DPT.1 Testing: Basic Design ATE_FUN.1 Functional Testing ATE_IND.2 Independent Testing - Sample AVA: Vulnerability Assessment | AVA VAN.2 Vulnerability Analysis Table 20 - Security Assurance Requirements at EAL3 6.6.4 Security Assurance Requirements Rationale The ST specifies Evaluation Assurance Level 3. EAL3 was chosen because it is based upon good commercial development practices with thorough functional testing. EAL3 provides the developers and users a moderate level of independently assured security in conventional commercial TOEs. The threat of malicious attacks is not greater than low, the security environment provides physical protection, and the TOE itself offers a very limited and purpose-built interface. 6.6.5 Security Assurance Requirements Evidence This section identifies the measures applied to satisfy CC assurance requirements. SECURITY ASSURANCE REQUIREMENT EVIDENCE TITLE ADV_ARC.1 Security Architecture Description Security Architecture: Concepteers Teleconsole Family Version 2.0 ADV_FSP.3 Functional Specification with Complete Summary Functional Specification: Concepteers Teleconsole Family Version 2.0 ADV_TDS.2 Architectural Design Architectural Design: Concepteers Teleconsole Family Version 2.0 AGD_OPE.1 Operational User Guidance Operational User Guidance and Preparative Procedures Supplement: Concepteers Teleconsole Family Version 2.0 AGD_PRE.1 Preparative Procedures Operational User Guidance and Preparative Procedures Supplement: Concepteers Teleconsole Family Version 2.0 ALC_CMC.3 Authorization Controls Security Measures: Concepteers Teleconsole Family Version 2.0 ALC_CMS.3 Implementation representation CM coverage Security Measures: Concepteers Teleconsole Family Version 2.0 ALC_DEL.1 Delivery Procedures Secure Delivery Processes and Procedures: Concepteers Teleconsole Family Version 2.0 ALC_DVS.1 Identification of Security Measures Security Measures: Concepteers Teleconsole Family Version 2.0 ALC_LCD.1 Developer defined life- cycle model Life Cycle Model: Concepteers Teleconsole Family Version 2.0 ATE_COV.2 Analysis of Coverage Testing Plan and Analysis: Concepteers Teleconsole Family Version 2.0 Document Version 1.2 © Concepteers Page 36 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 SECURITY ASSURANCE REQUIREMENT EVIDENCE TITLE ATE_DPT.1 Testing: Basic Design Testing Plan and Analysis: Concepteers Teleconsole Family Version 2.0 ATE_FUN.1 Functional Testing Testing Plan and Analysis: Concepteers Teleconsole Family Version 2.0 Table 21 - Security Assurance Rationale and Measures Document Version 1.2 © Concepteers Page 37 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 7 TOE Summary Specification This section presents the Security Functions implemented by the TOE. 7.1 TOE Security Functions The security functions performed by the TOE are as follows: * Security Audit * Cryptographic Operations + User Data Protection * Identification and Authentication + Security Management * Protection of the TSF 7.2 Security Audit The TOE generates a fine-grained set of audit log. These logs are stored on the TOE itself, and the administrator can also download them to a local machine. There are three sets of logs, and the fields associated with each are included inline: ¢ Local Logs o Date/Time o Facility o Logtype o User o Message + Certificate Status Log o Date/Time © Process o Message ¢ SSL Log o Date/Time © Process o Message The TOE generates Local Logs for the following list of events: Document Version 1.2 © Concepteers Page 38 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 * Modifications to the group of users that are part of a role, which includes the identity of the Administrator performing the modification; ¢ Alluse of the user identification mechanism, which includes the user identities provided to the TOE in each related log; ¢ Any use of the authentication mechanism, which includes the user identities provided to the TOE in each related log; + All decisions on requests for information flow, which includes the presumed addresses of the source and destination subject in each related log; ¢ Changes to the time; ¢ The identity of the Administrator performing the operation in each related log; ¢ Startup and shutdown of audit function (instantiated through startup/shutdown of TOE). The logs are only accessible through the Web-Based administrative interface, which only authorized operators can access. When logs are saved from the TOE, they are transferred to the PC connected to the Web-Based administrative interface. The Security Audit function is designed to satisfy the following security functional requirements: ¢ FAU_GEN.1: The TOE generates all the audit events identified in this requirement. Within each event is the information listed above which addresses all required details. ¢ FAU_SAR.1: The Administrator has the ability to read all of the audit logs. Each log is presented to the administrator in a human-readable format. ¢ FAU_STG.1: Only the Administrator has access to the logs. The Administrator is not permitted to modify any information in the logs. The only manipulations allowed on logs are to clear them, download them, save them, or view them. 7.3. Cryptographic Support The TOE provides an encrypted path between users and the TOE. Users connect to the TOE using a secure connection using TDES or AES encryption algorithms supported by The TOE. The secure connection ensures that user passwords and data are protected from modification and disclosure. The TOE provides cryptography via CAVP-validated algorithm implementations, and the cryptographic module fulfills the requirements of FIPS 140-2 Overall Level 2. The Cryptographic Support function is designed to satisfy the following security functional requirements: ¢ FCS_CKM.1: This component ensures that cryptographic keys and parameters are generated with standards-based algorithms ¢ FCS_CKM.2: This component provides secure key distribution to remote trusted IT products ¢ FCS_CKM.4: This component ensures that the cryptographic keys and parameters are safely destroyed when their lifetime ends or when the Administrator forces generation of new keys ¢ FCS_COP.1: Robust algorithms are used to support encrypted communications between users Document Version 1.2 © Concepteers Page 39 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 and The TOE. 7.4 User Data Protection The TOE enforces an information flow policy between authenticated users and protected resources logically behind the appliance. Before any access is granted, users must log into The TOE. Each user account is associated with one or more user roles. The administrator sets up roles and access rules associated with the roles. The access rules can address resource types or other management functions.. The User data protection function is designed to satisfy the following security functional requirements: ¢ FDP_IFC.1: The TOE supports an authenticated user information flow policy that controls who can send and receive network traffic. ¢ FDP_IFF.1: The Authenticated User SFP limits information flow based on user roles and resource types. Administrators have the ability to establish rules that permit or deny information flows based on the combination of attributes listed. 7.5 Identification and Authentication The TOE performs identification and authentication of all users and administrators accessing the TOE. The TOE has the ability to authenticate users locally using a password or can integrate with a remote authentication server. Users enter a username and password, which is validated by The TOE against the user information stored by the TOE. If the authentication succeeds, the user receives a session token that is used for identification of subsequent requests during that session. The Identification and Authentication function is designed to satisfy the following security functional requirements: ¢ FIA_ATD.1: For each registered user, the TOE stores the following information: user identity, user name, user roles, and password. ¢ FIA_SOS.1: The TOE is equipped with a mechanism that can be configured by the administrator to verify that user authentication secrets meet a list of criteria for ensuring their strength. The following parameters for authentication secrets are required for the evaluated configuration: a minimum of eight (8) characters, a minimum of one (1) to three (3) numeric characters, a minimum of one (1) to three (3) alphabetic characters, a combination of both uppercase and lowercase alphabetic characters, and different from the previously used password. ¢ FIA_UAU.2: The TOE requires a valid password associated with a user name before providing access to the TOE. Passwords must conform to the requirements in FIA_SOS.1 e FIA_UID.2: The TOE requires a user name during the identification and authentication process. The username is entered, then a password. If the password is valid, the user will be associated with a role and set of privileges based on the username. Document Version 1.2 © Concepteers Page 40 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 7.6 Security Management The TOE provides security management functions via a browser interface. The Administrator logs onto the TOE from a protected network and performs all management functions through the browser interface. The Administrator has the ability to control all aspects of the TOE configuration including: user management, information flow policy management, audit management, and system start-up and shutdown. The TOE also provides a console port for certain management capabilities, such as configuring the network relevant information pertaining to the internal and external network interfaces. However, the console port does not provide the management capabilities necessary to utilize the security management functionalities claimed within this ST. Administrators set the information flow policy rules on a per user basis. When the Administrator adds a new user, the Administrator defines the user access. By default, user access is restrictive but the Administrator may override the default upon rule creation. The Security Management function is designed to satisfy the following security functional requirements: ¢ FMT_MOF.1: The ability to perform the following security management functions is restricted to an Administrator role: a) start-up and shutdown of The TOE; b) create, delete, modify, and view resource policy rules that permit or deny resource requests; c) create, delete, modify, and view user attribute values, which include a user’s identity, association to a role, and authentication credentials; d) enable and disable external IT entities from communicating to the TOE; e) modify and set the time and date; f) review the audit trail. ¢ FMT_MSA.1: This component restricts the ability to modify, delete, or query the parameters for the Authenticated User SFP to the Administrator role ¢ FMT_MSA.2: This component ensures that only secure values are accepted for the configuration parameters associated with the Authenticated User SFP ¢ FMT_MSA.3: The TOE allows restrictive access by default but the Administrator role can assign more restrictive permissions. ¢ FMT_MTD.1: The TOE restricts the ability to modify the Authenticated User SFP, restricts the ability to modify identification and authentication data, restricts the ability to query audit logs, restricts the ability to modify the date and time, restricts the ability to modify the data relating to TOE access locations. All restrictions apply to unauthenticated or unauthorized users. Document Version 1.2 © Concepteers Page 41 of 42 Security Target: Concepteers Teleconsole Family Version 2.0 ¢ FMT_SAE.1: The TOE allows the Administrator role to set expiration times for operator passwords. When these times are exceeded a user is prompted to change their password before being allowed additional access to the TOE. ¢ FMT_SMF.1: The TOE supports the following security management functions: a) start-up and shutdown of The TOE; b) create, delete, modify, and view resource policy rules that permit or deny resource requests; c) create, delete, modify, and view user attribute values, which include a user’s identity, association to a role, and authentication credentials; d) enable and disable external IT entities from communicating to the TOE; e) modify and set the time and date; f) archive, clear, and review the audit trail. ¢ FMT_SMR.1: The TOE supports the roles administrator, limited administrator, read-only administrator, and user. The administrator role can perform all management functionalities available from within the administrator console and user. The administrator dynamically sets up user roles and access rules associated with the roles. A limited administrator has a subset of the functions associated with the administrator, and these functions are assigned by the administrator. The read-only administrator role provides read-only access to the various configurations and logs available from within the console (as specified by the administrator). The user role has only Diagnostic Access (i.e., access to resources such as medial applications). A 7.7 Protection ofthe TSF The Protection of the TSF function is designed to satisfy the following security functional requirements: ¢ FPT_STM.1: The TOE generates a reliable timestamp for its own use. ¢ FTP_TRP.1: All communications between users and the TOE is encrypted via a secure connection using encryption & decryption algorithms defined in FCS_COP.1. This protects the traffic from disclosure and modification. Document Version 1.2 © Concepteers Page 42 of 42