assurance activity report - niap-ccevs.org · assurance activity report -junos 12.3 ... unos® os...

FOR PUBLIC RELEASE

PAGE 1 OF 84

ASSURANCE ACTIVITY REPORT JUNOS 12.3 X48-D30 FOR SRX PLATFORMS

Reference Status EFS-T041-AAR Released

Version 1.3 Release Date 17 January 2017

Author Dan Pitcher Customer Juniper Networks, Inc.

Approved By X

17025 Signatory

FOR PUBLIC RELEASE

FOR PUBLIC RELEASE

ASSURANCE ACTIVITY REPORT -JUNOS 12.3 X48-D30 FOR SRX PLATFORMS PAGE 2 OF 84

EFS-T041-AAR 1.3 17 JANUARY 2017

FOR PUBLIC RELEASE

Table of Contents

1 Introduction ...............................................................................................................4 1.1 Overview ...........................................................................................................................4 1.2 Evaluation details ...............................................................................................................4 1.3 ST configuration control identifiers ......................................................................................4 1.4 TOE Configuration..............................................................................................................4 1.5 References.........................................................................................................................4 1.5.1 Requirements................................................................................................................................ 4

1.5.2 Evaluation Evidence....................................................................................................................... 4

1.6 Copyright statement...........................................................................................................5 2 Protection Profile SFR assurance activities ...............................................................6 2.1 Security Audit (FAU)...........................................................................................................6 2.1.1 FAU_GEN.1(1) Audit data generation .............................................................................................. 6 2.1.2 FAU_GEN.1(2) Audit data generation (IPS) ...................................................................................... 7

2.1.3 FAU_GEN.2 User identity association............................................................................................... 8 2.1.4 FAU_STG_EXT.1 External audit trail storage .................................................................................... 8

2.2 Cryptographic support (FCS) ............................................................................................. 10 2.2.1 FCS_CKM.1(1) Cryptographic key generation (for asymmetric keys)................................................. 10 2.2.2 FCS_CKM.1(2) Cryptographic key generation (for asymmetric keys)................................................. 10

2.2.3 FCS_CKM_EXT.4 Cryptographic key zeroization .............................................................................. 11 2.2.4 FCS_COP.1(1) Cryptographic operation (for data encryption/decryption) .......................................... 12

2.2.5 FCS_COP.1(2) Cryptographic operation (for cryptographic signature)............................................... 12 2.2.6 FCS_COP.1(3) Cryptographic operation (for cryptographic signature)............................................... 13

2.2.7 FCS_COP.1(4) Cryptographic operation (for cryptographic hashing) ................................................. 13 2.2.8 FCS_COP.1(5) Cryptographic operation (for keyed-hash message authentication) ............................. 13

2.2.9 FCS_RBG_EXT.1 Extended cryptographic operation (random bit generation) .................................... 14 2.2.10 FCS_SSH_EXT.1 Explicit SSH ........................................................................................................ 14

2.2.11 FCS_IPSEC_EXT.1 Extended: Internet Protocol Security (IPSec) Communications ............................. 17

2.3 User Data Protection (FDP) ............................................................................................... 28 2.3.1 FDP_RIP.2 Full residual information protection............................................................................... 28

2.4 Identification and Authentication (FIA) .............................................................................. 28 2.4.1 FIA_AFL.1 Authentication failure handling...................................................................................... 28 2.4.2 FIA_PMG_EXT.1 Password management ....................................................................................... 29

2.4.3 FIA_UAU_EXT.2 Extended: Password-based authentication mechanism............................................ 30 2.4.4 FIA_UIA_EXT.1 User identification and authentication .................................................................... 30

2.4.5 FIA_UAU.7 Protected authentication feedback................................................................................ 31 2.4.6 FIA_X509_EXT.1 Extended: X.509 certificates ................................................................................ 32

2.4.7 FIA_PSK_EXT.1 Extended: Pre-shared key composition................................................................... 33

2.5 Security management (FMT)............................................................................................. 35 2.5.1 FMT_MOF.1 Management of security functions behaviour ............................................................... 35

2.5.2 FMT_MTD.1 Management of TSF data (for general TSF data).......................................................... 35 2.5.3 FMT_SMF.1(1) Specification of management functions ................................................................... 35

2.5.4 FMT_SMF.1(2) Specification of management functions ................................................................... 36

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2.5.5 FMT_SMR.2 Restrictions on security roles ...................................................................................... 36

2.6 Protection of the TSF (FPT)............................................................................................... 38 2.6.1 FPT_SKP_EXT.1 Extended: Protection of TSF data (for reading of all symmetric keys) ....................... 38 2.6.2 FPT_APW_EXT.1 Extended: Protection of administrator passwords .................................................. 38

2.6.3 FPT_FLS.1 Fail secure .................................................................................................................. 38 2.6.4 FPT_STM.1 Reliable time stamps .................................................................................................. 39

2.6.5 FPT_TUD_EXT.1 Extended: Trusted update ................................................................................... 40 2.6.6 FPT_TST_EXT.1 Extended: TSF testing.......................................................................................... 41

2.7 TOE access (FTA)............................................................................................................. 43 2.7.1 FTA_SSL_EXT.1 TSF-initiated session locking ................................................................................. 43

2.7.2 FTA_SSL.3(1) TSF-initiated termination ......................................................................................... 43 2.7.3 FTA_SSL.3(2) TSF-initiated termination ......................................................................................... 43

2.7.4 FTA_SSL.4 User-initiated termination ............................................................................................ 43 2.7.5 FTA_TAB.1 Default TOE access banners ........................................................................................ 44

2.8 Trusted path/channels (FTP)............................................................................................. 45 2.8.1 FTP_ITC.1(1) Inter-TSF trusted channel (prevention of disclosure) .................................................. 45

2.8.2 FTP_ITC.1(2) Inter-TSF trusted channel ........................................................................................ 45 2.8.3 FTP_TRP.1 Trusted path .............................................................................................................. 46

2.9 Stateful traffic/packet filtering (FFW and FPF) .................................................................... 48 2.9.1 FFW_RUL_EXT.1 Stateful firewall filtering ...................................................................................... 48 2.9.2 FPF_RUL_EXT.1 Packet filtering .................................................................................................... 60

2.10 Intrusion prevention system (IPS) ..................................................................................... 68 2.10.1 IPS_NTA_EXT.1 Network traffic analysis........................................................................................ 68

2.10.2 IPS_IPB_EXT.1 IP blocking........................................................................................................... 69 2.10.3 IPS_SBD_EXT.1 Signature-based IPS functionality.......................................................................... 70

2.10.4 IPS_ABD_EXT.1 Anomaly-based IPS functionality ........................................................................... 76

3 Protection Profile SAR assurance activities .............................................................79 3.1 Development (ADV).......................................................................................................... 79 3.1.1 Basic functional specification (ADV_FSP.1)..................................................................................... 79

3.2 Guidance documentation (AGD) ........................................................................................ 79 3.2.1 Operational user guidance (AGD_OPE.1) ....................................................................................... 79 3.2.2 Preparative procedures (AGD_PRE.1) ............................................................................................ 80

3.3 Lifecycle support (ALC)..................................................................................................... 81 3.3.1 Labelling of the TOE (ALC_CMC.1) ................................................................................................ 81

3.3.2 TOE CM coverage (ALC_CMS.1).................................................................................................... 81

3.4 Testing (ATE)................................................................................................................... 81 3.4.1 Independent testing – conformance (ATE_IND.1) .......................................................................... 81

3.5 Vulnerability assessment (AVA) ......................................................................................... 83 3.5.1 Vulnerability survey (AVA_VAN.1) ................................................................................................. 83

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

1 INTRODUCTION 1.1 Overview

This report documents the Common Criteria NDPP + FWEP + VPNEP + IPSEP evaluation of the Juniper Networks, Inc. Junos 12.3 X48-D30 for SRX Platforms (Junos 12.3 X48-D30) product.

1.2 Evaluation details

Developer Juniper Networks, Inc.

1133 Innovation Way, Sunnyvale, CA 94089, USA

Sponsor Juniper Networks, Inc.

Evaluator BAE Systems Lab - AISEF

Level 1, 14 Childers Street, Canberra ACT 2601, Australia

Scheme AISEP

Task ID EFS-T041

1.3 ST configuration control identifiers

ST Title Junos 12.3 X48-D30 for SRX Platforms

ST Version/Date Version 1.0, 11 November 2016

1.4 TOE Configuration

TOE Name Junos 12.3 X48-D30 for SRX Platforms (Junos 12.3 X48-D30)

TOE Version 12.3 X48-D30

1.5 References

1.5.1 Requirements

