For the Security Problem Definition (SPD) part of the SCAS writing phase, the steps to be accomplished by 3GPP for a given network product class are:

• List the critical assets of the network product class.
• List the assumptions on the Operational Environment
• Identify the attacker model for the Network Product Class.
• Identify threats, i.e. adverse actions than can be performed on assets.
• Identify the threat relevance (Mitigate, Accept, and Transfer).
• Identify the level (probability and impact) of risk associated with the threats and assess a risk by comparing the risk level with the cost for mitigation.
• Identify the list of the security objectives necessary to face the identified threats and reduce the risk surface.

For features that are standardized in 3GPP specifications some threat analyses are available from e.g. TR 33.821 for EPS or other publications. In particular, threat analyses related to the security requirements in 3GPP TSs to be re-used in SCAS, see clause 5.2.3.2, need not be repeated in SCAS. These were however written before e.g. current SCAS type of work objectives came to light.

• Threat descriptions should avoid including security objectives or requirements or countermeasure implementation details.
• Check if there is an existing threat in a 3GPP TR of the 900-series before attempting to create a new one. For example a variant of an existing threat could be created.
• Attempt to map the threat to one of the existing threat categories before creating a new threat category.
• Details in the threat description should indicate if the threat is a high level threat (refers to several attack components) or a detailed threat (refers to a specific attack component).
• Attempt to map the threat to one of the existing security objectives before creating a new security objective.
• All requirements should map to one or more threats.
• All requirements should map to one or more security objectives.
• It should be clear from the text in the requirement description field that the requirement is a detailed specific requirement (which has its own test case(s)) or is a high level requirement (e.g. conformance to industry best practices) which has multiple test cases.
• A new threat, threat category, or security objective should be included only after 3GPP determined that sufficient rationale was provided.

There are many threat and risks analysis or modelling frameworks available for IT equipment and computers networks. None of them provided a perfect fit for the needs of SECAM whose ultimate goal is to be capable to derive concrete and testable security requirements to reduce the level of exposure of telecom equipment. This process is likely to be iterative and there will be some trade-off in terms of time. It is not a goal to be absolutely complete in the threats assessment. What ultimately matters in the threat analysis phase is that 3GPP determines that the achieved level of details is good enough to be able to easily derive testable security requirements to cover the risks in a reasonable amount of time. The structure for a threat description is provided here to indicate the information needed for having a clear security problem definition. This can help to facilitate the identification of the security requirements. Hereafter a possible structure for the threats, risks and security objectives which are part of the SPD is reported. This structure will be related to the threat modelling framework used for the analysis and consequently this proposal could be changed accordingly:

• Threat Name: each threat is assigned a unique name. The name preferably indicates the topics covered by the threat.
• Threat Reference: a unique short form is assigned to each threat as a primary means for referencing the threat. The convention adopted is: <threat category> - <progressive number> where the convention adopted for the "threat category" can be the first two letters of the category to which the threat belongs or similar.
• Threat Category: a reference to the category to which the threat belong based on the classification (threat methodology) that will be adopted.
• Threatened Asset: an indication of the network product assets that are object of the threat.
• Threat Description: the adverse actions that can be performed by a threat agent on an asset. These actions influence one or more properties of the asset from which that asset derives its value. Examples of threat agents are hackers, users, computer processes, and accidents. Threat agents, and their level, may be further described by aspects such as expertise, resources, opportunity and motivation. To provide a basis for requirements that are on roughly the same level, 3GPP chooses a level of threat agents that the system should be able to withstand (although the levels may be hard to quantify or measure). Protection mechanisms or requirements then are not selected if a threat can be instantiated only by a threat agent of higher level. This is in line with the single assurance level and single security baseline per network product class of clause 4.
• Threat relevance: the threat relevance (Mitigate, Accept, and Transfer).

Further details are given in TS 33.926.

The Security Objectives countering the defined threats are likely to overlap in many cases. Therefore, they are to be listed in a separate section of the SCAS document to aggregate references to the threats they counter. The structure for Security Objective is as follows:

• Security Objective Reference: a unique short form is assigned to each Security Objective as a primary means for referencing. The convention adopted is: SO - <progressive number>
• Security Objective: the concise and abstract statement as given for the threats.
• Threat References: List of Threat References of the threats countered by the Security Objective in question.

