Assurance Activity Report (NDcPP10/IPScEP211) for FirePOWER 6.1

Transcription

1 Assurance Activity Report (NDcPP10/IPScEP211) for FirePOWER 6.1 Version 0.4 1/03/2018 Prepared by: Gossamer Security Solutions Accredited Security Testing Laboratory Common Criteria Testing Catonsville, MD Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme Document: AAR-VID Gossamer Security Solutions, Inc.

2 REVISION HISTORY Revision Date Authors Summary Version /29/2017 Haley Initial draft /01/2017 Haley Updated for new Guidance and Security Target /13/2017 Haley Respond to Validation Comments 0.4 1/3/2018 Haley Clerical corrections The TOE Evaluation was sponsored by: Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA Evaluation Personnel: Cornelius Haley Khai Van Common Criteria Versions: Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 4, September 2012 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 4, September 2012 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1 Revision 4, September 2012 Common Evaluation Methodology Versions: Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, July 2012 GSS CCT Assurance Activity Report Page 2 of Gossamer Security Solutions, Inc.

3 TABLE OF CONTENTS 1. Introduction References Acronyms CAVP Certificate Justification Protection Profile SFR Assurance Activities Security audit (FAU) Audit Data Generation (FAU_GEN.1) Audit Data Generation (IPS) (FAU_GEN.1(1)) User identity association (FAU_GEN.2) Audit Review (IPS Data) (FAU_SAR.1) Restricted Audit Review (IPS Data) (FAU_SAR.2) Selectable Audit Review (IPS Data) (FAU_SAR.3) Protected Audit Trail Storage (IPS Data) (FAU_STG.1) Prevention of Data Loss (IPS Data) (FAU_STG.4) Protected Audit Event Storage (FAU_STG_EXT.1) Cryptographic support (FCS) Cryptographic Key Generation (FCS_CKM.1) Cryptographic Key Establishment (FCS_CKM.2) Cryptographic Key Destruction (FCS_CKM.4) Cryptographic Operation (AES Data Encryption/Decryption) (FCS_COP.1(1)) Cryptographic Operation (Signature Generation and Verification) (FCS_COP.1(2)) Cryptographic Operation (Hash Algorithm) (FCS_COP.1(3)) Cryptographic Operation (Keyed Hash Algorithm) (FCS_COP.1(4)) HTTPS Protocol (FCS_HTTPS_EXT.1) Random Bit Generation (FCS_RBG_EXT.1) SSH Server Protocol (FCS_SSHS_EXT.1) TLS Client Protocol with authentication (FCS_TLSC_EXT.2) TLS Server Protocol (FCS_TLSS_EXT.1) Identification and authentication (FIA) Password Management (FIA_PMG_EXT.1) Protected Authentication Feedback (FIA_UAU.7) GSS CCT Assurance Activity Report Page 3 of Gossamer Security Solutions, Inc.

4 2.3.3 Password-based Authentication Mechanism (FIA_UAU_EXT.2) User Identification and Authentication (FIA_UIA_EXT.1) X.509 Certificate Validation (FIA_X509_EXT.1) X.509 Certificate Authentication (FIA_X509_EXT.2) X.509 Certificate Requests (FIA_X509_EXT.3) Security management (FMT) Management of security functions behavior - Trusted Update (FMT_MOF.1(1)) Management of Security Functions Behavior (FMT_MOF.1/IPS) Management of IPS data (FMT_MTD.1/IPS) Management of TSF Data (FMT_MTD.1(1)) Specification of Management Functions (FMT_SMF.1) Specification of Management Functions (IPS) (FMT_SMF.1(1)) Restrictions on Security Roles (FMT_SMR.2) Security roles (IPS) (FMT_SMR.2(1)) Protection of the TSF (FPT) Protection of Administrator Passwords (FPT_APW_EXT.1) Basic Internal TSF Data Transfer Protection (FPT_ITT.1) Protection of TSF Data (for reading of all symmetric keys) (FPT_SKP_EXT.1) Reliable Time Stamps (FPT_STM.1) TSF testing (FPT_TST_EXT.1) Trusted update (FPT_TUD_EXT.1) TOE access (FTA) TSF-initiated Termination (FTA_SSL.3) User-initiated Termination (FTA_SSL.4) TSF-initiated Session Locking (FTA_SSL_EXT.1) Default TOE Access Banners (FTA_TAB.1) Trusted path/channels (FTP) Inter-TSF trusted channel (FTP_ITC.1) Trusted Path (FTP_TRP.1) Intrusion Prevention Systems (IPS) Anomaly-Based IPS Functionality (IPS_ABD_EXT.1) IP Blocking (IPS_IPB_EXT.1) GSS CCT Assurance Activity Report Page 4 of Gossamer Security Solutions, Inc.

