Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 33.926  Word version:  17.6.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   A…   B…   C…   D…   E…   F…   G…   H…   I…   J…   K…   L…   M…   O…   P…

 

4  Generic Network Product (GNP) class descriptionp. 13

4.1  Overviewp. 13

A 3GPP generic network product class defines a set of functions that are implemented on that product, which includes, but not limited to minimum set of common 3GPP functions for that product covered in 3GPP specifications, other functions not covered by 3GPP specifications, as well as interfaces to access that product. A generic network product also includes hardware, software, and OS components that the product is implemented on. The current document describes the threats and the critical assets in the course of developing 3GPP security assurance specifications for a particular network product class.
Applicability of the GNP security assurance specification to products: Assume a telecom equipment vendor wants to sell a product to an operator, and the latter is interested in following the Security Assurance Methodology as described in TR 33.916, then, before evaluation according to TR 33.916 in a testing laboratory can start, it first needs to be determined which security assurance specifications written by 3GPP apply to the given product.
Each 3GPP Network Product, is basically a device composed of hardware (e.g. chip, processors, RAM, network cards), software (e.g. operating system, drivers, applications, services, protocols), and interfaces (e.g. console interfaces and O&M interfaces) that allow the 3GPP network product to be managed and configured locally and/or remotely A GNP is a 3GPP network product.
GNP Security Assurance Specification (GNP SCAS): The GNP SCAS provides a description of the security requirements (which are including test cases) pertaining to that generic network product class.
Need for a GNP network product model: This minimum set of functions listed in clause 4.2 is exclusively meant as a membership criterion for the GNP Class. It is not meant to restrict the functionality of a GNP, or the scope of the present document in any way. On the contrary, it is clear that GNPs will contain many more functions than those from the minimum set listed in clause 4.2, and the GNP will contain requirements relating to functions not contained in this minimum set. Some of these functions, beyond the minimum set, can be found from various 3GPP specifications, but by far not all these functions. This implies that there is a need to describe the functions that cannot be found from 3GPP specifications in some other way before the GNP can be written so that the GNP can make reference to this description. This description is the GNP model, cf. clause 4.3.
EXAMPLE 1:
3GPP specifications do not describe a local management interface, but the GNP will have to take it into account, so a local management interface needs to be part of an GNP model.
EXAMPLE 2:
The GNP sometimes says e.g.: "Authentication events on the local management interface shall be logged." This implies the presence of a logging function. The logging function is not part of the defining minimum set of functions from clause 4.2. If a product implements this minimum set, but no logging function, then this just means that the product is a GNP, but will fail the evaluation against the GNP SCAS.
The GNP model is further used in clauses 5 and 6 in various ways, e.g. the critical assets can point to parts of the GNP model, threats and requirements can refer to interfaces shown in the GNP model, etc.
Up

4.2  Minimum set of functions defining the GNP classp. 14

According to TR 33.916, a network product class is a class of products that all implement a common set of 3GPP-defined functionalities. This common set is defined to be the list of functions contained in pertinent 3GPP specifications, such as clause 4.3 of TS 23.401, Release 8.
Up

4.3  Generic network product modelp. 14

4.3.1  Generic network product model overviewp. 14

Figure 4.3-1 depicts the components of a generic network product model at a high level.
These components are further described in the following subclauses.
Copy of original 3GPP image for 3GPP TS 33.926, Fig. 4.3-1: GNP model
Figure 4.3-1: GNP model
(⇒ copy of original 3GPP image)
Up

4.3.2  Functions defined by 3GPPp. 14

A GNP will, in many cases, implement 3GPP-defined functions from various releases of pertinent 3GPP specifications. Vendors are, to a large extent, free to select the features implemented in their GNPs. E.g. a GNP could lack support for relay nodes, as introduced in Release 10, but implement all other features defined up to and including Release 10.

4.3.3  Other functionsp. 14

A GNP will also contain functionality not or not fully covered in 3GPP specifications.
Examples include, but are not limited to, local or remote management functions.

4.3.4  Operating System (OS)p. 14

The present document assumes that the GNP is implemented on dedicated hardware that requires an operating system to run.

4.3.5  Hardwarep. 14

The present document assumes that the GNP is implemented on dedicated hardware. Aspects of virtualization and cloud are not taken into account in the present version.

4.3.6  Interfacesp. 15

There are two types of logical interfaces defined for the GNP:
  • remote logical interfaces; and
  • local logical interfaces.
A remote logical interface is an interface which can be used to communicate with the GNP from another network node.
The entire protocol stack implementing the communication is considered to be part of the remote logical interface.
Remote Logical Interfaces also include the remote access interfaces to the GNP for its maintenance through e.g. an Element Management System (EMS).
A local logical interface is an interface that can be used only via physical connection to the GNP. That is, the connection requires physical access to the GNP.
The entire protocol stack is considered to be part of the local logical interface. The entire protocol stack and the physical parts of the interface can be used by local connections.
Local Logical Interfaces also include the local hardware interfaces and the Local Maintenance Terminal interface (LMT) of the GNP used for its maintenance through a console.
This means that for both, local and remote logical interfaces, the GNP model does not only cover the application layer protocol, for which a GNP function terminates the interface (e.g. S5), but also the protocols (e.g. SCTP, IP, Ethernet, USB) in the protocol stack below the application layer protocol.
There are some major differences between local and remote interfaces from security perspective. For example attaching to a local interface may cause execution of complex internal procedures in the GNP like loading USB device drivers, enumeration of attached devices, mounting file systems etc.
A GNP hosts the following interfaces:
Remote logical interfaces:
  • Service interfaces that are defined in pertinent 3GPP specifications
  • Service interfaces that are not defined by 3GPP
  • Remote OAM interface
  • EMS (Element Management System) interface
Local logical interfaces:
  • OAM local console
  • LMT (Local Maintenance Terminal) interface
  • GNP local hardware interfaces
Up

4.4  Scope of the present documentp. 15

4.4.1  Introductionp. 15

The present subclause refers to the GNP model in clause 4.3.

4.4.2  Scope regarding GNP functions defined by 3GPPp. 16

The set of GNP functions actually implemented in an GNP is to be described in the annex of the present document. But the GNP SCAS needs to explicitly address all GNP functions that, if present in an GNP network product, need to be evaluated and hence covered by requirements in the GNP SCAS. Furthermore, it is to be avoided that a particular version of an GNP SCAS becomes a moving target. This leads to the following note:
Up

4.4.3  Scope regarding other functionsp. 16

At least the following functions not defined by 3GPP are in scope of the GNP SCAS:
  • Remote management functions
  • Local management functions

4.4.4  Scope regarding Operating System (OS)p. 16

The GNP SCAS does not attempt a full evaluation of the correct internal functioning of the OS. However, interfaces (I.e. the restriction on open ports and unnecessary services running in the system) and modifications (e.g. verification of the correct applied patch level, hardening, etc.) of the OS are in scope.

4.4.5  Scope regarding hardwarep. 16

The GNP SCAS does not attempt a full evaluation of the correct internal functioning of the hardware platform. However, interfaces that are implemented in hardware (e.g. USB port) and modifications of the hardware are in scope.

4.4.6  Scope regarding interfacesp. 16

The interfaces listed in clause 4.3.6 are all in scope of the present document.

Up   Top   ToC