. van; env teers yaaa munie < : us, KoAAOAAT-aTmureo«m avyvaead v : Aa: KATOAVOAYATATmam« emna< ® « vaan VERYAYYAAN a aa mre . . . - ek th O APP AP AAP OM MOMP 5 @ral .. "OO OH «> «AP ATon . .. AED AADO «AD OAH A «HE AOAA| Evaluation Technical Report (Base) Evaluation Technical Report Criteria Methodology Developer Evaluation facility Security Target Junos OS 19.2R1 for SRX300, SRX320, SRX340, SRX345, SRX345-DUAL-AC, SRX550M, SRX5400, SRX5600 and SRX5800 Series, v3.2, dated 14 June 2019 Security Target Junos OS 19.2R1 for SRX1500, SRX4100, SRX4200 and SRX4600 Series, v3.2, dated 14 June 2019 Evaluation Technical Report v1.0, dated 09 September 2019 Document reference EFT-T002-ETR 1.0 Evaluation Technical Report v1.0, dated 22 September 2019 Document reference EFT-T006-ETR 1.0 Common Criteria for Information Technology Security Evaluation Part 2 Extended and Part 3 Conformant, April 2017, Version 3.1 Rev5 Common Methodology for Information Technology Security, April 2017 Version 3.1 Rev5 Network international Technical Community Teron Labs, Level 7, 221 London Circuit, Canberra, ACT 2601, Australia The NDcPP contains a set of ‘base’ requirements that all conformant STs must include, and additionally contains ‘optional’ and ‘selection-based’ requirements. Optional requirements may or may not be included within the scope of the evaluation, depending on whether the vendor provides that functionality within the tested product and chooses to include it inside the TOE boundary. Selection-based requirements are those that must be included based upon the selections made in the base requirements and the capabilities of the TOE. Because the STs contain material drawn directly from the NDcPP, performance of the majority of the ASE work units serves to satisfy the APE work units as well. Where this is not the case, the evaluation facility performed the outlying APE work units as part of this evaluation. Additionally, where possible, the evaluation of NDcPP v2.1 leverages analyses from the evaluation of NDcPP v2.0E [6], which are assumed to have been performed correctly. This approach is in agreement with Section 9.2.1 (‘Re-using the evaluation results of certified PPs’) of the CEM [3]. cyber.gov.au Birnen ed ana. sens cae Lee ss ea ape su „.oon«>» tne a am ares NDcPP description Overview The NDcPP describes security requirements for network-based devices, which in the context of this PP are defined as both hardware and software devices that are connected to the network and have an infrastructure role within the network. The TOE may be standalone or distributed, where a distributed TOE is one that requires multiple distinct components to operate as a logical whole in order to fulfil the requirements of the PP. The NDcPP provides a minimal baseline of security requirements that are targeted at mitigating well defined and described threats in the following functional areas: © Security Audit Cryptographic Support © Identification and Authentication e Security Management + Protection of the TSF + TOE Access e Trusted Path/Channels + = Communication (optional) Security Problem Description, Objectives and Extended Components Threats The NDcPP defines a set of threats, assumptions and OSPs to be included in the ST of a compliant TOE. Threats are defined in terms of a threat agent, asset and adverse action. The following table lists the applicable threats defined in the NDcPP. Threat Name Threat Definition T.UNAUTHORIZED_ADMINISTRATOR_ACCESS Threat agents may attempt to gain Administrator access to the network device by nefarious means such as masquerading as an Administrator to the device, masquerading as the device to an Administrator, replaying an administrative session (in its entirety, or selected portions), or performing man-in-the-middle attacks, which would provide access to the administrative session, or sessions between network devices. Successfully gaining Administrator access allows malicious actions that compromise the security functionality of the device and the network on which it resides. T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic algorithms or perform a cryptographic exhaust against the key space. Poorly chosen encryption algorithms, modes, and key sizes will allow attackers to compromise the algorithms, or brute force exhaust cyber.gov.au ee eee as pers. Vmware @avre en we sees ss the key space and give them unauthorized access allowing them to read, manipulate and/or control the traffic with minimal effort. T.UNTRUSTED_COMMUNICATION_CHANNELS Threat agents may attempt to target network devices that do not use standardized secure tunnelling protocols to protect the critical network traffic. Attackers may take advantage of poorly designed protocols or poor key management to successfully perform man- in-the-middle attacks, replay attacks, etc. Successful attacks will result in loss of confidentiality and integrity of the critical network traffic, and potentially could lead to a compromise of the network device itself. T.WEAK_AUTHENTICATION_ENDPOINTS Threat agents may take advantage of secure protocols that use weak methods to authenticate the endpoints — e.g. a shared password that is guessable or transported as plaintext. The consequences are the same as a poorly designed protocol, the attacker could masquerade as the Administrator or another device, and the attacker could insert themselves into the network stream and perform a man-in-the-middle attack. The result is the critical network traffic is exposed and there could be a loss of confidentiality and integrity, and potentially the network device itself could be compromised. T.UPDATE_COMPROMISE Threat agents may attempt to provide a compromised update of the software or firmware which undermines the security functionality of the device. Non-validated updates or updates validated using non-secure or weak cryptography leave the update firmware vulnerable to surreptitious alteration. T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change, and/or modify the security functionality of the network device without Administrator awareness. This could result in the attacker finding an avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the Administrator would have no knowledge that the device has been compromised. T.SECURITY_FUNCTIONALITY_COMPROMISE Threat agents may compromise credentials and device data enabling continued access to the network device and its critical data. The compromise of credentials includes replacing existing credentials with an attacker’s credentials, modifying existing credentials, or obtaining the Administrator or device credentials for use by the attacker. T.PASSWORD_CRACKING Threat agents may be able to take advantage of weak administrative passwords to gain privileged access to the device. Having privileged access to the device provides the attacker unfettered access to the network traffic and may allow them to take advantage of any trust relationships with other network devices. Bae er sss Beet teehee ta ee we Se ee ee ee eee cyber.gov.au Fe eke Doreen rer 604 seas Denen DAAD T.SECURITY_FUNCTIONALITY_FAILURE An external, unauthorized entity could make use of failed or compromised security functionality and might therefore subsequently use or abuse security functions without prior authentication to access, change or modify device data, critical network traffic or security functionality of the device. cyber.gov.au ee eee as pers. Vmware @avre eee we sees ss Assumptions The table below lists the assumptions about the operational environment of the TOE defined by the NDcPP. Assumption Name Assumption Definition A.PHYSICAL_PROTECTION The network device is assumed to be physically protected in its operational environment and not subject to physical attacks that compromise the security and/or interfere with the device’s physical interconnections and correct operation. This protection is assumed to be sufficient to protect the device and the data it contains. As a result, the cPP will not include any requirements on physical tamper protection or other physical attack mitigations. The cPP will not expect the product to defend against physical access to the device that allows unauthorized entities to extract data, bypass other controls, or otherwise manipulate the device. A.LIMITED_FUNCTIONALITY The device is assumed to provide networking functionality as its core function and not provide functionality/services that could be deemed as general purpose computing. For example, the device should not provide a computing platform for general purpose applications (unrelated to networking functionality). A.NO_THRU_TRAFFIC_PROTECTION A standard/generic network device does not provide any assurance regarding the protection of traffic that traverses it. The intent is forthe network device to protect data that originates on or is destined to the device itself, to include administrative data and audit data. Traffic that is traversing the network device, destined for another network entity, is not covered by the NDcPP. It is assumed that this protection will be covered by cPPs and PP-Modules for particular types of network devices (e.g., firewall). A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the network device are assumed to be trusted and to act in the best interest of security for the organization. This includes being appropriately trained, following policy, and adhering to guidance documentation. Administrators are trusted to ensure passwords/credentials have sufficient strength and entropy and to lack malicious intent when administering the device. The network device is not expected to be capable of defending against a malicious Administrator that actively works to bypass or compromise the security of the device. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are expected to fully validate (e.g. offline verification) any CA certificate (root CA certificate or intermediate CA certificate) loaded into the TOE’s trust store (aka ‘root store’, ' trusted CA Key Store’, or similar) as a trust anchor prior to use (e.g. offline verification). Bae er sss Beet teehee ta ee we Se ee ee ee eee cyber.gov.au Fe eke ... „eo oon«> seas Denen DAAD A.REGULAR_UPDATES A.ADMIN_CREDENTIALS_SECURE A.COMPONENTS_RUNNING A.RESIDUAL_INFORMATION Organisational Security Policies The network device firmware and software is assumed to be updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. The Administrator’s credentials (private key) used to access the network device are protected by the platform on which they reside. For distributed TOEs it is assumed that the availability of all TOE components is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. It is also assumed that in addition to the availability of all components it is also checked as appropriate that the audit functionality is running properly on all TOE components. The Administrator must ensure that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. The following table lists the only organisational security policy defined by the NDcPP. OSP Name OSP Definition P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal agreements, or any other appropriate information to which users consent by accessing the TOE. Security Objectives The NDcPP does not define any security objectives for the TOE, but it defines a set of objectives for the operational environment, which are listed below: Objective Name Objective Definition OE.PHYSICAL OE.NO_GENERAL_PURPOSE cyber.gov.au Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment. There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the TOE, other than those services necessary for the operation, administration and support of the TOE. pers. Vmware @avre OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this traffic will be covered by other security and assurance measures in the operational environment. OE.TRUSTED_ADMIN Security Administrators are trusted to follow and apply all guidance documentation in a trusted manner. For TOEs supporting X.509v3 certificate-based authentication, the Security Administrator(s) are assumed to monitor the revocation status of all certificates in the TOE's trust store and to remove any certificate from the TOE’s trust store in case such certificate can no longer be trusted. OE.UPDATES The TOE firmware and software is updated by an Administrator on a regular basis in response to the release of product updates due to known vulnerabilities. OE.ADMIN_CREDENTIALS_SECURE The Administrator's credentials (private key) used to access the TOE must be protected on any other platform on which they reside. OE.COMPONENTS_RUNNING For distributed TOEs the Security Administrator ensures that the availability of every TOE component is checked as appropriate to reduce the risk of an undetected attack on (or failure of) one or more TOE components. The Security Administrator also ensures that it is checked as appropriate for every TOE component that the audit functionality is running properly. OE.RESIDUAL_INFORMATION The Security Administrator ensures that there is no unauthorized access possible for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking equipment when the equipment is discarded or removed from its operational environment. Extended Components Definition The NDcPP defines the extended functional components as listed in table below. All other components in the NDcPP are from CC Part 2 or CC Part 3. The evaluation determined that the extended components definition describes how each extended component is related to existing CC Part 2 components, families, and classes; and that it follows CC Part 2 as a model for presentation. This includes operations such as assignments, selections and refinements. Each element in each extended component was determined to be measurable and states objective evaluation requirements, such that conformance or non-conformance can be demonstrated during the evaluation of a compliant TOE. To reach this conclusion, the evaluation relied upon a combination of results from evaluations EFT-T002, EFT-004 and EFT-TO05, as well as direct review of the extended components definition in the PP and review of the evaluation activities defined in the Supporting Document for the NDcPP. Bae er sss Beet teehee ta ee we Se ee ee ee eee cyber.gov.au Fe eke Doreen rer 604 seas Denen DAAD Component Identifier FAU_GEN_EXT.1 FAU_STG_EXT.1 FAU_STG_EXT.2 FAU_STG_EXT.3 FAU_STG_EXT.4 FCO_CPC_EXT.1 FCS_DTLSC_EXT.1 FCS_DTLSC_EXT.2 FCS_DTLSS_EXT.1 FCS_DTLSS_EXT.2 FCS_HTTPS_EXT.1 FCS_IPSEC_EXT.1 FCS_NTP_EXT.1. FCS_RBG_EXT.1 FCS_SSHC_EXT.1 FCS_SSHS_EXT.1 FCS_TLSC_EXT.1 FCS_TLSC_EXT.2 FCS_TLSS_EXT. 1 FCS_TLSS_EXT.2 FIA_PMG_EXT.1 FIA_UAU_EXT.2 Saeeeese See Peewee estas awewa eo se eee ene cyber gov.au Denn db Donner eo «> en Sonnen r EA OAAD AO OH MAL OAHAAHAOAA| FIA_UIA_EXT.1 FIA_X509_EXT.1. FIA_X509_EXT.2 FIA_X509_EXT.3 FPT_APW_EXT.1 FPT_SKP_EXT.1 FPT_STM_EXT.1 FPT_TST_EXT.1 FPT_TSTLEXT.2 FPT_TUD_EXT.1 FPT_TUD_EXT.2 FTA_SSL_EXT.1 Network iTC Interpretations The evaluation included all modifications to the NDcPP and Supporting Document [5] specified by the Network iTC in their Interpretations published to date and listed in the table below: Network Device Interpretation # Description 201828 Rev2 Different Handling of TLS1.1 and TLS1.2 201801 FCS_TLSC_EXT.1.1, Test 2 201815 Fixing AES-CTR Mode Tests 201817 FCS_SSH*EXT.1.1 RFCs for AES-CTR 201820 Rev3 Manual installation of CRL (FIA_X509_EXT.2) 201826 FCS_CKM.2 and elliptic curve-based key establishment 201823 Reliance on external servers to meet SFRs Soeur +s à Fr nk ew ke ne A ADO AO AH AO AP OP OH «> «A «| ne Lettre: AO HE «AP HH>>O>A > mre cyber gov.au Fe ek Oo ADD ADAAD OA LOH> 14 OPA! ee .. "OO OH «> «AP ATon rss. ner er ED AAD OO AAP AO OH HA «PO AH A «EA GA A| 201835Rev2 201827 201818 201829 201827 Rev2 201832 201836 201840 201908 201910 RSA-based FCS_CKM.2 Selection Handling Certification of Cloud Deployments local vs. remote administrator accounts for Applicability of FIA_AFL.1 to key-based SSH authentication Redundant assurance activities associated with FAU_GEN.1 FCS_SSHC_EXT.1.5, Test 1 - Server and client side seem to be confused FCS_SSHS_EXT.1.5 SFR and AA discrepancy Clarification about application of Rfi#201726rev2 NDcPP v2.1 Clarification - FCS_SSHC/S_EXT.1.5 Cut-and-paste Error for Guidance AA Security Requirements Requirements in the NDcPP are comprised of mandatory ‘base’, optional and selection-based SFRs, and these requirements are listed in tables below. The following table contains the ‘base’ requirements that were evaluated as part of a ST and PP evaluation. Requirements Class Requirement Component Verified By FAU: Security Audit FCS: Cryptographic Support cyber.gov.au FAU_GEN.1: Audit Data Generation FAU_GEN.2: User Identity Association FAU_STG_EXT.1FAU_STG_EXT.1: Protected Audit Event Storage FCS_CKM.1: Cryptographic Key Generation FCS_CKM.2: Cryptographic Key Establishment .: peers PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS pers. Vmware @avre Ave: ADAOOHHEA«>OAHA<«EHAGAA| FIA: Identification and Authentication FMT: Security Management cyber.gov.au FCS_CKM.4: Cryptographic Key Destruction FCS_COP.1/DataEncryption: Cryptographic Operation (AES Data Encryption/Decryption) FCS_COP.1/SigGen: Cryptographic Operation (Signature Generation and Verification) FCS_COP.1/Hash: Cryptographic Operation (Hash Algorithm) FCS_COP.1/KeyedHash: Cryptographic Operation (Keyed Hash Algorithm) FCS_RBG_EXT.1: Random Bit Generation FIA_AFL.1: Authentication Failure Management FIA_PMG_EXT.1: Password Management FIA_UIA_EXT.1: User Identification and Authentication FIA_UAU_EXT.2: Password-based Authentication Mechanism FIA_UAU.7: Protected Authentication Feedback FMT_MOF.1/ManualUpdate: Management of Security Functions Behaviour FMT_MTD.1/CoreData: Management of TSF Data FMT_SMF.1: Specification of Management Functions FMT_SMR.2: Restrictions on Security Roles peers PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS PP evaluation, EFT-T002, EFT-T004 and EFT- TOOS .e 0 4440 «0 AH «O0 A>O> OH «> < "A0OHO«>HE>>O>A > Ad Pear rm ardaredPOAHAaAkDO AD «OO HHA<«>OAHA<«EHAGAA| AGD_PRE.1: Preparative Procedures ALC_CMC.1: Labeling of the TOE EFT-T002, EFT-T004 and EFT-T005 EFT-T002, EFT-T004 and EFT-T005 Evaluation Overview This chapter contains information about the procedures used in conducting the cPP evaluation. Evaluation procedures The criteria against which the Target of Evaluation (TOE) has been evaluated are contained in the NDcPP [4] and Common Criteria for Information Technology Security Evaluation Version 3.1 Revision 5, Parts 2 and 3 (1, 2]. Testing methodology was drawn from Common Methodology for Information Technology Security, April 2017 Version 3.1 Revision 5 [3]. The evaluation was carried out in accordance with the operational procedures of the Australasian Information Security Evaluation Program [12]. The evaluation was performed with the first product evaluation against the NDcPP requirements. In this case, the TOE for this first product was the Junos OS 19.2R1 for MX204 and EX9251, based on its Security Target (ST) [8]. In addition, the conditions outlined in the Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security were also upheld [11]. Results The evaluation results for the APE requirements as verified by the APE and ASE work units are listed in the table below: APE Requirement Evaluation Verdict Verified By APE_CCL.1 Pass PP evaluation APE_ECD.1 Pass PP evaluation, EFT-T002, EFT-T004 and EFT- T005 APE_INT.1 Pass PP evaluation APE_OBJ.1 Pass PP evaluation APE_REQ.1 Pass PP evaluation, EFT-T002, EFT-T004 and EFT- T005 APE_SPD.1 Pass PP evaluation cyber.gov.au ee eee as pers. Vmware @avre eee we sees ss Certification Overview This chapter contains information about the result of the certification, an overview of the assurance provided and recommendations made by the certifiers. Assurance This certification is focused on the evaluation of the collaborative Protection Profile for Network Devices (NDcPP). Because the STs contain material drawn directly from the NDcPP, performance of the majority of the ASE work units serves to satisfy the APE work units as well. Where this is not the case, the evaluation facility performed the outlying APE work units as part of this evaluation. The ST evaluations addressed the base requirements of the NDcPP, as well as a few of the additional requirements contained in optional and selection-based requirements tables above. Additionally, where possible, the evaluation of NDcPP v2.1 leverages analyses from the evaluation of NDcPP v2.0E [6], which are assumed to have been performed correctly. This approach is in agreement with Section 9.2.1 (‘Re-using the evaluation results of certified PPs’) of the CEM [3]. Certification result After due consideration of the conduct of the evaluation as reported to the certifier and of the Evaluation Technical Report [10], the Australasian Certification Authority certifies the evaluation of the collaborative Protection Profile for Network Devices (NDcPP) version 2.1 performed by the Australasian Information Security Evaluation Facility (AISEF), Teron Labs. The AISEF Teron Labs has determined that the collaborative Protection Profile for Network Devices (NDcPP) version 2.1 uphold the APE assurance requirements of the Common Criteria Part 3. Recommendations The Australasian Certification Authority (ACA) recommends that: = None. cyber.gov.au ee eee as pers. Vmware @avre eee we sees ss Annex À — References and abbreviations References Common Criteria for Information Technology Security Evaluation Part 2: Security functional components April 2017, Version 3.1 Revision 5 2. Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components April 2017, Version 3.1 Revision 5 3. Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, April 2017, Version 3.1 Revision 5 4. collaborative Protection Profile for Network Devices (NDcPP), Version 2.1, 24 September 2018 5. Supporting Document, Evaluation Activities for Network Device cPP, Version 2.1, September-2018 6. Collaborative Protection Profile for Network Devices (NDcPP), Version 2.0 + Errata 20180314, 14 March 2018 7. Supporting Documents, Evaluation Activities for NDcPP2.0 + Errata 20180314, 14 March 2018 8. Security Target Junos OS 19.2 R1 for MX204 and EX9251, v1.0, 9 September 2019 9. Evaluation Technical Report - Junos OS 19.2R1 for MX204 and EX9251, v1.0, 9 September 2019 10. Evaluation Technical Report - collaborative Protection Profile for Network Devices, v1.1, 25 September 2019 11. ‚Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security, 2 July 2014 12. AISEP Policy Manual (APM): https://www.cyber.gov.au/publications/aisep-policy-manual Abbreviations AISEP Australasian Information Security Evaluation Program ASD Australian Signals Directorate CCRA Common Criteria Recognition Arrangement NDcPP CCRA-approved collaborative Protection Profile for Network Devices TOE Target of Evaluation See . Er cyber.gov.au Donner need Dre >. se a mh kare