[1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 4

[2] Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, Version 3.1, Revision 4

[3] Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, version 3.1 Revision 4

[4] Common Methodology for Information Technology Security Evaluation, Evaluation methodology, Version 3.1, Revision 4

[5] Security Requirements for Network Devices (NDPP), Version 1.1, 08 June 2012 [6] Security Requirements for Network Devices (NDPP) Errata #3, 3 November 2014 [7] Network Device Protection Profile (NDPP) Extended Package Stateful Traffic Filter

Firewall (FWEP), Version 1.0, 19 December 2011 [8] Network Device Protection Profile (NDPP) Extended Package VPN Gateway

(VPNEP), Version 1.1, 12 April 2013 [9] Network Device Protection Profile (NDPP) Extended Package for Intrusion

Prevention Systems (IPSEP), Version 1.0, 26 June 2014

1.5.2 Evaluation Evidence

[10] Security Target - Junos 12.3X48-D30 for SRX Platforms, Version 1.0, 11-Nov-16

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

[11] Junos® OS Common Criteria and Junos Evaluated Configuration Guide for SRX Series Security Devices, Release 12.3X48-D30, 28-Jul-16

[12] Junos® OS CLI User Guide, Release 12.3, 13-Jun-16 [13] Junos® OS Installation and Upgrade Guide, Release 12.3, 17-Jun-16 [14] Junos® OS System Basics: Getting Started Configuration Guide, Release 12.3, 10-

Jun-16 [15] Junos® OS Intrusion Detection and Prevention Feature Guide for Security Devices,

Release 12.3X48-D10, 12-Jan-16 [16] Junos® 12.3 X48 for SRX Series Platforms – SRX Guidance Annex, Version 1.0, 17-

Jan-17 [17] Junos® OS VPN Feature Guide for Security Devices, Release 12.3X48-D10, 08-07-

2016 [18] Junos® 12.3 X48 for SRX Series Platforms – SRX Running Processes, Version 1.0,

17-Jan-17 [19] Junos® 12.3 X48 for SRX Series Platforms – SRX IPS Guidance Supplement,

Version 1.0, 17-Jan-17 [20] Seeding of the Kernel in SRX Series Appliances running Junos 12.3 X48 D30,

Version 0.2, 15-Sep-16 [21] Test Report – Junos 12.3 X48-D30 for SRX Series Platforms (NDPP), EFS-T041-TR-

NDPP, Version 1.0, 11 November 2016 [22] Test Report – Junos 12.3 X48-D30 for SRX Series Platforms (FWEP), EFS-T041-TR-

FWEP, Version 1.0, 11 November 2016 [23] Test Report – Junos 12.3 X48-D30 for SRX Series Platforms (VPNEP), EFS-T041-TR-

VPNEP, Version 1.0, 11 November 2016 [24] Test Report – Junos 12.3 X48-D30 for SRX Series Platforms (IPSEP), EFS-T041-TR-

IPSEP, Version 1.0, 11 November 2016

1.6 Copyright statement This document contains information protected by copyright. © BAE Systems Applied Intelligence Pty Ltd (ABN 14 111 187 270). The material in this document may not be commercialised without prior written permission from BAE Systems Applied Intelligence.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2 PROTECTION PROFILE SFR ASSURANCE ACTIVITIES This section of the AAR defines each of the SFRs specified in the ST (Ref. [10]), their corresponding assurance activities and the evaluator’s findings in each case.

2.1 Security Audit (FAU)

2.1.1 FAU_GEN.1(1) Audit data generation

TSS None specified.

N/A

Guidance

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

The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN1.2, and the additional information specified in Table 1.

The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP.

The evaluator shall examine the administrative guide and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the PP.

The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements.

The Common Criteria Evaluated Configuration Guide (Ref. [11]) and other associated guidance documents together provide examples of the auditable events and their corresponding audit records. Audit records are provided by the TOE in the following format (also see Chapter 11 of the CCECG): <date> <time> <system name> <process>: <event> All configuration/commands presented in the Evaluated Configuration Guide are considered relevant to the secure configuration of the TOE and the mechanisms necessary to enforce the requirements of the PP and associated EP. For all other guidance documentation, the evaluators determined that, while the guidance covers the whole breadth of functionality provided by the TOE (a substantial amount of which is not included in the scope of this evaluation), the chapter and section headings used allow for easy identification of which information and configuration data is pertinent to the functionality provided by the PP/EPs.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

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

The evaluator 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.

For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable.

When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields in each audit record have the proper entries.

Throughout the testing performed, the evaluators examined the TOE to determine whether audit log entries for all auditable events were generated. The evaluators confirmed that all auditable events are generated. The evaluators confirmed that audit entries were generated for the firewall rules for permit, deny and log. The evaluators confirmed that, in the scenario when the TOE is subjected to more traffic than the interfaces are able to handle, that the TOE automatically drops all received packets until the overwhelming traffic ceases and audits these events appropriately.

2.1.2 FAU_GEN.1(2) Audit data generation (IPS)

TSS

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.

The TOE generates event logs when a firewall or IPS – also referred to as Intrusion Detection and Prevention (IDP) in the Junos OS literature – rules are triggered. Event logging can be configured on a rule-by-rule basis when defining individual firewall and IPS policies. Because of the nature of IDP event logs, log generation often happens in bursts and can generate a much larger volume of messages during an attack. To manage the volume of log messages, Junos supports log suppression, which suppresses multiple instances of the same log occurring from the same or similar sessions over the same period of time. IDP log suppression is enabled by default and can be customized based on configurable attributes:

Source/destination addresses; Number of log occurrences after which log suppression begins; Maximum number of logs that log suppression can operate on; Time after which suppressed logs are reported.

Suppressed logs are reported as single log entry containing the count of occurrences.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

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

Chapter 12 (Configuring Network Attacks) of the Evaluated Configuration Guide (Ref. [11]) and Chapter 12 (Monitoring Device Events by Configuring IDP Logging) of the IDP Feature Guide (Ref. [15]) provide guidance to administrators regarding the composition of IDP policies and the configuration of logging.

Testing

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.

The evaluators performed a variety of tests that exercised all required IPS events. The evaluators confirmed that the behaviour of the TOE and the data generated by the TOE were consistent with expectations.

2.1.3 FAU_GEN.2 User identity association

TSS None specified.

N/A

Guidance None specified.

N/A

Testing None specified.

N/A

2.1.4 FAU_STG_EXT.1 External audit trail storage

TSS

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.

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 TOE defines an active log file and a number of “archive” files (10 by default, but configurable from 1 to 1000). When the active log file reaches its maximum size, the logging utility closes the file, compresses it, and names the compressed archive file ‘logfile.0.gz’. The logging utility then opens and writes to a new active log file. When the new active log file reaches the configured maximum size, ‘logfile.0.gz’ is renamed ‘logfile.1.gz’, and the active log file is closed, compressed, and renamed ‘logfile.0.gz’. When the maximum number of archive files is reached and when the size of the active file reaches the configured maximum size, the contents of the oldest archived file are deleted so the current active file can be archived. The maximum value that can be specified for the size of a log file is 1GB. These defaults maximum sizes can be modified by the user.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Syslog can be configured to store the audit logs locally, or to send them to one or more syslog log servers (via IPSec ). When the TOE is configured to direct syslog traffic to an external syslog server via a IPSec, a VPN tunnel is initiated from the TOE immediately upon configuration commit and communications from TOE to the syslog server is encrypted and integrity protected. Audit records are sent to the syslog server periodically as configured by the Administrator

Guidance

The evaluator shall examine the operational guidance to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server (for TOEs that are not acting as an audit log server).

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

Chapter 8 of the Evaluated Configuration Guide (Ref. [11]) indicates that: “When the device running Junos OS is set up for an external syslog server, the TOE forwards copies of local logs to the external syslog server and retains local copies of all logs when the TOE is configured in event log mode. In stream log mode, all logs except traffic logs are stored locally and can be forwarded to an external syslog server, whereas traffic logs can only be forwarded to an external syslog server”.

Testing

The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided.

The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server.

The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server.

The evaluator shall record the particular software (name, version) used on the audit server during testing

The evaluators configured and established an IPsec tunnel between itself and a remote audit server. The evaluators then performed a number of events to generate audit traffic. The evaluators confirmed that this traffic was not sent in the clear. The evaluators examined the syslog on the audit server and confirmed that the audit entries were received from the TOE. The audit server was configured using Strongswan version U5.4.0 and the default rsyslogd installation provided with Kali Linux 2016.1.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2.2 Cryptographic support (FCS)

2.2.1 FCS_CKM.1(1) Cryptographic key generation (for asymmetric keys)

TSS

In order to show that the TSF complies with 800-56A and/or 800-56B, depending on the selections made, the evaluator shall ensure that the TSS contains the following information:

The TSS shall list all sections of the appropriate 800-56 standard(s) to which the TOE complies.

For each applicable section listed in the TSS, for all statements that are not "shall" (that is, "shall not", "should", and "should not"), if the TOE implements such options it shall be described in the TSS. If the included functionality is indicated as "shall not" or "should not" in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE; and

For each applicable section of 800-56A and 800-56B (as selected), any omission of functionality related to "shall" or “should” statements shall be described.

Any TOE-specific extensions, processing that is not included in the documents, or alternative implementations allowed by the documents that may impact the security requirements the TOE is to enforce shall be described

The TOE complies with section 6 of NIST SP 800-56B regarding RSA key pair generation. The TOE implements all of the "shall" and "should" requirements and none of the "shall not" or "should not" from FIPS PUB 186-3 Appendix B3 and B4.


N/A

Testing

The evaluator shall use the key pair generation portions of "The FIPS 186-3 Digital Signature Algorithm Validation System (DSA2VS)", "The FIPS 186-3 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS)", and "The RSA Validation System (RSA2VS)" as a guide in testing the requirement above, depending on the selection performed by the ST author.

This will require that the evaluator have a trusted reference implementation of the algorithms that can produce test vectors that are verifiable during the test.

The key generation implementations used by the TOE have been given the following CAVP certificate numbers: #909, #912, #913, #914, #915, #916, #917, #1099, #1100, #1101, #1102, #1103, #1104 and #2087.

2.2.2 FCS_CKM.1(2) Cryptographic key generation (for asymmetric keys)

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

In order to show that the TSF complies with 800-56A and/or 800-56B, depending on the selections made, the evaluator shall ensure that the TSS contains the following information:

The TSS shall list all sections of the appropriate 800-56 standard(s) to which the TOE complies.

For each applicable section listed in the TSS, for all statements that are not "shall" (that is, "shall not", "should", and "should not"), if the TOE implements such options it shall be described in the TSS. If the included functionality is indicated as "shall not" or "should not" in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE; and

For each applicable section of 800-56A and 800-56B (as selected), any omission of functionality related to "shall" or “should” statements shall be described.

Any TOE-specific extensions, processing that is not included in the documents, or alternative implementations allowed by the documents that may impact the security requirements the TOE is to enforce shall be described

The TOE complies with section 6 of NIST SP 800-56B regarding RSA key pair generation. The TOE implements all of the "shall" and "should" requirements and none of the "shall not" or "should not" from FIPS PUB 186-3 Appendix B3 and B4.


N/A

Testing

The evaluator shall use the key pair generation portions of "The FIPS 186-3 Digital Signature Algorithm Validation System (DSA2VS)", "The FIPS 186-3 Elliptic Curve Digital Signature Algorithm Validation System (ECDSA2VS)", and "The RSA Validation System (RSA2VS)" as a guide in testing the requirement above, depending on the selection performed by the ST author.

This will require that the evaluator have a trusted reference implementation of the algorithms that can produce test vectors that are verifiable during the test.

The key generation implementations used by the TOE have been given the following CAVP certificate numbers: #909, #912, #913, #914, #915, #916, #917, #1099, #1100, #1101, #1102, #1103, #1104 and #2087.

2.2.3 FCS_CKM_EXT.4 Cryptographic key zeroization

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator shall check to ensure the TSS describes each of the secret keys (keys used for symmetric encryption), private keys, and CSPs used to generate key; when they are zeroized (for example, immediately after use, on system shutdown, etc.); and the type of zeroization procedure that is performed (overwrite with zeros, overwrite three times with random pattern, etc.).

If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the zeroization procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are zeroized by overwriting once with zeros, while secret keys stored on the internal hard drive are zeroized by overwriting three times with a random pattern that is changed before each write").

Table 7-2, provided in Section 7.2 of the Security Target (Ref. [10]), lists each of the keys/CSPs used by the TOE. Each key is listed by name/purpose and is accompanied by a description, how and where within the TOE the key is stored and a description of the method used to destroy the key.



2.2.4 FCS_COP.1(1) Cryptographic operation (for data encryption/decryption)

TSS None specified.

N/A


N/A

Testing

The evaluator shall use tests appropriate to the modes selected in the above requirement from "The Advanced Encryption Standard Algorithm Validation Suite (AESAVS)", "The XTS-AES Validation System (XTSVS)", The CMAC Validation System (CMACVS)", "The Counter with Cipher Block Chaining-Message Authentication Code (CCM) Validation System (CCMVS)", and "The Galois/Counter Mode (GCM) and GMAC Validation System (GCMVS)" (these documents are available from http://csrc.nist.gov/groups/STM/cavp/index.html) as a guide in testing the requirement above.

This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test.

The AES implementation used by the TOE has been given the CAVP certificate numbers: #4056, #4066, #4067, #4068, #4069 and #4070.

2.2.5 FCS_COP.1(2) Cryptographic operation (for cryptographic signature)

TSS None specified.

N/A


N/A

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

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

The RSA implementation used by the TOE has been given the CAVP certificate numbers: #2197, #2198, #2199, #2200, #2201 and #2202.

2.2.6 FCS_COP.1(3) Cryptographic operation (for cryptographic signature)

TSS None specified.

N/A


N/A

Testing

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

The ECDSA implementation used by the TOE has been given the CAVP certificate numbers: #909, #912, #913, #914, #915, #916 and #917.

2.2.7 FCS_COP.1(4) Cryptographic operation (for cryptographic hashing)

TSS None specified.

N/A


N/A

Testing

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

The SHA implementation used by the TOE has been given the CAVP certificate numbers: #3342, #3343, #3349, #3350, #3351, #3352 and #3353.

2.2.8 FCS_COP.1(5) Cryptographic operation (for keyed-hash message authentication)

TSS None specified.

N/A

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE


N/A

Testing

The evaluator shall use "The Keyed-Hash Message Authentication Code (HMAC) Validation System (HMACVS)" as a guide in testing the requirement above. This will require that the evaluator have a reference implementation of the algorithms known to be good that can produce test vectors that are verifiable during the test.

The HMAC implementation used by the TOE has been given the CAVP certificate numbers: #2647, #2648, #2653, #2654, #2655, #2656 and #2657.

2.2.9 FCS_RBG_EXT.1 Extended cryptographic operation (random bit generation)

TSS None specified.

N/A

Guidance The evaluator shall confirm that the operational guidance contains appropriate instructions for configuring the RBG functionality.

The RBG utilised by the TOE is non-configurable by users of the TOE. As such, no guidance is provided to meet this requirement.

Testing The evaluator shall perform 15 trials for the RBG implementation. If the RBG is configurable, the evaluator shall perform 15 trials for each configuration.

The DRBG implementation used by the TOE has been given the CAVP certificate number #1216.

2.2.10 FCS_SSH_EXT.1 Explicit SSH

2.2.10.1 FCS_SSH_EXT.1.1

TSS None specified.

N/A


N/A


N/A

2.2.10.2 FCS_SSH_EXT.1.2

TSS

The evaluator shall check to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication, that this list conforms to FCS_SSH_EXT.1.5, and ensure that password-based authentication methods are also allowed.

The TOE uses SSH_RSA and SSH-ECDSA as its public key algorithms for authentication, as well as password-based authentication.


N/A

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

The evaluator shall, for each public key algorithm supported, show that the TOE supports the use of that public key algorithm to authenticate a user connection. Any configuration activities required to support this test shall be performed according to instructions in the operational guidance.

Using the operational guidance, the evaluator shall configure the TOE to accept password-based authentication, and demonstrate that a user can be successfully authenticated to the TOE over SSH using a password as an authenticator.

The evaluators configured the TOE to use RSA, ECDSA and password-based authentication for SSH connections. The evaluators were able to successfully authenticate with the TOE using both methods.

2.2.10.3 FCS_SSH_EXT.1.3

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

Packets greater than 32768 bytes in an SSH transport connection are dropped and the connection is terminated by the TOE. The SSH daemon maintains a 32768 byte buffer for incoming packet processing, adding to the buffer in 1K increments. If the accumulated data for a packet exceeds the buffer size, the packet is dropped, the accumulator buffer is reset to zero and a log message indicating that the packet was dropped is created.


N/A

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

The evaluators used scapy to generate a packet larger than the size specified in the requirement. The evaluators sent the packet to the TOE as part of an SSH session. The evaluators confirmed that the TOE dropped the packet.

2.2.10.4 FCS_SSH_EXT.1.4

TSS

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

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

The TOE supports AES-CBC-128 and AES-CBC-256 encryption algorithms for SSH transport.

Guidance

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

Chapter 3 of the Evaluated Configuration Guide specifies how an administrator may configure the warning/consent banner presented at login and how to configure the SSH daemon to run in an NDPP-compliant setup (such as supported algorithms and key exchange methods).

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

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

The evaluators successfully connected to the TOE using both AES-128-CBC and AES-256-CBC as the encryption algorithms for SSH.

2.2.10.5 FCS_SSH_EXT.1.5

TSS None specified.

N/A


N/A


N/A

2.2.10.6 FCS_SSH_EXT.1.6

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

The data integrity algorithms used in SSH transport connection are HMAC-SHA1, HMAC-SHA1-96, as required by RFC4253, and HMAC-SHA2-256, AND HMAC-SHA2-512 as recommended by RFC6668

Guidance

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

Chapter 3 of the Evaluated Configuration Guide (Ref. [11]) specifies how an administrator may configure the warning/consent banner presented at login and how to configure the SSH daemon to run in an NDPP-compliant setup (such as supported algorithms and key exchange methods).

Testing

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

The evaluators successfully connected to the TOE using HMAC-SHA1-96 as the integrity algorithm for SSH.

2.2.10.7 FCS_SSH_EXT.1.7

TSS If this capability is “hard-coded” into the TOE, the evaluator shall check the TSS to ensure that this is stated in the discussion of the SSH protocol.

Key exchange is done using diffie-hellman-group14-sha1 as per RFC4253 and ecdh-sha2-nistp256, ecdh-sha2-nistp384 as per RFC5656.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

The evaluator shall ensure that operational guidance contains configuration information that will allow the security administrator to configure the TOE so that all key exchanges for SSH are performed using DH group 14 and any groups specified from the selection in the ST.

Chapter 3 of the Evaluated Configuration Guide (Ref. [11]) specifies how an administrator may configure the warning/consent banner presented at login and how to configure the SSH daemon to run in an NDPP-compliant setup (such as supported algorithms and key exchange methods).

Testing

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

The evaluators attempted to connect to the TOE using DH Group 1 for the key exchange method. The TOE denied this connection attempt. The evaluators attempted to connect to the TOE using DH Group 14 for the key exchange method. The TOE permitted this connection attempt.

2.2.11 FCS_IPSEC_EXT.1 Extended: Internet Protocol Security (IPSec) Communications

2.2.11.1 FCS_IPSEC_EXT.1.1

TSS Nothing is done in addition to determining that the TOE’s implementation is conformant to RFC 4301 as described above.

The TOE is conformant to RFC 4301.

Guidance The evaluator shall examine the operational guidance to verify it instructs the Administrator how to construct entries into the SPD that specify a rule for DISCARD, BYPASS and PROTECT.

Chapter 6 (Configuring Security Flow Policies) of the Evaluated Configuration Guide (Ref. [11]) provides administrators with guidance and CLI examples for configuring security flow policies that contain each of the reactions listed above.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

The evaluator uses the operational guidance to configure the TOE to carry out the following tests:

The evaluator shall configure the TOE’s SPD such that there is a rule for DISCARD, BYPASS, PROTECT. The selectors used in the construction of the rule shall be different such that the evaluator can send in three network packets with the appropriate fields in the packet header that each packet will match one of the three rules. The evaluator observes via the audit trail, and packet captures that the TOE exhibited the expected behavior: appropriate packet was dropped, allowed through without modification, was encrypted by the IPsec implementation.

The evaluator shall devise two equal SPD entries with alternate operations – BYPASS and PROTECT. The entries should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first entry is enforced in both cases by generating applicable packets and using packet capture and logs for confirmation.

The evaluator shall repeat the procedure above, except that the two entries should be devised where one is a subset of the other (e.g., a specific address vs. a network segment). Again, the evaluator should test both orders to ensure that the first is enforced regardless of the specificity of the rule.

The evaluators configured a number of security policies to test the DISCARD, BYPASS and PROTECT functionality of the TOE. The evaluators confirmed that the TOE reacted as expected and that appropriate audit log entries were generated. As the TOE does not permit the creation of distinct BYPASS/PROTECT rules, BYPASS/REJECT was used in place to demonstrate the ordering of rules. The evaluators confirmed that the TOE enforces security policies in the order defined by the administrator. The evaluators repeated the previous test using a subset-based configuration. The evaluators confirmed that the TOE enforced the rules in the order defined by the administrator.


TSS The evaluator checks the TSS to ensure it states that the TOE can operate in tunnel mode and/or transport mode (as selected).

The TOE supports tunnel mode only.

Guidance The evaluator shall confirm that the operational guidance instructs the Administrator how the TOE is configured in each mode selected.

Per the ST, the TOE supports main mode only for IPsec connections. Chapter 7 of the Evaluated Configuration Guide (Ref. [11], Configuring VPNs) provides numerous configuration examples and guidance to administrators on how to include main mode as part of an IPsec VPN configuration.

Testing

If tunnel mode is selected, the evaluator uses the operational guidance to configure the TOE in tunnel mode, and a TOE peer in tunnel mode. The evaluator configures the two peer TOEs to use any of the allowable cryptographic algorithms, authentication methods, etc. to ensure an allowable SA can be negotiated.

The evaluator shall then initiate a session between the peers. The evaluator observes in the audit trail and the captured packets that a successful connection was established using the tunnel mode.

The evaluators configured the TOE to establish an IPsec connection between itself and a peer using tunnel mode. The evaluator confirmed that the IPsec tunnel was established as configured and that the associated audit logs were generated.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE


TSS

The evaluator shall examine the TSS to verify that the TSS provides a description of how a packet is processed against the SPD and that if no “rules” are found to match, that a final rule exists, either implicitly or explicitly, that causes the network packet to be discarded.

By default, the TOE denies all traffic through an SRX Series device. In fact, an implicit default security policy exists that denies all packets. You can change this behavior by configuring a standard security policy that permits certain types of traffic. The implicit default policy can be changed to permit all traffic with the 'set security policies default-policy' command; however, this is not recommended.

Guidance The evaluator checks that the operational guidance provides instructions on how to construct the SPD and uses the guidance to configure the TOE for the following tests.

Chapter 7 of the Evaluated Configuration Guide (Ref. [11], Configuring VPNs) provides numerous configuration examples and guidance.

Testing

The evaluator shall configure the TOE’s SPD, such that it has entries that contain operations that DISCARD, BYPASS, and PROTECT network packets.

The evaluator also configures the TOE so that all auditable events with respect to FCS_IPSEC_EXT.1 are enabled.

The evaluator may use the SPD that was created for verification of FCS_IPSEC_EXT.1.1.

The evaluator shall construct a network packet that matches a BYPASS entry, and send that packet to the TOE.

The evaluator should observe that the network packet is passed by the TOE to the proper destined interface with no modification.

The evaluator shall then modify a field in the packet header; such that it no longer matches the evaluator created entries (there may be a “TOE created” final entry that discards packets that do not match any previous entries).

The evaluator sends the packet to the TOE, and observes that the packet was not permitted to flow to any of the TOE’s interfaces.

The evaluator shall verify that an audit record is generated that specifies that the packet was discarded as expected.

The evaluators configured a number of traffic policies that met the requirements of this test. The evaluators sent traffic through the TOE that matched the BYPASS rule and confirmed that the TOE allowed the traffic to pass with no modification. The evaluators then constructed a “junk” packet that did not match any of the policies in place. The evaluators confirmed that the “default-last-deny-and-log” policy was enforced and the TOE automatically dropped and logged the traffic flow.


TSS

The evaluator shall examine the TSS to verify that the algorithms AES-GCM-128 and AES-GCM-256 are implemented.

If the ST author has selected either AES-CBC-128 or AES-CBC-256 in the requirement, then the evaluator verifies the TSS describes these as well.

In addition, the evaluator ensures that the SHA-based HMAC algorithm conforms to the algorithms specified in FCS_COP.1(4) Cryptographic Operations (for keyed-hash message authentication).

The TOE supports AES-GCM-128 and AES-GCM-256, and AES-CBC-128 or AES-CBC-256 using HMAC SHA-1 and SHA-256.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Keyed-hash algorithms including HMAC-SHA1-96, HMAC-SHA-256-128 can be configured for AES-CBC.

Guidance

The evaluator checks the operational guidance to ensure it provides instructions on how to configure the TOE to use the AES-GCM-128, and AES-GCM-256 algorithms, and if either AES-CBC-128 or AES-CBC-256 have been selected the guidance instructs how to use these as well.

Chapter 7 (Configuring VPNs) of the Evaluated Configuration Guide (Ref. [11]) provides a number of examples for both IPsec and IKE policy configuration. While the examples provided uses aes-128-cbc as the encryption algorithm, the guidance indicates the values use if AES-256-CBC, AES-GCM-128 or AES-GCM-256 is to be used.

Testing

The evaluator shall configure the TOE as indicated in the operational guidance configuring the TOE to using each of the AES-GCM-128, and AES-GCM-256 algorithms, and attempt to establish a connection using ESP in confidentiality and integrity mode.

If the ST Author has selected either AES-CBC-128 or AES-CBC-256, the TOE is configured to use those algorithms and the evaluator attempts to establish a connection using ESP in confidentiality and integrity mode for those algorithms selected.

The evaluators configured the TOE to use each of the supported encryption algorithms. The evaluators confirmed that, in each instance, a connection was established using ESP.


TSS The evaluator shall examine the TSS to verify that IKEv1 and/or IKEv2 are implemented.

IKEv1 and IKEv2 are implemented. IKEv1 as defined in RFCs 2407, 2408, 2409, RFC 4109 and RFC 4868 for hash functions; IKEv2 as defined in RFCs 5996 (with mandatory support for NAT traversal as specified in section 2.23) and RFC 4868 for hash functions.

Guidance

The evaluator checks the operational guidance to ensure it instructs the administrator how to configure the TOE to use IKEv1 and/or IKEv2 (as selected), and uses the guidance to configure the TOE to perform NAT traversal for the following test.

Chapter 7 (Configuring VPNs) of the Evaluated Configuration Guide (Ref. [11]) provides a number of examples for both IPsec and IKE policy configuration. These examples use IKEv1, but additional commands are also provided for administrators to configure the TOE to use IKEv2 instead.

Testing

The evaluator shall configure the TOE so that it will perform NAT traversal processing as described in the TSS and RFC 5996, section 2.23. The evaluator shall initiate an IPsec connection and determine that the NAT is successfully traversed.

The evaluators configured a network environment such that NAT traversal was required for the establishment of an IPsec connection. The evaluators confirmed that the connection was established and NAT successfully traversed.


FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator shall ensure the TSS identifies the algorithms used for encrypting the IKEv1 and/or IKEv2 payload, and that the algorithms AES-CBC-128, AES-CBC-256 are specified, and if others are chosen in the selection of the requirement, those are included in the TSS discussion.

The TOE supports AES-CBC-128, AES-CBC-256, AES-GCM-128 and AES-GCM-256 for payload protection in IKEv1 and IKEv2.

Guidance

The evaluator ensures that the operational guidance describes how the TOE can be configured to use the mandated algorithms, as well as any additional algorithms selected in the requirement. The guidance is then used to configure the TOE to perform the following test.

Chapter 7 (Configuring VPNs) of the Evaluated Configuration Guide (Ref. [11]) provides a number of examples for both IPsec and IKE policy configuration. While the examples provided uses aes-128-cbc as the encryption algorithm, the guidance indicates the values use if AES-256-CBC, AES-GCM-128 or AES-GCM-256 is to be used.

Testing

The evaluator shall configure the TOE to use AES-CBC-128 to encrypt the IKEv1 and/or IKEv2 payload and establish a connection with a peer device, which is configured to only accept the payload encrypted using AES-CBC-128. The evaluator will consult the audit trail to confirm the algorithm was that used in the negotiation.

The evaluators configured both the TOE and peer device to use AES-CBC-128 algorithm only for payload encryption. The evaluators confirmed, via TOE and peer output, that the connection was established and AES-128-CBC was the only algorithm used for payload encryption.


TSS

The evaluator shall examine the TSS to ensure that, in the description of the IPsec protocol supported by the TOE, it states that aggressive mode is not used for IKEv1 Phase 1 exchanges, and that only main mode is used. It may be that this is a configurable option.

In the evaluated configuration, the TOE permits only main mode to be configured for IKEv1 Phase 1 exchanges. There is no option to configure aggressive mode.

Guidance If the mode requires configuration of the TOE prior to its operation, the evaluator shall check the operational guidance to ensure that instructions for this configuration are contained within that guidance.

Chapter 7 (Configuring VPNs) of the Evaluated Configuration Guide (Ref. [11]) provides a number of examples for both IPsec and IKE policy configuration. All IKEv1 examples provided utilise main mode only.

Testing

The evaluator shall configure the TOE as indicated in the operational guidance, and attempt to establish a connection using an IKEv1 Phase 1 connection in aggressive mode. This attempt should fail.

The evaluator should then show that main mode exchanges are supported. This test is not applicable if IKEv1 is not selected above in the FCS_IPSEC_EXT.1.5 protocol selection.

The evaluators configured the IPsec peer to attempt to establish an IKEv1 Phase 1 connection using aggressive mode. The TOE rejected this connection attempt. The evaluators established an IKEv1 connection between the TOE and a peer device. TOE and peer output confirmed that the connection was established using main mode.


FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS How the lifetimes are established and enforced is described in the RFCs and the evaluator examines the TSS as stated at the beginning of this section.

The following CLI commands configure a lifetime of either kilobytes or seconds: set security ipsec proposal <name> lifetime-kilobytes <kb>

set security ipsec proposal <name> lifetime-seconds <seconds>

Guidance

The evaluator verifies that the values for SA lifetimes can be configured and that the instructions for doing so are located in the operational guidance.

The evaluator ensures that the Administrator is able to configurable Phase 1 SAs values for 24 hours and 8 hours for Phase 2 SAs.

Currently there are no values mandated for the number of packers, the evaluator just ensures that this can be configured. The TOE may limit the lifetime on the number of bytes that have been transmitted and this would be acceptable.

The following commands can be used to configure Phase 1 lifetimes in seconds or kilobytes: set security ike proposal <name> lifetime‐seconds <value> (180 to

86,400) set security ike proposal <name> lifetime‐kilobytes <value> (64 to

1,048,576) The following commands can be used to configure Phase 2 lifetimes in seconds or kilobytes:

set security ike proposal <name> lifetime‐seconds <value> (180 to 86,400)

set security ike proposal <name> lifetime‐kilobytes <value> (64 to 1,048,576)

Testing

The evaluator shall configure a maximum lifetime in terms of the # of packets (or bytes) allowed following the operational guidance.

The evaluator shall establish an SA and determine that once the allowed # of packets (or bytes) through this SA is exceeded, the connection is closed.

The evaluator shall construct a test where a Phase 1 SA is established and attempted to be maintained for more than 24 hours before it is renegotiated.

The evaluator shall observe that this SA is closed or renegotiated in 24 hours or less. If such an action requires that the TOE be configured in a specific way, the evaluator shall implement tests demonstrating that the configuration capability of the TOE works as documented in the operational guidance.

The evaluator shall perform a test similar to Test 1 for Phase 2 SAs, except that the lifetime will be 8 hours instead of 24.

The evaluators configured maximum lifetimes in terms of bytes. The evaluators sent traffic through the IPsec tunnel and confirmed that, once the defined limit of bytes was met, the TOE closed and re-established the connection. The evaluators configured the TOE to enforce a Phase 1 SA lifetime of 24 hours. The evaluators confirmed that, after 24 hours, the connection was re-negotiated. The evaluators configured the TOE to enforce a Phase 2 SA lifetime of 8 hours. The evaluators confirmed that, after 8 hours, the connection was re-negotiated.


FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator shall check to ensure that, for each DH group supported by the TSF, the TSS describes the process for generating "x" (as defined in FCS_IPSEC_EXT.1.9) and each nonce.

The evaluator shall verify that the TSS indicates that the random number generated that meets the requirements in this PP is used, and that the length of "x" and the nonces meet the stipulations in the requirement.

The TOE uses HMAC DRBG with SHA-256 for the generation of DH exponents and nonces in the IKE key exchange protocol of length 224 bits (for DH Group 14), 256 bits (for DH Groups 19 and 24) and 384 bits (for DH Group 20).


N/A


N/A

2.2.11.10 FCS_IPSEC_EXT.1.10

TSS None specified.

N/A


N/A


N/A

2.2.11.11 FCS_IPSEC_EXT.1.11

TSS

The evaluator shall check to ensure that the DH groups specified in the requirement are listed as being supported in the TSS.

If there is more than one DH group supported, the evaluator checks to ensure the TSS describes how a particular DH group is specified/negotiated with a peer.

The TOE supports Diffie-Hellman Groups 14, 19, 20, and 24. In the IKEv1 phase 1 and phase 2 exchanges, the TOE and peer will agree on the best DH group both can support. When the TOE receives an IKE proposal, it will select the first DH group that matches the acceptable DH groups configured in the TOE (one or more of DH Groups 14, 19, 20 or 24) and the negotiation will fail if there is no match. Similarly, when the peer initiates the IKE protocol, the TOE will select the first match from the IKE proposal sent by the peer and the negotiation fails is no acceptable match is found.


N/A

Testing For each supported DH group, the evaluator shall test to ensure that all IKE protocols can be successfully completed using that particular DH group.

The evaluators configured the TOE and an IPsec peer to use each supported Diffie-Hellman group. The evaluators confirmed that groups 14, 19, 20 and 24 were supported and that the connection was successfully established.

2.2.11.12 FCS_IPSEC_EXT.1.12

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator ensures that the TSS identifies RSA and/or ECDSA as being used to perform peer authentication. The description must be consistent with the algorithms as specified in FCS_COP.1(2) Cryptographic Operations (for cryptographic signature).

The TOE supports both RSA and ECDSA for use with X.509v3 certificates that conform to RFC 4945 and pre-shared Keys for IPsec support.

Guidance The evaluator ensures the operational guidance describes how to set up the TOE to use the cryptographic algorithms RSA and/or ECDSA.

Chapter 7 (Configuring VPNs) of the Evaluated Configuration Guide (Ref. [11]) contains distinct sections for the configuration of the IPsec VPN using either RSA or ECDSA. The instructions provided include the configuration of IKE proposals, IKE policy, IPsec proposal, IPsec policy, IKE and VPN. Command Line Interface (CLI) commands to be entered by the device administrator when selecting the algorithm to be used and configuring the VPN component of the TOE accordingly.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

The evaluator shall have the TOE generate a public-private key pair, and submit a CSR (Certificate Signing Request) to a CA (trusted by both the TOE and the peer VPN used to establish a connection) for its signature. The values for the DN (Common Name, Organization, Organizational Unit, and Country) will also be passed in the request.

The evaluator shall use a certificate signed using the RSA or ECDSA algorithm to authenticate the remote peer during the IKE exchange. This test ensures the remote peer has the certificate for the trusted CA that signed the TOE’s certificate and it will do a bit-wise comparison on the DN. This bit-wise comparison of the DN ensures that not only does the peer have a certificate signed by the trusted CA, but the certificate is from the DN that is expected.

The evaluator will configure the TOE to associate a certificate (e.g., a certificate map in some implementations) with a VPN connection. This is what the DN is checked against.

The evaluator shall test that the TOE can properly handle revoked certificates – conditional on whether CRL or OCSP is selected; if both are selected, and then a test is performed for each method. For this draft of the EP, the evaluator has to only test one up in the trust chain (future drafts may require to ensure the validation is done up the entire chain). The evaluator shall ensure that a valid certificate is used, and that the SA is established.

The evaluator then attempts the test with a certificate that will be revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the TOE will not establish an SA.

The evaluator shall construct a certificate path, such that the certificate of the CA issuing the TOE’s certificate does not contain the basicConstraints extension. The validation of the certificate path fails.

The evaluator shall construct a certificate path, such that the certificate of the CA issuing the TOE’s certificate has the cA flag in the basicConstraints extension not set. The validation of the certificate path fails.

The evaluator shall construct a certificate path, such that the certificate of the CA issuing the TOE’s certificate has the cA flag in the basicConstraints extension set to TRUE. The validation of the certificate path succeeds.

The evaluator shall test that given a signed certificate from a trusted CA, that when the DN does not match – any of the four fields can be modified such that they do not match the expected value, that an SA does not get established.

The evaluator shall ensure that the TOE is configurable to either establish an SA, or not establish an SA if a connection to the certificate validation entity cannot be reached. For each method selected for certificate validation, the evaluator attempts to validate the certificate – for the purposes of this test, it does not matter if the certificate is revoked or not. For the “mode” where an SA is allowed to be established, the connection is made. Where the SA is not to be established, the connection is refused.

The evaluators created a certificate request and submitted it to a CA. The evaluators confirmed that the information specified in the requirement was included in the request. The evaluators confirmed that IPsec connections could be established using both RSA and ECDSA-signed certificates for peer authentication. The evaluators confirmed that both Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP) can be used by the TOE for validation of certificates. The TOE does not establish a connection when a certificate is determined to be invalid/revoked.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

