Common Criteria NDcPP Assurance Activity Report for Cisco Security Appliance. ISSUED BY Acumen Security, LLC.

Transcription

1 Common Criteria NDcPP Assurance Activity Report for Cisco Security Appliance ISSUED BY Acumen Security, LLC.

2 Revision History: Version Date Changes Version 1.6 8/4/2017 Updated for additional CAVP certs 2

3 Table of Contents 1 TOE Overview TOE Description Assurance Activities Identification Test Equivalency Justification TOE Description OS, Processor, and Firmware Analysis Equivalency Analysis Recommendations/Conclusion Test Diagram Testbed Diagram Testbed Component Description Detailed Test Cases (Auditing) Test Cases (Auditing) FAU_GEN.1 Guidance FAU_GEN.1 Guidance FAU_GEN.1 Test FAU_GEN FAU_STG_EXT.1.1 TSS FAU_STG_EXT.1.1 TSS FAU_STG_EXT.1.1 TSS FAU_STG_EXT.1 Guidance FAU_STG_EXT.1 Guidance FAU_STG_EXT.1. Guidance FAU_STG_EXT.1 Test FAU_STG_EXT.1 Test Test Cases (Cryptographic Support) FCS_CKM.1 TSS FCS_CKM.1 Guidance FCS_CKM.1 Test

4 6.2.4 FCS_CKM.2 TSS FCS_CKM.2 Guidance FCS_CKM.2 Test FCS_CKM.4.1 TSS FCS_CKM.4 TSS FCS_CKM.4 TSS FCS_COP.1(1) Test FCS_COP.1(2) Test FCS_COP.1(3) TSS FCS_COP.1(3) Guidance FCS_COP.1(3) Test FCS_COP.1(4) TSS FCS_COP.1(4) Test FCS_RBG_EXT.1.1 Test Test Cases (HTTPS) FCS_HTTPS_EXT.1 TSS # FCS_HTTPS_EXT.1 Test # FCS_HTTPS_EXT.1 Test # Test Cases (SSHC) FCS_SSHC_EXT.1.2 TSS FCS_SSHC_EXT.1.2 Test FCS_SSHC_EXT.1.3 TSS FCS_SSHC_EXT.1.3 Test FCS_SSHC_EXT.1.4 TSS FCS_SSHC_EXT.1.4 Guidance FCS_SSHC_EXT.1.4 Test FCS_SSHC_EXT.1.4 Test FCS_SSHC_EXT.1.5 TSS FCS_SSHC_EXT.1.5 Guidance FCS_SSHC_EXT.1.5 Test FCS_SSHC_EXT.1.5 Test FCS_SSHC_EXT.1.6 TSS

5 FCS_SSHC_EXT.1.6 Guidance FCS_SSHC_EXT.1.6 Test FCS_SSHC_EXT.1.6 Test FCS_SSHCS_EXT.1.6 Test FCS_SSHC_EXT.1.7 TSS FCS_SSHC_EXT.1.7 Guidance FCS_SSHCS_EXT.1.7 Test FCS_SSHC_EXT.1.8 TSS FCS_SSHC_EXT.1.8 Test FCS_SSHC_EXT.1.9 Test FCS_SSHC_EXT.1.9 Test Test Cases (SSHS) FCS_SSHS_EXT.1.2 TSS FCS_SSHS_EXT.1.2 Test FCS_SSHS_EXT.1.2 Test FCS_SSHS_EXT.1.2 Test FCS_SSHS_EXT.1.2 Test FCS_SSHS_EXT.1.3 TSS FCS_SSHS_EXT.1.3 Test FCS_SSHS_EXT.1.4 TSS FCS_SSHS_EXT.1.4 Guidance FCS_SSHS_EXT.1.4 Test FCS_SSHS_EXT.1.4 Test FCS_SSHS_EXT.1.5 TSS FCS_SSHS_EXT.1.5 Guidance FCS_SSHS_EXT.1.5 Test FCS_SSHS_EXT.1.5 Test FCS_SSHS_EXT.1.6 TSS FCS_SSHS_EXT.1.6 Test FCS_SSHS_EXT.1.6 Test FCS_SSHS_EXT.1.6 Test FCS_SSHS_EXT.1.7 TSS

6 FCS_SSHS_EXT.1.7 Guidance FCS_SSHS_EXT.1.7 Test FCS_SSHS_EXT.1.7 Test FCS_SSHS_EXT.1.8 TSS FCS_SSHS_EXT.1.8 Test Test Cases (TLSS) FCS_TLSS_EXT.1.1 TSS FCS_TLSS_EXT.1.1 Guidance FCS_TLSS_EXT.1.1 Test # FCS_TLSS_EXT.1.1 Test # FCS_TLSS_EXT.1.1 Test # FCS_TLSS_EXT.1.1 Test # FCS_TLSS_EXT.1.2 TSS FCS_TLSS_EXT.1.2 Guidance FCS_TLSS_EXT.1.2 Test # FCS_TLSS_EXT.1.3 TSS FCS_TLSS_EXT.1.3 Guidance Test Cases (Identification and Authentication) FIA_PMG_EXT.1.1 Guidance FIA_PMG_EXT.1 Test FIA_UIA_EXT.1 TSS FIA_UIA_EXT.1 Guidance FIA_UIA_EXT.1 Test # FIA_UIA_EXT.1 Test # FIA_UIA_EXT.1 Test # FIA_UAU_EXT FIA_UAU.7 Test # FIA_X509_EXT.1 TSS FIA_X509_EXT.1.1 Test # FIA_X509_EXT.1.1 Test # FIA_X509_EXT.1.1 Test # FIA_X509_EXT.1.1 Test #