5 2.8.3 Network Traffic Analysis (IPS_NTA_EXT.1) Signature-Based IPS Functionality (IPS_SBD_EXT.1) DECODE_NOT_IPV4_DGRAM DECODE_IPV6_IS_NOT DECODE_IPV6_TRUNCATED_EXT DECODE_IPV6_BAD_NEXT_HEADER DECODE_IPV6_TWO_ROUTE_HEADERS DECODE_TCPOPT_TRUNCATED Protection Profile SAR Assurance Activities Development (ADV) Basic functional specification (ADV_FSP.1) Guidance documents (AGD) Operational user guidance (AGD_OPE.1) Preparative procedures (AGD_PRE.1) Life-cycle support (ALC) Labelling of the TOE (ALC_CMC.1) TOE CM coverage (ALC_CMS.1) Tests (ATE) Independent testing - conformance (ATE_IND.1) Vulnerability assessment (AVA) Vulnerability survey (AVA_VAN.1) GSS CCT Assurance Activity Report Page 5 of Gossamer Security Solutions, Inc.

6 1. INTRODUCTION This document presents evaluation results of the Cisco FirePOWER NDcPP10/IPScEP21 evaluation. This document contains a description of the assurance activities and associated results as performed by the evaluators. 1.1 REFERENCES The following guidance documentation included material used to satisfy the Guidance assurance activities. [ST] CISCO FirePOWER Version 6.1 Security Target, Version 1.0, January 2, 2018 [Guide] CISCO Common Criteria Supplemental User Guide for FirePOWER v6.1, Version 1.0, December 13, 2017 Other Documentation References [NDcPP10] collaborative Protection Profile for Network Devices, Version 1.0, 27 February [IPScEP211] collaborative Protection Profile for Network Devices/collaborative Protection Profile for Stateful Traffic Filter Firewalls Extended Package (EP) for Intrusion Prevention Systems (IPS), Version 2.11, 15 June ACRONYMS Term AES AMP CAVP CRL DUT ECDSA FMC FMCv HMAC IPS NGIPSv SHA SSH ST TLS TOE TSF TSS Definition Advanced Encryption Standard Name for one model of TOE sensor Cryptographic Algorithm Validation Program Certificate Revocation List Device Under Test Elliptic Curve Digital Signature Algorithm Firepower Management Center Firepower Management Center Virtual (FMC w/i a VM) Keyed-Hash Message Authentication Code Intrusion Prevention System Name for a model of TOE Sensor that is running in a VM Secure Hash Algorithm Secure Shell Security Target Transport Layer Security Target of Evaluation TOE Security Functionality TOE Summary Specification 1.3 CAVP CERTIFICATE JUSTIFICATION The TOE has been CAVP tested. As a result, the evaluator is relying on the associated CAVP testing results to address test assurance activities for the following security functional requirements: GSS CCT Assurance Activity Report Page 6 of Gossamer Security Solutions, Inc.

7 FCS_CKM.1 FCS_CKM.2 FCS_COP.1(1) FCS_COP.1(2) FCS_COP.1(3) FCS_COP.1(4) FCS_RBG_EXT.1 The following describes the TOE hardware and software, providing details for the various TOE models that support the applicability of the claimed CAVP certificates. Since the CAVP certificates all identify firmware implementations, Table 1-1 and Table 1-2 identify the processors included in each of the TOE models claimed by the Security Target. Table 1-1 Platforms for Physical Devices ST Processor CERT Processor ST Model Intel Atom D2xxx Intel Atom D2xxx 7010, 7020, 7030 Intel Pentium B9xx Intel Pentium B9xx 7050 Intel Xeon 34xx Intel Xeon 34xx 7110, 7115, 7120, 7125, AMP7150 Intel Xeon 5xxx Intel Xeon 5xxx 8120, 8130, 8140, 8250, 8260, 8270, 8290, 8360, 8370, 8390, AMP8050, AMP8150, AMP8360, AMP8370, AMP8390 Intel Xeon E Intel Xeon E series FS750 series Intel Xeon E Intel Xeon E series FS2000, FS4000 series Intel Xeon E5600 series Intel Xeon E5600 series 8350, 8350AMP, FS1500, FS3500 Table 1-2 Platforms for Virtual Devices ST Processor CERT Processor ST Model Xeon E5 w/ ESXi 5.5 Intel Xeon E5 w/ ESXi 5.5; UCS B200-M3, B200-M4, B420 M4, B420 M3, B22 M3, C22 M3, C24 M3, C220 M3, C220 M4, C240 M3, C240 M4, C420 M3, E140D M1, E160D M2 & M1, E180D M2, E140DP M1, E160DP M1 Xeon E7 w/ ESXi 5.5 Intel Xeon Eseries w/ ESXi 5.5 B260 M4, B460 M4, B230 M2, B440 M2, C260 M2, C460 M2, C460 M4 Xeon E w/ ESXi 5.5 Intel Xeon Eseries w/ ESXi 5.5 UCS E140S M1 and M2 The FMC and Sensors (Series 7k, 8k and AMP) include the FMC FOM version 6.0 firmware cryptographic functions. The FMCv and NGIPSv includes the FMC FOM virtual version 6.0 firmware cryptographic functions. The same FMCv and NGIPSv images run on ESXi 5.5 and ESXi 6.0. The difference between ESXi 5.5 and 6.0 represents minor version variations. These variations are related to performance only. ESXi 6.0 supports more RAM (memory) per host, more processors per host, etc. The differences are not relevant since the hardware platforms included in the evaluation do not make use of these differences. VMware publishes information describing the differences between these versions. These differences do not affect the FMCv or NGIPSv image s GSS CCT Assurance Activity Report Page 7 of Gossamer Security Solutions, Inc.

