Imperva SecureSphere v11.5 Common Criteria … · Common Criteria . Assurance Activities Report . ... Version 11.5, December 2015 [DSMON ... Imperva SecureSphere Upgrade Guide, Version

Imperva SecureSphere v11.5 Common Criteria

Assurance Activities Report

Version 0.92 December 11, 2015

Prepared by:

Leidos Inc. (formerly Science Applications International Corporation) https://www.leidos.com/commercialcyber/ate

Common Criteria Testing Laboratory 6841 Benjamin Franklin Drive

Columbia, MD 21046

1

https://www.leidos.com/commercialcyber/ate

Prepared for: National Information Assurance Partnership

Common Criteria Evaluation and Validation Scheme

The Developer of the TOE: Imperva Inc.

3400 Bridge Parkway, Suite 200 Redwood Shores, CA 94065

United States

The TOE Evaluation was Sponsored by: Imperva Inc.

3400 Bridge Parkway, Suite 200 Redwood Shores, CA 94065

United States

Evaluation Personnel: Greg Beaver

Common Criteria Versions

• Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 4, dated: September 2012.

• Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Components, Revision 4, dated: September 2012.

• Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Components, Revision 4, dated: September 2012.

Common Evaluation Methodology Versions

• Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, dated: September 2012.

Protection Profiles

• [NDPP_1.1] Security Requirements for Network Devices, Version 1.1, 8 June 2012

• [NDPP_Errata#3] Security Requirements for Network Devices Errata #3, November 3, 2014

2

Table of Contents

1 Introduction ........................................................................................................................ 6

1.1 Evidence ......................................................................................................................................... 6

2 Security Functional Requirement Assurance Activities ................................................... 6

2.1 Security Audit (FAU) .................................................................................................................. 6

2.1.1 Audit Data Generation (FAU_GEN.1) ...................................................................... 6

2.1.2 User Identity Association FAU_GEN.2 .................................................................... 15

2.1.3 External Audit Trail Storage (FAU_STG_EXT.1).................................................. 15

2.2 Cryptographic Support (FCS) .................................................................................................... 16

2.2.1 Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1) .............. 16

2.2.2 Cryptographic Key Zeroization (FCS_CKM_EXT.4) ............................................ 17

2.2.3 Cryptographic Operation (for data encryption/decryption) FCS_COP.1(1) ...... 18

2.2.4 Cryptographic Operation (for cryptographic signature) (FCS_COP.1(2)) ......... 18

2.2.5 Cryptographic Operation (for cryptographic hashing) (FCS_COP.1(3)) ........... 19 2.2.6 Cryptographic Operation (for keyed-hash message authentication)

(FCS_COP.1(4)) ............................................................................................................. 19 2.2.7 Extended: Cryptographic Operation (Random Bit Generation)

(FCS_RBG_EXT.1) ....................................................................................................... 20

2.2.8 Explicit: HTTPS (FCS_HTTPS_EXT.1) .................................................................. 22

2.2.9 Explicit: TLS (FCS_TLS_EXT.1) .............................................................................. 22

2.2.10 Explicit: FCS_SSH_EXT.1 (FCS_SSH_EXT.1.1) ................................................. 24







2.3 User Data Protection (FDP) ....................................................................................................... 31

2.3.1 Full Residual Information Protection (FDP_RIP.2) ................................................ 32

3

2.4 Identification and Authentication (FIA) .................................................................................. 32

2.4.1 Password Management (FIA_PMG_EXT.1) ............................................................ 32

2.4.2 User Identification and Authentication (FIA_UIA_EXT.1) .................................. 33

2.4.3 Extended: Password-based Authentication Mechanism (FIA_UAU_EXT.2) ... 35

2.4.4 FIA_UAU.7 Protected Authentication Feedback .................................................... 35

2.5 Security Management (FMT) .................................................................................................... 36

2.5.1 FMT_MTD.1 Management of TSF Data (for general TSF data) ......................... 36

2.5.2 FMT_SMF.1 Specification of Management Functions .......................................... 38

2.5.3 FMT_SMR.2 Restrictions on Security Roles ........................................................... 38

2.6 Protection of the TSF (FPT) ...................................................................................................... 39 2.6.1 Extended: Protection of TSF Data (for reading of all symmetric keys)

FPT_SKP_EXT.1 ........................................................................................................... 39

2.6.2 Extended: Protection of Administrator Passwords FPT_APW_EXT.1 .............. 40

2.6.3 FPT_STM.1 Reliable Time Stamps ............................................................................ 40

2.6.4 Extended: Trusted Update (FPT_TUD_EXT.1) ...................................................... 41

2.6.5 FPT_TST_EXT.1: TSF Testing .................................................................................. 43

2.6.6 FPT_ITT.1 Basic Internal TSF Data Transfer Protection ...................................... 44

2.7 TOE Access (FTA) ...................................................................................................................... 47

2.7.1 FTA_SSL_EXT.1 TSF-initiated Session Locking .................................................. 47

2.7.2 FTA_SSL.3 TSF-initiated Termination ..................................................................... 47

2.7.3 FTA_SSL.4 User-initiated Termination .................................................................... 48

2.7.4 FTA_TAB.1 Default TOE Access Banners .............................................................. 48

2.7.5 FTP_ITC.1 Inter-TSF trusted channel ....................................................................... 49

2.7.6 FTP_TRP.1 Trusted Path .............................................................................................. 51

3 Security Assurance Requirements ..................................................................................... 52

3.1 Class ADV: Development .......................................................................................................... 52

3.1.1 ADV_FSP.1 Basic Functional Specification ............................................................ 52

3.2 Class AGD: Guidance Documents ........................................................................................... 53

3.2.1 AGD_OPE.1 Operational User Guidance ................................................................. 53

3.2.2 AGD_PRE.1 Preparative Procedures ......................................................................... 54

3.3 ATE_IND.1 Independent Testing Conformance ................................................................... 55

4

3.3.1 ATE_IND.1 Assurance Activity ................................................................................. 55

3.4 Class AVA: Vulnerability Assessment .................................................................................... 56

3.4.1 AVA_VAN.1 Assurance Activity ............................................................................... 56

3.5 Class ALC: Life-Cycle Support ................................................................................................ 56

3.5.1 ALC_CMC.1 Labeling of the TOE Assurance Activity ........................................ 56

3.5.2 ALC_CMS.1 TOE CM Coverage Assurance Activity ........................................... 57

5

1 INTRODUCTION This document presents assurance activity evaluation results of the Imperva SecureSphere v11.5 evaluation. There are three types of assurance activities and the following is provided for each:

1. TOE Summary Specification (TSS)—an indication that the required information is in the TSS section of the Security Target

2. Guidance—a specific reference to the location in the guidance is provided for the required information

3. Test—a summary of the test procedure and result is provided for each required test activity.

This Assurance Activities Report contains sections for each functional class and family and sub-sections addressing each of the SFRs specified in the Security Target.

1.1 Evidence

[ST] Imperva SecureSphere Security Target, Version 0.4, November 12, 2015 [ADM] Imperva SecureSphere v11.5 Admin Guide, Version 11.5, August 2015 [SOM] Imperva SecureSphere Operations Manager (SOM) user Guide, Version 11.5, August

2015 [CCCC] Configuring Common Criteria Compliance User Guide, Version 11.5, December 2015 [DSMON] Imperva SecureSphere Directory Services Monitoring, Version 11.5, August 2015 [FILESEC] Imperva SecureSphere File Security User Guide, Version 11.5, August 2015 [UPGUIDE] Imperva SecureSphere Upgrade Guide, Version 11.5, August 2015

2 SECURITY FUNCTIONAL REQUIREMENT ASSURANCE ACTIVITIES This section describes the assurance activities associated with the SFRs defined in the ST and the results of those activities as performed by the evaluation team. The assurance activities are derived from [NDPP_1.1] and [NDPP_Errata#3].

2.1 Security Audit (FAU)

2.1.1 Audit Data Generation (FAU_GEN.1)

2.1.1.1 TSS Assurance Activities

The evaluator shall check to ensure that the TSS contains a list (possibly empty except for authentication failures for user-level connections) of the protocol failures that are auditable.

[ST] Section 6.1 states that the only protocol (i.e., HTTPS, TLS) failures auditable by the TOE are authentication failures for user-level connections.

2.1.1.2 Guidance Assurance Activities

The evaluator shall check the administrative guide and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type

6

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 1.

[CCCC] Section Audit Format, identifies the audit records and identifies the format of the audit records by providing an example of each audit record.

Requirement Auditable Events Additional Audit

Record Contents Sample Audit Record

FAU_GEN.1 Start-up of the audit functions 2015-08-22T21:33:09.233087-04:00

localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="2471" x-info="http://www.rsyslog.com"] start

FAU_GEN.1 Shut-down of the audit functions 2015-09-04T05:50:41.846355-04:00 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="4931" x-info="http://www.rsyslog.com"] exiting on signal 15.

FAU_GEN.1 None. FAU_GEN.2 None. FAU_STG_EXT.1 None. FCS_CKM.1 None. FCS_CKM_EXT.4 None. FCS_COP.1(1) None. FCS_COP.1(2) None. FCS_COP.1(3) None. FCS_COP.1(4) None. FCS_HTTPS_EXT.1 Failure to establish

a HTTPS session. Establishment/Termination of a HTTPS session.

Reason for failure. Non-TOE endpoint of connection (IP address) for both successes and failures

Failure Login failed System Sep 22, 2015 11:05 AM User High Login failed for user admin (IP: 192.168.1.9) Reason: bad credentials Success User logged in System Sep 22, 2015 10:39 AM User High User admin logged in from 192.168.1.9

FCS_RBG_EXT.1 None. FCS_SSH_EXT.1 Failure to establish

an SSH session. Establishment/Termination of an SSH session.

Reason for failure

Sep 1 07:14:31 192.168.1.7 sshd(20033]: pam_unix(sshd:auth): authentication_failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.10 user=root

Establishment/Termination of an SSH session.

Non-TOE endpoint of connection (IP address) for

Failure Nov 1 13:33:37 10.10.19.99 sshd[483]: pam_unix(sshd:session): session closed for user root

7

Requirement Auditable Events Additional Audit Record Contents

Sample Audit Record

both successes and failures.

Success Nov 1 13:33:30 10.10.19.99 sshd[483]: Accepted password for root from 10.2.48.225 port 51852 ssh2

