NIKSUN NetOmni Security Target (Version 1.0)

Transcription

1 Assurance Activities Report For a Target of Evaluation NIKSUN NetOmni Security Target (Version 1.0) Assurance Activities Report (AAR) Version /27/2017 Evaluated by: Booz Allen Hamilton Common Criteria Test Laboratory NIAP Lab # Sentinel Drive Annapolis Junction, MD of 72

2 Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme The Developer of the TOE: NIKSUN, Inc, 457 N. Harrison St Princeton, NJ The Author of the Security Target: Booz Allen Hamilton CATL 304 Sentinel Drive Annapolis Junction, MD The TOE Evaluation was sponsored by: NIKSUN, Inc, 457 N. Harrison St Princeton, NJ Evaluation Personnel: Christopher Gugel, CC Technical Director David Cornwell Christopher Rakaczky Applicable Common Criteria Version Common Criteria for Information Technology Security Evaluation, September 2012 Version 3.1 Revision 4 Common Evaluation Methodology Version Common Criteria for Information Technology Security Evaluation, Evaluation Methodology, September 2012 Version 3.1 Revision 4 2 of 72

3 Table of Contents 1 Purpose TOE Summary Specification Assurance Activities Operational Guidance Assurance Activities Test Assurance Activities (Test Report) Platforms Tested and Composition Test Cases Security Audit Cryptographic Security User Data Protection Identification and Authentication Security Management Protection of the TSF TOE Access Trusted Path/Channels Vulnerability Testing Conclusions Glossary of Terms of 72

4 1 Purpose The purpose of this document is to serve as a non-proprietary attestation that this evaluation has satisfied all of the TSS, AGD, and ATE Assurance Activities required by the Protection Profile to which the TOE claims exact conformance. 2 TOE Summary Specification Assurance Activities The evaluation team completed the testing of the Security Target (ST) NIKSUN NetOmni 8940 Security Target v1.0 and confirmed that the TOE Summary Specification (TSS) contains all Assurance Activities as specified by the Collaborative Protection Profile for Network Devices Version 1.0 (NDcPP) and has addressed all relevant NIAP Technical Decisions. The evaluators were able to individually examine each s TSS statements and determine that they comprised sufficient information to address each claimed by the TOE as well as meet the expectations of the NDcPP Assurance Activities. Through the evaluation of ASE_TSS.1-1, described in the ETR, the evaluators were able to determine that each individual was discussed in sufficient detail in the TSS to describe the being met by the TSF in general. However, in some cases the Assurance Activities that are specified in the claimed source material instruct the evaluator to examine the TSS for a description of specific behavior to ensure that each is described to an appropriate level of detail. The following is a list of each, the TSS Assurance Activities specified for the, and how the TSS meets the Assurance Activities. FAU_GEN.1 This does not contain any NDcPP TSS Assurance Activities. FAU_GEN.2 This does not contain any NDcPP TSS Assurance Activities. FAU_STG_EXT.1 The evaluator shall examine the TSS to ensure it describes the means by which the audit data are transferred to the external audit server, and how the trusted channel is provided. The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally; what happens when the local audit data store is full; and how these records are protected against unauthorized access. If the TOE complies with FAU_STG_EXT.2 the evaluator shall verify that the numbers provided by the TOE according to the selection for FAU_STG_EXT.2 are correct when performing the tests for FAU_STG_EXT.1.3. The evaluator shall examine the TSS to ensure that it details the behaviour of the TOE when the storage space for audit data is full. When the option overwrite previous audit record is selected this description should include an outline of the rule for overwriting audit data. If other actions are chosen such as sending the new audit data to an external IT entity, then the related behaviour of the TOE shall also be detailed in the TSS. The TSS states in Section that audit records related to the GUI and CLI are kept and stored locally in /var/log. In addition, many applications run from the CLI keep their own VAR log files. Both sets of logs are transferred to a remote Syslog Server, the trusted channel is provided by TLS, the records are protected against unauthorized access by the TOE s authentication mechanisms, when local audit data is full the oldest logs are overwritten, and the rule is to overwrite the oldest log file. Other actions was not selected. FCS_CKM.1 The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme. The TSS states in Section that RSA key pairs are generated with a key size of 2048 bits and diffiehellman-group14-sha1 key generation is performed with a key size of 2048 bits. (2) The TSS states that RSA is used in TLS key establishment and Diffie-Hellman is used in SSH key establishment. Page - 1 -

