Security of Network Products should be measurable, comparable, and follow a common standardised baseline. This allows mobile network operators to determine the achieved level of security of network products. 3GPP addresses this by introducing SECAM. SECAM covers:

• creation of security requirements and test specifications - the so-called Security Assurance Specifications (SCAS) - (see clause 4.1) and
• security evaluation of Network Products and evaluation of vendor network product development and network product lifecycle management processes compliance (see clauses 4.2, 4.4, and 4.5).

SECAM is defined in this document. For trustworthiness of evaluation results and credibility of the entire initiative, security-relevant parts of the vendor network product development and network product lifecycle management processes and the test laboratories should be accredited (see clause 4.2). Accreditation by an external party demonstrates that the actor has the capabilities, skills, and competence to perform their respective tasks. The SECAM Accreditation Body - currently only the GSM Association (GSMA) - covers accreditation and its governance and maintenance and by that complements this 3GPP activity. The SECAM Accreditation Body defines requirements and processes for:

• vendor network product development and network product lifecycle management processes accreditation [9],
• test laboratory (vendor owned or third party) accreditation [8],
• dispute resolution [7].
• vendor development and lifecycle security requirements [10].

The activities of the GSMA are combined in a single scheme, the Network Equipment Security Assurance Scheme (NESAS). It is currently being specified in various documents. They are publicly available on the Internet. An overview is provided in the NESAS Overview document [7].

A 3GPP Network Product can have vulnerabilities which, if exploited, can damage the MNO and/or end-users. In order to understand the potential attack vectors which could be used, the first thing to do is to identify the targets of the analysis. 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. All these features can expose the 3GPP network product to several potential security attacks. If the network product is securely implemented, managed and configured then some of these attacks can be prevented. The above mentioned security attacks can exploit different 3GPP network product features/ capabilities. The Security Assurance Specification (SCAS) for a given network product class provides a description of the security requirements and associated test cases pertaining to that network product class. It is assumed that the latest version of the 3GPP Security Assurance documents available at the beginning of a particular instance of an evaluation will be used for 3GPP Security Assurance whatever the 3GPP Release compliance of the other 3GPP functions of the product is. Evaluations performed in the past remain valid, however, even when a new version of the 3GPP Security Assurance documents is published. As pre-requisite for writing a SCAS, 3GPP defines a complete list of features/capabilities considered to be part of the Network Product Class. In order to achieve the security assured by a SCAS, the network operator needs to ensure that deployment fulfils the environmental assumptions given in the SCAS. The overall process therefore contains the following steps:

1. 3GPP writes SCAS, which may contain environmental assumptions
2. Accredited security test laboratories (vendors or third party) evaluate network product according to SCAS, but only the single product in a vendor-documented configuration for SECAM testing, without any considerations on the system or network or environment in a specific deployment. Here SECAM stops.
3. when the evaluated network product is being deployed, the operator goes back to the environmental assumptions from the SCAS and tests whether they are fulfilled. This validation of environmental assumptions can only be performed during deployment and is needed for security, but is not part of SECAM, because SECAM is about product-testing.

A SECAM evaluation comprises the Vendor Network Product Development process evaluation, the product lifecycle management process evaluation and the Network Product evaluation The SECAM evaluation will cover the following tasks:

• Vendor network product development and network product lifecycle management process assurance compliance (assessing if the method used to develop the products is compliant with the Vendor network product development and network product lifecycle management process assurance requirements). Details of this activity can be found in clause 7 and the documents defined by the SECAM Accreditation Body.
• Security Compliance Testing (assessing if requested security requirements are correctly implemented in a network product). This includes Basic Vulnerability Testing (running of a set of FOSS/COTS tools on external interfaces of the Network product).

The actor performing a task should be accredited by the SECAM Accreditation Body for this specific task.

Consequently, according to Table 4.3-1, SECAM can take different forms, depending on who performs security compliance testing and who performs Basic Vulnerability Testing. SECAM is intended to enable self-evaluation where the vendors evaluate their network products if they have the proper accreditation for that. The responsibility for writing and managing the accreditation and monitoring rules is taken by a SECAM Accreditation Body. The SECAM Accreditation Body's role also includes the handling of the dispute resolution process. GSMA takes this role and will provide a clear delineation between SECAM work in 3GPP and in GSMA. Even if it describes the complete process, including evaluation by accredited actors under SECAM Accreditation Body control and Security Assurance Specifications (SCAS) writing, SECAM does not preclude 3GPP SCAS security requirements and tests cases being used directly by mutual consent between vendors and operators without the accreditation process in place if it so desires. This ensures that the 3GPP SECAM work is not held up by delays in deliverables under the responsibility of external bodies, or by conflicting requirements in different countries (e.g. relating to accreditation). The presence of a SECAM Accreditation Body as defined above is highly desirable in order to ensure a wide recognition of evaluation results and to have a working dispute resolution process available. Having a SECAM Accreditation Body also avoids the need for each operator to set up a one to one trust relationship with every vendor regarding their testing methods and skills. Validity of accreditation is defined by the SECAM Accreditation Body.

The ultimate output of the SECAM evaluation is:

• an evaluation report demonstrating compliance of the network product with the 3GPP security assurance specifications;
• evidence to demonstrate to the test laboratory that the accredited vendor product and development lifecycle processes have been complied with for the network product;
• evidence that the actors performing the evaluation tasks are accredited by the SECAM Accreditation Body.Such evidence is not required if there is consent between operator and vendor to not use the accreditation process, see clause 4.3.

The operator examines the evaluation reports and the evidence that the actors performing the evaluation tasks are accredited by the SECAM Accreditation Body.