FCS_TLS_EXT.1 Failure to establish a TLS session. Establishment/Termination of a TLS session.

Reason for failure. Non-TOE endpoint of connection (IP address) for both successes and failures


FDP_RIP.2 None. FIA_PMG_EXT.1 None. FIA_UAU_EXT.2 All use of the

authentication mechanism.

Origin of the attempt (e.g., IP address).

User logged in System Sep 22, 2015 10:39 AM User High User admin logged in from 192.168.1.9

FIA_UIA_EXT.1 All use of the identification and authentication mechanism.

Provided user identity, origin of the attempt (e.g., IP address).


FIA_UAU.7 None. FMT_MTD.1 None. FMT_SMF.1 None. FMT_SMR.2 None. FPT_APW_EXT.1 None. FPT_ITT.1 None. FPT_SKP_EXT.1 None. FPT_STM.1 Changes to the

time. The old and new values for the time. Origin of the attempt (e.g., IP address).

Set Time Regular System Aug 15, 2015 12:43 PM Appliance Medium Platform event: Platform time was changed from 2014/03/21 03:03 to 2015/08/15 12:43:23 Set NTP Regular System Aug 15, 2015 1:44 PM Appliance Medium Platform event: NTP server(s) changed from none to

8


Sample Audit Record

98.175.203.200 FPT_TUD_EXT.1 Initiation of update. No additional

information. Regular System Sep 2, 2015 11:52 AM Appliance Medium Platform event: The system was patched to 11.5.0-5_0 level

FPT_TST_EXT.1 None. FTA_SSL_EXT.1 Any attempts at

unlocking of an interactive session.

No additional information.

Regular admin Sep 22, 2015 10:42 AM User High Account enabled for user testuser

FTA_SSL.3 The termination of a remote session by the session locking mechanism.


User logged out System Sep 2, 2015 4:26 PM User High User admin logged out. (session expired)

FTA_SSL.4 The termination of an interactive session.


Nov 1 13:37:34 10.10.19.99 CEF: 0|Imperva Inc.|SecureSphere|11.5.0|User logged in|User admin logged in from 10.2.48.225.|High|suser=System rt=Nov 01 2015 15:49:13 cat=SystemEvent Nov 1 13:37:58 10.10.19.99 CEF: 0|Imperva Inc.|SecureSphere|11.5.0|User logged out|User admin logged out.|High|suser=System rt=Nov 01 2015 15:49:37 cat=SystemEvent

FTA_TAB.1 None. FTP_ITC.1 Initiation of the

trusted channel. Termination of the trusted channel. Failure of the trusted channel functions.

Identification of the initiator and target of failed trusted channels establishment attempt.

Update Server Success Regular System Sep 2, 2015 11:52 AM Appliance Medium Platform event: The system was patched to 11.5.0-5_0 level Failure 2015-09-01 06:48:55,378 INFO [BL-Thread-Jobs-General_3] (HttpConnectionServiceImpl.java:131) - failed sending request: www.imperva.com 2015-09-01 06:48:55,379 ERROR [BL-Thread-Jobs-General_3] (OnlinePackagesRepositoryService.java:63) - Failed to connect to Imperva central software update repository LDAP

9


Sample Audit Record

Success User logged in System Sep 1, 2015 8:52 AM User High User testimp logged in from 192.168.1.9. Failure Login failed System Sep 1, 2015 8:51 AM User High Login failed for user testimp (IP: 192.168.1.9) Reason: bad credentials Syslog Success 2015.09.01 03:40:00 LOG5[15156:139994576393984]: rsyslog connected remote server from 192.168.1.2:62760 Failure 2015.09.01 09:23:26 LOG3[790:140333738657536]: connect_blocking: getsockopt 192.168.1.7:60514: No route to host (113)

FTP_TRP.1 Initiation of the trusted channel. Termination of the trusted channel. Failures of the trusted path functions.

Identification of the claimed user identity.


The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP. The evaluator shall examine the administrative guide and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the 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 while determining which actions in the administrative guide are security relevant with respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements.

10

The evaluator examined the FMT_SMF.1.1 security requirement and compared those management functions with those in the NDPP. The following administrative actions were determined to be relevant in the context of the NDPP.

[CCCC] Section Audit Format, identifies the audit records and identifies the format of the audit records by providing an example of each audit record for the management functions provided by the TOE. Administrative Actions and Audit Records

Management Action Operational Guidance Audit Record Sample External Roles [ADM] Section Creating a

Role

Create New Role Regular admin Sep 22, 2015 10:45 AM User High Role NewAdmin created Delete Existing Role Regular admin Sep 22, 2015 10:45 AM User High Role NewAdmin removed

Create/Remove Roles Change role permissions

[ADM] Section Assigning Roles to Users

Add Role Regular admin Sep 1, 2015 11:29 AM User Low Role Administrator was added to user testuser Remove Role Regular admin Sep 1, 2015 9:34 AM User Low Role Administrator was removed from user ImpervaTest

Change user permissions [ADM] Section Understanding the Permissions Window

Permissions Granted Permissions changed admin Sep 22, 2015 10:49 AM Permissions Low User testuser was granted View,Edit permissions on item Site Default Site Permissions Revoked Permissions changed admin Sep 22, 2015 10:49 AM Permissions Low User testuser permissions on item Site Default Site have been revoked

User Accounts [ADM] Section Creating a SecureSphere User

Created Regular admin Sep 1, 2015 11:29 AM User High User testuser created Deleted Regular admin Sep 1, 2015

11

Management Action Operational Guidance Audit Record Sample 9:34 AM User High User ImpervaTest removed

Password Management [ADM] Section Resetting a User Password

Change Password Regular System Sep 2, 2015 2:36 AM Appliance Medium Platform event: User newuser has changed his password Set Max Length Regular System Sep 2, 2015 2:35 AM Appliance Medium Platform event: Password maximum length was changed from 14 to 30 Set Min Length Regular System Sep 2, 2015 2:35 AM Appliance Medium Platform event: Password minimum length was changed from 15 to 15

configure the cryptographic functionality

[ADM] Section Activating FIPS Mode

System parameter changed admin Sep 22, 2015 10:58 AM Config Low Parameter FIPS Mode value changed

verify the updates using the published hash

[ADM] Section Software Update Settings

Regular System Sep 2, 2015 11:52 AM Appliance Medium Platform event: The system was patched to 11.5.0-5_0 level

Time [ADM] Section Time Management

Set Time Regular System Aug 15, 2015 12:43 PM Appliance Medium Platform event: Platform time was changed from 2014/03/21 03:03 to 2015/08/15 12:43:23 Set NTP Regular System Aug 15, 2015 1:44 PM Appliance Medium Platform event: NTP server(s) changed from none to 98.175.203.200

Configure the TOE advisory notice and consent warning message [CCCC] Section Configuring

the Management Server (MX)

[CCCC] Section Configuring the Gateway

Banner Enabled Regular System Oct 6, 2015 11:56 AM Appliance Medium Platform event: Banner was enabled

12

Management Action Operational Guidance Audit Record Sample Banner Modified Regular System Oct 6, 2015 11:56 AM Appliance Medium Platform event: Banner text was changed

2.1.1.3 Test Activities

NIAP Technical Decision TD0017: NDPP Audit Shutdown 09/29/2014 Issue Description NDPP Errata #2 added the shutdown event to FAU_GEN.1. There are many circumstances under which a TOE may be unable to generate a shutdown audit record. If auditing can never be turned off and the TOE generates a startup audit record, is a separate shutdown audit record even necessary or can the startup audit record be used as the sentinel for demarcation between TOE startups and shutdowns? Resolution In the case of an administrative shutdown, a shutdown audit record must be created according to FAU_GEN.1 c). In the case of an uncontrolled shutdown (e.g., power failure, system is unplugged or powered down), it is likely not possible to create a shutdown audit record. In that case, the creation of the startup audit record is sufficient to indicate that a shutdown event occurred, accounting for the break in the audit records. Justification There are cases where the audit system can only be shut down when the system is shut down. For uncontrolled shutdowns in those cases, the startup audit record can be used to indicate that there was a break in the audit records.

The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed in table 1 and administrative actions. This should include all instances of an event--for instance, if there are several different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be generated for each mechanism.

The evaluator generated and recorded the audit records identified in Table 1 of the NDPP and the administrative actions. Each of the required audit records were captured and recorded. Refer to the evaluation team test report: Imperva SecureSphere Common Criteria Test Report and Procedures for details of the testing of the auditing capabilities of the TOE. The audit records are identified in the Test Report Table 2 and Table 3.

13

The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. If HTTPS is implemented, the test demonstrating the establishment and termination of a TLS session can be combined with the test for an HTTPS session.

The security target states that the only protocol (i.e., HTTPS, TLS, SSH) failures auditable by the TOE are authentication failures for user-level connections. These audit records were captured verified.

Refer to the evaluation team test report: Imperva SecureSphere Common Criteria Test Report and Procedures for details of the testing of the auditing capabilities of the TOE. The audit records are identified in the Test Report Table 2.

For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields in each audit record have the proper entries. Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. For example, testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit records are generated as expected.

The evaluation team performed the testing specified in the assurance activity and confirmed the TOE’s ability to generate the specified audit events. The evaluator generated and recorded the audit records identified in Table 1 of the NDPP and the administrative actions. Each of the required audit records were captured and recorded. Refer to the evaluation team test report: Imperva SecureSphere Common Criteria Test Report and Procedures for details of the testing of the auditing capabilities of the TOE. The audit records generated from administrative actions are identified in the Test Report Table 3.

The evaluator shall check to ensure that the TSS contains a list (possibly empty except for authentication failures for user-level connections) of the protocol failures that are auditable. The evaluator shall test all identified audit events during protocol testing/audit testing.

The security target states that the only protocol (i.e., HTTPS, TLS, SSH) failures auditable by the TOE are authentication failures for user-level connections. These audit records were captured verified.

Refer to the evaluation team test report: Imperva SecureSphere Common Criteria Test Report and Procedures for details of the testing of the auditing capabilities of the TOE. The audit records are identified in the Test Report Table 2.

14

2.1.2 User Identity Association FAU_GEN.2

2.1.2.1 TSS Assurance Activities

This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1.





2.1.3 External Audit Trail Storage (FAU_STG_EXT.1)

2.1.3.1 TSS Assurance Activity