8 cryptographic implementation because FMCv and NGIPSv only use a preset number of processors and amount of RAM, regardless of the hypervisor versions. The following table shows the CAVP certificates associated with each cryptographic SFR they support. Table 1-3 TOE CAVP Certificates Functions Encryption/Decryption Requirement CAVP Certificates for Physical Models Virtual Models AES CBC (128 and 256 bits) FCS_COP.1(1) AES: 4266 AES: 4411 Cryptographic signature services RSA Digital Signature Algorithm (rdsa) (modulus 2048) ECDSA Digital Signature Algorithm (P-256, 384, 521) Cryptographic hashing FCS_COP.1(2) RSA: 2297 RSA: 2397 FCS_COP.1(2) ECDSA: 995 ECDSA: 1063 SHA-1/256/512 (digest sizes 160, 256, and 512 bits) FCS_COP.1(3) SHS: 3512 SHS: 3637 Keyed-hash message authentication HMAC-SHA-1, HMAC_SHA2-256, HMAC-SHA2-512 (digest sizes 160, 256, and 512 bits) Random bit generation RNG with sw based noise sources Key Generation FCS_COP.1(4) HMAC: 2811 HMAC: 2932 FCS_RBG_EXT.1 DRBG: 1337 DRBG: 1425 RSA Key Generation FCS_CKM.1 RSA: 2297 RSA: 2397 ECDSA Key Generation FCS_CKM.1 ECDSA: 995 ECDSA: 1063 DSA Key Generation FCS_CKM.1 DSA: 1197 DSA: 1196 Key Establishment FFC/ECC KAS FCS_CKM.2 CVL: 1183 CVL: 1182 Key Derivation Functions TLS and SSH CVL: 1008 CVL: 1117 GSS CCT Assurance Activity Report Page 8 of Gossamer Security Solutions, Inc.

9 1.4 TEST PLATFORM EQUIVALENCY The evaluation team exercised the independent tests specified in the Security Requirements for Network Devices, Version 1.0, 10 December 2010 (including the optional HTTPS, SSH, and TLS requirements) against the evaluated configuration of the TOE. The evaluation team also exercised the independent tests specified by the collaborative Protection Profile for Network Devices/collaborative Protection Profile for Stateful Traffic Filter Firewalls Extended Package (EP) for Intrusion Prevention Systems (IPS). The evaluators utilized a test server (identified as testlab1v) to initiate tests, generate traffic and act as a syslog server. The network infrastructure also included a test server acting as a Fake Gateway (FakeGW), and several network switches (including a Cisco Catalyst switch) which are not part of the TOE. Figure 1-1 General Test Bed Topology, presents a generalized design of the network (w/o networking details) to show how the Management network, Test Network and Probe Network are defined relative to the test server and the IPS devices being tested. In both test bed Alpha and Beta topologies, there is an isolated Management network (shown as yellow lines in the figures). This management network is used for all communication from administrators to the various TOE devices (trusted path), for communication between TOE components (Inter-TOE Transfers) and for communication to a trusted syslog server (trusted channel). Figure 1-1 General Test Bed Topology TOE Platforms Tested: FS-750 Firepower Management Center AMP 7150 Sensor (also a Series 7000 Model ) 1 The Model 7030 was used to for a very small sample of tests (~ 6) because of a hardware failure in the AMP7150 that occurred after all other test had been completed. The evaluator installed the very same software image onto the 7030 that had been installed previously on the AMP7150. GSS CCT Assurance Activity Report Page 9 of Gossamer Security Solutions, Inc.