Additionally, a table matching the Threats and Security Objectives should be given in an annex TR 33.926.

3GPP will have to list the countermeasures deemed relevant to mitigate the risks identified in the threat assessment. These countermeasures will take the form of either:

• security requirements on the network product with associated test cases; or
• operational environment security assumptions for a given product class.

The Security Requirements clauses within the the pertinent 3GPP TS contain the security requirements identified according to the threats (see Figure 5.2.3.1-1).

The security requirements will include security functional requirements as well as hardening requirements and basic vulnerability testing requirements. The security functional requirements are ensuring the existence of security functionalities in the network products in order to achieve security objectives (e.g. 3GPP functional requirements). The hardening requirements are either ensuring the absence of unneeded or insecure functionality, or impose a restriction on a function forcing it to behave in a more secure way. The basic vulnerability testing requirements specify the areas to be subjected to basic vulnerability testing. The purpose of hardening is to reduce the attack surface and security vulnerability of the network product and to ensure that security functions of the network product cannot be bypassed. SECAM will specify hardening requirements that should be part of the evaluation. Those requirements are only intended to reduce the attack surface rather than directly related to a security function. All security requirements, those related to a specific security function as well as those related to the reduction of the attack surface and basic vulnerability testing requirements, will be treated on the same footing and the text of clause 5.2.3.3 applies to all "types" of requirements. Their evaluation will be based on the tests cases of the SCAS. In any case, hardening requirements imply that they are implemented before evaluation through test cases. Hardening requirements should be formulated generic enough, or in different variants, to be applicable for a variety of anticipated operating systems and applications. Hardening is needed to let network products achieve the given security baseline and assurance level, alongside with other security requirements. Hardening can be the removal of services, protocols, ports, etc. in order to reduce known security vulnerabilities and minimize the risk in an existing but unneeded functionality. An example of hardening is to remove unnecessary services of general purpose software used in a specific context. It can also be a physical action like removing unneeded USB ports. An example of such a requirement is provided at the end of clause 5.2.3.3. SECAM security requirements represent the common agreement of operators and vendors on what has to be implemented for a given network product class to achieve the required security baseline. All those requirements (including operator's initialization and configuration requirements which have been channelled through the relevant SECAM standardization processes) have to be taken into account from the beginning of the development and design phase of the network product as well as in subsequent updates of the network product. This will ensure that network products will be developed in a way that:

1. Maximizes their likelihood to pass SECAM evaluation.
2. They operate correctly and securely when deployed in operator's networks.
3. Avoids costly patching cycle to ensure a) and b).

In Figure 5.2.3.1-1, 3GPP specifications represent an input for both SPD and security requirements definition, where the latter includes test case definition. The reason for this assumption is that 3GPP security specifications (e.g. TS 33.401) already contain several security objectives and related security functional requirements which 3GPP identified when designing UMTS and LTE. When looking at such type of security functional requirements, they can be grouped into three categories:

1. Security functional requirements related to protocols and behaviours necessary for secure interoperability between nodes from different vendors that require a certain positive behaviour of a 3GPP function.
   For example, the security functional requirement "the MME sends to the USIM via ME the random challenge RAND and an authentication token AUTN for network authentication from the selected authentication vector." retrieved from TS 33.401, belongs to this category.
2. Security functional requirements related to protocols and behaviours necessary for secure interoperability between nodes from different vendors that require that a 3GPP function does not perform a certain action.
   For example, the security functional requirement "Access to E-UTRAN with a 2G SIM or a SIM application on a UICC shall not be granted" retrieved from TS 33.401 belongs to this category.
3. Security functional requirements not related to protocols or behaviours necessary for secure interoperability between nodes from different vendors, but rather dealing with security features which are supported by the network products and consequently strictly related to their implementation.

For example, the security functional requirements specified in clause 5.3 of TS 33.401 for eNBs and in Annex I of TS 33.102 for RNCs in exposed locations belong to this category. The security functional requirements in the first group are already covered by the interoperability and conformance testing and SECAM documents do not repeat these requirements or add tests for them. The security functional requirements in the second category may not be covered by the interoperability and conformance testing. In this case a SCAS document may contain a reference to these requirements with the related test cases which verify that the network products adhere to the security functional requirements. As an example, security functional requirements for the MME in the second category are collected in TS 33.116. The security functional requirements in the third category are within the scope of SECAM and they will be taken into account by the security requirements for the compliance testing. However, for some network product classes, e.g. the MME, there are no requirements in the third category. A security compliance requirement in a SCAS that references a 3GPP TS refers to the corresponding TS security functional requirement and also contains a test description how to verify the correct implementation of the described security functional requirements. SECAM does not provide stand-alone security assurance requirements. Instead, SECAM provides a test case for every security requirement.