7 FIA_X509_EXT.1.1 Test # FIA_X509_EXT.1.1 Test # FIA_X509_EXT.1.1 Test # FIA_X509_EXT.1.2 Test # FIA_X509_EXT.1.2 Test # FIA_X509_EXT.1.2 Test # FIA_X509_EXT.2 TSS FIA_X509_EXT.2 TSS FIA_X509_EXT.2 Test # FIA_X509_EXT.3 Guidance FIA_X509_EXT.3 Test # FIA_X509_EXT.3 Test # Test Cases (Security Management) FMT_MOF.1(1)/Trusted Update Test # FMT_MOF.1(1)/Trusted Update Test # FMT_MTD.1 TSS FMT_MTD.1 Guidance FMT_SMF FMT_SMR.2 Guidance FMT_SMR.2 Test # Test Cases (Protection of the TSF) FPT_SKP_EXT.1 TSS FPT_APW_EXT.1 TSS FPT_APW_EXT.1 TSS FPT_STM.1 TSS FPT_STM.1 Guidance FPT_STM.1 Test # FPT_STM.1 Test # FPT_TST_EXT.1.1 TSS FPT_TST_EXT.1.1 TSS FPT_TST_EXT.1.1 Guidance FPT_TST_EXT.1.1 Test #

8 FPT_TUD_EXT.1 TSS FPT_TUD_EXT.1 Guidance FPT_TUD_EXT.1 Test # FPT_TUD_EXT.1 Test # Test Cases (TOE Access) FTA_SSL_EXT.1 Test # FTA_SSL.3 Test # FTA_SSL.4 Test # FTA_SSL.4 Test # FTA_TAB.1 TSS FTA_TAB.1 Test # Test Cases (Trusted Path/Channels) FTP_ITC.1 TSS FTP_ITC.1 TSS FTP_ITC.1 Guidance FTP_ITC.1 Test #1, 2, FTP_ITC.1 Test # FTP_TRP.1 TSS FTP_TRP.1 TSS FTP_TRP.1 Guidance FTP_TRP.1 Test #1, 2, FTP_TRP.1 Test # Security Assurance Requirements ASE_CCL.1 Conformance Claims ASE_CCL.1.8.C # ASE_CCL.1.9.C # ASE_CCL.1.9.C # ASE_CCL.1.9.C # AGD_OPE.1 Operational User Guidance AGD_OPE.1 # AGD_PRE.1 Preparative Procedures AGD_PRE.1 #

9 7.3.2 AGD_PRE.1 # AGD_PRE.1 # ATE_IND.1 Independent Testing Conformance ATE_IND.1 # ATE_IND.1 # ATE_IND.1 # AVA_VAN.1 Vulnerability Survey AVA_VAN.1 # Technical Decisions Conclusion

10 Assurance Activity Report (AAR) for a Target of Evaluation Cisco Security Appliance, version 9.8 Cisco Security Appliance Security Target, version 1.0 Collaborative Protection Profile for Network Devices version 1.0 AAR version 1.6 Evaluated by: Office Park Dr. Montgomery Village, MD Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme 10

11 The Developer of the TOE: Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA The Author of the Security Target: Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA The TOE Evaluation was Sponsored by: Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA Evaluation Personnel: Pascal Patin Common Criteria Version Common Criteria Version 3.1 Revision 4 Common Evaluation Methodology Version CEM Version 3.1 Revision 4 11

12 1 TOE Overview The TOE, Cisco ESA, is a network device. ESA is an appliance that provides comprehensive protection services for . It is an protection product that monitors Simple Mail Transfer Protocol (SMTP) network traffic, analyzes the monitored network traffic using various techniques, and reacts to identified threats associated with messages (such as spam and inappropriate or malicious content). ESA was evaluated as a network device only and the protection services were not assessed during this evaluation. 1.1 TOE Description ESA is a security appliance that scans traffic between an external network and the customer s internal network. Traffic flowing to and from the external network to the internal network is first routed through the ESA appliance. The TOE was evaluated as a network device only and the protection services were not assessed during this evaluation. Through the intercept, scanning, and reporting functions, the ESA appliance can detect potentially malicious files of various types, filter traffic for restricted content, and containing spam messages or phishing attempts. Error! Unknown document property name. supports RFC 2821-compliant Simple Mail Transfer Protocol (SMTP) to accept and deliver messages. Cisco ESA monitors SMTP network traffic and applies the following traffic analysis mechanisms: Signature analysis - the administrator can configure message filters, comprising rules describing how to handle messages and attachments as they are received. Filter rules identify messages based on message or attachment content, information about the network, message headers, or message body. Detection of spam - ESA implements a layered mechanism to detecting and handling spam. The first layer of spam control is called reputation filtering, which allows for classifying senders and restricting access to infrastructures based on a sender s trustworthiness as determined by the ESA. The second layer comprises scanning of messages by the ESA s Anti-Spam engine. In addition, the administrator can create policies to deliver messages from known or highly reputable senders directly to the end user without any anti-spam scanning, while messages from less reputable or unknown senders are subjected to anti-spam scanning. ESA can also be configured to throttle the number of messages it will accept from suspicious senders, reject connections or bounce messages. Anti-virus scanning - ESA incorporates both Sophos and McAfee Anti-Virus virus scanning engines, which can be configured to scan messages and attachments for viruses on a per-mail policy basis and take the following actions based on the scan results: attempt to repair the attachment; drop the attachment; modify the subject header; add an additional header; send the message to a different address or mail host; archive the message; or delete the message. Application of content filters - the administrator can create content filters to be applied to messages on a perrecipient or per-sender basis. Content filters are similar to the message filters described above under Signature analysis, except that they are applied later in the processing pipeline. messages can be quarantined, deleted, or have the flagged content filtered from the . The action taken on the is based on the content filtering policies configured by the authorized administrator. Application of virus outbreak filters - ESA has the ability to compare incoming messages with administratorconfigured Virus Outbreak Rules. Messages that match such rules are assigned a threat level and that threat level is compared to the threat level threshold set by the administrator. Messages meeting or exceeding the threshold are quarantined. Once a suspected infected or phishing attempt is detected, ESA can then take one or more of the following actions in response as identified by the traffic analysis mechanisms: Generate an to an administrator containing an alarm Generate an alarm that is written to a log file that can be examined using the administrator console 12