10 FMCv running on B220 w/ ESXi 5.5 NGIPSv running on B220 w/ ESXi 5.5 All models identified by the Security Target as being included in the evaluation utilize one of the following four software images: Physical FMC image Virtual FMC image Physical Sensor Image Virtual Sensor Image (a.k.a., NGIPSv) The physical FMC and Sensors (Series 7k, 8k and AMP) include the FMC FOM version 6.0 firmware cryptographic functions. The virtual FMC (FMCv) and NGIPSv includes the FMC FOM virtual version 6.0 firmware cryptographic functions. Thus, all models in the evaluated configuration have been subject to CAVP testing and share the same cryptographic library. As such, it is concluded that the cryptographic functions are equivalent despite any model differences. While models may have different processors, they all utilize the same x64 architecture. In addition, the very same Physical Sensor image is installed onto every physical sensor device in the 7000, 8000 and AMP series. The evaluator installed the one image into both the AMP7150 and the model The Model 7030 was used to for a very small sample of tests (~ 6) because of a hardware failure in the AMP7150 that occurred after all other test had been completed. Similarly, all FMC management devices utilize an x64 architecture and the same software image is installed onto every FMC model. All FMC devices (physical and virtual) and virtual Sensors run on platforms with Xeon processors. The AMP7150 model utilizes a Xeon processor and the Model 7030 utilizes an Atom processor, so the evaluation included limited testing for both processor sets. However, Intel's current CPUs (i.e., Atom, Pentium and Xeon) have the same base instruction set and differ in advanced technologies (SSE instructions, Turbo boost, Hyper-threading, virtualization, speed step, etc. which should not affect the actual operation but the rather will affect performance. The evaluators tested a physical IPS sensor and FMC management device, along with a virtual IPS sensor and virtual FMC management device, running all tests on each set of devices. The NDcPP tests were run against each component (i.e., physical FMC, virtual FMC, physical sensor, and virtual sensor). The IPS tests were performed against an FMC controlling a physical sensor and a virtual sensor. The IPS testing performed on test bed alpha used the physical FMC device to control and test both the physical IPS and the virtual IPS devices. The IPS testing performed on test bed beta, used a virtual FMC device to control and test both of the reconfigured physical IPS and virtual IPS devices. We believe this test coverage shows that physical FMC and sensors can operate in any combination. The same NGIPSv image runs on ESXi 5.5 and ESXi 6.0. The difference between ESXi 5.5 and 6.0 is performance only and ESXi 6.0 supports more RAM (memory) per host, more processors per host, etc. VMware publishes information describing the differences between these versions. These differences do not affect the NGIPSv image s cryptographic implementation because NGIPSv only uses a preset number of processors and amount of RAM, regardless of the hypervisor versions. GSS CCT Assurance Activity Report Page 10 of Gossamer Security Solutions, Inc.

11 2. PROTECTION PROFILE SFR ASSURANCE ACTIVITIES 2.1 SECURITY AUDIT (FAU) AUDIT DATA GENERATION (FAU_GEN.1) FAU_GEN FAU_GEN.1.2 Component Component Guidance Assurance Activities: 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. 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. GSS CCT Assurance Activity Report Page 11 of Gossamer Security Solutions, Inc.

12 Section 4.2 of [Guide] indicates that the TOE generates audit records for each user interaction with the web and CLI interface, as well as recording system status messages in the system log. For the CLI, the appliance also generates an audit record for every command executed. These events all include timestamps, user identifiers, messages/event identifiers (which include an indication of success or failure). The [Guide] distributes the specific details of audit records throughout the document, describing audit record content with the administrative actions or system behaviors that cause the audit record to be generated. All reference to Sections in the following table are to sections within [Guide]. SFR Auditable Event Reproduced from the NDcPP FCS_HTTPS_EXT.1 Failure to establish an HTTPS session. Additional Audit Record Contents Reason for failure Guidance Doc Reference Section 4.2 shows examples of user login and logout via the HTTPS connection. FCS_SSHS_EXT.1 FCS_TLSC_EXT.2 FCS_TLSS_EXT.1 FIA_UIA_EXT.1 FIA_UAU_EXT.2 FIA_X509_EXT.1 FMT_MOF.1(1)/ TrustedUpdate FMT_MTD.1 Failure to establish an SSH session Successful SSH rekey Failure to establish an TLS Session Failure to establish an TLS Session All use of the identification and authentication mechanism. All use of the identification and authentication mechanism. Unsuccessful attempt to validate a certificate Any attempt to initiate a manual update All management activities of TSF data. Reason for failure Non-TOE endpoint of connection (IP address) Reason for failure Reason for failure Provided user identity, origin of the attempt (e.g., IP address). Origin of the attempt (e.g., IP address). Reason for failure None. None. Section 4.2 includes TLS failure audits (e.g., mismatched ciphersuites, handshake failure, bad record MAC). Section 4.2 shows two examples of SSH failure audits. This audit removed by TD0150 Section 4.2 includes TLS failure audits (e.g., mismatched ciphersuites, handshake failure, bad record MAC). Section 4.2 includes TLS failure audits (e.g., mismatched ciphersuites, handshake failure, bad record MAC). Section 4.1 and 4.2 shows examples of user login and logout via the SSH and HTTPS connections. Section 4.1 and 4.2 shows examples of user login and logout via the SSH and HTTPS connections. Section 4.2 includes TLS audit failures for problems associated with X509 certificates (e.g., subject mismatch, expired, revoked). Section Product Upgrade, shows an example of a successful product update. Section 4.2 shows examples of audit events for web interface and CLI operations. FPT_TUD_EXT.1 Initiation of No additional Section Product Upgrade, shows an GSS CCT Assurance Activity Report Page 12 of Gossamer Security Solutions, Inc.

