3GPP TS 33.117

Name: Protection at the transport layer

Description: Network products using SBI shall support TLS-based protection as specified in TS 33.501 clause 13.1, including mutual authentication using certificates as per TS 33.310. The NF shall support HTTP/2 (RFC 7540) over TLS.

TR 33.926 §5.3.6 Information disclosure ▶

• The NF is configured for TLS-based protection on the SBI
• Valid certificates are installed on the NF as per TS 33.310
• A tester machine with TLS analysis capabilities is available
• A network traffic analyser (e.g. TCPDUMP, Wireshark) is available

1. Verify that the NF supports TLS on its SBI interfaces
2. Verify mutual authentication using certificates per TS 33.310
3. Check that the NF supports HTTP/2 over TLS as per RFC 7540
4. Check the supported TLS versions and cipher suites match TS 33.210/TS 33.310 requirements
5. Attempt to connect without TLS and verify the connection is rejected
6. Attempt to connect with an invalid/expired certificate and verify rejection

The NF enforces TLS protection on all SBI interfaces with mutual authentication. Connections without TLS or with invalid certificates are rejected.

Pcap traces, TLS handshake logs, certificate details, test tool output, Pass/Fail result.

Name: Authorization token verification failure handling within same PLMN

Reference: TS 33.501 clause 13.4.1, RFC 6749 (OAuth 2.0), RFC 7515 (JWS), RFC 7519 (JWT)

Description: The NF service producer shall verify the access token in each service request within the same PLMN and reject the request if the token verification fails.

TR 33.926 §5.3.8.1 Misuse by authorized users ▶

• NRF issues access tokens for NF service consumers within the same PLMN
• NF service producer is configured to verify access tokens
• Test environment with NF producer, NF consumer, and NRF (may be simulated)

1. No token: Send a service request without an access token → verify rejection
2. Expired token: Send request with an expired access token → verify rejection
3. Invalid signature: Send request with a token signed by wrong key → verify rejection
4. Wrong audience: Send request with an access token having incorrect audience claim → verify rejection
5. Wrong scope: Send request with an access token for a different service/resource → verify rejection
6. Malformed token: Send request with a syntactically malformed access token → verify rejection
7. Wrong issuer: Send request with an access token from a non-trusted NRF → verify rejection
8. Valid token: Send request with a valid, correctly scoped access token → verify acceptance

Sub-tests 1–7: The NF service producer rejects the service request with an appropriate error response.
Sub-test 8: The NF service producer accepts and processes the request normally.

HTTP request/response logs, token payloads (decoded JWTs), pcap traces, Pass/Fail per sub-test.

Name: Authorization token verification failure handling across different PLMNs

Description: When receiving service requests from NFs in a different PLMN, the NF service producer shall verify the PLMN ID in the access token and reject requests with mismatched or invalid PLMN identifiers.

1. Wrong PLMN ID: Send request with an access token containing a PLMN ID that does not match the consumer's PLMN → verify rejection
2. Valid cross-PLMN: Send request with a valid access token containing correct PLMN ID → verify acceptance

Sub-test 1: Rejection with appropriate error. Sub-test 2: Normal processing.

Name: Client credentials assertion validation

Reference: TS 33.501 clause 13.3.1, RFC 7523

Description: The NRF shall validate the client credentials assertion (CCA) presented by an NF service consumer when requesting an access token. The CCA is a JWT signed by the NF.

1. Invalid CCA signature: Request access token with a CCA signed by wrong key → NRF rejects
2. Expired CCA: Request access token with an expired CCA → NRF rejects
3. Valid CCA: Request access token with valid, correctly-signed CCA → NRF issues token

Sub-tests 1–2: NRF rejects the token request. Sub-test 3: NRF issues an access token.

HTTP request/response logs, CCA JWT payloads, NRF logs, Pass/Fail per sub-test.

Name: Protecting data and information — confidential system-internal data

