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

Data masking on integration analysis about personal data

TBA.

NWDAF can collect data from UE, NF, OAM, etc. used for analytics. Personal data of the UE's user are involved also. When NWDAF uses such personal data in analytics with other information together, such data correlation operation could bind more personal information with the user's identity. Thus, privacy information about that specific user could be revealed to the person who is allowed to operate data correlation for analytics but not allowed to know the privacy information as the result of data correlation. Therefore, applicable measures (e.g. data masking) shall be applied to mitigate such privacy violation risk.

Verify that no privacy information of operators' users is revealed to the party who is not allowed to have.

The vendor shall provide the documentation describing how to create an account for accessing the analytics results.

Privacy information list (should be specified based on local policy, regulation and others).

1. Review the documentation provided by the vendor describing how to create the account for accessing the analytics results provided by the NWDAF.

2. The tester creates the account, and retrieves the analytics results from the NWDAF using the account.

The tester can create the account, and the account does not reveal subscriber permanent identifier.

Evidence suitable for the interface, e.g. screenshot containing the results.

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

Data masking on integration analysis about personal data

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.

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.