4.3 Security requirements and related test cases related to hardening
33.1173GPPCatalogue of general security assurance requirementsRelease 16TS
4.3.1 Introduction
The requirements proposed hereafter (with the relative test cases) aim to securing network products (including the network functions in service-based architecture) by reducing its surface of vulnerability. In particular the identified requirements aim to ensure that all the default network product configurations (including operating system software, firmware and applications) are appropriately set.
4.3.2 Technical Baseline
4.3.2.1 No unnecessary or insecure services / protocols
Requirement Name: No unnecessary or insecure services / protocols
Requirement Description:
The network product shall only run protocol handlers and services which are needed for its operation, and which do not have any known security vulnerabilities. In particular, by default the following services shall be initially configured to be disabled on the network product by the vendor except if services are needed during deployment. In that case those services shall be disabled according to vendor’s instructions after deployment is done. Disabled protocols may still need to be enabled for other reasons by the operators, e.g. remote diagnostics.
– FTP
– TFTP
– Telnet
– rlogin, RCP, RSH
– HTTP
– SNMPv1 and v2
– SSHv1
– TCP/UDP Small Servers (Echo, Chargen, Discard and Daytime)
– Finger
– BOOTP server
– Discovery protocols (CDP, LLDP)
– IP Identification Service (Identd)
– PAD
– MOP
NOTE 1: As an alternative to disabling the HTTP service, it is also possible for this service to remain active for reasons of user friendliness. In this case, however, queries to the web service may not be answered directly on this port but from a redirected to HTTPS service.
Note 2: Full documentation of required protocols and services of the network product and their purpose needs to be provided by the vendor as prerequisite for the test case.
Test Case: TBA
Test Name: TC_NO_UNNECESSARY_SERVICE
Purpose:
To ensure that on all network interfaces, there are no unsecure services or protocols that might be running.
Procedure and execution steps:
Pre-Conditions:
A list of all required network protocols and services containing at least the following information shall be included in the documentation accompanying the Network Product:
– protocol handlers and services needed for the operation of network product;
– their open ports and associated services;
– and a description of their purposes.
The tool used shall be capable to detect and identify the protocol handlers and running services in the system.
Execution Steps
The accredited evaluator’s test lab is required to execute the following steps:
1. Verification of the compliance to the prerequisites:
a. Verification that the list of available network services and protocol handlers is available in the documentation of the Network Product.
b. Validation that all entries in the list are meaningful and reasonably necessary for the operation of the Network Product class.
2. Identification of the network services and protocol handlers by means of capable tools or any other suitable testing means.
3. Validation that there are no entries in the list of network services and handlers apart from the ones that have been mentioned and deemed necessary for the operation of the Network Product in the attached documentation.
4. The tester shall reboot the network product and re-execute execution steps 2 and 3 without further configuration.
Expected Results:
The report will contain:
– The names and version of the tool(s) used.
– Information of all the protocol handlers and services running in the network product.
Result will show:
– There are no unnecessary services running in the network product except for the ones which are deemed necessary for its operation.
– Any undocumented services running on the network product should be highlighted and brought out in the report.
– The network product behaves the same after reboot as before.
Expected format of evidence:
A 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
– The output pertaining to the test case performed and
– The test results i.e. services existing or not existing in the MME
4.3.2.2 Restricted reachability of services
Requirement Name: The network product shall restrict the reachability of services
Requirement Description:
The network product shall restrict the reachability of services so that they can only be reached on interfaces where their usage is required. On interfaces were services are active, the reachability should be limited to legitimate communication peers. This limitation shall be realized on the network product itself (without measures (e.g. firewall) at network side) according to the requirement detailed in clause 4.2.6.2.1 Packet Filtering.
Example: Administrative services (e.g. SSH, HTTPS, RDP) shall be restricted to interfaces in the management network to support separation of management traffic from user traffic.
Test Case:
Test Name: TC_RESTRICTED_REACHIBILITY_OF_SERVICES
Purpose:
To verify that it is possible to bind the services only to the interfaces from which they are expected to be reachable.
Note: The test case developed for the requirement " 4.2.6.2.1 Packet Filtering" implicitly verifies that the network product permits to limit the reachability of the services only to legitimate communication peers,
Procedure and execution steps:
Pre-Conditions:
– The vendor shall declare, in the documentation accompanying the network product if the network product supports the capability to restrict services reachability to only the nodes authorized to access them. In this case, the vendor shall detail how this capability can be configured.
– A list of all required network protocols and services containing at least the following information shall be included in the documentation accompanying the Network Product:
– protocol handlers and services needed for the operation of network product;
– their open ports and associated services;
– the configuration options;
– and a description of their purposes.
– The network product is configured such that the required network protocols and services (as described in the network product documentation) are setup and each service is bound to an IP address of a specific network interface (e.g. IP1 which is the ip address of if1). Configuration may occur automatically during the initialization phase of the network product or manually as defined in the network product administration documentation.
– The network product shall have at least two interfaces enabled, if1 and if2 respectively configured with IP Address IP1 and IP2.
– The tester has administrative privileges.
– A tester machine equipped with a network port scanner tool is available.
Execution Steps
1. The tester runs a network port scanner (e.g. nmap) towards if1 and verifies that the configured services are open/reachable.
2. The tester runs a network port scanner (e.g. nmap) towards if2 and verifies that the configured services are not open/reachable.
Expected Results:
Services can be enabled on per-interface basis.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– The network product configuration
– Pcap files
– Screenshot
– Network port scanner results (e.g. files containing this results)
– Test result (Passed or not)
4.3.2.3 No unused software
Requirement Name: Unused software shall not be installed or shall be uninstalled
Requirement Description:
Unused software components or parts of software which are not needed for operation or functionality of the network product shall not be installed or shall be deleted after installation. This includes also parts of a software, which will be installed as examples but typically not be used (e.g. default web pages, example databases, test data).
Test Case:
Test Name: TC_NO_UNUSED_SOFTWARE
Purpose:
To ensure that there is no unused software or associated components that might be installed in the network product which are not required for its operation or functionality.
Procedure and execution steps:
Pre-Conditions:
A list of all available software and libraries and associated components containing at least the following information shall be included in the documentation accompanying the Network Product:
– name of the software / library;
– version of the software / library installed;
– list of dependencies and versions;
– any add-ons and functions;
– any special hardware/debugging ports;
– software support type;
– licensing information;
– brief description of their purpose.
Execution Steps
The accredited evaluator’s test lab is required to execute the following steps:
1. Verification of the compliance to the prerequisites:
a. Verification that the list of software / libraries and components is available in the documentation of the Network Product.
b. Validation that all entries in the list of software / libraries and components are meaningful and reasonably necessary for the operation of the Network Product class.
2. Identification of the software / libraries or components which are installed in the system using any suitable command line tools or any other suitable means of determination.
3. Validation that there are no entries in the list of software / libraries installed in the system apart from the ones that have been mentioned and deemed necessary for the operation of the network product in the attached documentation.
4. Based on his/her experience, the tester will check for known default example files for software installed on the system.
Expected Results:
The report will contain the names and version of the tool(s) used for finding out what software /libraries is installed in the system. The detailed report will contain the name and version information of all the software / libraries installed in the system generated by the tool.
The list of all available software / libraries which has been deemed necessary for the operation of the network product by the vendor shall also be included as the test result. Any software / library not in the list of allowed software / libraries will be highlighted and brought out as a part of the report.
There should be no unnecessary software / library installed in the network product except for the ones which are deemed necessary for its operation.
There should be no more default example files for the installed software on the system.
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
– the output pertaining to the test case performed and,
– the test results i.e. list of allowed and disallowed software
4.3.2.4 No unused functions
Requirement Name: Unused functions of the network products’ software and hardware shall be deactivated.
Requirement Description:
During installation of software and hardware often functions will be activated that are not required for operation or function of the system. If unused functions of software cannot be deleted or deinstalled individually as required in clause "5.3.2.3 No unused software" of the present document, such functions shall be deactivated in the configuration of the network product permanently.
Also hardware functions which are not required for operation or function of the system (e.g. unused interfaces) shall be permanently deactivated. Permanently means that they shall not be reactivated again after network product reboot.
Example: A debugging function in software which can be used for troubleshooting shall not be activated during normal operation of the network product.
Test Case:
Test Name: TC_NO_UNUSED_FUNCTIONS
Purpose:
To ensure that there is no unused hardware or software functions that are not deactivated in the network product which are not required for its operation or functionality.
Procedure and execution steps:
Pre-Conditions:
A list of all available software and associated components containing at least the following information shall be included in the documentation accompanying the Network Product:
– name of the software;
– version of the software installed;
– list of dependencies and versions;
– any add-ons and functions;
– any special hardware/debugging ports;
– software support type;
– licensing information;
– requirement during functioning of system;
– brief description of their purpose.
Execution Steps:
The accredited evaluator’s test lab is required to execute the following steps:
1. Identification of the hardware and software functions which are installed in the system or might have been disabled using any suitable command line tools or any other suitable means of determination.
2. Validate that there are no entries in the list of hardware and software functions installed in the system apart from the ones that have been mentioned and deemed necessary for the operation of the network product in the attached documentation.
Expected Results:
The report will contain the names and version of the tool(s) used for finding out what software and associated function is installed in the system. The detailed report will contain the name and version information of all the software and components installed in the system generated by the test tool.
The list of all available software which has been deemed necessary for the operation of the network product by the vendor shall also be included as the test result. Any software not in the list of allowed software will be highlighted and brought out as a part of the report.
There should be no unused function that is not deactivated in the network product except for the ones which are deemed necessary for its operation.
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
– The list of software and associated functions
– the test results i.e. allowed list of functions
4.3.2.5 No unsupported components
Requirement Name: The network product shall not contain software and hardware components that are no longer supported by their vendor, producer or developer.
Requirement Description:
The network product shall not contain software and hardware components that are no longer supported by their vendor, producer or developer, such as components that have reached end-of-life or end-of-support. Excluded are components that have a special support contract. This contract shall guarantee the correction of vulnerabilities over components’ lifetime.
Test Case:
Test Name: TC_NO_UNSUPPORTED_COMPONENTS
Purpose:
To ensure that there is no unsupported software that is running in the network product which is not supported anymore and has reached its end-of-life or end-of-support.
Procedure and execution steps:
Pre-Conditions:
A list of all available software and associated components containing at least the following information shall be included in the documentation accompanying the Network Product:
– name of the software;
– version of the software installed;
– list of dependencies and versions;
– any add-ons and functions;
– any special hardware/debugging ports;
– software support type;
– licensing information;
– requirement during functioning of system;
– brief description of their purpose.
Execution Steps
The accredited evaluator’s test lab is required to execute the following steps:
1. Identification of the hardware and software components, version information and the kind of support available for the software provided by the vendor, the producer, the developer or other contractual partner of the operator using any tool or any other suitable means of determination.
2. Validate that there are no entries in the list of hardware and software installed in the system which are not supported as given by the vendor of network product in the attached documentation.
Expected Results:
The report will contain the names and versions of the tool(s) used for finding out what software and hardware components are installed in the system. The detailed report will contain the name and version of the software and hardware used in the system, and the period of support for each of these components.
The list of all available software and hardware components and their associated support information which has been deemed necessary for the operation of the network product by the vendor shall also be included as the test result. Any software or component which is not supported any longer by the vendor will be highlighted and brought out as a part of the report.
There should be no software installed in the network product which is unsupported as of the day of testing.
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
– Software and hardware components used in the network product
– the test results i.e. support information of each listing
4.3.2.6 Remote login restrictions for privileged users
Requirement Name: Remote login restrictions for privileged users
Requirement Description: Direct login as root or equivalent highest privileged user shall be limited to the system console only. Root user will not be allowed to login to the system remotely.
Test Case:
Test Name: TC_REMOTE_LOGIN_RESTRICTIONS_PRIVILEGED_USERS
Purpose:
Verify that root or equivalent highest privileged user will not be allowed to login to the system remotely.
Procedure and execution steps:
Pre-Condition:
A document that describes the interfaces to the network product and how the tester can login to them remotely.
Execution Steps
Execute the following steps:
1. The tester tries to remotely login to the network product using the credentials of the root or equivalent highest privileged user via the interfaces as described in the documentation.
2. The tester tries to login to the network product using the credentials of the root or equivalent highest privileged user from the physical console of the system.
Expected Results:
The tester is not able to login to the system remotely using the root credentials.
The tester is able to login to the system from the physical console using the root credentials.
Expected format of evidence:
A Pass/Fail result.
4.3.2.7 Filesystem Authorization privileges
Requirement Name: Filesystem Authorization privileges.
Requirement Description: The system shall be designed to ensure that only users that are authorized to modify files, data, directories or file systems have the necessary privileges to do so.
EXAMPLE: On unix® systems a ‘sticky’ bit may be set on all directories where all users have write permissions. This ensures that only the file’s owner, the directory’s owner, or root user can rename or delete the file. Without the sticky bit being set, any user that has write and execute permissions for the directory can rename or delete files within the directory, regardless of the file’s owner.
Test Case:
Test Name: TC_FILESYSTEM_AUTHORIZATION_PRIVILEGES
Purpose:
Verify that only users that are authorized to modify files, data, directories or file systems have the necessary privileges to do so.
Procedure and execution steps:
Pre-Condition:
A document describing how access control is configured for the filesystems in the network product shall be provided by the vendor.
Execution Steps
Execute the following steps:
1. The tester checks that OS-level permissions are configured correctly for users that are authorized to modify files, data, directories or file systems on the system.
2. The tester tries to modify the files and directories for which the user has the necessary privileges.
3. The tester tries to modify the files and directories for which the user doesn’t have the necessary privileges.
Expected Results:
The OS-level access permissions are set correctly for the users.
The users can only modify files, data, directories or file systems for which he has the necessary privileges to do so.
Expected format of evidence:
Screenshot containing the configuration file showing the OS-level permissions are set correctly.
4.3.3 Operating Systems
4.3.3.1 General operating system requirements and test cases
4.3.3.1.1 IP-Source address spoofing mitigation
Requirement Name: IP-Source address spoofing mitigation
Requirement Description:
Systems shall not process IP packets if their source address is not reachable via the incoming interface. Implementation example: Use of "Reverse Path Filter" (RPF) provides this function.
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_IP_SPOOFING_MITIGATION
Purpose:
To verify that the network product provides anti-spoofing function that is, before a packet is processed, the network product checks whether the source IP of the received packet is reachable through the interface it comes in.
To verify that if the received packet source address is not routable through the interface on which it comes, then the network product drops this packet.
Procedure and execution steps:
Pre-Conditions:
– A node N1 is available with:
– Two interfaces named respectively if1-n1 connected to the network product and if2-n1 to which the tester connects a tester machine
– routing capabilities
– if2-n1 has a static IP address (e.g. 192.168.3.1 belonging to the subnet 192.168.3.0/24)
– A node N2 is available with:
– Two interfaces named respectively if1-n2 connected to the network product and if2-n2 to which the tester connects a tester machine
– Routing capabilities. In particular N2 has a default route to if1-np subnet via if2-np (e.g. 192.168.2.1)
– if2-n2 has a static IP address . This ip is the same as if2-n1 (e.g. 192.168.3.1 belonging to the subnet 192.168.3.0/24)
– The network product has at least 2 enabled interfaces said if1-np and if2-np:
– The interface if1-np is connected to interface if1-n1 of the node N1 on the subnet, e.g., 192.168.1.0/24.
– The interface if2-np is connected to interface if1-n2 of the node N2 on the subnet, e.g., 192.168.2.0/24.
– The network product is configured with a static route for the subnet where if2-n1 is connected to (e.g. 192.168.3.0/24), so this subnet can be reached via if1-n1 through if1-np.
Figure 1: Configurations for the network product, N1 and N2
– The vendor shall declare, in the documentation accompanying the network product, the supported anti-spoofing mechanism (e.g. RPF or similar function) and if it is enabled for all interfaces (e.g. net.ipv4.conf.all.rp_filter = 1 and net.ipv4.conf.default.rp_filter = 1 in the linux sysctl.conf file) or per interface bases.
– The vendor shall declare if the dropped packets can be logged and how to enable this logging
– The tester has administrator privileges
– A tester machine is available and configured with:
– A static IP address belonging to the subnet where if2-n1 and if2-n2 are connected to (e.g. 192.168.3.2/24)
– A default gateway set to if2-n1 and if2-n2 IP Address (e.g. 192.168.3.1)
– A network traffic analyser (e.g. tcpdump) on the network product is available
Execution Steps
1. The tester starts to send ping messages to if1-np interface of the network product.
2. The tester verifies, through the network traffic analyser, that the ping reaches correctly the if1-np interface and that responses are sent back.
3. The tester disconnects the tester machine from if2-n1 interface of the node N1 and reconnects it to the interface if2-n2 of the node N2:
– The testers uses the same network configuration of the tester machine.
– The tester sends ping messages to if1-np interface of the network product.
– The tester verifies, through the network traffic analyser, that the pings reach the if1-np interface of the network product, but they are dropped and no response is sent back since the source of the received packet is not reachable through the interface it came in.
– The tester sends ping messages to if2-np interface of the network product.
– The tester verifies, through the network traffic analyser, that the pings reach the if2-np interface of the network product, but they are dropped and no response is sent back since there is a default route via if2-np.
– If the dropped packets are logged, the testers verifies that these packets are recorded.
Expected Results:
The network product supports an anti-spoofing mechanism (e.g. the RPF function) and it accepts a packet only if it reaches the network product on the expected interface (i.e. this packet has a source ip address belonging to the same network as the interface where it came in or if it is routable through the interface on which it came in), otherwise it discards the packet.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– The user settings and configurations
– Pcap files
– Log file if available
– Test result (Passed or not)
4.3.3.1.2 Minimized kernel network functions
Requirement Name: Minimized kernel network functions.
Requirement Description:
Kernel based network functions not needed for the operation of the network element shall be deactivated.
In particular the following ones shall be disabled by default:
Note: Void
– Proxy ARP (to prevent resource exhaustion attack and man-in-the-middle attacks.
– Directed broadcast (to prevent Smurf, Denial of Service attack and others like it.
– IPv4 Multicast handling. In particular all packets with IP source or destination address belonging to the multicast IP ranges (224.0.0.0 through 239.255.255.255) shall be discarded by default and multicast route caching and forwarding shall be disabled to prevent smurf and fraggle attacks. A configuration option shall be available to enable the IPv4 multicast handling if required.
– Gratuitous ARP messages (to prevent ARP Cache Poisoning attacks [ef]). A Gratuitous ARP request can be used mainly to inform the neighbours about the change in the MAC for the specified IP and consequently to update their ARP tables or to update the switches with the new MAC address or to defend link-local IP addresses in the Zeroconf protocol. By default, the network product shall not send Unsolicited ARP and any incoming Gratuitous ARP requests shall be discarded.
Note: The above text does not preclude that Gratuitous ARP can be enabled in certain deployment scenarios.
Answering routine for broadcast ICMP packets. In particular all ICMP ECHO and TIMESTAMP requests sent to network product via broadcast/multicast shall not be answered by default.
Test Case:
Test Name: TC_PROXY_ARP_DISABLING
Purpose:
Verify that the Proxy ARP feature is disabled by default on the network product. In particular this test case verifies that the network product does not respond to ARP requests intended for another host.
Procedure and execution steps:
Pre-Conditions:
– The network product shall have at least 2 different physical or logical Ethernet interface IF1 and IF2. E.g.
– Host 1 is connected to IF1 on subnet A (for example 172.16.10.0/16).
– Host 2 is connected to IF2 on subnet B (for example 172.16.20.0/24).
– Network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available.
Execution Steps
1. If the feature is available in a configuration file, verify that it is disabled by default.
2. Broadcast an ARP request from Host 1 on Subnet A to discover the MAC of Host 2 on subnet B. Since the ARP request is a broadcast, it reaches all nodes in the Subnet A, which include the IF1 interface of the network product, but it does not reach Host 2.
3. Verify that the network product correctly receives this packet but that it does not send an ARP reply to Host 1 with its own MAC address.
Expected Results:
No Arp Reply is received by Host 1.
Expected format of evidence:
Pcap trace, snapshot of ARP Cache of Host 1
Test Name: TC_DIRECTED_BROAD_DISABLING
Purpose:
Verify that the Directed broadcast is disabled by default on the network product. In particular this test case verifies that a packet received by a network product whose destination address is a valid broadcast address is dropped.
Procedure and execution steps:
Pre-Conditions:
– The network product has at least 2 different physical or logical Ethernet interface IF1 and IF2.
– Host 1 is connected to IF1 on Subnet A and Host 2 is connected to IF2 on Subnet B.
– Network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available.
Execution Steps
1. If the feature is available in a configuration file, verify that it is disabled by default.
2. Send an IP packet from Host 1 whose IP destination address is a valid broadcast address belonging to the subnet B.
3. Verify that the Host 2 on Subnet B does not receive the packet because it will be dropped by the network product, rather than being broadcasted.
Expected Results:
The packet is not broadcasted by the network product and Host 2 cannot receive it.
Expected format of evidence:
Pcap trace showing that packet from host 1only incomes to the network product.
Test Name: TC_ IP_MULTICAST_HANDLING
Purpose:
Verify that IP Multicast is disabled by default on the network product. In particular this test case verifies that packets with IP source or destination address belonging to the multicast IP ranges (224.0.0.0 through 239.255.255.255) are not handled by the network product.
Procedure and execution steps:
Pre-Conditions:
– Network traffic analyser on the network product or an external traffic analyser directly connected to the network product is available.
– Network product
Capability:
NOT applicable in certain deployment scenarios where multicast needs to be enabled.
Execution Steps
1. If the feature is available in a configuration file, verify that it is disabled by default.
2. Verify that none of the network product’s interfaces is running Multicast (e.g. typing command ip maddr or ifconfig on any Unix® based platform)
Expected Results:
No interface is running multicast protocols
Expected format of evidence:
Screenshot containing command output.
Test Name: TC_GRATUITOUS_ARP_DISABLING
Purpose:
Verify that the Gratuitous ARP feature is disabled by default on the network product. In particular this test case verifies that the network product cannot send gratuitous ARP requests and that the network product discards incoming Gratuitous ARP requests.
Procedure and execution steps:
Pre-Conditions:
– Network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available.
– Host 1 is connected to the network product
– The network product ARP Cache already contains an entry for Host 1
– The network product documentation does not state any reason why gratuitous ARP may be deliberately enabled in order to satisfy certain deployment scenarios. If the network product documentation does, however, state that the usage of gratuitous ARP is enabled in certain deployment scenarios, then this test case is not applicable (refer to the NOTE in the requirement).
Execution Steps
1. If the feature is available in a configuration file, verify that it is disabled by default.
2. Send a Gratuitous ARP request from Host 1, i.e. an ARP request where the source and destination IP are both set to an IP address different from the one already cached in the network product ARP Cache for Host 1 and the destination MAC is the broadcast address ff:ff:ff:ff:ff:ff.
3. Verify that the network product correctly receives this packet but discards it and that the ARP Cache is not updated.
4. Send a Gratuitous ARP request i.e. an ARP reply where the source and destination IP are both set to an IP address different from the one already cached in the network product ARP Cache for Host 1 and the destination MAC is the broadcast address ff:ff:ff:ff:ff:ff.
5. Verify that the network product correctly receives this packet but discards it and that the ARP Cache is not updated.
Expected Results:
The network product ARP Cache is not updated.
Expected format of evidence:
Snapshot of the network product ARP Cache
Test Name: TC_BROADCAST_ICMP_HANDLING
Purpose:
Verify that responses to ICMP broadcast packets are disabled by default on the network product . In particular this test case verifies that all ICMP ECHO and TIMESTAMP requests sent to the network product via broadcast/multicast are not answered.
Procedure and execution steps:
Pre-Conditions:
– The network product has at least one physical or logical Ethernet interface IF1 connected to a host, Host 1.
– Network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available.
Execution Steps
1. If the feature is available in a configuration file, verify that it is disabled by default. .
2. Send an ICMP ECHO message from Host 1 to ping a broadcast address (such as 255.255.255.255, or 192.168.1.255 on a 192.168.1.0/24 subnet)
3. Verify that the network product doesn’t respond to the ping.
4. Send an ICMP timestamp request (ICMP type 13) from host 1 to a broadcast address (such as 255.255.255.255, or 192.168.1.255 on a 192.168.1.0/24 subnet).
5. Verify that the network product doesn’t respond to the timestamp request.
Expected Results:
The network product doesn’t respond to any ICMP packet with a broadcast address.
Expected format of evidence:
Pcap trace showing that the ICMP ECHO/ ICMP timestamp packets are received by the network product but no responses are generated by the network product.
4.3.3.1.3 No automatic launch of removable media
Requirement Name: No automatic launch of removable media
Requirement Description:
The network product shall not automatically launch any application when removable media device such as CD-, DVD-, USB-Sticks or USB-Storage drive is connected. If the operating system supports an automatic launch, it shall be deactivated unless it is required to support availability requirements.
Test Case:
Test Name: TC_NO_AUTO_LAUNCH_OF_REMOVABLE_MEDIA
Purpose:
To verify that the network product does not launch any applications automatically when a removable media device is connected. Any such feature should be deactivated.
Procedure and execution steps:
Pre-Condition
If the network product is provisioned with the necessary physical ports/drives (CD/DVD drive, USB port, etc.) then the test case applies.
Execution Steps
1. The tester log in the network product.
2. The tester inserts a removable media device (CD-, DVD-, USB-Sticks and/or USB-Storage drives) in the network product.
Expected Results:
The network product does not launch any applications to open the contents in the removable media device.
In Linux® machines, the removable media device is not automatically mounted in the filesystem.
Expected format of evidence:
Evidence can be presented in the form of screenshot/screen-capture on how the network product responds when any removable media device is attached to it.
4.3.3.1.4 SYN Flood Prevention
Requirement Name: Syn Flood Prevention
Requirement Description:
The network product shall support a mechanism to prevent Syn Flood attacks (e.g. implement the TCP Syn Cookie technique in the TCP stack by setting net.ipv4.tcp_syncookies = 1 in the linux sysctl.conf file). This feature shall be enabled by default.
Test Case:
Test Name: TC_SYN_FLOOD_PREVENTION
Purpose:
Verify that the Network Product supports a Syn Flood Prevention technique.
Procedure and execution steps:
Pre-Conditions:
– The Network Product is listening on a TCP port one of its interfaces.
– A network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product is available.
– A host is connected to the Network Product interface and it is equipped with a tool able to reproduce a Syn Flood attack (e.g. nmap or hping)
Execution Steps
1. The tester configures the tool to send a huge amount of TCP Syn packets against the Network Product (e.g. hping3 -i <waiting time between each packet> -S -p <TCP port> -c <Number of packets> <MME IP>)
2. The Network Product is still up and running normally, its services are still available and reachable, the memory is not exhausted, there is no crash.
Expected Results:
The Network Product does not become inoperative.
Expected format of evidence:
A Pass/Fail result provided by the tester.
4.3.3.1.5 Protection from buffer overflows
Requirement Name: Protection mechanisms against buffer overflows
Requirement Description:
The system shall support mechanisms for buffer overflow protection. Documentation which describes these buffer overflow mechanisms and also how to check that they have been enabled and/or implemented shall be provided.
Note: Void
NOTE: Void
Test Case:
Test Name: TC_PROTECTION_FROM_BUFFER_OVERFLOW
Purpose:
To ensure that the system supports mechanisms that protect against buffer overflow.
Procedure and execution steps:
Pre-Conditions:
1. A document which provides a detailed technical description of the system’s buffer overflow protection mechanisms.
If a standard buffer overflow mechanism from a 3rd party vendor is used then a reference to the standard feature in the 3rd party vendors documentation should be provided.
2. Test results from a test execution phase of buffer overflow protection mechanism testing.
Execution Steps:
The accredited evaluator’s test lab is required to execute the following steps:
1. The tester verifies that there is:
a) A technical description of the buffer overflow protection mechanisms that have been implemented on the system.
b) Details of whether the buffer overflow protection mechanisms are implemented by default or if additional actions (e.g. scripts or commands manually executed) are required.
c) If manually executed actions are required then detailed instructions should be included in the technical description.
2. The tester verifies that the test results:
a) Describe test procedures used to verify the buffer overflow protection mechanisms,
b) Contain data which demonstrates/indicates that the buffer overflow protection mechanisms described in the technical description document have been implemented.
c) Contains details of the test set-up for the testing of the buffer overflow protection mechanisms. Where simulators and/or scripts are used to artificially create the conditions to trigger the buffer overflow protection mechanism then details of these should also be included.
Expected Results:
1. A technical description of the buffer overflow protection mechanisms that have been implemented on the system.
– Details of whether the buffer overflow protection mechanisms are implemented by default or if additional actions (e.g. scripts or commands manually executed) are required.
– If manually executed actions are required then detailed instructions should be included in the technical description.
2. The test results should:
– Describe test procedures used to verify the buffer overflow protection mechanisms,
– Contain data which demonstrates/indicates that the buffer overflow protection mechanisms described in the technical description document have been implemented.
– Contain details of the test set-up for the testing of the buffer overflow protection mechanisms. Where simulators and/or scripts are used to artificially create the conditions to trigger the buffer overflow protection mechanism then details of these should also be included.
Expected format of evidence:
Documentation showing each of the points in the results sections.
4.3.3.1.6 External file system mount restrictions
Requirement Name: External file system mount restrictions
Requirement Description:
If normal users are allowed to mount external file systems (attached locally or via the network), OS-level restrictions shall be set properly in order to prevent privilege escalation or extended access permissions due to the contents of the mounted file systems.
Implementation example: In Linux® systems, administrators shall set the options nodev and nosuid in the /etc/fstab for all filesystems, which also have the "user" option.
NOTE: This requirement does not apply when the docker is used to mount file system.
Test Case:
Test Name: TC_EXTERNAL_FILE_SYSTEM_MOUNT_RESTRICTIONS
Purpose:
Verify that OS-level restrictions are set properly for users that are allowed to mount external file systems (attached locally or via the network). This is to prevent privilege escalation or extended access permissions due to the contents of the mounted file systems.
Procedure and execution steps:
Pre-Condition:
Tester has admin access to check and configure the external filesystem mount permissions in the OS.
Tester has username and password of a user in the network product that has external filesystem mount privileges.
Execution Steps
Execute the following steps:
1. The tester shall verify that OS-level restrictions are set properly in order to prevent privilege escalation due to the contents of the mounted file systems (e.g. In Linux® systems, administrators shall set the options nodev and nosuid in the /etc/fstab for all filesystems, which also have the "user" option). The tester checks that OS-level parameters are configured correctly on the system.
2. The tester mounts an external filesystem prepared by the tester with files exploiting privilege escalation methods (e.g. with writable SUID/GUID files).
3. The tester tries to gain privileged access to system by using a suitable privilege escalation method using the contents of the mounted file system and then confirms that privilege escalation doesn’t happen.
Expected Results:
The OS-level restrictions are set properly in order to prevent privilege escalation or extended access permissions due to the contents of the mounted file systems.
Any privilege escalation method used by the tester should be blocked.
Expected format of evidence:
Screenshot containing the configuration file showing that OS-level restrictions are set properly for users that are allowed to mount external file systems.
4.3.4 Web Servers
4.3.4.1 General
Hardening requirements for Web servers of this section are well covered also by external sources, such as Center for Internet Security (CIS) benchmarks <https://benchmarks.cisecurity.org/index.cfm>. It is highly recommended to consult e.g. CIS, for the purpose of using automatic testing tools, for product-specific considerations, and for manual auditing, when testing the below listed requirements. If and when such mapping of requirements is used, i.e. to those of an external source, it needs to be well verified and documented that they cover the requirements of this section.
4.3.4.2 No system privileges for web server
Requirement Name: No system privileges for web server.
Requirement Description:
No web server processes shall run with system privileges. This is best achieved if the web server runs under an account that has minimum privileges. If a process is started by a user with system privileges, execution shall be transferred to a different user without system privileges after the start.
Test Case:
Test Name: TC_NO_SYSTEM_PRIVILEGES_WEB_SERVER
Purpose:
Verify that the Web server is not run under system privileges.
Procedure and execution steps:
Pre-Conditions:
– The tester has needed administrative privileges.
– A tester machine is available.
– Recommended: an automatic assessment tool has been configured /script adapted in line with the Requirement Description.
Execution Steps
1. Check that no web server processes runs with system privileges. Check that this is the case even for processes that may have been started by a user with system privileges.
2. Check that relevant system settings and configurations are correct to ensure fulfilment of the requirement.
Expected Results:
– There are no findings of processes that run with system privileges.
– System settings have been found correctly set to ensure that no processes will run with system privileges.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Log files and screen shots of test executions
– Test result (Passed or not)
4.3.4.3 No unused HTTP methods
Requirement Name: Unused HTTP methods shall be deactivated.
Requirement Description:
HTTP methods that are not required shall be deactivated. Standard requests to web servers only use GET, HEAD, and POST. If other methods are required, they shall not introduce security leaks such as TRACK or TRACE.
Test Case: TBA
Test Name: TC_NO_UNUSED_HTTP_METHODS
Purpose:
Verify that the Web server has deactivated all HTTP methods that are not required.
Procedure and execution steps
Pre-Conditions:
– The tester has needed administrative privileges.
– A tester machine is available.
– Recommended: an automatic assessment tool has been configured / script adapted in line with the Requirement Description.
Execution Steps
– Check that relevant system settings and configurations are correct to ensure fulfilment of the requirement.
Expected Results:
– System settings and configurations have been found adequately set, in all Web components of the system, to ensure that unneeded HTTP methods are deactivated.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Log files and screen shots of test executions
– Test result (Passed or not)
4.3.4.4 No unused add-ons
Requirement Name: Any add-ons and components that are not required shall be deactivated.
Requirement Description: All optional add-ons and components of the web server shall be deactivated if they are not required. In particular, CGI or other scripting components, Server Side Includes (SSI), and WebDAV shall be deactivated if they are not required.
Test Case:
Test Name: TC_NO_UNUSED_ADD-ONS
Purpose:
To verify that the Web server has deactivated unneeded add-ons and unneeded scripting components.
Procedure and execution steps
Pre-Conditions:
– The vendor has supplied a list of add-ons or scripting tools for Web server components needed for system operation, and that therefore need to be exempted from the test investigation.
– The tester has administrative privileges.
– A tester machine is available.
– Recommended: an automatic assessment tool has been configured / script adapted in line with the Requirement Description.
Execution Steps
1. Check that the web server is only running and listening on known ports (e.g. tcp port 80 and/or 443). Check that CGI or other scripting components, Server Side Includes (SSI), and WebDAV are deactivated if they are not required. See also guidance under 4.3.4.12.
2. Check that nothing else has been installed than the web server.
3. Check that relevant system settings and configurations are correct to ensure fulfilment of the requirement.
Expected Results:
– System settings and configurations have been found adequately set, in all Web components of the system, to ensure that all unneeded add-ons or script components are deactivated.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Log files and screen shots of test executions.
– Test result (Passed or not).
4.3.4.5 No compiler, interpreter, or shell via CGI or other server-side scripting
Requirement Name: No compiler, interpreter, or shell via CGI or other server-side scripting.
Requirement Description: If CGI (Common Gateway Interface) or other scripting technology is used, the CGI directory – or other corresponding scripting directory – shall not include compilers or interpreters (e.g. PERL interpreter, PHP interpreter/compiler, Tcl interpreter/compiler or operating system shells).
Test Case:
Test Name: TC_NO_COMPILER_FOR_CGI
Purpose:
To verify that the Web server has deactivated unneeded add-ons and unneeded scripting components.
Procedure and execution steps
Pre-Conditions:
– The tester has administrative privileges
– A tester machine is available.
– Recommended: an automatic assessment tool has been configured /script adapted in line with the Requirement Description.
Execution Steps
1. Check that there are no compilers or interpreters (e.g., PERL interpreter, PHP interpreter/compiler, Tcl interpreter/compiler or operating system shells) in the directory/directories used for CGI or for other scripting tools (including PERL, PHP, and others).
2. Check that relevant system settings and configurations are correct to ensure fulfilment of the requirement.
Expected Results:
– System settings and configurations have been found adequately set, in all Web components of the system, to ensure that all unneeded add-ons or script components are deactivated.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Log files and screen shots of test executions
– Test result (Passed or not)
4.3.4.6 No CGI or other scripting for uploads
Requirement Name: No CGI or other scripting for uploads.
Requirement Description: If CGI or other scripting technology is used, the associated CGI/script directory shall not be used for uploads.
Test Case:
Test Name: TC_NO_CGI_OR_SCRIPTING_FOR_UPLOADS
Purpose:
To test whether the upload directory is equal to the CGI/Scripting directory.
Procedure and execution steps:
Pre-Condition:
If the web server is configured with CGI/Scripting on, this test applies.
Execution Steps
Execute the following steps:
The tester checks whether the upload directory is configured to be different from the CGI/Scripting directory.
Expected Results:
The configured upload directory is different from the CGI/Scripting directory.
Additional evidence might be provided that shows that the web server has no write rights for the CGI/Scripting directory.
Expected format of evidence:
A part of the configuration file / screenshot of the configuration showing that the web server is properly configured.
4.3.4.7 No execution of system commands with SSI
Requirement Name: No execution of system commands with SSI.
Requirement Description: If Server Side Includes (SSI) is active, the execution of system commands shall be deactivated.
Test Case:
Test Name: TC_NO_EXECUTION_OF_SYSTEM_COMMANDS
Purpose:
To test whether it is possible to use the exec directive and if so, whether it can be used for system commands.
Procedure and execution steps:
Pre-Condition:
If the web server is configured with SSI active, this test applies.
Execution Steps
Execute the following steps:
The tester checks whether execution of system commands is disabled in the web server configuration.
Expected Results:
For example, a configuration file that shows that the IncludesNOEXEC (APACHE) or ssiExecDisable (IIS) is set.
Expected format of evidence:
A part of the configuration file / screenshot of the configuration showing that the web server is properly configured.
4.3.4.8 Access rights for web server configuration
Requirement Name: Access rights for web server configuration files shall only be granted to the owner of the web server process or to a user with system privileges.
Requirement Description: Access rights for web server configuration files shall only be granted to the owner of the web server process or to a user with system privileges. Implementation example: Delete "read" and "write" access rights for "others." Only grant "write" access to the user who configures the web server.
Test Case:
Test Name: TC_ACCESS_RIGHTS_WEB_SERVER_FILES
Purpose:
To verify that the access rights for Web server configuration files are correctly set.
Procedure and execution steps
Pre-Conditions:
– The tester has administrative privileges
– A tester machine is available.
– Recommended: an automatic assessment tool has been configured / script adapted in line with the Requirement Description.
Execution Steps
– Check the access rights settings for Web server system configuration files.
– Check that relevant system settings and configurations are correct to ensure fulfilment of the requirement.
Expected Results:
– Access rights for system configuration files are adequately set.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Log files and screen shots of test executions
– Test result (Passed or not)
4.3.4.9 No default content
Requirement Name: Default content shall be removed.
Requirement Description: Default content (examples, help files, documentation, aliases) that is provided with the standard installation of the web server shall be removed.
Test Case:
Test Name: TC_NO_DEFAULT_CONTENT
Purpose:
To verify that there is no default content on the web server, that is not needed for web server operation, since such default content can be useful for an attacker.
Procedure and execution steps
Pre-Conditions:
– The tester has needed administrative privileges
– A tester machine is available.
– Recommended: an automatic assessment tool has been configured / script adapted in line with the Requirement Description.
Execution Steps
1. Check that all default content (examples, help files, documentation, aliases) that is provided with the standard installation of the web server has been removed.
Expected Results:
– No default content (examples, help files, documentation, aliases, un-needed directories or manuals) has been found to remain on any Web server component.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Log files and screen shots of test executions.
– Test result (Passed or not).
4.3.4.10 No directory listings
Requirement Name: No directory listings / Directory Browsing.
Requirement Description: Directory listings (indexing) / "Directory browsing" shall be deactivated.
Test Case:
Test Name: TC_NO_DIRECTORY_LISTINGS
Purpose:
To verify that Directory listings / Directory browsing has been deactivated in all Web server components.
Procedure and execution steps
Pre-Conditions:
– The tester has administrative privileges
– A tester machine is available.
– Recommended: an automatic assessment tool has been configured / script adapted in line with the Requirement Description.
Execution Steps
– Check that Directory listings (indexing) / "Directory browsing" has been deactivated in all Web server components.
Expected Results:
– Evidence that Directory listing / Directory browsing has been deactivated in all Web server components.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Log files and screen shots of test executions
– Test result (Passed or not)
4.3.4.11 Web server information in HTTP headers
Requirement Name: Information about the web server in HTTP headers shall be minimized.
Requirement Description: The HTTP header shall not include information on the version of the web server and the modules/add-ons used.
Test Case:
Test Name: TC_NO_WEB_SERVER_HEADER_INFORMATION
Purpose:
To verify that HTTP headers do not include information on the version of the web server and the modules/add-ons used.
Procedure and execution steps
Pre-Conditions:
– The tester has administrative privileges
– A tester machine is available.
– Recommended: an automatic assessment tool has been configured / script adapted in line with the Requirement Description.
Execution Steps
1. Check that HTTP headers do not include information on the version of the web server and the modules/add-ons used.
Expected Results:
– Evidence that HTTP headers do not include information on the version of the web server and the modules/add-ons used.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Log files and screen shots of test executions
– Test result (Passed or not)
4.3.4.12 Web server information in error pages
Requirement Name: Web server information in error pages shall be deleted.
Requirement Description: User-defined error pages shall not include version information about the web server and the modules/add-ons used. Error messages shall not include internal information such as internal server names, error codes, etc. Default error pages of the web server shall be replaced by error pages defined by the vendor.
Test Case:
Test Name: TC_NO_WEB_SERVER_ERROR_PAGES_INFORMATION
Purpose:
To verify that error pages and error messages do not include information about the web server.
Procedure and execution steps
Pre-Conditions:
– The tester has needed administrative privileges.
– A tester machine is available.
– Recommended: an automatic assessment tool has been configured / script adapted in line with the Requirement Description.
Execution Steps
– Check that generated error pages and error messages do not include information about the web server.
Expected Results:
– Evidence that generated error pages and error messages do not include information about the web server.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Log files and screen shots of test executions
– Test result (Passed or not)
4.3.4.13 Minimized file type mappings
Requirement Name: File type- or script-mappings that are not required shall be deleted.
Requirement Description: File type- or script-mappings that are not required shall be deleted, e.g. php, phtml, js, sh, csh, bin, exe, pl, vbe, vbs.
Test Case:
Test Name: TC_NO_WEB_SERVER_FILE_TYPE MAPPINGS
Purpose:
To verify that file type- or script-mappings that are not required have been deleted.
Procedure and execution steps
Pre-Conditions:
– The tester has needed administrative privileges.
– A tester machine is available.
– Recommended: an automatic assessment tool has been configured / script adapted in line with the Requirement Description.
Execution Steps
– Check that all file type- or script-mappings that are not required have been deleted.
Expected Results:
– Evidence that all file type- or script-mappings, that are not required, have been deleted.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
– Log files and screen shots of test executions
– Test result (Passed or not)
4.3.4.14 Restricted file access
Requirement Name: The web server shall only deliver files which are meant to be delivered.
Requirement Description: Restrictive access rights shall be assigned to all files which are directly or indirectly (e.g. via links or in virtual directories) in the web server’s document directory. In particular, the web server shall not be able to access files which are not meant to be delivered.
Test Case:
Test Name: TC_RESTRICTED_FILE_ACCESS
Purpose:
To test whether the restrictive access rights are assigned to all files which are directly or indirectly in the web server’s document directory and to verify whether path traversal is made improbable.
Procedure and execution steps:
Pre-Condition:
1. The web server is configured according to the manual
Execution Steps
Execute the following steps:
1. The tester verifies that access rights on the servable content (meaning directories and files) is set to the following:
a. The files are owned by the user that runs the web server;
b. The files are not writable to others, except the web server’s account;
2. The tester verifies that the user running the web server is an unprivileged account;
3. For Operating Systems that have chrooted environments, the tester verifies that the web server runs inside a jail or chrooted environment.
Expected Results:
– Name of user running the web server with the privileges of the account;
– Access rights of files and directories that the web server serves;
– Configuration that shows that the web server is in a chrooted environment.
Expected format of evidence:
A part of the configuration file / screenshot of the configuration showing that the web server, the file access rights and the account running the web server is properly configured.
4.3.4.15 Void
4.3.5 Network Devices
4.3.5.1 Traffic Separation
Requirement Name: Traffic Separation
Requirement Description:
The network product shall support physical or logical separation of traffic belonging to different network domains. For example, O&M traffic and control plane traffic belong to different network domains. See RFC 3871 [3] for further information.
Security Objective references: tba.
Test case:
Test Name: TC_TRAFFIC_SEPARATION
Purpose:
To test whether traffic belonging to different network domains is separated.
Procedure and execution steps:
Pre-Condition:
NOTE: This test applies if the network product is meant to handle traffic from different network domains, e.g. both O&M and control plane traffic.
The network product has at least two separate (logical) interfaces dedicated to different network domains. Network products for which the test applies and that fail to meet this precondition fail the test by definition.
Execution Steps
Execute the following steps:
1. The tester checks whether the network product refuses traffic intended for one network domain on all interfaces meant for the other network domain, and vice versa.
2. Step 1 is to be performed for all pairs of different network domains.
Expected Results:
The two tests should be successful.
Expected format of evidence:
A PASS or FAIL.
4.3.6 Network Functions in service-based architecture
4.3.6.1 Introduction
The purpose of the sub-clauses in 4.3.6 is to identify and describe the hardening related requirements for all Network Function (NF) within the 5G Core (5GC) utilizing Service-Based Interfaces (SBI) and the corresponding test cases.
4.3.6.2 No code execution or inclusion of external resources by JSON parsers
Requirement Name: No code execution or inclusion of external resources by JSON parsers.
Requirement Description:
Parsers used by Network Functions (NF) shall not execute JavaScript or any other code contained in JSON objects received on Service Based Interfaces (SBI). Further, these parsers shall not include any resources external to the received JSON object itself, such as files from the NF’s filesystem or other resources loaded externally.
Threat References: TR 33.926 [4], clause 6.3.2.1, JSON Parser Exploits
Test Case:
Test Name: TC_JSON_PARSER_CODE_EXEC_INCL
Purpose:
NFs implementing SBI transfer application data serialized as JSON objects. When receiving such data, an NF parses this JSON representation and creates equivalent internal data structures. Since the contents of the JSON objects must be considered untrusted, blindly executing code fragments or loading resources from a local path or Uniform Resource Identifier (URI) must not be possible.
Procedure and execution steps:
Pre-Conditions:
– The tester has the privileges to log in the network product and to access to the all system resources (e.g. log files)
– A list of all available network services containing at least the following information shall be included in the documentation accompanying the Network Product:
– all interfaces providing IP-based protocols;
– the available transport layer protocols on these interfaces;
– their open ports and associated services in the form of an OpenAPI3.0 interface specification;
– The tester should have access to an effective Web Application Security (WAS) test tool that allows to generate HTTP messages exploiting JSON parsers that do not prevent the above-mentioned scenarios of code execution and loading external resources. The accredited test lab is expected to have sufficient expertise to recognize the level of effectiveness of the available tools.
– A network traffic analyser on the network product (e.g. TCPDUMP) or an external traffic analyser directly connected to the network product and on a tester machine is available.
Execution Steps
1. Execution of available WAS test tools against the network product’s API endpoints via its Service Based Interfaces.
2. Using a network traffic analyser on the network product, e.g. TCPDUMP or an external traffic analyser directly connected to the network product, the tester verifies that no external resources get loaded during JSON parsing.
3. Depending on the actual JavaScript code in the HTTP message, the tester verifies that the network product does not execute any of the contained actions.
Expected Results:
– The NF does not load any resources external to the JSON object itself.
– The NF does not execute any JavaScript code contained in JSON objects.
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
– The output log file of the chosen tool that displays the results (passed/failed).
– Screenshot
– Test result (Passed or not)
4.3.6.3 Unique key values in IEs
Requirement Name: Validation of the unique key values in IEs.
Requirement Reference: 3GPP TS 29.501 Principles and Guidelines for Services Definition [13], clause 6.2.
Requirement Description: "For data structures where values are accessible using names (sometimes referred to as keys), e.g. a JSON object, the name shall be unique. The occurrence of the same name (or key) twice within such a structure shall be an error and the message shall be rejected”.
Threat References: TR 33.926 [4], clause 6.3.2.2, JSON Parser not Robust
Test Case:
NOTE: This requirement can also be verified as part of Robustness and Protocol fuzzing tests as defined in clause 4.4.4 Robustness and fuzz testing according to referenced requirements.
Purpose:
Verify that the API implementation fullfills the requirements as specified in 29.501 [13], clause 6.2.
Pre-Conditions:
Test environment with network product under test. Rest of the network and network products may be simulated.
Execution Steps
1) The test equipment sends requests with duplicate keys in message IE payload to the network product under test.
2) The test equipment sends valid requests to network product under test
Expected Results:
1) Network product under tests responses with an error message
2) Network product under test still responses normally to valid requests
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
– The output log file of the chosen tool that displays the results (passed/failed).
– Test result (Passed or not)
– Log/evidence tracing possible crashes
– Information of any input causing unspecified, undocumented, or unexpected behaviour
4.3.6.4 The valid format and range of values for IEs
Requirement Name: Validation of the IEs limits.
Requirement Reference: 3GPP TS 29.501 Principles and Guidelines for Services Definition [13], clause 6.2
Requirement Description: "The valid format and range of values for each IE, when applicable, shall be defined unambiguously:
– For each message the number of leaf IEs shall not exceed 16000.
– The maximum size of the JSON body of any HTTP request shall not exceed 2 million bytes.
– The maximum nesting depth of leaves shall not exceed 32."
Threat References: TR 33.926 [4], clause 6.3.2.2, JSON Parser not Robust
Test Case:
NOTE: This requirement can also be verified as part of Robustness and Protocol fuzzing tests as defined in clause 4.4.4 Robustness and fuzz testing according to referenced requirements.
Purpose:
Verify that the API implementation fullfills the requirements as specified in 29.501[13], clause 6.2.
Pre-Conditions:
Test environment with network product under test. Rest of the network may be simulated.
Execution Steps
1) The test equipment sends requests with out of bounds IEs towards the network product under test.
Expected Results:
– Network product under tests responses with an error message.
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.
– The output log file of the chosen tool that displays the results (passed/failed).
– Test result (Passed or not).
– Log/evidence tracing possible crashes.
– Information of any input causing unspecified, undocumented, or unexpected behaviour.