5 FCS_CKM.2 The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme. The TSS states in Section that Diffie-Hellman key establishment complies with the NISP SP A Key Agreement Scheme (KAS) without a Key Derivation Function (KDF) which is defined in section 5.6 of the SP. The TSS also states that diffie-hellman-group14-sha1 conforms to RFC 3526, Section 3. FCS_CKM.4 The evaluator shall check to ensure the TSS lists each type of plaintext key material and its origin and storage location. The evaluator shall verify that the TSS describes when each type of key material is cleared (for example, on system power off, on wipe function, on disconnection of trusted channels, when no longer needed by the trusted channel per the protocol, etc.). The evaluator shall also verify that, for each type of key, the type of clearing procedure that is performed (cryptographic erase, overwrite with zeros, overwrite with random pattern, or block erase) is listed. If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are cleared by overwriting once with zeros, while secret keys stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write"). The TSS states in Section that the Diffie-Hellman Shared Secret, private exponent, and SSH session key are stored in volatile memory (RAM). The SSH private key and SSL server key are stored on the local filesystem and RAM. The TSS states that keys stored in volatile memory are zeroized immediately after they are no longer needed and when the TOE is shut down as well as when power is lost. For keys stored in non-volatile locations, when new keys are generated, the TOE overwrites the location where the keys are stored with three overwrite passes of random patterns including the new key value. The TSS states that the random data is provided by the random bit generator. FCS_COP.1(1) This does not contain any NDcPP TSS Assurance Activities. FCS_COP.1(2) This does not contain any NDcPP TSS Assurance Activities. FCS_COP.1(3) The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS. The TSS states in Section that SHA-1, SHA-256 and SHA-512 are used for HMAC message authentication, health tests and TLS certificate authentication. It also states that SHA-256 and SHA-512 are used in RSA for Signature Generation and Signature Verification. FCS_COP.1(4) The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used. The TSS states in Section that HMAC-SHA-1, HMAC-SHA-256 and HMAC-SHA-512 are used with key sizes of 160, 256, and 512 bits and digest sizes (MAC lengths) of 160, 256, and 512 bits. FCS_HTTPS_EXT.1 The evaluator shall check that the TSS describes how peer authentication is implemented when HTTPS protocol is used. The TSS states in Section that the TOE will initiate the connection to the peer and that it will only be established if the peer certificate provided by the peer to the TOE is valid. FCS_RBG_EXT.1 This does not contain any NDcPP TSS Assurance Activities. FCS_SSHC_EXT.1.2 The evaluator shall check to ensure that the TSS contains a description of the public key algorithms that are acceptable for use for authentication and that this list conforms to Page - 2 -

6 FCS_SSHC_EXT.1.5. and ensure that if password-based authentication methods have been selected in the ST then these are also described. The TSS states in Section The TOE supports password based and public key based authentication using an RSA key of 2048 bits in length as described in RFC 4252, using ssh-rsa as its public key authentication algorithm. FCS_SSHC_EXT.1.3 The evaluator shall check that the TSS describes how large packets in terms of RFC 4253 are detected and handled. The TSS states in Section that the connection is dropped when packets larger than bytes are detected in accordance with RFC FCS_SSHC_EXT.1.4 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 TSS states in Section that aes128-cbc and aes256-cbc are used for encryption. These are identical to those listed for this. FCS_SSHC_EXT.1.5 The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the public key algorithms supported are specified as well. The evaluator shall check the TSS to ensure that the public key algorithms specified are identical to those listed for this component. The TSS states in Section that ssh-rsa is used for public key authentication and this is identical to that listed for this. FCS_SSHC_EXT.1.6 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 TSS states in Section that HMAC-SHA2-256 and HMAC-SHA2-512 are used for data integrity and this matches that listed for this. FCS_SSHC_EXT.1.7 The evaluator shall check the TSS to ensure that it lists the supported key exchange algorithms, and that that list corresponds to the list in this component. The TSS states in Section that diffie-hellman-group14-sha1 is used for the key exchange algorithm and that this is identical to that listed for this. FCS_SSHC_EXT.1.8 The evaluator shall check the TSS to ensure that it describes how the is met. This comprises checking that the TSS clarifies that both thresholds are checked by the TOE and that rekeying is performed upon reaching the threshold whichever is hit first. The TSS states in Section that the SSH connection will rekey before 1 hour has elapsed or 1 GB of data has been transmitted using that key. FCS_SSHS_EXT.1.2 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_SSHS_EXT.1.5, and ensure that password-based authentication methods are also allowed. The TSS states in Section that ssh-rsa is used for the public key algorithm and this conforms to FCS_SSHS_EXT.1.5. In addition, the TSS states that password-based methods are supported. Page - 3 -