The evaluators constructed a certificate path where the CA did not have the basicConstraints extension. The TOE was unable to validate the certificate path. The evaluators constructed a certificate path where the CA did not have the CA flag in the basicConstraints extension set. The TOE was unable to validate the certificate path. The evaluators constructed a certificate path where the CA had the CA flag in the basicConstraints extension set to TRUE. The TOE was able to successfully validate the certificate path. The evaluators provided a certificate to the TOE where the DN did not match the expected value. The evaluators confirmed that the connection was not established. The evaluators configured the TOE to use a CRL but did not provide the revocation list. The connection was not established as the TOE could not validate the certificate.

2.2.11.13 FCS_IPSEC_EXT.1.13

TSS

The evaluator shall check that the TSS describes the potential strengths (in terms of the number of bits in the symmetric key) of the algorithms that are allowed for the IKE and ESP exchanges.

The TSS shall also describe the checks that are done when negotiating IKEv1 Phase 2 and/or IKEv2 CHILD_SA suites to ensure that the strength (in terms of the number of bits of key in the symmetric algorithm) of the negotiated algorithm is less than or equal to that of the IKE SA this is protecting the negotiation.

The TOE ensures that the strength of the symmetric algorithm (128 or 256 bits) negotiated to protect the IKEv1 Phase 1, IKEv2 IKE_SA connection is greater than or equal to the strength of the symmetric algorithm negotiated to protect the IKEv1 Phase 2, IKEv2 CHILD_SA connection.


N/A

Testing

This test shall be performed for each version of IKE supported by the TOE. The evaluator shall successfully negotiate an IPsec connection using each of the supported algorithms and hash functions identified in the requirements.

This test shall be performed for each version of IKE supported by the TOE. The evaluator shall attempt to establish an SA for ESP that selects an encryption algorithm with more strength than that being used for the IKE SA (i.e., symmetric algorithm with a key size larger than that being used for the IKE SA). Such attempts should fail.

This test shall be performed for each version of IKE supported by the TOE. The evaluator shall attempt to establish an IKE SA using an algorithm that is not one of the supported algorithms and hash functions identified in the requirements. Such an attempt should fail.

This test shall be performed for each version of IKE supported by the TOE. The evaluator shall attempt to establish an SA for ESP (assumes the proper parameters where used to establish the IKE SA) that selects an encryption algorithm that is not identified in FCS_IPSEC_EXT.1.4. Such an attempt should fail.

The evaluators confirmed that both IKEv1 and IKEv2 connections could be established using each of the encryption algorithms and hash functions identified in the SFR. The evaluators attempted to configure an IPsec connection where the configured encryption algorithm for Phase 2 was greater than the connection strength selected for Phase 1. The evaluators confirmed that the TOE rejected this configuration.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

The evaluators attempted to configure a connection using both an unsupported encryption a algorithm and/or an unsupported hashing algorithm. In all cases, the TOE rejected these unsupported algorithms.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2.3 User Data Protection (FDP)

2.3.1 FDP_RIP.2 Full residual information protection

TSS

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

The only resource made available to information flowing through a TOE is the temporary storage of packet information when access is requested and when information is being routed. User data is not persistent when resources are released by one user/process and allocated to another user/process. Temporary storage (memory) used to build network packets is erased when the resource is called into use by the next user/process. Junos knows, and keeps track of, the length of the packet. This means that when memory allocated from a previous user/process arrives to build the next network packet, Junos is aware of when the end of the packet is reached and pads a short packet with zeros accordingly. Therefore, no residual information from packets in a previous information stream can traverse through the TOE.


N/A


N/A

2.4 Identification and Authentication (FIA)

2.4.1 FIA_AFL.1 Authentication failure handling

TSS

The evaluator shall examine the TSS to determine that it contains a description, for each supported method for remote administrative actions, of how successive unsuccessful authentication attempts are detected and tracked.

The TSS shall also describe the method by which the remote administrator is prevented from successfully logging on to the TOE, and the actions necessary to restore this ability.

A remote administrator may logon to the TOE via SSH. Administrator credentials are stored locally to the device. If the remote administrator presents a valid username and password, access to the TOE is granted. If the credentials are invalid, the TOE allows the authentication to be retried after an interval that starts at 1 second at increases exponentially. If the number of authentication attempts exceeds the configured maximum, no authentication attempts are accepted for a configured time interval. When the interval has expires, authentication attempts are again accepted.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

The evaluator shall also examine the operational guidance to ensure that instructions for configuring the number of successive unsuccessful authentication attempts (1.1) and time period (1.2, if implemented) are provided, and that the process of allowing the remote administrator to once again successfully log on is described for each “action” specified (if that option is chosen).

If different actions or mechanisms are implemented depending on the secure protocol employed (e.g., TLS vs. SSH), all must be described.

Per Chapter 3 (Configuring SSH and Console Connection) of the Evaluated Configuration Guide (Ref. [11]), the following commands can be used to enforce a login attempt policy for SSH connections: user@host# set retry options tries‐before‐disconnect <number>

user@host# set retry options backoff‐threshold <number>

user@host# set retry options backoff‐factor <number>

The guidance also provides the following statement: “If the number of authentication attempts exceed the configured maximum, no authentication attempts are accepted for a configured time" interval. When the interval expires, authentication attempts are again accepted.”

Testing

The evaluator shall perform the following tests for IPsec, and for each other method by which remote administrators access the TOE (e.g., TLS, SSH):

The evaluator shall use the operational guidance to configure the number of successive unsuccessful authentication attempts allowed by the TOE. The evaluator shall test that once the limit is reached, attempts with valid credentials are not successful. For each action specified by the requirement, the evaluator shall show that following the operational guidance and performing each action to allow the remote administrator access are successful.

The evaluator shall use the operational guidance to configure the number of successive unsuccessful authentication attempts allowed by the TOE and a time period after which valid logins will be allowed for a remote administrator. After exceeding the specified number of invalid login attempts and showing that valid login is not possible, the evaluator shall show that waiting for the interval defined by the time period before another access attempt will result in the ability for the remote administrator to successfully log on using valid credentials.

The evaluators configured a maximum failed-attempt limit for each remote administration method. The evaluators confirmed that the TOE rejected any further attempts until a defined time period had expired. Evaluators confirmed that, once the time period had passed, further login attempts were permitted by the TOE and attempts using correct credentials led to a successful logon.

2.4.2 FIA_PMG_EXT.1 Password management

TSS None specified.

N/A

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

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

Chapter 2 of the Evaluated Configuration Guide (Ref. [11]) provides guidance on passwords (complexity, valid characters, what constitutes a weak password, etc.) and guidance on how to configure the TOE to set the minimum length and minimum number of character changes.

Testing

The evaluator shall compose passwords that either meet the requirements, or fail to meet the requirements, in some way. For each password, the evaluator shall verify that the TOE supports the password.

While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all characters, rule characteristics, and a minimum length listed in the requirement are supported, and justify the subset of those characters chosen for testing.

The evaluators tested a variety of passwords, both valid and invalid. The evaluators confirmed that the TOE accepted those passwords on the “valid” list and rejected those on the “invalid” list.

2.4.3 FIA_UAU_EXT.2 Extended: Password-based authentication mechanism

TSS None specified.

N/A


N/A


N/A

2.4.4 FIA_UIA_EXT.1 User identification and authentication

TSS