13 Drop the message Bounce the message Archive the message Add a blind-carbon copied recipient to the message Modify the message. The various administrator-configurable rule sets that control the behavior of spam detection, anti-virus scanning, content filtering and virus outbreak filtering are configured such that they are applied to specific groups of users based on message attributes (Envelope Recipients, Envelope Sender, From: header, or Reply-To: header) in order to perform each type of analysis as described above. 13

14 2 Assurance Activities Identification The following table identifies each of the Assurance Activities (testing and documentation review) executed for this evaluation. Test Case ID FAU_GEN.1 Test 1 FAU_STG_EXT.1 Test 1 FAU_STG_EXT.1.1 Test 2 FCS_CKM.1 Test 1 FCS_CKM.2 Test 1 FCS_COP.1.1 (1) Test 1 FCS_COP.1.1 (2) Test 1 FCS_COP.1.1 (3) Test 1 FCS_COP.1.1 (4) Test 1 FCS_RBG_EXT.1.1 Test 1 FCS_HTTPS_EXT.1 Test #1 FCS_SSHC_EXT.1.2 Test #1 FCS_SSHC_EXT.1.3 Test #1 FCS_SSHC_EXT.1.4 Test #1 FCS_SSHC_EXT.1.4 Test #2 FCS_SSHC_EXT.1.5 Test #1 FCS_SSHC_EXT.1.5 Test #2 FCS_SSHC_EXT.1.6 Test #1 FCS_SSHC_EXT.1.6 Test #2 FCS_SSHC_EXT.1.6 Test #3 FCS_SSHC_EXT.1.7 Test #1 FCS_SSHC_EXT.1.8 Test #1 FCS_SSHC_EXT.1.9 Test #1 FCS_SSHC_EXT.1.9 Test #2 FCS_SSHS_EXT.1.2 Test #1 FCS_SSHS_EXT.1.2 Test #2 FCS_SSHS_EXT.1.2 Test #3 FCS_SSHS_EXT.1.2 Test #4 FCS_SSHS_EXT.1.3 Test 1 FCS_SSHS_EXT.1.4 Test 1 FCS_SSHS_EXT.1.4 Test 2 FCS_SSHS_EXT.1.5 Test 1 FCS_SSHS_EXT.1.5 Test 2 FCS_SSHS_EXT.1.6 Test 1 FCS_SSHS_EXT.1.6 Test 2 FCS_SSHS_EXT.1.6 Test 3 FCS_SSHS_EXT.1.7 Test 1 FCS_SSHS_EXT.1.7 Test 2 FCS_SSHS_EXT.1.8 Test 1 FCS_TLSS_EXT.1.1 Test #1 Description of Test Case Confirming the ability to generate all required audit logs. Confirming the ability to send audit logs to an external audit server in a protected fashion. Confirming the behavior of the TOE when the audit log is full. Verification of the Key Generation implementation. Verification of the Key Establishment implementation. Verification of the symmetric encryption implementation. Verification of the signature processing implementation. Verification of the hashing implementation. Verification of the MACing implementation. Verification of the DRBG implementation. Confirming the ability to make an HTTPS connection Confirming the ability to use claimed public key algorithms. Confirming the ability to reject large SSH packets. Confirming encryption algorithm support. Confirming encryption algorithm enforcement (rejection of non-allowed). Confirming public key algorithm support. Confirming public key algorithm enforcement (rejection of non-allowed). Confirming integrity algorithm support. Confirming integrity algorithm enforcement (rejection of none). Confirming integrity algorithm enforcement (rejection of non-allowed). Confirming key exchange algorithm support. Confirming rekey support. Confirming the correct handling of untrusted certificates. Confirming the correct handling of untrusted hosts. Confirming the ability to use key based authentication. Confirming the ability to enforce key based authentication. Confirming the ability to use password based authentication. Confirming the ability to reject incorrect passwords. Confirming the ability to reject large SSH packets. Confirming encryption algorithm support. Confirming encryption algorithm enforcement (rejection of non-allowed). Confirming public key algorithm support. Confirming public key algorithm enforcement (rejection of non-allowed). Confirming integrity algorithm support. Confirming integrity algorithm enforcement (rejection of none). Confirming integrity algorithm enforcement (rejection of non-allowed). Confirming key exchange enforcement (rejection of non-allowed). Confirming key exchange algorithm support. Confirming rekey support. Confirming ciphersuite support. 14