7 FCS_SSHS_EXT.1.3 The evaluator shall check that the TSS describes how large packets in terms of RFC 4253 are detected and handled. The TSS states in Section that packets larger than bytes will cause the connection to be dropped. FCS_SSHS_EXT.1.4 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 TSS states in Section that aes128-cbc and aes256-cbc are used for encryption and that this matches those listed in the. FCS_SSHS_EXT.1.5 The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that optional characteristics are specified, and the public key algorithms supported are specified as well. The evaluator shall check the TSS to ensure that the public key algorithms specified are identical to those listed for this component. The TSS states in Section that ssh-rsa is used for the public-key algorithm and that this is identical to the. FCS_SSHS_EXT.1.6 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 TSS states in Section that hmac-sha2-256 and hmac-sha2-512 are used for data integrity and this matches the. FCS_SSHS_EXT.1.7 The evaluator shall check the TSS to ensure that it lists the supported key exchange algorithms, and that that list corresponds to the list in this component. The TSS states in Section that diffie-hellman-group14-sha1 is used for the key exchange algorithm and this matches the. FCS_SSHS_EXT.1.8 The evaluator shall check the TSS to ensure that it describes how the is met. This comprises checking that the TSS clarifies that both thresholds are checked by the TOE and that rekeying is performed upon reaching the threshold whichever is hit first. The TSS states in Section that the SSH connection will rekey before 1 hour has elapsed or 1 GB of data has been transmitted using that key. FCS_TLSC_EXT.1.1 The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified include those listed for this component. The TSS states in Section that the following ciphersuite is used: TLS_DHE_RSA_WITH_AES_256_CBC_SHA This ciphersuite is identical to the. FCS_TLSC_EXT.1.2 The evaluator shall ensure that the TSS describes the client s method of establishing all reference identifiers from the administrator/application-configured reference identifier, including which types of reference identifiers are supported (e.g Common Name, DNS Name, URI Name, Service Name, or other application-specific Subject Alternative Names) and whether IP addresses and wildcards are supported. The evaluator shall ensure that this description identifies whether and the manner in which certificate pinning is supported or used by the TOE. Page - 4 -

8 The TSS states in Section that the TOE will verify the identity of the Syslog Server, LDAP/AD Server, SMTP Server, and NetDetector in accordance with RFC 6125 by checking that the presented identifier from the certificate, which includes the Common Name and DNS Name (Subject Alternative Name), matches the reference identifier (i.e. DNS hostname) defined on the TOE. The TSS states that it supports the DNS hostname only and does not support IP addresses. The TSS states that wildcards cannot be defined as part of the DNS hostname on the TOE, but the TOE will accept certificates with wildcards specified. The TSS also states that the TOE does not support certificate pinning. FCS_TLSC_EXT.1.4 The evaluator shall verify that TSS describes the Supported Elliptic Curves Extension and whether the required behaviour is performed by default or may be configured. This is N/A because elliptic curves are not supported. FCS_TLSS_EXT.1.1 The evaluator shall check the description of the implementation of this protocol in the TSS to ensure that the ciphersuites supported are specified. The evaluator shall check the TSS to ensure that the ciphersuites specified are identical to those listed for this component. The TSS states in Section that the following ciphersuite is used: TLS_DHE_RSA_WITH_AES_256_CBC_SHA This ciphersuite is identical to the. FCS_TLSS_EXT.1.2 The evaluator shall verify that the TSS contains a description of the denial of old SSL and TLS versions. The TSS states in Section that SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 attempted connections are denied. FCS_TLSS_EXT.1.3 The evaluator shall verify that the TSS describes the key agreement parameters of the server key exchange message. The TSS states in Section that Diffie-Hellman key establishment is used and that the key size is 2048 bits. FIA_PMG_EXT.1 This does not contain any NDcPP TSS Assurance Activities. FIA_UIA_EXT.1 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. The TSS states in Section that connection can take place locally or remotely via SSH using a username and password or by SSH public key. Also, connections can occur using the web GUI via HTTPS/TLS also using a username and password that is verified either locally or remotely by an LDAP/AD Server. FIA_UAU_EXT.2 Evaluation Activities for this requirement are covered under those for FIA_UIA_EXT.1. If other authentication mechanisms are specified, the evaluator shall include those methods in the activities for FIA_UIA_EXT.1. The TSS states in Section that public-key based authentication can be selected when authenticating via the CLI using SSH. Also, usernames and passwords can be verified using LDAP/AD when authenticating via the web GUI. FIA_UAU.7 This does not contain any NDcPP TSS Assurance Activities. Page - 5 -