For both types of TOEs (those that act as an audit server and those that send data to an external audit server), there is some amount of local storage. The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally; what happens when the local audit data store is full; and how these records are protected against unauthorized access.

[ST] Section 6.1 states that the TOE includes an internal log implementation that can be used to store and review audit records locally. The local audit logs are stored on the MX Management Server database. By default, the Management Server retains up to 100,000 System Event records, and purges the oldest records when this configurable threshold is exceeded. An authorized Administrator can modify this threshold, or specify a time period for which System Event records must be retained.

TOE is not an audit server

The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided.

[ST] Section 6.1 states that the TOE can be configured to send generated audit records to an external Syslog server using TLS. When configured to send audit records to a syslog server, audit records are also written to the external syslog as they are written to the local audit log.


The evaluator shall also examine the operational guidance to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server (for TOEs that are not acting as an audit log server). For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and

15

“cleared” periodically by sending the data to the audit server.

[CCCC] Chapter 2, Section Configuring Syslog to use Secure Channels, states that when configured to send audit records to an external syslog server, the audit records are written to the local audit log file while simultaneously written to the external syslog server.

[ADM] Section System Events Archive identifies the parameters for configuring the local audit data. The system events are recorded locally as well as sent simultaneously to the syslog server. The default is By Size - Purge Oldest Records When there are more than 100,000 Records, meaning that by default, no more than 100,000 system events are available locally. The locally stored logs can also be purged by Time or by Time and Size.


The evaluator shall examine the operational guidance to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server.

[CCCC] Section Configuring Syslog to use Secure Channels, provides the guidance to configure the trusted channel to secure the communication to the syslog server.



Test 1: The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing.

The evaluator used the Administrative guidance provided to configure the TOE to log to an external Syslog server over TLS. The evaluator ran a Wireshark capture and established a session between the TOE and the external Syslog server. The evaluator verified that the data was sent encrypted and the log reached the syslog server successfully.

2.2 Cryptographic Support (FCS)

2.2.1 Cryptographic Key Generation (for asymmetric keys) (FCS_CKM.1)


The evaluator shall ensure that the TSS contains a description of how the TSF complies with 800-56A and/or 800-56B, depending on the selections made. This description shall indicate the sections in 800-56A and/or 800-56B that are implemented by the TSF, and the evaluator shall ensure that key

16

establishment is among those sections that the TSF claims to implement. 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

The TOE implements a random number generator for RSA key establishment schemes; and for finite-based key establishment (conformant to NIST SP 800-56A and to NIST SP 800-56B).


None Identified


The evaluator shall use the key pair generation portions of "The FIPS 186-3 Digital Signature Algorithm Validation System (DSA2VS)", "The FIPS 186-3 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS)", and either "The RSA Validation System (RSAVS)" (for FIPS 186-2) or “The 186-3 RSA Validation System (RSA2VS)” (for FIPS 186-3) 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.

Section 6.2 of the ST identifies the TOE’s RSA implementation has CAVP validation using “The RSA Validation System (RSAVS)” against FIPS 186-2 and FIPS 186-3, with CAVP certificates RSA #1154 RSA (Certs. #960, #1086, #1145, #1205, #1237, #1273, #1477, #1535 and #1581).

2.2.2 Cryptographic Key Zeroization (FCS_CKM_EXT.4)


The evaluator shall check to ensure the TSS describes each of the secret keys (keys used for symmetric encryption), private keys, and CSPs 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.).

[ST] Section 6.2 states that the TOE zeroizes secret and private keys when they are no longer required by the TOE. The TOE uses the RSA Crypto-J and FIPS 140-2 OpenSSL cryptomodule functions for the zeroization of all ephemeral sensitive data. The TOE itself zeroizes the secret and private keys when they are no longer required by the TOE. The zeroization procedure for each CSP is identified in [ST] Table 5. 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

17

random pattern that is changed before each write").

The zeroization procedure for each CSP is identified in [ST] Table 5.


None defined.


None defined.

2.2.3 Cryptographic Operation (for data encryption/decryption) FCS_COP.1(1)


None defined.


None defined.


The evaluator 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 guide in testing the requirement above. This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test.

Section 6.2 of the ST identifies the TOE’s AES implementation has CAVP validation using “The Advanced Encryption Standard Algorithm Validation System (AESAVS)” against FIPS 197 and NIST SP 800-38A, with CAVP certificates AES #2249 AES (Certs. #1884, #2116, #2234, #2342, #2394, #2484, #2824, #2929 and #3090).

2.2.4 Cryptographic Operation (for cryptographic signature) (FCS_COP.1(2))


None defined.

18


None defined.


The evaluator shall use the signature generation and signature verification portions of "The Digital Signature Algorithm Validation System” (DSA2VS), "The Elliptic Curve Digital Signature Algorithm Validation System” (ECDSA2VS), and "The RSA Validation System” (RSAVS (for 186-2) or RSA2VS (for 186-3)) as a guide in testing the requirement above. The Validation System used shall comply with the conformance standard identified in the ST (i.e., FIPS PUB 186-2 or FIPS PUB 186-3). This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test.

Section 6.2 of the ST identifies the TOE’s RSA implementation has CAVP validation using “The RSA Validation System (RSAVS)” against FIPS 186-2 and FIPS 186-3, with CAVP certificates RSA #1154 RSA (Certs. #960, #1086, #1145, #1205, #1237, #1273, #1477, #1535 and #1581).

2.2.5 Cryptographic Operation (for cryptographic hashing) (FCS_COP.1(3))


None defined.


None defined.


The evaluator shall use "The Secure Hash Algorithm Validation System (SHAVS)" as a guide in testing the requirement above. This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test.

Section 6.2 of the ST identifies the TOE’s secure hash algorithm implementation has CAVP validation using “The Secure Hash Algorithm Validation System (SHAVS)” against FIPS 180-3, with CAVP certificate SHS #1938, SHS (Certs. #1655, #1840, #1923, #2019, #2056, #2102, #2368, #2465 and #2553).

2.2.6 Cryptographic Operation (for keyed-hash message authentication)

(FCS_COP.1(4))


None defined.

19


None defined.


The evaluator 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 evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test.

Section 6.2 of the ST identifies the TOE’s secure hash algorithm implementation has CAVP validation using “The Keyed-Hash Message Authentication Code (HMAC) Validation System (HMACVS)” against FIPS 198 and FIPS 180-3 with CAVP certificate HMAC #1378, HMAC (Certs. #1126, #1288, #1363, #1451, #1485, #1526, #1768, #1856 and #1937).

2.2.7 Extended: Cryptographic Operation (Random Bit Generation) (FCS_RBG_EXT.1)

2.2.7.1 Assurance Activity

Documentation shall be produced—and the evaluator shall perform the activities—in accordance with Annex D, Entropy Documentation and Assessment. The evaluator shall also perform the following tests, depending on the standard to which the RBG conforms.

The Gateway appliances (including virtual appliances) implement a software-based deterministic random bit generator that complies with NIST SP 800-90, using CTR_DRBG (AES) seeded with 256 bits of entropy. On the X10K, X2510, and X8510 appliances, the entropy source is the RDRAND instruction provided by Intel Ivy Bridge-based processors, which is assumed to provide 0.5 bits of entropy per bit sample. The same entropy source is also used on virtual gateway appliances, which require an Ivy Bridge-based processor on the hosting hardware. On X1010, X2010, X4510, and X6510 appliances, the entropy source is an Infineon SLB96xx Trusted Platform Module (TPM) processor, which is assumed to provide 1 bit of entropy per bit sample (i.e., full entropy).

In depth entropy analysis is provided in the proprietary Imperva Common Criteria – Entropy Solution document.


None defined.


None defined.

20

[CCCC] Page 53, Section Common Criteria states: “To comply with the Common Criteria standard demanding that encryption must use highly randomized bits, you need to use the IMPCTL entropy commands. Since some computer systems do not generate enough randomness by default on their own, SecureSphere must be configured to supply the required randomness. Therefore, you need to use the IMPCTL entropy commands to enable SecureSphere discover and configure the hardware source (Trusted Platform Module (TPM) or RdRand) that lets it generate the required randomness.

[CCCC] Section Common Criteria Commands, identifies the commands to set the entropy configuration:

Command Description impctl security entropy --config=<option> Enable or disable entropy source discovery

and configuration. <option> is enable or disable

impctl security entropy --show Display current entropy configuration.

impctl security entropy --status Display current entropy status (TPM or RdRand)


Implementations Conforming to NIST Special Publication 800-90

The evaluator shall perform 15 trials for the RNG implementation. If the RNG is configurable, the evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that the operational guidance contains appropriate instructions for configuring the RNG functionality. If the RNG has prediction resistance enabled, each trial consists of (1) instantiate drbg, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. “Generate one block of random bits” means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP 800-90). If the RNG does not have prediction resistance, each trial consists of (1) instantiate drbg, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The fifth value is additional input to the first call to generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call. The following paragraphs contain more information on some of the input values to be generated/selected by the evaluator.

21

Entropy input: the length of the entropy input value must equal the seed length. Nonce: If a nonce is supported (CTR_DRBG with no df does not use a nonce), the nonce bit length is one-half the seed length. Personalization string: The length of the personalization string must be <= seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not use a personalization string, no value needs to be supplied. Additional input: the additional input bit lengths have the same defaults and restrictions as the personalization string lengths.

Section 6.2 of the ST identifies the TOE’s random bit generation implementation has CAVP validation for NIST SP 800-90A using CTR_DRBG (AES) with CAVP certificate # DRBG # 273, DRBG (Certs. #157, #229, #264, #292, #316, #342, #485, #540 and #607).

2.2.8 Explicit: HTTPS (FCS_HTTPS_EXT.1)


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.

[ST] Section 6.2 states that the TOE supports HTTP over TLS web-based secure administrator sessions. The TOE’s implementation of the HTTPS protocol complies with RFC 2818 and is implemented using TLS 1.0 (RFC 2246), TLS 1.1 (RFC 4346), TLS 1.2 (RFC 5246) using the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.


None Defined.


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.

This test was performed by testing FCS_TLS_EXT.1 over HTTPS/TLS.

2.2.9 Explicit: TLS (FCS_TLS_EXT.1)


The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that ciphersuites supported are specified.

22

[ST] Section 6.2 states that the TOE uses the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.

The evaluator shall check the TSS to ensure that the ciphersuites specified are identical to those listed for this component.