The security assurance process describes how the operator gets assurance regarding the security of the network product. The process is depicted in Figure 4.5-1. If there are any regulatory requirements on security assurance of the network product, they will for the purpose of this process model be considered being included in the acceptance requirements of the operator. When a vendor is ready to provide security assurance w.r.t. a given network product, the vendor obtains one or more Security Assurance Specifications (SCASs) that the network product is aiming to fulfil. Choice of which SCASs to select may depend on operator and/or regulatory input. Then the product is evaluated against the Security Assurance Specification(s). The evaluation results in an evaluation report. Once the operator received the evaluation report, the operator then decides if the results are sufficient according to its internal policies and whether to accept the security assurance level of the network product or not. The operator's acceptance decision may depend on external forces such as regulatory requirements.

Certification of network products is out of scope for SECAM. However, SECAM does not preclude certification activities for network products which would e.g. complement the Self-declaration step (cf. clause 7.3). The SECAM security assurance process is described in depth in clause 7.

The operator examines the network product, the security compliance testing, including the basic vulnerability testing analysis reports, the self-declaration as well as the optional evidence of accreditation from the SECAM Accreditation Body for the actors performing the evaluation task and decides if the results are sufficient according to its internal policies. In particular, the operator can perform a sample of the security compliance testing and basic vulnerability testing, based on the delivered test procedures. The vendors and third-party laboratories accreditation documents monitored and maintained by the SECAM Accreditation Body attest the trustworthiness of these actors and can help operators in their security acceptance decisions. The operator does not need to be accredited to perform again the tests made by the test laboratories in order to gain a higher level of assurance that the SECAM evaluation provided trustable results. Definition of the tools and methods for these supplementary evaluations is outside of the scope of SECAM and left as operators' proprietary procedures. However, in case of disagreement on the test results and if the operator wants to enter a conflict resolution process with the SECAM Accreditation Body and the vendor, some forms of recognition of the validity of the operator's complaint might be useful. This description will be part of the description of the complete dispute resolution process. It is left to the SECAM Accreditation Body and is outside the scope of 3GPP.

Assurance level is related to evaluation effort in terms of:

• scope - that is, the effort is greater when a larger portion of the IT product is evaluated; For example, when supplementary aspects of the functionality are included in the evaluation;
• depth - that is, the effort is greater when evaluation is deployed to a finer level of design and implementation detail;
• rigour - that is, the effort is greater when evaluation is applied in a more structured, formal manner.
  For example, for a given security requirement to test, the effort is greater if the test laboratory is requested to provide a formal demonstration that the product will always behave as intended versus providing a given set of output test data for a limited set of test cases.

In SECAM:

• Scope is constant: SECAM provides a single process for a given network product class, which will be relevant to this class.
• Depth of evaluation is also considered to be constant. The paradigm of SECAM consists in:
  • Security compliance testing: the paradigm would consist in black box verification of security requirements, but exceptions would be possible, e.g.:
    • when required in order to demonstrate compliance for requirements on cryptography, key storage, secure deletion, or implementation of protocols, etc. (in such cases, code inspection would be more efficient than a functional test);
    • when a white/grey box approach is considered more efficient (a black box vulnerability scan over the network would take longer and reveal less than a white box local system analysis).
  • Vulnerability testing: the general paradigm of vulnerability testing would be consistent with the expected attacker model. Such testing will consequently be based on black box vulnerability testing unless the expected attacker is considered having a higher potential. In the latter case, white/grey box penetration testing would be necessary to assess the resistance of the network product. For example, if an attacker were believed to have knowledge of the implementation of the network product, a black box assessment only would be unreasonable.
  • Build process assurance: Verification of build process is limited to basic functional documentation, use of a configuration system and providing of operational guidance.
• Rigour of verification is also considered constant, since it focuses on demonstration for functional testing and vulnerability assessment, justification when necessary, and does not require formal demonstration.

Considering that the three parameters are expected to be constant and the above mentioned additional complexity of having several assurance levels, SECAM considers only one assurance level per network product class. However it is expected that different product class are confronted by different attacker models, and have consequently to undergo different levels of rigour or depth of evaluation.

The security baseline of an evaluated network product is a set of security requirements and environmental assumptions defining its capacity to resist a given attack potential. This resistance to a given attack potential relies on:

• Attacker model and attacker potential agreed to be relevant for a given network product class.
• The completeness and correct implementation of security requirements and operational environment assumptions which limit the capacity of this attacker to threaten given assets:
  • Security requirements can be more demanding in some network elements, e.g. exposed nodes will have to implement hardening requirements which will not necessarily be needed in elements less exposed.
  • Vulnerability assessment will be performed with more depth whenever the element is expected to resist a stronger attacker.

It is necessary to state in a well-defined way in which environment the 3GPP-defined functionality is assumed to be operating and what types of attackers (if any) may be able to launch attacks from the outside as well as from the inside of this environment. This assessment is accomplished during the SCAS writing phase and related to the threat and risk analysis outcomes. At the end of this process, for each network product class, 3GPP will have precisely defined the attacker model as well as the operational environment assumption and the security requirements to mitigate the identified risks. The modularity of SCAS allows an easy composition of SCAS modules to describe all the countermeasures of a given network product class and to take the particular environment of the node into account. The entire set of security requirements, operational environment assumptions and attacker model is built to achieve a security baseline deemed relevant by 3GPP for a network product class. This results in one security level per network product class (security baseline MME, security baseline HSS, security baseline eNodeB, etc.). These baselines are not meant to be compared to one another as they apply to different network product classes.