13 SFR FPT_STM.1 FTA_SSL_EXT.1 Auditable Event update; result of the update attempt (success or failure) Changes to the time. Any attempts at unlocking of an interactive session. Additional Audit Record Contents information. The old and new values for the time. Origin of the attempt to change time for success and failure (e.g., IP address). None. Guidance Doc Reference example of a successful product update. This includes an indication that the update succeeded. Section shows examples of audits of time updates, including the old and new time values, origin of the change request, and an indication that the change was successful. Since the TOE terminates inactive sessions, unlocking is equivalent to a new login, and is covered by the audits for FIA_UIA_EXT.1. FTA_SSL.3 FTA_SSL.4 FTP_ITC.1 FTP_TRP.1 The termination of a remote session by the session locking mechanism. The termination of an interactive session. Initiation of the trusted channel. Termination of the trusted channel. Failure of the trusted channel functions. Initiation of the trusted channel. Termination of the trusted channel. Failures of the trusted path functions. Reproduced from the IPScEP FMT_SMF.1/IPS Modification of an IPS policy element. None. None. Identification of the initiator and target of failed trusted channels establishment attempt Identification of the claimed user identity. Identifier or name of the modified IPS policy element (e.g. which signature, baseline, or knowngood/known-bad list was modified). Section shows audit records indicating a user is logged out due to inactivity. Section shows audit record format and content indicating user logout from either the Web UI or the CLI. Section 4.1 includes audits indicating TLS session establishment and termination. Section 4.2 includes TLS failure audits (e.g., mismatched ciphersuites, handshake failure, bad record MAC). Section 4.2 shows SSH session establishment and termination audits, along with examples of SSH failure audits. Section 4.2 shows examples of user login and logout via the HTTPS connection. Section 4.2 includes TLS failure audits (e.g., mismatched ciphersuites, handshake failure, bad record MAC). Section and show audit events associated with changing intrusion rules. These audits include an identifier for the rule. GSS CCT Assurance Activity Report Page 13 of Gossamer Security Solutions, Inc.

14 SFR IPS_ABD_EXT.1 Auditable Event Inspected traffic matches an anomaly-based IPS policy. Additional Audit Record Contents Source and destination IP addresses. Guidance Doc Reference Section describes that any Intrusion Rule can be assigned one of 3 states: Generate Events, Drop and Generate Events or Disable which controls the manner in which the rule is applied. IPS_IPB_EXT.1 Inspected traffic matches a list of known-good or known-bad addresses applied to an IPS policy. The content of the header fields that were determined to match the policy. TOE interface that received the packet. Aspect of the anomaly-based IPS policy rule that triggered the event (e.g. throughput, time of day, frequency, etc.). Network-based action by the TOE (e.g. allowed, blocked, sent reset to source IP, sent blocking notification to firewall). Source and destination IP addresses (and, if applicable, indication of whether the source and/or destination address matched the list). TOE interface that received the packet. Network-based action by the TOE Section describes how to view, search and sort intrusion events. This section also includes a description of the fields present within intrusion events. Section indicates all of the fields that are shown within every Intrusion event. One field is a message field that is specific to each rule, and indicates the rule specific data. Section indicates that the Ingress and Egress interface are shown within every Intrusion event and these fields can be used for searching and sorting. Section indicates all of the fields that are shown within every Intrusion event. One field is a message field that is specific to each rule, and indicates the rule specific data. This message is used to describe the anomalybased detection. Section indicates that the Inline Result is shown within every Intrusion event. Section 4.2 shows examples of events for access control rules (the mechanism used to support IP Blocking features). Each audit event indicate the interface by specifying the Ingress and Egress zones. Each audit event indicate the action by specifying an Action. GSS CCT Assurance Activity Report Page 14 of Gossamer Security Solutions, Inc.

15 SFR IPS_NTA_EXT.1 Auditable Event Modification of which IPS policies are active on a TOE interface. Enabling/disabling a TOE interface with IPS policies applied. Additional Audit Record Contents (e.g. allowed, blocked, sent reset). Identification of the TOE interface. The IPS policy and interface mode (if applicable). Guidance Doc Reference Section shows audit events associated with modification of IPS policies. Section shows audit events associated with modification of IPS policies, however, it is not possible to tell from the audit events what interface mode is configured. IPS_SBD_EXT.1 Modification of which mode(s) is/are active on a TOE interface. Inspected traffic matches a signature-based IPS policy. Name or identifier of the matched signature. Source and destination IP addresses. The content of the header fields that were determined to match the signature. TOE interface that received the packet. Network-based action by the TOE (e.g. allowed, blocked, sent reset). Section indicates all of the fields that are shown within every Intrusion event. One field is a message field that is specific to each rule, and indicates the rule specific data. This message is used to describe the anomalybased detection. Section indicates that the Source IP and Destination IP addresses are shown within every Intrusion event and these fields can be used for searching and sorting. Section indicates all of the fields that are shown within every Intrusion event. One field is a message field that is specific to each rule, and indicates the rule specific data. Section indicates that the Ingress and Egress interface are shown within every Intrusion event and these fields can be used for searching and sorting. Section indicates that the Inline Result is shown within every Intrusion event. Component Testing Assurance Activities: 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 above. This should include all instances of an event: for instance, if there are several GSS CCT Assurance Activity Report Page 15 of Gossamer Security Solutions, Inc.