[ST] Section 6.2 states that the TOE uses the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. The TSS description is identical to the description in the SFR.


The evaluator shall also check the operational guidance to ensure that it contains instructions on configuring the TOE 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).

[CCCC] Section Configuring the Management Server (MX), provides the instructions to configure the MX to use only the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. [CCCC] Section Configuring the Gateway, provides the instructions to configure the Gateway to use only the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.


Test 1: The evaluator shall establish 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 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).

The evaluator configured the TOE to use only the supported ciphersuite. The evaluator ran a Wireshark capture and attempted to establish a HTTPS/TLS session with the TOE with the claimed ciphersuite. The evaluator verified that the TLS session was negotiated successfully. NIAP Technical Decision TD0004: FCS_TLS_EXT Man-in-the-Middle Tests 05/28/2014 Issue Description The man-in-the-middle testing in FCS_TLS_EXT requires tools that can sniff the TCP traffic and modify the packets on the fly. Currently, no tools have been identified that will allow these test to be performed practically, reliably, and repeatedly. Resolution Remove the FCS_TLS_EXT man-in-the-middle tests for the NDPP (FCS_TLS_EXT.1.1, Test 2) and

23

the MDFPP (FCS_TLS_EXT.1, Test 5, FCS_TLS_EXT.2, Test 5) Justification New TLS requirements and assurance activities are being drafted to address 112-bit security strengths and those changes would likely involve splitting client requirements from server requirements. CCEVS expects to develop tests similar to these that address the required elements of the TLS RFCs and will consider the providing tools or additional guidance to the labs regarding how these tests are performed as we draft them. Once incorporated in the PPs, the man-in-the-middle testing will be mandatory.

Test 2: The evaluator shall setup a man-in-the-middle tool between the TOE and the TLS Peer and shall perform the following modifications to the traffic:

• [Conditional: TOE is a server] Modify at least one byte in the server’s nonce in the Server Hello handshake message, and verify that the server denies the client’s Finished handshake message.

• [Conditional: TOE is a client] Modify the server’s selected ciphersuite in the Server Hello handshake message to be a ciphersuite not presented in the Client Hello handshake message. The evaluator shall verify that the client rejects the connection after receiving the Server Hello.

• [Conditional: TOE is a client] If a DHE or ECDHE ciphersuite is supported, modify the

signature block in the Server’s KeyExchange handshake message, and verify that the client rejects the connection after receiving the Server KeyExchange.

• [Conditional: TOE is a client] Modify a byte in the Server Finished handshake message, and verify that the client sends a fatal alert upon receipt and does not send any application data.

Test 2 Not Required per NIAP Technical Decision TD0004.

2.2.10 Explicit: FCS_SSH_EXT.1 (FCS_SSH_EXT.1.1)


None defined.


None defined.

24


None defined.


NIAP Technical Decision TD0032: Update to FCS_SSH_EXT.1.2 1/28/2015 Issue Description FCS_SSH_EXT.1.2 requires the support of both password-based and public key-based authentication. A distributed TOE is likely to support communication between its components via SSH public key-based authentication only. This requirement prevents any CCTL from testing Test 2 of FCS_SSH_EXT.1.2 (configuring and using SSH password-based authentication) for TOE component-to-component communication that is public key-based only. Resolution FCS_SSH_EXT.1.2 will be rewritten to conditionally require password-based authentication as shown below:

FCS_SSH_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following authentication methods as described in RFC 4252: public key-based, [selection: password-based, none].

Application Note: The ST author can choose "none" from the selection if the TOE uses SSH for FPT_ITT. The ST author must choose "password-based" from the selection if the TOE uses SSH for FTP_ITC or FTP_TRP. ,.


Updated per TD0032 The evaluator shall check to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication, that this list conforms to FCS_SSH_EXT.1.5, and ensure that password-based authentication methods are also allowed if SSH is selected for FTP_ITC and FTP_TRP.

[ST] Section 6.2 states that the TOE uses the RSA public key algorithm and supports diffie-hellman-group14-sha1 key exchange method. The description in the TSS conforms to FCS_SSH_EXT.1.5. The TOE supports both public-key and password based authentication.


Updated per TD0032 The evaluator shall check to ensure that the operational guidance contains instructions to the

25

administrator to configure SSH to support all uses identified in the ST (e.g., use to support distributed TOE functionality, use to support trusted path for administrators).

[CCCC] Section Configuring the Management Server (MX), provides the instructions to configure the MX to use the correct ciphersuites for SSH communication.

[CCCC] Section Configuring the Gateway, provides the instructions to configure the Gateway to use the correct ciphersuites for SSH communication.

[CCCC] Section Configuring SSH to Accept Login using Keys, provides the instructions to configure SSH to accept specific users using secret keys instead of a username and password. Instructions are also provided to logon using password based authentication.


NIAP Technical Decision TD0012: FCS_SSH_EXT.1 Conflict Resolution 09/09/2014 Issue Description When a TOE claims conformance to the SSH requirements in the NDPP with Errata #2, there is a conflict between the requirements in FCS_SSH_EXT.1.1 and FCS_SSH_EXT.1.4. FCS_SSH_EXT.1.1 requires conformance to SSH RFCs that mandate use of algorithms (e.g., 3DES-CBC in RFC 4253) not listed in FCS_SSH_EXT.1.4. The Assurance Activities for FCS_SSH_EXT.1.4 imply that the supported algorithms should be restricted to those listed in the requirement, causing the conflict. Background The statement of FCS_SSH_EXT.1.1 in [ERRATA] and [NDPP] specifies:

The TSF shall implement the SSH protocol that complies with RFCs 4251, 4252, 4253, and 4254, and [selection: 5656, 6668, no other RFCs].

The statement of FCS_SSH_EXT.1.4 in [ERRATA] and [NDPP] specifies:

The TSF shall ensure that the SSH transport implementation uses the following encryption algorithms: AES-CBC-128, AES-CBC-256, [selection: AEAD_AES_128_GCM, AEAD_AES_256_GCM, no other algorithms].

As seen from comparing the two requirement statements, FCS_SSH_EXT.1.4 requires only the listed algorithms be utilized by the TOE, while compliance with the RFCs mandated by FCS_SSH_EXT.1.1 requires use of algorithms not listed in FCS_SSH_EXT.1.4. Resolution Algorithms not identified in FCS_SSH_EXT.1.4 must not be allowed; other cipher suites (such as 3DES-CBC) must be disabled in evaluated configurations. The Assurance Activities associated with

26

this requirement must verify that connection attempts with algorithms not listed in FCS_SSH_EXT.1.4 are denied. The NDPP will be updated to reflect this decision. Effective Date Evaluations with an official scheme start date after 13 October 2014 must conform to this Technical Decision.

Updated per TD0032 The evaluator shall also perform the following tests for each use of the SSH mechanism (e.g., if the SSH mechanism was used for distributed TOE support using certificates only as well as for administrator trusted path using either certificates or passwords, the evaluator would perform Test 1 twice and Test 2 once) : Test 1: The evaluator shall, for each public key algorithm supported, show that the TOE supports the use of that public key algorithm to authenticate a user connection. Any configuration activities required to support this test shall be performed according to instructions in the operational guidance.

The evaluator generated an SSH RSA public key to be tested. The evaluator configured the TOE to accept the use of the public key for authentication. The evaluator attempted to authenticate an SSH session using the generated public key and verified that it was successful. Updated per TD0032 The evaluator shall also perform the following tests for each use of the SSH mechanism (e.g., if the SSH mechanism was used for distributed TOE support using certificates only as well as for administrator trusted path using either certificates or passwords, the evaluator would perform Test 1 twice and Test 2 once) : Test 2 [conditional]: Using the operational guidance, the evaluator shall configure the TOE to accept password-based authentication, and demonstrate that a user can be successfully authenticated to the TOE over SSH using a password as an authenticator.

The evaluator enabled SSH on the TOE. The evaluator established an SSH session and authenticated using the correct username and password. The evaluator verified that the login was successful.



The evaluator shall check that the TSS describes how “large packets” in terms of RFC 4253 are detected and handled.

27

[ST] Section 6.2 states that the TOE manages a packet counter for each SSH session such that packets larger than the 256K bytes packet limit are dropped.


None defined.


Test 1: The evaluator shall demonstrate that if the TOE receives a packet larger than that specified in this component, that packet is dropped.

The evaluator used Putty to establish an SSH session with the TOE. The evaluator used Putty to send a very large packet to the TOE over SSH. The evaluator viewed that the SSH session was terminated when the TOE received the large packet.


NIAP Technical Decision TD0011: Clarification on FCS_SSH_EXT.1.4 08/27/2014 Issue Description The SFR requires that the SSH transport implementation use specific encryption algorithms. Can the restriction to those algorithms be reliant upon configuration of the SSH client? Resolution No. The restrictions must be implemented by the TOE. Justification The SFR clearly states that “The TSF shall ensure”. Hence, although a compatible client configuration is necessary for negotiations to succeed, the restrictions must be enforced by the TOE.


The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the encryption algorithms supported are specified as well.

The TOE supports SSHv2 with AES (CBC) 128 or 256 bit ciphers, in conjunction with HMAC-SHA-1. The TOE SSH implementation complies with RFCs 4251, 4252, 4253, and 4254, 5656.

28

The evaluator shall check the TSS to ensure that the encryption algorithms specified are identical to those listed for this component.

The encryption algorithms identified in the TSS are identical to those listed in the security requirement.


The evaluator shall also check the operational guidance to ensure that it contains instructions on configuring the TOE so that SSH conforms to the description in the TSS (for instance, the set of algorithms advertised by the TOE may have to be restricted to meet the requirements).

[CCCC] Section Configuring the Management Server (MX), provides the instructions to configure the SSH algorithms in the sshd_config file for the following:

KexAlgorithms diffie-hellman-group14-sha1

Ciphers aes128-cbc, aes256-cbc

MACs hmac-sha1

[CCCC] Section Configuring the Gateway, provides the instructions to configure the SSH algorithms in the sshd_config file for the following:



MACs hmac-sha1


Test 1: The evaluator shall establish a SSH connection using each of the encryption algorithms specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test.

The evaluator configured SSH to use the algorithms AES128-CBC and AES256-CBC. The evaluator ran a Wireshark capture and attempted to establish an SSH connection using each of these algorithms. The evaluator verified that the connection was established successfully.