Description: Confidential system-internal data (e.g. passwords, secret keys, private keys) shall be stored in a secure manner and shall not be accessible in clear text to unauthorized users or processes.

TR 33.926 §5.3.6 Information disclosure

1. The tester identifies all confidential data items as declared in the vendor documentation
2. The tester verifies that confidential data is stored in encrypted or otherwise protected form
3. The tester verifies that unauthorized users/processes cannot access confidential data in clear text
4. The tester checks configuration files, log files, and debug outputs for unprotected confidential data

No confidential system-internal data is accessible in clear text to unauthorized users or processes.

Name: Password storage support

Description: Passwords shall be stored using a one-way hashing mechanism with a salt. The hashing algorithm shall be a current, non-deprecated algorithm (e.g., bcrypt, scrypt, Argon2, PBKDF2).

1. The tester verifies in the vendor documentation which password hashing algorithm and parameters are used
2. The tester verifies that passwords are stored as salted hashes (not reversible encryption or plain text)
3. The tester verifies the hashing algorithm is not deprecated (not MD5, not SHA-1 for password storage)

All passwords are stored using approved one-way salted hashing. No passwords in plain text or reversible form.

Name: Protecting data and information in transfer

Description: Sensitive data transferred between the network product and external entities shall be protected in transit using approved cryptographic mechanisms (e.g. TLS, IPsec as per TS 33.210).

1. Identify all data transfer interfaces from vendor documentation
2. Verify that all interfaces transferring sensitive data use cryptographic protection
3. Verify the TLS/IPsec configuration conforms to TS 33.210/TS 33.310 requirements
4. Attempt to intercept data in transit and confirm it is encrypted

All sensitive data in transit is protected by approved cryptographic mechanisms.

Name: Password structure

Description: The system shall support enforcement of password complexity rules including: minimum length (≥8 characters), support for upper/lower case, digits, and special characters. Default/initial passwords shall be changed on first login.

1. Attempt to set passwords that violate length requirements → verify rejection
2. Attempt to set passwords without required complexity → verify rejection or warning
3. Verify that default/initial passwords must be changed on first login
4. Verify password complexity configuration options match vendor documentation

Password complexity rules are enforced. Weak passwords are rejected. First-login password change is required.

Name: Password changes

Description: Users shall be able to change their own passwords. The system shall support password expiry/aging policies. Password history shall prevent reuse of recent passwords.

1. Verify a user can change their own password
2. Verify password aging/expiry is configurable and enforced
3. Attempt to reuse a recent password → verify rejection

Password change works. Password aging is enforced. Password history prevents reuse.

Name: Protection against brute force and dictionary attacks

Description: The system shall implement mechanisms to mitigate brute force and dictionary attacks against authentication mechanisms, such as account lockout or increasing delay after consecutive failed attempts.

1. Configure the brute force protection mechanism per vendor documentation
2. Attempt multiple consecutive failed login attempts
3. Verify that the protection mechanism activates (lockout, delay, CAPTCHA, etc.)
4. Verify the mechanism is configurable (threshold, lockout duration, etc.)

After reaching the threshold, further login attempts are blocked or delayed. The mechanism is configurable.

Description: The system shall mask password input on all interfaces (CLI, GUI, web). Passwords shall not be displayed in clear text in any user interface, log file, or configuration display.

1. Enter a password via CLI → verify characters are masked (asterisks or not echoed)
2. Enter a password via web/GUI → verify password field is masked
3. Check logs and configuration displays for password exposure

Passwords are never displayed in clear text on any interface, log, or configuration output.

Name: Mutual authentication

Description: System functions shall not be used without successful authentication and authorization. The system shall support mutual authentication where both the user/entity and the system verify each other's identity.

1. Attempt to access system functions without authentication → verify denial
2. Verify that mutual authentication is supported and can be configured
3. Authenticate successfully and verify access is granted

Name: Consecutive failed login attempts policy

Description: The network product shall implement a policy for handling consecutive failed login attempts. After a configurable number of failed attempts, the account shall be locked for a configurable period or require administrative intervention to unlock.