The evaluator shall examine the TSS to determine that it describes the logon process for each logon method (local, remote (HTTPS, SSH, etc.)) supported for the product.

This description shall contain information pertaining to the credentials allowed/used, any protocol transactions that take place, and what constitutes a “successful logon”.

Following TOE initialization, a ‘login’ process is listening for a connection at the local console. This ‘login’ process can be accessed through either direct connection to the local console or following successful establishment of a remote management connection over SSH, when a login prompt is displayed. This login process identifies and authenticates the user using PAM operations. The TOE provides obscured feedback during the authentication process. The login process does two things; it first establishes that the requesting user is whom they claim to be and second provides them with an interactive Junos Command interactive command line interface (CLI). The SSH daemon supports public key authentication by looking up a public key in an authorized keys file located in the directory '.ssh' in the user's home directory (ie '~/.ssh/') and this authentication method will be attempted before any other if the client has a key available. The SSH daemon will ignore the authorized keys file if it or the directory'.ssh' or the user's home directory are not owned by the user or are writeable by anyone else.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

For password authentication, login() interacts with a user to request a username and password to establish and verify the user’s identity. The username entered by the administrator at the username prompt is reflected to the screen, but no feedback to screen is provided while the entry made by the administrator at the password prompt until the Enter key is pressed. Login uses PAM Library calls for the actual verification of this data. PAM is used in the TOE support authentication management, account management, session management and password management. Login primarily uses the session management and password management functionality offered by PAM.

Guidance

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

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

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

With the exception of having an SSH client compatible with the TOE, and selecting an SSH proposal (encryption and integrity algorithms, etc.) that match the evaluated configuration of the TOE, and permitting the use of SSH via the desired interface, no other actions are required to be performed by administrator prior to logging in. The administrator must connect to the TOE via SSH or CLI and provide their username and password. If the username and password combination provided are valid, the TOE will permit access to TSF data. No services are provided to the administrator prior to authentication and no configuration is required.

Testing

The evaluator shall perform the following tests for each method by which administrators access the TOE (local and remote), as well as for each type of credential supported by the login method:

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

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

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

The evaluators configured that for both local and remote administration methods, providing the correct credentials results in a successful login. Providing invalid credentials results in denial of access. There are no services provided by the TOE prior to login.

2.4.5 FIA_UAU.7 Protected authentication feedback

TSS None specified.

N/A


N/A

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

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

The evaluators confirmed that, while authenticating with the TOE, obscured feedback (*) is provided while entering authentication information.

2.4.6 FIA_X509_EXT.1 Extended: X.509 certificates

TSS

The TSS shall describe all certificate stores implemented that contain certificates used to meet the requirements of this EP. This description shall contain information pertaining to how certificates are loaded into the store, and how the store is protected from unauthorized access.

The TSS description will also include a discussion as to how the TOE forms a certification path as specified in the standard and how certificates are validated (CRL and/or OCSP are included in the discussion, as well as the certificate path validation algorithm).

Certificates are stored in non-volatile flash memory. Access to flash memory requires administrator credentials. A certificate may be loaded via command line. Alternately, the key-pair may be generated locally and the certificate self-signed. If the TOE has been configured for CRL revocation checking and the certificate considered for validation is not present on the CRL, then the validation succeeds. If the CRL fails to download, the certificate is considered to have failed validation, unless the option to skip CRL checking on download failure has been enabled. If the TOE has been configured for OCSP, and the response from the OCSP responder is “good” or “unknown”, then the validation succeeds. If there is an error, or no response from the OCSP responder, then the TOE will either fail the validation, skip the OCSP check and pass the validation, or fall back to CRL checking, as configured. The TOE validates a certificate path by building a chain of certificates based upon issuer and subject linkage, validating each according the certificate validation procedure described above. If any certificate in the chain fails validation, the validation fails as a whole. A self-signed certificate is not required to be at the root of the certificate chain.

Guidance

The evaluator shall verify that the operational guidance describes how to the administrator loads certificates into the certificate store. If the level of protection can be managed by the administrator, the guidance provides a description of how to manage the protection mechanism. The guidance instructs the administrator how to generate a key pair and how to generate a Certificate Request Message to the CA.

The guidance documentation provides instructions how to select the method used for checking, as well as how to setup a protected communication path with the entity providing the information pertaining to certificate validity.

How the administrator can configure the TOE to either allow or disallow the establishment of an SA is also described in the operational guidance.

The following commands can be used to import certificates: request security pki local‐certificate load certificate‐id local.cert filename <filename>

request security pki ca‐certificate load ca‐profile ca‐profile‐ipsec filename <filename>

The level of protection provided to the store cannot be configured by the administrator. Section 5 of the SRX Guidance Annex (Ref. [16]) provides guidance on configuring a certificate request message. The following command(s) can be used to generate the request:

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

request security pki generate‐certificate‐request certificate‐id <id> domain‐name <domain> subject <subject>

The <subject> can be comprised of the following components:

Domain component (DC);

Common name (CN);

Serial number (SN);

Organizational unit name (OU);

Organization name (O);

Locality (L)

State (ST); and

Country (C)

The following commands can be used to configure revocation checking using OCSP: set security pki ca‐profile <ca> revocation‐check use‐ocsp

set security pki ca‐profile <ca> revocation‐check ocsp url <url>

set security pki ca‐profile <ca> revocation‐check ocsp disable‐responder‐revocation‐check

set security pki ca‐profile <ca> revocation‐check ocsp connection‐failure fallback‐crl

The following commands can be used to configure revocation checking using CRL: Using a local CRL: request security pki crl load ca‐profile <ca profile> filename <path to CRL>

Using a remote CRL: set security pki ca‐profile <ca profile> revocation‐check crl url <URL>

The commands provided in the VPN Security Feature document can be used to configure an IPsec tunnel between the TOE and the remote entity providing revocation checks.


N/A

2.4.7 FIA_PSK_EXT.1 Extended: Pre-shared key composition

TSS

The evaluator shall examine the TSS to ensure that it identifies all protocols that allow both text-based and bit-based pre-shared keys, and states that text-based pre-shared keys of 22 characters are supported.

For each protocol identified by the requirement, the evaluator shall confirm that the TSS states the conditioning that takes place to transform the text-based pre-shared key from the key sequence entered by the user (e.g., ASCII representation) to the bit string used by the protocol, and that this conditioning is consistent with the last selection in the FIA_PSK_EXT.1.3 requirement.