The assurance activity associated with FCS_SSH_EXT.1.4 verifies this requirement.



29





The evaluator shall check the TSS to ensure that it lists the supported data integrity algorithms, and that that list corresponds to the list in this component.

The TOE supports SSHv2 with AES (CBC) 128 or 256 bit ciphers, in conjunction with HMAC-SHA-1. The data integrity algorithm identified in the TSS corresponds to the data integrity algorithm identified in the security requirement.


The evaluator shall also check the operational guidance to ensure that it contains instructions to the administrator on how to ensure that only the allowed data integrity algorithms are used in SSH connections with the TOE (specifically, that the “none” MAC algorithm is not allowed).




MACs hmac-sha1




MACs hmac-sha1


Test 1: The evaluator shall establish a SSH connection using each of the integrity algorithms specified by the requirement. It is sufficient to observe (on the wire) the successful negotiation of the algorithm to satisfy the intent of the test.

The evaluator configured SSH on the TOE to use hmac-sha1. The evaluator established an SSH connection with the TOE and verified that hmac-sha1 was the integrity algorithm used.

30



The evaluator shall ensure that operational guidance contains configuration information that will allow the security administrator to configure the TOE so that all key exchanges for SSH are performed using DH group 14 and any groups specified from the selection in the ST. If this capability is “hard-coded” into the TOE, the evaluator shall check the TSS to ensure that this is stated in the discussion of the SSH protocol.

The key exchanges for SSH using DH group 14 are not “hard-coded”. The configuration information is provided in the guidance documents.


The evaluator shall ensure that operational guidance contains configuration information that will allow the security administrator to configure the TOE so that all key exchanges for SSH are performed using DH group 14 and any groups specified from the selection in the ST. If this capability is “hard-coded” into the TOE, the evaluator shall check the TSS to ensure that this is stated in the discussion of the SSH protocol.




MACs hmac-sha1




MACs hmac-sha1


Test 1: The evaluator shall attempt to perform a diffie-hellman-group1-sha1 key exchange, and observe that the attempt fails. For each allowed key exchange method, The evaluator shall then attempt to perform a key exchange using that method, and observe that the attempt succeeds.

The evaluator attempted to establish an SSH session using the diffie-hellman-group1-sha1 key exchange and viewed that the attempt failed. The evaluator then attempted an SSH session using diffie-hellman-group14-sha1 and viewed that the attempt succeeded.

2.3 User Data Protection (FDP)

31

2.3.1 Full Residual Information Protection (FDP_RIP.2)


The evaluator shall check to ensure that the TSS describes packet processing to the extent that they can determine that no data will be reused when processing network packets. The evaluator shall ensure that this description at a minimum describes how the previous data are zeroized/overwritten, and at what point in the buffer processing this occurs.

[ST] Section 6.3 states that TOE is designed to ensure that it does not inadvertently reuse data found in network traffic. Previous information is made unavailable to next user during construction of the new packet. The TOE does not include any padding or gaps within packets, and therefore all information that the next user receives is the information intended for it. The next user will only receive the information written in the packet for the new user.


None defined.


None defined.

2.4 Identification and Authentication (FIA)

2.4.1 Password Management (FIA_PMG_EXT.1)


None defined.


The evaluator shall examine the operational guidance to determine that it provides guidance to security administrators on the composition of strong passwords, and that it provides instructions on setting the minimum password length.

[CCCC] Section Password Strength, identifies the impctl commands that are used to set security password strength and minimum password length.

[CCCC] Section Configuring the Management Server (MX), identifies the requirement that passwords must be 15 characters and consist of upper-case, lower-case, digits and special characters.

32


Test 1: The evaluator shall compose passwords that either meet the requirements, or fail to meet the requirements, in some way. For each password, the evaluator shall verify that the TOE supports the password. While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all characters, rule characteristics, and a minimum length listed in the requirement are supported, and justify the subset of those characters chosen for testing.

The evaluator set the minimum password length to 15 and attempted to reset the password with a length of less than 15. The evaluator verified that the password reset attempt failed. The evaluator then attempted to reset the password to several passwords with a length of greater than 15. The evaluator made sure to use a significant sample of the allowed letters, numbers, and special characters to show that the password changes were successful.

2.4.2 User Identification and Authentication (FIA_UIA_EXT.1)


The evaluator shall examine the TSS to determine that it describes the logon process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the product. This description shall contain information pertaining to the credentials allowed/used, any protocol transactions that take place, and what constitutes a “successful logon”.

[ST] Section 6.4 states that the TOE is designed to require users to be identified and authenticated before they can access any of the TOE functions. Administrators manage the TOE remotely using a web-based GUI accessed via HTTPS. Administrators can also connect to the TOE locally using a directly connected console. However the TOE is not intended to be managed locally. For each session, the user is required to log in prior to successfully establishing a session through which TOE functions can be exercised. After a user enters their credentials but prior to a session being established, the TOE displays an advisory warning banner.


The evaluator shall examine the operational guidance to determine that any necessary preparatory steps (e.g., establishing credential material such as pre-shared keys, tunnels, certificates, etc.) to logging in are described.

[CCCC] Section Create a Self-signed Key to be used by Stunnel, provides the guidance to create a certificate by using OpenSSL tools.

[CCCC] Section Configuring SSH to Accept Login using Keys, to configure SSH to accept specific users using secret keys instead of a username and password.

For each supported login method, the evaluator shall ensure the operational guidance provides clear instructions for successfully logging on.

33

[ADM] v11.5 Section Logging In and Out of the WebGUI provides the guidance for a user to login and logout of the TOE by the Web GUI.

[ADM] v11.5 Section Serial Console Access to SecureSphere, provides the steps an administrator must take in order interact with SecureSphere’s Command Line Interfaces (CLIs) through a serial console.

[ADM] v11.5 Section Before You Begin: Checking OS Layer Serial Console Access, provides the guidance to logon via the serial console.

If configuration is necessary to ensure the services provided before login are limited, the evaluator shall determine that the operational guidance provides sufficient instruction on limiting the allowed services.

The TOE does not permit access to the TSF prior to a user’s identification and authentication. Instructions to limit services prior to login are not required. [CCCC] Section Configuring the Management Server (MX) states that the banner is displayed after entering credentials but you cannot do anything applicative until you accept it.


Test 1: The evaluator shall use the operational guidance to configure the appropriate credential supported for the login method. For that credential/login method, the evaluator shall show that providing correct I&A information results in the ability to access the system, while providing incorrect information results in denial of access.

The evaluator created a new administrative user to be authenticated locally with username and password. The evaluator verified that the new user was authenticated successfully. The evaluator also configured the use of an external LDAP server and created a new LDAP user to authenticate with. The evaluator verified that the LDAP user authenticated successfully to the TOE.

Test 2: The evaluator shall configure the services allowed (if any) according to the operational guidance, and then determine the services available to an external remote entity. The evaluator shall determine that the list of services available is limited to those specified in the requirement.

The evaluator verified that the only service available before login is viewing the external warning banner.

Test 3: For local access, the evaluator shall determine what services are available to a local administrator prior to logging in, and make sure this list is consistent with the requirement.

The evaluator verified that the only service available before login is viewing the external warning banner.

34

2.4.3 Extended: Password-based Authentication Mechanism (FIA_UAU_EXT.2)


Assurance activities for this requirement are covered under those for FIA_UIA_EXT.1. If other authentication mechanisms are specified, the evaluator shall include those methods in the activities for FIA_UIA_EXT.1.





2.4.4 FIA_UAU.7 Protected Authentication Feedback


None defined.


None defined.


Test 1: The evaluator shall locally authenticate to the TOE. While making this attempt, the evaluator shall verify that at most obscured feedback is provided while entering the authentication information.

The evaluator attempted to login to the TOE using username and password. The evaluator viewed that the password was obscured as it was entered.

35

2.5 Security Management (FMT)

2.5.1 FMT_MTD.1 Management of TSF Data (for general TSF data)


The evaluator shall examine the TSS to determine that, for each administrative function identified in the operational guidance; those that are accessible through an interface prior to administrator log-in are identified. For each of these functions, the evaluator shall also confirm that the TSS details how the ability to manipulate the TSF data through these interfaces is disallowed for non-administrative users.

[ST] Section 6.5 that security management commands are limited to administrators and are available only after they have provided acceptable user identification and authentication data to the TOE. The TOE controls user access to the TOE and resources based on user role. Users are given permission to access a set of commands and resources based on their user role. Users with the Administrator role are capable of managing the security functions of the TOE. The TOE includes other pre-defined roles that represent logical subsets of the Administrator role. Only users with the Administrator role can manage all aspects of the TOE.


The evaluator shall review the operational guidance to determine that each of the TSF-data-manipulating functions implemented in response to the requirements of this PP is identified, and that configuration information is provided to ensure that only administrators have access to the functions.

The TOE includes the following security management functions:

a. Configure the TOE banners The function control is limited to only administrators. The administrator must log on and open a shell in the MX and the Gateway.

[CCCC] Section Configuring the Management Server (MX), provides the guidance to configure the access banner on the MX.

Open a shell on the MX and enter the command: impctl security banner config –-text="<Text>"

[CCCC] Section Configuring the Gateway, provides the guidance to configure the access banner.

Open a shell on the Gateway and enter the command: impctl security banner config –-text="<Text>"

b. Enable/disable FIPS mode

The function is limited to only administrators. The Administrator must be in the Admin workspace and click System Definitions to access the function. [CCCC] Section Activating FIPS Mode provides the guidance to enable/disable the FIPS mode of operation.

36

c. Configure the crypto algorithms

The function control is limited to only administrators. The administrator must log on and open a shell in the MX and the Gateway. [CCCC] Section Configuring the Management Server (MX) and [CCCC] Section Configuring the Gateway provide the guidance to configure the TOE to use the TLS_RSA_WITH_AES_128_CBC_SHA cipher.

d. Configure TLS secure connections for external user LDAP authentication

[ADM] v11.5 Section External System - LDAP Authentication and Authorization provides the guidance to configure the TOE to encrypt the communication link to the LDAP server.

[ADM] v11.5 Section Creating a SecureSphere User provides the guidance to create a user and to use SecureSphere or External Authorization (LDAP).

[ADM] v11.5 Section External Systems - LDAP provides the guidance to define the external LDAP system. Included in the configuration parameters is the setting to Use SSL - Specifies whether to connect to the external system using SSL.