1. Configure the failed login attempt threshold (e.g., 5 attempts)
2. Attempt to login with incorrect credentials exceeding the threshold
3. Verify the account is locked after threshold is exceeded
4. Verify the account is unlocked after the configured lockout period or by admin action

Name: Protecting sessions — logout

Description: The system shall provide a logout function that terminates the session and invalidates all associated session tokens/credentials. After logout, the user must re-authenticate to access system functions.

1. Login to the system and verify session is established
2. Execute the logout function
3. Attempt to reuse the previous session token/credential → verify denial
4. Verify that re-authentication is required for further access

Name: Protecting sessions — inactivity timeout

Description: The system shall terminate sessions after a configurable period of inactivity. The user must re-authenticate after session timeout.

1. Configure the inactivity timeout period
2. Login and remain inactive for longer than the configured timeout
3. Attempt to use the session → verify it has been terminated
4. Verify re-authentication is required

Name: Security event logging

Description: The network product shall log security-relevant events. Each log entry shall include at minimum: event type, timestamp, outcome (success/failure), identity of the entity involved, and the source of the event.

1. Trigger each category of security event listed above
2. Verify each event is recorded in the security log
3. Verify log entries contain required fields (timestamp, event type, outcome, identity, source)
4. Verify logs cannot be modified or deleted by non-administrative users

Name: Log transfer to centralized storage

Description: The network product shall support the transfer of security logs to a centralized log storage (e.g., syslog server, SIEM). The transfer shall be done in a secure manner (encrypted and/or integrity protected).

1. Configure the network product to send logs to a centralized storage
2. Generate security events and verify they appear in the centralized storage
3. Verify the log transfer is protected (TLS, IPsec, etc.)
4. Verify log integrity is maintained during transfer

Name: Growing content shall not influence system functions

Description: Growing content (such as log files, temporary files, or databases) shall not fill up the file system to the point where the system becomes inoperative. The OS shall have mechanisms (partitioning, quotas, log rotation) to prevent this.

1. Review the vendor documentation for mechanisms to handle growing content
2. Verify that log files and temp directories are on separate partitions or have quotas
3. Simulate excessive log generation and verify the system remains functional
4. Verify that log rotation or equivalent cleanup mechanisms are in place

The system remains operational even when growing content reaches its limits. Mechanisms exist to prevent storage exhaustion.

Name: Processing of ICMPv4 and ICMPv6 packets

Description: The system shall be configurable to control which ICMP message types are processed. Unnecessary ICMP types should be disabled by default to reduce the attack surface.

1. Review vendor documentation for ICMP handling configuration
2. Send each ICMP type to the network product and verify handling matches the documented policy
3. Verify that ICMP types marked "Drop" are silently dropped
4. Verify that ICMP redirect messages are not processed by default

Name: Handling of IP options and IPv6 extension headers

Reference: RFC 7126 — Recommendations on Filtering of IPv4 Packets Containing IPv4 Options

Description: The network product shall handle IPv4 options and IPv6 extension headers according to RFC 7126 recommendations. IP packets with potentially dangerous options (e.g., Source Route, Record Route) shall be dropped by default.

1. Send packets with IPv4 Loose Source Route option → verify they are dropped
2. Send packets with IPv4 Strict Source Route option → verify dropped
3. Send packets with IPv4 Record Route option → verify dropped
4. Send packets with IPv4 Timestamp option → verify dropped
5. Send packets with normal headers → verify accepted
6. For IPv6: send packets with Routing Header Type 0 → verify dropped

Name: Privilege escalation prevention (UNIX-specific)

Description: The system shall minimize privilege escalation risks. SUID/SGID binaries shall be limited to those essential for operation. Linux capabilities shall be minimized.

1. List all SUID binaries: find / -perm -4000 -type f
2. List all SGID binaries: find / -perm -2000 -type f
3. List all binaries with capabilities: getcap -r /
4. Verify each found binary against the vendor's documented list of required SUID/SGID/capabilities
5. Any undocumented SUID/SGID binary or capability shall be flagged