15 Test Case ID FCS_TLSS_EXT.1.1 Test #2 FCS_TLSS_EXT.1.1 Test #3 FCS_TLSS_EXT.1.1 Test #4 FCS_TLSS_EXT.1.2 Test #1 FIA_PMG_EXT.1 Test 1 FIA_UIA_EXT.1 Test #1 FIA_UIA_EXT.1 Test #2 FIA_UIA_EXT.1 Test #3 FIA_UAU.7 Test #1 FIA_X509_EXT.1.1 Test #1 FIA_X509_EXT.1.1 Test #2 FIA_X509_EXT.1.1 Test #3 FIA_X509_EXT.1.1 Test #4 FIA_X509_EXT.1.1 Test #5 FIA_X509_EXT.1.1 Test #6 FIA_X509_EXT.1.1 Test #7 FIA_X509_EXT.1.2 Test #1 FIA_X509_EXT.1.2 Test #2 FIA_X509_EXT.1.2 Test #3 FIA_X509_EXT.2 Test #1 FIA_X509_EXT.3 Test #1 FIA_X509_EXT.3 Test #2 FMT_MOF.1(1) Test #1 FMT_MOF.1(1) Test #2 FPT_STM.1 Test #1 FPT_STM.1 Test #2 FPT_TUD_EXT.1 Test #1 FPT_TUD_EXT.1 Test #2 FPT_TST_EXT.1.1 Test #1 FTA_SSL_EXT.1 Test #1 FTA_SSL.3 Test #1 FTA_SSL.4 Test #1 FTA_SSL.4 Test #2 FTA_TAB.1 Test #1 FTP_ITC.1 Test #1/2/3 FTP_ITC.1 Test #4 FTP_TRP.1 Test #1/2/3/4 FTP_TRP.1 Test #4 Table 1: Assurance Activities Description of Test Case Confirming NULL ciphersuite rejection. Confirming session establishment exchange error rejection. Confirming session establishment exchange error rejection. Confirming rejection of non-allowed protocol versions. Confirming minimum password length enforcement. Confirming user authentication. Confirming remote user authentication. Confirming local user authentication. Confirming obscured authentication output. Confirming certificate path verification. Confirming certificate expiration verification. Confirming certificate revocation enforcement. Confirming certificate revocation enforcement. Confirming malformed certificate handling. Confirming malformed certificate handling. Confirming malformed certificate handling. Confirming basicconstraints validation. Confirming basicconstraints validation. Confirming basicconstraints validation. Confirming validity handling when OSCP server cannot be reached. Confirming CSR generation. Confirming CSR responder Certificate path verification. Confirming the requirement to be authenticated to access management. Confirming available management functionality. Confirming the ability to set time. Confirming the ability to use NTP. Confirming software update procedures. Confirming rejection of corrupted software update images. Confirming self-testing. Confirming local inactivity logout. Confirming remote inactivity logout. Confirming local administrator logout. Confirming remote administrator logout. Confirming TOE access banners. Confirming protected communications with external servers. Confirming no plaintext data when disconnected from external servers. Confirming protected communications with remote management. Confirming no plaintext data when disconnected from remote management. 15

16 3 Test Equivalency Justification 3.1 TOE Description The TOE is comprised of both software and hardware. The hardware is comprised of the following: C170, C670, C190, C370, C380, C680, C690, C1070X, C100v, C300, C600v running on Cisco UCS servers (blade or rack-mounted). The software version of the TOE is Cisco AsyncOS version 9.8. The Cisco Security Appliance that comprises the TOE has common hardware characteristics. These characteristics affect only non-tsf relevant functions of the appliances (such as throughput and amount of storage) and therefore support security equivalency of the appliances in terms of hardware. The C100v, C300v, and C600v models running on Cisco UCS servers have similar disk layouts, queue and cache sizes, and configurations as their dedicated hardware appliance counterparts. The software images for the C100v, C300v, and C600v have been pre-configured with disk space, queue/cache space, memory, and processor cores. These differences in the pre-configurations of these models are the reason the software images differ. 3.2 OS, Processor, and Firmware Analysis The following table compares the Operating System, CPU, and firmware that runs on each of the included TOE platforms TOE Model Description Analysis Operating System This is the OS that runs on the platform C170 AsyncOS 9.8 The same base OS is included on each of the platforms C670 AsyncOS 9.8 included within the TOE. C190 AsyncOS 9.8 C370 AsyncOS 9.8 C380 AsyncOS 9.8 C680 AsyncOS 9.8 C690 AsyncOS 9.8 C1070X AsyncOS 9.8 C100v AsyncOS 9.8 C300v AsyncOS 9.8 C600v AsyncOS 9.8 CPU This is the processor running on the platform C170 Intel Xeon The exact same processor is used on each of these C670 Intel Xeon platforms. C190 Intel Xeon C370 Intel Xeon C380 Intel Xeon C680 Intel Xeon C690 Intel Xeon C1070X Intel Xeon 16