e. Configure user session timeout The function control is limited to only administrators. The administrator must log on and open a shell in the MX and the Gateway. [CCCC] Section Configuring the Management Server (MX), provides the guidance to configure the idle timeout session for the MX for both the SSH users and the GUI users. [CCCC] Section Configuring the Gateway, provides the guidance to configure the idle timeout session for the Gateway.

f. Manage and verify updates of the TOE software.

[UPGUIDE] Section Downloading and Verifying SecureSphere Software provides the guidance to download and verify the software updates. Imperva supplies an MD5 and SHA-256 files to be used for verification with the corresponding binary installation files. The guidance identifies the procedures to verify the download using the SHA-256.

g. Ability to configure the cryptographic functionality to establish an Internet connection to

perform various updates.

[UPGUIDE] v11.5 Section Downloading and Verifying SecureSphere Software provides to the guidance for SecureSphere to establish an Internet connection to download and verify the updates.

h. Time Management

[CCCC] Section Time Management provides the guidance change the date, time, and time zone.

[CCCC]Section Time Servers provides the guidance to add and delete NTP Servers. The administrator will be prompted to enter the IP address of the NTP server to be added.

37


None defined.

2.5.2 FMT_SMF.1 Specification of Management Functions


The security management functions for FMT_SMF.1 are distributed throughout the PP and are included as part of the requirements in FMT_MTD, FPT_TST_EXT, and any cryptographic management functions specified in the reference standards. Compliance to these requirements satisfies compliance with FMT_SMF.1.





2.5.3 FMT_SMR.2 Restrictions on Security Roles


None defined.


The evaluator shall review the operational guidance to ensure that it contains instructions for administering the TOE both locally and remotely, including any configuration that needs to be performed on the client for remote administration.

[ADM] v11.5 Section Working with Roles identifies the pre-defined roles as the Administrator and Web/DB/File/SharePoint Security Admin. The Administrator role is considered a ‘Security Administrator’ as defined in the NDPP. Users with the Administrator role are capable of managing the security functions of the TOE. The TOE is also capable of creating custom roles with assigned permissions as needed by the deployment.

38

[ADM] v11.5 Section Logging In and Out of the WebGUI, provides the guidance to login and logout of the WebGUI. The administrator can remotely manage the TOE through the Web GUI. [ADM] Section The Admin Workspace, provides the guidance to remotely administer the TOE. The Admin Workspace provides the administrator to perform the following tasks: install SecureSphere licenses, define SecureSphere administrators, users and their privileges, configure SecureSphere to download content from Imperva’s ADC (Application Defense Center), define system-wide parameters, track jobs initiated by SecureSphere, Export SecureSphere system data, maintain archives etc., and monitor system performance.

[ADM] v11.5 Section Initial Configuration, states that the initial configuration of the TOE is accomplished by the administrator logging on through the CLI.


In the course of performing the testing activities for the evaluation, the evaluator shall use all supported interfaces, although it is not necessary to repeat each test involving an administrative action with each interface. The evaluator shall ensure, however, that each supported method of administering the TOE that conforms to the requirements of this PP be tested; for instance, if the TOE can be administered through a local hardware interface; SSH; and TLS/HTTPS; then all three methods of administration must be exercised during the evaluation team’s test activities.

The evaluator performed testing on all of the supported interfaces. Testing was done for FCS_SSH_EXT.1 and FCS_TLS_EXT.1. Additionally testing was performed through local console access.

2.6 Protection of the TSF (FPT)

2.6.1 Extended: Protection of TSF Data (for reading of all symmetric keys)

FPT_SKP_EXT.1


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.

[ST] Table 5 identifies the details how the pre-shared keys, symmetric keys, and private keys are stored. Administrator passwords for users with local authentication are stored as SHA-512 hash in a database located on the MX Management Server.

The TOE is designed specifically to prevent access to locally-stored cryptographically protected passwords and does not disclose any keys stored in the TOE. The TOE protects user passwords as follows. User and administrator passwords are hashed with SHA-512. Keys are encrypted using the default Java algorithm, which is PBEWithMD5AndTripleDES. The TOE does not offer any functions that will disclose to any users a stored cryptographic key or password.

39


None defined.


None defined.

2.6.2 Extended: Protection of Administrator Passwords FPT_APW_EXT.1


The evaluator shall examine the TSS to determine that it details all authentication data that are subject to this requirement, and the method used to obscure the plaintext password data when stored.

The TOE does not offer any functions that will disclose to any user a plain text password. Passwords and keys are stored in cryptographically protected from within the TOE. User and administrator passwords are hashed with SHA-512. Keys are encrypted using the default Java algorithm, which is PBEWithMD5AndTripleDES. The TOE does not offer any functions that will disclose to any users a stored cryptographic key or password.

The TSS shall also detail passwords 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.

The TOE does not offer any functions that will disclose to any user a plain text password. Passwords and keys are stored in cryptographically protected from within the TOE.


None defined.


None defined.

2.6.3 FPT_STM.1 Reliable Time Stamps


The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time. The TSS provides a description of how the time is maintained and considered reliable in the context of each of the time related functions.

The TOE’s embedded OS manages the clock and exposes administrator clock-related functions. The clock is used for audit record time stamps, measuring session activity for termination, and for

40

cryptographic operations based on time/date. The TOE requires an NTP Server in the operational environment in order to synchronize its clock with that of the external time server.


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.

[CCCC] Section Time Management provides the guidance change the date, time, and time zone.

[CCCC] Section Time Servers provides the guidance add and delete NTP Servers. The administrator will be prompted to enter the IP address of the NTP server to be added.


Test 1: The evaluator uses the operational guide to set the time. The evaluator shall then use an available interface to observe that the time was set correctly.

The evaluator verified the time and then attempted to set the time to something new. The evaluator verified the time again and observed that it had changed successfully.

Test 2: [conditional] If the TOE supports the use of an NTP server; the evaluator shall use the operational guidance to configure the NTP client on the TOE, and set up a communication path with the NTP server. The evaluator will observe that the NTP server has set the time to what is expected. If the TOE supports multiple protocols for establishing a connection with the NTP server, the evaluator shall perform this test using each supported protocol claimed in the operational guidance.

The evaluator verified the time and then configured the TOE to sync with an NTP server. The evaluator verified the time again and observed that the time had synced with the NTP server successfully.

2.6.4 Extended: Trusted Update (FPT_TUD_EXT.1)


Updates to the TOE either have a hash associated with them, or are signed by an authorized source. If digital signatures are used, the definition of an authorized source is contained in the TSS, along with a description of how the certificates used by the update verification mechanism are contained on the device. The evaluator ensures this information is contained in the TSS.

The TOE provides functions to query and upgrade the TOE versions. SHA-256 hash is used to ensure the integrity of each upgrade prior to performing the upgrade.

The evaluator also ensures that the TSS (or the operational guidance) describes how the candidate updates are obtained; the processing associated with verifying the digital signature or calculating the

41

hash of the updates; and the actions that take place for successful (hash or signature was verified) and unsuccessful (hash or signature could not be verified) cases.

MX and Gateway software updates can be downloaded from the TOE Update Server using a secure TLS connection. A software update installation package is hashed by Imperva using SHA-256 hash. Administrators with proper credentials are able to download the update package and can verify the hash prior to installing the update. If the verification fails, it is assumed that the download was corrupted and the administrator is instructed not to install the package. There are no automatic installation procedures available.


The evaluator also ensures that the TSS (or the operational guidance) describes how the candidate updates are obtained; the processing associated with verifying the digital signature or calculating the hash of the updates; and the actions that take place for successful (hash or signature was verified) and unsuccessful (hash or signature could not be verified) cases.

[UPGUIDE] Section Downloading and Verifying SecureSphere Software provides the guidance to download and verify the software updates. Imperva supplies an MD5 and SHA-256 files to be used for verification with the corresponding binary installation files. The guidance identifies the procedures to verify the download using the SHA-256.


Test 1: The evaluator performs the version verification activity to determine the current version of the product. The evaluator obtains a legitimate update using procedures described in the operational guidance and verifies that it is successfully installed on the TOE. Then, the evaluator performs a subset of other assurance activity tests to demonstrate that the update functions as expected. After the update, the evaluator performs the version verification activity again to verify the version correctly corresponds to that of the update.

The evaluator obtained a legitimate update an attempted to install it. The evaluator observed that the update was installed successfully.

NIAP Technical Decision TD0026: Update to FPT_TUD_EXT.1 11/26/2014 Issue Description FPT_TUD_EXT.1 as currently written has a test Assurance Activity that instructs the evaluator to verify that the TOE rejects an illegitimate update. This does not allow for the case where the administrator follows the instructions in the operational guidance and rejects an illegitimate update. Resolution The Test 2 Assurance Activity should be rewritten as follows:

42

Test 2: The evaluator performs the version verification activity to determine the current version of the product. The evaluator obtains or produces an illegitimate update, and attempts to install it on the TOE. The evaluator verifies that the TOE either rejects the update without intervention or detects that the update is illegitimate and allows the administrator to reject the update (as specified in the operational guidance).

Justification The intent of this requirement is that either the TOE rejects the corrupt update without any administrator intervention or the TOE detects a corrupt update and the administrator is instructed by the operational guidance to reject the update. The modification adds the option for administrator intervention.

Test 2: The evaluator performs the version verification activity to determine the current version of the product. The evaluator obtains or produces an illegitimate update, and attempts to install it on the TOE. The evaluator verifies that the TOE either rejects the update without intervention or detects that the update is illegitimate and allows the administrator to reject the update (as specified in the operational guidance).

The evaluator modified the legitimate update using a hex editor. The evaluator attempted to install the modified update. The evaluator observed that the update failed.

2.6.5 FPT_TST_EXT.1: TSF Testing


The evaluator shall examine the TSS to ensure that it details the self tests that are run by the TSF on start-up; this description should include an outline of what the tests are actually doing (e.g., rather than saying "memory is tested", a description similar to "memory is tested by writing a value to each memory location and reading it back to ensure it is identical to what was written" shall be used).

The TOE includes FIPS validated OpenSSL and RSA BSAFE and as such runs the same suite of self-tests included with these packages during initial start-up (on power on) to demonstrate the correct operation of the cryptographic procedures of the TOE. The FIPS policies for OpenSSL and RSA BSAFE provide greater details on the execution of the self-tests.

The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the TSF is operating correctly.