16 different I&A mechanisms for a system, the FIA_UIA_EXT.1 events must be generated for each mechanism. 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. Logging of all activities related to trusted update should be tested in detail and with utmost diligence. 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. Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. The evaluator created a list of the required audit events. The evaluator then collected the audit event when running the other security functional tests described by the protection profiles. For example, the required event for FPT_STM.1 is Changes to Time. The evaluator collected these audit records when modifying the clock using administrative commands and NTP. The evaluator then recorded these audit events in the proprietary Detailed Test Report (DTR). The security management events are handled in a similar manner. When the administrator was required to set a value for testing, the audit record associated with the administrator action was collected and recorded in the DTR AUDIT DATA GENERATION (IPS) (FAU_GEN.1(1)) FAU_GEN.1(1) FAU_GEN.1(1).2 Component TSS Assurance Activities: The evaluator shall verify that the TSS describes how the TOE can be configured to log IPS data associated with applicable policies. The evaluator shall verify that the TSS describes what (similar) IPS event types the TOE will combine into a single audit record along with the conditions (e.g., thresholds and time periods) for so doing. The TSS shall also describe to what extent (if any) that may be configurable. GSS CCT Assurance Activity Report Page 16 of Gossamer Security Solutions, Inc.

17 Section 6.1 of [ST] explains that an administrator configures an IPS sensor in either inline or passive mode, creates intrusion policies composed of intrusion rules, and assigns intrusion policies to access policies which are applied to TOE interfaces. Component Guidance Assurance Activities: The evaluator shall verify that the operational guidance describes how to configure the TOE to result in applicable IPS data logging. The evaluator shall verify that the operational guidance provides instructions for any configuration that may be done in regard to logging similar events (e.g., setting thresholds, defining time windows, etc.). Section 4.7 of [Guide] describes how to configure IPS policies and rules which cause IPS data logging. Section specifically discusses Rate-based attack prevention. Component Testing Assurance Activities: Test 1: The evaluator shall test that the interfaces used to configure the IPS polices yield expected IPS data in association with the IPS policies. A number of IPS policy combination and ordering scenarios need to be configured and tested by attempting to pass both allowed and anomalous network traffic matching configured IPS policies in order to trigger all required IPS events. Note that this activity should have been addressed with a combination of the Test assurance activities for the other IPS requirements. This testing was performed as part of the testing for the generation of audits for individual signature-based rules, anomaly-based rules and IP blocking rules. Refer to testing of IPS_SBD_EXT.1, IPS_ABD_EXT.1 and IPS_IPB_EXT USER IDENTITY ASSOCIATION (FAU_GEN.2) FAU_GEN.2.1 Component Component Component Testing Assurance Activities: This activity should be accomplished in conjunction with the testing of FAU_GEN.1.1. See the test results for FAU_GEN AUDIT REVIEW (IPS DATA) (FAU_SAR.1) FAU_SAR.1.1 GSS CCT Assurance Activity Report Page 17 of Gossamer Security Solutions, Inc.

18 FAU_SAR.1.2 Component TSS Assurance Activities: The evaluator shall examine the TSS to verify that it describes the ability of administrators to view IPS data from the IPS events, the format in which this IPS data is displayed, and how an administrator is authorized to view this data. Section 6.1 (FAU_SAR.1*) in [ST] indicates that IPS intrusion event records can be viewed only through the webbased UI provided by the FMC component of the TOE. This table entry in section 6.1 also states that only Administrators and Intrusion Admins have access to the intrusion events. Component Guidance Assurance Activities: The evaluator shall examine the operational guidance to verify that it provides instructions on how to access and interpret IPS events using the TOE's management interface. Section of [Guide] indicates that the TOE supports the viewing of Intrusion Event audit data by Administrators and Intrusion Admins. This section enumerates the values that can be used for searching, sorting and filtering these Intrusion events. Component Testing Assurance Activities: Test 1: The evaluator shall devise tests that demonstrate that IPS data (generated as defined in FAU_GEN) can be interpreted by authorized administrators from the TOE's management interface. The evaluator logged into the TOE as an administrative user authorized to view intrusion IPS events, and opened the window displaying IPS events. The evaluator was able to inspect intrusion events using that GUI RESTRICTED AUDIT REVIEW (IPS DATA) (FAU_SAR.2) FAU_SAR.2.1 GSS CCT Assurance Activity Report Page 18 of Gossamer Security Solutions, Inc.