17 TOE Model Description Analysis C100v Intel Xeon C300v Intel Xeon C600v Intel Xeon Firmware This is the actual software binary installed on the platform C170 phoebe tgz The exact same binary is used on each of these C670 phoebe tgz platforms. C190 phoebe tgz C370 phoebe tgz C380 phoebe tgz C680 phoebe tgz C690 phoebe tgz C1070X phoebe tgz C100v phoebe c100v.zip A binary specific to the VM is used. C300v phoebe c300v.zip A binary specific to the VM is used. C600v phoebe c600v.zip A binary specific to the VM is used. Table 2 OS, Processor, and Firmware Analysis 3.3 Equivalency Analysis The following equivalency analysis provides a per category analysis of key areas of differentiation for each hardware model to determine the minimum subset to be used in testing. The areas examined will use the areas and analysis description provided in the supporting documentation for the NDcPP. Platform/Hardware Differences The TOE boundary is inclusive of all hardware required by the TOE. The hardware platforms do not provide any of the TSF functionality. The hardware within the TOE only differs by configuration and performance. There are no hardware specific dependencies of the product. There aren t hardware specific functionality between appliance types. The base hardware may be configured as multiple types of appliance. : There are no hardware dependencies. All products are equivalent. Processor Differences Each product includes an Intel Xeon processor. These processors are identical. There is no difference between platforms. : All platforms are equivalent. Software/OS Dependencies The underlying OS is installed with the application level software on each of the appliances. The underlying OS for all models within the TOE is Cisco AsyncOS 9.8. There are no specific dependencies 17

18 on the OS since the TOE will not be installed on different OSs. : All platforms are equivalent. Differences in TOE Software Binaries All platforms run AsyncOS 9.8. Each hardware product runs the EXACT same image. There are no differences between the binaries. Each virtual image has a separate binary. This is the case to account for the performance configuration differences (storage, RAM, processor cores used). The software that runs on the devices, however, are identical. There are NO functional differences between software binaries. These differences are only to account for differences in performance. Appliance Binary C170 phoebe tgz The exact same binary is used on each of C670 phoebe tgz these platforms. C190 phoebe tgz C370 phoebe tgz C380 phoebe tgz C680 phoebe tgz C690 phoebe tgz C1070X phoebe tgz C100v phoebe c100v.zip A binary specific to the VM is used. C300v phoebe c300v.zip A binary specific to the VM is used. C600v phoebe c600v.zip A binary specific to the VM is used. Table 3 TOE Software Binaries While there are several different images (with VM images), there are no security related differences between software binaries. Features only differ when different software versions are used. Each image is part of the the release. All features and implementations of the features are identical. All differences are only performance related (Storage, RAM, Processor Cores). For this evaluation, there are no differences. : All platforms are equivalent. However, recommendation is to test two platforms, an appliance and a virtual image. Differences in Libraries Used to Provide TOE Functionality All software binaries compiled in the TOE software are identical including the version of the library regardless of the platform for which the software is compiled. There are no differences between the included libraries. : All platforms are equivalent. 18

19 TOE Management Interface Differences The TOE is managed via remote GUI or directly connected CLI. These management options are available on all platforms regardless of the configuration. There is no difference in the management interface for any platform. : All platforms are equivalent. TOE Functional Differences Each hardware model within the TOE boundary provides identical functionality. There is no difference in the way the user interacts with each of the devices or the services that are available to the user in for each of these devices. Each device runs the same version of software. : All platforms are equivalent. 4 Recommendations/Conclusion Based on the analysis above, the following will sufficiently test the TOE, Appliance C170 C670 C190 C370 C380 C680 C690 C1070X C100v C300v C600v Table 4 Required Subset Binary Minimally, one example of these devices is acceptable for testing. It is also acceptable to stripe tests across devices in this family. Minimally, one example of these devices is acceptable for testing. It is also acceptable to stripe tests across devices in this family. For this evaluation, the lab plans to execute the tests on the following appliances, Cisco ESA 190 Cisco ESA C300v 19

20 5 Test Diagram 5.1 Testbed Diagram 5.2 Testbed Component Description The following table provides a description of each of components in the testbed. Table 5: Testbed Component Description Component Software IP Address Cisco ESA C190 ASync OS Cisco ESA C300V ASync OS Testing Laptop Windows Bitvise SSH Server Bitvise Certificate Authority OpenSSL OCSP Server OpenSSL