The TSS references the FIPS policies for OpenSSL and RSA BSAFE. The security policy states that if the power-up self-test fails, the module is disabled and throws a SecurityException. The module cannot be used within the current JVM. If the conditional self-test fails, the module throws a SecurityException and aborts the operation.


The evaluator shall also ensure that the operational guidance describes the possible errors that may

43

result from such tests, and actions the administrator should take in response; these possible errors shall correspond to those described in the TSS.

[CCCC] Section FIPS 140 Compliance, states that the SecureSphere uses FIPS-certified encryption modules to perform cryptographic operations within the cryptographic boundary. The cryptographic modules used by SecureSphere are compiled and operated in FIPS mode and perform the appropriate self-tests at initialization.


None defined.

2.6.6 FPT_ITT.1 Basic Internal TSF Data Transfer Protection


The evaluator shall examine the TSS to determine that the methods and protocols used to protect distributed TOE components are described. The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST.

[ST] Section 6.6 states that the TOE protects TSF data from disclosure and detects its modification when it is transmitted between separate parts of the TOE through the use of TLS/HTTPS. Communication between TOE components uses HTTP over TLS for TOE configuration, management and monitoring. The TSS is consistent with the security requirement.


The evaluator shall confirm that the operational guidance contains instructions for establishing the communication paths for each supported method.

The TOE protects the transmission of the TSF data through separate parts of the TOE through the use of TLS/HTTPS. [CCCC] pages 25 – 27 provides the guidance to use only TLS_RSA_WITH_AES_128_CBC_SHA for communication with other SecureSphere components. The TSF data is protected by the following communication paths:

Distributed TOE Components

[CCCC] Section Configuring the Management Server (MX) provides the guidance to configure the Management Server to use only TLS_RSA_WITH_AES_128_CBC_SHA for communication with other SecureSphere components.

[CCCC] Section Configuring the Gateway provides the guidance to configure the Gateway to use only TLS_RSA_WITH_AES_128_CBC_SHA for communication with other SecureSphere components.

GUI

44

[ADM] Section Connecting to the Management Server, identifies the guidance to connect securely to the TOE via a browser.

Configure SecureSphere using the GUI, connect to the Management Server by pointing your browser to https://<IP address>:8083, where <IP address> is the IP address of the management port on the MX.

Syslog

[CCCC] Section Create a Self-signed Key to be used by Stunnel provides the guidance to configure the trusted channel to secure the communication to the syslog server.

[CCCC] Section Configure SecureSphere to Send Syslog Messages to Stunnel provides the guidance for the SecureSphere to send syslog messages to the stunnel. Stunnel can be used to encrypt syslog messages from both GW (audit, security events...) and MX (alerts, system events...).

Authentication Server

[ADM] Section Creating a SecureSphere User provides the guidance to create a user and to use SecureSphere or External Authorization (LDAP). [ADM] Section External Systems - LDAP provides the guidance to define the external LDAP system. Included in the configuration parameters is the setting to Use SSL - Specifies whether to connect to the external system using SSL.

[ADM] Section External System - LDAP Authentication and Authorization included in the configuration parameters is the setting to Use SSL - Select to specify that communication with LDAP servers is encrypted.

TOE Update Server

[ADM] Section Downloading and Verifying SecureSphere Software provides to the guidance for SecureSphere to establish an Internet connection to perform various updates.


Test 1: The evaluators shall ensure that communications using each specified (in the operational guidance) communications method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.

The evaluator set up the TOE to communicate internally with TLS.

Test 2: The evaluator shall ensure, for each method of communication, the channel data is not sent in plaintext.

The evaluator ran a Wireshark capture and attempted to send data across the TOE. The evaluator observed that the data sent to other parts of the TOE was encrypted.

45

NIAP Technical Decision TD0005: FPT_ITT Test 3 Resolution 06/18/2014 Issue Description In the NDPP Errata #2, they removed test 3 (channel data modification test) in the FPT_ITC and FPT_TRP, but not for FPT_ITT. I think this is an omission in the Errata. FPT_ITC and FPT_TRP are for external communications between the TOE and external entities. If test 3 is needed, it should be for these connections because they travel through the Internet and are more likely to be modified or tampered with. FPT_ITT is an internal, trusted connection (between TOE components). It is on the trusted management network; it is protected by the firewall; it is protected by the VLAN and switched environment. I don't see removing this test from the external communication but leaving this test for the internal communication is anything but an error in the Errata. There are many difficulties in running this test. One would be to create a Man-in-the-Middle (MITM) tool to capture the packets and modify them before sending them out. This is a similar problem with test 4 in FCS_TLS_EXT.1 in which there is an official waiver for (see TD0004). I also believe this is why the test 3 was removed from FPT_ITC and FTP_TRP, external communications. The other difficulty is to install the MITM tool on the TOE components. FPT_ITT is for internal communication, TOE components communicating with each other, so we need to install the MITM tool on the TOE component itself. This is very hard because we don't have a compiler on the TOE. This is a STIG requirement. We would need to install a compiler, libraries, etc. to compile and install any program on the TOE itself to run this test. If this is an external communication test, we would do all of this (compiler, libraries, etc.) on the external entity. However, because it's an internal communication, both end is a TOE component which cannot have those things. Resolution There is an oversight to have removed the test in assurance activities for FPT_ITC and not for FPT_ITT and, therefore, it is acceptable to not perform test 3 of the test assurance activity for FPT_ITT. It should be noted, however, that this test was removed in FTP_ITC and FTP_TRP because it was covered (in Errata #2) directly in the protocols used to implement the trusted channel, so the appropriate protocol testing (e.g., FCS_IPSEC_EXT) will still need to be performed.

Test 3: The evaluator shall ensure, for each method of communication, modification of the channel data is detected by the TOE.

Test 3 not required per NIAP Technical Decision TD0005.

46

2.7 TOE Access (FTA)

2.7.1 FTA_SSL_EXT.1 TSF-initiated Session Locking


None defined.


None defined.


Test 1: The evaluator follows 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.

The evaluator configured the inactivity timeout for local access for 1 minute. The evaluator logged in and waited 1 minute and verified that the session was terminated. The evaluator repeated these steps for 3 and 5 minutes.

2.7.2 FTA_SSL.3 TSF-initiated Termination


None defined.


None defined.


Test 1: The evaluator follows 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 remote interactive session with the TOE. The evaluator then observes that the session is terminated after the configured time period.

The evaluator configured the inactivity timeout for remote access for 1 minute. The evaluator logged in and waited 1 minute and verified that the session was terminated. The evaluator repeated these steps for 3 and 5 minutes.

47

2.7.3 FTA_SSL.4 User-initiated Termination


None defined.


None defined.


Test 1: The evaluator initiates an interactive local session with the TOE. The evaluator then follows the operational guidance to exit or log off the session and observes that the session has been terminated.

The evaluator logged onto the local console. The evaluator entered the exit command and observed that the session was terminated.

Test 2: The evaluator initiates an interactive remote session with the TOE. The evaluator then follows the operational guidance to exit or log off the session and observes that the session has been terminated.

The evaluator logged on remotely to the TOE. The evaluator clicked on the logout button and observed that the session was terminated.

2.7.4 FTA_TAB.1 Default TOE Access Banners


The evaluator shall check the TSS to ensure that it details each method of access (local and remote) available to the administrator (e.g., serial port, SSH, HTTPS).

The TOE also provides the ability to manage the TOE locally via direct serial console connection. The direct serial console is used mainly for initial configuration and then the TOE is designed to be managed and monitored using the Web GUI from a remote HTTPS/TLS client.


None defined.

[CCCC] Section Configuring the Management Server (MX), provides the guidance to configure the access banner.

Open a shell on the MX and enter the command: impctl security banner config –-text="<Text>"

48

[CCCC] Section Configuring the Gateway, provides the guidance to configure the access banner.

Open a shell on the Gateway and enter the command: impctl security banner config –-text="<Text>"

[CCC] Section Common Criteria Commands identifies the administrator commands to configure the access banner.


Test 1: The evaluator follows the operational guidance to configure a notice and consent warning message. The evaluator shall then, for each method of access specified in the TSS, establish a session with the TOE. The evaluator shall verify that the notice and consent warning message is displayed in each instance.

The evaluator configured the TOE to display a warning message. The evaluator logged onto to TOE for each management method and observed that the warning message was displayed.

2.7.5 FTP_ITC.1 Inter-TSF trusted channel


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.

[ST] Section 6.8 states that the TOE can be configured to use TLS to ensure that any authentication operations, and exported audit records, are sent only to the configured Syslog or authentication servers so they are not subject to inappropriate disclosure or modification. TLS is also used to ensure TOE updates are transmitted securely.

The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST.

The inter-TSF trusted channel identified in the TSS identifies the use of TLS. The TSS description is in agreement with the security requirement.


The evaluator shall confirm that the operational guidance contains instructions for establishing the allowed protocols with each authorized IT entity, and that it contains recovery instructions should a connection be unintentionally broken.

GUI

49

[ADM] Section Connecting to the Management Server, identifies the guidance to connect securely to the TOE via a browser.

Configure SecureSphere using the GUI, connect to the Management Server by pointing your browser to https://<IP address>:8083, where <IP address> is the IP address of the management port on the MX.

Syslog

[CCCC] Section Create a Self-signed Key to be used by Stunnel, provides the guidance to configure the trusted channel to secure the communication to the syslog server.

[CCCC] Section Recovery Instructions, provides the steps to recover if the connection to the server is lost.

If stunnel on MX or on a gateway loses connection to the server:

• Log into the machine • Kill the stunnel process if it still exists: killall stunnel • Rerun it: stunnel

Authentication Server

[ADM] v11.5 Section Creating a SecureSphere User provides the guidance to create a user and to use SecureSphere or External Authorization (LDAP).

[ADM] v11.5 Section External Systems - LDAP provides the guidance to define the external LDAP system. Included in the configuration parameters is the setting to Use SSL - Specifies whether to connect to the external system using SSL.

[ADM] v11.5 Section External System - LDAP Authentication and Authorization included in the configuration parameters is the setting to Use SSL - Select to specify that communication with LDAP servers is encrypted.

TOE Update Server

[UPGUIDE] Section Downloading and Verifying SecureSphere Software provides to the guidance for the administrator to download SecureSphere versions and patches from the SecureSphere FTP site.


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.