9 FIA_X509_EXT.1 The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm. The evaluator shall ensure the TSS describes when the check of validity of the certificates takes place. It is expected that revocation checking is performed when a certificate is used in an authentication step and when performing trusted updates (if selected). It is not sufficient to verify the status of a X.509 certificate only when it's loaded onto the device. It is not necessary to verify the revocation status of X.509 certificates during power-up self-tests (if the option for using X.509 certificates for self-testing is selected). The TSS states in Section that the check of certificate validity occurs when the TOE connects with a NetDetector/NetVCR, when it connects to a Syslog Server, when it connects to an LDAP/AD Server, and when it connects to an SMTP Server. The certificate path validation includes verifying the path terminates with a trusted CA certificate, the basicconstraints extension is present and the CA flag is set to TRUE for all CA certificates. The TSF validates the revocation status of the certificate and verifies the extendedkeyusage field includes the Server Authentication purpose for server certificates used in HTTPS/TLS and TLS. FIA_X509_EXT.2 The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE can use the certificates. The evaluator shall examine the TSS to confirm that it describes the behaviour of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. The evaluator shall verify that any distinctions between trusted channels are described. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the guidance documentation contains instructions on how this configuration action is performed. The TSS describes in Section what certificates to use based upon RFC 5280 to support authentication for TLS and HTTPS connections. If the connection to the CRL distribution point cannot be made, the certificate is rejected. FIA_X509_EXT.3 If the ST author selects "device-specific information", the evaluator shall verify that the TSS contains a description of the device-specific fields used in certificate requests. This is N/A as the does not contain the device-specific information selection. FMT_MOF.1(1)/AdminAct: Management of Security Functions Behaviour - This does not contain any NDcPP TSS Assurance Activities. FMT_MOF.1(2)/AdminAct: Management of Security Functions Behaviour - This does not contain any NDcPP TSS Assurance Activities. FMT_MOF.1/LocSpace: Management of Security Functions Behaviour - This does not contain any NDcPP TSS Assurance Activities. FMT_MOF.1(1)/Trusted Update This does not contain any NDcPP TSS Assurance Activities. FMT_MTD.1/AdminAct: Management of TSF data - This does not contain any NDcPP TSS Assurance Activities. FMT_MTD.1 The evaluator shall examine the TSS to determine that, for each administrative function identified in the guidance documentation; 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 nonadministrative users. Page - 6 -

10 The TSS states in Section that the only administrative action allowed before authentication is the forgot password function for the GUI and the display of the Security banner for the web GUI and the CLI. FMT_SMF.1 This does not contain any NDcPP TSS Assurance Activities. FMT_SMR.2 This does not contain any NDcPP TSS Assurance Activities. FPT_SKP_EXT.1 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 TSS states in Section that the Diffie-Hellman Shared Secret, Diffie Hellman private exponent, and SSH session key are stored in volatile memory (RAM) and are not accessible by any user. The SSH private key and SSL server key are stored on the local filesystem and RAM. The keys stored on the local filesystem are protected using AES-128 bit encryption. Core dumps are disabled in order to prevent key data stored in memory from being disclosed if an error were to occur on the underlying operating system. FPT_APW_EXT.1 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. The TSS states in Section that the VCR user s password is stored in the OS s password file which is hashed using SHA-512. Web GUI user passwords are stored in an internal PostgreSQL Database which is hashed using SHA-256. The password for supportnet.niksun.com is protected using AES-128 encryption. The passwords required for the connection to a NetDetector/NetVCR are stored using AES ECB PKCS5 with key size 128. The VCR user is able to view the locations of these passwords but can only see their hash or encrypted values. FPT_STM.1 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 TSS states in Section that the TOE has a hardware clock for time keeping. The TSS states that the TOE uses time for audit records, inactivity timeout for the local CLI, remote CLI and web GUI, and X.509 certificate validation. FPT_TST_EXT.1 The evaluator shall examine the TSS to ensure that it details the self tests that are run by the TSF; 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 TSS describes in Section a collection of self-tests that are performed by the TSF including power-up self-tests by the FIPS module with CMVP certificate #2441, CPU tests, RAM memory tests, disk tests, DRBG health tests and a maximum heat BurnInTest. The TSS states that the tests described are sufficient to ensure the health of each component tested. FPT_TUD_EXT.1 The evaluator shall verify that the TSS describes all TSF software update mechanisms for updating the system software. The evaluator shall verify that the description includes a digital signature verification of the software before installation and that installation fails if the verification fails. Alternatively an approach using a published hash can be used. In this case the TSS shall detail this mechanism instead of the digital signature verification mechanism. The evaluator shall verify that the TSS Page - 7 -

