TR 33.926 [ 4], clause 5.3.6.7, Personal Identification Information Violation

Data masking on integration analysis about personal data

In accordance with industry best practice..

NWDAF can collect data from OAM, MDAF and/or 5GC NFs (e.g. AMF) etc. for analytics purposes. Since personal data of the users could be involved , there is a potential privacy impact. As the NWDAF can expose its service operations with a request for bulked data, anonymization of data fields shall be applied to avoid exposing undesired information, aggregation levels.

Verify that no privacy-related information of the subscribers is disclosed to any entity who is not authorized to access such information.

Privacy information list (contains e.g. PII, location data, network identifiers, session information; should be specified based on local policy, regulation and others).

NOTE: If user consent check is implemented, user consent for data collection is granted.

The following entities are operational, integrated and simulated:

• NWDAF.

• 'data producer' (NF- or OAM as source for data collection which generates user data containing privacy info, e.g. AMF).

• 'analytics consumer' (NF- or OAM to which the NWDAF exposes analytics).

The data producer is configured to receive and accept subscription requests from the NWDAF for events according to TS 29.552 [6], clause 5.5.1.1.

1. Tester triggers behaviour so that the 'data producer' is required to handle privacy information (e.g. for AMF trigger registration request at UE).

2. The tester sends an Nnwdaf_AnalyticsInfo_Request request message from the 'analytics consumer' to NWDAF according to TS 29.552 [6], clause 5.2.3.1. The request message shall be crafted to capture information from step 1.

3. The tester retrieves the Nnwdaf_AnalyticsInfo_Request response message from the NWDAF.

The analytics results do not reveal subscriber permanent identifier nor any other data listed on the Privacy information list.

Evidence suitable for the interface, e.g. screenshot, pcap trace, log files containing the results.

TR 33.926 [ 4], clause 5.3.6.7, Personal Identification Information Violation

Data masking on integration analysis about personal data

In accordance with industry best practice..

NWDAF can collect data from OAM, MDAF and/or 5GC NFs (e.g. AMF) etc. for analytics purposes. Since personal data of the users could be involved , there is a potential privacy impact. As the NWDAF can expose its service operations with a request for bulked data, anonymization of data fields shall be applied to avoid exposing undesired information, aggregation levels.

Verify that no privacy-related information of the subscribers is disclosed to any entity who is not authorized to access such information.

Privacy information list (contains e.g. PII, location data, network identifiers, session information; should be specified based on local policy, regulation and others).

NOTE: If user consent check is implemented, user consent for data collection is granted.

The following entities are operational, integrated and simulated:

• NWDAF.

• 'data producer' (NF- or OAM as source for data collection which generates user data containing privacy info, e.g. AMF).

• 'analytics consumer' (NF- or OAM to which the NWDAF exposes analytics).

The data producer is configured to receive and accept subscription requests from the NWDAF for events according to TS 29.552 [6], clause 5.5.1.1.

1. Tester triggers behaviour so that the 'data producer' is required to handle privacy information (e.g. for AMF trigger registration request at UE).

2. The tester sends an Nnwdaf_AnalyticsInfo_Request request message from the 'analytics consumer' to NWDAF according to TS 29.552 [6], clause 5.2.3.1. The request message shall be crafted to capture information from step 1.

3. The tester retrieves the Nnwdaf_AnalyticsInfo_Request response message from the NWDAF.

The analytics results do not reveal subscriber permanent identifier nor any other data listed on the Privacy information list.

Evidence suitable for the interface, e.g. screenshot, pcap trace, log files containing the results.

TR 33.926 [4], threats related to "Privilege Escalation" and "Unauthorized Service Access".

Fine-grained authorization for analytics services

In accordance with TS 33.501 [7], clauses X.8, X.9, and X.12.

The NF Service Producer authenticates the NF Service Consumer and verifies the access token and ensures that the Analytics ID is included in the access token.

To verify that the NWDAF, when acting as an NF service producer, can perform fine-grained authorization control based on the Analytics ID claim in an access token within procedures such as Nnwdaf_RoamingAnalytics_Subscribe/Request. The test ensures that a service consumer is only able to access the specific analytics type(s) it is authorized for.

NOTE: This test case applies only when the access token includes Analytics ID.

• The NWDAF under test is configured to support at least two distinct analytics services, Analytics ID 1 and Analytics ID 2.

• The tester has the capability to generate valid OAuth 2.0 access tokens. Two valid OAuth 2.0 access tokens are pre-configured and prepared for testing:

• Token_A: Contains Analytics ID 1 in its claims.