The evaluator configured the TOE to establish connection with the Update Server, Syslog server, and LDAP server over TLS.

50

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.

The evaluator attempted to initiate a connection with the external servers and verified that data was sent successfully.

Test 3: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data are not sent in plaintext.

The evaluator ran a Wireshark capture and attempted to establish a connection with the external servers. The evaluator verified that the data was encrypted.

Test 4: The evaluators shall, for each protocol associated with each authorized IT entity tested during test 1, the connection is physically interrupted. The evaluator shall ensure that when physical connectivity is restored, communications are appropriately protected.

The evaluator physically broke the connection to the external server and tried to reestablish connection upon physically restoring it. The evaluator verified that the data was still encrypted.

2.7.6 FTP_TRP.1 Trusted Path


The evaluator shall examine the TSS to determine that the methods of remote TOE administration are indicated, along with how those communications are protected.

[ST] Section 6.8 states administrators can initiate a remote session that is secured using TLS/HTTPS.

The evaluator shall also confirm that all protocols listed in the TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST.

The protocol description in the TSS that supports remote TOE administration (TLS/HTTPS) is in agreement with the security requirement.


The evaluator shall confirm that the operational guidance contains instructions for establishing the remote administrative sessions for each supported method.

An authorized administrator can establish secure remote connections with the TOE using HTTP over TLS.

[CCCC] Section Setting up the System, provides the guidance to set up Stunnel client and server configuration to be used for the TLS/HTTPS connections.

51

[ADM] v11.5 Section Preparing the Appliance, provides the guidance for establishing the remote administrative session. To connect to the Management Server point your browser to https://<IP address>:8083, where <IP address> is the IP address of the management port on the MX.

[CCCC] Section Configuring the Management Server (MX), provides the instructions to configure SSH for establishing the remote administrative sessions.


Test 1: The evaluators shall ensure that communications using each specified (in the operational guidance) remote administration method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.

The evaluator performed testing on SSH and TLS throughout the course of the evaluation as seen in FCS_SSH_EXT.1 and FCS_TLS_EXT.1.

Test 2: or each method of remote administration supported, the evaluator shall follow the operational guidance to ensure that there is no available interface that can be used by a remote user to establish a remote administrative sessions without invoking the trusted path.

The evaluator verified that no other paths were available to administrate the TOE remotely.

Test 3: The evaluator shall ensure, for each method of remote administration, the channel data is are not sent in plaintext.

The evaluator ran a Wireshark capture and attempted to manage the TOE using HTTPS/TLS and SSH. The evaluator viewed that data was not sent in plaintext.

3 SECURITY ASSURANCE REQUIREMENTS

3.1 Class ADV: Development

3.1.1 ADV_FSP.1 Basic Functional Specification

3.1.1.1 FSP_FSP.1 Assurance Activity

There are no specific assurance activities associated with these SARs. The functional specification documentation is provided to support the evaluation activities described in Section 4.2, and 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.

52

3.2 Class AGD: Guidance Documents

3.2.1 AGD_OPE.1 Operational User Guidance

3.2.1.1 AGD_OPE.1 Assurance Activity

The operational guidance shall at a minimum list the processes running (or that could run) on the TOE in its evaluated configuration during its operation that are capable of processing data received on the network interfaces (there are likely more than one of these, and this is not limited to the process that "listens" on the network interface). It is acceptable to list all processes running (or that could run) on the TOE in its evaluated configuration instead of attempting to determine just those that process the network data. For each process listed, the administrative guidance will contain a short (e.g., one- or two-line) description of the process' function, and the privilege with which the service runs. "Privilege" includes the hardware privilege level (e.g., ring 0, ring 1), any software privileges specifically associated with the process, and the privileges associated with the user role the process runs as or under.

[CCCC] Section SecureSphere Processes that Handle Data provides a summary of processes that run on SecureSphere which are capable of processing data received on network interfaces.

Name Process Name Hosting Component

Description Special Privileges

Privileges of User Role Running Process

Gateway gw.x Gateway • Manages the gateway

• Manages database audit

• Actual data processing is in the kernel

Process runs as root

Root has all access

Java java MX • MX application

Java runtime

Runs as a special user named mxserver within a special group named mxserver, with no special privileges

SSH sshd MX and Gateway (if not disabled)

• Secure Shell (Linux logon)

Process runs as root

Root has all access

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 administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE.

53

[CCCC] Section Activating FIPS Mode, provides the steps to configure the cryptographic engine by activating the FIPS mode of operation.

[CCCC] Section FIPS 140 Compliance, identifies the cryptographic algorithms that are not FIPS approved. The TOE features not supported in the FIPS mode are identified.

The documentation must describe the process for verifying updates to the TOE, either by checking the hash or by verifying a digital signature. The evaluator shall verify that this process includes the following steps:

1. For hashes, a description of where the hash for a given update can be obtained. For digital signatures, instructions for obtaining the certificate that will be used by the FCS_COP.1(2) mechanism to ensure that a signed update has been received from the certificate owner. This may be supplied with the product initially, or may be obtained by some other means. 2. Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory). 3. Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes generation of the hash/digital signature.

[UPGUIDE] Section Downloading and Verifying SecureSphere Software provides to the guidance for the administrator to download SecureSphere versions and patches from the SecureSphere FTP site. Instructions are provided for obtaining the update itself and verifying the published hash value.

The TOE will likely contain security functionality that does not fall in the scope of evaluation under this PP. The operational guidance shall make it clear to an administrator which security functionality is covered by the evaluation activities.

[CCCC] Section FIPS-Non-Approved Algorithms, identifies the security functionality not covered by the evaluation. The Non-FIPS approved algorithms are not covered by the evaluation activities.

3.2.2 AGD_PRE.1 Preparative Procedures

3.2.2.1 AGD_PRE.1 Assurance Activity

As indicated in the introduction above, there are significant expectations with respect to the documentation—especially when configuring the operational environment to support TOE functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms claimed for the TOE in the ST.

The Admin Guide, Configuring SecureSphere for Common Criteria Compliance User Guide, Imperva SecureSphere Database Security User Guide, Version Imperva SecureSphere Directory Services Monitoring, File Security User Guide, and Upgrade Guide provide detailed information for installing, configuring and administering the TOE platforms.

54

3.3 ATE_IND.1 Independent Testing Conformance

3.3.1 ATE_IND.1 Assurance Activity

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 CEM and 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 evaluator must 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 must address the differences between the tested platforms 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 must 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 evaluator is 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) should be 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). 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 (which 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.

The evaluation team performed testing on the following platforms:

• One of the following management servers: M160 or VM150 • One of the following gateways: x2010, x4510, x6510 or VM2500 • Optional: Management Server configured as Operations Manager

The test plans and test results are documented in the Imperva SecureSphere Common Criteria Test Report and Procedures, which includes equivalency rationale for coverage of other platforms listed in [ST] but not physically tested by the evaluation team.

Ivy Bridge / Sandy Bridge Microprocessor Equivalency Rationale The TOE hardware appliances and virtual machines incorporate the use of Ivy Bridge and Sandy Bridge Microprocessors. Both the Sandy Bridge and the Ivy Bridge processors are considered architecturally compatible.

55

The Ivy Bridge is a next generation microprocessor that uses the Sandy Bridge architecture. The Ivy Bridge CPU microarchitecture is a shrink from Sandy Bridge and remains largely unchanged. The Ivy Bridge includes 22 nm Tri-gate transistor ("3-D") technology. The Ivy Bridge is essentially the same as Sandy Bridge microprocessor, but features slightly faster cores, better integrated graphics, less power consumption, and better on board graphics. A new random number generator and the RdRand instruction have been added to the Ivy Bridge microprocessor. The Ivy Bridge and the Sandy Bridge microprocessors are backward compatible.

3.4 Class AVA: Vulnerability Assessment

3.4.1 AVA_VAN.1 Assurance Activity

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 network infrastructure devices and the implemented communication protocols 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, a test would be suitable at the assurance level of this PP. If exploiting the vulnerability requires expert skills and an electron microscope, for instance, then a test would not be suitable and an appropriate justification would be formulated.

The evaluation team performed a search of public information for potential vulnerabilities related to the TOE. The results of the search are documented in the Evaluation Team Test Report for Imperva SecureSphere Common Criteria Test Report and Procedures.

3.5 Class ALC: Life-Cycle Support

3.5.1 ALC_CMC.1 Labeling of the TOE Assurance Activity

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. The evaluator shall ensure that this identifier is sufficient for an acquisition entity to use in procuring the TOE (including the appropriate administrative guidance) as specified in the ST.

The TOE is identified as the Imperva SecureSphere 11.5 software running on two or more of the Imperva appliances listed below, including one or more Management Servers and one or more Gateways:

Hardware appliance:

• Gateway Appliances: X1010, X10K, X2010, X2510, X4510, X6510, X8510

56

• MX Management Server Appliances: M110, M160 Virtual Machine Appliances:

• V1000, V2500, V4500 (for Gateway) • VM150 (for MX)

And optionally a SecureSphere Operations Manager (SOM) Management Server appliance or Virtual Machine Appliance:

• Appliances: M160 • Virtual Machine Appliance: VM150

This identifier is sufficient for an acquisition entity to use in procuring the TOE (including the appropriate administrative guidance) as specified in 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.

The TOE is identified as the Imperva SecureSphere 11.5 software running on two or more of the Imperva appliances listed below, including one or more Management Servers and one or more Gateways:

Hardware appliance:

• Gateway Appliances: X1010, X10K, X2010, X2510, X4510, X6510, X8510 • MX Management Server Appliances: M110, M160

Virtual Machine Appliances:

• V1000, V2500, V4500 (for Gateway) • VM150 (for MX)

And optionally a SecureSphere Operations Manager (SOM) Management Server appliance or Virtual Machine Appliance:

• Appliances: M160 • Virtual Machine Appliance: VM150

The evaluator verified that AGD guidance and the TOE samples received for testing are 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.

The evaluator verified that the vendor website http://www.imperva.com/ advertisement of the TOE is sufficient to distinguish the products as advertised in the ST.

3.5.2 ALC_CMS.1 TOE CM Coverage Assurance Activity

The “evaluation evidence required by the SARs” in this PP is limited to the information in the ST coupled with the guidance provided to administrators and users under the AGD requirements. By

57

http://www.imperva.com/

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.

The TOE is specifically identified and this identification is consistent in the ST and in the AGD guidance.

58