11 describes the method by which the digital signature or published hash is verified to include how the candidate updates are obtained, the processing associated with verifying the digital signature or published hash of the update, and the actions that take place for both successful and unsuccessful signature verification or published hash verification. If the ST author indicates that a certificate-based mechanism is used for software update digital signature verification, the evaluator shall verify that the TSS contains a description of how the certificates are contained on the device. The evaluator also ensures that the TSS (or guidance documentation) describes how the certificates are installed/updated/selected, if necessary. If a published hash is used to protect the trusted update mechanism, then the evaluator shall verify that the trusted update mechanism does involve an active authorization step of the Security Administrator, and that download of the published hash value, hash comparison and update is not a fully automated process involving no active authorization by the Security Administrator. In particular, authentication as Security Administration according to FMT_MOF.1/Update needs to be part of the update process when using published hashes If a trusted update can be installed on the TOE with a delayed activation, the TSS needs to describe how and when the inactive version becomes active. The evaluator shall verify this description. The TSS states in Section that the TOE software is obtained by an administrator from supportnet.niksun.com. It is then loaded onto a CD and transferred to the TOE or loaded onto an SCP server and then downloaded to the TOE from the SCP server. The update is initiated by the VCR user via the CLI and a SHA-256 hash verification is performed on the image. If the two hashes match the install continues otherwise the VCR user will receive an error message and the install process is halted. FTA_SSL_EXT.1 This does not contain any NDcPP TSS Assurance Activities. FTA_SSL.3 This does not contain any NDcPP TSS Assurance Activities. FTA_SSL.4 This does not contain any NDcPP TSS Assurance Activities. FTA_TAB.1 The evaluator shall check the TSS to ensure that it details each method of access (local and remote) available to the administrator (e.g., serial port, SSH, HTTPS). The TSS states in Section that there are three ways to login to the TOE local CLI, remote CLI (SSH) and remote web GUI (HTTPS/TLS). FTP_ITC.1 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 TSS states in Section that connections to the Syslog Server are protected by TLS, SCP uses an SSH client, connections between the TOE and the LDAP/AD server are protected by TLS, when the TOE sends an it is protected by TLS to an SMTP Server, and connections to NetDetector are protected by HTTPS/TLS. The TSS description is consistent with the. FTP_TRP.1 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. The TSS states in Section that connections via the remote GUI are protected by HTTPS/TLS and connections via the remote CLI are protected by SSH. Page - 8 -

12 Additionally, the assurance activity for ALC_CMC.1 requires the ST to identify the product version that meets the requirements of the ST such that the identifier is sufficiently detailed to be usable for acquisitions. The ST clearly specifies the TOE Reference as being the NIKSUN NetOmni 8940 appliance running the NIKSUN NetOmni Everest software version In addition, the ST specifies the TOE model. 3 Operational Guidance Assurance Activities The evaluation team completed the testing of the Operational Guidance, which includes the review of the NIKSUN NetOmni 8940 Release Supplemental Administrative Guidance for Common Criteria Version 1.0 (AGD) document, and confirmed that the Operational Guidance contains all Assurance Activities as specified by the Collaborative Protection Profile for Network Devices Version 1.0 (NDcPP). The evaluators reviewed the NDcPP to identify the security functionality that must be discussed for the operational guidance. This is prescribed by the Assurance Activities for each and the AGD SARs. The evaluators have listed below each of the s defined in the NDcPP that have been claimed by the TOE (some s are conditional or optional) as well as the AGD SAR, along with a discussion of where in the operational guidance the associated Assurance Activities material can be found. If an is not listed, one of the following conditions applies: There is no Assurance Activity for the. The Assurance Activity for the specifically indicates that it is simultaneously satisfied by completing a different Assurance Activity (a testing Assurance Activity for the same, a testing Assurance Activity for a different, or a guidance Assurance Activity for another ). The Assurance Activity for the does not specify any actions to review the operational guidance. FAU_GEN.1 The evaluator shall check the guidance documentation and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the cpp is described and that the description of the fields contains the information required in FAU_GEN1.2, and the additional information specified in the table of audit events. The evaluator shall also make a determination of the administrative actions that are relevant in the context of the cpp. The evaluator shall examine the guidance documentation and make a determination of which administrative commands, including subcommands, scripts, and configuration files, are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the cpp. The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to the cpp. The evaluator may perform this activity as part of the activities associated with ensuring that the corresponding guidance documentation satisfies the requirements related to it. Section 8 of the AGD provides a table of auditable events that is consistent with the auditable events table in the NDcPP for the claimed s. This table includes examples of audit records for different situations that are associated with the requirement including all audit events defined in Table 1 of the NDcPP as well as the management actions to configure the TSF capability. Section 8 provides an example of an audit record before this table and breaks it down into the individual fields that are prescribed by FAU_GEN.1.2. From this example, the relationship between the audit logs shown in the table and the required fields can be determined clearly. The AGD was developed with the intent to provide the specific guidance for managing TOE functionality or a pointer to the necessary documentation as defined by the Intended Audience statement in Section 2: This document is intended for administrators responsible for installing, configuring, and/or operating NetOmni. Guidance provided in this document allows the reader to deploy the product in an environment that is consistent with the configuration that was evaluated as part of the product s Common Criteria (CC) testing process. It also provides the reader with instructions on how to exercise the security functions that were claimed as part of the CC evaluation. The reader is also expected to be familiarity with the general Page - 9 -