Name: Unique system account identification

Description: Each system account shall have a unique user ID. No two accounts shall share the same UID. Service accounts shall not have interactive login capability unless explicitly required.

1. Check /etc/passwd for duplicate UIDs
2. Verify service accounts have /sbin/nologin or /bin/false as shell
3. Verify vendor documentation covers all system accounts and their purposes

Name: Web server logging

Description: Web server access logs and error logs shall be enabled and shall capture sufficient information for security monitoring and incident investigation.

1. Verify that access logging is enabled on the web server
2. Verify that error logging is enabled
3. Generate requests (valid and invalid) and verify they appear in logs
4. Verify logs include: timestamp, source IP, request method, URI, response code, user agent
5. Verify logs do not contain sensitive data (passwords, tokens, etc.)

1. Session IDs shall be cryptographically random and of sufficient length
2. Session IDs shall not be transmitted in URLs
3. Session cookies shall have the Secure flag set
4. Session cookies shall have the HttpOnly flag set
5. Session IDs shall be regenerated after authentication
6. Session timeout shall be enforced (both idle and absolute)
7. Logout shall invalidate the session on the server side
8. The server shall support only one active session per user (configurable)
9. Session fixation attacks shall be prevented
10. Cross-site request forgery (CSRF) protection shall be implemented
11. Session data shall be stored server-side, not in cookies
12. The SameSite cookie attribute shall be set appropriately

Name: Input validation

Description: All user input accepted by the web application shall be validated. Input validation shall protect against injection attacks including SQL injection, command injection, XSS, LDAP injection, and path traversal.

1. Test all input fields with common injection payloads (SQL, XSS, command injection)
2. Test for path traversal attempts (e.g., ../../etc/passwd)
3. Verify that error messages do not reveal internal implementation details
4. Use a web application security testing tool for comprehensive injection testing

Name: Packet filtering

Reference: RFC 3871 — Operational Security Requirements for Large ISP IP Network Infrastructure

Description: The network product shall support configurable packet filtering (stateful firewall / ACL) on each network interface. The filtering shall support rules based on source/destination IP, protocol, source/destination port, and direction (ingress/egress). A default deny policy shall be configurable.

TR 33.926 §5.3.7.3 Insecure Network Services

• The network product has at least two network interfaces
• The tester has administrative access
• A network traffic generator and analyser (e.g., hping3, scapy, tcpdump) is available
• Vendor documentation describes the packet filtering capabilities

1. Configure a default-deny policy on all interfaces
2. Add specific allow rules for required traffic
3. Send packets matching allowed rules → verify they are forwarded/accepted
4. Send packets not matching any allow rule → verify they are dropped
5. Verify filtering works for both ingress and egress directions
6. Verify rules can be configured per-interface
7. Verify filtering criteria: source IP, destination IP, protocol, source port, destination port

Packet filtering is functional, configurable per-interface, supports default deny, and correctly allows/drops packets based on configured rules.

Firewall/ACL configuration, pcap captures, traffic generator commands, Pass/Fail result.

Name: Interface robustness

Description: The network product shall be robust against malformed, oversized, fragmented, or otherwise unexpected packets received on any interface. Such packets shall not cause crashes, resource exhaustion, or security breaches.

1. Send malformed packets (truncated headers, invalid fields) to each interface
2. Send oversized packets exceeding MTU
3. Send heavily fragmented packets
4. Send packets with invalid checksums
5. Monitor the network product for crashes, memory leaks, or degraded performance

The network product remains stable and functional. Malformed packets are silently dropped or logged without causing system instability.

Name: GTP-C filtering

Reference: In accordance with industry best practice and TS 33.501

Description: For network products that receive GTP-C (GTP Control Plane) traffic, the network product shall be capable of filtering GTP-C messages. The filtering shall support inspection of GTP-C header fields and permit/deny decisions based on GTP-C message type, TEID, and other relevant fields.