The TOE uses pre-shared keys for IPSec. The TOE accepts ASCII pre-shared or bit-based keys of 1 to 255 characters (and their binary equivalent) that may contain upper and lower case letters, numbers, and special characters (that include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”. The TOE accepts pre-shared text keys and converts the text string into an authentication value as per RFC 2409 for IKEv1 or RFC 4306 for IKEv2, using the PRF that is configured as the hash algorithm for the IKE exchanges.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

The evaluator shall examine the operational guidance to determine that it provides guidance to administrators on the composition of strong text-based pre-shared keys, and (if the selection indicates keys of various lengths can be entered) that it provides information on the merits of shorter or longer pre-shared keys.

The guidance must specify the allowable characters for pre-shared keys, and that list must be a super-set of the list contained in FIA_PSK_EXT.1.2.

The evaluator shall confirm the operational guidance contains instructions for either entering bit-based pre-shared keys for each protocol identified in the requirement, or generating a bit-based pre-shared key (or both).

Chapter 7 (Configuring VPNs) of the Evaluated Configuration Guide (Ref. [11]) provides the following guidance for PSKs: “A device running Junos OS uses preshared keys for IPsec (no other protocols). TOE accepts ASCII preshared or bit-based keys up to 255 characters (and their binary equivalents) that contain uppercase and lowercase letters, numbers, and special characters such as !, @, #, $, %, ^, &, *, (, and ). The device accepts the preshared text keys and converts the text string into an authentication value as per RFC 2409 for IKEv1 or RFC 4306 for IKEv2, using the PRF that is configured as the hash algorithm for the IKE exchanges.” Chapter 7 also provides guidance on configuring the TOE to use PSK authentication for VPN connections, including the entry of pre-share keys (the TOE does not support the generation of bit-based PSKs).

Testing

The evaluator shall also perform the following tests for each protocol (or instantiation of a protocol, if performed by a different implementation on the TOE). Note that one or more of these tests can be performed with a single test case.

The evaluator shall compose a pre-shared key of 22 characters that contains a combination of the allowed characters in accordance with the operational guidance, and demonstrates that a successful protocol negotiation can be performed with the key.

If the TOE supports pre-shared keys of multiple lengths, the evaluator shall repeat Test 1 using the minimum length; the maximum length; and an invalid length. The minimum and maximum length tests should be successful, and the invalid length must be rejected by the TOE.

If the TOE does not generate bit-based pre-shared keys, the evaluator shall obtain a bit-based pre-shared key of the appropriate length and enter it according to the instructions in the operational guidance. The evaluator shall then demonstrate that a successful protocol negotiation can be performed with the key.

The evaluators confirmed that a valid PSK of 22 characters is accepted by the TOE. This PSK was then used for the negotiation and establishment of an IPsec connection. The evaluators confirmed that PSKs of the minimum and maximum length thresholds are accepted by the TOE, while a PSK of an invalid length was rejected. The evaluators that the TOE permits the import and use of bit-based pre-shared keys for IPsec connections.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2.5 Security management (FMT)

2.5.1 FMT_MOF.1 Management of security functions behaviour

TSS

The evaluator shall examine the TSS to determine that, for each administrative function identified in the operational guidance; those that are accessible through an interface prior to administrator log-in are identified.

For each of these functions, the evaluator shall also confirm that the TSS details how the ability to manipulate the configuration of the system through this interface is disallowed for non-administrative users.

No functions are available to administrators prior to login.

Guidance

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

The documentation groups functionality into specific sections and/or chapters (IPsec, SSH, firewall rules, etc.), which allows for simple identification of which functions are applicable to the requirements of the PP. The TOE implements a single role, that of the authorised administrator. As such, no configuration is required to restrict access to TOE functions and TSF data.


N/A

2.5.2 FMT_MTD.1 Management of TSF data (for general TSF data)

TSS

The evaluator shall examine the TSS to determine that, for each administrative function identified in the operational guidance; those that are accessible through an interface prior to administrator log-in are identified.

For each of these functions, the evaluator shall also confirm that the TSS details how the ability to manipulate the TSF data through these interfaces is disallowed for non-administrative users.

No functions are available to administrators prior to login.

Guidance

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

The documentation groups functionality into specific sections and/or chapters (IPsec, SSH, firewall rules, etc.), which allows for simple identification of which functions are applicable to the requirements of the PP. The TOE implements a single role, that of the authorised administrator. As such, no configuration is required to restrict access to TOE functions and TSF data.


N/A

2.5.3 FMT_SMF.1(1) Specification of management functions

TSS None specified.

N/A

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE


N/A


N/A

2.5.4 FMT_SMF.1(2) Specification of management functions

TSS

The evaluator shall verify that the TSS describes how the IPS data analysis and reactions can be configured. Note that this activity should have been addressed with the TSS assurance activities for IPS_SBD_EXT.1, IPS_SBD_EXT.1 and IPS_ABD_EXT.1

See TSS entries for IPS_SBD_EXT.1 and IPS_ABD_EXT.1.

Guidance

The evaluator shall verify that the operational guidance describes the instructions for each function defined in the SFR, describes how to configure the IPS data analysis and reactions, including how to set any configurable defaults and how to configure each of the applicable analysis pattern matching methods and reaction modes.

The IDP Feature Guide and Evaluated Configuration Guide (Refs. [15] and [11]) provide sufficient information and instruction on how to configure the IPS data analysis and reactions and how to configure each of the applicable analysis pattern matching methods and reaction modes.

Testing

The evaluator shall use the operational guidance to create a signature and enable it on an interface. The evaluator shall then generate traffic that would be successfully triggered by the signature. The evaluator should observe the TOE applying the corresponding reaction in the signature.

The evaluator shall then disable the signature and attempt to regenerate the same traffic and ensure that the TOE allows the traffic to pass with no reaction.

The evaluator shall use the operational guidance to import signatures and repeat the test conducted in Test 1.

The evaluators configured, enabled and tested an IPS signature on an interface. The evaluator generated traffic matching the signature and confirmed that the TOE denied the traffic flow and generated appropriate log entries. The evaluator then disabled the IPS signature and confirmed that the TOE allowed the traffic to flow with no reaction. The evaluators imported a signature and repeated the test – the behaviour of the TOE was identical in both cases.

2.5.5 FMT_SMR.2 Restrictions on security roles

TSS None specified.

N/A

Guidance

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

Chapter 3 (Configuring SSH and Console Connection) of the Evaluated Configuration Guide (Ref. [11]) provides administrators with the commands required to configure the SSH daemon to be compliant with the NDPP (key exchange methods, encryption algorithms, etc.) and the authentication lockout/failure attempts permitted for both CLI and SSH.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

SSH is the only permitted remote administrative method – J-Web and Telnet are not permitted. SSH access can be permitted via any of the Ethernet ports the TOE provides. Local administration is provided via the Console RJ-45 port on each SRX device. This port is configured as an RS-232 serial communications port and allows local administrator’s access to the CLI.

Testing

In the course of performing the testing activities for the evaluation, the evaluator shall use all supported interfaces, although it is not necessary to repeat each test involving an administrative action with each interface.

The evaluator shall ensure, however, that each supported method of administering the TOE that conforms to the requirements of this PP be tested; for instance, if the TOE can be administered through a local hardware interface; SSH; and TLS/HTTPS; then all three methods of administration must be exercised during the evaluation team’s test activities.

The evaluators exercised all local and remote methods of administration during the execution of testing.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2.6 Protection of the TSF (FPT)

2.6.1 FPT_SKP_EXT.1 Extended: Protection of TSF data (for reading of all symmetric keys)

TSS

The evaluator shall examine the TSS to determine that it details how any pre-shared keys, symmetric keys, and private keys are stored and that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note.

If these values are not stored in plaintext, the TSS shall describe how they are protected/obscured.

The TOE does not provide a CLI interface to permit the viewing of keys. Cryptographic keys are protected through the enforcement of kernel-level file access rights, limiting access to the contents of cryptographic key containers to processes with cryptographic rights. Authentication data for public key-based authentication methods are stored in a directory owned by the user (and typically with the same name as the user). This directory contains the files '.ssh/authorized_keys' and '.ssh/authorized_keys2' which are used for SSH public key authentication.


N/A


N/A

2.6.2 FPT_APW_EXT.1 Extended: Protection of administrator passwords

TSS

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

The TSS shall also detail passwords are stored in such a way that they are unable to be viewed through an interface designed specifically for that purpose, as outlined in the application note.

Password information is stored as hashed data (using hmac-sha1) in the authentication database and public keys are stored in plaintext in '.ssh' files in the user's home directory (ie '~/.ssh/').


N/A


N/A

2.6.3 FPT_FLS.1 Fail secure

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator shall ensure the TSS describes how the TOE ensures a shutdown upon a self-test failure, a failed integrity check of the TSF executable image, or a failed health test of the noise source.

If there are instances when a shut-down does not occur, e.g., a failure is deemed non-security relevant, those cases are identified and a rationale supporting the classification and justification why the TOE’s ability to enforce its security policies is not affected.

In the event of a transiently corrupt state or failure condition, the system will panic; the event will be logged and the system restarted, having ceased to process network traffic. When the system restarts, the system boot process does not succeed without passing all self-tests for cryptographic algorithms, RNG tests, and software integrity tests


N/A


N/A

2.6.4 FPT_STM.1 Reliable time stamps

TSS

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

The clock function of the TOE provides a source of date and time information for the appliance, used in audit timestamps. The clock function is reliant on the system clock provided by the underlying hardware. In addition, for each user session the TOE maintains a count of clock cycles (provided by the system clock) since last activity. The count is reset each time there is activity related to the user session. When the counter reaches the number of clock cycles equating to the configured period of inactivity the user session is locked out. The system clock is also used to determine SA lifetimes and authentication failure timeout.

Guidance

The evaluator examines the operational guidance to ensure it instructs the administrator how to set the time. If the TOE supports the use of an NTP server, the operational guidance instructs how a communication path is established between the TOE and the NTP server, and any configuration of the NTP client on the TOE to support this communication.

Per Chapter 24 (Junos CLI Environmental Controls) of the CLI Guide (Ref. [12]), the time can be set via the CLI using the following command: set date YYYYMMDDHHMM.SS

The use of an NTP server can be configured via the following command: set date ntp <server ip>

No additional configuration of the NTP client on the TOE is required to assist in establishing the connection.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

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

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

The evaluators configured the time via the CLI and verified that the system clock was adjusted appropriately. The evaluators configured the TOE to synchronise its clock with an NTP server hosted on the test network. The evaluators confirmed that, once the connection was established, the TOE updated its clock to match the NTP server.

2.6.5 FPT_TUD_EXT.1 Extended: Trusted update

TSS

Updates to the TOE either have a hash associated with them, or are signed by an authorized source.

If digital signatures are used, the definition of an authorized source is contained in the TSS, along with a description of how the certificates used by the update verification mechanism are contained on the device. The evaluator ensures this information is contained in the TSS.

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

The kernel maintains a set of fingerprints (SHA1 digests) for executable files and other files which should be immutable. No executable can be run or shared object loaded unless the fingerprint is correct. The fingerprints are loaded as the filesystems are mounted, from digitally signed manifests. The manifest file is signed using the Juniper engineering private key, and is verified by the TOE using the Juniper engineering public key (stored on the TOE filesystem in clear, protected by filesystem access rights). The fingerprint loader will only process a manifest for which it can verify the signature. Thus without a valid digital signature an executable cannot be run. When the command is issued to install an update (e.g. request system software add jinstall), the manifest file for the update is verified and stored, and each executable/immutable file is verified before it is executed. If any of the fingerprints in an update are not correctly verified, the TOE rolls back to the last known verified image.

Guidance

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

Chapter 5 (Software Upgrade) of the Software Installation and Upgrade Guide (Ref. [13]) describes the process for obtaining candidate update files from the Juniper website. It also provides administrators with the commands required to back up their active configuration prior to commencing the update.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

All downloaded candidate update files are digitally signed by the Juniper engineering team upon compilation. When a candidate update file is loaded onto the TOE and included as part of the syntax for the request system software add command, the TOE attempts to verify the signature attached to the file. If verification fails, the TOE rejects the update file and the update process is cancelled. If the verification passes, the TOE will update the OS and reboot to finalise the update.

Testing

The evaluator performs the version verification activity to determine the current version of the product.

The evaluator obtains a legitimate update using procedures described in the operational guidance and verifies that it is successfully installed on the TOE.

Then, the evaluator performs a subset of other assurance activity tests to demonstrate that the update functions as expected. After the update, the evaluator performs the version verification activity again to verify the version correctly corresponds to that of the update

The evaluator performs the version verification activity to determine the current version of the product. The evaluator obtains or produces an illegitimate update, and attempts to install it on the TOE. The evaluator verifies that the TOE rejects the update.

The evaluators performed a system upgrade using a legitimate update file. The evaluators confirmed that the update completed successfully and the TOE version number was updated to reflect the change. The evaluators attempted to perform the update process using a modified update file. The evaluators confirmed that the TOE rejected this update file and the system update file was halted.

2.6.6 FPT_TST_EXT.1 Extended: TSF testing

TSS

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

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

The TOE runs the following set of self-tests during power on to check the correct operation of the TOE.

Power on test – determines the boot-device responds, and performs a memory size check to confirm the amount of available memory.

File integrity test –verifies integrity of all mounted signed packages, to assert that system files have not been tampered with.

Authentication error – verifies that veriexec is enabled and operates as expected using /opt/sbin/kats/cannot-exec.real.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

The evaluator shall also ensure that the operational guidance describes the possible errors that may result from such tests, and actions the administrator should take in response; these possible errors shall correspond to those described in the TSS.

Chapter 11 (Performing Self-Tests on a Device) of the Evaluated Configuration Guide (Ref. [11]) provides a list of the errors that may occur due to the failure of one or more of the self-tests performed by the TOE. Actions that may be taken as a result of the failure of self-tests are provided as part of the console output.


N/A

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2.7 TOE access (FTA)

2.7.1 FTA_SSL_EXT.1 TSF-initiated session locking

TSS None specified.

N/A


N/A

Testing

The evaluator follows the operational guidance to configure several different values for the inactivity time period referenced in the component.

For each period configured, the evaluator establishes a local interactive session with the TOE. The evaluator then observes that the session is either locked or terminated after the configured time period.

If locking was selected from the component, the evaluator then ensures that re-authentication is needed when trying to unlock the session.

The evaluators configured a number of values for the inactivity time period (1, 5, 10 and 30 minutes). The evaluators confirmed that, for each time period, the local interactive session was automatically closed once the defined time period of inactivity had passed. Re-authentication was required before access to TSF data was restored.

2.7.2 FTA_SSL.3(1) TSF-initiated termination

TSS None specified.

N/A


N/A

Testing

The evaluator follows the operational guidance to configure several different values for the inactivity time period referenced in the component.

For each period configured, the evaluator establishes a remote interactive session with the TOE. The evaluator then observes that the session is terminated after the configured time period.

The evaluators configured a number of values for the inactivity time period (1, 5, 10 and 30 minutes). The evaluators confirmed that, for each time period, the remote interactive session was automatically closed once the defined time period of inactivity had passed. Re-authentication was required before access to TSF data was restored.

2.7.3 FTA_SSL.3(2) TSF-initiated termination

TSS None specified.

N/A


N/A

Testing None specified

N/A

2.7.4 FTA_SSL.4 User-initiated termination

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS None specified.

N/A


N/A

Testing

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

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

The evaluator commenced both local and remote interactive sessions with the TOE. The evaluators confirmed that, once the “exit” command was issued from the CLI, the sessions were terminated.

2.7.5 FTA_TAB.1 Default TOE access banners

TSS None specified.

N/A


N/A

Testing

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

The evaluators confirmed an access/warning banner to be displayed prior to administrator login. The evaluators connect to the TOE via both local and remote channels and confirmed that, in both instances, the configured message was displayed.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2.8 Trusted path/channels (FTP)

2.8.1 FTP_ITC.1(1) Inter-TSF trusted channel (prevention of disclosure)

TSS

The evaluator shall examine the TSS to determine that, for all communications with authorized IT entities identified in the requirement, each communications mechanism is identified in terms of the allowed protocols for that IT entity.

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

The TOE supports and enforces Trusted Channels that protect the communications between the TOE and remote audit server from unauthorized disclosure or modification using IPSec.

Guidance

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

Chapter 8 of the Evaluated Configuration Guide (Ref. [11]) provides an administrator with guidance and configuration examples for configuring an IPsec VPN tunnel between the TOE and the external syslog server to allow for the transmission of log data.

Testing

The evaluators shall ensure that communications using each protocol with each authorized IT entity is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.

For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall follow the operational guidance to ensure that in fact the communication channel can be initiated from the TOE.

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

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

The evaluator configured IPsec communications with the remote audit server as part of ongoing testing. The evaluators confirmed that the channel was initiated from the TOE and that communications were protected while in transit between the two devices. The evaluators confirmed that, upon physically disconnection and reconnection of the link, encrypted communications were re-established and no data was sent in the clear.

2.8.2 FTP_ITC.1(2) Inter-TSF trusted channel

TSS

The evaluator shall examine the TSS to determine that, for all communications with authorized IT entities identified in the requirement, each communications mechanism is identified in terms of the allowed protocols for that IT entity.

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

The TOE supports and enforces Trusted Channels that protect the communications between the TOE and remote audit server from unauthorized disclosure or modification using IPSec.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

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

Chapter 8 of the Evaluated Configuration Guide (Ref. [11]) provides an administrator with guidance and configuration examples for configuring an IPsec VPN tunnel between the TOE and the external syslog server to allow for the transmission of log data.

Testing

The evaluators shall ensure that communications using each protocol with each authorized IT entity is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.

For each protocol that the TOE can initiate as defined in the requirement, the evaluator shall follow the operational guidance to ensure that in fact the communication channel can be initiated from the TOE.

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

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

The evaluator configured IPsec communications between the TOE and an IPsec peer as part of ongoing testing. The evaluators confirmed that the channel was initiated from the TOE and that communications were protected while in transit between the two devices. The evaluators confirmed that, upon physically disconnection and reconnection of the link, encrypted communications were re-established and no data was sent in the clear.

2.8.3 FTP_TRP.1 Trusted path

TSS

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

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

It also supports Trusted Paths between itself and remote administrators so that the contents of administrative sessions are protected against unauthorized disclosure or modification using SSHv2, which can be further protected using IPSec.

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

Chapter 3 (Configuring SSH and Console Connection) of the Evaluated Configuration Guide (Ref. [11]) provides administrators with the commands required to configure the SSH daemon to be compliant with the NDPP (key exchange methods, encryption algorithms, etc.) and the authentication lockout/failure attempts permitted for both CLI and SSH. SSH is the only permitted remote administrative method – J-Web and Telnet are not permitted. SSH access can be permitted via any of the Ethernet ports the TOE provides. The administrator must connect to the TOE via SSH and provide their username and password. If the username and password combination provided are valid, the TOE will permit access to TSF data.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

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

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

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

The evaluators configured and connected to the TOE via SSH for remote administration. The TOE provides no other capability for establishing a remote administrative session. The evaluators performed traffic analysis while a remote administrative session was active and confirmed that traffic was not sent in plaintext.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2.9 Stateful traffic/packet filtering (FFW and FPF)

2.9.1 FFW_RUL_EXT.1 Stateful firewall filtering

2.9.1.1 FFW_RUL_EXT.1.1

TSS

The evaluator shall verify that the TSS provide a description of the TOE’s initialization/startup process, which clearly indicates where processing of network packets begins to take place, and provides a discussion that supports the assertion that packets cannot flow during this process.

The evaluator shall verify that the TSS also include a narrative that identifies the components (e.g., active entity such as a process or task) involved in processing the network packets and describe the safeguards that would prevent packets flowing through the TOE without applying the ruleset in the event of a component failure. This could include the failure of a component, such as a process being terminated, or a failure within a component, such as memory buffers full and cannot process packets.

The boot sequence of the TOE appliances also aids in establishing the securing domain and preventing tamping or bypass of security functionality. The following steps list the boot sequence for the TOE:

BIOS hardware and memory checks Loading and initialization of the FreeBSD Kernel OS FIPS self-tests and firmware integrity tests are executed The init utility is started (mounts file systems, sets up network cards to communicate

on the network, and generally starts all the processes that usually are run on a FreeBSD system at startup)

Daemon programs such as Internet Service Daemon (INETD), Routing Protocol Daemon (RPD), Syslogd are started; Routing and forwarding tables are initialized

Management Daemon (or MGD) is loaded, allowing access to management interface Physical interfaces are active

Once the interfaces are brought up, they will start to receive and send packets based on the current configuration (or not receive or send any packets if they have not been previously configured). Interfaces are brought up only after successful loading of kernel and Information Flow subsystems, and these interfaces cannot send or receive packets unless previously configured by an authorized administrator. Since the Management Daemon is not loaded until after the kernel and INETD are initialized, no modification to the security attributes can be made by a user or process other than via the management process. INETD is used to start SSHD which provides secure communication path for remote administrators to manage the TOE. The trusted and untrusted network connection interfaces on the security appliance are not enabled until all of the components on the appliance are fully initialized; power-up tests are successful and ready to enforce the configured security policies. In this manner, the TOE ensures that administrators are appropriately authorized when they exercise management commands and any network traffic is always subject to the configured information flow policies. JUNOS is composed of a number of separate executables, or daemons. If a failure occurs in the “flow” daemon (flowd) causing it to halt, no packet processing will occur and no packets will be forwarded. A failure in another daemon will not prevent the flow daemon from enforcing the policy rule set.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE


N/A

Testing

The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized. A steady flow of network packets that would otherwise be denied by the ruleset should be directed at the TOE’s interfaces, with packet sniffers listening to see if any network traffic is allowed through.

The evaluators sent a stream of traffic at the TOE while it was initialising. The evaluators performed a Wireshark analysis and confirmed that no traffic was permitted to flow through the TOE while initialisation was in progress.

2.9.1.2 FFW_RUL_EXT.1.2

TSS

The evaluator shall verify that the TSS indicates that the following protocols are supported:

RFC 792 (ICMPv4);

RFC 4443 (ICMPv6);

RFC 791 (IPv4);

RFC 2460 (IPv6);

RFC 793 (TCP); and

RFC 768 (UDP)

The evaluator shall verify that the TSS describes how conformance with the identified RFCs has been determined by the TOE developer (e.g., third party interoperability testing, protocol compliance testing).

Table 7-3, provided in Section 7.10 of the Security Target, indicates that the above protocols are supported. Conformance to these RFCs is demonstrated by protocol compliance testing by the product QA team.

Guidance

The evaluator shall verify that the operational guidance indicates that the following protocols are supported:

RFC 792 (ICMPv4);

RFC 4443 (ICMPv6);

RFC 791 (IPv4);

RFC 2460 (IPv6);

RFC 793 (TCP); and

RFC 768 (UDP)

If the guidance describes other protocols that are processed by the TOE, it should be made clear that those protocols were not considered as part of the TOE evaluation.

Chapter 5 (Configuring Traffic Filtering Rules) of the Evaluated Configuration Guide (Ref. [11]) provides a listing of the supported protocols and their relevant RFCs. The list matches the one specified in this requirement. The guidance also indicates that the TOE supports the OSPF, BGP and RIP protocols, but that these protocols are not included in the scope of the evaluated configuration.


N/A

2.9.1.3 FFW_RUL_EXT.1.3

TSS None specified.

N/A

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE


N/A


N/A

2.9.1.4 FFW_RUL_EXT.1.4

TSS None specified.

N/A


N/A


N/A

2.9.1.5 FFW_RUL_EXT.1.5

TSS

The evaluator shall verify that the TSS describes a stateful packet filtering policy and the following attributes are identified as being configurable within stateful traffic filtering rules for the associated protocols:

ICMPv4

o Type

o Code

ICMPv6

o Type

o Code

IPv4

o Source address

o Destination Address

o Transport Layer Protocol

IPv6

o Source address



TCP

o Source Port

o Destination Port

UDP

o Source Port

o Destination Port

The evaluator shall verify that each rule can identify the following actions: permit, deny, and log.

The evaluator shall verify that the TSS identifies all interface types subject to the stateful packet filtering policy and explains how rules are associated with distinct network interfaces. Where interfaces can be grouped into a common interface type (e.g., where the same internal logical path is used, perhaps where a common device driver is used) they can be treated collectively as a distinct network interface.

Table 7-3, provided in Section 7.10 of the Security Target (Ref. [10]) , indicates that the above protocols and attributes are supported and configurable within firewall rules.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

The TOE shall allow permit, deny, and log operations to be associated with rules and these rules can be assigned to distinct network interfaces. The TOE is configured to associate network interfaces to IP subnets. Source IP addresses are then associated with the network interface.

Guidance

The evaluators shall verify that the operational guidance identifies the following attributes as being configurable within stateful traffic filtering rules for the associated protocols:

ICMPv4

o Type

o Code

ICMPv6

o Type

o Code

IPv4

o Source address



IPv6

o Source address



TCP

o Source Port

o Destination Port

UDP

o Source Port

o Destination Port

The evaluator shall verify that the operational guidance indicates that each rule can identify the following actions: permit, deny, and log.

The evaluator shall verify that the operational guidance explains how rules are associated with distinct network interfaces.

The evaluator shall verify that the operational guidance explains how to determine the interface type of a distinct network interface (e.g., how to determine the device driver for a distinct network interface).

Chapter 5 of the Evaluated Configuration Guide (Ref. [11]) lists the protocols and their associated fields listed above as being configurable within stateful traffic filtering rules. Chapter 6 (Configuring Security Flow Policies) indicates that the following actions can be tied to each security flow policy:

Bypass—The Permit option directs the traffic traversing the device through the stateful firewall inspection, but not through the IPsec VPN tunnel.

Discard—The Deny option inspects and drops all packets that do not match any Permit policies.

Protect—The traffic is routed through an IPsec tunnel based on the combination of route lookup and Permit policy inspection.

Log—This option logs traffic and session information for all the modes mentioned above

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Per Chapter 6 of the Evaluated Configuration Guide, each firewall rule is associated with a security zone (trustLan, untrustLan, etc.). These security zones are subsequently associated with a specific interface provided by the TOE. Each interface provided by the TOE is prefixed by a character pattern (in this example, fe and ge), such as ge-0/0/1. The designator ge stands for Gigabit Ethernet, while fe stands for Fast Ethernet. The 0/0/1 after the type designator is in the format <pin/0/port>. This allows the administrator to determine the physical location on the device of the interface. The TOE also provides the se-pin/0/port designator for the serial port used for local administration.

Testing

The evaluator shall use the instructions in the operational guidance to test that stateful packet filter firewall rules can be created that permit, deny, and log packets for each of the following attributes:

ICMPv4

o Type

o Code

ICMPv6

o Type

o Code

IPv4

o Source address



IPv6

o Source address



TCP

o Source Port

o Destination Port

UDP

o Source Port

o Destination Port

Repeat the test assurance activity above to ensure that stateful traffic filtering rules can be defined for each distinct network interface type supported by the TOE.

The evaluators designed a number of test cases to exercise all of the above protocols and attributes for permit, deny and log actions. The evaluators performed these tests on all interface types provided by the TOE and confirmed that the TOE behaved as expected.

2.9.1.6 FFW_RUL_EXT.1.6

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator shall verify that the TSS identifies the protocols that support stateful session handling. The TSS shall identify TCP, UDP, and ICMP if selected by the ST author.

The evaluator shall verify that the TSS describes how stateful sessions are established (including handshake processing) and maintained.

The evaluator shall verify that for TCP, the TSS identifies and describes the use of the following attributes in session determination: source and destination addresses, source and destination ports, sequence number, and individual flags.

The evaluator shall verify that for UDP, the TSS identifies and describes the following attributes in session determination: source and destination addresses, source and destination ports.

The evaluator shall verify that for ICMP (if selected), the TSS identifies and describes the following attributes in session determination: source and destination addresses, other attributes chosen in FFW_RUL_EXT.1.6.

The evaluator shall verify that the TSS describes how established stateful sessions are removed.

The TSS shall describe how connections are removed for each protocol based on normal completion and/or timeout conditions. The TSS shall also indicate when session removal becomes effective (e.g., before the next packet that might match the session is processed).

The TOE supports FTP (RFC 959) to dynamically establish sessions allowing network traffic according to Authorized Administrator rules. Session events will be logged in accordance with ‘log’ operations defined in the rules. Source and destination addresses, source and destination ports, transport layer protocol, and TOE Interface are recorded in each log record. The TOE accepts network packets if it matches an established TCP, UDP or ICMP session using:

TCP: source and destination addresses, source and destination ports, sequence number, flags

UDP: source and destination addresses, source and destination ports ICMP: source and destination addresses, type, code, and list of matching attributes

The TOE will remove existing traffic flows due to session inactivity timeout, or completion of the session.

Guidance The evaluator shall verify that the operational guidance describes stateful session behaviors. For example, a TOE might not log packets that are permitted as part of an existing session.

Administrators may assign the “session-init” and “session-close” log operations to a security flow policy. When these clauses are in place, the TOE will log all session establishment and closedown actions associated with dynamic sessions. Source and destination addresses, source and destination ports, transport layer protocol, and TOE Interface are recorded in each log record. Traffic received as part of an existing session will be captured by the Firewall log, but not included in Syslog.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

The evaluator shall configure the TOE to permit and log TCP traffic. The evaluator shall initiate a TCP session. While the TCP session is being established, the evaluator shall introduce session establishment packets with incorrect flags to determine that the altered traffic is not accepted as part of the session (i.e., a log event is generated to show the ruleset was applied).

After a TCP session is successfully established, the evaluator shall alter each of the session determining attributes (source and destination addresses, source and destination ports, sequence number, flags) one at a time in order to verify that the altered packets are not accepted as part of the established session.

The evaluator shall terminate the TCP session established per Test 1 as described in the TSS. The evaluator shall then immediately send a packet matching the former session definition in order to ensure it is not forwarded through the TOE without being subject to the ruleset.

The evaluator shall expire (i.e., reach timeout) the TCP session established per Test 1 as described in the TSS. The evaluator shall then send a packet matching the former session in order to ensure it is not forwarded through the TOE without being subject to the ruleset.

The evaluator shall configure the TOE to permit and log UDP traffic. The evaluator shall establish a UDP session. Once a UDP session is established, the evaluator shall alter each of the session determining attributes (source and destination addresses, source and destination ports) one at a time in order to verify that the altered packets are not accepted as part of the established session.

The evaluator shall expire (i.e., reach timeout) the UDP session established per Test 4 as described in the TSS. The evaluator shall then send a packet matching the former session in order to ensure it is not forwarded through the TOE without being subject to the ruleset.

If ICMP is selected, the evaluator shall configure the TOE to permit and log ICMP traffic. The evaluator shall establish a session for ICMP as defined in the TSS. Once an ICMP session is established, the evaluator shall alter each of the session determining attributes (source and destination addresses, other attributes chosen in FFW_RUL_EXT.1.6) one at a time in order to verify that the altered packets are not accepted as part of the established session.

If applicable, the evaluator shall terminate the ICMP session established per Test 6 as described in the TSS. The evaluator shall then immediately send a packet matching the former session definition in order to ensure it is not forwarded through the TOE without being subject to the ruleset.

The evaluator shall expire (i.e., reach timeout) the ICMP session established per Test 6 as described in the TSS. The evaluator shall then send a packet matching the former session in order to ensure it is not forwarded through the TOE without being subject to the ruleset.

The evaluators devised tests to permit and log TCP, UDP and ICMP. While sessions for each protocol were established, the evaluator attempted to send traffic that did not match the existing session characteristics. The TOE did not permit this traffic as it did not match any existing session(s). The evaluators expired/terminated each session and attempted to send traffic matching the former session definition. The evaluators confirmed that the TOE rejected these packets.

2.9.1.7 FFW_RUL_EXT.1.7

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator shall verify that the TSS identifies the protocols that can cause the automatic creation of dynamic packet filtering rules. In some cases rather than creating dynamic rules, the TOE might establish stateful sessions to support some identified protocol behaviors. The TSS shall identify FTP and optionally other protocols.

The evaluator shall verify that the TSS explains the dynamic nature of session establishment and removal. The TSS also shall explain any logging ramifications.

The evaluator shall verify that for FTP, the TSS explains how FTP data sessions will be allowed through the TOE in response to FTP control sessions.

The evaluator shall verify that for each of the other protocols selected, the TSS explains the dynamic nature of session establishment and removal specific to the protocol.

The Session Lookup module performs lookups in the session table which is used for all interfaces based on the information in incoming packets. Specifically, the lookup is based on the exact match of source IP address and port, destination IP address and port, protocol attributes (e.g., SYN, ACK, RST, and FIN), and egress/ingress zone. The input is passed to the module as a set of parameters from the Attack Detection module via a function call. The module returns matching wing if a match is found and 0 otherwise. Sessions are removed when terminated. The Session Setup module is only available for packets that do not match current established sessions. It is activated after the Session Lookup module. If packet has a matched session, it will skip the session setup module and proceed to the Security Policy module, and other modules. Eventually if the packet is not destined for the TOE, the Network interface will pass the traffic out of the appliance. The TOE accepts network packets if it matches an established TCP, UDP or ICMP session using:

TCP: source and destination addresses, source and destination ports, sequence number, flags

UDP: source and destination addresses, source and destination ports ICMP: source and destination addresses, type, code, and list of matching attributes

The TOE supports FTP (RFC 959) to dynamically establish sessions allowing network traffic according to Authorized Administrator rules. Session events will be logged in accordance with ‘log’ operations defined in the rules. Source and destination addresses, source and destination ports, transport layer protocol, and TOE Interface are recorded in each log record. JUNOS implements what is referred to as an Application Layer gateway (ALG) that inspects FTP traffic to determine the port number used for data sessions. The ALG permits data traffic for the duration of the session, closing the port when the session ends. In this context, “session” refers to the TCP data transfer connection, not the duration of the FTP control session. JUNOS implements ALGs for a number of protocols. The TOE will remove existing traffic flows due to session inactivity timeout, or completion of the session.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

The evaluator shall verify that the operational guidance describes dynamic session establishment capabilities.

The evaluator shall verify that the operational guidance describes the logging of dynamic sessions consistent with the TSS.

Chapters 5 and 6 of the Common Criteria Evaluated Configuration Guide (Ref. [11]) describe the construction and implementation of stateful traffic filtering rules. Rules can be assigned to the FTP protocol and configured per the instructions provided. The TOE will then establish FTP sessions as and when required, assuming that the rule is configured to permit FTP traffic. Administrators may assign the “session-init” and “session-close” log operations to a security flow policy. When these clauses are in place, the TOE will log all session establishment and closedown actions associated with dynamic sessions. Source and destination addresses, source and destination ports, transport layer protocol, and TOE Interface are recorded in each log record.

Testing

The evaluator shall define stateful traffic filtering rules to permit and log an FTP session and deny and log TCP ports above 1024. Subsequently, the evaluator shall establish an FTP session in order to ensure that it succeeds. The evaluator shall examine the generated logs to verify they are consistent with the operational guidance.

Continuing from Test 1, the evaluator shall determine (e.g., using a packet sniffer) which port above 1024 is being used by the FTP data session, terminate the FTP session, and then verify that TCP packets cannot be sent through the TOE using the same source and destination addresses and ports.

For each additionally supported protocol, the evaluator shall repeat the procedure above for the protocol. In each case the evaluator must use the applicable RFC or standard in order to determine what range of ports to block in order to ensure the dynamic rules are created and effective.

The evaluators configured firewall rules to permit and log FTP sessions and deny TCP ports above 1024. The evaluators established an FTP session and confirmed that the TOE generated log entries consistent with expectations and guidance. The evaluators then terminated the session and confirmed that attempts to transmit traffic using the same address/port combination were denied by the TOE.

2.9.1.8 FFW_RUL_EXT.1.8

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator shall verify that the TSS identifies the following as packets that will be automatically rejected and are capable of being logged:

Packets which are invalid fragments, including a description of what constitutes an invalid fragment

Fragments that cannot be completely re-assembled

Packets where the source address is equal to the address of the network interface where the network packet was received

Packets where the source address does not belong to the networks associated with the network interface where the network packet was received, including a description of how the TOE determines whether a source address belongs to a network associated with a given network interface

Packets where the source address is defined as being on a broadcast network

Packets where the source address is defined as being on a multicast network

Packets where the source address is defined as being a loopback address

Packets where the source address is defined as being a reserved address as specified in RFC 1918 for IPv4, and RFC 3513 for IPv6

Packets where the source or destination address of the network packet is a link-local address

Packets where the source or destination address of the network packet is defined as being an address “reserved for future use” as specified in RFC 5735 for IPv4

Packets where the source or destination address of the network packet is defined as an “unspecified address” or an address “reserved for future definition and use” as specified in RFC 3513 for IPv6

Packets with the IP options: Loose Source Routing, Strict Source Routing, or Record Route specified

Other packets defined in FFW_RUL_EXT.1.8.

The TSF shall enforce the following default reject rules with logging on all network traffic: invalid fragments; fragmented IP packets which cannot be re-assembled completely; where the source address is equal to the address of the network interface where the

network packet was received; where the source address does not belong to the networks associated with the

network interface where the network packet was received; where the source address is defined as being on a broadcast network; where the source address is defined as being on a multicast network; where the source address is defined as being a loopback address; where the source address is a multicast; packets where the source or destination address is a link-local address; where the source or destination address is defined as being an address “reserved for

future use” as specified in RFC 5735 for IPv4; where the source or destination address is defined as an “unspecified address” or an

address “reserved for future definition and use” as specified in RFC 3513 for IPv6;

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

with the IP options: Loose Source Routing, Strict Source Routing, or Record Route specified;

Packets are checked for validity. “Invalid fragments” are those that violate these rules:

No overlap The total fragments in one packet should not be more than 62 pieces The total length of merged fragments should not larger than 64k All fragments in one packet should arrive in 2 seconds The total queued fragments has limitation, depending on the platform The total number of concurrent fragment processing for different packet has

limitations depending on platform

Guidance

The evaluator shall verify that the operational guidance describes packets that are discarded and potentially logged by default. If applicable protocols are identified, their descriptions need to be consistent with the TSS. If logging is configurable, the evaluator shall verify that applicable instructions are provided to configure auditing of automatically rejected packets.

Section 5 (Configuring Traffic Filtering Rules) of the Evaluated Configuration Guide (Ref. [11]) identifies the default firewall rules that must be in place for the TOE to be operating in the evaluated configuration. The TOE will, by default, automatically drop and log the following packets:

Invalid fragments;

Fragmented IP packets that cannot be reassembled completely;

Where the source address is equal to the address of the network interface;

Where the source address does not belong to the networks associated with the network interface;

Where the source address is defined as being on a broadcast network;

Where the source address is defined as being on a multicast network;

Where the source address is defined as being a loopback address;

Where the source address is a multicast packet;

Where the source or destination address is a link-local address;

Where the source or destination address is defined as being an address “reserved for future use” as specified in RFC 5735 for IPv4;

Where the source or destination address is defined as an “unspecified address” or an address “reserved for future definition and use” as specified in RFC 3513 for IPv6; and

With the IP option Loose Source Routing, Strict Source Routing, or Record Route is specified

The guidance provides administrators with the CLI commands necessary to configure the TOE to enforce these rules and match matching traffic.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

The evaluator shall test each of the conditions for automatic packet rejection in turn. In each case, the TOE should be configured to allow all network traffic and the evaluator shall generate a packet or packet fragment that is to be rejected. The evaluator shall use packet captures to ensure that the unallowable packet or packet fragment is not passed through the TOE.

For each of the cases above, the evaluator shall use any applicable guidance to enable rejected packet logging. In each case above, the evaluator shall ensure that the rejected packet or packet fragment was appropriately logged.

The evaluators generated numerous tests to exercise each of the default reject rules. The evaluators confirmed that, even when all traffic is permitted, traffic matching the default reject rules was still dropped by the TOE. The evaluators confirmed that the TOE logged each event appropriately.

2.9.1.9 FFW_RUL_EXT.1.9

TSS

The evaluator shall verify that the TSS describes the algorithm applied to incoming packets, including the processing of default rules, determination of whether a packet is part of an established session, and application of administrator defined and ordered ruleset.

JUNOS is composed of a number of separate executables, or daemons. If a failure occurs in the “flow” daemon (flowd) causing it to halt, no packet processing will occur and no packets will be forwarded. A failure in another daemon will not prevent the flow daemon from enforcing the policy rule set. The Information Flow subsystem is responsible for processing the arriving packets from the network to the TOE's network interface. Based on Administrator-configured policy, interface and zone information, the packet flows through the various modules of the Information Flow subsystem. Rules within policies are processed in an Administrator-defined order when network traffic flows through the TOE network interfaces. By default, the TOE behavior is to deny packets when there is no rule match unless another required condition allows the network traffic If a security risk is found in the packet. e.g. denial-of-service attacks, the packet is dropped and an event is logged. The packet does not continue to the next module for processing. If the packet is not dropped by a given module, the interrupt handling routine calls the function for the next relevant module.

Guidance

The evaluator shall verify that the operational guidance describes how the order of stateful traffic filtering rules is determined and provides the necessary instructions so that an administrator can configure the order of rule processing.

The evaluator has identified the following relevant information in the CLI User Guide (Ref. [12]): “[..] there are a few cases where the ordering of the statements matters because the configuration statements create a sequence that is analyzed in order. For example, in a routing policy or firewall filter, you define terms that are analyzed sequentially.” If an administrator wishes to change the order in which policies are enforced, the following command can be used: insert <statement‐path> identifier1 (before | after) identifier2

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

The evaluator shall devise two equal stateful traffic filtering rules with alternate operations – permit and deny. The rules should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first rule is enforced in both cases by generating applicable packets and using packet capture and logs for confirmation.

The evaluator shall repeat the procedure above, except that the two rules should be devised where one is a subset of the other (e.g., a specific address vs. a network segment). Again, the evaluator should test both orders to ensure that the first is enforced regardless of the specificity of the rule.

The evaluators devised a pair of rule with permit and deny reactions. The evaluators deployed these rules in distinct orders and confirmed that the TOE enforced the rules in the configured order. The evaluators modified the rules so that they were a subset of each other. The evaluators confirmed that, as before, the TOE enforced the rules in the administrator-defined order.

2.9.1.10 FFW_RUL_EXT.1.10

TSS

The evaluator shall verify that the TSS describes the process for applying stateful traffic filtering rules and also that the behavior (either by default, or as configured by the administrator) is to deny packets when there is no rule match unless another required conditions allows the network traffic (i.e., FFW_RUL_EXT.1.6 or FFW_RUL_EXT.1.7).

If there is no policy to deny traffic, traffic that does not match any policy is dropped and not logged.

Guidance

The evaluator shall verify that the operational guidance describes the behavior if no rules or special conditions apply to the network traffic. If the behavior is configurable, the evaluator shall verify that the operational guidance provides the appropriate instructions to configure the behavior to deny packets with no matching rules.

Per the Evaluated Configuration Guide (Ref. [11]), if traffic is processed that does not match any other rule in place, the Default Deny-All rule will be enforced, which will drop and log the traffic. This rule is configured during the initial configuration of the TOE.

Testing See FFW_RUL_EXT.1.10 in the FWEP for a full definition of the testing requirements for this assurance component.

The evaluators configured a variety of firewall rules to test the protocols and attributes defined in the assurance activities for FFW_RUL_EXT.1.10. The evaluators confirmed that, for each test, the TOE behaved (permitted or denied traffic) and logged events as expected.

2.9.2 FPF_RUL_EXT.1 Packet filtering

2.9.2.1 FPF_RUL_EXT.1.1

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator shall verify that the TSS provide a description of the TOE’s initialization/startup process, which clearly indicates where processing of network packets begins to take place, and provides a discussion that supports the assertion that packets cannot flow during this process.

The evaluator shall verify that the TSS also includes a narrative that identifies the components (e.g., active entity such as a process or task) involved in processing the network packets and describes the safeguards that would prevent packets flowing through the TOE without applying the ruleset in the event of a component failure. This could include the failure of a component, such as a process being terminated, or a failure within a component, such as memory buffers full and cannot process packets.

The boot sequence of the TOE appliances also aids in establishing the securing domain and preventing tamping or bypass of security functionality. The following steps list the boot sequence for the TOE:

BIOS hardware and memory checks Loading and initialization of the FreeBSD Kernel OS FIPS self-tests and firmware integrity tests are executed The init utility is started (mounts file systems, sets up network cards to communicate

on the network, and generally starts all the processes that usually are run on a FreeBSD system at startup)

Daemon programs such as Internet Service Daemon (INETD), Routing Protocol Daemon (RPD), Syslogd are started; Routing and forwarding tables are initialized

Management Daemon (or MGD) is loaded, allowing access to management interface Physical interfaces are active

Once the interfaces are brought up, they will start to receive and send packets based on the current configuration (or not receive or send any packets if they have not been previously configured). Interfaces are brought up only after successful loading of kernel and Information Flow subsystems, and these interfaces cannot send or receive packets unless previously configured by an authorized administrator. JUNOS is composed of a number of separate executables, or daemons. If a failure occurs in the “flow” daemon (flowd) causing it to halt, no packet processing will occur and no packets will be forwarded. A failure in another daemon will not prevent the flow daemon from enforcing the policy rule set.


N/A

Testing

The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized. A steady flow of network packets that would otherwise be denied by the ruleset should be directed at the TOE’s interfaces, with packet sniffers listening to see if any network traffic is allowed through.

Please see the assurance results for FFW_RUL_EXT.1 (Section 2.9.1).

2.9.2.2 FPF_RUL_EXT.1.2

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS


RFC 791 (IPv4);

RFC 2460 (IPv6);

RFC 793 (TCP); and

RFC 768 (UDP).

The evaluator shall verify that the TSS describes how conformance with the identified RFCs has been determined by the TOE developer (e.g., third party interoperability testing, protocol compliance testing).

Table 7-3, provided in Section 7.10 of the Security Target (Ref. [10]), indicates that the above protocols are supported. Conformance to these RFCs is demonstrated by protocol compliance testing by the product QA team.

Guidance

The evaluator shall verify that the operational guidance indicates that the following protocols are supported:

RFC 791 (IPv4);

RFC 2460 (IPv6);

RFC 793 (TCP); and

RFC 768 (UDP)

The guidance will describe the other protocols contained within the ST (e.g., IPsec, IKE, potentially HTTPS, SSH, and TLS) that are processed by the TOE. The evaluator ensures it is made clear what protocols were not considered as part of the TOE evaluation.

Chapter 5 of the Evaluated Configuration Guide (Ref. [11]) lists the above protocols and their associated RFCs as being supported by the TOE.


N/A

2.9.2.3 FPF_RUL_EXT.1.3 / FPF_RUL_EXT.1.4 / FPF_RUL_EXT.1.5

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator shall verify that the TSS describes a packet filtering policy and the following attributes are identified as being configurable within packet filtering rules for the associated protocols:

ICMPv4

o Type

o Code

ICMPv6

o Type

o Code

IPv4

o Source address



IPv6

o Source address



TCP

o Source Port

o Destination Port

UDP

o Source Port

o Destination Port

The evaluator shall verify that each rule can identify the following actions: permit, deny, and log.

The evaluator shall verify that the TSS identifies all interface types subject to the packet filtering policy and explains how rules are associated with distinct network interfaces. Where interfaces can be grouped into a common interface type (e.g., where the same internal logical path is used, perhaps where a common device driver is used) they can be treated collectively as a distinct network interface.

Table 7-3, provided in Section 7.10 of the Security Target (Ref. [10]), indicates that the above protocols and attributes are supported and configurable within firewall rules. The TOE shall allow permit, deny, and log operations to be associated with rules and these rules can be assigned to distinct network interfaces. The TOE is configured to associate network interfaces to IP subnets. Source IP addresses are then associated with the network interface.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

The evaluators shall verify that the operational guidance identifies the following attributes as being configurable within packet filtering rules for the associated protocols:

ICMPv4

o Type

o Code

ICMPv6

o Type

o Code

IPv4

o Source address



IPv6

o Source address



TCP

o Source Port

o Destination Port

UDP

o Source Port

o Destination Port

The evaluator shall verify that the operational guidance indicates that each rule can identify the following actions: permit, deny, and log.

The evaluator shall verify that the operational guidance explains how rules are associated with distinct network interfaces.

The evaluator shall verify that the operational guidance explains how to determine the interface type of a distinct network interface (e.g., how to determine the device driver for a distinct network interface).

Chapter 5 of the Evaluated Configuration Guide (Ref. [11]) lists the protocols and fields above as being configurable within packet filtering rules. Chapter 6 (Configuring Security Flow Policies) indicates that the following actions can be tied to each security flow policy:

Bypass—The Permit option directs the traffic traversing the device through the stateful firewall inspection, but not through the IPsec VPN tunnel.

Discard—The Deny option inspects and drops all packets that do not match any Permit policies.

Protect—The traffic is routed through an IPsec tunnel based on the combination of route lookup and Permit policy inspection.

Log—This option logs traffic and session information for all the modes mentioned above

Per Chapter 6, each firewall rule is associated with a security zone (trustLan, untrustLan, etc.). These security zones are subsequently associated with a specific interface provided by the TOE.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Each interface provided by the TOE is prefixed by a character pattern (in this example, fe and ge), such as ge-0/0/1. The designator ge stands for Gigabit Ethernet, while fe stands for Fast Ethernet. The 0/0/1 after the type designator is in the format <pin/0/port>. This allows the administrator to determine the physical location on the device of the interface. The TOE also provides the se-pin/0/port designator for the serial port used for local administration.

Testing

The evaluator shall use the instructions in the operational guidance to test that packet filter rules can be created that permit, deny, and log packets for each of the following attributes:

ICMPv4

o Type

o Code

ICMPv6

o Type

o Code

IPv4

o Source address



IPv6

o Source address



TCP

o Source Port

o Destination Port

UDP

o Source Port

o Destination Port

Repeat the test assurance activity above to ensure that packet filtering rules can be defined for each distinct network interface type supported by the TOE.


2.9.2.4 FPF_RUL_EXT.1.6

TSS

The evaluator shall verify that the TSS describes the algorithm applied to incoming packets, including the processing of default rules, determination of whether a packet is part of an established session, and application of administrator defined and ordered ruleset.

The Information Flow subsystem is responsible for processing the arriving packets from the network to the TOE's network interface. Based on Administrator-configured policy, interface and zone information, the packet flows through the various modules of the Information Flow subsystem. Rules within policies are processed in an Administrator-defined order when network traffic flows through the TOE network interfaces. By default, the TOE behavior is to deny packets when there is no rule match unless another required condition allows the network traffic If a security risk is found in the packet. e.g. denial-of-service attacks, the packet is dropped and an event is logged - the packet does not continue to the next module for processing. If the packet is not dropped by a given module, the interrupt handling routine calls the function for the next relevant module.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

The evaluator shall verify that the operational guidance describes how the order of Packet filtering rules is determined and provides the necessary instructions so that an administrator can configure the order of rule processing.

The evaluator has identified the following relevant information in the CLI User Guide (Ref. [12]): “[…] the ordering of the statements matters because the configuration statements create a sequence that is analyzed in order. For example, in a routing policy or firewall filter, you define terms that are analyzed sequentially.” If an administrator wishes to change the order in which policies are enforced, the following command can be used: insert <statement‐path> identifier1 (before | after) identifier2

Testing

The evaluator shall devise two equal Packet filtering rules with alternate operations – permit and deny. The rules should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first rule is enforced in both cases by generating applicable packets and using packet capture and logs for confirmation.

The evaluator shall repeat the procedure above, except that the two rules should be devised where one is a subset of the other (e.g., a specific address vs. a network segment). Again, the evaluator should test both orders to ensure that the first is enforced regardless of the specificity of the rule.


2.9.2.5 FPF_RUL_EXT.1.7

TSS

The evaluator shall verify that the TSS describes the process for applying Packet filtering rules and also that the behavior (either by default, or as configured by the administrator) is to deny packets when there is no rule match unless another required conditions allows the network traffic (i.e., FPF_RUL_EXT.1.6 or FPF_RUL_EXT.1.7).

The Security Policy module examines traffic passing through the TOE (via Session Setup module) and determines if the traffic can pass based on administrator-configured access policies. The Security Policy module is the core of the firewall and IPS functionalities in the TOE: It is the policy enforcement engine that fulfills the security requirements for the user. The Security Policy module will deny packets when there is no policy match unless another policy allows the traffic. The Session Setup module performs the auditing of denied packets. If there is a policy to specifically deny traffic, traffic matching this deny policy is dropped and logged in traffic log. If there is no policy to deny traffic, traffic that does not match any policy is dropped and not logged. In either case, Session Setup module does not create any sessions for denied traffic. Sessions are created for allowed traffic.

Guidance

The evaluator shall verify that the operational guidance describes the behavior if no rules or special conditions apply to the network traffic. If the behavior is configurable, the evaluator shall verify that the operational guidance provides the appropriate instructions to configure the behavior to deny packets with no matching rules.

Per the Evaluated Configuration Guide (Ref. [11]), if traffic is processed that does not match any other rule in place, the Default Deny-All rule will be enforced, which will drop and log the traffic. This rule is configured during the initial configuration of the TOE.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing See FPF_RUL_EXT.1.7 in the VPNEP (Ref. [8]) for a full definition of the testing requirements for this assurance component.


FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2.10 Intrusion prevention system (IPS)

2.10.1 IPS_NTA_EXT.1 Network traffic analysis

2.10.1.1 IPS_NTA_EXT.1.1

TSS

The evaluator shall verify that the TSS explains the TOE’s capability of analyzing IP traffic in terms of the TOE’s policy precedence hierarchy order.

The TSS should identify if the TOE’s policy hierarchy order is configurable by the administrator for IPS policy elements (known-good lists, known-bad lists, signature-based rules, and anomaly-based rules).

Regardless of whether the precedence is configurable, the evaluator shall verify that the TSS describes the default precedence as well as the IP analyzing functions supported by the TOE.

An IDP policy is made up of rule bases, and each rule base contains a set of rules that specify rule parameters, such as traffic match conditions, action, and logging requirements. IDP policies can then be associated to firewall policies. IDP can be invoked on a firewall rule by rule basis for maximum granularity. Only firewall policies marked for IDP will be processed by IDP engine, all other rules will only be processed by the firewall.

Guidance

The evaluator shall verify that the guidance describes the default precedence.

If the precedence is configurable. The evaluator shall verify that the guidance explains how to configure the precedence.

IDP policies are attached to security flow policies – as such, the precedence assigned to IDP policies is dependent on the order in which the underlying flow policies are arranged (see similar entry for the FWEP guidance requirements).


N/A

2.10.1.2 IPS_NTA_EXT.1.2

TSS


IPv4

IPv6

ICMPv4

ICMPv6

TCP

UDP

The evaluator shall verify that the TSS describes how conformance with the identified protocols has been determined by the TOE developer. (e.g., third party interoperability testing, protocol compliance testing).

Table 7-3, provided in Section 7.10 of the Security Target (Ref. [10]), indicates that the above protocols are supported. Conformance to these RFCs is demonstrated by protocol compliance testing by the product QA team.


N/A


N/A

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

2.10.1.3 IPS_NTA_EXT.1.3

TSS

The evaluator shall verify that the TSS identifies all interface types capable of being deployed in the modes of promiscuous, and or inline mode as well as the interfaces necessary to facilitate each deployment mode (at a minimum, the interfaces need to support inline mode). The TSS should also provide descriptions how the management interface is distinct from sensor interfaces.

The TOE is capable of inspecting all traffic passing through the TOE’s Ethernet interfaces (inline mode). Ethernet interfaces can be assigned to Zones on which firewall and IDP policies are predicated. The TOE supports management through the console port, as well as through a dedicated Ethernet management port whose traffic is never processed for routing.

Guidance

The evaluator shall verify that the operational guidance provides instructions on how to deploy each of the deployment methods outlined in the TSS.

The evaluator shall also verify that the operational guidance provides instructions of applying IPS policies to interfaces for each deployment mode.

If the management interface is configurable the evaluator shall verify operational guidance explains how to configure the interface into a management interface.

The evaluator shall verify that the operational guidance explains how the TOE sends commands to remote traffic filtering devices.

As the TOE only supports inline mode for all Ethernet interfaces, no configuration is required to place the interface into inline mode. The out-of-band Ethernet port provided on some SRX-series devices and the console port are not subject to traffic inspection and, therefore, are exempt from IDP policy. Ethernet ports may be used for remote management and, as mentioned above, are always operating in inline mode.


N/A

2.10.2 IPS_IPB_EXT.1 IP blocking

TSS

The evaluator shall verify how good / bad lists affect the way in which traffic is analyzed with respect to processing packets. The TSS should also provide detail with the attributes that create a known good list, a known bad list, their associated rules, including how to define the source or destination IP address (e.g. a single IP address or a range of IP addresses).

The evaluator shall also verify that the TSS identifies all the roles and level of access for each of those roles that have been specified in the requirement.

The TOE supports the definition of known-good and known-bad lists of source and/or destination addresses at the firewall rule level. Address ranges can be defined by creating address book entries and attaching them to firewall policies.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance The evaluator shall verify that the administrative guidance provides instructions with how each role specified in the requirement can create, modify and delete the attributes of a known good and known bad lists.

While the TOE does not explicitly define “good” and “bad” lists for network traffic, the TOE permits the creation of security flow policies based on entries in the TOE address book – these entries may be specific hosts, a range of addresses or entire subnets, which are then tied to security zones. The administrator may then create security flow policies indicating that traffic from Subnet A to Host B is permitted, while traffic from Subnet A to Subnet B is blocked (or vice-versa).

Testing

The evaluator shall use the instructions in the operational guidance to create a known-bad address list. Using a single IP address, a list of addresses or a range of addresses from that list, the evaluator shall attempt to send traffic through the TOE that would otherwise be allowed by the TOE and observe the TOE automatically drops that traffic.

The evaluator shall use the instructions in the operational guidance to create a known-good address list. Using a single IP address, a list of addresses or a range of addresses from that list, the evaluator shall attempt to send traffic that would otherwise be denied by the TOE and observe the TOE automatically allowing traffic.

The evaluator shall add conflicting IP addresses to each list and ensure that the TOE handles conflicting traffic in a manner consistent with the precedence in IPS_NTA_EXT.1.1.

The TOE configured security policies to both allow and deny traffic from certain subnets. The evaluators confirmed that, upon receiving traffic that matched these policies, the TOE reacted as configured (permitting or dropping the traffic). The evaluators configured conflicting policies and confirmed that the TOE enforces policies in the administrator-defined order.

2.10.3 IPS_SBD_EXT.1 Signature-based IPS functionality

2.10.3.1 IPS_SBD_EXT.1.1 / IPS_SBD_EXT.1.5

TSS

The evaluator shall verify that the TSS describes what is comprised within a signature rule.

The evaluator shall verify that each signature can be associated with a reactions specified in IPS_SBD_EXT.1.5.

The evaluator shall verify that the TSS identifies all interface types capable of applying signatures and explains how rules are associated with distinct network interfaces.

Where interfaces can be grouped into a common interface type (e.g., where the same internal logical path is used, perhaps where a common device driver is used) they can be treated collectively as a distinct network interface.

Signatures can be defined to match the any of supported header-field values, using the command “set security idp custom-attack”, along with the desire reaction, using the command “set security idp idp-policy”, that the TOE will perform when a match is found in the processed packets. The matching criteria can be "equal", "greater-than", "less-than" or "not-equal". Possible actions include allowing the traffic to pass or dropping the packet/connection.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

An IDP policy is made up of rule bases, and each rule base contains a set of rules that specify rule parameters, such as traffic match conditions, action, and logging requirements. IDP policies can then be associated to firewall policies. IDP can be invoked on a firewall rule by rule basis for maximum granularity. Only firewall policies marked for IDP will be processed by IDP engine, all other rules will only be processed by the firewall.

Close client and server (sends an RST packet to

both client and server)Guidance

The evaluator shall verify that the operational guidance provides instructions with how to create and/or configure rules using the following protocols and header inspection fields:

IPv4: Version; Header Length; Packet Length; ID; IP Flags; Fragment Offset; Time to Live (TTL); Protocol; Header Checksum; Source Address; Destination Address; and IP Options.

IPv6: Version; traffic class; flow label; payload length; next header; hop limit; source address; destination address; routing header; home address options.

ICMP: Type; Code; Header Checksum; and Rest of Header(varies based on the ICMP type and code).

ICMPv6: Type; Code; and Header Checksum.

TCP: Source port; destination port; sequence number; acknowledgement number; offset; reserved; TCP flags; window; checksum; urgent pointer; and TCP options.

UDP: Source port; destination port; length; and UDP checksum.

The evaluator shall verify that the operational guidance provides instructions with how to select and/or configure reactions specified in IPS_SBD_EXT.1.5 in the signature rules.

Both the Evaluated Configuration Guide and IDP Feature Guide (Refs. [11] and [15]), across all of the information provided, detail how to configure each of the fields listed above. In particular, the [edit security idp] Hierarchy Level component in Chapter 16 of the IDP Feature Guide provides the configuration hierarchy used when composing custom attack signatures, which includes all of the protocols and header inspection fields listed above.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

The evaluator shall use the instructions in the operational guidance to test that packet header signatures can be created and/or configured with the selected and/or configured reactions specified in IPS_SBD_EXT.1.5 for each of the attributes listed below. Each attribute shall be individually assigned to its own unique signature:

IPv4: Version; Header Length; Packet Length; ID; IP Flags; Fragment Offset; Time to Live (TTL); Protocol; Header Checksum; Source Address; Destination Address; and IP Options.

IPv6: Version; traffic class; flow label; payload length; next header; hop limit; source address; destination address; routing header; home address options.

ICMP: Type; Code; Header Checksum; and Rest of Header (varies based on the ICMP type and code).

ICMPv6: Type; Code; and Header Checksum;.

TCP: Source port; destination port; sequence number; acknowledgement number; offset; reserved; TCP flags; window; checksum; urgent pointer; and TCP options.

UDP: Source port; destination port; length; and UDP checksum.

Using packet sniffers, the evaluator will generate traffic to trigger a signature and using packet captures will ensure that the reactions of each rule are performed as expected.

Repeat the test assurance activity above to ensure that signature-based IPS policies can be defined for each distinct network interface type capable of applying signatures as supported by the TOE.

The evaluators configured custom attack signatures for each of the protocols and attributes listed above. The evaluators configured a variety of reactions and enabled logging for each attack signature. The evaluators confirmed that the TOE identified traffic matching each signature and reacted as configured.


TSS

The evaluator shall verify that the TSS describes what is comprised within a string-based detection signature.

The evaluator shall verify that each packet payload string-based detection signature can be associated with a reactions specified in IPS_SBD_EXT.1.5.

Signatures can be defined to match the any of supported header-field values, using the command “set security idp custom-attack”, along with the desire reaction, using the command “set security idp idp-policy”, that the TOE will perform when a match is found in the processed packets. The matching criteria can be "equal", "greater-than", "less-than" or "not-equal". Possible actions include allowing the traffic flow or dropping the packet/connection.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Guidance

The evaluator shall verify that the operational guidance provides instructions with how to configure rules using the packet payload string-based detection fields defined in IPS_SBD_EXT.1.2. The operational guidance shall provide configuration instructions, if needed, to detect payload across multiple packets.

The evaluator shall verify that the operational guidance provides instructions with how to configure reactions specified in IPS_SBD_EXT.1.5 for each string-based detection signature.

The evaluator shall verify that the operational guidance provides instructions with how rules are associated with distinct network interfaces that are capable of being associated with signatures.

The guidance documentation (Refs. [11] and [15]) provides sufficient information to allow administrators to configure the detection patterns specified in the requirement. For example, the following command can be used to specify a text string in ICMPv4 packet data: set security idp custom‐attack icmp_packet_data attack‐type signature pattern .*test_string.*

The TOE supports the definition of these detection patterns for each of the fields specified in IPS_SBD_EXT.1.2 Both the Evaluated Configuration Guide and IDP Feature Guide, across all of the information provided, detail how to configure each of the reactions listed in the ST. In particular, the rule (Security IPS Rulebase) section of Chapter 16 of the IDP Feature Guide provides administrators with the command syntax to configure each of the reactions specified in IPS_SBD_EXT.1.5. IDP/IPS rules are part of an IDP Policy. Each IDP Policy is attached to a Security Flow Policy, which is in turn tied to a specific Security Zone. These zones are attached to one or more interfaces. Once a zone is tied to an interface, all policies, rules, etc. applicable to that zone are enforced on the associated interface.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

The evaluator shall use the instructions in the operational guidance to test that packet payload string-based detection rules can be assigned to the reactions specified in IPS_SBD_EXT.1.5 using the attributes specified in IPS_SBD_EXT.1.2. However it is not required (nor is it feasible) to test all possible strings of protocol data, the evaluator shall ensure that a selection of strings in the requirement is selected to be tested. At a minimum at least one string using each of the following attributes from IPS_SBD_EXT.1.2 should be tested for each protocol. The evaluator shall generate packets that match the string in the rule and observe the corresponding reaction is as configured.

Test at least one string of characters for ICMPv4 data: beyond the first 4 bytes of the ICMP header.

Test at least one string of characters for ICMPv6 data: beyond the first 4 bytes of the ICMP header.

TCP data (characters beyond the 20 byte TCP header):

o Test at least one FTP (file transfer) command: help, noop, stat, syst, user, abort, acct, allo, appe, cdup, cwd, dele, list, mkd, mode, nlst, pass, pasv, port, pass, quit, rein, rest, retr, rmd, rnfr, rnto, site, smnt, stor, stou, stru, and type.

o ii) HTTP (web) commands and content:

