4.2 Security functional requirements and related test cases
33.1173GPPCatalogue of general security assurance requirementsRelease 16TS
4.2.1 Introduction
The present clause describes the security functional requirements and the corresponding test cases, independent of a specific network product class. In particular the proposed security requirements are classified in two groups:
– Security functional requirements deriving from 3GPP specifications and detailed in clause 4.2.2
– General security functional requirements which include requirements not already addressed in the 3GPP specifications but whose support is also important to ensure a network product conforms to a common security baseline detailed in clause 4.2.3.
4.2.2 Security functional requirements deriving from 3GPP specifications and related test cases
4.2.2.1 Security functional requirements deriving from 3GPP specifications – general approach
The present clause describes the general approach taken towards security functional requirements deriving from 3GPP specifications and the corresponding test cases, independent of a specific network product class.
It is assumed for the purpose of the present SCAS that a network product conforms to all mandatory security-related provisions in 3GPP specifications pertaining to it, in particular:
– all 3GPP specifications of the 33-series (security specifications) that are pertinent to the network product class;
– other 3GPP specifications that make reference to security specifications or are referred to from one of them.
3GPP has decided to develop test specifications for the UE in the TSs of the 34-series under the responsibility of Working Group RAN5. 3GPP saw, however, no need to develop test specifications for network elements. For network elements, 3GPP rather trusts that tests are run under the responsibility of the vendors.
Security procedures pertaining to a network product are typically embedded in non-security procedures and are hence assumed to be tested together with them.
It is the purpose of the present SCAS to identify security requirements from the EPS and 5G security architecture that require special attention in testing as they may:
(a) lead to vulnerabilities when not satisfied;
(b) not be captured through ordinary testing activity for non-security procedures;
(c) address security-relevant failure cases and exceptions or ‘negative’ requirements of the kind: "The network product shall not…"
It is not an intention of the present document to provide an exhaustive set of test cases that would be sufficient to demonstrate conformance of all security procedures with the above-mentioned specifications.
4.2.2.2 Security functional requirements derived from 3GPP specifications – general SBA/SBI aspects
4.2.2.2.1 Introduction
The purpose of the sub-clauses in 4.2.2.2 is to identify and describe the general baseline requirements from SBA security architecture and the corresponding test cases. The general baseline requirements are applicable to all Network Function (NF) within the 5G Core (5GC) utilizing Service-Based Interfaces (SBI), independent of a specific network product class.
4.2.2.2.2 Protection at the transport layer
Requirement Name: Protection at the transport layer
Requirement Reference: TS 33.501 [10], clause 5.9.2.1, clause 13.1, clause 13.3.2
Requirement Description:
"NF Service Request and Response procedure shall support mutual authentication between NF consumer and NF producer" as specified in TS 33.501 [10], clause 5.9.2.1;
"All network functions shall support TLS. Network functions shall support both server-side and client-side certificates.
The TLS profile shall follow the profile given in Annex E of TS 33.310 [9] with the restriction that it shall be compliant with the profile given by HTTP/2 as defined in RFC 7540 [11]. "
as specified in TS 33.501 [10], clause 13.1.
"Authentication between network functions within one PLMN shall use one of the following methods:
– If the PLMN uses protection at the transport layer as described in clause 13.1, authentication provided by the transport layer protection solution shall be used for authentication between NFs."
as specified in TS 33.501 [10], clause 13.3.2.
Threat References: TR 33.926 [4], clause 5.3.6.3, Weak cryptographic algorithms
Test case:
Test Name: TC_PROTECT_TRANSPORT_LAYER
Purpose:
Verify that TLS protocol for NF mutual authentication and NF transport layer protection is implemented in the network products based on the profile required.
Procedure and execution steps:
Pre-Conditions:
Network product documentation containing information about supported TLS protocol and certificates is provided by the vendor.
A peer implementing the TLS protocol configured by the vendor shall be available.
The tester shall base the tests on the profile defined by 3GPP in Annex E of TS 33.310 [9] with the restriction that it shall be compliant with the profile given by HTTP/2 as defined in RFC 7540 [11].
Execution Steps
1. The tester shall check that compliance with the TLS profile can be inferred from detailed provisions in the network product documentation.
2. The tester shall establish a secure connection between the network product under test and the peer and verify that all TLS protocol versions and combinations of cryptographic algorithms that are mandated by the TLS profile are supported by the network product under test.
3. The tester shall try to establish a secure connection between the network product under test and the peer and verify that this is not possible when the peer only offers a feature, including protocol version and combination of cryptographic algorithms, that is forbidden by the TLS profile.
Expected Results:
– The network product under test and the peer establish TLS if the TLS profiles used by the peer are compliant with the profile requirements in TS 33.310 [9] Annex E and RFC 7540 [11].
– The network product under test and the peer fail to establish TLS if the TLS profiles used by the peer are forbidden in TS 33.310 [9] Annex E or RFC 7540 [11].
Expected format of evidence:
Provide evidence of the check of the product documentation in plain text. Save the logs and the communication flow in a .pcap file.
4.2.2.2.3 Authorization of NF service access
4.2.2.2.3.1 Authorization token verification failure handling wthin one PLMN
Requirement Name: Authorization token verification failure handling wthin one PLMN
Requirement Reference: TS 33.501 [10], clause 13.4.1.1
Requirement Description:
"13.4.1.1 Service access authorization within the PLMN
2. The NF Service producer shall verify the access token as follows:
– The NF Service producer ensures the integrity of the access token by verifying the signature using NRF’s public key or checking the MAC value using the shared secret. If integrity check is successful, the NF Service producer shall verify the claims in the access token as follows:
NOTE: Void.
– It checks that the audience claim in the access token matches its own identity or the type of NF service producer.
– If scope is present, it checks that the scope matches the requested service operation.
– It checks that the access token has not expired by verifying the expiration time in the access token against the current data/time.
3. If the verification is successful, the NF Service producer shall execute the requested service and responds back to the NF Service consumer. Otherwise it shall reply based on Oauth 2.0 error response defined in RFC 6749 [43]."
Threat References: TR 33.926 [4], clause 6.3.3.1, Incorrect Verification of Access Tokens
Test Case:
Test Name: TC_AUTHORIZATION_TOKEN_VERIFICATION_FAILURE_ONE_PLMN
Purpose:
Verify that the NF service producer does not grant service access if the verification of authorization token from a NF service consumer in the same PLMN fails.
Procedure and execution steps:
Pre-Conditions:
– Test environment with a NF service consumer.
– The NF service consumer may be simulated.
– The network product under test has already mutually authenticated with the NF service consumer.
– The tester shall have access to the interface between the NF service consumer and the network product under test.
– The tester has the NRF’s private key or the shared key.
– The network product under test is preconfigured with the NRF’s public key or the shared key.
Execution Steps
The network product under test receives the access token sent from the NF service consumer, verifies the access token based on Oauth 2.0.
Test Case 1: Verification failure of the access token integrity
1) The tester computes an access token correctly, except that the signature or the MAC is incorrect, e.g., the signature or the MAC is randomly selected, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.
2) The integrity verification of the access token by the network product under test fails.
Test Case 2: Incorrect audience claim in the access token
1) The tester computes an access token correctly, except that the audience claim is incorrect, i.e., the audience claim in the access token does not match the identity or the type of the network product under test, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.
2) The network product under test verifies that the audience claim in the access token does not match its identity or type.
Test Case 3: Incorrect scope claim in the access token
1) The tester computes an access token correctly, except that the scope is incorrect, i.e., the scope does not match the requested service operation, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.
2) The network product under test verifies that the integrity verification of the access token and audience claim verification are correct. However, the scope does not match the requested service operation.
Test Case 4: Expired access token
1) The tester computes an access token correctly, except that the expiration time has expired against the current data/time, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.
2) The network product under test verifies that the expiration time in the access token has expired against the current data/time.
Expected Results:
For test cases 1~4, the network product under test rejects the NF service consumer’s service request based on Oauth 2.0 error response defined in RFC 6749 [12].
Expected format of evidence:
Evidence suitable for the interface, e.g., Screenshot containing the operational results.
4.2.2.2.3.2 Authorization token verification failure handling in different PLMNs
Requirement Name: Authorization token verification failure handling in different PLMNs
Requirement Reference: TS 33.501 [10], clause 13.4.1.2
Requirement Description:
"The NF service producer shall check that the home PLMN ID of audience claim in the access token matches its own PLMN identity."
Threat References: TR 33.926 [4], clause 6.3.3.1, Incorrect Verification of Access Tokens
NOTE: The test case below only applies to the NFs which support identifying and understanding the producerPlmnId claim.
Test Case:
Test Name: TC_AUTHORIZATION_TOKEN_VERIFICATION_FAILURE_DIFF_PLMN
Purpose:
Verify that the NF service producer does not grant service access if the verification of authorization token from a NF service consumer in a different PLMN fails.
Procedure and execution steps:
Pre-Conditions:
– Test environment with a NF service consumer and two SEPPs (one cSEPP, one pSEPP).
– The NF service consumer and SEPPs may be simulated.
– The network product under test has already mutually authenticated with the NF service consumer in a different PLMN via the SEPPs.
– The tester has the NRF’s private key or the shared key.
– The network product under test is preconfigured with the NRF’s public key or the shared key.
– The tester shall have access to the interfaces of the NF service consumer and the network product under test.
Execution Steps
The network product under test receives the access token sent from the NF service consumer, verifies the access token in accordance with the execution steps in 4.2.2.1.2.1, with the following additional test cases:
Test Case 1: incorrect PLMN ID of the NF service producer in the access token
1) The test computes an access token correctly, except that the PLMN ID in the producerPlmnId claim of the access token is empty or different from the home PLMN ID of the network product under test, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test through the SEPPs.
2) The network product under test receives the access token sent from the NF service consumer through the SEPPs, verifies that the PLMN ID in the producerPlmnId claim of the access token is different from its own home PLMN identity.
Test Case 2: absent PLMN ID of the NF service producer in the access token
1) The test computes an access token correctly, except that no producerPlmnId claim is included in the access token, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test through the SEPPs.
2) The network product under test receives the access token sent from the NF service consumer through the SEPPs, verifies that the access token is not a token to be used by the NF service consumer in a different PLMN, based on the absence of PLMN ID of the NF service producer in the access token.
Expected Results:
For both test cases 1 and 2, the network product under test rejects the NF service consumer’s service request based on Oauth 2.0 error response defined in RFC 6749 [12].
Expected format of evidence:
Evidence suitable for the interface, e.g., Screenshot containing the operational results.
4.2.3 Technical baseline
4.2.3.1 Introduction
The technical baseline is a generic set of security requirements to be fulfilled by all network products.
In particular these requirements counter the security threats and objectives identified in the TR 33.926 [4] and they basically aim to guarantee the network product confidentiality, integrity and availability.
4.2.3.2 Protecting data and information
4.2.3.2.1 Protecting data and information – general
Adequate security measures for protecting sensitive data shall be implemented as defined in the present document. Further measures (that are beyond the scope of the present document) may be required by local regulation depending on the classification of the data and other factors such as type of network used during transmission, storage location for data, etc.
4.2.3.2.2 Protecting data and information – Confidential System Internal Data
Requirement Name: Unauthorized Viewing
Requirement Description: When the system is not under maintenance, there shall be no system function that reveals confidential system internal data in the clear to users and administrators. Such functions could be, for example, local or remote OAM CLI or GUI, logging messages, alarms, configuration file exports etc. Confidential system internal data contains authentication data (i.e. PINs, cryptographic keys, passwords, cookies) as well as system internal data that is not required for systems administration and could be of advantage to attackers (i.e. stack traces in error messages).
Security Objective references: tba.
Test case:
Test Name: TC_CONFIDENTIAL_SYSTEM_INTERNAL_DATA
Purpose:
Verify that no system function reveals sensitive data in the clear
Procedure and execution steps:
Pre-Condition:
The vendor shall provide documentation describing how confidential system internal information that could possibly be revealed in clear-text is handled by system functions.
A list of all system functions in the network product, information on how to enable and execute them should be provided as a part of the vendor’s documentation. A system function is every function implemented in the network product needed by the services/functionalities provided by the network product itself.
Execution Steps
Execute the following steps:
1. Review the documentation provided by the vendor describing how confidential system internal information is handled by system functions.
2. The tester checks whether any system functions as described in the product documentation (e.g. local or remote OAM CLI or GUI, logging messages, alarms, error messages, configuration file exports, stack traces) reveal any confidential system internal data in the clear (for example, passphrases).
Expected Results:
There should be no confidential system internal data revealed in the clear by any system function.
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot containing the operational results.
4.2.3.2.3 Protecting data and information in storage
Requirement Name: Protecting data and information in storage
Requirement Description:
For sensitive data in (persistent or temporary) storage read access rights shall be restricted. Files of a system that are needed for the functionality shall be protected against manipulation.
In addition, the following rules apply for:
– Systems that need access to identification and authentication data in the clear, e.g. in order to perform an authentication. Such systems shall not store this data in the clear, but scramble or encrypt it by implementation-specific means.
– Systems that do not need access to sensitive data (e.g. user passwords) in the clear. Such systems shall hash this sensitive data .
– Stored files on the network product: examples for protection against manipulation are the use of checksum or cryptographic methods.
Security Objective references: tba
Test case:
Test Name: TC_PSW_STOR_SUPPORT
Purpose:
Verify that Password storage use one-way hash algorithm.
Procedure and execution steps:
Pre-Conditions:
– The tester can access the storage of own user account password.
– The tester has privileges to change the password.
– The original password is P1.
Execution Steps
1. The tester accesses the storage where the result of P1 is, and the corresponding hash value is recorded as A
2. The tester changes the password with P2, then the tester records the storage hash value of the new password as B
3. The tester repeats the step 2 to get other records.
4. The tester verifies whether all the records comply with the characteristic of one-way hash result.
Expected Results:
All records comply with the characteristic of one-way hash result.
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot containing the operation results.
4.2.3.2.4 Protecting data and information in transfer
Requirement Name: tba
Requirement Description:
– Usage of cryptographically protected network protocols is required.
– The transmission of data with a need of protection shall use industry standard network protocols with sufficient security measures and industry accepted algorithms. In particular, a protocol version without known vulnerabilities or a secure alternative shall be used.
Security Objective references: tba
Test case:
Test Name: TC_PROTECT_DATA_INFO_TRANSFER_1
Purpose:
Verify the mechanisms implemented to protect data and information in transfer to and from the Network Product’s OAM interface.
NOTE: The test is limited to the OAM interface although the requirement does not have this limitation because the protection of standardised interfaces will be covered by regular interoperability testing and the proprietary use of HTTPS is covered in clause 4.2.5.1.
Procedure and execution steps:
Pre-Conditions:
Network product documentation containing information about supported OAM protocols is provided by the vendor,
A peer implementing the security protocol configured by the vendor (e.g. SSH client supporting SSHv2 or HTTPS client) shall be available.
Network product documentation stating which security protocols for protection of data in transit are implemented and which profiles in TS 33.310 [9] and TS 33.210 [X] are applicable is provided by the vendor
For TLS, the tester shall base the tests on the profile defined by 3GPP in TS 33.310 [9]. For IKE and IPsec, the tester shall base the tests on the profile defined by 3GPP in TS 33.210 [X]. For protocols, for which 3GPP did not define a security profile, e.g. SSH, the tester shall base the tests on a widely recognised and publicly available security profile.
Execution Steps
1. The tester shall check that compliance with the selected security profile can be inferred from detailed provisions in the product documentation.
2. The tester shall establish a secure connection between the network product and the peer and verify that all protocol versions and combinations of cryptographic algorithms that are mandated by the security profile are supported by the network product.
3. The tester shall try to establish a secure connection between the network product and the peer and verify that this is not possible when the peer only offers a feature, including protocol version and combination of cryptographic algorithms, that is forbidden by the security profile.
Expected Results:
The traffic is properly protected, and insecure options are not accepted by the Network Product.
Expected format of evidence:
Provide evidence of the check of the product documentation in plain text. Save the logs and the communication flow in a .pcap file.
4.2.3.2.5 Logging access to personal data
Requirement Name: Logging access to personal data
Requirement Description:
In some cases access to personal data in clear text might be required. If such access is required, access to this data shall be logged, and the log shall contain who accessed what data without revealing personal data in clear text. When for practical purposes such logging is not available, a coarser grain logging is allowed.
In some cases, the personal data stored in the log files may allow the direct identification of a subscriber. In such cases, the revealed personal information may not expose the subscriber to any kind of privacy violation.
Test case:
Test Name: TC_LOGGING_ACCESS_TO_PERSONAL_DATA
Purpose:
Verify that in cases where a network product presents personal data in clear text, access attempts to such data are logged and the log information includes the user identity that has accessed the data. The test case also verifies that the personal data itself is not included in clear text in the log.
Procedure and execution steps:
Pre-Conditions:
A document which provides a description of where personal data in clear text is accessible on the network product, how it can be accessed, and details of where such access attempts are logged and how to view these logs.
Execution Steps
– The tester verifies, for cases where personal data is accessible in clear text, that attempts to access it are recorded in a log, that the log includes the identity of the user that has attempted to access the data, and that the log does not include the actual personal data in clear-text.
– The tester repeats the check for each case where personal data is accessible.
Expected Results:
All access attempts to personal data (in clear text) are recorded in the described logs, with the user identity included and no personal data visible in the log.
Expected format of evidence:
Sample copies of the log files.
4.2.3.3 Protecting availability and integrity
4.2.3.3.1 System handling during overload situations
Requirement Name: System handling during overload situations
– Requirement Description:
The system shall provide security measures to deal with overload situations which may occur as a result of a denial of service attack or during periods of increased traffic, or reach the congestion threshold. In particular, partial or complete impairment of system availability shall be avoided. Potential protective measures include:
– Restricting available RAM per application.
– Restricting maximum sessions for a Web application.
– Defining the maximum size of a dataset.
– Restricting CPU resources per process.
– Prioritizing processes.
– Overload control method, e.g. limiting amount or size of transactions of a user or from an IP address in a specific time range.
– Security Objective references: tba.
Test case: Refer to test case in clause 4.2.3.3.3.
4.2.3.3.2 Boot from intended memory devices only
Requirement name: Boot from intended memory devices only
Requirement reference: to be done later
Requirement Description:
The network product can boot only from the memory devices intended for this purpose.
Test case:
Test Name: TC_BOOT_INT_MEM_1
Purpose:
Verify that the network product can only boot from memory devices intended for this purpose (e.g. not from external memory like USB key).
Procedure and execution steps:
Pre-Conditions:
A document which contains information regarding the firmware access mechanism supported by the product and about the memory devices from which the network product can boot.
Execution Steps
1. The tester verifies that the network product is configured to boot from memory devices declared in the network product document only.
2. The tester verifies that there is no possibility to access and modify the firmware of the network product without successful authentication.
Expected Results:
The network product cannot boot from a memory device that is not configured in its firmware, and access to the firmware is only possible with the correct authentication.
Expected format of evidence: NA
4.2.3.3.3 System handling during excessive overload situations
Requirement Name: System handling during excessive overload situations
Requirement Description: The system shall act in a predictable way if an overload situation cannot be prevented. A system shall be built in this way that it can react on an overload situation in a controlled way. However it is possible that a situation happens where the security measures are no longer sufficient.
In such case it shall be ensured that the system cannot reach an undefined and thus potentially insecure state. In an extreme case this means that a controlled system shutdown is preferable to uncontrolled failure of the security functions and thus loss of system protection.
The vendor shall provide a technical description of the network product’s Over Load Control mechanisms (especially whether these mechanisms rely on cooperation of other network elements e.g. eNode B) and the accompanying test case for this requirement will check that the description provides sufficient detail in order for an evaluator to understand how the mechanism is designed.
Security Objective references: tba.
Test case:
Test Name: TC_SYSTEM_HANDLING_OF_OVERLOAD_SITUATIONS
Note: This test case covers requirements 4.2.3.3.1 and this requirement4.2.3.3.3.
Purpose:
Verify that the network product:
– has a detailed technical description of the overload control mechanisms used to deal with overload scenarios;
– has test results verifying the operation of the overload control mechanisms.
Procedure and execution steps:
Pre-Conditions:
– A document which provide a detailed technical description of the overload control mechanisms.
– Test results from a test execution phase of overload control mechanism testing.
Execution Steps
– The tester verifies that there is:
– A technical description providing a high-level overview of the overload control design:
– An overview of the types of overload scenarios that the network product overload control mechanisms are expected to handle.
– An overview of the overload control thresholds that the network product uses to trigger overload control mechanisms.
– Description of the types of attacks that may cause an overload to the network product and how these are handled.
– A description of how the network product discards or handles input during various overload situations including excessive overloads. i.e. where the overload is significantly greater than the thresholds where overload detection is triggered.
– A description of how the network product security functions operate and perform during overload.
– A description of how the network product shuts down or performs or takes other abatement or corrective actions during excessive overload conditions.
– The tester verifies that the test results:
– Contain details of the overload conditions used in the test execution that are consistent with the technical description document.
– Describe test procedures used to verify the overload control mechanisms.
– Contain data which demonstrates/indicates that the overload control mechanisms described in the technical description document have been implemented.
– Contain details of the test set-up including the mechanisms for creating the overload. Where simulators and/or scripts are used to artificially create a load then details of these should also be included.
Expected Results:
– A technical description provides a high-level overview of the overload control design.
– A overview of the types of overload scenarios and overload control thresholds that are considered.
– Description on the types of attacks that may cause an overload to the system and how these are handled.
– A description of how the network product discards or handles input during various overload situations.
– Describes if or how the network product security functions operate and perform during overload.
– If parts of the system shutdown or take other abatement or corrective actions these should be described.
Note: If some of the items listed above are not applicable to a network product then, in those cases, it should be clarified by the vendor why these items are not applicable.
The test results should:
– Contain details of the overload conditions used in the test execution that are consistent with the technical description document.
– Describe the test procedures used to verify the overload control mechanisms.
– Contain data which demonstrates/indicates that the overload control mechanisms described in the technical description document have been implemented.
– Contain details of the test set-up including the mechanisms for creating the overload.
Expected format of evidence:
Documentation showing each of the points in the results sections.
4.2.3.3.4 System robustness against unexpected input.
Requirement Name: System robustness against unexpected input.
Requirement Description: During transmission of data to a system it is necessary to validate input to the network product before processing. This includes all data which is sent to the system. Examples of this are user input, values in arrays and content in protocols. The following typical implementation error shall be avoided:
– No validation on the lengths of transferred data
– Incorrect assumptions about data formats
– No validation that received data complies with the specification
– Insufficient handling of protocol errors in received data
– Insufficient restriction on recursion when parsing complex data formats
– White listing or escaping for inputs outside the values margin
Security Objective references: tba.
Test case:
This requirement will be verified by Robustness and Protocol fuzzing tests as defined in clause 4.4.4 Robustness and fuzz testing.
4.2.3.3.5 Network Product software package integrity
Requirement name: Network product Software integrity validation
Requirement reference: to be done later
Requirement Description:
1) Software package integrity shall be validated in the installation/upgrade stage.
2) Network product shall support software package integrity validation via cryptographic means, e.g. digital signature. To this end, the network product has a list of public keys or certificates of authorised software sources, and uses the keys to verify that the software update is originated from only these sources.
3) Tampered software shall not be executed or installed if integrity check fails.
4) A security mechanism is required to guarantee that only authorized individuals can initiate and deploy a software update, and modify the list mentioned in bullet 2.
Security Objective references: SOFTWARE INTEGRITY
Test case:
Test Name: TC_SW_PKG_INTEGRITY_1
Purpose:
Verify that:
1. The Network Product validates the software package integrity during the installation/upgrade stage.
2. The software package integrity validation mechanism is performed using cryptographic mechanisms, e.g. digital signature using the public keys or certificates configured in the network product.
3. Software that fails an integrity check is rejected by the network product.
4. Only authorized users are allowed to install software.
Procedure and execution steps:
Pre-Conditions:
– A network product document containing information regarding software package integrity checks, including details of how the integrity check is carried out, where public keys or certificates of sources authorised to sign software packages are stored on the network product and who these sources are, and what evidence is created to prove that the integrity check has been executed and what the result of the check was. Documentation which describes the installation procedure including how a user is authorized and authenticated to perform installation process.
– A valid network product software load/package and one that is not-valid (or could be deemed to have been tampered with) are available.
Execution Steps
The tester checks the permissions required to install software on the network product ensuring that a user is properly authenticated by the network product and that they have the required access privileges to perform the installation activity.
The tester checks, when a software package is attempted to be installed on the network product, that the software package integrity check is executed (check for evidence of execution as described in network product documentation) and that valid software is allowed to be installed but invalid software is rejected.
The tester checks the access control permissions for the software package integrity checking process, the list of public keys of authorised software sources, and any related credentials or keys for the process, to ensure that the process cannot be controlled by persons that are not authorized to do so.
Expected Results:
– Evidence that the software package integrity check has been executed for both cases of software installation (valid and invalid software packages).
– Authentication and access control mechanisms are in operation for software package installation and around the software package integrity checking mechanism.
– The installation/upgrade operation fails when using an invalid software package.
– The installation/upgrade operation is successful when using a valid software package.
Expected format of evidence:
Snapshots containing the result of the installation of package A and B.
4.2.3.4 Authentication and authorization
4.2.3.4.1 Authentication policy
4.2.3.4.1.1 System functions shall not be used without successful authentication and authorization.
Requirement Name: System functions shall not be used or accessed without successful authentication and authorization.
Requirement Description:
The usage of a system function without successful authentication on basis of the user identity and at least one authentication attribute (e.g. password, certificate) shall be prevented. System functions comprise, for example network services (like SSH, SFTP, Web services), local access via a management console, local usage of operating system and applications. This requirement shall also be applied to accounts that are only used for communication between systems. An exception to the authentication and authorization requirement are functions for public use such as those for a Web server on the Internet, via which information is made available to the public.
Security Objective references: tba.
Test case:
Test Name: TC_SYS_FUN_USAGE
Purpose:
To ensure that system functions shall not be used without successful authentication and authorization.
Procedure and execution steps:
Pre-Conditions:
1. The manufacturer shall supply the list of system functions which include network services, local access via a management console, local usage of operating system and applications.
2. The manufacturer shall supply the list of access entries for system functions.
Execution Steps
The accredited evaluator’s test lab is required to execute the following steps:
1. The tester verifies, based on his/her own experience, that the list is adequate.
2. The tester verifies that the access entries to use system functions, which are listed by the manufacturer, require successful authentication on basis of the user name and at least one authentication attribute. This applies to both system functions that are locally accessible and those that are remotely accessible via a network interface.
Expected Results:
1. The network product does not allow access to any system function provided by the manufacturer without a successful user authentication.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Description of executed tests and commands
– Relevant output (e.g. Screenshot)
– Test result (Passed or not)
4.2.3.4.1.2 Accounts shall allow unambiguous identification of the user.
Requirement name: The network product shall use accounts that allow unambiguous identification of the user.
Requirement Description: Users shall be identified unambiguously by the network product. The network product shall support assignment of individual accounts per user, where a user could be a person, or, for Machine Accounts, an application, or a system. The network product shall not enable the use of group accounts or group credentials, or sharing of the same account between several users, by default. The network product shall support a minimum number of 50 individual accounts per user data base if not explicitly specified in a SCAS of a particular network product, so that accountability for each user is ensured even in large operator networks. The network product shall not support user access credentials unrelated to an account.
NOTE 1: The network product may support independent user data bases for different access methods, e.g. one data base for command shell access on OS level and another data base for GUI access. User data bases may be stored locally on the network product or on a central AAA system that the network product accesses for user authentication.
NOTE 2: This requirement does not preclude user group concepts for access control.
Security Objective references: tba.
Test case:
NOTE 3: Some typical default accounts suggest that they are shared amongst several persons (e.g. vendor_xy, support), or do not allow identification of individual users (e.g. guest, ftp, anonymous). In order to avoid overlap of this test case with clause 4.2.3.4.2.2, it is assumed for this test case that such accounts have been deleted or disabled in line with clause 4.2.3.4.2.2.
Test Name: TC_ACCOUNT_DOCUMENTATION
Purpose:
To ensure that documentation of the network product does not encourage or require the use of group accounts, group credentials, or sharing of the same account between several users. To ensure that the network product does not support credentials unrelated to an account.
Procedure and execution steps:
Pre-Conditions:
1) All user and group data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.
2) All predefined accounts and groups are identified in the documentation accompanying the Network Product.
3) Instructions of how administrator users can add accounts, groups, and credentials to the database(s) are provided in the documentation accompanying the Network Product.
4) The operations manual describes OAM user and group concepts supported by the network product.
Execution Steps:
The accredited evaluator’s test lab is required to execute the following steps:
1) Review the system documentation (in particular operations manual) whether it encourages or requires the use of group accounts, group credentials, or sharing of the same account between several users.
2) Review the system documentation whether the network product requires or supports entering credentials unrelated to an account, in order to perform specific actions, e.g. to enter a "master password" for access to privileged functions.
Expected Results:
1) The reviewed documentation is in line with the requirement.
Expected format of evidence:
Test report that lists the reviewed documentation (incl. release dates and versions) and the findings.
Test Name: TC_ACCOUNT_DEFAULTS
Purpose:
To ensure that the default setup of the network product does not enable the use of group accounts or group credentials.
Procedure and execution steps:
Pre-Conditions:
1) All user and group data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.
2) Instructions of how administrator users can view all existing accounts, groups, and protected credentials in the databases are provided in the documentation accompanying the Network Product.
Execution Steps:
The accredited evaluator’s test lab is required to execute the following steps:
1) After login via an account with necessary access rights (e.g. Admin) search in the databases for any group credentials. Example for Linux®: /etc/gshadow
Expected Results:
1) No group credentials are defined.
Expected format of evidence:
Test report that lists the reviewed documentation, reviewed user and group databases, and the findings.
Test Name: TC_ACCOUNT_NUMBER
Purpose:
To ensure that a minimum number of individual accounts per user data base is supported. The minimum number is defined in the requirement description of this clause.
Procedure and execution steps:
Pre-Conditions:
All user data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.
Execution Steps:
The accredited evaluator’s test lab is required to execute the following steps:
Create accounts until the minimum number of accounts is reached.
Expected Results:
Successful creation of the minimum number of accounts.
Expected format of evidence:
Test report that lists the reviewed documentation, reviewed user databases, and the findings.
4.2.3.4.2 Authentication attributes
4.2.3.4.2.1 Account protection by at least one authentication attribute.
Requirement Name: Account protection by at least one authentication attribute.
Requirement Description: The various user and machine accounts on a system shall be protected from misuse. To this end, an authentication attribute is typically used, which, when combined with the user name, enables unambiguous authentication and identification of the authorized user.
Authentication attributes include:
– Cryptographic keys
– Token
– Passwords
This means that authentication based on a parameter that can be spoofed (e.g. phone numbers, public IP addresses or VPN membership) is not permitted. Exceptions are attributes that cannot be faked or spoofed by an attacker.
NOTE: Several of the above options can be combined (dual-factor authentication) to achieve a higher level of security. Whether or not this is suitable and necessary depends on the protection needs of the individual system and its data and is evaluated for individual cases.
Security Objective references: tba.
TEST CASE:
Test Name: TC_ACCOUNT_PROTECTION
Purpose:
To ensure that all accounts are protected by at least one authentication attribute.
Procedure and execution steps:
Pre-Conditions:
1) All predefined accounts are identified in the documentation accompanying the Network Product.
2) Instructions of how to create new accounts are provided in the documentation accompanying the Network Product.
3) Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.
NOTE: No test is provided here for finding undocumented hard coded accounts as such tests may be impossible to define in a general way.
Execution Steps:
The accredited evaluator’s test lab is required to execute the following steps:
1) After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.
2) Attempt login to all predefined accounts identified (either documented or not) with and without using the respective authentication attribute.
3) Create a new account by following instructions in documentation.
4) Attempt login to the newly created account.
Expected Results:
1) It is not possible to login to any predefined account without using at least one authentication attribute that satisfies the conditions in the requirement.
2) It is not possible to login to any newly created account without usage of at least one authentication attribute that satisfies the conditions in the requirement.
Expected format of evidence: tba
4.2.3.4.2.2 Predefined accounts shall be deleted or disabled.
Requirement Name: Predefined accounts shall be deleted or disabled.
Requirement Description: All predefined or default accounts shall be deleted or disabled. Many systems have default accounts (e.g. guest, ctxsys), some of which are preconfigured with or without known passwords. These standard users shall be deleted or disabled. Should this measure not be possible the accounts shall be locked for remote login. In any case disabled or locked accounts shall be configured with a complex password as specified in clause 4.2.3.4.3.1 Password Structure. This is necessary to prevent unauthorized use of such an account in case of misconfiguration.
Exceptions to this requirement to delete or disable accounts are accounts that are used only internally on the system involved and that are required for one or more applications on the system to function. Also for these accounts remote access or local login shall be forbidden to prevent abusive use by users of the system.
Security Objective references: TBA.
TEST CASE:
Test Name: TC_PREDEFINED_ACCOUNT_DELETION
Purpose:
To ensure that predefined accounts are deleted or disabled unless there is specific exception as defined in the requirement 4.2.3.4.2.2.
Procedure and execution steps:
Pre-Conditions:
1) All predefined accounts are identified in the documentation accompanying the Network Product.
2) Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.
NOTE: No test is provided here for finding undocumented hard coded accounts as such tests may be impossible to define in a general way.
Execution Steps:
1) Check in documentation of the existence of any documented predefined account and what is the reason for existence.
2) After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.
3) Check the password complexity of such existing predefined accounts according to the test provided in clause 4.2.3.4.3.1.
4) Attempt remote login to such predefined accounts.
Expected Results:
1) Predefined accounts are either deleted/ disabled or, if existing, the reason is in accordance with the requirement exception.
2) If there are active predefined accounts in accordance with the requirement exception then there is no remote login possibility.
3) If predefined account is either disabled or locked then it shall anyway fulfil the complex password requirements as specified in clause 4.2.3.4.3.1 after enabling or unlocking it.
Expected format of evidence:
Evidence can be presented in the form of screenshot/screen-capture on showing for example a remote login failure or complexity of a password of e.g. locked or disabled accounts.
4.2.3.4.2.3 Predefined or default authentication attributes shall be deleted or disabled.
Requirement Name: Predefined or default authentication attributes shall be deleted or disabled.
Requirement Description: Predefined or default authentication attributes shall be deleted or disabled.
Normally, authentication attributes such as password or cryptographic keys will be preconfigured from producer, vendor or developer of a system. Such authentication attributes shall be changed by automatically forcing a user to change it on 1st time login to the system or the vendor provides instructions on how to manually change it.
Security Objective references: TBA.
TEST CASE:
Test Name: TC_PREDEFINED_AUTHENTICATION_ATTRIBUTES_DELETION
Purpose:
To ensure that predefined or default authentication attributes are deleted or disabled as defined in the requirement 4.2.3.4.2.3.
Procedure and execution steps:
Pre-Conditions:
1) Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.
2) All predefined accounts and their respective predefined or default passwords are identified in the documentation accompanying the Network Product.
NOTE: No test is provided here for finding undocumented hard coded accounts as such tests may be impossible to define in a general way.
Execution Steps:
1) Check in documentation of the existence of any documented predefined account and what is the login password or if any cryptographic key for such accounts is preinstalled.
2) After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.
3) Attempt login to such predefined accounts if existing.
Expected Results:
1) When login is attempted to any predefined account the user is automatically forced to change login password at first time login to the system.
2) If there is no automatic password change enforced then recommendation and clear instructions of how to manually change the password or how to create and reinstall a new cryptographic key exist in the documentation.
Expected format of evidence:
Evidence can be presented in the form of screenshot/screen-capture on how the network product prompts for password change at first login. Also extracts from product documentation with clear instructions of how to change any default password or cryptographic key.
4.2.3.4.3 Password policy
4.2.3.4.3.1 Password Structure
Requirement Name: Password Complexity rule
Requirement Description:
The setting by the vendor shall be such that a network product shall only accept passwords that comply with the following complexity criteria:
1) Absolute minimum length of 8 characters (shorter lengths shall be rejected by the network product). It shall not be possible setting this absolute minimum length to a lower value by configuration.
2) Comprising at least three of the following categories:
– at least 1 uppercase character (A-Z)
– at least 1 lowercase character (a-z)
– at least 1 digit (0-9)
– at least 1 special character (e.g. @;!$.)
The network product shall use a default minimum length of 10 characters. The minimum length of characters in the passwords shall be configurable by the operator. The default minimum length is the value configured by the vendor before any operator-specific configuration has been applied. The special characters may be categorized in sets according to their Unicode category.
The network product shall at least support passwords of a length of 64 characters or a length greater than 64 characters.
If a central system is used for user authentication, password policy is performed on the central system and additional assurance shall be provided that the central system enforces the same password complexity rules as laid down for the local system in this subclause. If a central system is not used for user authentication, the assurance on password complexity rules shall be performed on the Network Product.
When a user is changing a password or entering a new password, the system checks and ensures that it meets the password requirements. Above requirements shall be applicable for all passwords used (e.g. application-level, OS-level, etc.).
Security Objective references: Hardening.
Test case:
Test Name: TC_PASSWORD_STRUCT
Purpose:
To verify that password structure adheres to the password complexity criteria.
To verify that password structure is configurable as per the complexity criteria.
Procedure and execution steps:
Pre-Conditions:
1. Tester has rights to create user account.
Execution Steps
Execute the following steps:
A. Test Case 1
1. The tester logs into Network Product application using admin account.
2. The tester creates user A following the password complexity criteria.
3. The tester logs in as user A and attempts to change their password which contains characters from all four categories mentioned in the password complexity criteria.
B. Test Case 2
1. The tester logins with privileged account.
2. The tester modifies password structure policy on the network product by strengthening the policy (e.g. changing the minimum password length to 8+x, changing the minimum number of character Unicode categories to 4).
3. The tester logs in as user A and attempts to change their password to a password with a strength of less than that permitted by the policy strengthened in step 2 above.
Expected Results:
Tester can change password only if new password fulfil the password complexity criteria
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot containing the operation result or report in text form.
4.2.3.4.3.2 Password changes
Requirement Name: tba
Requirement Description:
If a password is used as an authentication attribute, then the system shall offer a function that enables a user to change his password at any time. When an external centralized system for user authentication is used it is possible to redirect or implement this function on this system.
Password change shall be enforced after initial login.
The system shall enforce password change based on password management policy. In particular, the system shall enforce password expiry.
Previously used passwords shall not be allowed up to a certain number (Password History).
The number of disallowed previously used passwords shall be:
– Configurable;
– Greater than 0;
– And its default value shall be 3. This means that the network product shall store at least the three previously set passwords. The maximum number of passwords that the network product can store for each user is up to the manufacturer.
When a password is about to expire a password expiry notification shall be provided to the user.
Above requirements shall be applicable for all passwords used(e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.
Security Objective references: tba.
Test case:
Test Name: TC_PASSWORD_CHANGES
Purpose:
– To check whether the network product is provisioned with the functionality that enables its user to change the password at any time.
– The network product enforces password change after initial login.
– To verify the new password adheres to the password management policy and also to verify whether it has password expiry rule.
– The network product is configured to disallow specified number of previously used passwords (Password History).
Procedure and execution steps:
Pre-Conditions:
1. Tester has account with username and password in the network product.
2. Network product vendor will provide documentation for password management policy which should include details on how to change the password, configure password expiry rule and disallowing specified number of previously used passwords.
3. The network product vendor shall supply information on how many passwords the network product can store for each user in the password history.
4. The tester has privilege to modify the number of disallowed previously used password.
Execution Steps
Execute the following steps:
A. Positive Test
Case 1:
Test case to enforce password change after initial login is covered in clause 4.2.3.4.2.3.
Case 2:
1 The tester logs into network product application using a privileged account .
2 The network product application generates password expiry notification for user Y to force user Y to change the password.
3 The tester logs out as a privileged user and logs on as user Y.
4. The tester is prompted to change his password and creates a new password by following the password policy management.
5 The network product application confirms change in password by, for example, displaying "Password Changed Successfully".
6 The tester successfully logs-in the network product application as user Y using the new password.
Case 3:
1. The tester logs into network product application using a privileged account.
2. Tester configures the network product application for number of disallowed previously used passwords to x
3. The tester requests for a password change for user Y.
4. The tester logs out of the privileged account and logs on as user Y
5. The tester creates a new password by following the password policy management.
6. If the password is not equal to any of the x previously used passwords, the network product application still accepts the new password and displays "Password Changed Successfully".
B. Negative Test
Case 1:
Test case to enforce password change after initial login is covered in clause 4.2.3.4.2.3.
Case 2:
No negative test case for this scenario.
Case 3:
1. The tester logs into network product application using privileged account.
2. Tester configures the network product application for number of disallowed previously used passwords to x for user Y.
3. The tester logs out of the privileged account and logs in as user Y
4. The tester requests for a password change.
5. The tester sets the new password to a value that is among the last x passwords used previously x times.
Expected Results:
A. Positive Test
Case 1:
Expected result for enforcing password change after initial login is covered in clause 4.2.3.4.2.3.
Case 2:
Tester can successfully change the password.
Case 3:
Tester can successfully change the password.
B. Negative Test
If the negative test case passes, this shows that network product application does not work properly and it violates the requirement.
Case 1:
Expected result for enforcing password change after initial login is covered in clause 4.2.3.4.2.3.
Case 2:
No negative test case for this scenario.
Case 3:
The tester cannot successfully change the password.
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot contains the operation result.
4.2.3.4.3.3 Protection against brute force and dictionary attacks
Requirement Name: Protection against brute force and dictionary attacks
Requirement Description:
If a password is used as an authentication attribute, a protection against brute force and dictionary attacks that hinder password guessing shall be implemented.
Brute force and dictionary attacks aim to use automated guessing to ascertain passwords for user and machine accounts. Various measures or a combination of these measures can be taken to prevent this.
The most commonly used protection measures are:
1) Using the timer delay (this delay could be the same or increased depending the operator’s policy for each attempt, e.g. double the delay, or 5 minutes delay, or 10 minutes delay) for each newly entered password input following an incorrect entry ("tar pit").
2) Blocking an account following a specified number of incorrect attempts, refer to 4.2.3.4.5. However it has to be taken into account that this solution needs a process for unlocking and an attacker can force this to deactivate accounts and make them unusable.
3) Using CAPTCHA to prevent automated attempts (often used for Web applications).
4) Using a password blacklist to prevent vulnerable passwords.
NOTE 1: Password management and blacklist configuration may be done in a separate node that is different to the node under test, e.g. a SSO server or any other central credential manager.
In order to achieve higher security, it is often meaningful to combine two or more of the measures named here. It is left to the vendor to select appropriate measures.
Above requirements shall be applicable for all passwords used (e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.
Security Objective references: tba.
Test case:
Test Name: TC_PROTECT_AGAINST_BRUTE_FORCE_AND_DICTIONARY_ATTACKS
This test applies only when the most commonly used protection measures used in the requirement are implemented. If they are not implemented, then the vendor documentation needs to provide alternative measures and the tester needs to develop suitable tests for these alternative measures. Since a vendor is free to select appropriate measures, only the vendor selected measures are to be tested.
Purpose:
To ensure that the system uses a mechanism with adequate protection against brute force and dictionary attacks
To check whether system follows commonly used preventive measures which are mentioned below.
1. Using the timer delay (e.g. doubling wait times after every incorrect attempt, or 5 minutes delay, or 10 minutes delay) after each incorrect password input ("tar pit").
2. Blocking an account following a specified number of incorrect attempts (typically 5). However administrator has to keep in account that this solution needs a process for unlocking and an attacker can utilize this process to deactivate the accounts and make them unusable.
3. Using CAPTCHA to prevent automated attempts (often used for Web interface).
4. Using a password blacklist to prevent vulnerable passwords.
Procedure and execution steps:
Pre-Conditions:
1. The password policy management of the network product is configured to use the timer delay after each incorrect password input.
2. The password policy management is configured to block an account following a specified number of incorrect password attempts (typically 5).
3. The web interface should be configured with CAPTCHA feature to prevent automated attempts.
4. CAPTCHA feature is optional and test is done only if implemented.
5. A password blacklist is configured by the tester. At least one blacklisted password (a password that meets the complexity criteria but is blacklisted) is documented.
NOTE 2: Password management and blacklist configuration may be done in a separate node that is different to the node under test, e.g. a SSO server or any other central credential manager.
6. Tester has valid credentials as an authorized user.
Execution Steps
Execute the following steps:
A. Positive Test
Case 1:
Test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.
Case 2:
Test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.
Case 3:
1. The network product’s login web interface is configured with CAPTCHA feature.
2. Tester enters the valid password and correct CAPTCHA
3. Tester can successfully log into the network product.
In some cases the network product class can have two or more of the attack prevention methods available, which are a combination of Cases 1-3. In such cases the tester will need to run a combination of these test cases.
B. Negative Test
Case 1:
Test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.
Case 2:
Test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.
Case 3:
1. The network product’s login web interface is configured with CAPTCHA feature.
2. Tester enters the valid password without CAPTCHA.
Case 4:
1. The tester tries to change the password to the blacklisted password.
Expected Results:
A. Positive Test
Case 1:
Expected result for the test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.
Case 2:
Expected result for the test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.
Case 3:
Tester can login only after entering the correct password and CAPTCHA.
B. Negative Test
Case 1:
Expected result for the use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.
Case 2:
Expected result for the test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.
Case 3:
Tester cannot successfully log in to the network product.
Case 4:
Tester cannot successfully change the password to the blacklisted password.
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot containing the operation result.
4.2.3.4.3.4 Hiding password display
Requirement Name: tba
Requirement Description:
The password shall not be displayed in such a way that it could be seen and misused by a casual local observer. Typically, the individual characters of the password are replaced by a character such as "*". Under certain circumstances it may be permissible for an individual character to be displayed briefly during input. Such a function is used, for ex ample, on smartphones to make input easier. However, the entire password is never output to the display in plaintext.
Above requirements shall be applicable for all passwords used(e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.
Security Objective references: tba.
Test case:
Test Name: TC_HIDING_PASSWORD_DISPLAY
Purpose:
Verify that the given password is not visible to the casual local observer.
Procedure and execution steps:
Pre-Conditions:
Tester has account with username and password in the network product.
Execution Steps
Execute the following steps:
1. The network product will display the login screen.
2. The tester enters the username.
3. The tester enters the password.
Expected Results:
The password shall not be displayed in such a way that it could be seen and misused by a casual local observer. Typically, the individual characters of the password are replaced by a character such as "*". Under certain circumstances it may be permissible for an individual character to be displayed briefly during input. Such a function is used, for ex ample, on smartphones to make input easier. However, the entire password is never output to the display in plaintext.
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot contains the operation results.
4.2.3.4.4 Specific Authentication use cases
4.2.3.4.4.1 Network Product Management and Maintenance interfaces
Requirement Name: Network Product Management and Maintenance interfaces
Requirement Description: The network product management shall support mutual authentication mechanisms, the mutual authentication mechanism can rely on the protocol used for the interface itself or other means.
Security Objective references: Secure Network Product Administration.
Test case:
Test Name: TC_MUTUAL_AUTHENTICATION-ON_NETWORK_PRODUCT_MANAGEMENT_PROTOCOLS
Purpose:
Verify that:
There is mutual authentication of entities for management interfaces on the network product.
Procedure and execution steps:
Pre-conditions: Documentation that lists each of the management protocols and describes the authentication mechanism used for each one.
Execution Steps
1. The tester checks that the authentication mechanisms have been configured on the network product.
2. The tester triggers communication between network product and a test entity that has a legitimate authentication credential.
3. Then, the tester triggers communication between network product and a test entity that doesn’t have a legitimate authentication credential.
Expected results:
– Mutual authentication is successful and communication between network product and the entity with correct credentials can be established.
– Mutual authentication fails and communication between the network product and the entity with incorrect credentials cannot be established.
Expected format of evidence: Test result pass/fail recorded by tester.
4.2.3.4.5 Policy regarding consecutive failed login attempts
Requirement Name: tba
Requirement Description:
a) The maximum permissible number of consecutive failed user account login attempts should be configurable by the operator. The definition of the default value set at manufacturing time for maximum number of failed user account login attempts shall be less than or equal to 8, typically 5. After the maximum permissible number of consecutive failed user account login attempts is exceeded by a user there shall be a block delay in allowing the user to attempt login again. This block delay and also the capability to set period of the block delay, e.g. double the delay, or 5 minutes delay, or 10 minutes delay, after each login failure should be configurable by the operator. The default value set at manufacturing time for this delay shall be greater than or equal to 5 sec.
b) If supported, infinite (permanent) locking of an account that has exceeded maximum permissible number of consecutive failed user account login attempts should also be possible via configuration, with the exception of administrative accounts which shall get only temporarily locked.
Security Objective references: tba.
TEST CASE:
Test Name: TC_FAILED_LOGIN_ATTEMPTS
Purpose:
To ensure that the policy regarding failed login attempts is adhered to.
Case 1: Testing for requirement 4.2.3.4.5 a)
Procedure and execution steps:
Pre-Conditions:
1) At least one user account has been created as per manufacturer’s instructions.
2) Directions of how to configure the maximum permissible number of consecutive failed user account login attempts and the default value of this number are identified in the documentation accompanying the Network Product. Default value shall be stated as well.
3) Directions of how to configure the block delay in allowing a user attempt to login again when the number of failed login attempts has exceeded the maximum number are identified in the documentation accompanying the Network Product. Default value of the delay shall be stated as well.
Execution Steps:
The accredited evaluator’s test lab is required to execute the following steps:
1) Check default values from precondition 2 and 3.
2) Perform consecutive failed login attempts for the user account until the default maximum number of precondition 2 is reached.
3) Attempt again one extra login, which fails again.
4) Attempt one extra login in less time than the default for the delay of precondition 3, using the correct credentials.
5) Attempt one extra login in more time than the default for the delay of precondition 3, using the correct credentials.
Expected Results:
1) Default values from precondition 2 and 3 are in accordance with the requirement.
2) In execution step 4, the login attempt shall be rejected in all cases.
3) In execution step 5, the login attempt shall be accepted.
4) In execution step 6, it is verified that the user can login only at the last login attempt.
Expected format of evidence: tba
Case 2: Testing for requirement 4.2.3.4.5 b)
Procedure and execution steps:
Pre-Conditions:
1. At least one user account has been created as per manufacturer’s instructions.
2. Directions of how to configure the maximum permissible number of consecutive failed user account login attempts and the default value of this number are identified in the documentation accompanying the Network Product. Default value shall be stated as well.
3. Directions of how to optionally configure permanent locking for non-administrative accounts shall be stated as well.
Execution Steps:
The accredited evaluator’s test lab is required to execute the following steps:
1. Check default values from precondition 2.
2. Perform consecutive failed login attempts for the user account until the default maximum number of precondition 2 is reached.
3. Attempt again one extra login, which fails again.
4. Attempt one extra login in more time than the default for the delay of precondition 3, using the correct credentials.
5a. If supported enable permanent locking of accounts exceeding the maximum permissible number of consecutive failed user account login attempts and repeat steps 1-4 for a normal user.
5b. If supported enable permanent locking of accounts exceeding the maximum permissible number of consecutive failed user account login attempts and repeat steps 1-4 for a user with administrative access rights.
Expected Results:
In execution step 5a it is verified that the user cannot login at any execution step.
In execution step 5b it is verified that an administrator user can successfully login only at execution step 5b.
Expected format of evidence: tba
4.2.3.4.6 Authorization and access control
4.2.3.4.6.1 Authorization policy
Requirement Name: tba
Requirement Description:
The authorizations for accounts and applications shall be reduced to the minimum required for the tasks they have to perform.
Authorizations to a system shall be restricted to a level in which a user can only access data and use functions that he needs in the course of his work. Suitable authorizations shall also be assigned for access to files that are components of the operating system or of applications or that are generated by the same (e.g. configuration and logging files).
Alongside access to data, execution of applications and components shall also take place with rights that are as low as possible. Applications should not be executed with administrator or system rights.
Security Objective references: tba.
Test case: verify authorization policy is in place and that user access and data access in the system are according to the authorization policy.
Procedure and execution steps:
Pre-Conditions:
Documentation describing the authorization policy defined for the system including details on the lowest access rights assigned to user accounts, access to data, application execution and components.
Execution Steps:
1. Assign access rights (e.g. read only) to user accounts, data files, and applications.
2. Operations, that are allowed as per authorization policy (as defined in the network product documentation), are attempted via the different user accounts, data files, and applications.
Expected Results:
1. User accounts, data files, and applications are allowed to be accessed (e.g. able to read but not write to a file, able to execute an application as a user account without administrator rights, etc.) according to the access rights assigned.
2. User accounts, data files, and applications are not allowed to be accessed above the access rights assigned (e.g. able to write to a read only file, able to execute an application as an administrator, etc.).
Expected format of evidence:
Pass/fail results as recorded by the tester.
4.2.3.4.6.2 Role-based access control
Requirement Name: tba
Requirement Description:
The network product shall support Role Based Access Control (RBAC). A role-based access control system uses a set of controls which determines how users interact with domains and resources. The domains could be Fault Management (FM), Performance Management (PM), System Admin, etc. The RBAC system controls how users or groups of users are allowed access to the various domains and what type of operation they can perform, i.e. the specific operation command or command group (e.g. View, Modify, Execute).
The network product supports RBAC, in particular, for OAM privilege management for network product Management and Maintenance, including authorization of the operation for configuration data and software via the network product console interface.
Security Objective references: tba.
Test case:
Purpose:
Verify that users are granted access with role-based privileges.
Procedure and execution steps:
Pre-Conditions:
Documentation describing the role based access control system including details on which user roles are defined.
Execution Steps
1. User accounts which are assigned to different access roles are created.
2. Operations, that are allowed by different roles (as defined in the network product documentation), are attempted via the different user accounts.
Expected Results:
1. Users that are assigned to a role that is not allowed to execute an operation are prevented from executing the operation.
2. Users that are assigned to a role that is allowed to execute an operation can successfully execute the operation.
Expected format of evidence:
Pass/fail results as recorded by the tester.
4.2.3.5 Protecting sessions
4.2.3.5.1 Protecting sessions – logout function
Requirement Name: Protecting sessions – logout function
Requirement Description: The system shall have a function that allows a signed in user to logout at any time. All processes under the logged in user ID shall be terminated on log out. The network product shall be able to continue to operate without interactive sessions.
Only for debugging purposes, processes under a logged in user ID may be allowed to continue to run after detaching the interactive session.
Security Objective references: tba.
Test Name: TC_PROTECTING_SESSION_LOGOUT
Purpose:
To ensure a signed in user can logout at any time.
Procedure and execution steps:
Pre-Conditions:
– The manufacturer shall declare that it has a function that allows a signed in user to logout at any time.
– The tester has privileges to create a new account or use an existing account.
Execution Steps:
The accredited evaluator’s test lab is required to execute the following steps:
1) The tester creates a new account.
2) The tester uses the new account or an existing account to log into network product. After x minutes the tester tries to logout network product.
NOTE: The value of x can be arbitrarily set by the tester.
Expected Results:
– The tester can use a new account or an existing account to log into network product and logout network product after x minutes.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Settings, and configurations used
– Test result (Passed or not)
4.2.3.5.2 Protecting sessions – Inactivity timeout
Requirement Name: Protecting sessions – inactivity timeout
Requirement Description: An OAM user interactive session shall be terminated automatically after a specified period of inactivity. It shall be possible to configure an inactivity time-out period.
Note: The kind of activity required to reset the timeout timer depends on the type of user session.
Test Name: TC_PROTECTING_SESSION_ INAC TIMEOUT
Purpose:
To ensure an OAM user interactive session shall be terminated at inactivity timeout.
Procedure and execution steps:
Pre-Conditions:
– The tester has privileges to create an OAM user interactive session.
– The tester has privileges to configure the inactivity time-out period for user interactive session.
– Session log should be enabled.
Execution Steps
1. The tester creates OAM user A interaction session.
2. The tester configures the inactivity time-out period for user A to x minute, for example 1 minute.
3. The tester does not make any actions on the network production in x minutes. After that, the tester checks whether OAM user A interaction session has been terminated automatically.
Expected Results:
– In step 3, OAM user A interaction session has been terminated automatically after x minute.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Session log
– Settings, protocols and configurations used
– Test result (Passed or not)
Security Objective references: tba.
4.2.3.6 Logging
4.2.3.6.1 Security event logging
Requirement Name: Security event logging
Requirement Description: Security events shall be logged together with a unique system reference (e.g. host name, IP or MAC address) and the exact time the incident occurred. For each security event, the log entry shall include user name and/or timestamp and/or performed action and/or result and/or length of session and/or values exceeded and/or value reached.
IETF RFC 3871, section 2.11.10 specifies the minimum set of security events. Each vendor shall document what security events the product logs so that it can be verified by testing.
In particular, it shall be possible to log the following events (which are intended to be supported by the network product and which can be enabled by default at manufacturing time or at a later time by the operator):
|
EventTypes |
Description |
Event data to be logged |
|
Incorrect login attempts |
Records any user incorrect login attempts to the network product |
• Username, • Source (IP address) if remote access • Timestamp |
|
Administrator access |
Records any access attempts to accounts that have system privileges. |
• Username, • Timestamp, • Length of session, • Source (IP address) if remote access |
|
Account administration |
Records all account administration activity, i.e. configure, delete, enable, and disable. |
• Administrator username, • Administered account, • Activity performed (configure, delete, enable and disable) • Timestamp |
|
Resource Usage |
Records events that have been triggered when system parameter values such as disk space, CPU load over a longer period have exceeded their defined thresholds. |
• Value exceeded, • Value reached (Here suitable threshold values shall be defined depending on the individual system.) • Timestamp |
|
Configuration change |
Changes to configuration of the network device |
• Change made • Username |
|
Reboot/shutdown/crash |
This event records any action on the network device that forces a reboot or shutdown OR where the network device has crashed. |
• Action performed (reboot, shutdown, etc.) • Username (for intentional actions) • Timestamp |
|
Interface status change |
Change to the status of interfaces on the network device (e.g. shutdown) |
• Interface name and type • Status (shutdown, missing link, etc.) • Timestamp |
In addition, optionally it shall be possible to log also the following event (if supported):
|
EventTypes |
Description |
Event data to be logged |
|
Change of group membership or accounts |
Any change of group membership for accounts |
• Administrator username, • Administered account, • Activity performed (group added or removed) • Timestamp. |
Security Objective references: tba.
Test case:
Test Name: TC_SECURITY_EVENT_LOGGING
Purpose:
To verify that the network product correctly logs all required security event types.
Procedure and execution steps:
Pre-Conditions:
– The following information shall be provided by the documentation accompanying the network product:
– The log where the event is recorded and how it can be accessed (e.g. the complete path).
– If the event type is enabled by default or how to enable it.
– What O&M services can be used on the Network Product in the configuration according to the pre-requisites for testing in clause 4.1 and how to use them.
– The tester has the needed administrative privileges to sufficiently perform the tests
– If needed for testing specific O&M services, a tester machine is available.
Execution Steps
For each O&M service perform the following test steps
– The Tester sequentially triggers each security event listed in the requirement, while covering each option detailed in the individual security event descriptions.
– The Tester verifies whether the security events, and their individual options, were correctly logged. In particular it is verified whether they include at least the event data specified as required to be logged.
Expected Results:
All security events are appropriately logged, including all required event data.
Expected format of evidence:
The testing report contains the following information for each security event:
– List of O&M services
– Commands executed per O&M services
– The relevant parts of the logs in appropriate form (e.g. file, screenshot)
– Test result (Passed or not)
4.2.3.6.2 Log transfer to centralized storage
Requirement Name: Log transfer to centralized storage
Requirement Description:
a) The Network Product shall support forwarding of security event logging data to an external system. Secure transport protocols in accordance with clause 4.2.3.2.4, shall be used.
b) Log functions should support secure uploading of log files to a central location or to an external system for the Network Product that is logging.
Security Objective references: tba.
Test Name: TC_LOG TRANS_TO_CENTR STORAGE
Purpose:
To ensure log shall be transferred to centralized storage.
Procedure and execution steps:
Pre-Conditions:
– The manufacturer shall list the standard protocols which transfer security event logging data.
– The session between network product and central location or external system for network product log functions has been set up.
– The tester has privilege to operate network product and related logs can be outputted.
Execution Steps
1. The tester configures the network product to forward event logs to an external system (according to bullet a) of requirement) and related logs are sent out.
2. The tester checks whether the used transport protocol is secure protocol.
3. The tester checks whether the central location or external system for network product log functions has stored the related logs.
4. The tester configures the network product for secure upload of event log files to an external system (according to bullet b) of requirement) and performs a log file upload.
5. The tester checks whether the used transport protocol for log file upload is a secure standard protocol.
6. The tester checks whether the central location or external system for network product log functions has stored the related logs.
Expected Results:
– The listed transport protocols are secure protocols.
– The used transport protocol for log file upload is a secure standard protocol.
– The tester finds that the central location or external system for network product log functions has stored the related logs.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Settings, protocols and configurations used,
– Screenshot
– Test result (Passed or not)
4.2.3.6.3 Protection of security event log files
Requirement Name: Protection of security event log files
Requirement Description: The security event log shall be access controlled (file access rights) so only privileged users have access to the log files.
Security Objective references: tba.
Test case:
Purpose:
Verify that the log(s) is(are) only accessible by privileged user(s).
Procedure and execution steps:
Pre-Conditions:
– Documentation describing where logs are stored and how these logs are accessed and the Network Product interfaces that these logs can be access from.
Execution Steps
1. The tester attempts to access log files using users accounts with and without the correct permissions for accessing log files.
2. Repeat the test as described in step 1 using each of the interfaces as described in the Network Product documentation.
Expected Results:
The tester checks that log files are accessible when a user with the appropriate authorisation attempts to access them and fails when a user without the correct permissions attempts to access them
Expected format of evidence:
Pass/fail result as recorded by the tester.
4.2.4 Operating systems
4.2.4.1 General operating system requirements and related test cases
4.2.4.1.1 Availability and Integrity
4.2.4.1.1.1 Handling of growing content
Requirement Name: Growing (dynamic) content shall not influence system functions.
Requirement Description:
Growing or dynamic content (e.g. log files, uploads) shall not influence system functions. A file system that reaches its maximum capacity shall not stop a system from operating properly. Therefore, countermeasures shall be taken such as usage of dedicated filesystems, separated from main system functions, or quotas, or at least a file system monitoring to ensure that this scenario is avoided.
Test Case:
Test Name: TC_HANDLING_OF_GROWING_CONTENT
Purpose:
To verify that the growing or dynamic content does not influence system functions.
Procedure and execution steps:
Pre-Conditions:
1. Growing or dynamic content sources like e.g. log files and their paths are documented.
2. Measures that are taken to protect system functions from growing or dynamic content that may exhaust file system capacity are documented.
3. All logging capabilities that are not enabled by default are enabled manually as per the documentation instructions.
Execution Steps
1. Tester checks that the sources that are susceptible to being exhausted have been documented and measures aimed to counteract this are described.
2. Tester enables monitoring of the system operation.
3. Tester initiates traffic that causes increase of log files and monitors the system behaviour until the log file either reaches its quota or until file system is exhausted.
4. In case file uploading is allowed (e.g. via SFTP) the tester initiates file uploading and tries to exhaust the file system.
Expected Results:
1. It is verified that the taken measures are sufficient so that system operation is not influenced by growing or dynamic content at any case.
Expected format of evidence:
System monitoring data (e.g. Alarms, logs, CPU utilization, etc.).
4.2.4.1.1.2 Handling of ICMP
Requirement Name: Processing of ICMPv4 and ICMPv6 packets
Requirement Description:
Processing of ICMPv4 and ICMPv6 packets which are not required for operation shall be disabled on the network product. In particular, there are certain types of ICMP4 and ICMPv6 that are not used in most networks, but represent a risk.
ICMP message types which on receipt lead to responses or to configuration changes are not mentioned in this requirement, but they may be necessary to support relevant and specified networking features. Those must be documented.
Certain ICMP types are generally permitted and do not need to be specifically documented. Those are marked as "Permitted" in below table.
The network product shall not send certain ICMP types by default, but it may support the option to enable utilization of these types (e.g. for debugging). This is marked as "Optional" in below table.
|
Type (IPv4) |
Type (IPv6) |
Description |
Send |
Respond to |
|
0 |
128 |
Echo Reply |
Optional (i.e. as automatic reply to "Echo Request") |
N/A |
|
3 |
1 |
Destination Unreachable |
Permitted |
N/A |
|
8 |
129 |
Echo Request |
Permitted |
Optional |
|
11 |
3 |
Time Exceeded |
Optional |
N/A |
|
12 |
4 |
Parameter Problem |
Permitted |
N/A |
|
N/A |
2 |
Packet Too Big |
Permitted |
N/A |
|
N/A |
135 |
Neigbor Solicitation |
Permitted |
Permitted |
|
N/A |
136 |
Neighbor Advertisement |
Permitted |
N/A |
The network product shall not respond to, or process (i.e. do changes to configuration), under any circumstances certain ICMP message types as marked in below table.
|
Type (IPv4) |
Type (IPv6) |
Description |
Send |
Respond to |
Process (i.e. do changes to configuration) |
|
5 |
137 |
Redirect |
N/A |
N/A |
Not Permitted |
|
13 |
N/A |
Timestamp |
N/A |
Not Permitted |
N/A |
|
14 |
N/A |
Timestamp Reply |
Not Permitted (i.e. as automatic reply to "Timestamp") |
N/A |
N/A |
|
N/A |
133 |
Router Solicitation |
N/A |
Not Permitted |
Not Permitted |
|
N/A |
134 |
Router Advertisement |
N/A |
N/A |
Not Permitted |
Test Case:
The test for this requirement can be carried out using a suitable tool or manually by performing the steps described below. If a tool is used then the tester needs to provide evidence, e.g. by referring to the documentation of the tool, that the tool actually provides functionality equivalent to the steps described below.
Test Name: TC_HANDLING_OF_ICMP
Purpose:
To verify that the network product does not reply to certain ICMP types in accordance with the requirement. To verify that the network product does not send ‘Time Exceeded’.
To verify that the network product does not process the following ICMPv4 and ICMPv6 types:
– "Redirect (5)"
– Router Solicitation
– Router Advertisement
Procedure and execution steps:
Pre-Conditions:
– The tester knows whether the network product supports IPv4 and/or IPv6:
– If applicable, the tester has the needed system privileges for confirming that the ICMP messages with types "Not Permitted" to process are indeed not leading to configuration changes..
– If applicable, the tester has the needed system privileges for confirming that certain ICMP message types are dropped by the network product on receipt.
– A tester machine is available and equipped with a suitable ICMP packets generator tool.
Execution Steps
The following needs to be done for all IP protocol versions (IPv4 and/or IPv6) supported by the network element.
For verifying that the network product does not reply to ICMP messages with types where this is not permitted: The tester sends samples of the applicable ICMP messages from the tester machine to the network product and verifies by appropriate means that
– the messages are dropped on receipt by the network product (e.g. by means of appropriate firewall rules),
– or no response is sent out towards the test machine,
– or there are other means ensuring that the ICMP messages cannot trigger a response.
For verifying that the network product does not change its configuration due to receiving ICMP messages with types where this is not permitted: The tester sends samples of the applicable ICMP messages from the tester machine to the network product and verifies by appropriate means that
– the messages are dropped on receipt by the network product (e.g. by means of appropriate firewall rules),
– or the network product’s applicable system configuration remains unchanged upon receipt of the messages,
– or there are other means ensuring that the ICMP messages cannot lead to configuration changes.
The tester utilizes appropriate means to verify consistency between the documentation in regard to ICMP and the network product.
Expected Results:
The ICMP messages which are "Not Permitted" to generate a response from the network product do not generate a response.
The ICMP messages which are "Not Permitted" to change the configuration of the network element do not change the configuration.
ICMP message types which lead to responses or to configuration changes on receipt, if neither mentioned in the requirement nor in the documentation, are not enabled.
Expected format of evidence:
The following information needs to be retained and included into the report as appropriate:
– Tools used and their configuration
– Tool output
– Test result (Passed or not)
4.2.4.1.1.3 Handling of IP options and extensions
Requirement Name: IP packets with unnecessary options or extension headers shall not be processed.
Requirement Description:
IP packets with unnecessary options or extension headers shall not be processed. IP options and extension headers (e.g. source routing) are only required in exceptional cases. So, all packets with enabled IP options or extension headers shall be filtered.
Test Case:
The test for this requirement can be carried out using a suitable tool or manually by performing the steps described below. If a tool is used then the tester needs to provide evidence, e.g. by referring to the documentation of the tool, that the tool actually provides functionality equivalent to the steps described below.
Test Name: TC_HANDLING-IP-OPTIONS-AND-EXTENSIONS
Purpose: To verify that the network product provides functionality to filter out IP packets with unnecessary options or extension headers.
Procedure and execution steps:
Pre-Conditions:
– The manufacturer declares in the documentation accompanying the network product at least the following information:
– The support of filtering capability for IP packets with unnecessary options or extensions headers.
– The actions performed by the network product when an IP packet with unnecessary options or extensions headers is received (e.g. the packet is dropped, the options or extensions are ignored and the packet is treated as if it has no IP options, etc.) .
– Guidelines on how to enable and configure this filtering capability.
– The network product has at least one physical interface named if1 supporting both IPv4 and IPv6. If the network product does not support IPv6 then IPv6 related steps and checks may be skipped.
– A network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available .
– The tester has administrative privileges.
– A tester machine is available with a tool able to send IPv4 packets with the IP Options and IPv6 packets (if supported by the network product) with Extension Header set (e.g. Scapy).
Execution Steps
1. The tester logs in the network product.
2. The tester configures on the network product a filtering rule to drop all IP packets containing an IP Option set
a) The tester establishes an O&M session on if1 interface
b) Using the tool (e.g. Scapy) the tester sends from the tester machine an IPv4 TCP SYN packet with an appropriate destination portto if1 interface without setting any IP Options
c) Using the network traffic analyser, the tester verifies that the IP packet is received by the network product and the tester verifies that the corresponding ACK message is sent back.
d) Using the tool (e.g. Scapy) the tester sends an IPv4 TCP SYN packet with an appropriate destination port and an IP Option set to the if1 interface
e) Using the network traffic analyser, the tester verifies that the IP packet is received by the network product but no ACK message is sent back. This confirms the packet is dropped as expected from the filtering rule.
3. The tester configures on the network product a filtering rule to drop all incoming packets based on specific Extension Header Types, e.g. packets with the Routing Header extension. Step 3 may be skipped if the network product does not support IPv6.
a) Using the tool (e.g. Scapy) the tester sends from the tester machine an IPv6 TCP SYN packet with an appropriate destination port to if1 interface without setting any extension header
b) Using the network traffic analyser, the tester verifies that the IP packet is received by the network product and the tester verifies that the corresponding ACK message is sent back.
c) Using the tool (e.g. Scapy) the tester sends an IPv6 TCP SYN packet with an appropriate destination port and an extension header set to the if1 interface
d) Using the network traffic analyser, the tester verifies that the IP packet is received by the network product but no ACK message is sent back. This confirms the packet is dropped as expected from the filtering rule.
Expected Results:
The network product discards IPv4 packets with unnecessary options or IPv6 packets (assuming the network product supports IPv6) with extension header.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Used tools and their configurations
– Settings and configurations used
– Pcap trace
– Screenshot
– Test result (Passed or not)
4.2.4.1.2 Authentication and Authorization
4.2.4.1.2.1 Authenticated Privilege Escalation only
Requirement Name: There shall not be a privilege escalation method in interactive sessions (CLI or GUI) which allows a user to gain administrator/root privileges from another user account without re-authentication.
Requirement Description:
There shall not be a privilege escalation method in interactive sessions (CLI or GUI) which allows a user to gain administrator/root privileges from another user account without re-authentication.. Implementation example: Disable insecure privilege escalation methods so that users are required to (re-)login directly into the account with the required permissions.
Test Case:
Test Name: TC_OS_PRIVILEGE
Purpose:
To ensure that privileged operating system functions shall not be used without successful authentication and authorization, and that violations of this requirement are documented and strictly limited in number and functionality.
Procedure and execution steps:
Pre-Conditions:
1. The manufacturer shall provide documentation of the operating system(s) used in the network product.
2. The manufacturer shall supply a list "A" of operating system functions which a system user can use to explicitly gain higher privileges, and how these functions are configured. Unix® example: sudo command and its configuration file /etc/sudoers.
3. The manufacturer shall supply a list "B" of operating system commands, GUI functions, and files which will execute specifically limited tasks automatically with higher privileges, even when used by a low-privileged user. List "B" shall also contain:
– configuration of these commands and GUI functions;
– owner and permission settings of files;
– justification for having the command, GUI function or file on the network product
Unix® example: root-owned files with SUID and SGID permissions.
Execution Steps
The accredited evaluator’s test lab is required to execute the following steps:
1. The tester logs into the network product and verifies that list "A" is accurate, based on his expert knowledge of the operating system(s) used in the network product, and operating system documentation.
2. The tester verifies that entries in the list "A" require successful authentication for all users without exception, on basis of the user name and at least one authentication attribute.
3. The tester logs into the network product and verifies that list "B" is accurate, based on his expert knowledge of the operating system(s) used in the network product, and operating system documentation. Unix® example: To list files with SUID and SGID permissions, the following commands can be used:
SUID: find / -perm -4000 -type f -exec ls {} \; > suid_files.txt
SGID: find / -perm -2000 -type f -exec ls {} \; > sgid_files.txt
4. The tester verifies that file entries in the list "B" do not have write permissions for anyone else than the owner.
5. The tester verifies that entries in the list "B" only allow execution of specifically limited tasks which are needed on this network product, based on his expert knowledge of the operating system(s) used in the network product, and operating system documentation.
6. The tester logs into the network product and tests for every entry in the list "B" that it does not provide a means to execute arbitrary functions with administrator/root privileges, e.g. via a shell escape.
Expected Results:
1. The network product does not allow a user to gain administrator/root privileges from another user account without re-authentication.
2. If a network product provides functions and files which execute specifically limited tasks automatically with higher privileges, it ensures that these limits cannot be bypassed.
3. The system documentation about means for a user to gain administrator/root privileges from another user account accurately describes the network product.
Expected format of evidence:
A test report provided by the accredited evaluator’s test lab which will consist of the following information:
– Documentation provided by the vendor: lists "A" and "B"
– Description of executed tests and commands
– Relevant output (e.g. screenshot or terminal log)
– Test result (passed or not passed)
4.2.4.2 UNIX® specific requirements and related test cases
4.2.4.2.1 General
NOTE: The term ‘UNIX®’ is throughout the present document meant to include all major UNIX®-like derivatives, including Linux®.
4.2.4.2.2 System account identification
Requirement Name: System account identification
Requirement Description: Each system account in UNIX® shall have a unique UID.
Security Objective references: tba.
Test case:
Test Name: TC_UNIQUE_SYSTEM_ACCOUNT_IDENTIFICATION
Purpose: To verify that UNIX® account UIDs are assigned uniquely.
Procedure and execution steps:
Pre-Conditions: UNIX® is used on the MME.
Execution Steps
1. Create several UNIX® accounts.
2. Check UIDs of created accounts and of existing system accounts and, in particular, the root account.
Expected Results: The UIDs are all different and, in particular, only the root account has UID = 0.
4.2.5 Web Servers
4.2.5.1 HTTPS
Requirement Name: HTTPS
Requirement Description: The communication between Web client and Web server shall be protected using TLS. The TLS profile defined in Annex E of TS 33.310 shall be followed with the following modifications:
Cipher suites with NULL encryption shall not be supported
Security Objective references: tba.
Test case:
Test Name: HTTPS
Purpose: Verify the above requirement.
Procedure and execution steps, expected results, expected format of evidence:
These are the same as for the test case in clause 4.2.3.2.4, except that, for execution step 2, it is tested that NULL encryption is not supported.
4.2.5.2 Logging
4.2.5.2.1 Webserver logging
Requirement Name: Webserver logging
Requirement Description: Access to the webserver shall be logged. The web server log shall contain the following information:
– Access timestamp
– Source (IP address)
– (Optional) Account (if known)
– (Optional) Attempted login name (if the associated account does not exist)
– Relevant fields in http request. The URL should be included whenever possible.
– Status code of web server response
Security Objective references: tba.
Test case:
Test Name: TC_WEBSERVER_LOGGING
Purpose:
Verify that all accesses to the webserver are logged with the required information.
Procedure and execution steps:
Pre-Condition:
Network Product documentation which contains information on log file location and procedure to access it.
Tester has the necessary privileges to access the log files.
Execution Steps
Execute the following steps:
1. The tester tries to login to the webserver using the correct and incorrect login credentials.
2. The tester verifies whether the login attempts were logged correctly with all of the required information.
Expected Results:
All webserver events are logged with all of the required information.
Expected format of evidence:
Testing report contains copies of the log file showing the captured information.
4.2.5.3 HTTP User sessions
Requirement Name: User sessions
Requirement Description:
To protect user sessions the Network Product shall support the following session ID and session cookie requirements:
1. The session ID shall uniquely identify the user and distinguish the session from all other active sessions.
2. The session ID shall be unpredictable.
3. The session ID shall not contain sensitive information in clear text (e.g. account number, social security, etc.).
4. In addition to the Session Idle Timeout (see clause 4.2.3.5.2 Protecting sessions – Inactivity timeout), the Network Product shall automatically terminate sessions after a configurable maximum lifetime This maximum lifetime defines the maximum session span. When the maximum lifetime expires, the session shall be closed, the session ID shall be deleted and the user shall be forced to (re)authenticate in the web application and to establish a new session. The default value for this maximum lifetime shall be set to 8 hours.
5. Session ID’s shall be regenerated for each new session (e.g. each time a user logs in).
6. The session ID shall not be reused or renewed in subsequent sessions.
7. The Network Product shall not use persistent cookies to manage sessions but only session cookies. This means that neither the "expire" nor the "max-age" attribute shall be set in the cookies.
8. Where session cookies are used the attribute ‘HttpOnly’ shall be set to true.
9. Where session cookies are used the ‘domain’ attribute shall be set to ensure that the cookie can only be sent to the specified domain.
10. Where session cookies are used the ‘path’ attribute shall be set to ensure that the cookie can only be sent to the specified directory or sub-directory.
11. The Network Product shall not accept session identifiers from GET/POST variables.
12. The Network Product shall be configured to only accept server generated session ID’s.
Security Objective references: tba.
Test case:
Purpose:
Verify that the above 12 session ID and session cookie requirements have been met.
Procedure and execution steps:
Pre-Conditions:
– The Network Product uses a session ID that is communicated between the client and Network Product to establish and maintain a session.
– Documentation describing how a session is maintained and where the session ID is stored / and how this is communicated and after how long sessions expire.
– The documentation should describe the algorithm used to generate the session IDs.
Execution Steps
1. The tester logs in repeatedly with different user IDs and a number of times with the same user ID in a row and collects the session IDs according to the documentation and the user IDs associated with them. The tester verifies that:
a. The session IDs are different between sessions of the same and different users;
b. The session IDs seems random based on his/her own experience. The tester may use tests like the bitstream test or the count-the-1s-tests from the diehard test suite. The tester documents how randomness was verified;
c. The session IDs are always different between sessions, also when the user ID is the same.
2. The tester verifies that when session cookies are used
a. neither the "expire" or the "max-age" is set;
b. the ‘HttpOnly’ is set to true;
c. the ‘domain’ attribute is set to the correct domain;
d. the ‘path’ attribute is set to the correct directory or sub-directory.
3. The tester verifies that it is impossible to:
a. access a session by retrieving the session ID and communicating the session ID through a POST or GET variable.
b. generate a session ID on the client by attempting to login with a custom generated session ID.
c. keep a session alive for longer than the configured maximum lifetime (by default 8 hours).
Expected Results:
1. A list of session IDs and user IDs that are different between sessions even when the tester has logged in with the same user and that are unpredictable as is confirmed by the entropy calculation.
2. A confirmation from the tester that the correct variables are indeed set.
3. A denied access to the tester when attempting the two login steps of step 3 and an expired session in step 3c.
Expected format of evidence:
A confirmation that the tester has confirmed that:
1. Session IDs follow the rules 1-3, 5, 6.
2. A session times out after 8 hours or sooner according to the documentation.
3. The correct cookie settings are used.
4. The network product does not accept customly generated session IDs and that session IDs over GET or POST are ignored.
4.2.5.4 HTTP input validation
Requirement Name: Input validation
Requirement Description:
The Network Product shall have a mechanism in place to ensure that web application inputs are not vulnerable to command injection or cross-site scripting attacks. The Network Product shall validate, filter, escape, and encode user-controllable input before it is placed in output that is used as a web page that is served to other users.
Security Objective references: tba.
Test case:
This requirement is covered by the basic vulnerability testing as described in clause 4.4.
4.2.6 Network Devices
4.2.6.1 Protection of Data and Information
Refer to clause 4.2.3.2 for requirements on protection of data and information.
4.2.6.2 Protecting availability and integrity
4.2.6.2.1 Packet filtering
Requirement Name: Packet filtering
Requirement Description:
The Network Product shall provide a mechanism to filter incoming IP packets on any IP interface (see RFC 3871 for further information).
In particular the Network Product shall provide a mechanism:
1) To filter incoming IP packets on any IP interface at Network Layer .and Transport Layer of the stack ISO/OSI.
2) To allow specified actions to be taken when a filter rule matches. In particular at least the following actions should be supported:
– Discard/Drop: the matching message is discarded, no subsequent rules are applied and no answer is sent back.
– Accept: the matching message is accepted.
– Account: the matching message is accounted for i.e. a counter for the rule is incremented. This action can be combined with the previous ones. This feature is useful to monitor traffic before its blocking.
3) To enable/disable for each rule the logging for Dropped packets, i.e. details on messages matching the rule for troubleshooting.
4) To filter on the basis of the value(s) of any portion of the protocol header.
5) To reset the accounting.
6) The Network Product shall provide a mechanism to disable/enable each defined rule.
Security Objective references: PROTECTED COMMUNICATIONS, HARDENING.
Test case:
Test Name: TC_PACKET_FILTERING
Purpose:
Verify that the system provides functionality for incoming packet filtering
Procedure and execution steps:
Pre-Conditions:
– The Network Product has packet filtering enabled.
– The Network Product has 2 different logical or physical Ethernet ports and each port is connected to a host.
Execution Steps
1. The tester configures the Network Product to only allow ICMP traffic from host 1.
2. The tester initiates ping traffic from host 1.
3. The tester initiates ping traffic from host 2.
Expected Results:
Host 1 will receive a ‘ping’ answer back, but host 2 will not.
Expected format of evidence:
NA
4.2.6.2.2 Interface robustness requirements
Requirement Name: Manipulated packets that are sent to an address of the network device shall not lead to an impairment of availability.
Requirement Description:
A network device shall be not affected in its availability or robustness by incoming packets, from other network element, that are manipulated or differing the norm. This means that appropriate packets shall be detected as invalid and be discarded. The process shall not be affecting the performance of the network device. This robustness shall be just as effective for a great mass of invalid packets as for individual or a small number of packets.
Examples of such packets are:
– Mass-produced TCP packets with a set SYN flag to produce half-open TCP connections (SYN flooding attack).
– Packets with the same IP sender address and IP recipient address (Land attack).
– Mass-produced ICMP packets with the broadcast address of a network as target address (Smurf attack).
– Fragmented IP packets with overlapping offset fields (Teardrop attack).
– ICMP packets that are larger than the maximum permitted size (65,535 Bytes) of IPv4 packets (Ping-of-death attack).
– Uncorrelated reply packets (i.e. packets which cannot be correlated to any request).
Sometimes the relevant behaviour of the network device will be configured. In other cases, the behaviour of the network device may only be verified by the relevant tests.
Security Objective references: PROTECTED COMMUNICATIONS, HARDENING.
Test case: Refer to Test Case in clause 4.4.4.
4.2.6.2.3 GTP-C Filtering
Requirement Name: GTP-C Filtering
Requirement Description:
The following capability is conditionally required:
– For each message of a GTP-C-based protocol, it shall be possible to check whether the sender of this message is authorized to send a message pertaining to this protocol.
NOTE 1: The check could be performed e.g. against a whitelist or blacklist of permitted message type / sender identity combinations.
– At least the following actions should be supported when the check is satisfied:
– Discard: the matching message is discarded.
– Accept: the matching message is accepted.
– Account: the matching message is accounted for, i.e. a counter for the rule is incremented. This action can be combined with the previous ones. This feature is useful to monitor traffic before its blocking.
This requirement is conditional in the following sense: It is required that at least one of the following two statements holds:
– The Network Product supports the capability described above and this is stated in the product documentation.
– The Network Product’s product documentation states that the capability is not supported and that the Network Product needs to be deployed together with a separate entity which provides the capability described above.
NOTE 2: Such a separate entity could e.g. be a GTP Firewall.
NOTE 3: Test cases for this separate entity are not provided in the present document, but are believed to be similar to them.
NOTE 4: The test cases are only applicable to all network product classes utilizing GTP-C based protocol.
Security Objective references: tba.
Test case:
The test case described here apply only when GTP-C filtering is provided on the Network Product itself.
Test Name: TC_GTP-C_FILTERING
Purpose:
To verify that the network product provides filtering functionalities for incoming GTP-C messages. In particular this test case verifies that:
1. The network product provides filtering of incoming GTP-C messages on any interface.
2. It is possible to block all GTP-C messages on those network product interfaces where they are unwanted.
3. It is possible to specify defined actions for each rule.
Procedure and execution steps:
Pre-Conditions:
– The network product has at least two physical interfaces, named if1 and if2.
– The tester has the privileges to configure GTP-C filtering on the network product.
– The manufacturer declares that the GTP-C filtering is supported.
– The manufacturer includes a guideline to configure the GTP-C filtering in the documentation accompanying the network product.
– A network traffic generator or a pcap file containing the GTP-C messages is available.
– A network traffic analyser on the network product (e.g. tcpdump) is available.
Execution Steps
1. The tester log in the network product.
2. The tester configures the network product with the following rules:
a) Accept only GTP-C EchoRequest messages on if1.
b) Discard all GTP-C messages on if2.
c) For each rule above the accounting is also enabled.
3. The tester turns on the network traffic analyser on if2.
4. The tester sends on if2 EchoRequest messages replying a pcap file or using a network generator.
a) Using the network analyser the tester verifies that the network product correctly receives the EchoRequest messages on if2.
b) Using the accounting, the tester verifies that the messages are discarded and that any response is sent back by the network product.
5. The tester sends to if1 EchoRequest messages replying a pcap file or using a network generator.
a) Using the network analyser, the tester verifies that the messages are correctly received by the network product.
b) The tester verifies that the GTP-C EchoRequest messages are not discarded because EchoResponse messages are sent back by the network product.
6. The tester verifies that the matching messages are correctly accounted for both rules.
7. The tester sends to if1 GTP-C messages different from EchoRequest replying a pcap file or using a network generator.
a) Using the network analyser, the tester verifies that the messages are correctly received by the network product.
b) Using the accounting, the tester verifies that the messages are discarded and that any response is sent back by the network product.
8. The tester deletes the previous rules and configures a new rule, i.e. to accept only GTP-C EchoRequest on if1 coming from a certain IP Address named IP1.
9. The tester sends GTP-C EchoRequest messages with source IP Address set to IP1:
a) Using the network analyser, the tester verifies that the messages are correctly received by the network product.
b) The tester verifies that the GTP-C EchoRequest messages are not discarded and EchoResponse messages are sent back by the network product.
10. The tester sends GTP-C EchoRequest messages with source IP Address set to IP2 different from IP1 using a network traffic generator or replying a pcap file.
a) Using the network analyser the tester verifies that the messages are correctly received by the network product.
b) The tester verifies that the GTP-C EchoRequest messages are discarded and that no EchoResponse messages are sent back.
Expected Results:
– For steps 4, 5, 6 and 7 the tester receives GTP-C EchoResponse messages from if1 only.
– For steps 4, 5, 6 and 7 the messages matching the rules are correctly accounted.
– For steps 8, 9, 10 the tester receives GTP-C EchoResponse messages only for the authorized source IP address.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– The used tool(s) name and version information
– Settings and configurations used
– Pcap trace
– Screenshot
Test result (Passed or not)
4.2.6.2.4 GTP-U Filtering
Requirement Name: GTP-U Filtering
Requirement Description:
The following capability is conditionally required:
– For each message of a GTP-U-based protocol, it shall be possible to check whether the sender of this message is authorized to send a message pertaining to this protocol.
NOTE 1: The check could be performed e.g. against a whitelist or blacklist of permitted message type / sender identity combinations.
– At least the following actions should be supported when the check is satisfied:
– Discard: the matching message is discarded.
– Accept: the matching message is accepted.
– Account: the matching message is accounted for, i.e. a counter for the rule is incremented. This action can be combined with the previous ones. This feature is useful to monitor traffic before its blocking.
This requirement is conditional in the following sense: It is required that at least one of the following two statements holds:
– The Network Product supports the capability described above and this is stated in the product documentation.
– The Network Product’s product documentation states that the capability is not supported and that the Network Product needs to be deployed together with a separate entity which provides the capability described above.
NOTE 2: Such a separate entity could e.g. be a GTP Firewall.
NOTE 3: Test cases for this separate entity are not provided in the present document, but are believed to be similar to them.
NOTE 4: The test cases are only applicable to all network product classes utilizing GTP-U based protocol.
Security Objective references: tba.
Test case:
The test case described here apply only when GTP-U filtering is provided on the Network Product itself.
Test Name: TC_GTP-U_FILTERING
Purpose:
To verify that the network product provides filtering functionalities for incoming GTP-U messages. In particular this test case verifies that:
1. The network product provides filtering of incoming GTP-U messages on any interface.
2. It is possible to block all GTP-U messages on those network product interfaces where they are unwanted.
3. It is possible to specify defined actions for each rule.
Procedure and execution steps:
Pre-Conditions:
– The network product has at leastone physical interface named if1 and may have another physical interface named if2 .
– The tester has the privileges to configure GTP-U filtering on the network product.
– The manufacturer declares that the GTP-U filtering is supported.
– The manufacturer includes a guideline to configure the GTP-U filtering in the documentation accompanying the network product.
– A network traffic generator or a pcap file containing the GTP-U messages is available.
– A network traffic analyser on the network product (e.g. tcpdump) is available.
NOTE: If the network product has only one physical interface named if1, execution steps on if2 are not needed.
Execution Steps
1. The tester log in the network product.
2. The tester configures the network product with the following rules:
a) Accept only GTP-U EchoRequest messages on if1.
b) Discard all GTP-U messages on if2.
c) For each rule above the accounting is also enabled.
3. The tester turns on the network traffic analyser on if2.
4. The tester sends on if2 EchoRequest messages replying a pcap file or using a network generator.
a) Using the network analyser the tester verifies that the network product correctly receives the EchoRequest messages on if2.
b) Using the accounting, the tester verifies that the messages are discarded and that any response is sent back by the network product.
5. The tester sends to if1 EchoRequest messages replying a pcap file or using a network generator.
a) Using the network analyser, the tester verifies that the messages are correctly received by the network product.
b) The tester verifies that the GTP-U EchoRequest messages are not discarded because EchoResponse messages are sent back by the network product.
6. The tester verifies that the matching messages are correctly accounted for both rules.
7. The tester sends to if1 GTP-U messages different from EchoRequest replying a pcap file or using a network generator.
a) Using the network analyser, the tester verifies that the messages are correctly received by the network product.
b) Using the accounting, the tester verifies that the messages are discarded and that any response is sent back by the network product.
8. The tester deletes the previous rules and configures a new rule, i.e. to accept only GTP-U EchoRequest on if1 coming from a certain IP Address named IP1.
9. The tester sends GTP-U EchoRequest messages with source IP Address set to IP1:
a) Using the network analyser, the tester verifies that the messages are correctly received by the network product.
b) The tester verifies that the GTP-U EchoRequest messages are not discarded and EchoResponse messages are sent back by the network product.
10. The tester sends GTP-U EchoRequest messages with source IP Address set to IP2 different from IP1 using a network traffic generator or replying a pcap file.
a) Using the network analyser the tester verifies that the messages are correctly received by the network product.
b) The tester verifies that the GTP-U EchoRequest messages are discarded and that no EchoResponse messages are sent back.
Expected Results:
– For steps 4, 5, 6 and 7 the tester receives GTP-U EchoResponse messages from if1 only.
– For steps 4, 5, 6 and 7 the messages matching the rules are correctly accounted.
– For steps 8, 9, 10 the tester receives GTP-U EchoResponse messages only for the authorized source IP address.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– The used tool(s) name and version information
– Settings and configurations used
– Pcap trace
– Screenshot
Test result (Passed or not)