TR 33.926 §5.3.7.3 Insecure Network Services ▶

TR 33.926 §5.3.6.15 Lack of GNP traffic isolation ▶

• The network product receives GTP-C traffic (e.g., it implements S11, S5/S8, N11 GTP-C interfaces)
• The network product is configured to filter GTP-C messages per vendor documentation
• A GTP-C traffic generator/simulator is available (e.g., capable of generating GTPv2-C messages)
• A network traffic analyser (e.g., tcpdump, Wireshark with GTP dissector) is available
• The tester has administrative access to the network product
• Vendor documentation describes the GTP-C filtering capabilities, supported message types, and configuration

1. Verify documentation: Confirm vendor documentation describes GTP-C filtering capabilities and configuration
2. Configure filtering: Configure GTP-C filtering rules on the network product per vendor documentation
3. Valid GTP-C messages: Send valid GTP-C messages matching allowed message types → verify they are accepted and processed
4. Blocked message types: Send GTP-C messages with message types that are not allowed → verify they are dropped/rejected
5. Invalid TEID: Send GTP-C messages with invalid or unknown TEIDs → verify appropriate handling (drop or error response)
6. Malformed GTP-C: Send malformed GTP-C messages (truncated, invalid header fields, wrong version) → verify they are dropped without crashing
7. GTP-C on wrong port: Send GTP-C messages on non-standard ports → verify they are dropped
8. Spoofed source: Send GTP-C messages from non-authorized source IP addresses → verify they are dropped
9. Rate limiting: If GTP-C rate limiting is supported, verify that excessive GTP-C message rates are throttled
10. Logging: Verify that filtered/dropped GTP-C messages are logged with sufficient detail for forensic analysis

• Only valid, authorized GTP-C messages are processed
• Unauthorized, malformed, or unexpected GTP-C messages are dropped
• The network product remains stable when receiving malformed GTP-C traffic
• Filtering events are properly logged

GTP-C filter configuration, pcap traces showing accepted and dropped GTP-C messages, log files showing filter events, traffic generator configuration/commands, Pass/Fail per step.

Name: GTP-U filtering

Reference: In accordance with industry best practice and TS 33.501

Description: For network products that receive GTP-U (GTP User Plane) traffic, the network product shall be capable of filtering GTP-U packets. The filtering shall support inspection of GTP-U header fields and permit/deny decisions based on TEID, source/destination addresses in the inner packet, and other relevant criteria.

TR 33.926 §5.3.7.3 Insecure Network Services ▶

TR 33.926 §5.3.6.15 Lack of GNP traffic isolation ▶

• The network product receives GTP-U traffic (e.g., it implements S1-U, S5/S8-U, N3, N9 GTP-U interfaces)
• The network product is configured to filter GTP-U traffic per vendor documentation
• A GTP-U traffic generator is available (e.g., capable of encapsulating user-plane data in GTP-U)
• A network traffic analyser with GTP-U dissector capability is available
• The tester has administrative access
• Vendor documentation describes GTP-U filtering capabilities and configuration

1. Verify documentation: Confirm vendor documentation describes GTP-U filtering capabilities and configuration
2. Configure filtering: Configure GTP-U filtering rules on the network product per vendor documentation
3. Valid GTP-U traffic: Send valid GTP-U encapsulated traffic with authorized TEIDs → verify accepted and forwarded
4. Invalid TEID: Send GTP-U packets with invalid or unassigned TEIDs → verify they are dropped
5. Inner packet filtering: Send GTP-U packets with inner IP packets that violate filtering rules (e.g., unauthorized destination) → verify dropped
6. Malformed GTP-U: Send malformed GTP-U packets (truncated, invalid version, wrong header flags) → verify dropped without crashing
7. GTP-U on wrong port: Send GTP-U traffic on non-standard ports → verify dropped
8. Spoofed outer source: Send GTP-U from unauthorized source IPs → verify dropped
9. GTP-in-GTP: Send GTP-U packets encapsulated within GTP-U (nested tunneling) → verify handling per policy (typically drop)
10. Logging: Verify that filtered/dropped GTP-U packets are logged with sufficient detail