21 6 Detailed Test Cases (Auditing) 6.1 Test Cases (Auditing) FAU_GEN.1 Guidance 1 The evaluator shall check the guidance documentation 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 mandated by the cpp is described and that the description of the fields contains the information required in FAU_GEN1.2, and the additional information specified in the table of audit events Evaluator Findings The evaluator examined the guidance document to determine if it lists all auditable events. Table 7 in section 7 of the AGD was used to determine the verdict of this assurance activity. The evaluator first found an identification of each auditable event in table 7. The evaluator next compared this list of events to the auditable events listed in the NDcPP. Each event listed in the NDcPP is also listed in AGD. Next, the evaluator reexamined AGD and found that table 7 also contains a listing and description of each of the fields in generated audit records that contain the information required in FAU_GEN Verdict FAU_GEN.1 Guidance 2 The evaluator shall also make a determination of the administrative actions that are relevant in the context of the cpp. The evaluator shall examine the guidance documentation 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 cpp. The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to the cpp. The evaluator may perform this activity as part of the activities associated with ensuring that the corresponding guidance documentation satisfies the requirements related to it Evaluator Findings The evaluator examined the guidance documentation to determine which administrative commands are relevant in the context of the cpp. The ST and AGD were used to determine the verdict of this assurance activity. The evaluator first examined the entirety of AGD to determine what administrative commands are associated with each administrative activity. The evaluator found the following are applicable, Administrative Activity Method (Command/GUI Configuration) Section Startup audit N/A N/A Shutdown audit N/A N/A Login N/A N/A Logout N/A N/A Generating Keys (certificates) Hostkeyconfig command Creating Users Userconfig 5.2 Performing Software Updates upgrade 5.10 Setting the Time Settime Configuring NTP Ntpconfig

22 Administrative Activity Method (Command/GUI Configuration) Section Configuring Admin Timeout GUI > System Administration > Network Access > Edit Settings 5.9 CLI > adminaccessconfig Configuring the Audit Server Logconfig 5.6 Configuring Access Banner Adminaccessconfig > banner 5.4 Setting word Length Guidance documentation informs user of minimum requiremends Resetting the TOE Reload Configuring SSH Sshconfig Configuring TLS sslconfig Next, the evaluator examined each of test cases and for those test cases which exercised the above referenced functionality. The audit record associated with the configuration was captured. The following table reflects, identifies the test cases in which those configurations can be found and identifies the specific method for invoking the functionality that generated the audit record. Administrative Activity Method (Command/GUI Configuration) Test Case(s) Login Credentials entered FIA_UIA_EXT.1.1 Logout Timeout of session of exit FTA_SSL_EXT.1.1 Display system information During test cases, GUI will display present configuration on screen. All Creating Users Userconfig FMT_MOF.1.1(1)/ AdminAct Performing Software Updates Upgrade FMT_MOF.1.1(1)/ Trusted Update Setting the Time Settime FPT_STM.1.1 Configuring NTP Through UI, navigate Time settings and select use network time FPT_STM.1.1 protocol. Specify the Server IP Configuring Admin Timeout Through UI, navigate to settings > Network Access and specify UI and FTA_SSL.3 CLI timeout Configuring the Audit Server Through UI, specify SCP Push to Remote Server and specify IP FAU_STG_EXT.1.1 Configuring Access Banner adminaccessconfig FTA_TAB.1 Configuring SSH Ssh-keygen -t rsa -b 2048 FCS_SSHS_EXT.1 The above analysis illustrates that each of the relevant configuration methods is appropriately audited by the TOE. Based on these findings, this assurance activity is considered satisfied Verdict FAU_GEN.1 Test 1 FAU_GEN.1_T1 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 the table of audit events and administrative actions listed below. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the guidance documentation, and that the fields in each audit record have the proper entries. The testing here can be accomplished in conjunction with the testing of the security mechanisms directly. Test Flow Trigger each auditable event on the TOE 22

23 /Fail Explanation Verify that each audit record is generated and contains the required information The audit records associated with each test case are recorded with each test case. A comparison of required audit records to the presented audit records was additionally performed. This analysis shows that each required audit record is generated by the TOE, meeting the test requirements FAU_GEN.2 None The evaluation of this SFR is tested in conjunction with the testing of FAU_GEN FAU_STG_EXT.1.1 TSS 1 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 Evaluator Findings The evaluator examined the TSS to ensure that it describes the means by which audit data is transmitted to an external audit server, and how the trusted channel is provided. The TSS entry for FAU_STG_EXT.1 in section 6.1 of the ST was used to determine the verdict of this assurance activity. The evaluator found that the TSS states that the TOE sends audit records to an external syslog server over SSH. To support this functionality, the TOE implements both SCP and SCP Push. Using SCP Push the TOE is capable of automatically sending records to an external audit server, but it will not do so if the SSH connection has failed Verdict FAU_STG_EXT.1.1 TSS 2 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 Evaluator Findings The evaluator examined the TSS to determine if 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. The TSS entry for FAU_STG_EXT.1 in section 6.1 of the ST was used to determine the verdict of this assurance activity. The evaluator found that the TSS states that by default the TOE stores up to 10 audit record files of 10 MB each. Administrators can increase this limit to up to 1000 files with sizes between 100KB and 100MB. The evaluator, next, found that, when the local audit storage on the TOE is exhausted, the TOE will generate an alert to the Administrator and begin overwriting the oldest audit records. Finally, the evaluator found that the TOE implements the following protection to protect against unauthorized access to local audit records: Only Authorized Administrators are able to clear local logs and there is no TOE interface that allows administrators to modify the contents of audit records Verdict FAU_STG_EXT.1.1 TSS 4 The evaluator shall examine the TSS to ensure that it details the behavior of the TOE when the storage space for audit data is full. When the option overwrite previous audit record is selected this description should include an outline of the rule for overwriting audit data. If other actions are chosen such as sending the new audit data to an external IT entity, then the related behavior of the TOE shall also be detailed in the TSS. 23