19 Component TSS Assurance Activities: Since administrative roles are needed to view the IPS data, the analysis performed by the evaluators in the Assurance Activity for FMT_MTD.1/IPS will demonstrate that this requirement is met. Section 6.1 (FAU_SAR.2*) in [ST] indicates that IPS intrusion event records can be viewed only through the webbased UI provided by the FMC component of the TOE. This table entry in section 6.1 also states that only Administrators and Intrusion Admins have access to the intrusion events. Component Component SELECTABLE AUDIT REVIEW (IPS DATA) (FAU_SAR.3) FAU_SAR.3.1 Component TSS Assurance Activities: The evaluator shall verify that the TSS includes a description of how the TOE has the ability to apply filtering and sorting of IPS data using the parameters listed in the requirement. Section 6.1 (FAU_SAR.3*) of [ST] states that the web-based UI is the only way to view the intrusion events (Analysis > Intrusions > Events). This section includes a list of all values within the IPS data that the UI allows to be used for filtering and sorting. The section indicates that basic contents of each record like date, time and type of export also be used to filter and sort. It states that risk ratings (Application Risk and Priority), source IP, and destination IP can be used for filtering the IPS data. This section states that signature ID (Access Control Rule) and IPS actions (Inline Result) can be used for sorting. Additionally, this section enumerates numerous other fields that can be used to filter or sort the IPS data. Component Guidance Assurance Activities: The evaluator shall review the administrative guidance to ensure that the guidance itemizes all event types, as well as describes all attributes that are to be selectable in accordance with the requirement, to include those attributes listed in the assignment. The administrative guidance shall also contain instructions on how to set the pre-selection, as well as explain the syntax (if present) for multi-value preselection. The administrative guidance shall also identify those audit records that are always recorded, regardless of the selection criteria currently being enforced. Section of [FP Guide] addresses the issue of viewing, searching and sorting of Intrusion events. These operations include support for filters available for searching Intrusion events. The set of operations supported by the TOE match those in the Guidance and are the same as that described by the SFR and TSS. Section also GSS CCT Assurance Activity Report Page 19 of Gossamer Security Solutions, Inc.

20 indicates that a priority can be assigned to each field displayed, as a way of defining the sorting of displayed events. Component Testing Assurance Activities: The evaluator shall perform the following tests: Test 1: For each attribute listed in the requirement, the evaluator shall devise a test to show that selecting the attribute causes only audit events with that attribute (or those that are always recorded, as identified in the administrative guidance) to be recorded. Test 2 [conditional]: If the TSF supports specification of more complex audit pre-selection criteria (e.g., multiple attributes, logical expressions using attributes) then the evaluator shall devise tests showing that this capability is correctly implemented. The evaluator shall also, in the test plan, provide a short narrative justifying the set of tests as representative and sufficient to exercise the capability. The evaluator utilized the search feature during testing to locate the IPS events shown for FAU_GEN.1(1), as well as other searches and observed that the events displayed were consistent with the Search Constraints and Time Windows configured. The TOE does not support preselection criteria PROTECTED AUDIT TRAIL STORAGE (IPS DATA) (FAU_STG.1) FAU_STG FAU_STG.1.2 Component TSS Assurance Activities: The evaluator shall ensure that the TSS identifies how IPS data is protected from unauthorized modification and deletion. Section 6.1 (FAU_STG.1*) in [ST] explains that only Administrators and Intrusion Admins have access to the intrusion events. The intrusion events cannot be modified but they can be deleted by the Administrators or Intrusion Admins who have restricted access. GSS CCT Assurance Activity Report Page 20 of Gossamer Security Solutions, Inc.

21 Component Guidance Assurance Activities: The evaluator shall confirm the guidance documentation describes how to protect IPS data from unauthorized modification and deletion. The TOE protects IPS data based upon a user s role. Section of [FP Guide] identifies the available roles, and permissions for each role. IPS Administrator (or Administrator): Have all privileges and access IPS Analyst (or Intrusion Admin): Have all access to intrusion policies and network analysis privileges but cannot deploy policies Access Admin: Have all access to access control policies but cannot deploy policies Discovery Admin: Have all access to network discovery, application detection, and correlation features but cannot deploy policies Security Analyst: Have all access to security event analysis feature Component Testing Assurance Activities: Test 1: The evaluator shall devise tests that demonstrate that IPS data can be protected from unauthorized modification and deletion. The evaluator logged into the TOE as an administrator not authorized to delete audit records (all roles except IPS admin) and observed that the GUI to view and delete audit records was not offered to that user PREVENTION OF DATA LOSS (IPS DATA) (FAU_STG.4) FAU_STG.4.1 Component TSS Assurance Activities: The evaluator shall ensure that the TSS identifies how IPS data logging is handled once the IPS data trail is full. The TSS shall also identify how IPS data logging is restored. Section 6.1 (FAU_STG.1*) in [ST] explains that when the intrusion events storage is full, the newest data will overwrite the oldest data. Component Guidance Assurance Activities: The evaluator shall confirm the guidance documentation describes the steps involved to manage IPS data logging when the IPS audit trail is full. Section of [FP Guide] indicates that when the intrusion events storage is full, the newest data will overwrite the oldest data. Component Testing Assurance Activities: There are no test assurance activities for this requirement. GSS CCT Assurance Activity Report Page 21 of Gossamer Security Solutions, Inc.

22 There are no test assurance activities for this requirement PROTECTED AUDIT EVENT STORAGE (FAU_STG_EXT.1) FAU_STG_EXT FAU_STG_EXT FAU_STG_EXT.1.3 Component TSS Assurance Activities: 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. 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. If the TOE complies with FAU_STG_EXT.2 the evaluator shall verify that the numbers provided by the TOE according to the selection for FAU_STG_EXT.2 are correct when performing the tests for FAU_STG_EXT.1.3. 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. Section 6.1 (FAU_STG_EXT.1) in [ST] explains that the TOE can generate an audit record for each user interaction with the web interface and each command in the CLI interface in the audit log, and can also record system status messages in the system log (i.e., syslog). Further, it indicates that administrators can configure the system to GSS CCT Assurance Activity Report Page 22 of Gossamer Security Solutions, Inc.