Test both GET and POST commands

(2) Test at least one administrator-defined strings to match URLs/URIs, and web page content.

o iii) Test at least one SMTP (email) state: start state, SMTP commands state, mail header state, mail body state, abort state.

o iv) Test at least one string in any additional attribute type defined within [selection: [assignment: other types of TCP payload inspection];

Test at least one string of UDP data: characters beyond the first 8 bytes of the UDP header;

Test at least one string for each additional attribute type defined in [assignment: other types of packet payload inspection]]

The evaluator shall repeat one of the tests in Test 1 but generate multiple non-fragmented packets that contain the string in the rule defined.

Repeat the test assurance activity above to ensure that signature-based IPS policies can be defined for each distinct network interface type capable of applying signatures as supported by the TOE.

The evaluators configured custom attack signatures for each of the protocols and characteristics listed above. The evaluators configured a variety of reactions and enabled logging for each attack signature. The evaluators confirmed that the TOE identified traffic matching each signature and reacted as configured.


TSS The evaluator shall verify that the TSS describes how the attacks defined in IPS_SBD_EXT.1.3 are processed by the TOE and what reaction is triggered when these attacks are identified.

The TOE is capable of detecting the following signatures using Junos predefined screen options:

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

IPS EP signature name Junos screen name

IP Fragments Overlap (Teardrop attack, Bonk attack, or Boink attack)