13 operation of the NetOmni product. This supplemental guidance includes references to NIKSUN s standard documentation set for the product and does not explicitly reproduce materials located there. Thus, the evaluation team has determined that only the commands located within the AGD and the specific pointers to other documents are considered to be security relevant for this evaluation. FAU_STG_EXT.1 The evaluator shall also examine the guidance documentation to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements on the audit server (particular audit server protocol, version of the protocol required, etc.), as well as configuration of the TOE needed to communicate with the audit server. The evaluator shall also examine the guidance documentation to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server. For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and cleared periodically by sending the data to the audit server. The evaluator shall also ensure that the guidance documentation describes all possible configuration options for FAU_STG_EXT.1.3 and the resulting behaviour of the TOE for each possible configuration. The description of possible configuration options and resulting behaviour shall correspond to those described in the TSS. Section 6.4 of the AGD discusses the configuration of the TOE to securely send the audit data between itself and the remote audit server. It describes the protocol and ciphersuite requirements for both the TOE and the remote audit server. Section 6.4 of the AGD also states that the TOE performs auditing of all audit events required by Common Criteria and stores them locally in the /var/log directory. It states that all audit records are stored locally and automatically transferred to the remote Syslog Server as soon as they are generated. Section 8.1 of the AGD describes how the TOE stores audit records locally and what behavior occurs when the storage space allocated for an individual file type is filled which is delete the oldest log file of that type. FCS_CKM.1 The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all uses defined in this PP. Section 6.3 of the AGD discusses how to configure the TOE to use the diffie-hellman-group14-sha1 key exchange algorithm for SSH. Section 6.4 of the AGD references an external vendor configuration guide that details the steps required to limit TLS connections between the TOE and remote audit server to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which uses Diffie-Hellman for key generation. Section 6.5 of the AGD specifies how to limit TLS connections between the TOE and HTTPS peers to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which uses Diffie-Hellman for key generation. Section 6.6 of the AGD specifies how to limit TLS connections between the TOE and LDAP/AD server to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which uses Diffie-Hellman for key generation. Section 6.7 of the AGD states that in the evaluated configuration, the connection between the TOE and the remote SMTP server to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which uses Diffie-Hellman for key generation. Page