• Token_B: Contains Analytics ID 2 in its claims.

• The vendor's product documentation describes the NWDAF's authorization policies and the APIs for the analytics services.

• The NWDAF under test has already authenticated the NF service consumer (simulated by the tester).

1. The tester sends an Nnwdaf_RoamingAnalytics_Subscribe/Request message to the NWDAF for Analytics ID 1, including Token_A in the request. The tester observes and records the NWDAF's response.

2. The tester sends an Nnwdaf_RoamingAnalytics_Subscribe/Request message to the NWDAF for Analytics ID 2, including Token_A in the request. The tester observes and records the NWDAF's response.

3. The tester repeats step 1, but uses Token_B for the request to Analytics ID 1.

4. The tester repeats step 2, but uses Token_B for the request to Analytics ID 2.

1. The request in Step 1 (authorized Analytics ID) is processed successfully by the NWDAF (subject to other normal conditions being met).

2. The request in Step 2 (unauthorized Analytics ID) is rejected by the NWDAF with an appropriate error (e.g., 403 Forbidden with OAuth 2.0 error insufficient_scope).

3. The request in Step 3 (unauthorized Analytics ID for Token_B) is rejected by the NWDAF with an appropriate error.

4. The request in Step 4 (authorized Analytics ID for Token_B) is processed successfully by the NWDAF.

Logs, network traces (e.g., .pcap files), or screenshots of the relevant interface messages. The evidence must clearly show:

1. The Nnwdaf_RoamingAnalytics_Subscribe/Request request messages, including the target Analytics ID and the access token used (Token A or Token B).

2. The corresponding success or error response (including status code and error details) from the NWDAF.

TR 33.926 [4], threats related to "Unauthorized Access to Critical Assets" and "Model Poisoning".

Analytics ID-level access control for ML model assets in MTLF provisioning

In accordance with TS 33.501 [7], clauses X.9 and X.10.

The NWDAF containing the MTLF verifies that the Analytics ID contained within the access token's scope matches the Analytics ID associated with the requested ML model asset.

To verify that the NWDAF, when acting as an MTLF (NF service producer), can perform fine-grained authorization control based on the Analytics ID claim in an access token within the Nnwdaf_MLModelProvision_Subscribe procedure. The test ensures that a service consumer is only able to access the specific ML model asset(s) it is authorized for.

NOTE: This test case applies only when the access token includes Analytics ID.

• The vendor's product documentation describes the ML model provisioning procedure and the associated authorization mechanism for the Nnwdaf_MLModelProvision_Subscribe service operation.

• A test environment with at least one NWDAF containing an MTLF and one NWDAF containing an AnLF (or an equivalent simulation provided by the vendor) shall be available.

• The MTLF under test is configured with at least two distinct ML model assets, identifiable by different Analytics IDs (e.g., Analytics ID 1 and Analytics ID 2).

• The tester has the capability to generate valid OAuth 2.0 access tokens. Two valid OAuth 2.0 access tokens are pre-configured and prepared for testing:

• Token_A: Contains Analytics ID 1 in its claims.

• Token_B: Contains Analytics ID 2 in its claims.

1. The tester sends an Nnwdaf_MLModelProvision_Subscribe request to the MTLF for the ML model corresponding to Analytics ID 1, including Token A in the request. The tester observes and records the MTLF's response.

2. The tester sends an Nnwdaf_MLModelProvision_Subscribe request to the MTLF for the ML model corresponding to Analytics ID 2, including Token A in the request. The tester observes and records the MTLF's response.

3. The tester repeats step 1, but uses Token_B for the request to Analytics ID 1.

4. The tester repeats step 2, but uses Token_B for the request to Analytics ID 2.

1. The request in Step 1 (authorized Analytics ID for Token A) is accepted by the MTLF, and ML model information for Analytics ID 1 is returned normally.

2. The request in Step 2 (unauthorized Analytics ID for Token A) is rejected by the MTLF with an appropriate error (e.g., 403 Forbidden with OAuth 2.0 error insufficient_scope).

3. The request in Step 3 (unauthorized Analytics ID for Token B) is rejected by the MTLF with an appropriate error.

4. The request in Step 4 (authorized Analytics ID for Token B) is accepted by the MTLF, and ML model information for Analytics ID 2 is returned normally.

Logs, network traces (e.g., .pcap files), or screenshots of the relevant interface messages. The evidence must clearly show:

1. The Nnwdaf_MLModelProvision_Subscribe request messages, including the target Analytics ID and the access token used (Token A or Token B).

2. The corresponding success or error response (including status code and error details) from the MTLF for each of the four execution steps.