ip tear-drop

IP source address equal to the IP destination (Land attack)

tcp land

Fragmented ICMP Traffic (e.g. Nuke attack)

icmp fragment

Large ICMP Traffic (Ping of Death attack)

icmp ping-death

TCP NULL flags tcp tcp-no-flag

TCP SYN+FIN flags tcp syn-fin

TCP FIN only flags tcp fin-no-ack

UDP Bomb Attack udp length-error

ICMP flooding (Smurf attack, and ping flood)

icmp flood

TCP flooding (e.g. SYN flood) tcp syn-flood

The default action for the above screens is to drop the packets. To allow the packets through, the “alarm-without-drop” action can be defined using the command “set security screen ids-option”.

Guidance The evaluator shall verify that the operational guidance provides instructions with configuring rules to identify the attacks defined in IPS_SBD_EXT.1.3 as well as the reactions to these attacks as specified in IPS_SBD_EXT.1.5.

The IPS Guidance Annex (Ref. [19]) provides guidance on configuring each of the security screens relevant to the attacks specified in IPS_SBD_EXT.1.3. The default behaviour of these screens is to drop matching traffic – the TOE can be configured to allow this traffic is desired by the administrator. The TOE automatically logs all events matching the events specified and this does not require any further configuration by the administrator.

Testing