14 Section 6.5 of the AGD discusses how to configure the TOE Apache Web Server which uses certificates for establishing TLS connections to clients that connect to the TOE via HTTPS. Specifically, Section 6.5 of the AGD, the openssl genrsa -out localhost,key 2048 command generates a 2048-bit RSA private key for the TOE Apache Web Server. Section 7.1 of the AGD discusses how to authenticate to the TOE using an SSH client. The AGD states that SSH public key authentication can be achieved for SSH and SCP sessions by generating a 2048-bit RSA private/public key pair with the ssh-keygen -t rsa command. FCS_CKM.2 The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s). Section 6.3 of the AGD discusses how to configure the TOE to use the diffie-hellman-group14-sha1 key exchange algorithm for SSH. Section 6.4 of the AGD references an external vendor configuration guide that details the steps required to limit TLS connections between the TOE and remote audit server to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which uses Diffie-Hellman for key establishment. Section 6.5 of the AGD specifies how to limit TLS connections between the TOE and HTTPS peers to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which uses Diffie-Hellman for key establishment. Section 6.6 of the AGD specifies how to limit TLS connections between the TOE and LDAP/AD server to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which uses Diffie-Hellman for key establishment. Section 6.7 of the AGD states that in the evaluated configuration, the connection between the TOE and the remote SMTP server to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which uses Diffie-Hellman for key establishment. FCS_COP.1(3) The evaluator checks the AGD documents to determine that any configuration that is required to configure the required hash sizes is present. Section 6.3 of the AGD discusses the syntax to limit the MAC algorithms, which rely on their hashing algorithm counterpart, to be used for SSH. Sections 6.4, 6.5, 6.6, and 6.7 of the AGD describe how to limit TLS connections between the TOE and external entities in the operational environment to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which uses SHA-1 for the hashed message authenticate code algorithm. FCS_SSHC_EXT.1.4 The evaluator shall also check the guidance documentation 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). Section 6.3 of the AGD describes how to configure the TOE to only use the aes128-cbc and aes256-cbc ciphers; which is consistent with the Security Target. FCS_SSHC_EXT The evaluator shall also check the guidance documentation 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). Section 6.3 of the AGD describes how to configure the TOE to only use the ssh-rsa public key algorithm; which is consistent with the Security Target. Page

15 FCS_SSHC_EXT.1.6 The evaluator shall also check the guidance documentation 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). Section 6.3 of the AGD describes how to configure the TOE to only use the hmac-sha2-256 and hmacsha2-512 integrity algorithms and includes a note that the none MAC is not allowed for SSH; which is consistent with the Security Target. FCS_SSHC_EXT.1.7 The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed key exchange algorithms are used in SSH connections with the TOE. Section 6.3 of the AGD describes how to configure the TOE to only use the diffie-hellman-group14-sha1 key exchange algorithm; which is consistent with the Security Target. FCS_SSHC_EXT.1.8 If one or more thresholds that are checked by the TOE to fulfil the are configurable, then the evaluator shall check that the guidance documentation describes how to configure those thresholds. Either the allowed values are specified in the guidance documentation and must not exceed the limits specified in the (one hour of session time, one gigabyte of transmitted traffic) or the TOE must not accept values beyond the limits specified in the. The evaluator shall check that the guidance documentation describes that the TOE reacts to the first threshold reached. Section 6.3 of the AGD describes how to configure the TOE to perform a SSH rekey before one hour has elapsed or one gigabyte of data has been transmitted using a key, whichever occurs first. The AGD states that the thresholds for SSH rekey are not configurable in the evaluated configuration. FCS_SSHS_EXT.1.4 The evaluator shall also check the guidance documentation 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). Section 6.3 of the AGD describes how to configure the TOE to only use the aes128-cbc and aes256-cbc ciphers; which is consistent with the Security Target. FCS_SSHS_EXT.1.5 The evaluator shall also check the guidance documentation 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). Section 6.3 of the AGD describes how to configure the TOE to only use the ssh-rsa public key algorithm; which is consistent with the Security Target. FCS_SSHS_EXT.1.6 The evaluator shall also check the guidance documentation 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). Section 6.3 of the AGD describes how to configure the TOE to only use the hmac-sha2-256 and hmacsha2-512 integrity algorithms and includes a note that the none MAC is not allowed for SSH; which is consistent with the Security Target. FCS_SSHS_EXT.1.7 The evaluator shall also check the guidance documentation to ensure that it contains instructions to the administrator on how to ensure that only the allowed key exchange algorithms are used in SSH connections with the TOE. Section 6.3 of the AGD describes how to configure the TOE to only use the diffie-hellman-group14-sha1 key exchange algorithm; which is consistent with the Security Target. Page

