Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 33.117  Word version:  17.1.0

Top   Top   None   None   Next
1…   4.2…   4.2.3…   4.2.3.4…   4.2.3.5…   4.2.4…   4.3…   4.3.4…   4.4…

 

1  Scopep. 7

The present document contains objectives, requirements and test cases that are deemed applicable, possibly after adaptation, to several network product classes.
Several network product classes share very similar if not identical security requirements for some aspects. Therefore, these are collected in this "catalogue" document applicable to many network product classes. In addition to this catalogue, requirements specific to different network product classes will be captured in separate documents.
Up

2  Referencesp. 7

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TR 41.001: "GSM Specification set".
→ to date, withdrawn by 3GPP
[3]
RFC 3871:  "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure".
[4]
TR 33.926: "Security Assurance Specification (SCAS) threats and critical assets in 3GPP network product classes".
[5]
CVE-1999-0511, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0511
[6]
"Practical recommendations for securing Internet-connected Windows NT Systems", https://support2.microsoft.com/default.aspx?scid=kb;%5BLN%5D;164882.
[7]
X-Force Vulnerability Report, http://www.iss.net/security_center/static/193.php
[8]
RFC 2644:  "Changing the Default for Directed Broadcasts in Routers."
[9]
TS 33.310: "Network Domain Security (NDS); Authentication Framework (AF)".
[10]
TS 33.501: v15 "Security architecture and procedures for 5G system".
[11]
RFC 7540:  "Hypertext Transfer Protocol Version 2 (HTTP/2)".
[12]
RFC 6749:  "OAuth2.0 Authorization Framework".
[13]
TS 29.501: "Principles and Guidelines for Services Definition".
[14]
TS 33.501: "Security architecture and procedures for 5G system" (Release 16).
[15]
TS 33.210: "Network Domain Security (NDS); IP network layer security".
Up

3  Definitions and abbreviationsp. 8

3.1  Definitionsp. 8

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
Machine Accounts:
These will be used for authentication and authorization from system to system or between applications on a system and cannot be assigned to a single person or a group of persons.
Personal data:
any information relating to an identified or identifiable natural person ('data subject').
Identifiable person:
one who can be identified, directly or indirectly, in particular by reference to an identification number, name or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity.
Sensitive data:
data that may be used for authentication or may help to identify the user, such as user names, passwords, PINs, cryptographic keys, IMSIs, IMEIs, MSISDNs, or IP addresses of the UE, as well as files of a system that are needed for the functionality such as firmware images, patches, drivers or kernel modules.
System group account:
a predefined system account in the network product, usually with special privileges, which has a predefined user id and hence cannot be tied to a single user (individual) in a normal operating environment.
EXAMPLE:
the 'root' account.
Up

3.2  Abbreviationsp. 8

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
API
Application Programming Interface
CIS
Center for Internet Security
JSON
Java Script Object Notation
NF
Network Function
NRF
Network Repository Function
SBA
Service Based Architecture
SBI
Service Based Interfaces
SEPP
Security Edge Protection Proxy
URI
Uniform Resource Identifier
WAS
Web Application Security
Up

4  Catalogue of security requirements and related test casesp. 9

4.1  Introductionp. 9

4.1.1  Pre-requisites for testingp. 9

The SCAS tests, as described in the present specification, are to be applied to a network product whose software and hardware has been brought into use so that the network product can provide the intended functionality, either in a real network environment or in a simulated environment. This implies that, before any testing is performed, the hardware and software has been installed correctly, the network product is powered on, and communication has been established over all standardized interfaces and OAM interfaces related with the network product's functionality, as described in the vendor's documentation.
Communication over external non standardized Interfaces that may exist and are marked as optional, according to the vendor's documentation, shall also be established during testing unless they are explicitly marked as "not recommended" in the vendor's documentation.
For each of the enabled external communication interfaces there may be various optional capabilities. During testing, all such capabilities shall be enabled unless they are explicitly marked as "not recommended" in the vendor's documentation.
In some cases a testcase might require configuration changes as part of the execution steps or pre-conditions. After such test is executed and prior to any further test execution it needs to be ensured that the state of the ToE is restored back in the original state.
SCAS testing is not about security in operations and deployments. So, in particular, SCAS testing is independent of any operator guidelines or considerations on specific deployment scenarios.
Up

4.1.2  Use of tools in testingp. 9

The following text shall apply to all test cases described in the present document:
The present document takes into account that the landscape of testing tools evolves more rapidly than SCAS specifications. It is therefore allowed that, for each requirement, the actual test carried out may deviate from the stepwise description of the test case in the present document if the following conditions are fulfilled:
  1. The test is carried out by preferably using Commercial-of-the-Shelf (COTS) and Free-Open-Source-Software (FOSS) tools that are available for other testers that may want to repeat the test. In case a tool not in any of these two categories is used then evidence of the quality assurance of the tool needs to be provided. This applies only to tools used to perform the actual test and not supportive tools needed for setting up the testing environment like for example traffic generators/ simulators.
    In cases where a test lab is not able to obtain the necessary tools to perform the test, vendor proprietary test tools may be used by the test lab as long the test tool is controlled under a suitable quality management system (QMS). The test lab ensures that this QMS is in place in order to avail of a vendor's test tool.
    Additionally in cases where the accredited test lab does not have the necessary test environment to perform a test, it shall be possible for the accredited test lab personnel to perform the test in a vendor's test lab. In such cases the accredited lab should record details of test environment, test set-up used and how the test was performed.
  2. The tester provides evidence, e.g. by referring to the documentation of the tool, that the tool is suitable to verify the requirement, and the scope of testing is equal or larger to the one of the test case described in the present document. The evidence needs to be sufficiently detailed for experts in the field of testing, not for the general public.
  3. The tester provides evidence that the tool has been actually used for testing the network product (e.g. by providing a trace).
Up

4.1.3  Documentation Requirementsp. 10

When a test case makes an assumption on the availability of certain items in the product documentation then this assumption is to be considered part of the requirement even if the requirements text does not mention the documentation.

Up   Top   ToC