Content for  TS 33.117  Word version:  18.3.0

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


1  Scopep. 8

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.

2  Referencesp. 8

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.
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]  Void
RFC 3871:  "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure".
TR 33.926: "Security Assurance Specification (SCAS) threats and critical assets in 3GPP network product classes".
[5]  Void
[6]  Void
[7]  Void
[8]  Void
TS 33.310: "Network Domain Security (NDS); Authentication Framework (AF)".
TS 33.501: v15 "Security architecture and procedures for 5G system".
RFC 7540:  "Hypertext Transfer Protocol Version 2 (HTTP/2)".
RFC 6749:  "OAuth2.0 Authorization Framework".
TS 29.501: "Principles and Guidelines for Services Definition".
[14]  Void
TS 33.210: "Network Domain Security (NDS); IP network layer security".
RFC 7515:  "JSON Web Signature (JWS)".
RFC 7519:  "JSON Web Token (JWT)".
TS 23.501: "System Architecture for the 5G System".
TR 33.916: "Security Assurance Methodology (SECAM) for 3GPP network products".
RFC 7126:  "Recommendations on Filtering of IPv4 Packets Containing IPv4 Options".
TS 29.500: "Technical Realization of Service Based Architecture".

3  Definitions and abbreviationsp. 9

3.1  Definitionsp. 9

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.
Automatic assessment tool:
A software that operates with a minimal human intervention and aids the user in evaluation of the security of computer programs, systems and/or networks.
A creator of systems, components, or services for use on or with a 3GPP network.
Expert knowledge:
Possesing skills, training and experience in analysing and understanding security threats in a wide variety of situations.
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 their physical, physiological, mental, economic, cultural or social identity.
Local access:
Communication through a direct network access interface.
Machine Accounts:
accounts 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.
Network Element:
As defined in TS 23.501.
Network Function:
As defined in TS 23.501.
Network product:
As defined in TR 33.916.
Network product class:
As defined in TR 33.916.
The person or enity responsible for creating and maintaining content. The person or enity determines who has access to the content and the content permissions.
Personal data:
any information relating to an identified or identifiable natural person ('data subject').
Remote access:
Communication through an external network access interface.
A digital image that shows the contents of a display.
Sensitive data:
data 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.
A commercial supplier of 3GPP network software or hardware.
As defined in TR 33.916.

3.2  Abbreviationsp. 10

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.
Authentication Authorization and AccountingBOOTP Bootstrap Protocol
Basic Vulnerability Testing
Completely Automated Public Turing test to tell Computers and Humans Apart
Compact Disk
Customer Data Platform
Center for Internet Security
Commercial Off The Shelf
Common Vulnerabilities and Exposures
Datagram Transport Layer Security
Digital Video Disk
Free Open-Source Software
File Transfer Protocol
GPRS Tunnelling Protocol for Control Plane
Graphical User Interface
Globally Unique Identifer
Internet Key Exchange
Internet Protocol Security
Java Script Object Notation
JSON Web Signature
Local Loop Demarcation Protocol
Maintenance Operations ProtocolNRF Network Repository Function
Network Slice Instance
Network Slice Instance Identifier
Network Slice Selection Assistance Information
Hypertext Preprocessor
Performance Management
Quality Management System
Random Access Memory
Role Based Access Control
Remote Copy Program
Remote Delete Program
Reverse Path Filter
Remote shell
Service Based Architecture
Service Based Interfaces
Security Assurance Specification
Service Communication Proxy
Security Assurance Methodology
Security Edge Protection Proxy
Secure File Transfer Protocol
Special Group Identification
Single Network Slice Selection Assistance Information
Secure Shell
Server Side Includes
Single Sign-On
Set owner User Idenification
Synchrounous Transmission
Trivial File Transfer Protocol
Web Application Security
Web Distributed Authoring and Versioning

4  Catalogue of security requirements and related test casesp. 11

4.1  Introductionp. 11

4.1.1  Pre-requisites for testingp. 11

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 O&M 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 Product under Evaluation 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 network operator guidelines or considerations on specific deployment scenarios.

4.1.2  Use of tools in testingp. 12

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 tester is not able to obtain the necessary tools to perform the test, vendor proprietary test tools may be used by the tester as long the test tool is controlled under a suitable quality management system (QMS). The tester ensures that this QMS is in place in order to avail of a vendor's test tool.
    Additionally in cases where the test lab does not have the necessary test environment to perform a test, it shall be possible for the test lab personnel to perform the test in a vendor's test lab. In such cases the tester shall 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).

4.1.3  Documentation Requirementsp. 12

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