Vormetric Data Security Manager Version 5.3 Security Target Version 2.3 March 20, 2016 Vormetric, Inc. 2545 N. 1st Street San Jose, CA 95131 Evaluated By: 7925 Jones Branch DriveSuite 5400 McLean, VA 22102-3378703 848-0883Fax 703 848-0985 Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 2 of 106 CygnaCom Solutions Table of Contents Section Page 1 SECURITY TARGET INTRODUCTION.............................................................................................7 1.1 SECURITY TARGET REFERENCE ...................................................................................................7 1.2 TOE REFERENCE ........................................................................................................................7 1.3 CONFORMANCE CLAIMS ...............................................................................................................7 1.4 TECHNICAL DECISIONS.................................................................................................................8 2 TOE DESCRIPTION ..........................................................................................................................9 2.1 PRODUCT OVERVIEW ...................................................................................................................9 2.2 TOE OVERVIEW ........................................................................................................................10 2.2.1 Vormetric Data Security Manager (DSM) ...........................................................................10 2.2.1.1 DSM Software..........................................................................................................................10 2.2.1.2 DSM Hardware ........................................................................................................................11 2.2.1.3 Remote Administrative Management .......................................................................................12 2.2.1.4 Vormetric Agents......................................................................................................................12 2.3 PHYSICAL SCOPE OF THE TOE...................................................................................................13 2.4 PROTOCOLS AND SERVICES EXCLUDED FROM EVALUATION..........................................................14 2.5 LOGICAL SCOPE OF THE TOE.....................................................................................................15 2.5.1 System Monitoring ..............................................................................................................15 2.5.2 Robust TOE Access............................................................................................................15 2.5.3 Authorized Management .....................................................................................................15 2.5.4 Policy Definition...................................................................................................................15 2.5.5 Dependent Product Configuration.......................................................................................16 2.5.6 Confidential Communications .............................................................................................16 2.5.7 Access Bannering ...............................................................................................................16 2.5.8 Cryptographic Services .......................................................................................................16 2.6 TOE GUIDANCE.........................................................................................................................16 3 SECURITY PROBLEM DEFINITION...............................................................................................17 3.1 THREATS...................................................................................................................................17 3.2 ORGANIZATIONAL SECURITY POLICIES (OSPS) ...........................................................................17 3.3 ASSUMPTIONS ...........................................................................................................................18 4 SECURITY OBJECTIVES ...............................................................................................................19 4.1 SECURITY OBJECTIVES FOR THE TOE.........................................................................................19 4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ....................................................20 5 EXTENDED COMPONENTS DEFINITION .....................................................................................21 6 SECURITY REQUIREMENTS.........................................................................................................22 6.1 SECURITY FUNCTIONAL REQUIREMENTS .....................................................................................22 6.1.1 Class ESM: Enterprise Security Management....................................................................23 6.1.1.1 ESM_ACD.1 Access Control Policy Definition .........................................................................23 6.1.1.2 ESM_ACT.1 Access Control Policy Transmission ...................................................................24 6.1.1.3 ESM_ATD.1 Object Attribute Definition....................................................................................24 6.1.1.4 ESM_ATD.2 Subject Attribute Definition..................................................................................25 6.1.1.5 ESM_EAU.2 (1) Reliance on Enterprise Authentication (Password authentication) ................25 6.1.1.6 ESM_EID.2 (1) Reliance on Enterprise Identification (Password authentication) ....................25 Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 3 of 106 CygnaCom Solutions 6.1.1.7 ESM_EAU.2 (2) Reliance on Enterprise Authentication (LDAP authentication).......................25 6.1.1.8 ESM_EID.2 (2) Reliance on Enterprise Identification (LDAP authentication)...........................25 6.1.2 Class FAU: Security Audit...................................................................................................25 6.1.2.1 FAU_GEN.1 Audit Data Generation.........................................................................................25 6.1.2.2 FAU_SEL.1 Selective Audit .....................................................................................................27 6.1.2.3 FAU_SEL_EXT.1 External Selective Audit ..............................................................................27 6.1.2.4 FAU_STG_EXT.1 External Audit Trail Storage........................................................................27 6.1.3 Class FCS: Cryptographic Support.....................................................................................28 6.1.3.1 FCS_CKM.1 Cryptographic Key Generation (for Asymmetric Keys)........................................28 6.1.3.2 FCS_CKM_EXT.4 Cryptographic Key Zeroization...................................................................28 6.1.3.3 FCS_COP.1 (1) Cryptographic Operation (for Data Encryption/Decryption)............................28 6.1.3.4 FCS_COP.1 (2) Cryptographic Operation (for Cryptographic Signature).................................28 6.1.3.5 FCS_COP.1 (3) Cryptographic Operation (for Cryptographic Hashing)...................................29 6.1.3.6 FCS_COP.1 (4) Cryptographic Operation (for Keyed-Hash Message Authentication).............29 6.1.3.7 FCS_HTTPS_EXT.1 HTTPS ...................................................................................................29 6.1.3.8 FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation)....................................29 6.1.3.9 FCS_TLS_EXT.1 TLS..............................................................................................................30 6.1.4 Class FIA: Identification and Authentication .......................................................................30 6.1.4.1 FIA_AFL.1 Authentication Failure Handling .............................................................................30 6.1.4.2 FIA_SOS.1 Verification of Secrets ...........................................................................................30 6.1.4.3 FIA_USB.1 User-Subject Binding.............................................................................................31 6.1.5 Class FMT: Security Management......................................................................................31 6.1.5.1 FMT_MOF.1 Management of Functions Behavior ...................................................................31 6.1.5.2 FMT_MOF_EXT.1 External Management of Functions Behavior ............................................31 6.1.5.3 FMT_MSA_EXT.5 Consistent Security Attributes ....................................................................32 6.1.5.4 FMT_MTD.1 Management of TSF Data...................................................................................32 6.1.5.5 FMT_SMF.1 Specification of Management Functions..............................................................32 6.1.5.6 FMT_SMR.1 Security Management Roles...............................................................................33 6.1.6 Class FPT: Protection of the TSF .......................................................................................33 6.1.6.1 FPT_APW_EXT.1 Protection of Stored Credentials ................................................................33 6.1.6.2 FPT_SKP_EXT.1 Protection of Secret Key Parameters ..........................................................33 6.1.6.3 FPT_STM.1 Reliable Time Stamps..........................................................................................33 6.1.7 Class FTA: TOE Access .....................................................................................................33 6.1.7.1 FTA_SSL_EXT.1 TSF-initiated Session Locking .....................................................................33 6.1.7.2 FTA_SSL.3 TSF-initiated Termination .....................................................................................33 6.1.7.3 FTA_SSL.4 User-initiated Termination.....................................................................................34 6.1.7.4 FTA_TAB.1 TOE Access Banner.............................................................................................34 6.1.8 Class FTP: Trusted Paths/Channels...................................................................................34 6.1.8.1 FTP_ITC.1 Inter-TSF Trusted Channel....................................................................................34 6.1.8.2 FTP_TRP.1 Trusted Path.........................................................................................................34 6.2 SECURITY ASSURANCE REQUIREMENTS FOR THE TOE................................................................35 6.2.1 TOE Security Assurance Requirements .............................................................................35 6.2.2 Explicit Assurance Activities - SARs ...................................................................................38 6.2.2.1 Class ADV Assurance Activities...............................................................................................38 6.2.2.2 Class AGD Assurance Activities ..............................................................................................38 6.2.2.3 Class ALC Assurance Activities ...............................................................................................39 6.2.2.4 Class ATE Assurance Activities ...............................................................................................39 6.2.2.5 Class AVA Assurance Activities...............................................................................................40 6.2.3 Explicit Assurance Activities - SFRs ...................................................................................40 6.2.3.1 ESM_ACD.1 Assurance Activities............................................................................................40 6.2.3.2 ESM_ACT.1 Assurance Activities ............................................................................................41 6.2.3.3 ESM_ATD.1 Assurance Activities ............................................................................................42 6.2.3.4 ESM_ATD.2 Assurance Activities ............................................................................................42 6.2.3.5 ESM_EAU.2 Assurance Activities............................................................................................43 6.2.3.6 ESM_EID.2 Assurance Activities .............................................................................................43 6.2.3.7 FAU_GEN.1 Assurance Activities ............................................................................................43 6.2.3.8 FAU_SEL.1 Assurance Activities .............................................................................................44 Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 4 of 106 CygnaCom Solutions 6.2.3.9 FAU_SEL_EXT.1 Assurance Activities ....................................................................................44 6.2.3.10 FAU_STG_EXT.1 Assurance Activities....................................................................................45 6.2.3.11 FCS_CKM.1 Assurance Activities............................................................................................46 6.2.3.12 FCS_CKM_EXT.4 Assurance Activities...................................................................................46 6.2.3.13 FCS_COP.1 (1) Assurance Activities.......................................................................................46 6.2.3.14 FCS_COP.1 (2) Assurance Activities.......................................................................................47 6.2.3.15 FCS_COP.1 (3) Assurance Activities.......................................................................................47 6.2.3.16 FCS_COP.1 (4) Assurance Activities.......................................................................................47 6.2.3.17 FCS_HTTPS_EXT.1 Assurance Activities ...............................................................................47 6.2.3.18 FCS_RBG_EXT.1 Assurance Activities ...................................................................................48 6.2.3.19 FCS_TLS_EXT.1 Assurance Activities ....................................................................................48 6.2.3.20 FIA_AFL.1 Assurance Activities...............................................................................................49 6.2.3.21 FIA_SOS.1 Assurance Activities..............................................................................................49 6.2.3.22 FIA_USB.1 Assurance Activities ..............................................................................................50 6.2.3.23 FMT_MOF.1 Assurance Activities............................................................................................51 6.2.3.24 FMT_MOF_EXT.1 Assurance Activities...................................................................................51 6.2.3.25 FMT_MSA_EXT.5 Assurance Activities...................................................................................52 6.2.3.26 FMT_MTD.1 Assurance Activities............................................................................................53 6.2.3.27 FMT_SMF.1 Assurance Activities ............................................................................................53 6.2.3.28 FMT_SMR.1 Assurance Activities............................................................................................54 6.2.3.29 FPT_APW_EXT.1 Assurance Activities ...................................................................................54 6.2.3.30 FPT_SKP_EXT.1 Assurance Activities ....................................................................................55 6.2.3.31 FPT_STM.1 Assurance Activities.............................................................................................55 6.2.3.32 FTA_SSL_EXT.1 Assurance Activities.....................................................................................55 6.2.3.33 FTA_SSL.3 Assurance Activities..............................................................................................56 6.2.3.34 FTA_SSL.4 Assurance Activities..............................................................................................56 6.2.3.35 FTA_TAB.1 Assurance Activities .............................................................................................56 6.2.3.36 FTP_ITC.1 Assurance Activities ..............................................................................................57 6.2.3.37 FTP_TRP.1 Assurance Activities .............................................................................................57 7 TOE SUMMARY SPECIFICATION .................................................................................................58 7.1 SYSTEM MONITORING ................................................................................................................59 7.1.1 SM-1: Audit Generation.......................................................................................................59 7.1.2 SM-2: Audit Storage............................................................................................................61 7.2 ROBUST TOE ACCESS...............................................................................................................62 7.2.1 TA-1: Strength of Secrets....................................................................................................62 7.2.2 TA-2: Authentication Failure................................................................................................64 7.2.3 TA-3: Session Termination..................................................................................................64 7.3 AUTHORIZED MANAGEMENT .......................................................................................................65 7.3.1 AM-1: Management I&A......................................................................................................65 7.3.2 AM-2: Management Roles ..................................................................................................66 7.3.3 AM-3: Remote Administration .............................................................................................68 7.4 POLICY DEFINITION....................................................................................................................68 7.4.1 PD-1: Policy Definition ........................................................................................................68 7.5 DEPENDENT PRODUCT CONFIGURATION .....................................................................................75 7.5.1 PC-1: TOE Management Functions....................................................................................75 7.5.2 PC-2: Agent Configuration ..................................................................................................77 7.6 CONFIDENTIAL COMMUNICATIONS...............................................................................................77 7.6.1 CC-1: Agent Communications.............................................................................................78 7.6.2 CC-2: User Communications ..............................................................................................79 7.6.3 CC-3: External Server Communications .............................................................................80 7.6.4 CC-4: Key Protection ..........................................................................................................81 7.7 ACCESS BANNERING..................................................................................................................81 7.7.1 AB-1: Banner.......................................................................................................................81 7.8 CRYPTOGRAPHIC SERVICES .......................................................................................................81 7.8.1 CS-1: Crypto........................................................................................................................81 Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 5 of 106 CygnaCom Solutions Key..............................................................................................................................................................82 Generation Input .........................................................................................................................................82 Storage .......................................................................................................................................................82 Zeroization ..................................................................................................................................................82 Use..............................................................................................................................................................82 8 SECURITY PROBLEM DEFINITION RATIONALE ........................................................................91 9 ACRONYMS AND TERMINOLOGY................................................................................................99 9.1.1 CC Acronyms ......................................................................................................................99 9.1.2 CC Terminology ..................................................................................................................99 9.1.3 Product Acronyms and Terminology.................................................................................102 Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 6 of 106 CygnaCom Solutions Figures and Tables Figures Page FIGURE 1: VORMETRIC DATA SECURITY PRODUCT..........................................................................................9 FIGURE 2: TOE BOUNDARY .........................................................................................................................14 FIGURE 3: SECURITY RULE STRUCTURE.......................................................................................................70 FIGURE 4: DSM FUNCTIONAL BLOCK DIAGRAM ............................................................................................89 Tables Page TABLE 2-1: DSM APPLIANCE HARDWARE FEATURES ....................................................................................11 TABLE 2-3: ST REFERENCE DOCUMENTS.....................................................................................................16 TABLE 3-1: TOE THREATS...........................................................................................................................17 TABLE 3-2: ORGANIZATIONAL SECURITY POLICIES........................................................................................17 TABLE 3-3: CONNECTIVITY ASSUMPTIONS ....................................................................................................18 TABLE 4-1: TOE SECURITY OBJECTIVES......................................................................................................19 TABLE 4-2: SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ....................................................20 TABLE 5-1: EXTENDED COMPONENTS ..........................................................................................................21 TABLE 6-1: TOE SECURITY FUNCTIONAL COMPONENTS ...............................................................................23 TABLE 6-2: AUDITABLE EVENTS ([ESM PP PM] TABLE 3.)............................................................................26 TABLE 6-3: MANAGEMENT FUNCTIONS WITHIN THE TOE ([ESM PP PM] TABLE 4.)........................................32 TABLE 6-4: [ESM PM PP] ASSURANCE COMPONENTS..................................................................................35 TABLE 6-5: ADV_FSP.1 BASIC FUNCTIONAL SPECIFICATION........................................................................36 TABLE 6-6: AGD_OPE.1 OPERATIONAL USER GUIDANCE ............................................................................36 TABLE 6-7: AGD_PRE.1 PREPARATIVE PROCEDURES .................................................................................37 TABLE 6-8: ALC_CMC.1 LABELING OF THE TOE .........................................................................................37 TABLE 6-9: ALC_CMS.1 TOE CM COVERAGE ............................................................................................37 TABLE 6-10: ATE_IND.1 INDEPENDENT TESTING – CONFORMANCE..............................................................37 TABLE 6-11: AVA_VAN.1 VULNERABILITY SURVEY......................................................................................38 TABLE 7-1: SECURITY FUNCTIONAL REQUIREMENTS MAPPED TO SECURITY FUNCTIONS.................................58 TABLE 7-2: MESSAGE LOG INFORMATION .....................................................................................................59 TABLE 7-3: PASSWORD POLICY PARAMETERS ..............................................................................................62 TABLE 7-4: SECURITY RULE ACTIONS ..........................................................................................................71 TABLE 7-5: SECURITY RULE EFFECTS ..........................................................................................................72 TABLE 7-6: DSM MANAGEMENT FUNCTIONS BY ADMINISTRATOR TYPE..........................................................75 TABLE 7-7: PORTS AND PROTOCOLS FOR EXTERNAL COMMUNICATIONS........................................................77 TABLE 7-8: DSM KEY GENERATION .............................................................................................................82 TABLE 7-9: DSM CRYPTOGRAPHIC OPERATIONS..........................................................................................87 TABLE 8-1: ASSUMPTIONS, ENVIRONMENTAL OBJECTIVES, AND RATIONALE...................................................91 TABLE 8-2: POLICIES, THREATS, OBJECTIVES, AND RATIONALE.....................................................................93 TABLE 9-1: CC ACRONYMS .........................................................................................................................99 TABLE 9-2: CC TERMINOLOGY FROM [ESM PP PM].....................................................................................99 TABLE 9-3: PRODUCT-SPECIFIC ACRONYMS AND TERMINOLOGY..................................................................102 Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 7 of 106 CygnaCom Solutions 1 Security Target Introduction This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST conformance claims, and the ST organization. The TOE is the Vormetric Data Security Manager (DSM). The DSM creates, stores, and manages policies that protect data residing on host machines. The DSM allows administrators to manage Transparent Encryption Agents residing on the host machines that contain protected data and to specify data access policies that are sent to these agents. Administrators access the DSM through a browser-based user interface. 1.1 Security Target Reference ST Title: Vormetric Data Security Manager, Version 5.3 Security Target ST Version: v2.3 ST Author: CygnaCom Solutions ST Date: March 20, 2016 1.2 TOE Reference TOE Identification: Vormetric Data Security Manager V6000, Version 5.3 Build 1667 TOE Developer: Vormetric, Inc. Evaluation Sponsor:Vormetric, Inc. 1.3 Conformance Claims This TOE is conformant to the following CC specifications:  Information Technology Security Evaluation Part 2: Security Functional Components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-002  Part 2 Conformant with additional extended functional components as specified by the protection profile.  Information Technology Security Evaluation Part 3: Security Assurance Components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-003  Part 3 Conformant with additional assurance activities as specified by the protection profile  This ST claims strict conformance to the Protection Profile for Enterprise Security Management Policy Management, 24 October 2013, Version 2.1 [ESM PP PM]. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 8 of 106 CygnaCom Solutions  Package claims:  Assurance level: [ESM PP PM]. 1.4 Technical Decisions TD0016: Application of TD0005 and ERRATA2 to WLANASPP for FPT_ITT, FTP_ITC, and FTP_TRP TD0042: Removal of Low-level Crypto Failure Audit from PPs TD0055: Move FTA_TAB.1 to Selection-Based Requirement TD0066: Clarification of FAU_STG_EXT.1 Requirement in ESM PPs TD0071: Use of SHA-512 in ESM PPs Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 9 of 106 CygnaCom Solutions 2 TOE Description 2.1 Product Overview Vormetric® Data Security is a software data protection and encryption system. It provides policy-specified restricted access and encryption for the following types of data repositories:  Files and file systems.  Oracle Database and Microsoft SQL Server Transparent Data Encryption (TDE).  Applications that use a PKCS11 interface.  Other data encryption systems – securely stores inventory of symmetric and asymmetric encryption keys and certificates from any application, and tracks key expiration dates. The active components of Vormetric Data Security are the Vormetric Data Security Manager (DSM1 ), also called the Security Server, and Transparent Encryption Agent residing on the host machines containing data to be protected. Figure 1: Vormetric Data Security Product Note 1: DSM is the only component covered by the evaluation. For Transparent Encryption Agents, the DSM allows administrators to specify data access policies, create new administrators and administrative domains, generate usage reports, register new hosts, access security logs, and perform other management functions. Administrators access the DSM through a browser-based user interface called the Data Security Remote Administrative Management. The DSM is available as a hardened appliance. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 10 of 106 CygnaCom Solutions The Vormetric Transparent Encryption Agents are installed on the host machines that contain the data to be protected. The Transparent Encryption Agents manage and implement the security polices stored on the DSM. 2.2 TOE Overview The TOE is the appliance-based Vormetric Data Security Manager (DSM). The TOE includes all DSM appliance hardware and all software installed on the appliance. The TOE hardware appliance model is V6000. The DSM is the Policy Management product that serves as a trusted source for policy information that is ultimately consumed be the Transparent Encryption Agent (the Access Control product) as defined in [ESM PP PM]. The Transparent Encryption Agent is outside the scope of the ESM PP PM evaluation. The current Transparent Encryption Agent does not meet the definition options identified in ESM PP AC and will therefore not be submitted as a separate evaluation until such a time that the AC definition is updated to allow it into evaluation. This testing conducted in this evaluation will be limited to the Transparent Encryption Agent successfully receiving and loading the policy. The correctness of the enforcement of that policy will not be tested. 2.2.1 Vormetric Data Security Manager (DSM) 2.2.1.1 DSM Software The Vormetric Data Security Manager (DSM) comprises a policy engine and a central key and policy manager, which provides security, performance, and scalability. The policies and keys are defined on the DSM and downloaded to the Transparent Encryption Agent through a secure network connection. The requests are evaluated by using agent-system parameters and administrator-defined policy constraints. Transparent Encryption Agents that run on protected hosts can implement policies set by DSM administrators. TLS authentication is used to encrypt all communications between the agents and DSM. Vormetric Data Security employs X.509 digital certificates for agent/server communication as well as communication to LDAP server and syslog server. The DSM administrator configures policies comprised of sets of security rules that must be satisfied in order to allow or deny access. Each security rule evaluates who, what, when, and how protected data is accessed and, if these criteria match, the policy either permits or denies access. Furthermore, the security rule can be constructed to encrypt data in the Transparent Encryption Agent. If the encryption effect on the security rule is matched, the access control component will perform encryption. The security rules specify:  Data being accessed: Administrators can configure a mix of files and directories by specifying them individually or by using variables. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 11 of 106 CygnaCom Solutions  Applications that are authorized: Administrators can specify which executables and tools are permitted to access data.  The user attempting to access the protected data: Administrators can configure one or more users. Users can be identified by user name, identification number, group, or group number.  When the data is being accessed: Administrators can configure a range of hours and days of the week to allow access.  How the data is being accessed: Administrators can configure a security rule that considers how files and directories, and their attributes, are being accessed. The security rule can note attempts to read, write, delete, rename, create, and more. When the conditions specified in a security rule match, the policy dictates whether to permit or deny access. If encryption is used, the policy can be configured to permit read access but without including the key to decrypt encrypted data. This way the underlying encrypted (unintelligible) data can be backed up. The DSM also provides auditing capabilities. The Transparent Encryption Agent notifies security administrators of policy violations in near real time. The DSM records all context attributes of an access attempt, enabling traceability of host intrusion and data access events at the application and user level, and maintains an extensive log for detailed forensic analysis. In addition, the DSM provides audit logging to monitor all activities and transactions. 2.2.1.2 DSM Hardware The V6000 DSM Appliance is a 1u, rack-mountable chassis. Its dimensions are 17”x20.5”x1.75”. Network connectors, a serial console connector, and IPMI connector are on the back. It comes with two auto-switching, 100-240V power supplies. Power connectors are on the back while the power switch is on the front. There are four storage bays on the front but only two bays are populated with disks. Table 2-1: DSM Appliance Hardware Features Feature Description Hardware Model V6000 Chassis 1U rack-mountable; 17” wide x 20.5” long x1.75” high (43.18 cm x 52.07cm x 4.5 cm) Weight V6000: 21.5 lbs (9.8 kg) Hard Disk Dual SAS RAID 1 configured Serial Port 1; DB-9 RS-232 serial console interface to configure, or log onto, the DSM Appliance. Ethernet 2x1Gb; Ethernet interface used in the Remote Administrative Management to administer the DSM Appliance and Vormetric Agents. Also used to carry policy evaluation information between the DSM and its agents. IPMI 1x10/100Mb; Ethernet interface to configure, or log onto, the DSM Appliance. Power Supplies 2 removable 80+certified (100VAC-240VAC/50-60Hz) 400W Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 12 of 106 CygnaCom Solutions Chassis Intrusion Detection Yes. Maximum BTU 410 BTU max Operating Temperature 10° to 35° C (50° to 95° F) Non-Operating Temperature -40° to 70° C (-40° to 158° F) Operating Relative Humidity 8% to 90% (non-condensing) Non-Operating Relative Humidity 5% to 95% (non-condensing) Safety Agency Approval FCC, UL, and BIS certifications CPU 1 Intel Xeon (6 physical cores) Memory 16GB Status Display There are 4 LEDs indicate power on, network activity, hard disk activity, and system overheat conditions. 2.2.1.3 Remote Administrative Management The DSM includes a Web-based interface, referred to as the “Remote Administrative Management”, which is used to create policies, configure hosts, and assign keys. The Web application provides a secure connection between the DSM and the host administering that DSM. The Remote Administrative Management provides a robust security environment in which administrative control is distributed based upon administrative type. The menus displayed by the Remote Administrative Management and the tasks administrators can perform are dependent upon their administrator type. An administrator is assigned one administrative type and is allowed to perform the tasks for that one administrative type only. A domain is self-contained environment comprised of policies, keys, hosts, users, and audit records. The configuration data that administrators can see is dependent upon the domain in which they are working. The Remote Administrative Management provides fully separated domains, where the work and configuration data in one domain is invisible to administrators in other domains. Note: The DSM also includes a Command Line Interface (CLI). The CLI is used to configure the DSM at the system level. An administrator connects to the CLI via SSH. The CLI is used only for installation of the TOE and off-line maintenance. This connection cannot be used to import or export DSM cryptographic keys, therefore, from a FIPS standpoint, the SSH session can be treated as "equivalent to plaintext". The CLI is not in the scope of the evaluation and is not considered a TSFI. Note: Vormetric has developed a command line interface called VMSSC, which provides a subset of the administrative functions of the Remote Administrative Management. VMSSC is a separate utility that is not part of the TOE distribution and must be installed separately. VMSSC is not included in the scope of the evaluation. 2.2.1.4 Vormetric Agents There are several types of Vormetric agents, Transparent Encryption Agent, Key agent for Oracle and SQL Database, and Application Encryption Agent. Vormetric agents come with different installation packages and are not distributed as a part of DSM. All Vormetric Agents Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 13 of 106 CygnaCom Solutions are installed on the host machines that contain the data to be protected. The Transparent Encryption Agent enables data-at-rest encryption, file access control, and the collection of security intelligence audit logs. The DSM is capable of producing a policy and only the Transparent Encryption Agent can consume and enforce the policy from DSM. The testing conducted in this evaluation will be limited to the Transparent Encryption Agent successfully receiving and loading the policy. The correctness of the enforcement of that policy will not be tested. The Key Agent for Oracle and SQL database centralize the key storage for Oracle and SQL encryption key while the Application Encryption agent provides a framework to deliver application-layer encryption such as column-level encryption in the database. However, the Key Agent for database and Application Encryption Agent can not process policy from DSM. DSM is also capable of registering one external non-Vormetric agent called KMIP client. KMIP client is used to store and retrieve keys from DSM. However, KMIP client is a 3rd party software and Vormetric does not package or ship KMIP client. This feature is not enabled by default. 2.3 Physical Scope of the TOE The physical boundary of the TOE is the Vormetric Data Security Manager (DSM), which includes:  The DSM Appliance hardware  All software installed on the DSM Appliance o Remote Administrative Management Interface Required external access control product components:  One or more Vormetric Transparent Encryption Agents The Operational Environment of the TOE includes:  The web browser that is used for the Remote Administrative Management  The workstation that hosts the Remote Administrative Management web browser  The host platforms for the Vormetric Transparent Encryption Agents  Optional external servers o NTP Server (use of an external NTP Server is highly recommended) o SMTP Server o The DNS server that provides host name resolution service o LDAP Authentication Server o Syslog Server for external storage of the audit log o RSA Authentication Manager and an RSA SecurID device for each administrator o External Certificate Authority (CA) The TOE Boundary is depicted in the following figure: Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 14 of 106 CygnaCom Solutions 1 U Management workstation Servers with Vormetric Agents LDAP server Network switch Vormetric Data Security Manager TOE Syslog server Internet firewall HTTPS/TLS TLS TLS SNMP server NTP server DNS server TLS TLS Router Management workstation Local CLI IPMI Eth0, Eth1 Serial Management Data Figure 2: TOE Boundary 2.4 Protocols and Services Excluded from evaluation 1. The CLI should be only used for initial configuration and off-line maintenance. 2. CLI over SSH is not evaluated and must be disabled. 3. VMSSC (An external Vormetric command line tool for administering the DSM) - VMSSC is a separate utility that is not part of the TOE distribution and must be installed separately. VMSSC is not included in the scope of the evaluation. 4. Transparent Encryption Agent – This is an external agent that is not a part of TOE distribution. The scope of testing is limited to the Transparent Encryption Agent successfully receiving and loading the policy. 5. SNMP service – Use of the SNMPv1 and SNMPv2 functionality is excluded and it is disabled by default. The use of SNMPv3 with read-only community strings is not restricted in the evaluated configuration; however, it is not evaluated. 6. IPMI – This service offers the same TOE off-line maintenance capability as CLI. IPMI can not be used to import or export DSM cryptographic keys. IPMI service should be disabled. 7. Failover DSM – Failover is not restricted in the evaluated configuration; however, it is not evaluated. Failover configuration is disabled by default and this interface uses Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 15 of 106 CygnaCom Solutions standard database data replication method. The database replication does not transmit plaintext data. 8. Auto-backup via SCP and CIFS are not evaluated. 9. Application Encryption Agent – This is an external agent that is not a part of the TOE distribution. This agent is not evaluated. 10. Key Agents for SQL and Oracle Database – These are external agents that are not a part of the TOE distribution. These two agents are not evaluated. 11. KMIP client – This is an external client that is not a part of the TOE distribution. This client is not evaluated. 12. Email notification – email notification is disabled by default. SMTP is not evaluated. 13. Optional RSA Authentication Manager is not evaluated. 14. Optional External Certificate Authority is not evaluated. 2.5 Logical Scope of the TOE The TOE provides the security functionality described in the following subsections. 2.5.1 System Monitoring The TOE provides the ability to generate audit events In order to identify unauthorized TOE configuration changes and attempted malicious activity against protected objects. The audit trail identifies changes to subject data and usage of the authentication function. The audit data can be stored in an external repository 2.5.2 Robust TOE Access The TOE implements mechanisms via a configurable password policy that improve security relative to the attempts of unsophisticated attackers to authenticate to the TOE using repeated guesses. The TOE can also enforce an externally-defined LDAP authentication policy. The TOE provides capabilities to terminate established sessions. 2.5.3 Authorized Management Policy Administrators are designated by the TSF and given various responsibilities for managing the TOE and creating policies. The TSF has its own internal method of enforcing controlled access so that no actions can be performed against it unless the subject is identified, authenticated, and authorized. 2.5.4 Policy Definition The TSF is able to manage policy attributes that are consistent with the corresponding technology type(s) described in the User Data Protection requirements in the Standard Protection Profile for Enterprise Security Management Access Control. In addition, the TSF is able to detect or prevent inconsistencies in the application of policies so that policies are unambiguously defined. Finally, the TOE is able to identify uniquely policies it creates so that it can be used to determine what policies are being implemented by remote products. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 16 of 106 CygnaCom Solutions 2.5.5 Dependent Product Configuration The TOE is able to configure the behavior of the functions of the Access Control products that consume the policies it provides. This includes the configuration of what events they audit, what policies they enforce, and how they react in the event of a failure state or lack of connectivity. 2.5.6 Confidential Communications The TOE uses sufficiently strong and sufficiently trusted encryption algorithms to protect data in transit to and from the TOE. The TOE implements cryptographic protocol to protect these data in transit. 2.5.7 Access Bannering The TOE displays a banner prior to authentication that defines its acceptable use. This banner provides legal notification for monitoring that allows audit data to be admissible in the event of any legal investigations. 2.5.8 Cryptographic Services The TOE uses cryptographic primitives (encryption, decryption, random bit generation, etc.) in order to ensure the confidentiality and integrity of the policy data it transmits and to provide trusted communications between itself and the Operational Environment where necessary. 2.6 TOE Guidance The following user guidance document is provided to customers and is considered part of the TOE:  Vormetric Data Security Manager (DSM) Common Criteria Addendum, Version 1.0, February 10, 2016 The documents in the following table were used as reference materials to develop this ST. Table 2-2: ST Reference Documents Reference Title ID Common Criteria for Information Technology Security Evaluation, CCMB-2009-07- 002, Version 3.1, Revision 4 [CC] Standard Protection Profile for Enterprise Security Management Policy Management, Version 2.1, 24 October 2013 [ESM PM PP] Data Security Manager (DSM) Common Criteria Addendum, Version 1.0, February 10, 2016 [ADDEND] Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 17 of 106 CygnaCom Solutions 3 Security Problem Definition The U.S. Government Enterprise Security Management Policy Management Protection Profile, [ESM PP PM] provides the following policies, threats and assumptions about the TOE. 3.1 Threats This section identifies the threats applicable to the U.S. Government Enterprise Security Management Policy Management Protection Profile, [ESM PP PM] as specified in the Protection Profile, verbatim. Table 3-1: TOE Threats Threat Name Threat Definition T.ADMIN_ERROR An administrator may unintentionally install or configure the TOE incorrectly, resulting in ineffective security mechanisms. T.CONDTRADICT A careless administrator may create a policy that contains contradictory rules for access control enforcement. T.EAVES A malicious user could eavesdrop on network traffic to gain unauthorized access to TOE data. T.FORGE A malicious user may exploit a weak or nonexistent ability for the TOE to provide proof of its own identity in order to send forged policies to an Access Control product. T.MASK A malicious user may attempt to mask their actions, causing audit data to be incorrectly recorded or never recorded. T.UNAUTH A malicious user could bypass the TOE’s identification, authentication, or authorization mechanisms in order to illicitly use the TOE’s management functions. T.WEAKIA A malicious user could be illicitly authenticated by the TSF through brute- force guessing of authentication credentials. T.WEAKPOL A Policy Administrator may be incapable of using the TOE to define policies in sufficient detail to facilitate robust access control, causing an Access Control product to behave in a manner that allows illegitimate activity or prohibits legitimate activity. 3.2 Organizational Security Policies (OSPs) This section identifies the organizational security policies applicable to the Standard Protection Profile for Enterprise Security Management Policy Management [ESM PP PM] as specified in the Protection Profile, verbatim. Table 3-2: Organizational Security Policies Policy Name Policy Definition P.BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by accessing the system. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 18 of 106 CygnaCom Solutions 3.3 Assumptions This section identifies assumptions applicable to the Standard Protection Profile for Enterprise Security Management Policy Management [ESM PP PM] as specified in the Protection Profile, verbatim. Table 3-3: Connectivity Assumptions Assumption Name Assumption Definition A.ESM The TOE will be able to establish connectivity to other ESM products in order to share security data. A.ROBUST The Operational Environment will provide mechanisms to the TOE that reduce the ability for an attacker to impersonate a legitimate user during authentication. A.SYSTIME The TOE will receive reliable time data from the Operational Environment. A.USERID The TOE will receive identity data from the Operational Environment. Table 3-4: Personnel Assumptions Assumption Name Assumption Definition A.MANAGE There will be one or more competent individuals assigned to install, configure, and operate the TOE. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 19 of 106 CygnaCom Solutions 4 Security Objectives This section defines the security objectives of the TOE and its supporting environment. 4.1 Security Objectives for the TOE This section identifies Security Objectives for the TOE applicable to the Standard Protection Profile for Enterprise Security Management Policy Management [ESM PP PM], verbatim. Table 4-1: TOE Security Objectives Objective TOE Security Objective Definition O.ACCESSID The TOE will contain the ability to validate the identity of other ESM products prior to distributing data to them. O.AUDIT The TOE will provide measures for generating and recording security relevant events that will detect access attempts to TOE-protected resources by users. O.AUTH The TOE will provide a mechanism to securely validate requested authentication attempts and to determine the extent to which any validated subject is able to interact with the TSF. O.BANNER The TOE will display an advisory warning regarding use of the TOE. O.CONSISTENT The TSF will provide a mechanism to identify and rectify contradictory policy data. O.CRYPTO The TOE will provide cryptographic primitives that can be used to provide services such as ensuring the confidentiality and integrity of communications. O.DISTRIB The TOE will provide the ability to distribute policies to trusted IT products using secure channels. O.INTEGRITY The TOE will contain the ability to assert the integrity of policy data. O.MANAGE The TOE will provide the ability to manage the behavior of trusted IT products using secure channels. O.POLICY The TOE will provide the ability to generate policies that are sufficiently detailed to satisfy the Data Protection requirements for one or more technology types in the Standard Protection Profile for Enterprise Security Management Access Control. O.PROTCOMMS The TOE will provide protected communication channels or administrators, other parts of a distributed TOE, and authorized IT entities. O.ROBUST The TOE will provide mechanisms to reduce the ability for an attacker to impersonate a legitimate user during authentication. O.SELFID The TOE will be able to confirm its identity to the ESM deployment upon sending data to other processes within the ESM deployment. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 20 of 106 CygnaCom Solutions 4.2 Security Objectives for the Operational Environment This section identifies operational environment security objectives applicable to the Standard Protection Profile for Enterprise Security Management Policy Management [ESM PP PM] as specified in the Protection Profile, verbatim. Table 4-2: Security Objectives for the Operational Environment Objective Environmental Security Objective Definition OE.ADMIN There will be one or more administrators of the Operational Environment that will be responsible for managing the TOE. OE.INSTALL Those responsible for the TOE shall ensure that the TOE is delivered, installed, managed, and operated in a secure manner. OE.PERSON Personnel working as TOE administrators shall be carefully selected and trained for proper operation of the TOE. OE.PROTECT One or more ESM Access Control products will be deployed in the Operational Environment to protect organizational assets. OE.ROBUST The Operational Environment will provide mechanisms to reduce the ability for an attacker to impersonate a legitimate user during authentication. OE.SYSTIME The Operational Environment will provide reliable time data to the TOE. OE.USERID The Operational Environment shall be able to identify a user requesting access to the TOE. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 21 of 106 CygnaCom Solutions 5 Extended Components Definition The components listed in the following table have been defined in the Standard Protection Profile for Enterprise Security Management Policy Management [ESM PP PM]. The true extended components are denoted by adding “_EXT” in the component name. [ESM PP PM] also defines new requirements, which are considered extended components that are prefixed with “ESM”. Table 5-1: Extended Components Item SFR ID SFR Title 1 ESM_ACD.1 Access Control Policy Definition 2 ESM_ACT.1 Access Control Policy Transmission 3 ESM_ATD.1 Object Attribute Definition 4 ESM_ATD.2 Subject Attribute Definition 5 ESM_EAU.2 Reliance on Enterprise Authentication 6 ESM_EID.2 Reliance on Enterprise Identification 7 FAU_SEL_EXT.1 External Selective Audit 8 FAU_STG_EXT.1 External Audit Trail Storage 9 FCS_CKM_EXT.4 Cryptographic Key Zeroization 10 FCS_HTTPS_EXT.1 HTTPS 12 FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation) 14 FCS_TLS_EXT.1 TLS 15 FMT_MOF_EXT.1 External Management of Functions Behavior 16 FMT_MSA_EXT.5 Consistent Security Attributes 17 FPT_APW_EXT.1 Protection of Stored Credentials 18 FPT_SKP_EXT.1 Protection of Secret Key Parameters 19 FTA_SSL_EXT.1 TSF-initiated Session Locking Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 22 of 106 CygnaCom Solutions 6 Security Requirements 6.1 Security Functional Requirements Conventions The following conventions have been applied in this document:  Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be applied to functional requirements: iteration, assignment, selection, and refinement. o Iteration: allows a component to be used more than once with varying operations. In the ST, iteration is indicated by a letter in parenthesis placed at the end of the component. For example FDP_ACC.1 (a) and FDP_ACC.1 (b) indicate that the ST includes two iterations of the FDP_ACC.1 requirement, “a” and “b”. o Assignment: allows the specification of an identified parameter. Assignments are indicated using bold italics and are surrounded by brackets (e.g., [assignment]). o Selection: allows the specification of one or more elements from a list. Selections are indicated using bold italics and are surrounded by brackets (e.g., [selection]). o Refinement: are identified with "Refinement:" right after the short name. Additions to the CC text are specified in italicized bold and underlined text. Note: Operations already performed in the [ESM PP PM] are not identified in this Security Target  Application notes provide additional information for the reader, but do not specify requirements. Application notes are denoted by italicized text.  Explicitly stated Security Functional Requirements (i.e., those not found in Part 2 of the CC) are identified “_EXT” or “ESM” in the component name.)  Case - [ESM PP PM] uses an additional convention which defines parts of an SFR that apply only when corresponding selections are made or some other identified conditions exist. Only the applicable cases are identified in this ST. The TOE security functional requirements are listed in Table 6-1. All SFRs are based on requirements defined in Part 2 of the Common Criteria or defined in the Standard Protection Profile for Enterprise Security Management Policy Management [ESM PP PM]. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 23 of 106 CygnaCom Solutions Table 6-1: TOE Security Functional Components Functional Component 1 1 ESM_ACD.1 Access Control Policy Definition 2 2 ESM_ACT.1 Access Control Policy Transmission 3 3 ESM_ATD.1 Object Attribute Definition 4 4 ESM_ATD.2 Subject Attribute Definition 5 5 ESM_EAU.2 (1) Reliance on Enterprise Authentication (Password authentication) 6 6 ESM_EID.2 (1) Reliance on Enterprise Identification (Password authentication) 7 7 ESM_EAU.2 (2) Reliance on Enterprise Authentication (LDAP authentication) 8 8 ESM_EID.2 (2) Reliance on Enterprise Identification (LDAP authentication) 9 1 FAU_GEN.1 Audit Data Generation 10 1 FAU_SEL.1 Selectable Audit 11 1 FAU_SEL_EXT.1 External Selective Audit 12 1 FAU_STG_EXT.1 External Audit Trail Storage 13 1 FCS_CKM.1 Cryptographic Key Generation (for Asymmetric Keys) 14 1 FCS_CKM_EXT.4 Cryptographic Key Zeroization 15 1 FCS_COP.1 (1) Cryptographic Operation (for Data Encryption/Decryption) 16 1 FCS_COP.1 (2) Cryptographic Operation (for Cryptographic Signature) 17 1 FCS_COP.1 (3) Cryptographic Operation (for Cryptographic Hashing) 18 2 FCS_COP.1 (4) Cryptographic Operation (for Keyed-Hash Message Authentication) 19 2 FCS_HTTPS_EXT.1 HTTPS 20 2 FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation) 21 2 FCS_TLS_EXT.1 TLS 22 2 FIA_AFL.1 Authentication Failure Handling 23 2 FIA_SOS.1 Verification of Secrets 24 2 FIA_USB.1 User-Subject Binding 25 2 FMT_MOF.1 Management of Functions Behavior 26 2 FMT_MOF_EXT.1 External Management of Functions Behavior 27 2 FMT_MSA_EXT.5 Consistent Security Attributes 28 3 FMT_MTD.1 Management of TSF Data 29 3 FMT_SMF.1 Specification of Management Functions 30 3 FMT_SMR.1 Security Management Roles 31 3 FPT_APW_EXT.1 Protection of Stored Credentials 32 3 FPT_SKP_EXT.1 Protection of Secret Key Parameters 33 3 FPT_STM.1 Reliable Time Stamps 34 3 FTA_SSL_EXT.1 TSF-initiated Session Locking 35 3 FTA_SSL.3 TSF-initiated Termination 36 3 FTA_SSL.4 User-initiated Termination 37 3 FTA_TAB.1 TOE Access Banner 38 4 FTP_ITC.1 Inter-TSF Trusted Channel 39 4 FTP_TRP.1 Trusted Path 6.1.1 Class ESM: Enterprise Security Management 6.1.1.1 ESM_ACD.1 Access Control Policy Definition ESM_ACD.1.1 The TSF shall provide the ability to define access control policies for consumption by one or more compatible Access Control products. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 24 of 106 CygnaCom Solutions ESM_ACD.1.2 Access control policies defined by the TSF shall be capable of containing the following: Subjects: [Process accessing GuardPoint] and Objects: [resource set, user set, process set, time set]; and Operations: [create file, read file, write file, remove file, rename file, read file attribute, change file attribute, create directory, read directory, rename directory, remove directory, read directory attribute, change directory attribute, read file security attribute, change file security attribute, read directory security attribute, change directory security attribute]; and Attributes: [File name or path (resource set) User or group (user set) Process hashed values (process set) Time or day (time set)] ESM_ACD.1.3 The TSF shall associate unique identifying information with each policy. 6.1.1.2 ESM_ACT.1 Access Control Policy Transmission ESM_ACT.1.1 The TSF shall transmit policies to compatible and authorized Access Control products under the following circumstances: [immediately following creation of a new or updated policy, [upon startup of the authorized Access Control product]]. 6.1.1.3 ESM_ATD.1 Object Attribute Definition ESM_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual objects: [ Object: Resource Set Attribute: directory path and/or file name Object: User Set Attribute: user name, user id, group name or group id Object: Process Set Attribute: hashed value of trusted process binaries Object: Time Set Attribute: time and/or day ]. ESM_ATD.1.2 The TSF shall be able to associate security attributes with individual objects. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 25 of 106 CygnaCom Solutions 6.1.1.4 ESM_ATD.2 Subject Attribute Definition ESM_ATD.2.1 The TSF shall maintain the following list of security attributes belonging to individual subjects: [full path directory location on network host where the Transparent Encryption Agent is installed]. ESM_ATD.2.2 The TSF shall be able to associate security attributes with individual subjects. 6.1.1.5 ESM_EAU.2 (1) Reliance on Enterprise Authentication (Password authentication) ESM_EAU.2.1 (1) The TSF shall rely on [Vormetric Data Security Manager] for subject authentication. ESM_EAU.2.2 (1) The TSF shall require each subject to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that subject. 6.1.1.6 ESM_EID.2 (1) Reliance on Enterprise Identification (Password authentication) ESM_EID.2.1 (1) The TSF shall rely on [Vormetric Data Security Manager] for subject identification. ESM_EID.2.2 (1) The TSF shall require each subject to be successfully identified before allowing any other TSF-mediated actions on behalf of that subject. 6.1.1.7 ESM_EAU.2 (2) Reliance on Enterprise Authentication (LDAP authentication) ESM_EAU.2.1 (2) The TSF shall rely on [LDAP Authentication Server] for subject authentication. ESM_EAU.2.2 (2) The TSF shall require each subject to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that subject. 6.1.1.8 ESM_EID.2 (2) Reliance on Enterprise Identification (LDAP authentication) ESM_EID.2.1 (2) The TSF shall rely on [LDAP Authentication Server] for subject identification. ESM_EID.2.2 (2) The TSF shall require each subject to be successfully identified before allowing any other TSF-mediated actions on behalf of that subject. 6.1.2 Class FAU: Security Audit 6.1.2.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: a) Start-up and shutdown of the audit functions; and Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 26 of 106 CygnaCom Solutions b) All auditable events identified in Table 3 for the not specified level of audit; and c) [no other auditable events]. Table 6-2: Auditable Events ([ESM PP PM] Table 3.) Component Event Additional Information ESM_ACD.1 Creation or modification of policy Unique policy identifier ESM_ACT.1 Transmission of policy to Access Control products Destination of policy ESM_ATD.1 Definition of object attributes Identification of the attribute defined ESM_ATD.1 Association of attributes with objects Identification of the object and the attribute ESM_ATD.2 Definition of subject attributes Identification of the attribute defined ESM_ATD.2 Association of attributes with subjects None ESM_EAU.2 (1) All use of the authentication mechanism None ESM_EAU.2 (2) All use of the authentication mechanism None ESM_EAU.2 (3) All use of the authentication mechanism None FAU_SEL_EXT.1 All modifications to audit configuration None FAU_STG_EXT.1 Establishment and disestablishment of communications with audit server Identification of audit server FCS_CKM.1 Failure of the key generation activity None FCS_CKM_EXT.4 Failure of the key zeroization process Identity of subject requesting or causing zeroization, identity of object or entity being cleared FCS_COP.1 (1) Failure of encryption or decryption Cryptographic mode of operation, name/identifier of object being encrypted/decrypted FCS_COP.1 (2) Failure of cryptographic signature Cryptographic mode of operation, name/identifier of object being signed/verified FCS_COP.1 (3) Failure of hashing function Cryptographic mode of operation, name/identifier of object being hashed FCS_COP.1 (4) Failure in cryptographic hashing for non-data integrity Cryptographic mode of operation, name/identifier of object being hashed FCS_HTTPS_EXT.1 Failure to establish a session, establishment/termination of a session Non-TOE endpoint of connection (IP address), reason for failure (if applicable) FCS_RBG_EXT.1 Failure of the randomization process None FCS_TLS_EXT.1 Failure to establish a session, establishment/termination of a session Non-TOE endpoint of connection (IP address), reason for failure (if applicable) FIA_AFL.1 The reaching of an unsuccessful authentication attempt threshold, the actions taken when the threshold is reached, and any actions taken to restore the normal state Action taken when threshold is reached Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 27 of 106 CygnaCom Solutions Component Event Additional Information FIA_SOS.1 Rejection or acceptance by the TSF of any tested secret None FIA_SOS.1 Identification of any changes to the defined quality metrics The change made to the quality metric FMT_SMF.1 Use of the management functions Management function performed FMT_SMR.1 Modifications to the members of the management roles None FTA_SSL_EXT.1 All session locking and unlocking events None FTA_SSL.3 All session termination events None FTA_SSL.4 All session termination events None FTP_ITC.1 All use of trusted channel functions Identity of the initiator and target of the trusted channel FTP_TRP.1 All attempted uses of the trusted path functions Identification of user associated with all trusted path functions, if available FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity (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, [message ID, the additional information identified in Table 3]. 6.1.2.2 FAU_SEL.1 Selective Audit FAU_SEL.1.1 Refinement: The TSF shall be able to select the set of events to be audited from the set of all auditable events from [local definition] based on the following attributes: a) [severity level]; and b) [no additional attributes] 6.1.2.3 FAU_SEL_EXT.1 External Selective Audit FAU_SEL_EXT.1.1 The TSF shall be able to select the set of events to be audited by an ESM Access Control product from the set of all auditable events based on the following attributes: a) [severity level]; and b) [upload to server checkbox]. 6.1.2.4 FAU_STG_EXT.1 External Audit Trail Storage FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to [external syslog using TLS]. FAU_STG_EXT.1.2 The TSF shall ensure that transmission of generated audit data to any Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 28 of 106 CygnaCom Solutions external IT entity uses a trusted channel defined in FTP_ITC.1. FAU_STG_EXT.1.3 The TSF shall ensure that any TOE-internal storage of generated audit data: a) protects the stored audit records in the TOE-internal audit trail from unauthorized deletion; and b) prevents unauthorized modifications to the stored audit records in the TOE-internal audit trail. 6.1.3 Class FCS: Cryptographic Support 6.1.3.1 FCS_CKM.1 Cryptographic Key Generation (for Asymmetric Keys) FCS_CKM.1.1 Refinement: The TSF shall generate asymmetric cryptographic keys used for key establishment in accordance with: [  NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography” for RSA-based key establishment schemes  NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” for elliptic curve-based key establishment schemes and implementing “NIST curves” P-256, P-384 and [no other curves] (as defined in FIPS PUB 186-4, “Digital Signature Standard”) ] and specified cryptographic key sizes equivalent to, or greater than, 112 bits of security that meet the following: standards defined in first selection. 6.1.3.2 FCS_CKM_EXT.4 Cryptographic Key Zeroization FCS_CKM_EXT.4.1 The TSF shall zeroize all plaintext secret and private cryptographic keys and cryptographic security parameters when no longer required. 6.1.3.3 FCS_COP.1 (1) Cryptographic Operation (for Data Encryption/Decryption) FCS_COP.1.1 (1) Refinement: The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm AES operating in [CBC] and cryptographic key sizes 128-bits, 256-bits, and [no other key sizes] that meets the following:  FIPS PUB 197, “Advanced Encryption Standard (AES)”  [NIST SP 800-38A] 6.1.3.4 FCS_COP.1 (2) Cryptographic Operation (for Cryptographic Signature) FCS_COP.1.1 (2) Refinement: The TSF shall perform cryptographic signature services in Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 29 of 106 CygnaCom Solutions accordance with a [ (2) RSA Digital Signature Algorithm (rDSA) with a key size (modulus) of 2048 bits or greater (3) Elliptic Curve Digital Signature Algorithm (ECDSA) with a key size of 256 bits or greater ] that meets the following: Case: RSA Digital Signature Algorithm o FIPS PUB 186-4, “Digital Signature Standard”; Case: Elliptic Curve Digital Signature Algorithm o FIPS PUB 186-4, “Digital Signature Standard”; 6.1.3.5 FCS_COP.1 (3) Cryptographic Operation (for Cryptographic Hashing) FCS_COP.1.1 (3) Refinement: The TSF shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] and message digest sizes [160, 256, 384, 512] bits that meet the following: FIPS Pub 180-4, “Secure Hash Standard.” 6.1.3.6 FCS_COP.1 (4) Cryptographic Operation (for Keyed-Hash Message Authentication) FCS_COP.1.1 (4) Refinement: The TSF shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm HMAC-[SHA-1, SHA-256, SHA-384], key size [256, 256, 384 key size (in bits) used in HMAC], and message digest sizes [160, 256, 384] bits that meet the following: FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code”, and FIPS Pub 180-4, “Secure Hash Standard.” 6.1.3.7 FCS_HTTPS_EXT.1 HTTPS FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818. FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS using TLS as specified in FCS_TLS_EXT.1 6.1.3.8 FCS_RBG_EXT.1 Cryptographic Operation (Random Bit Generation) FCS_RBG_EXT.1.1 The TSF shall perform all random bit generation (RBG) services in accordance with [NIST Special Publication 800-90A using [CTR_DRBG (AES)]] seeded by an entropy source that accumulates entropy from Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 30 of 106 CygnaCom Solutions [ (3) a combination of hardware-based and software-based noise sources. ]. FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded with a minimum of [256 bits] of entropy at least equal to the greatest security strength of the keys and hashes that it will generate. 6.1.3.9 FCS_TLS_EXT.1 TLS FCS_TLS_EXT.1.1 The TSF shall implement one or more of the following protocols [TLS 1.0 (RFC 2246), TLS 1.1(RFC 4346) ,TLS 1.2 (RFC 5246)] supporting the following ciphersuites: Mandatory Ciphersuites: TLS_RSA_WITH_AES_128_CBC_SHA Optional Ciphersuites: [TLS_RSA_WITH_AES_256_CBC_SHA]. [[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256] [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384] 6.1.4 Class FIA: Identification and Authentication 6.1.4.1 FIA_AFL.1 Authentication Failure Handling FIA_AFL.1.1 The TSF shall detect when [an administrator configurable positive integer within [1 to 10]] unsuccessful authentication attempts occur related to [remote administrative management login]. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been [met], the TSF shall [lock the account for an administrator configurable period of time]. 6.1.4.2 FIA_SOS.1 Verification of Secrets FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet the following: a) For environmental password-based authentication, the following rules apply: 1. Passwords shall be able to be composed of a subset of the following character sets: [Standard ASCII character set] that include the following values [alphabet characters: a-z, A-Z, integers: 0-9, and a limited set of special characters: !@#$%^&*(){}[] ]; and 2. Minimum password length shall settable by an administrator, and support passwords of 16 characters or greater; and 3. Password composition rules specifying the types and numbers of required characters that comprise the password shall be settable by an administrator; and Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 31 of 106 CygnaCom Solutions 4. Passwords shall have a maximum lifetime, configurable by an administrator; and 5. New passwords shall contain a minimum of an administrator-specified number of character changes from the previous password; and 6. Passwords shall not be reused within the last administrator-settable number of passwords used by that user; b) For non-password-based authentication, the following rules apply: 1. The probability that a secret can be obtained by an attacker during the lifetime of the secret is less than 2-20 . 6.1.4.3 FIA_USB.1 User-Subject Binding FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: [  Username  Password  Role  Domain ] FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: [user security attributes are associated upon successful identification and authentication]. FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: [user security attributes can be changed only by an administrator with type “System Administrator” or “All” through the management interfaces of the TOE]. 6.1.5 Class FMT: Security Management 6.1.5.1 FMT_MOF.1 Management of Functions Behavior FMT_MOF.1 The TSF shall restrict the ability to [determine the behavior of, modify the behavior of] the functions: [DSM auditing functions] to [administrators with type “System Administrator” or “All”]. 6.1.5.2 FMT_MOF_EXT.1 External Management of Functions Behavior FMT_MOF_EXT.1.1 The TSF shall restrict the ability to query the behavior of, modify the functions of Access Control products: audited events, repository for audit storage, Access Control SFP, policy version being implemented, Access Control SFP behavior to enforce in the event of communications Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 32 of 106 CygnaCom Solutions outage to [administrators with type “Security Administrator”, “Domain and Security Administrator”, or “All” inside a given domain]. 6.1.5.3 FMT_MSA_EXT.5 Consistent Security Attributes FMT_MSA_EXT.5.1 The TSF shall [identify the following internal inconsistencies with a policy prior to distribution: Rule A: When a newly added or updated security rule is identical to an existing security rule, Rule B: when two security rules have identical security objects but the effects are contradictory (one security rule with permit effect while the other rule has deny effect), Rule C: When a security rule is a superset of subsequent security rule, then the subsequent security rule will not get executed]. FMT_MSA_EXT.5.2 The TSF shall take the following action when an inconsistency is detected: [issue a prompt for an administrator to manually resolve the inconsistency]. 6.1.5.4 FMT_MTD.1 Management of TSF Data FMT_MTD.1.1 The TSF shall restrict the ability to [modify, delete, [add]] the [authentication data: username and password] to [administrators with type “System Administrator” or “All”]. 6.1.5.5 FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [the management activities listed in Table 6-3]. Table 6-3: Management Functions within the TOE ([ESM PP PM] Table 4.) Requirement Management Activities ESM_ACD.1 Creation of policies ESM_ACT.1 Transmission of policies ESM_ATD.1 Definition of object attributes Association of attributes with objects ESM_ATD.2 Definition of subject attributes Association of attributes with subjects ESM_EAU.2 Management of authentication data for both interactive users and authorized IT entities (if managed by the TSF) ESM_EID.2 Management of authentication data for both interactive users and authorized IT entities (if managed by the TSF) FAU_SEL.1 Configuration of auditable events FAU_SEL_EXT.1 Configuration of auditable events for defined external entities FAU_STG_EXT.1 Configuration of external audit storage location FIA_AFL.1 Configuration of authentication failure threshold value Configuration of actions to take when threshold is reached Execution of restoration to normal state following threshold action (if applicable) FIA_SOS.1 Management of the metric used to verify secrets Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 33 of 106 CygnaCom Solutions FIA_USB.1 Definition of default subject security attributes, modification of subject security attributes FMT_MOF_EXT.1 Configuration of the behavior of other ESM products FMT_MSA_EXT.5 Configuration of what policy inconsistencies the TSF shall identify and how the TSF shall respond if any inconsistencies are detected (if applicable) FMT_MTD.1 Management of user authentication data FMT_SMR.1 Management of the users that belong to a particular role FTA_TAB.1 Maintenance of the banner FTP_ITC.1 Configuration of actions that require trusted channel (if applicable) FTP_TRP.1 Configuration of actions that require trusted path (if applicable) 6.1.5.6 FMT_SMR.1 Security Management Roles FMT_SMR.1.1 The TSF shall maintain the roles [“System Administrator”, “Domain Administrator”, “Security Administrator”, “Domain and Security Administrator”, “All”]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. 6.1.6 Class FPT: Protection of the TSF 6.1.6.1 FPT_APW_EXT.1 Protection of Stored Credentials FPT_APW_EXT.1.1 The TSF shall store credentials in non-plaintext form. [Passwords are protected and store as SHA-256 hash and salted] FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext credentials. 6.1.6.2 FPT_SKP_EXT.1 Protection of Secret Key Parameters FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys. 6.1.6.3 FPT_STM.1 Reliable Time Stamps FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use. 6.1.7 Class FTA: TOE Access 6.1.7.1 FTA_SSL_EXT.1 TSF-initiated Session Locking FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [terminate the session] after an Authorized Administrator specified time period of inactivity. 6.1.7.2 FTA_SSL.3 TSF-initiated Termination FTA_SSL.3.1 Refinement: The TSF shall terminate a remote interactive session after an Authorized Administrator-configurable time interval of session inactivity. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 34 of 106 CygnaCom Solutions 6.1.7.3 FTA_SSL.4 User-initiated Termination FTA_SSL.4.1 Refinement: The TSF shall allow Administrator-initiated termination of the Administrator’s own interactive session. 6.1.7.4 FTA_TAB.1 TOE Access Banner FTA_TAB.1.1 Refinement: Before establishing a user session, the TSF shall display a configurable advisory warning message regarding unauthorized use of the TOE. 6.1.8 Class FTP: Trusted Paths/Channels 6.1.8.1 FTP_ITC.1 Inter-TSF Trusted Channel FTP_ITC.1.1 Refinement: The TSF shall use [TLS] to provide a trusted communication channel between itself and authorized IT entities that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification and disclosure. [The communication is protected with use of TLS]. FTP_ITC.1.2 The TSF shall permit [the TSF, LDAP Authentication Server, Syslog Server] to initiate communication via the trusted channel. FTP_ITC.1.3 Refinement: The TSF shall initiate communication via the trusted channel for transfer of policy data, [transfer of encryption keys, directory information services through LDAP, transmitting syslog messages]. 6.1.8.2 FTP_TRP.1 Trusted Path FTP_TRP.1.1 Refinement: The TSF shall use [TLS/HTTPS] to provide a trusted communication path between itself and remote users that is logically distinct from other communication channels and provides assured identification of its end points and protection of the communicated data from modification, disclosure. FTP_TRP.1.2 The TSF shall permit remote users to initiate communication via the trusted path. FTP_TRP.1.3 Refinement: The TSF shall require the use of the trusted path for initial user authentication, execution of management functions. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 35 of 106 CygnaCom Solutions 6.2 Security Assurance Requirements for the TOE 6.2.1 TOE Security Assurance Requirements This section defines the assurance requirements for the TOE. The assurance activities to be performed by the evaluator are defined in Sections 6 and Appendix C of the Standard Protection Profile for Enterprise Security Management Policy Management dated [ESM PM PP]. The [ESM PM PP] draws from the CC Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing. The TOE security assurance requirements, summarized in the table below, identify the management and evaluative activities required to address the threats identified in [ESM PM PP]. Table 6-4: [ESM PM PP] Assurance Components Assurance Class Assurance Components Development ADV_FSP.1 Basic Functional Specification Guidance documents AGD_OPE.1 Operational User guidance AGD_PRE.1 Preparative User guidance Life cycle support ALC_CMC.1 Labeling of the TOE ALC_CMS.1 TOE CM coverage Tests ATE_IND.1 Independent testing - conformance Vulnerability assessment AVA_VAN.1 Vulnerability analysis The following tables state the developer action elements, content and presentation elements and evaluator action elements for each of the assurance components. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 36 of 106 CygnaCom Solutions Table 6-5: ADV_FSP.1 Basic Functional Specification Developer action elements ADV_FSP.1.1D The developer shall provide a functional specification. ADV_FSP.1.2D The developer shall provide a tracing from the functional specification to the SFRs. Content and presentation elements ADV_FSP.1.1C The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.2C The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.3C The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering. ADV_FSP.1.4C The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. Evaluator action elements ADV_ FSP.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_ FSP.1.2E The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. Table 6-6: AGD_OPE.1 Operational User Guidance Developer action elements AGD_OPE.1.1D The developer shall provide operational user guidance. Content and presentation elements AGD_OPE.1.1C The operational user guidance shall describe, for each user role, the user- accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. AGD_OPE.1.2C The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner. AGD_OPE.1.3C The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. AGD_OPE.1.4C The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. AGD_OPE.1.5C The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences, and implications for maintaining secure operation. AGD_OPE.1.6C The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST. AGD_OPE.1.7C The operational user guidance shall be clear and reasonable. Evaluator action elements AGD_OPE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 37 of 106 CygnaCom Solutions Table 6-7: AGD_PRE.1 Preparative Procedures Developer action elements AGD_PRE.1.1D The developer shall provide the TOE, including its preparative procedures. Content and presentation elements AGD_ PRE.1.1C The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. AGD_ PRE.1.2C The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST. Evaluator action elements AGD_ PRE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AGD_ PRE.1.2E The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation. Table 6-8: ALC_CMC.1 Labeling of the TOE Developer action elements ALC_CMC.1.1D The developer shall provide the TOE and a reference for the TOE. Content and presentation elements ALC_CMC.1.1C The TOE shall be labeled with its unique reference. Evaluator action elements ALC_CMC.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Table 6-9: ALC_CMS.1 TOE CM Coverage Developer action elements ALC_CMS.1.1D The developer shall provide a configuration list for the TOE. Content and presentation elements ALC_CMS.1.1C The configuration list shall include the following: the TOE itself; and the evaluation evidence required by the SARs. ALC_CMS.1.2C The configuration list shall uniquely identify the configuration items. Evaluator action elements ALC_CMS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Table 6-10: ATE_IND.1 Independent Testing – Conformance Developer action elements ATE_IND.1.1D The developer shall provide the TOE for testing. Content and presentation elements ATE_IND.1.1C The TOE shall be suitable for testing. Evaluator action elements ATE_IND.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_IND.1.2E The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 38 of 106 CygnaCom Solutions Table 6-11: AVA_VAN.1 Vulnerability Survey Developer action elements AVA_VAN.1.1D The developer shall provide the TOE for testing. Content and presentation elements AVA_VAN.1.1C The TOE shall be suitable for testing. Evaluator action elements AVA_VAN.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AVA_VAN.1.2E The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE. AVA_VAN.1.3E The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential. 6.2.2 Explicit Assurance Activities - SARs The following subsections define the explicit assurance activities presented in the [ESM PM PP] for applicable SAR families. These assurance activities serve to refine the standard SARs previously stated with specific activities to be performed by the evaluators during the course of their evaluation. 6.2.2.1 Class ADV Assurance Activities There are no specific assurance activities associated with these SARs. The functional specification documentation is provided to support the evaluation activities described for each SFR, and for other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other assurance activities being performed; if the evaluator is unable to perform an activity because the there is insufficient interface information, then an adequate functional specification has not been provided. For example, if the TOE provides the capability to configure the key length for the encryption algorithm but fails to specify an interface to perform this function, then the assurance activity associated with FMT_SMF would fail. The evaluator shall verify that the TOE functional specification describes the set of interfaces the TOE intercepts or works with. The evaluator shall examine the description of these interfaces and verify that they include a satisfactory description of their invocation. The evaluator shall also verify that the TOE functional specification describes how the TOE deals with the possibility of acceptance of invalid data. The possibility of invalid data acceptance, if not properly protected, could alter access control decisions to give access to unauthorized users or deny access to authorized users. 6.2.2.2 Class AGD Assurance Activities AGD_OPE.1 The operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 39 of 106 CygnaCom Solutions administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE. AGD_PRE.1 The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms (that is, combination of hardware and operating system) claimed for the TOE in the ST. 6.2.2.3 Class ALC Assurance Activities ALC_CMC.1 The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a web site advertising the TOE, the evaluator shall examine the information on the web site to ensure that the information in the ST is sufficient to distinguish the product. ALC_CMS.1 By ensuring that the TOE is specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component. 6.2.2.4 Class ATE Assurance Activities ATE_IND.1 The evaluator shall prepare a test plan and report documenting the testing aspects of the system. The test plan covers all of the testing actions contained in the body of this PP’s Assurance Activities. While it is not necessary to have one test case per test listed in an Assurance Activity, the evaluators shall document in the test plan that each applicable testing requirement in the ST is covered. The Test Plan identifies the platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification shall address the differences between the tested platform and the untested platforms, and make an argument that the differences do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no affect; rationale shall be provided. If all platforms claimed in the ST are tested, then no rationale is necessary. The test plan describes the composition of each platform to be tested, and any setup that is necessary beyond what is contained in the AGD documentation. It should be noted that the evaluators are expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. This may include special test drivers or tools. For each driver or tool, an argument (not just an assertion) is provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform. This also includes the configuration of the cryptographic engine to be used. The cryptographic algorithms implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated (IPsec, TLS/HTTPS, SSH). Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 40 of 106 CygnaCom Solutions The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results. The test report (that could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the report would show a “fail” and “pass” result (and the supporting details), and not just the “pass” result. 6.2.2.5 Class AVA Assurance Activities AVA_VAN.1 As with ATE_IND, the evaluator shall generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The evaluator performs a search of public information to determine the vulnerabilities that have been found in this category of ESM application in general, as well as those that pertain to the particular TOE. The evaluator documents the sources consulted and the vulnerabilities found in the report. For each vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed to take advantage of the vulnerability. For example, if the vulnerability can be detected by pressing a key combination on boot-up, for example, a test would be suitable at the assurance level of this PP. If exploiting the vulnerability requires an electron microscope and liquid nitrogen, for instance, then a test would not be suitable and an appropriate justification would be formulated. 6.2.3 Explicit Assurance Activities - SFRs The following subsections define the explicit assurance activities presented in the [ESM PM PP] for applicable SFR elements. Note that the sections for the SFRs have been divided into assurance activities based on whether they apply to TOE design, operational guidance, or testing. The [ESM PM PP] does not include any SFR-specific life-cycle or vulnerability analysis assurance activities. The assurance activities in the following sections serve to refine the SARs with specific activities to be performed by the evaluators during the course of their evaluation. 6.2.3.1 ESM_ACD.1 Assurance Activities Assurance Activities - Design The evaluator shall do the following:  Verify that the TSS identifies one or more compatible Access Control products  Verify that the TSS describes the scope and granularity of the entities that define policies (subjects, objects, operations, attributes)  Review STs for the compatible Access Control products and verify that there is correspondence between the policies the TOE is capable of creating and the policies the Access Control products are capable of consuming Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 41 of 106 CygnaCom Solutions  Verify that the TSS indicates how policies are identified Assurance Activities - Guidance The evaluator shall review the operational guidance to ensure that that it indicates the compatible Access Control product(s) as well as the allowable contents and means of identification of the access control policies that can be defined by the TOE. Assurance Activities - Testing The evaluator shall test this capability by using the TOE to create a policy that uses the full range of subjects, objects, operations, and attributes and sending it to a compatible Access Control product for consumption. The evaluator will then perform actions that are mediated by the Access Control product in order to confirm that the policy was applied appropriately. The evaluator will also verify that a policy identifier is associated with a transmitted policy by querying the policy that is being implemented by the Access Control product. 6.2.3.2 ESM_ACT.1 Assurance Activities Assurance Activities - Design The evaluator shall check the TSS and ensure that it summarizes when and how policy data will be transmitted to Access Control products. This includes the ability to specify the product(s) that the policy data will be sent to. Assurance Activities - Guidance The evaluator shall review the operational guidance to determine how to create and update policies, and the circumstances under which new or updated policies are transmitted to consuming ESM products (and how those circumstances are managed, if applicable). Assurance Activities - Testing The evaluator shall test this capability by obtaining one or more compatible Access Control products and configuring the TOE to manage them. Then, following the procedures in the operational guidance for both the TOE and the Access Control product, the evaluator shall create a new policy and ensure that the new policy defined in the by the TSF is successfully transmitted to, consumed by, and enforced in an Access Control product, in accordance with the circumstances defined in the SFR. In other words, a) if the selection is completed to transmit after creation of a new policy, then the evaluator shall create the new policy and ensure that, after a reasonable window for transmission, the new policy is installed; b) if the selection is completed to transmit periodically, the evaluator shall create the new policy, wait until the periodic interval has passed, and then confirm that the new policy is present in the Access Control component; or c) if the section is completed to transmit upon the request of a compatible Secure Configuration Management component, the evaluator shall create the policy, use the Secure Configuration Management component to request transmission, and the confirm that the Access Control component has received and installed the policy. If the ST author has specified “other circumstances”, then a similar test shall be executed to confirm transmission under those circumstances. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 42 of 106 CygnaCom Solutions The evaluator shall then make a change to the previously created policy and then repeat the previous procedure to ensure that the updated policy is transmitted to the Access Control component in accordance with the SFR-specified circumstances. Lastly, as updating a policy encompasses deletion of a policy, the evaluator shall repeat the process a third time, this time deleting the policy to ensure it is removed as an active policy from the Access Control component. The evaluator shall repeat this test for a representative sample of Access Control products that can be managed by the TOE. For example, if the TOE provides the ability to manage groups of host-based access control endpoints, the evaluator shall create different groups such that each supported platform is included in at least one group and verify that group members will appropriately consume policies when instructed to do so. Note: This testing will likely be performed in conjunction with the testing of ESM_ACD.1. The access control product using the Transparent Encryption Agent is outside the scope of the ESM PP PM evaluation. 6.2.3.3 ESM_ATD.1 Assurance Activities Assurance Activities - Design The evaluator shall check the TSS to ensure that it describes the object attributes that are defined by the TOE and the purpose for their definition. Assurance Activities - Guidance The evaluator shall check the operational guidance to ensure that it provides instructions on how to define and configure the object attributes. Assurance Activities - Testing The evaluator shall test this capability by creating a policy that uses the defined attributes and having an Access Control product consume it. They shall then perform actions that will be allowed by the Access Control product and actions that will be denied by the Access Control product based on the object attributes that were associated with the policy. 6.2.3.4 ESM_ATD.2 Assurance Activities Assurance Activities - Design The evaluator shall check the TSS to ensure that it describes the subject attributes that are defined by the TOE and the purpose for their definition. Assurance Activities - Guidance The evaluator shall check the operational guidance to ensure that it provides instructions on how to define and configure these attributes. Assurance Activities - Testing The evaluator shall test this capability by creating a policy that uses the defined attributes and having an Access Control product consume it. They shall then perform actions that will be allowed by the Access Control product and actions that will be denied by the Access Control product based on the object attributes that were associated with the policy. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 43 of 106 CygnaCom Solutions 6.2.3.5 ESM_EAU.2 Assurance Activities Assurance Activities - Design The evaluator shall check the TSS in order to determine that it describes the TSF as requiring authentication to use and that it describes, for each type of user or IT entity that authenticates to the TOE, the identification and authentication mechanism that is used. The evaluator shall also check to ensure that this information is appropriately represented by iterating the SFR for each authentication mechanism that is used by the TSF. Assurance Activities - Guidance The evaluator shall check the operational guidance in order to determine how the TOE determines whether an interactive user requesting access to it has been authenticated and how the TOE validates authentication credentials or identity assertions that it receives. If any IT entities authenticate to the TOE, the evaluator shall also check the operational guidance to verify that it identifies how these entities are authenticated and what configuration steps must be performed in order to set up the authentication. Assurance Activities - Testing The evaluator shall test this capability by accessing the TOE without having provided valid identification and authentication information and observe that access to the TSF is subsequently denied. If any IT entities authenticate to the TOE, the evaluator shall instruct these IT entities to provide invalid identification and authentication information and observe that they are not able to access the TSF. Note that positive testing of the identification and authentication is assumed to be tested by other requirements because successful authentication is a prerequisite to manage the TSF (and possibly for the TSF to interact with external IT entities). 6.2.3.6 ESM_EID.2 Assurance Activities This functionality—for both interactive users and authorized IT entities—is verified concurrently with ESM_EAU.2. 6.2.3.7 FAU_GEN.1 Assurance Activities Assurance Activities - Design The evaluator shall check the TSS and ensure that it summarizes the auditable events and describes the contents of the audit records. Assurance Activities - Guidance The evaluator shall check the operational guidance and ensure that it lists all of the auditable events and provides description of the content of each type of audit record. Each audit record format type shall be covered, and shall include a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN 1.2, and the additional information specified in Table 3. The evaluator shall review the operational guidance, and any available interface documentation, in order to determine the administrative interfaces (including subcommands, Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 44 of 106 CygnaCom Solutions scripts, and configuration files) that permit configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the PP. The evaluator shall document the methodology or approach taken to do this. The evaluator may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements. Using this list, the evaluation shall confirm that each security relevant administrative interface has a corresponding audit event that records the information appropriate for the event. Assurance Activities - Testing The evaluator shall test the TOE’s audit function by having the TOE generate audit records for all events that are defined in the ST and/or have been identified in the previous two activities. The evaluator shall then check the audit repository defined by the ST, operational guidance, or developmental evidence (if available) in order to determine that the audit records were written to the repository and contain the attributes as defined by the ST. This testing may be done in conjunction with the exercise of other functionality. For example, if the ST specifies that an audit record will be generated when an incorrect authentication secret is entered, then audit records will be expected to be generated as a result of testing identification and authentication. The evaluator shall also check to ensure that the content of the logs are consistent with the activity performed on the TOE. For example, if a test is performed such that a policy is defined, the corresponding audit record should correctly identify the policy that was defined. 6.2.3.8 FAU_SEL.1 Assurance Activities Assurance Activities - Design The evaluator shall check the TSS in order to determine that it discusses the TSF’s ability to have selective auditing and that it summarizes the mechanism(s) by which auditable events are selected for auditing. Assurance Activities - Guidance The evaluator shall check the operational guidance in order to determine the selections that are capable of being made to the set of auditable events, and shall confirm that it contains all of the selections identified in the Security Target. Assurance Activities - Testing The evaluator shall test this capability by using all allowable vectors that are defined in FMT_MOF.1 to configure the TOE in the following manners:  All selectable auditable events enabled  All selectable auditable events disabled  Some selectable auditable events enabled For each of these configurations, the evaluator shall perform all selectable auditable events and determine by review of the audit data that in each configuration, only the enabled events are recorded. 6.2.3.9 FAU_SEL_EXT.1 Assurance Activities Assurance Activities - Design Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 45 of 106 CygnaCom Solutions The evaluator shall check the TSS in order to determine that it discusses the TSF’s ability to configure selective auditing for an Access Control product and that it summarizes the mechanism(s) by which auditable events are selected for auditing. Assurance Activities - Guidance The evaluator shall check the operational guidance in order to determine the selections that are capable of being made to the set of auditable events, and shall confirm that it contains all of the selections identified in the Security Target. Assurance Activities - Testing The evaluator shall test this capability by configuring a compatible Access Control product to have:  All selectable auditable events enabled  All selectable auditable events disabled  Some selectable auditable events enabled For each of these configurations, the evaluator shall perform all selectable auditable events and determine by review of the audit data that in each configuration, only the enabled events are recorded by the Access Control product. 6.2.3.10 FAU_STG_EXT.1 Assurance Activities Assurance Activities - Design The evaluator shall check the TSS in order to determine that it describes the location where the TOE stores its audit data, and if this location is remote, the trusted channel that is used to protect the data in transit. Assurance Activities - Guidance The evaluator shall check the operational and preparatory guidance in order to determine that they describe how to configure and use an external repository for audit storage. The evaluator shall also check the operational guidance in order to determine that a discussion on the interface to this repository is provided, including how the connection to it is established, how data is passed to it, and what happens when a connection to the repository is lost and subsequently re-established. Assurance Activities - Testing The evaluator shall test this function by configuring this capability, performing auditable events, and verifying that the local audit storage and external audit storage contain identical data. The evaluator shall also make the connection to the external audit storage unavailable, perform audited events on the TOE, re-establish the connection, and observe that the external audit trail storage is synchronized with the local storage. Similar to the testing for FAU_GEN.1, this testing can be done in conjunction with the exercise of other functionality. Finally, since the requirement specifically calls for the audit records to be transmitted over the trusted channel established by FTP_ITC.1, verification of that requirement is sufficient to demonstrate this part of this one. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 46 of 106 CygnaCom Solutions 6.2.3.11 FCS_CKM.1 Assurance Activities Assurance Activities – Design In order to show that the TSF complies with 800-56A and/or 800-56B, depending on the selections made, the evaluator shall ensure that the TSS contains the following information:  The TSS shall list all sections of the appropriate 800-56 standard(s) to which the TOE complies.  For each applicable section listed in the TSS, for all statements that are not "shall" (that is, "shall not", "should", and "should not"), if the TOE implements such options it shall be described in the TSS. If the included functionality is indicated as "shall not" or "should not" in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE;  For each applicable section of 800-56A and 800-56B (as selected), any omission of functionality related to "shall" or “should” statements shall be described;  Any TOE-specific extensions, processing that is not included in the documents, or alternative implementations allowed by the documents that may impact the security requirements the TOE is to enforce shall be described. Assurance Activities – Testing The evaluator shall use the key pair generation portions of "The FIPS 186-4 Digital Signature Algorithm Validation System (DSA2VS)", "The FIPS 186-4 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS)", and "The RSA Validation System (RSA2VS)" as a guide in testing the requirement above, depending on the selection performed by the ST author. This will require that the evaluator have a trusted reference implementation of the algorithms that can produce test vectors that are verifiable during the test. 6.2.3.12 FCS_CKM_EXT.4 Assurance Activities Assurance Activities – Design The evaluator shall check to ensure the TSS describes each of the secret keys (keys used for symmetric encryption), private keys, and critical security parameters used to generate key; when they are zeroized (for example, immediately after use, on system shutdown, etc.); and the type of zeroization procedure that is performed (overwrite with zeros, overwrite three times with random pattern, etc.). If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the zeroization procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are zeroized by overwriting once with zeros, while secret keys stored on the internal hard drive are zeroized by overwriting three times with a random pattern that is changed before each write"). 6.2.3.13 FCS_COP.1 (1) Assurance Activities Assurance Activities – Testing The evaluators shall use tests appropriate to the modes selected in the above requirement from "The Advanced Encryption Standard Algorithm Validation Suite (AESAVS)", "The XTS- AES Validation System (XTSVS)", The CMAC Validation System (CMACVS)", "The Counter with Cipher Block Chaining-Message Authentication Code (CCM) Validation System (CCMVS)", and "The Galois/Counter Mode (GCM) and GMAC Validation System (GCMVS)" (these documents are available from http://csrc.nist.gov/groups/STM/cavp/index.html) as a Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 47 of 106 CygnaCom Solutions guide in testing the requirement above. This will require that the evaluators have a reference implementation of the algorithms that can produce test vectors that are verifiable during the test. 6.2.3.14 FCS_COP.1 (2) Assurance Activities Assurance Activities – Testing The evaluators shall use the signature generation and signature verification portions of "The FIPS 186-4 Digital Signature Algorithm Validation System (DSAVS)", "The FIPS 186-4 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS)", and "The RSA Validation System (RSAVS)" as a guide in testing the requirement above. This will require that the evaluators have a reference implementation of the algorithms that can produce test vectors that are verifiable during the test. 6.2.3.15 FCS_COP.1 (3) Assurance Activities Assurance Activities – Testing The evaluators shall use "The Secure Hash Algorithm Validation System (SHAVS)" as a guide in testing the requirement above. This will require that the evaluators have a reference implementation of the algorithms that can produce test vectors that are verifiable during the test. 6.2.3.16 FCS_COP.1 (4) Assurance Activities Assurance Activities – Testing The evaluators shall use "The Keyed-Hash Message Authentication Code (HMAC) Validation System (HMACVS)" as a guide in testing the requirement above. This will require that the evaluators have a reference implementation of the algorithms that can produce test vectors that are verifiable during the test. 6.2.3.17 FCS_HTTPS_EXT.1 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS to ensure that it is clear on how HTTPS uses TLS to establish an administrative session, focusing on any client authentication required by the TLS protocol vs. security administrator authentication which may be done at a different level of the processing stack. The evaluator shall also check the TSS to verify that it describes how the cryptographic functions in the FCS requirements associated with this protocol (FCS_COP.1(1), etc.) are being used to perform the encryption functions. For the cryptographic functions that are provided by the Operational Environment, the evaluator shall check the TSS to ensure it describes—for each platform identified in the ST—the interface(s) used by the TOE to invoke this functionality. Assurance Activities – Guidance There are no assurance activities to be performed against the operational guidance for this requirement. Assurance Activities – Testing Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 48 of 106 CygnaCom Solutions Testing for this activity is done as part of the TLS testing; this may result in additional testing if the TLS tests are done at the TLS protocol level. 6.2.3.18 FCS_RBG_EXT.1 Assurance Activities Assurance Activities – Design The evaluator shall review the TSS section to determine the version number of the product containing the RBG(s) used in the TOE. The evaluator shall also review the TSS to determine that it includes discussions that are sufficient to address the requirements described in Appendix C.9 Entropy Documentation and Assessment. This documentation may be included as a supplemental addendum to the Security Target. Assurance Activities – Testing Regardless of the standard to which the RBG is claiming conformance, the evaluator performs the following test:  Test 1: The evaluator shall determine an entropy estimate for each entropy source by using the Entropy Source Test Suite. The evaluator shall ensure that the TSS includes an entropy estimate that is the minimum of all results obtained from all entropy sources. 6.2.3.19 FCS_TLS_EXT.1 Assurance Activities Assurance Activities – Design The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics (e.g., extensions supported, client authentication supported) are specified, and the ciphersuites supported are specified as well. The evaluator shall check the TSS to ensure that the ciphersuites specified are identical to those listed for this component. The evaluator shall also check the TSS to verify that it describes how the cryptographic functions in the FCS requirements associated with this protocol (FCS_COP.1(1), etc.) are being used to perform the encryption functions. For the cryptographic functions that are provided by the Operational Environment, the evaluator shall perform the following activities: a) Ensure the ST contains a list of representative platforms (hardware and software) compromising the operational environment. b) Check the TSS to ensure it describes-for each platform identified in the ST-the interface(s) used by the TOE to invoke this functionality. c) For each platform identified in the ST, check the OE documentation to ensure the interfaces identified in the previous step exist. Assurance Activities – Guidance The evaluator shall check the operational guidance to ensure that it contains instructions on configuring the TOE in the Operational Environment so that TLS conforms to the description in the TSS (for instance, the set of ciphersuites advertised by the TOE may have to be restricted to meet the requirements or an administrator is expected to deploy a particular client to access the TOE). Assurance Activities – Testing Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 49 of 106 CygnaCom Solutions The evaluator shall test this capability by establishing a TLS connection using each of the ciphersuites specified by the requirement. This connection may be established as part of the establishment of a higher-level protocol, e.g., as part of a HTTPS session. It is sufficient to observe (on the wire) the successful negotiation of a ciphersuite to satisfy the intent of the test; it is not necessary to examine the characteristics of the encrypted traffic in an attempt to discern the ciphersuite being used (for example, that the cryptographic algorithm is 128-bit AES and not 256-bit AES). 6.2.3.20 FIA_AFL.1 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to determine that the authentication failure handling function is described in sufficient detail to affirm the SFR. Assurance Activities – Guidance The evaluator shall check the operational guidance to verify that a discussion on authentication failure handling is present and consistent with the representation in the Security Target. Assurance Activities – Testing The evaluator shall test this capability by using the authentication function of the TSF to deliberately enter incorrect credentials. The evaluator shall observe that the proper action occurs after a sufficient number of incorrect authentication attempts. The evaluator shall also use the TSF to reconfigure the threshold value in a manner consistent with operational guidance to verify that it can be changed. 6.2.3.21 FIA_SOS.1 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to verify that it discusses the TOE’s strength of secrets capability to a level of detail that is consistent with the SFR. Assurance Activities – Guidance The evaluator shall check the operational guidance in order to verify that it provides information to administrators about the TOE’s enforcement of password composition, reuse, and aging or of a non-password-based credential. If the TOE does not support password- based credentials, the evaluator shall check to verify that the operational guidance provides information about the credential that is used by the TSF and how it is supplied to the TOE. The evaluator shall also check the operational guidance to verify that it discusses the aspects of the strength of secrets policy that can be configured and what steps an administrator needs to perform in order to configure it. Assurance Activities – Testing The evaluator shall test this capability in the following manner:  If password-based authentication is supported, the evaluator shall supply valid and invalid passwords in order to verify that the length and composition requirements function as described in the TSS. The evaluator shall test the password aging Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 50 of 106 CygnaCom Solutions requirements by setting a password and observing that it expires after the appropriate length of time. The evaluator shall test reuse requirements by providing a series of valid and invalid changed passwords, first to test that a changed password must be sufficiently distinct and then to test that passwords cannot be reused within a certain number.  If password-based authentication is supported, the evaluator shall perform the steps described in the operational guidance to alter each configurable parameter of the password policy and to supply passwords before and after the parameter is altered to verify that the change appropriately took effect.  If non-password-based authentication is supported, the evaluator shall follow the steps described in the operational guidance to create a credential. The evaluator shall then observe that providing that credential to the TOE allows access and an invalid credential is rejected. An example of this is fingerprint biometrics. In this case, the evaluator would associate a user account with their own fingerprint. They would then log on to their account by providing their fingerprint and then observe failure when someone else tries to provide their fingerprint instead. If only non-password-based authentication is supported, it is sufficient for the evaluator to justify the unlikelihood of brute force guessing using evidence provided by the vendor and/or published research. 6.2.3.22 FIA_USB.1 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to determine that it describes the security attributes that are assigned to administrators and the means by which the administrator is associated with these attributes, both during initial assignment and when any changes are made to them. Assurance Activities – Guidance The evaluator shall check the operational guidance in order to verify that it describes the mechanism by which external data sources are invoked and mapped to user data that is controlled by the TSF. Assurance Activities – Testing The evaluator shall test this capability by configuring the TSF to accept user information from external sources as defined by the ST. The evaluator shall then perform authentication activities using these methods and validate that authentication is successful in each instance. Based on the defined privileges assigned to each of the subjects, the evaluator shall then perform various management tests in order to determine that the user authorizations are consistent with their externally-defined attributes and the configuration of the TSF’s access control policy. For example, if a user who is defined in an LDAP repository belongs to a certain group and the TSF is configured such that members of that group only have read-only access to policy information, the evaluator shall authenticate to the TSF as that user and verify that as a subject under the control of the TSF that they do not have write access to policy information. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 51 of 106 CygnaCom Solutions This verifies that the aspects of the user’s identity data that are pertinent to how the TSF treats the user are appropriately taken from external sources and used in order to determine what the user is able to do. 6.2.3.23 FMT_MOF.1 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to determine that the assignments were completed in a manner that is consistent with the guidance provided by the application note(s). The evaluator shall also check the TSS to see that it describes the ability of the TSF to perform the required management functions and the authorizations that are required to do this. Assurance Activities – Guidance The evaluator shall review the operational guidance in order to determine what restrictions are in place on management of these attributes and how the TSF enforces them. For example, if management authority is role-based, then the operational guidance shall indicate this. Assurance Activities – Testing The evaluator shall test this function by accessing the TSF using one or more appropriately privileged administrative accounts and determining that the management functions as described in the ST and operational guidance can be managed in a manner that is consistent with any instructions provided in the operational guidance. If the TSF can be configured by an authorized and compatible Secure Configuration Management product, the evaluator shall also configure such a product to manage the TSF and use this product to perform the defined management activities. In addition, any access restrictions to this behavior should be enforced in a manner that is consistent with the relevant documentation. The evaluator shall test this by attempting to perform a sampling of the available management functions using one or more unprivileged accounts to observe that the activities are rejected or unavailable. 6.2.3.24 FMT_MOF_EXT.1 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to determine that the assignments were completed in a manner that is consistent with the guidance provided by the application note(s). The evaluator shall also check the TSS to see that it summarizes the Access Control product functions that the TOE is able to manage and the authorizations that are required in order to manage these functions. Assurance Activities – Guidance The evaluator shall check the operational guidance in order to determine that it provides instructions for how to connect to an Access Control product and what privileges are required to perform management functions on it once the connection has been established. Assurance Activities – Testing The evaluator shall test this capability by deploying the TOE in an environment where there is an Access Control component that is able to communicate with it. The evaluator shall configure this environment such that the Policy Management product is authorized to issue commands to the TOE. Once this has been done, the evaluator shall use the Policy Management product to modify the behavior of the functions specified in the requirement Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 52 of 106 CygnaCom Solutions above. For each function, the evaluator shall verify that the modification applied appropriately by using the Policy Management product to query the behavior for and after the modification. The evaluator shall also perform activities that cause the TOE to react in a manner that the modification prescribes. These actions include, for each function, the following activities:  Audited events: perform an event that was previously audited (or not audited) prior to the modification of the function’s behavior and observe that the audit repository now logs (or doesn’t log) this event based on the modified behavior  Repository for audit storage: observe that audited events are written to a particular repository, modify the repository to which the TOE should write audited events, perform auditable events, and observe that they are no longer written to the original repository  Access Control SFP: perform an action that is allowed (or disallowed) by the current Access Control SFP, modify the implemented SFP such that that action is now disallowed (or allowed), perform the same action, and observe that the authorization differs from the original iteration of the SFP.  Policy being implemented by the TSF: perform an action that is allowed (or disallowed) by a specific access control policy, provide a TSF policy that now disallows (or allows) that action, perform the same action, and observe that the authorization differs from the original iteration of the FSP.  Access Control SFP behavior to implement in the event of communications outage: perform an action that is handled in a certain manner in the event of a communications outage (if applicable), re-establish communications between the TOE and the Policy Management product, change the SFP behavior that the TOE should implement in the event of a communications outage, sever the connection between the TOE and the Policy Management product, perform the same action that was originally performed, and observe that the modified way of handling the action is correctly applied. Once this has been done, the evaluator shall reconfigure the TOE so that it is no longer authorized to manage the Access Control product. The evaluator shall then attempt to perform management functions using the TOE and observe that this is either disallowed or that the option is not even present. 6.2.3.25 FMT_MSA_EXT.5 Assurance Activities Assurance Activities – Design The evaluator shall review the TSS and in order to determine that it explains what potential contradictions in policy data may exist. For example, a policy could potentially contain two rules that permit and forbid the same subject from accessing the same object. Alternatively, the TOE may define an unambiguous hierarchy that makes it impossible for contradictions to occur. If the TOE does not allow contradictory policy to exist, the evaluator shall verify that this assertion has been made in the TSS and that justification is provided to support the assertion. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 53 of 106 CygnaCom Solutions Assurance Activities – Guidance If the TOE requires manual intervention in order to resolve contradictory policy data, the evaluator shall review the operational guidance in order to verify that it provides a summary of contradictory policy situations and the steps that must be taken in order to resolve them. If the TOE’s policy engine prevents such contradictions, the evaluator shall review the operational guidance in order to verify that it describes how the TSF reconciles any contradictory policy data (such as different rules simultaneously allowing and denying a certain behavior). Assurance Activities – Testing The evaluator shall test this capability by defining policies that contain the contradictions indicated in the operational guidance and observing if the TSF responds by detecting the contradictions and reacting in the manner prescribed in the ST. If the TSF behaves in a manner that prevents contradictions from occurring, the evaluator shall review the operational guidance in order to determine if the mechanism for preventing contradictions is described and if this feature is communicated to administrators. This feature shall be tested in conjunction with a compatible Access Control product; in other words, if the TOE has a mechanism that prevents contradictions (for example, if a deny rule always supersedes an allow rule), then correct enforcement of such a policy by a compatible Access Control product is both a sufficient and a necessary condition for demonstrating the effectiveness of this mechanism. 6.2.3.26 FMT_MTD.1 Assurance Activities Assurance Activities – Design The evaluator shall review the TSS in order to determine the repository in which the authentication data used by the TOE is stored. The evaluator shall also determine how communications with this repository is secured. Assurance Activities – Guidance The evaluator shall review the operational guidance in order to determine that it includes the data that can be managed and who is able to manage this data. This can be separated over multiple roles to distinguish between user administration and self-service; for example, both a Security Administrator and a specific user may be able to modify that user’s own password. Assurance Activities – Testing The evaluator shall test this capability by performing the identified management activities with authorized roles in order to determine that they are allowed. The evaluator shall also attempt to perform these activities with unauthorized roles in order to determine that they are not allowed. Finally, the evaluator shall verify that communications between the TSF and the authentication data repository are secured by repeating the testing for FTP_ITC.1 over the interface between the two components. 6.2.3.27 FMT_SMF.1 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to determine that it summarizes the management functions that are available. Assurance Activities – Guidance Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 54 of 106 CygnaCom Solutions The evaluator shall check the operational guidance in order to determine that it defines all of the management functions that can be performed against the TSF, how to perform them, and what they accomplish. Assurance Activities – Testing The evaluator shall test this capability by accessing the TOE and verifying that all of the defined management functions exist, that they can be performed in the prescribed manner, and that they and accomplish the documented capability. 6.2.3.28 FMT_SMR.1 Assurance Activities Assurance Activities – Design The evaluator shall review the TSS to determine the roles that are defined for the TOE. The evaluator shall also review the TSS to verify that the roles defined by this SFR are consistently referenced when discussion how management authorizations are determined. Assurance Activities – Guidance The evaluator shall review the operational guidance in order to verify that it provides instructions on how to assign users to roles. If the TSF provides only a single role that is automatically assigned to all users, then the evaluator shall review the operational guidance to verify that this fact is asserted. Assurance Activities – Testing The evaluator shall test this capability by using the TOE in the manner prescribed by the operational guidance to associate different users with each of the available roles. If the TSF provides the capability to define additional roles, the evaluator shall create at least one new role and ensure that a user can be assigned to it. Since other assurance activities for management requirements involve the evaluator assuming different roles on the TOE, it is possible that these testing activities will be addressed in the course of performing these other assurance activities. 6.2.3.29 FPT_APW_EXT.1 Assurance Activities Assurance Activities – Design The evaluator shall examine the TSS to determine that it details all authentication data, other than private keys addressed by FPT_SKP_EXT.1, that is used or stored by the TSF, and the method used to obscure the plaintext credential data when stored. This includes credential data stored by the TOE if the TOE performs authentication of users, as well as any credential data used by the TOE to access services in the operational environment (such as might be found in stored scripts). The TSS shall also describe the mechanisms used to ensure credentials are stored in such a way that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. Alternatively, if authentication data is not stored by the TOE because the authoritative repository for this data is in the Operational Environment, this shall be detailed in the TSS. Assurance Activities – Testing The evaluator shall test this SFR by reviewing all the identified credential repositories to ensure that credentials are stored obscured, and that the repositories are not accessible to non-administrative users. The evaluator shall similarly review all scripts and storage for Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 55 of 106 CygnaCom Solutions mechanisms used to access systems in the operational environment to ensure that credentials are stored obscured and that the system is configured such that data is inaccessible to non- administrative users. 6.2.3.30 FPT_SKP_EXT.1 Assurance Activities Assurance Activities – Design The evaluator shall examine the TSS to determine that it details how any pre-shared keys, symmetric keys, and private keys are stored and that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note. If these values are not stored in plaintext, the TSS shall describe how they are protected/obscured. 6.2.3.31 FPT_STM.1 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to determine that it discusses the TOE’s inclusion of a system clock. Assurance Activities – Guidance The evaluator examines the operational guidance to ensure it instructs the administrator how to set the time. If the TOE supports the use of an NTP server, the operational guidance instructs how a communication path is established between the TOE and the NTP server, and any configuration of the NTP client on the TOE to support this communication. Assurance Activities – Testing The evaluator shall determine through the evaluation of operational guidance how the TOE initializes and initiates the clock. The evaluator shall then follow those instructions to set the clock to a known value, and observe that the clock monotonically increments in a reliable fashion (comparison to a reference timepiece is sufficient). Through its exercise of other TOE functions, the evaluator shall confirm that the value of the timestamp is used appropriately. If the TOE supports multiple protocols for establishing a connection with an NTP server, the evaluator shall perform this test using each supported protocol claimed in the operational guidance. 6.2.3.32 FTA_SSL_EXT.1 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to determine that it discusses how inactivity is handled for local administrative sessions. Assurance Activities – Guidance The evaluator shall check the operational guidance in order to determine that it describes what happens when a local interactive session exceeds its idle time threshold. The evaluator shall also check the operational guidance in order to verify that it describes how to set the idle time threshold and, if applicable, how to configure the behavior the TSF performs when the idle time threshold is exceeded. Assurance Activities – Testing Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 56 of 106 CygnaCom Solutions The evaluator shall test this capability by following the operational guidance to configure several different values for the inactivity time period referenced in the component. For each period configured, the evaluator establishes a local interactive session with the TOE. The evaluator then observes that the session is either locked or terminated after the configured time period. If locking was selected from the component, the evaluator then ensures that re- authentication is needed when trying to unlock the session. 6.2.3.33 FTA_SSL.3 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to determine that it discusses how inactivity is handled for remote administrative sessions. Assurance Activities – Guidance The evaluator shall also check the operational guidance in order to verify that it describes how to set the idle time threshold. Assurance Activities – Testing The evaluator shall test this capability by following the operational guidance to configure several different values for the inactivity time period referenced in the component; these shall consist at least of the minimum and maximum allowed values as specified in the operational guidance, as well as one other value. For each period configured, the evaluator establishes a remote interactive session with the TOE. The evaluator then observes that the session is terminated after the configured time period. 6.2.3.34 FTA_SSL.4 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to determine that it discusses the ability of an administrator to terminate their own session. Assurance Activities – Guidance The evaluator shall check the operational guidance in order to verify that it describes how an administrator can terminate their own administrative session for each administrative interface that is supported by the TOE. Assurance Activities – Testing The evaluator shall test this capability by establishing a session with the TOE using an administrative interface. The evaluator then follows the operational guidance to exit or log off of the session and observes that the session has been terminated. If applicable, the evaluator shall repeat this test for each administrative interface that is supported by the TOE. 6.2.3.35 FTA_TAB.1 Assurance Activities Assurance Activities – Design The evaluator shall check the TSS in order to determine that it discusses the ability of the TSF to display a configurable banner prior to administrator authentication. Assurance Activities – Guidance Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 57 of 106 CygnaCom Solutions The evaluator shall review the operational guidance to determine how the TOE banner is displayed and configured. Assurance Activities – Testing If the banner is not displayed by default, the evaluator shall configure the TOE in accordance with the operational guidance in order to enable its display. The evaluator shall then attempt to access the TOE and verify that a TOE banner exists. If applicable, the evaluator will also attempt to use the functionality to modify the TOE access banner as per the standards defined in FMT_SMF.1 and verify that the TOE access banner is appropriately updated. 6.2.3.36 FTP_ITC.1 Assurance Activities Assurance Activities – Design The evaluator shall examine the TSS to determine that, for all communications with authorized IT entities identified in the requirement, each communications mechanism is identified in terms of the allowed protocols for that IT entity. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST. Assurance Activities – Guidance The evaluator shall confirm that the operational guidance contains instructions for establishing the allowed protocols with each authorized IT entity. Assurance Activities – Testing The evaluator shall also perform the following tests:  Test 1: The evaluators shall ensure that communications using each protocol with each authorized IT entity is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.  Test 2: For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall follow the operational guidance to ensure that in fact the communication channel can be initiated from the TOE.  Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data is not sent in plaintext.  Test 4: The evaluator shall ensure, for each communication channel with an authorized IT entity, modification of the channel data is detected by the TOE. Further assurance activities are associated with the specific FCS requirement(s) that are applicable to the TOE. 6.2.3.37 FTP_TRP.1 Assurance Activities The evaluator shall repeat the assurance activity for FTP_ITC.1 for each interface and cryptographic protocol that is provided by the TOE for remote administration. Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 58 of 106 CygnaCom Solutions 7 TOE Summary Specification Section 7 describes the specific Security Functions of the TOE that meet the criteria of the security features that are described in Section 2.5 Logical Scope of the TOE. The following sub-sections describe how the TOE meets each SFR listed in Section 6. Table 7-1: Security Functional Requirements Mapped to Security Functions Security Functions Sub-Functions SFRs System Monitoring SM-1: System Monitoring FAU_GEN.1 FPT_STM.1 FAU_SEL.1 SM-2: Audit Storage FAU_STG_EXT.1 Robust TOE Access TA-1: Strength of Secrets FIA_SOS.1 TA-2: Authentication Failure FIA_AFL.1 TA-3: Session Termination FTA_SSL_EXT.1 FTA_SSL.3 FTA_SSL.4 Authorized Management AM-1: Management I&A ESM_EAU.2 (1) ESM_EID.2 (1) ESM_EAU.2 (2) ESM_EID.2 (2) ESM_EAU.2 (3) ESM_EID.2 (3) FIA_USB.1 FPT_APW_EXT.1 AM-2: Management Roles FMT_MOF.1 FMT_SMR.1 AM-3: Remote Administration FTP_TRP.1 Policy Definition PD-1: Policy Definition ESM_ACD.1 ESM_ATD.1 ESM_ATD.2 FMT_MOF.1 FMT_MSA_EXT.5 FMT_SMF.1 Dependent Product Configuration PC-1: TOE Management Functions FMT_MOF.1 FMT_MTD.1 FMT_SMF.1 PC-2: Agent Configuration FAU_SEL_EXT.1 FMT_MOF_EXT.1 Confidential Communications CC-1: Agent Communications ESM_ACT.1 FCS_TLS_EXT.1 FCS_HTTPS_EXT.1 FMT_MOF.1 FTP_ITC.1 Vormetric Data Security Manager, Version 5.3 Security Target Vormetric Copyright 2016 59 of 106 CygnaCom Solutions Security Functions Sub-Functions SFRs CC-2: User Communications ESM_EAU.2 (1) ESM_EID.2 (1) ESM_EAU.2 (2) ESM_EID.2 (2) ESM_EAU.2 (3) ESM_EID.2 (3) FCS_HTTPS_EXT.1 FIA_USB.1 FMT_MOF FTP_TRP.1 CC-3: External Server Communications FMT_MOF FTP_ITC.1 CC-4: Key Protection FPT_SKP_EXT.1 Access Bannering AB-1: Banner FTA_TAB.1 Cryptographic Services CS-1: Crypto FCS_CKM.1 FCS_CKM_EXT.4 FCS_COP.1 (1) FCS_COP.1 (2) FCS_COP.1 (3) FCS_COP.1 (4) FCS_RBG_EXT.1 7.1 System Monitoring 7.1.1 SM-1: Audit Generation Log files and log data are generated on the DSM and its agents. The TSF generates audit records for the security significant events listed in Table 6-2: Auditable Events ([ESM PP PM] Table 3.). The DSM logs system-level events, such as failed login attempts, a broken network connection, and inoperable DSM database, and application-level events, such as evaluating a policy, applying GuardPoints, and adding administrators. Application-level Logs Application-level events from the DSM and the agents are collected in the Message Log and can be viewed in the “Logs” window of the Remote Administrative Management by administrators of type All or Security Administrator with Host role permission. The “Logs” window displays the following information: Table 7-2: Message Log Information Column Description ID Entries are numbered in the order in which the DSM enters them into the log database. Time The time at which the event occurred. Timestamps are in the form YYYY-MM-DD HH:MM:SS.mm,