24 Evaluator Findings The evaluator examined the TSS to ensure that it details the behavior of the TOE when the storage space for audit data is full. The FAU_STG_EXT.1 SFR found in section of the ST and the TSS entry for FAU_STG_EXT.1 in section 6.1 of the ST were used to determine the verdict of this assurance activity. The evaluator found that overwrite previous audit records was selected in the SFR. Next, the evaluator confirmed that the TSS provides a description of how the TOE implements this functionality. The TSS states that the TOE deletes the oldest stored audit records when storage space is exhausted. The evaluator found this description to be consist with the selection within the SFR Verdict FAU_STG_EXT.1 Guidance 1 The evaluator shall also examine the guidance documentation 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 Evaluator Findings The evaluator examined the guidance documentation to determine if it describes how to establish a trusted channel to an audit server. Section 5.6 of AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD states that the TOE securely send traffic to an external audit server via SCP over SSH. Next, the evaluator found that AGD provides instructions for configuring the secure connection between the TOE and the remote audit server via CLI or GUI. Finally, the evaluator found that AGD defines the following requirements for audit server to which the TOE connects: Support for SCP over SSHv Verdict FAU_STG_EXT.1 Guidance 2 The evaluator shall also examine the guidance documentation 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 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 cleared periodically by sending the data to the audit server Evaluator Findings The evaluator examined the guidance documentation to determine if the relationship between local and external audit data. Section 5.6 of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that AGD describes the relationship between local and external audit data, as follows. Audit records are periodically pushed out via SCP Push once it is configured. These are exact copies of the records stored on the TOE Verdict FAU_STG_EXT.1. Guidance 3 The evaluator shall also ensure that the guidance documentation describes all possible configuration options for FAU_STG_EXT.1.3 and the resulting behavior of the TOE for each possible configuration. The description of possible configuration options and resulting behavior shall correspond to those described in the TSS. 24

25 Evaluator Findings The evaluator examined the guidance documentation to determine if it describes all possible configuration options for FAU_STG_EXT.1.3 and the TOE behavior for each possible configuration. The TSS entry for FAU_STG_EXT.1 in section 6.1 of the ST and section 5.6 of the AGD was used to determine the verdict of this assurance activity. The evaluator found that the TOE does not support the configuration of different methods of handling exhausted local audit storage. Next, the evaluator compared the exhausted local audit handling description found in AGD to the description provided by the TSS of the ST. The descriptions of the behavior found in AGD and ST are consistent Verdict FAU_STG_EXT.1 Test 1 FAU_STG_EXT.1_T1 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. Test Flow Configure the TOE to communicate with a remote audit server via a secure channel Generate audit events (the event itself does matter) Capture the traffic between the TOE and the audit server Verify that the packets are sent through a secured channel /Fail Explanation The TOE passes all audit traffic to the remote audit server through a secure channel. This meets the testing requirements FAU_STG_EXT.1 Test 2 FAU_STG_EXT.1_T2 The evaluator shall perform operations that generate audit data and verify that this data is stored locally. The evaluator shall perform operations that generate audit data until the local storage space is exceeded and verifies that the TOE complies with the behavior defined in FAU_STG_EXT.1.3. Test Flow Show current logging space used Fill the audit log (a script was used to do this) Show current logging space used and verify the behavior /Fail Explanation The TOE will overwrite previous audit records when allotted space has reached its threshold. This meets the testing requirements. 25

26 6.2 Test Cases (Cryptographic Support) FCS_CKM.1 TSS 1 The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme Evaluator Findings The evaluator examined the TSS to determine if it identifies the key sizes supported by the TOE. The TSS entry for FCS_CKM.1 in section 6.1 of the ST was used to determine the verdict of this assurance activity. The evaluator found that the TSS states that the TOE can create RSA keys with sizes of 2048-bits or greater. In addition, it can perform ECC generation using NIST curves P-256, P-384 and P-521. Next, the evaluator confirmed that the TSS describes how these keys are used by the TOE. The evaluator found that these keys are used for the generation of Certificate Signing Requests (CSRs) Verdict FCS_CKM.1 Guidance 1 The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all uses defined in this PP Evaluator Findings The evaluator examined guidance documentation to determine if it instructs the administrator how to configure TOE to use the selected key generation schemes and key sizes. Section of the AGD was used to determine the verdict of this assurance activity. The evaluator found that the configuration for generating keys is done with the sshconfig command in the CLI Verdict FCS_CKM.1 Test 1 The evaluator shall verify the implementation of Key Generation by the TOE using the Key Generation test Evaluator Findings The implemented cryptographic module employed by the TOE has been subject to the Key Generation test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below CAVP Algorithm Certificate # ECDSA 1113, 1155 RSA 2488, Verdict 26