The evaluator shall create and/or configure rules for each attack signature in IPS_SBD_EXT.1.3. For each attack, the TOE should apply its corresponding signature and enable it to each distinct network interface type capable of applying the signatures.

The evaluator shall use packet captures to ensure that the attack traffic is detected by the TOE and a reaction specified in IPS_SBD_EXT.1.5 is triggered and stops the attack. Each attack should be performed one after another so as to ensure that its corresponding signature successfully identified and appropriately reacted to a particular attack.

The evaluators configured custom attack signatures for each of the attack signatures listed in IPS_SBD_EXT.1.3. The evaluators configured a variety of reactions and enabled logging for each attack signature. The evaluators confirmed that the TOE identified traffic matching each signature and reacted as configured.


TSS The evaluator shall verify that the TSS describes how the attacks defined in IPS_SBD_EXT.1.4 are processed by the TOE and what reaction is triggered when these attacks are identified.

The TOE is capable of detecting the following signatures using Junos predefined screen options:

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

IPS EP signature name Junos screen name

IP protocol scanning ip unknown-protocol

TCP port scanning tcp port-scan

UDP port scanning udp port-scan

ICMP scanning icmp ip-sweep

The TOE is also capable of detecting the following signatures: TCP SYN+RST flags, by defining an custom attack to match “protocol tcp tcp-flags

rst” and “protocol tcp tcp-flags syn”; UDP Chargen DoS attack , by configuring a firewall policy to match the predefined

“junos-chargen” with the desired allow/block reaction; Flooding of a network (DoS attack), by the configuration of policers that allow

establishing prioritization and bandwidth limits for different type of network traffic.

The default action for the above screens is to drop the packets. To allow the packets through, the “alarm-without-drop” action can be defined using the command “set security screen ids-option”.

Guidance The evaluator shall verify that the operational guidance provides instructions with configuring rules to identify the attacks defined in IPS_SBD_EXT.1.4 as well as the reactions to these attacks as specified in IPS_SBD_EXT.1.5.

The IPS Guidance Annex (Ref. [19]) provides guidance on configuring each of the security screens relevant to the attacks specified in IPS_SBD_EXT.1.4. The default behaviour of these screens is to drop matching traffic – the TOE can be configured to allow this traffic is desired by the administrator. The TOE automatically logs all events matching the events specified and this does not require any further configuration by the administrator.

Testing

The evaluator shall configure individual signatures for each attack in IPS_SBD_EXT.1.4. For each attack, the TOE should apply its corresponding signature and enable it to each distinct network interface type capable of applying signatures.

The evaluator shall use packet captures to ensure that the attack traffic is detected by the TOE and a reaction specified in IPS_SBD_EXT.1.5 is triggered and stops the attack. Each attack should be performed one after another so as to ensure that its corresponding signature successfully identified and appropriately reacted to a particular attack.

The evaluators configured custom attack signatures for each of the attack signatures listed in IPS_SBD_EXT.1.4. The evaluators configured a variety of reactions and enabled logging for each attack signature. The evaluators confirmed that the TOE identified traffic matching each signature and reacted as configured.

2.10.4 IPS_ABD_EXT.1 Anomaly-based IPS functionality

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

TSS

The evaluator shall verify that the TSS describes the composition, construction, and application of baselines or anomaly-based attributes specified in IPS_ABD_EXT.1.1.

The evaluator shall verify that the TSS provides a description of how baselines are defined and implemented by the TOE, or a description of how anomaly-based rules are defined and configured by the administrator.

The evaluator shall verify that each baseline or anomaly-based rule can be associated with a reaction specified in IPS_ABD_EXT.1.3.

The evaluator shall verify that the TSS identifies all interface types capable of applying baseline or anomaly-based rules and explains how they are associated with distinct network interfaces. Where interfaces can be grouped into a common interface type (e.g., where the same internal logical path is used, perhaps where a common device driver is used) they can be treated collectively as a distinct network interface.

The TOE allows administrators to define signatures for anomalous traffic in terms of throughput (bits per second) and time of the day for defined source/destination address and source/destination port. Anomaly signatures based on time of day characteristics are implemented by configuring schedulers using the Junos command ‘set schedulers’ and attaching them to firewall policies, which in turn specify the target traffic in terms of IP addresses and port numbers as well as the action to be perform on signature triggering (allow or block/drop traffic). IDP/IPS rules are part of an IDP Policy. Each IDP Policy is attached to a Security Flow Policy, which is in turn tied to a specific Security Zone. These zones are attached to one or more interfaces. Once a zone is tied to an interface, all policies, rules, etc. applicable to that zone are enforced on the associated interface.

Guidance

The evaluator shall verify that the operational guidance provides instructions with how to manually create baselines or anomaly-based rules according to the selections made in IPS_ABD_EXT.1.1. Note that dynamic “profiling” of a network to establish a baseline is outside the scope of this PP.

The evaluator shall verify that the operational guidance provides instructions to associate reactions specified in IPS_ABD_EXT.1.3 with baselines or anomaly-based rules.

The evaluator shall verify that the operational guidance provides instructions to associate the different policies with distinct network interfaces.

Per the IPS Guidance Annex (Ref. [19]): For time-of-day baselines/detection, administrators may configure schedulers. These allow administrators to only allow traffic flows at specific times of the day. Depending on the configuration, traffic within (or outside of) these schedules will be handled as configured. For throughput-based baselines/detection, administrators may configure policers/bandwidth limiters for each interface provided by the TOE. These policers will automatically drop (unless otherwise configured) traffic that exceeds a pre-determined maximum throughput.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

Testing

The evaluator shall use the instructions in the operational guidance to configure baselines or anomaly-based rules for each attributes specified in IPS_ABD_EXT.1.1. The evaluator shall send traffic that does not match the baseline or matches the anomaly-based rule and verify the TOE applies the configured reaction. This shall be performed for each attribute in IPS_ABD_EXT.1.1.

Repeat the test assurance activity above to ensure that baselines or anomaly-based rules can be defined for each distinct network interface type supported by the TOE.

The evaluators configured custom attack signatures/policies for each of the attributes specified in IPS_ABD_EXT.1.1. The evaluators configured different reactions (permit/deny) and enabled logging for each attack policy. The evaluators confirmed that the TOE identified the anomalous traffic and reacted as configured.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

3 PROTECTION PROFILE SAR ASSURANCE ACTIVITIES The following section addresses each of the assurance activities that correspond to the SARs claimed in the Security Target (Ref. [10]).

3.1 Development (ADV)

3.1.1 Basic functional specification (ADV_FSP.1)

Assurance activities

There are no specific assurance activities associated with these SARs. The functional specification documentation is provided to support the evaluation activities described in Section 4.2, and other activities described for AGD, ATE, and AVA SARs.

The requirements on the content of the functional specification information is implicitly assessed by virtue of the other assurance activities being performed; if the evaluator is unable to perform an activity because the there is insufficient interface information, then an adequate functional specification has not been provided.

N/A

3.2 Guidance documentation (AGD)

3.2.1 Operational user guidance (AGD_OPE.1)


Some of the contents of the operational guidance will be verified by the assurance activities in Section 4.2 and evaluation of the TOE according to the CEM. The following additional information is also required.

The operational guidance shall at a minimum list the processes running (or that could run) on the TOE in its evaluated configuration during its operation that are capable of processing data received on the network interfaces (there are likely more than one of these, and this is not limited to the process that "listens" on the network interface). It is acceptable to list all processes running (or that could run) on the TOE in its evaluated configuration instead of attempting to determine just those that process the network data.

For each process listed, the administrative guidance will contain a short (e.g., one- or two-line) description of the process' function, and the privilege with which the service runs. "Privilege" includes the hardware privilege level (e.g., ring 0, ring 1), any software privileges specifically associated with the process, and the privileges associated with the user role the process runs as or under.

The evaluators examined the SRX Running Processes document (Ref. [18]) and determined that it provided a list of the processes running on the TOE during its evaluated configuration. Each process is listed by name, a description of its purpose and functionality is provided and the level of privilege at which the service runs is identified.


The operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE.

No configuration of the cryptographic engine is required by TOE users, therefore no guidance pertinent to this requirement is provided.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE


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

1. For hashes, a description of where the hash for a given update can be obtained. For digital signatures, instructions for obtaining the certificate that will be used by the FCS_COP.1(2) mechanism to ensure that a signed update has been received from the certificate owner. This may be supplied with the product initially, or may be obtained by some other means.

2. Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory).

3. Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes generation of the hash/digital signature.

The Junos Installation and Upgrade Guide (Ref. [13]) provides TOE administrators with information on the upgrade process for the TOE, including the mechanisms used to verify updates, how updates are obtained and how to initiate the upgrade process.


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

The CCECG (Ref. [11]) identifies the CC documents to which the TOE is conformant (PP/EPs) and the functionality provided by the TOE which was included in the scope of the evaluation.

3.2.2 Preparative procedures (AGD_PRE.1)


Some of the contents of the operational guidance will be verified by the assurance activities in Section 4.2 and evaluation of the TOE according to the CEM. The following additional information is also required.

The operational guidance shall at a minimum list the processes running (or that could run) on the TOE in its evaluated configuration during its operation that are capable of processing data received on the network interfaces (there are likely more than one of these, and this is not limited to the process that "listens" on the network interface). It is acceptable to list all processes running (or that could run) on the TOE in its evaluated configuration instead of attempting to determine just those that process the network data.

For each process listed, the administrative guidance will contain a short (e.g., one- or two-line) description of the process' function, and the privilege with which the service runs. "Privilege" includes the hardware privilege level (e.g., ring 0, ring 1), any software privileges specifically associated with the process, and the privileges associated with the user role the process runs as or under.

The guidance provided by the developer is pertinent to all hardware platforms specified in the ST, as the command syntax and performance of the TOE is identical, regardless of platform used.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

3.3 Lifecycle support (ALC)

3.3.1 Labelling of the TOE (ALC_CMC.1)


The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST.

The evaluator shall ensure that this identifier is sufficient for an acquisition entity to use in procuring the TOE (including the appropriate administrative guidance) as specified in the ST.

Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST.

If the vendor maintains a web site advertising the TOE, the evaluator shall examine the information on the web site to ensure that the information in the ST is sufficient to distinguish the product.

The evaluators verified that the TOE reference used is consistent across the TOE and associated documentation.

3.3.2 TOE CM coverage (ALC_CMS.1)


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

By ensuring that the TOE is specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component.

The evaluators verified that ALC_CMC.1 is satisfied, hence ALC_CMS.1 is also satisfied.

3.4 Testing (ATE)

3.4.1 Independent testing – conformance (ATE_IND.1)

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE


The evaluator shall prepare a test plan and report documenting the testing aspects of the system.

The test plan covers all of the testing actions contained in the CEM and the body of this PP’s Assurance Activities.

While it is not necessary to have one test case per test listed in an Assurance Activity, the evaluator must document in the test plan that each applicable testing requirement in the ST is covered.

The test plan identifies the platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification must address the differences between the tested platforms and the untested platforms, and make an argument that the differences do not affect the testing to be performed.

It is not sufficient to merely assert that the differences have no affect; rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary.

The test plan describes the composition of each platform to be tested, and any setup that is necessary beyond what is contained in the AGD documentation.

It should be noted that the evaluator is expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. This may include special test drivers or tools.

For each driver or tool, an argument (not just an assertion) should be provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform. This also includes the configuration of the cryptographic engine to be used.

The cryptographic algorithms implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated (IPsec, TLS/HTTPS, SSH).

The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results.

The test report (which could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful rerun of the test, the report would show a “fail” and “pass” result (and the supporting details), and not just the “pass” result.

The evaluators developed a detailed test report for each PP/EP to address all aspects of this requirement (EFS-T041-TR-NDPP, EFS-T041-TR-FWEP, EFS-T041-TR-VPNEP and EFS-T041-TR-IPSEP (Refs. [21], [22], [23] and [24])). The TRs discuss the test configuration, test cases, expected results and actual results.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE

3.5 Vulnerability assessment (AVA)

3.5.1 Vulnerability survey (AVA_VAN.1)


As with ATE_IND, the evaluator shall generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document.

The evaluator performs a search of public information to determine the vulnerabilities that have been found in network infrastructure devices and the implemented communication protocols in general, as well as those that pertain to the particular TOE.

The evaluator documents the sources consulted and the vulnerabilities found in the report. For each vulnerability found, the evaluator either provides a rationale with respect to its nonapplicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable.

Suitability is determined by assessing the attack vector needed to take advantage of the vulnerability. For example, if the vulnerability can be detected by pressing a key combination on boot-up, a test would be suitable at the assurance level of this PP. If exploiting the vulnerability requires expert skills and an electron microscope, for instance, then a test would not be suitable and an appropriate justification would be formulated.

The vulnerability analysis performed by the evaluators is detailed in the NDPP Test Report (EFS-T041-TR-NDPP, Ref. [21]). The vulnerability analysis includes the mandatory testing prescribed by the FWEP.

FOR PUBLIC RELEASE



FOR PUBLIC RELEASE


The evaluator shall generate network packets that cycle through all of the values for attributes, Type, Code, and Transport Layer Protocol, that are undefined by the RFC for each of the protocols, ICMPv4, ICMPv6, IPv4, and IPv6. For example, ICMPv4 has an eight-byte field for Type and an eight-byte field for the Code. Only 21 Types are defined in the RFC (see table 4-2), but there are 256 possible value. Each Type has a Code associated with it, the number of RFC defined Codes varies based on the Type. The evaluator is required to construct packets that exercise each possible value not defined in the RFC (the defined values are already tested in FFW_RUL_EXT.1.10) of Type and Code (including all possible combinations) and target each distinct interface type to determine that the TOE handles these packets appropriately. Since none of these packets will match a rule, or belong to an allowed session the packets should be dropped. Since there are no requirements that the firewall audit a packet being dropped under these circumstances, the evaluator shall ensure the firewall does not allow these packets to flow through the TOE.

In addition to the undefined attribute testing required above, the evaluator shall perform intelligent fuzz testing of the remaining fields in the required protocol headers (excluding FTP). The intent of intelligent fuzzing is that a packet that is otherwise correctly constructed, such that it will be denied when the ruleset is applied, has random values inserted into each of the protocol header fields. The evaluator ensures a statistically significant sample size, which will vary depending on the protocol field length, is used and is justified in their report.

The evaluator should consult whatever diagnostics (e.g., logging, process status, interface errors) the TOE offers to determine if the TOE was adversely impacted by the processing of such packets.

The vulnerability analysis performed by the evaluators is detailed in the NDPP Test Report (EFS-T041-TR-NDPP, Ref [21]). The vulnerability analysis includes the mandatory testing prescribed by the FWEP.

---- END OF DOCUMENT ----

assurance activity report - niap-ccevs.org · assurance activity report -junos 12.3 ... unos® os...

Documents