23 transmit all of these audit event logs in real-time over a secure TLS connection to an external audit server in the operational environment. When an audit event is generated, it is sent to the local database and external audit server simultaneously. This ensures that current audit events can be viewed locally while all events, new or old, are stored off-line. Section 6.1 also indicates that the audit log is stored as rows in an internal/local database. After the administrator configured limit of rows (i.e., audit records) is exceeded, the oldest rows are deleted, reducing the amount of audit data back to the configured limit. For syslog, the logs are stored in /var/log/messages and are rotated daily or when the log file size exceeds 25 MB. After the maximum number of backlog files is reached, the oldest is deleted and the numbers on the other backlogs file are incremented. Both of these logs write new data and delete the oldest data. The TOE does not claim FAU_STG_EXT.2. Component Guidance Assurance Activities: 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. 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. 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. Section 4.4 of [FP Guide] describes how to configure a secure connection with an audit server using the syslog protocol. It explains the process for configuring the TOE components with an audit client certificate (i.e., a certificate used to identify the TOE to the audit server). It also explains how to specify the external audit server using the Web UI. Section 4.4 of [FP Guide] describes that an administrator can configure the system such that it can transmit audit and syslog records securely to an external audit server while also storing the audit and syslog records locally. Section of [FP Guide] identifies two types of audit data ( Audit and syslog ) that are viewed through different Web UI screens. It explains that the Audit log stores 100,000 entries, it also indicates that this does not include audit data identified as syslog. Component Testing Assurance Activities: Testing of the trusted channel mechanism for audit will be performed as specified in the associated assurance activities for the particular trusted channel mechanism. The evaluator shall perform the following additional test for this requirement: a) 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 GSS CCT Assurance Activity Report Page 23 of Gossamer Security Solutions, Inc.

24 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 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. Depending on the configuration this means that the evaluator has to check the content of the audit data when the audit data is just filled to the maximum and then verifies that a) The audit data remains unchanged with every new auditable event that should be tracked but that the audit data is recorded again after the local storage for audit data is cleared (for the option 'drop new audit data' in FAU_STG_EXT.1.3). b) The existing audit data is overwritten with every new auditable event that should be tracked according to the specified rule (for the option 'overwrite previous audit records' in FAU_STG_EXT.1.3) c) The TOE behaves as specified (for the option 'other action' in FAU_STG_EXT.1.3). The evaluator examined audit records on each TOE component while they resided on the TOE, and after they were transmitted to an external syslog server. The contents of the records before and after the transfer were identical. The evaluator also examined a packet capture obtained during the transfer and observed that the traffic was not plaintext. Each component in the TOE includes two collections of audit records described in the following list: SYSLOG Data: SYSLOG data is stored within each device and can be retransmitted to an external (syslog) audit server via the configured TLS channel. These records include a majority of the internal operations, errors and events required by FAU_GEN.1 AUDIT Data: AUDIT data is stored within each device using a different internal storage medium from SYSLOG data. AUDIT data can also be transferred to an external (syslog) audit server. The administrative actions performed through the WebUI fall into this class. Since each collections of audit records utilizes its own limiting mechanism to define and manage the audit full condition, each was being tested. The evaluator observed that the files containing syslog data were rotated such that the oldest files were deleted to make space for new syslog data. The evaluator also observed that for AUDIT data, the system purged the oldest records periodically to reduce the number of records saved to the configured limit. 2.2 CRYPTOGRAPHIC SUPPORT (FCS) CRYPTOGRAPHIC KEY GENERATION (FCS_CKM.1) GSS CCT Assurance Activity Report Page 24 of Gossamer Security Solutions, Inc.

25 FCS_CKM.1.1 Component TSS Assurance Activities: 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. Section 6.1 (FCS_CKM.1) in [ST] is consistent with the operations in the SFR and states the TOE generates Approved RSA public/private key pairs for key establishment to support other security protocols such as SSHv2 and TLS. The RSA modulus key size is 2048 bit, which according to NIST PUB , is equivalent to a symmetric key strength of 112 bits. Component Guidance Assurance Activities: 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. Section 4.3 of [Guide] describes the steps to configure the TOE in UCAPL/CC mode which defines the set of ciphersuites, versions and protocols that the TOE supports. Once in CC mode, the TOE supports only ciphersuites, protocols and versions as defined by the [ST]. Component Testing Assurance Activities: FIPS The TOE has been CAVP tested. Refer to Section 1.3, CAVP Certificate Justification and specifically to Table 1-3 TOE CAVP Certificates CRYPTOGRAPHIC KEY ESTABLISHMENT (FCS_CKM.2) FCS_CKM.2.1 Component TSS Assurance Activities: 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 (including whether the GSS CCT Assurance Activity Report Page 25 of Gossamer Security Solutions, Inc.