• Only valid, authorized GTP-U traffic is forwarded
• Unauthorized, malformed, or unexpected GTP-U packets are dropped
• Inner packet inspection works correctly for GTP-U decapsulated traffic
• The network product remains stable under malformed GTP-U traffic
• Filtering events are properly logged

GTP-U filter configuration, pcap traces showing accepted and dropped GTP-U packets, log files, traffic generator configuration, Pass/Fail per step.

Name: No unnecessary or insecure services

Description: No unnecessary or insecure services or protocols shall be active on any network interface. Services that should be disabled by default include: Telnet, FTP, TFTP, SNMP v1/v2c, rlogin, rsh, BOOTP server, discovery protocols (CDP, LLDP), Identd.

TR 33.926 §5.3.7.3 Insecure Network Services ▶

• Vendor provides a list of all required network protocols, services, open ports, and their purposes
• A port scanning / service identification tool is available

1. Verify the vendor documentation lists all required services and justifies each
2. Use tools to identify all running services and protocol handlers on the network product
3. Validate that no undocumented services are running
4. Reboot the network product and re-execute steps 2-3 to verify persistence

No unnecessary services running. No undocumented services. Behavior is consistent after reboot.

Description: Services shall be restricted to interfaces where their usage is required. Administrative services (SSH, HTTPS, RDP) shall be restricted to management interfaces to support traffic separation.

1. For each interface: run port scan to identify reachable services
2. Verify services are only reachable on designated interfaces per vendor documentation
3. Administrative services must not be reachable from user/data plane interfaces

Description: Unused software components shall not be installed or shall be deleted. This includes examples, default web pages, test data, and sample databases.

1. Verify vendor provides complete software inventory (name, version, dependencies, purpose)
2. Identify installed software using package managers (apt, rpm, pip, npm, etc.)
3. Validate no software exists beyond what's documented as necessary
4. Check for default configuration or example files

Description: Unused hardware and software functions shall be permanently deactivated. This includes unused interfaces (e.g., Bluetooth), debugging functionality, and unnecessary kernel modules. "Permanently" means not reactivated after reboot.

1. Verify vendor documentation lists all hardware and software functions
2. Identify active hardware/software functions using tools (lspci, lsusb, lsmod, etc.)
3. Validate no undocumented functions are active

Description: No software or hardware components that have reached end-of-life or end-of-support shall be present, unless covered by a special support contract guaranteeing vulnerability correction.

1. Identify all software/hardware components and their versions
2. Verify each component's support status (not EOL/EOS)
3. Flag any unsupported components

Description: Direct login as root or equivalent highest-privileged user shall be limited to the physical console only. Remote root login shall be disabled.

1. Attempt remote login as root via SSH/other remote interfaces → verify rejection
2. Attempt login as root from the physical console → verify success

Remote root login is denied. Console root login is permitted. Pass/Fail.

Description: File system permissions shall enforce that users can only modify files/directories they are authorized for. Sticky bit shall be set on world-writable directories.

1. Verify OS-level permissions match vendor documentation
2. Login as non-admin user and attempt to modify authorized files → verify success
3. Attempt to modify unauthorized files → verify permission denied

Name: IP-Source address spoofing mitigation

Description: Systems shall not process IP packets if their source address is not reachable via the incoming interface. Implementation example: Reverse Path Filter (RPF) — e.g., net.ipv4.conf.all.rp_filter = 1

TR 33.926 §5.3.3.5 IP Spoofing ▶

• Node N1: Two interfaces — if1-n1 connected to network product, if2-n1 (192.168.3.1/24) with tester machine
• Node N2: Two interfaces — if1-n2 connected to network product, if2-n2 (same IP as if2-n1: 192.168.3.1/24)
• Network Product: if1-np (192.168.1.x) → N1, if2-np (192.168.2.x) → N2
• Static route on network product: 192.168.3.0/24 reachable via if1-n1 through if1-np

