WIXLIB

2 Conformance Claims2.1 CC ConformanceThis TOE is conformant to: Common Criteria for Information Technology Security Evaluations Part 1, Version 3.1, Revision 5,April 2017 Common Criteria for Information Technology Security Evaluations Part 2, Version 3.1, Revision 5,April 2017: Part 2 extended Common Criteria for Information Technology Security Evaluations Part 3, Version 3.1, Revision 5,April 2017: Part 3 conformant2.2 Protection Profile ConformanceThis TOE claims exact conformance to: collaborative Protection Profile for Network Devices, Version 2.2e [NDcPP]2.3 Conformance RationaleThe security problem definition, security objectives and security requirements in this Security Target areall taken from the [NDcPP]. All of the mandatory security requirements are included and selection-basedSFRs are included based on the instructions in the [NDcPP].2.3.1 Technical DecisionsAll NIAP Technical Decisions (TDs) issued to date that are applicable to [NDcPP] have been considered.The following table identifies all applicable TD:IdentifierApplicable0581 – NIT Technical Decision for Elliptic curve-basedkey establishment and NIST SP 800-56Arev30580 – NIT Technical Decision for clarification aboutuse of DH14 in NDcPPv2.2e0572 – NiT Technical Decision for RestrictingFTP ITC.1 to only IP address identifiers0571 – NiT Technical Decision for Guidance on how tohandle FIA AFL.10570 – NiT Technical Decision for Clarification aboutFIA AFL.10569 – NIT Technical Decision for Session ID UsageConflict in FCS DTLSS EXT.1.70564 – NiT Technical Decision for VulnerabilityAnalysis Search Criteria0563 – NiT Technical Decision for Clarification of auditdate information0556 – NIT Technical Decision for RFC 5077 question0555 – NIT Technical Decision for RFC Referenceincorrect in TLSS Test0547 – NIT Technical Decision for Clarification ondeveloper disclosure of AVA VAN0546 – NIT Technical Decision for DTLS - clarificationof Application Note 630538 – NIT Technical Decision for Outdated link toallowed-with list0537 – NIT Technical Decision for Incorrect referenceto FCS TLSC EXT.2.30536 – NIT Technical Decision for Update VerificationInconsistencyYes10Exclusion Rationale (if esThe ST does not include DTLS SFRs.

IdentifierApplicable0528 – NIT Technical Decision for Missing EAs forFCS NTP EXT.1.40527 – Updates to Certificate Revocation Testing(FIA X509 EXT.1)YesTable 11 Technical Decisions11YesExclusion Rationale (if applicable)

3 Security Problem DefinitionThe security problem definition has been taken from [NDcPP] and is reproduced here for theconvenience of the reader. The security problem is described in terms of the threats that the TOE isexpected to address, assumptions about the operational environment, and any organizational securitypolicies that the TOE is expected to enforce.3.1 ThreatsThe following threats are drawn directly from the [NDcPP]:IDT.UNAUTHORIZED ADMINISTRATOR ACCESST.WEAK CRYPTOGRAPHYT.UNTRUSTED COMMUNICATION CHANNELST.WEAK AUTHENTICATION ENDPOINTST.UPDATE COMPROMISET.UNDETECTED ACTIVITY12ThreatThreat agents may attempt to gain Administrator access to theNetwork Device by nefarious means such as masquerading asan Administrator to the device, masquerading as the device toan Administrator, replaying an administrative session (in itsentirety, or selected portions), or performing man-in-themiddle attacks, which would provide access to theadministrative session, or sessions between Network Devices.Successfully gaining Administrator access allows maliciousactions that compromise the security functionality of thedevice and the network on which it resides.Threat agents may exploit weak cryptographic algorithms orperform a cryptographic exhaust against the key space. Poorlychosen encryption algorithms, modes, and key sizes will allowattackers to compromise the algorithms, or brute force exhaustthe key space and give them unauthorized access allowingthem to read, manipulate and/or control the traffic withminimal effort.Threat agents may attempt to target Network Devices that donot use standardized secure tunnelling protocols to protect thecritical network traffic. Attackers may take advantage of poorlydesigned protocols or poor key management to successfullyperform man-in-the-middle attacks, replay attacks, etc.Successful attacks will result in loss of confidentiality andintegrity of the critical network traffic, and potentially couldlead to a compromise of the Network Device itself.Threat agents may take advantage of secure protocols that useweak methods to authenticate the endpoints, e.g. a sharedpassword that is guessable or transported as plaintext. Theconsequences are the same as a poorly designed protocol, theattacker could masquerade as the Administrator or anotherdevice, and the attacker could insert themselves into thenetwork stream and perform a man-in-the-middle attack. Theresult is the critical network traffic is exposed and there couldbe a loss of confidentiality and integrity, and potentially theNetwork Device itself could be compromised.Threat agents may attempt to provide a compromised updateof the software or firmware which undermines the securityfunctionality of the device. Non-validated updates or updatesvalidated using non-secure or weak cryptography leave theupdate firmware vulnerable to surreptitious alteration.Threat agents may attempt to access, change, and/or modifythe security functionality of the Network Device without

T.SECURITY FUNCTIONALITY COMPROMISET.PASSWORD CRACKINGT.SECURITY FUNCTIONALITY FAILUREAdministrator awareness. This could result in the attackerfinding an avenue (e.g., misconfiguration, flaw in the product)to compromise the device and the Administrator would haveno knowledge that the device has been compromised.Threat agents may compromise credentials and device dataenabling continued access to the Network Device and itscritical data. The compromise of credentials includes replacingexisting credentials with an attacker’s credentials, modifyingexisting credentials, or obtaining the Administrator or devicecredentials for use by the attacker.Threat agents may be able to take advantage of weakadministrative passwords to gain privileged access to thedevice. Having privileged access to the device provides theattacker unfettered access to the network traffic and mayallow them to take advantage of any trust relationships withother Network Devices.An external, unauthorized entity could make use of failed orcompromised security functionality and might thereforesubsequently use or abuse security functions without priorauthentication to access, change or modify device data, criticalnetwork traffic or security functionality of the device.Table 12 Threats3.2 AssumptionsThe following assumptions are drawn directly from the [NDcPP]:IDA.PHYSICAL PROTECTIONA.LIMITED FUNCTIONALITYA.NO THRU TRAFFIC PROTECTION13AssumptionThe Network Device is assumed to be physically protected in itsoperational environment and not subject to physical attacks thatcompromise the security or interfere with the device’s physicalinterconnections and correct operation. This protection is assumed to besufficient to protect the device and the data it contains. As a result, thecPP does not include any requirements on physical tamper protection orother physical attack mitigations. The cPP does not expect the product todefend against physical access to the device that allows unauthorizedentities to extract data, bypass other controls, or otherwise manipulatethe device. For vNDs, this assumption applies to the physical platform onwhich the VM runs.The device is assumed to provide networking functionality as its corefunction and not provide functionality/services that could be deemed asgeneral purpose computing. For example, the device should not provide acomputing platform for general purpose applications (unrelated tonetworking functionality).In the case of vNDs, the VS is considered part of the TOE with only onevND instance for each physical hardware platform. The exception beingwhere components of the distributed TOE run inside more than onevirtual machine (VM) on a single VS. There are no other guest VMs on thephysical platform providing non-Network Device functionality.A standard/generic Network Device does not provide any assuranceregarding the protection of traffic that traverses it. The intent is for theNetwork Device to protect data that originates on or is destined to the

IDA.TRUSTED ADMINISTRATORA.REGULAR UPDATESA.ADMIN CREDENTIALS SECUREA.RESIDUAL INFORMATIONA.VS TRUSTED ADMINISTRATORA.VS REGULAR UPDATESA.VS ISOLATONA.VS CORRECT CONFIGURATIONAssumptiondevice itself, to include administrative data and audit data. Traffic that istraversing the Network Device, destined for another network entity, isnot covered by the ND cPP. It is assumed that this protection will becovered by cPPs and PP-Modules for particular types of Network Devices(e.g., firewall).The Security Administrator(s) for the Network Device are assumed to betrusted and to act in the best interest of security for the organization.This includes appropriately trained, following policy, and adhering toguidance documentation. Administrators are trusted to ensurepasswords/credentials have sufficient strength and entropy and to lackmalicious intent when administering the device. The Network Device isnot expected to be capable of defending against a maliciousAdministrator that actively works to bypass or compromise the securityof the device.For TOEs supporting X.509v3 certificate-based authentication, theSecurity Administrator(s) are expected to fully validate (e.g. offlineverification) any CA certificate (root CA certificate or intermediate CAcertificate) loaded into the TOE’s trust store (aka 'root store', ' trusted CAKey Store', or similar) as a trust anchor prior to use (e.g. offlineverification).The Network Device firmware and software is assumed to be updated byan Administrator on a regular basis in response to the release of productupdates due to known vulnerabilities.The Administrator’s credentials (private key) used to access the NetworkDevice are protected by the platform on which they reside.The Administrator must ensure that there is no unauthorized accesspossible for sensitive residual information (e.g. cryptographic keys, keyingmaterial, PINs, passwords etc.) on networking equipment when theequipment is discarded or removed from its operational environment.The Security Administrators for the VS are assumed to be trusted and toact in the best interest of security for the organization. This includes notinterfering with the correct operation of the device. The Network Deviceis not expected to be capable of defending against a malicious VSAdministrator that actively works to bypass or compromise the securityof the device.The VS software is assumed to be updated by the VS Administrator on aregular basis in response to the release of product updates due to knownvulnerabilities.For vNDs, it is assumed that the VS provides, and is configured to providesufficient isolation between software running in VMs on the samephysical platform. Furthermore, it is assumed that the VS adequatelyprotects itself from software running inside VMs on the same physicalplatform.For vNDs, it is assumed that the VS and VMs are correctly configured tosupport ND functionality implemented in VMs.Table 13 Assumptions3.3 Organizational Security PoliciesThe following Organizational Security Policies are drawn directly from the [NDcPP]:14

IDP.ACCESS BANNERTable 14 OSPs15OSPThe TOE shall display an initial banner describing restrictions of use, legalagreements, or any other appropriate information to which users consentby accessing the TOE.

4 Security ObjectivesThe security objectives have been taken from [NDcPP] and are reproduced here for the convenience ofthe reader.4.1 Security Objectives for the Operational EnvironmentThe following security objectives for the operational environment assist the TOE in correctly providingits security functionality. These track with the assumptions about the environment.IDOE.PHYSICALOE.NO GENERAL PURPOSEOE.NO THRU TRAFFIC PROTECTIONOE.TRUSTED ADMINOE.UPDATESOE.ADMIN CREDENTIALS SECUREOE.RESIDUAL INFORMATIONOE.VM CONFIGURATIONObjective for the Operation EnvironmentPhysical security, commensurate with the value of the TOE and the datait contains, is provided by the environment.There are no general-purpose computing capabilities (e.g., compilers oruser applications) available on the TOE, other than those servicesnecessary for the operation, administration and support of the TOE.Note: For vNDs the TOE includes only the contents of the its own VM,and does not include other VMs or the VS.The TOE does not provide any protection of traffic that traverses it. It isassumed that protection of this traffic will be covered by other securityand assurance measures in the operational environment.Security Administrators are trusted to follow and apply all guidancedocumentation in a trusted manner. For vNDs, this includes the VSAdministrator responsible for configuring the VMs that implement NDfunctionality.For TOEs supporting X.509v3 certificate-based authentication, theSecurity Administrator(s) are assumed to monitor the revocation statusof all certificates in the TOE's trust store and to remove any certificatefrom the TOE’s trust store in case such certificate can no longer betrusted.The TOE firmware and software is updated by an Administrator on aregular basis in response to the release of product updates due toknown vulnerabilities.The Administrator’s credentials (private key) used to access the TOEmust be protected on any other platform on which they reside.The Security Administrator ensures that there is no unauthorized accesspossible for sensitive residual information (e.g. cryptographic keys,keying material, PINs, passwords etc.) on networking equipment whenthe equipment is discarded or removed from its operationalenvironment. For vNDs, this applies when the physical platform onwhich the VM runs is removed from its operational environment.For vNDs, the Security Administrator ensures that the VS and VMs areconfigured tooo16reduce the attack surface of VMs as much as possible whilesupporting ND functionality (e.g., remove unnecessary virtualhardware, turn off unused inter-VM communications mechanisms),andcorrectly implement ND functionality (e.g., ensure virtualnetworking is properly configured to support network traffic,management channels, and audit reporting).

The VS should be operated in a manner that reduces the likelihood thatvND operations are adversely affected

1 Version 1.1 Prepared by: Acumen Security 2400 Research Blvd Rockville MD 20850 FireEye NX Series Appliances v9.0 Common Criteria Security Target