27 6.2.4 FCS_CKM.2 TSS 1 The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme Evaluator Findings The evaluator examined the TSS to determine if the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. The TSS entries for FCS_CKM.1 and FCS_CKM.2 in section 6.1 of the ST was used to determine the verdict of this assurance activity. The evaluator compared the key establishment schemes listed in FCS_CKM.2 to the key generation schemes listed in FCS_CKM.1. Upon investigation, the evaluator found that FCS_CKM.2 do not introduce any key generation scheme not include in FCS_CKM Verdict FCS_CKM.2 Guidance 1 The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s) Evaluator Findings The evaluator examined the guidance documentation to determine if it instructs the administrator how to configure TOE to use the selected key establishment schemes. The entire AGD was used to determine the verdict of this Assurance Activity. Upon investigation, the evaluator found that no configuration is required and the key establishment schemes are used automatically when the appropriate cryptographic function is invoked Verdict FCS_CKM.2 Test 1 The evaluator shall verify the implementation of the key establishment schemes of the supported by the TOE Evaluator Findings The implemented cryptographic module employed by the TOE has been subject to the Key Agreement Scheme test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below CAVP Algorithm Certificate # CVL Verdict FCS_CKM.4.1 TSS 1 The evaluator shall check to ensure the TSS lists each type of plaintext key material and its origin and storage location. 27

28 Evaluator Findings The evaluator examined the TSS to ensure that it lists each type of plaintext key material and its origin and storage location. The TSS entry for FCS_CKM.4 in section 6.1 of the ST was used to determine the verdict of this assurance activity. According to the TSS no plaintext keys are stored in volatile or non-volatile memory: Verdict FCS_CKM.4 TSS 2 The evaluator shall verify that the TSS describes when each type of key material is cleared (for example, on system power off, on wipe function, on disconnection of trusted channels, when no longer needed by the trusted channel per the protocol, etc.) Evaluator Findings The evaluator examined the TSS to determine if it describes when each type of key material is cleared. #6 in section 6 of the ST was used to determine the verdict of this assurance activity. The TSS entry for FCS_CKM.4 in section 6.1 and table 19 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the timing of each key zeroization is described in the TSS, as follows, Diffie-Hellman Shared Secret: Automatically after completion of DH exchange. Diffie-Hellman Private Exponent: Zeroized upon completion of DH exchange. SSH Private Key: Zeroized upon deletion of the SSH public/private key pair when no longer needed. AES Key: Automatically when the SSH/TLS session is terminated. Additionally, the evaluator compared each key for which the timing of zeroization is described to the totality of keys that are described in the TSS and found that the timing of zeroization for all keys supported by the TOE are described Verdict FCS_CKM.4 TSS 3 The evaluator shall also verify that, for each type of key, the type of clearing procedure that is performed (cryptographic erase, overwrite with zeros, overwrite with random pattern, or block erase) is listed. 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 clearing procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are cleared by overwriting once with zeros, while secret keys stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write") Evaluator Findings The evaluator examined the TSS to determine if for each type of key, the type of clearing procedure is listed. The TSS entry for FCS_CKM.4 in section 6.1 as well as table 19 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that all key zeroization is done by overwriting with 0x00. Additionally, the evaluator compared each key for which the method of zeroization is described to the totality of keys that are described in the TSS and found that the timing of zeroization for all keys supported by the TOE are described. 28

29 Verdict FCS_COP.1(1) Test 1 The evaluator shall verify the implementation of symmetric encryption supported by the TOE Evaluator Findings The implemented cryptographic module employed by the TOE has been subject to the Encryption test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below CAVP Algorithm Certificate # AES 4561, Verdict FCS_COP.1(2) Test 1 The evaluator shall verify the implementation of the digital signature algorithms supported by the TOE Evaluator Findings The implemented cryptographic module employed by the TOE has been subject to the Digital Signature test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below CAVP Algorithm Certificate # ECDSA 1113, 1155 RSA 2488, Verdict FCS_COP.1(3) TSS 1 The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS Evaluator Findings The evaluator examined the TSS to determine that the association of the hash function with other TSF cryptographic features is documented in the TSS. The TSS entry for FCS_COP.1(3) in section 6.1 of the ST was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the TSS describes each of the associated TSF cryptographic functions for which hashing is associated with, as follows, TLS session integrity Additionally, the evaluator compared the list of cryptographic functions provided by the TSF to the functions mapped in the TSS and found them to be consistent. 29

30 Verdict FCS_COP.1(3) Guidance 1 The evaluator checks the AGD documents to determine that any configuration that is required to configure the required hash sizes is present Evaluator Findings The evaluator examined the guidance documents to determine if they describe any configuration that is required for the required hash sizes. Section 5.1 of the AGD was used to determine the verdict of this assurance activity. Upon investigation, the evaluator found that the following hash sizes configurations are required, There are no hash configurations required by the administrator. Hashes are automatically selected based on cryptographic protocol usage. Additionally, the evaluator compared the instructions listed in AGD to the actual usage of the TOE during testing and found that the listed configuration covers the each way the hash functions can be configured for the TOE Verdict FCS_COP.1(3) Test 1 The evaluator shall verify the implementation of hashing supported by the TOE Evaluator Findings The implemented cryptographic module employed by the TOE has been subject to the Hashing test. The module passed each test. The individual algorithm implementations have been tested against the CAVP algorithm validation system. The associated certificate number is listed below CAVP Algorithm Certificate # SHA 3739, Verdict FCS_COP.1(4) TSS 1 The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used Evaluator Findings The evaluator examined the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used. The TSS entry for FCS_COP.1(4) in section 6.1 of the ST was used to determine the verdict of this assurance activity. The evaluator found the following information in the TSS for the supported HMACs: Key length: 160 bits Hash function used: HMAC-SHA-1 Block size: 512 bits 30