1. From tester via N1: send pings to if1-np → verify pings reach and responses are sent
2. Disconnect tester from N1, reconnect to N2 (same IP config)
3. Send pings to if1-np → verify pings reach but are dropped (source not routable via incoming interface)
4. Send pings to if2-np → verify also dropped
5. If logging available, verify dropped packets are recorded

RPF or equivalent anti-spoofing is active. Packets with source addresses not routable via the incoming interface are silently dropped.

TR 33.926 §5.3.6.11 Unnecessary Services — Prevents Smurf, Fraggle, ARP cache poisoning, and man-in-the-middle attacks ▶

Description: The network product shall not automatically launch any application when removable media (CD, DVD, USB) is connected. Auto-mount shall be disabled.

1. Prepare removable media with autostart files
2. Insert into each accessible port
3. Verify no auto-mount and no auto-launch

Description: The network product shall support SYN flood prevention (e.g., TCP SYN cookies: net.ipv4.tcp_syncookies = 1). This shall be enabled by default.

1. Verify SYN flood prevention mechanism in vendor documentation
2. Use tool (e.g., hping3 -i <interval> -S -p <port> -d <size> -c <count> <IP>) to generate SYN flood
3. Verify network product remains functional during and after the attack
4. Verify services remain accessible and responsive
5. Verify CPU/memory usage stays within acceptable thresholds

The network product does not become inoperative under SYN flood attack.

Description: The system shall support buffer overflow protection mechanisms (e.g., ASLR, DEP/NX bit, stack canaries, PIE). Documentation describing these mechanisms and how to verify them shall be provided.

1. Verify technical documentation describes buffer overflow protection mechanisms
2. Verify whether protections are enabled by default or require manual activation
3. Review test results demonstrating the protection mechanisms are functional

Description: OS-level restrictions (nodev, nosuid) shall be set for user-mountable filesystems to prevent privilege escalation. In Linux: set nodev and nosuid in /etc/fstab for filesystems with the "user" option.

1. Verify OS-level mount restrictions in /etc/fstab
2. Mount a prepared external filesystem with SUID files
3. Attempt privilege escalation using mounted content → verify blocked

Name: Traffic separation

Reference: RFC 3871

Description: The network product shall support physical or logical separation of traffic belonging to different network domains (e.g., O&M vs. control plane vs. user plane).

1. Verify the network product has separate interfaces for different domains
2. Send traffic intended for one domain on another domain's interface → verify it is rejected
3. Repeat for all pairs of network domains

Traffic is not passed between domains. Each domain's traffic stays on its designated interfaces. Pass/Fail.

Name: No code execution or inclusion of external resources by JSON parsers

Description: JSON parsers used by NFs shall not execute JavaScript or any other code contained in received JSON objects. Parsers shall not include external resources (filesystem files, URIs) referenced in JSON payloads.

TR 33.926 §6.3.2.1 JSON Parser Exploits ▶

1. Use a Web Application Security tool to send HTTP requests with JSON payloads containing JavaScript code
2. Send JSON payloads with references to local filesystem paths
3. Send JSON payloads with references to external URIs
4. Using tcpdump/traffic analyser, verify no external resources are loaded during parsing
5. Verify no code is executed from JSON payload content

Reference: TS 29.501 clause 6.2

Description: Duplicate key names in JSON objects shall result in an error and message rejection.

1. Send HTTP requests with duplicate keys in JSON payload → verify error response
2. Send valid requests → verify normal processing

Reference: TS 29.501 clause 6.2

Description: The NF shall enforce limits on JSON message structure:

• Maximum leaf IEs per message: 2,048K
• Maximum JSON body size: 16 million octets
• Maximum nesting depth: 32 levels

1. Send HTTP requests with JSON bodies exceeding each limit → verify error response
2. Send valid requests within limits → verify normal processing