16 FCS_SSHS_EXT.1.8 If one or more thresholds that are checked by the TOE to fulfil the are configurable, then the evaluator shall check that the guidance documentation describes how to configure those thresholds. Either the allowed values are specified in the guidance documentation and must not exceed the limits specified in the (one hour of session time, one gigabyte of transmitted traffic) or the TOE must not accept values beyond the limits specified in the. The evaluator shall check that the guidance documentation describes that the TOE reacts to the first threshold reached. Section 6.3 of the AGD describes how to configure the TOE to perform a SSH rekey before one hour has elapsed or one gigabyte of data has been transmitted using a key, whichever occurs first. The AGD states that the thresholds for SSH rekey are not configurable in the evaluated configuration. FCS_TLSC_EXT.1.1 The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS. Section 6.4 of the AGD references an external vendor configuration guide that details the steps required to limit TLS connections between the TOE and remote audit server to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which encrypts the data in transit. Section 6.5 of the AGD specifies how to limit TLS connections between the TOE and HTTPS peers to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which encrypts the data in transit. Section 6.6 of the AGD specifies how to limit TLS connections between the TOE and LDAP/AD server to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which encrypts the data in transit. Section 6.7 of the AGD states that in the evaluated configuration, the connection between the TOE and the remote SMTP server is protected with TLS v1.2 and the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite. FCS_TLSC_EXT.1.2 The evaluator shall verify that the AGD guidance includes instructions for setting the reference identifier to be used for the purposes of certificate validation in TLS. Section 6.4 of the AGD references an external vendor configuration guide that details the steps required to configure the reference identifier in order to validate the presented identifier in the certificate it receives from the remote audit server. Section 6.5 of the AGD references an external vendor configuration guide that details the steps required to configure the reference identifier in order to validate the presented identifier in the certificate it receives from the remote NetDetector/NetVCR peer. Section 6.6 of the AGD details the steps for configuring the LDAP server address which is used to verify the presented identifier in the certificate it receives from the remote LDAP/AD server. Section 6.7 of the AGD references an external vendor configuration guide that details the steps required to configure the reference identifier in order to validate the presented identifier in the certificate it receives from the remote SMTP server. FCS_TLSC_EXT.1.4 If the TSS indicates that the Supported Elliptic Curves Extension must be configured to meet the requirement, the evaluator shall verify that AGD guidance includes configuration of the Supported Elliptic Curves Extension. The TOE does not support Elliptic Curve Extensions. Therefore, this assurance activity is not applicable. FCS_TLSS_EXT.1.1 The evaluator shall also check the guidance documentation to ensure that it contains instructions on configuring the TOE so that TLS conforms to the description in the TSS (for instance, the set of ciphersuites advertised by the TOE may have to be restricted to meet the requirements). Page

17 Section 6.5 of the AGD specifies how to limit TLS connections between the TOE and HTTPS peers to only use the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which encrypts the data in transit. FCS_TLSS_EXT.1.2 The evaluator shall verify that any configuration necessary to meet the requirement must be contained in the AGD guidance. Section 6.5 of the AGD describes the configuration steps required to limit the protocol versions to TLS v1.2. FCS_TLSS_EXT.1.3 The evaluator shall verify that any configuration necessary to meet the requirement must be contained in the AGD guidance. Section 6.5 of the AGD describes the steps required to configure the Apache Web Server on the TOE such that TLS connections are limited to only using the TLS_DHE_RSA_WITH_AES_256_CBC_SHA ciphersuite, which uses Diffie-Hellman parameters of size 2048 bits, as specified in the Security Target. FIA_PMG_EXT.1 The evaluator shall examine the guidance documentation 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. Section 7.3 of the AGD includes a recommendation for strong password compositions and the procedures to set the minimum character limit for passwords for the web GUI and CLI. FIA_UIA_EXT.1 The evaluator shall examine the guidance documentation 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 guidance documentation 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 guidance documentation provides sufficient instruction on limiting the allowed services. Section 6.5 of the AGD discusses the configuration of the Apache Web Server, which hosts the web GUI, for the TLS trusted path. Section 6.3 of the AGD discusses the configuration of the TOE s sshd, which supports the remote CLI, to include that it is configured to use diffie-hellman-group14-sha1 and the different allowed algorithms claimed. Section 6.6 of the AGD discusses the configuration of the LDAP/AD remote authentication source. Section 7.1 of the AGD discusses how to access the web GUI and CLI as well as the different authentication methods that are supported by the TOE in the evaluated configuration. Section 7.4 of the AGD describes the configuration of login banners which is one of the allowed services prior to authentication. Section 6.7 of the AGD includes the configuration of the SMTP client which supports the Forgot Username/word feature which is another allowed service prior to authentication FIA_X509_EXT.3 The evaluator shall check to ensure that the guidance documentation contains instructions on requesting certificates from a CA, including generation of a Certificate Request Message. If the ST author selects "Common Name", "Organization", "Organizational Unit", or "Country", the evaluator shall ensure that this guidance includes instructions for establishing these fields before creating the certificate request message. Section 6.5 of the AGD provides instructions on requesting a certificate from a CA, including the generation of a Certificate Request Message containing the Common Name, Organization, Organizational Unit, and Country for the secure configuration of the TOE Apache Web Server. Page