A SECAM Catalogue of General Security Assurance Requirements and associated test cases is provided because several network product classes will share very similar if not identical security requirements for some aspects. This catalogue therefore allows to maximize the reuse of already written requirements. This approach matches the requirement that a SCAS will have to be developed in a modular fashion such that an individual module is generic enough to be applied to more than one network product class. This approach can help to prevent from writing the same security requirements from scratch several times in different network product class SCAS (see clause 4 of the present document). It is important to underline that the 3GPP catalogue is constructed while working on SCASs for specific network product classes, and the intention is not to first create the catalogue in an abstract way and then write the first SCAS based on it. No requirements is included in the catalogue before it has been found useful for a specific network product class. This prevents the catalogue from accumulating "good-to-have" requirements that are never used by specific network product classes. Consequently, the way to build the proposed catalogue is an iterative process that counts the following steps:

1. Start the normative phase for a specific Network Product Class (e.g. MME).
2. Select from the identified sources the proper security requirements that meet the needs of the security objectives and adapt them to SECAM.
3. Add this adapted requirements in the SECAM catalogue in order to reuse if possible during the normative phase of other Network Product Classes.
4. Start the normative phase of another Network Product Class (e.g. eNB) and refer to the security requirements already available in the SECAM catalogue if possible otherwise select the new ones from the agreed sources and update the Catalogue.

Security requirements are expected to follow a template similar to the one described hereafter: Statements of security requirements are intended to be clear, concise and unambiguous. In particular, each security requirement includes:

• Requirement name: each security requirement is assigned a unique name. The name indicates the topics covered by the requirement:
• Requirement reference: a unique short form of the security requirement is provided as a primary means for referencing the class. The convention adopted is: < requirement class reference> - <the first two letter of requirement name> or similar convention.
• Requirement Description: a detailed description for the security requirements identified by 3GPP to reduce/counteract the risks outlined by the threat analysis.
• Security Objective references: a list of the short identifiers assigned to the Security Objectives achieved through fulfilling this requirement.
• Test case: a description of the test case that defines how the requirement is tested, the expected skills and tools to be used to produce the test outputs.

Hardening requirements can also help to make the software/hardware of a network product more robust against un-authorized remote or physical access and can be tested as shown in the following example:

• Requirement name: Unauthenticated services binding:
  • Requirement reference: HARDENING_BINDING.1.1.
  • Requirement Description: No unauthenticated services shall be bound to physically accessible ports of the network product. Unauthenticated service running on the network product and bound to physically accessible ports, even if not security related, can be used by an attacker to gain connectivity on the network product. The attacker could then try to escalate their privileges to further compromise the network product. No unauthenticated service shall be bound to physically accessible ports.
  • Security Objective references or more general level requirement: SO-1, SO-2, SO-3.
  • Test case:
    • Review the documentation provided by the vendor describing the physically accessible ports and the services bound to them.
    • Document in the report the services listening on each physically accessible port and the type of credential required for access.
    • Connect to all documented services and check that authentication is required.
    • Connect on each physically accessible port and run an appropriate scan to detect listening services on all relevant OSI layers and check whether non documented services are listening and accessible.
      or where remote scanning results are not meaningful like e.g. in case of UDP, use appropriate in-host tools to verify that only documented services are listening and accessible on the physically accessible port.

Applicability of a hardening requirement may depend on the OS or application running on the network product. E.g. in case the hardening requires removal of all non-public-key based authentication:

• Vendor A has implemented this by running the COTS component OpenSSH. Hardening for this authentication function includes e.g. disabling password based login.
• Vendor B implements this by a proprietary protocol with public and private keys, i.e. a non-COTS component. Hardening for this authentication function includes e.g. ensuring that password based authentication is not implemented or disabled.

What ultimately matters for the SECAM evaluation (compliance and vulnerability) is that the network products fulfil the security requirement (functional and hardening) and pass the related test cases, not what method was applied by the vendor to do so.