Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TR 33.916  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   7…   A…

 

5  Security Assurance Specification (SCAS) Creationp. 16

5.1  Writing process overviewp. 16

An SCAS document will be defined for a specific network product class within the normative phase. On a high level, the process of writing SCAS documents for a given network product class follows these steps:
  • Describe and model the network product class
    The network product class is described and modelled to a sufficiently detailed level so as to ensure that the security requirements can clearly describe what data and functions are intended to be protected and which functionalities are required. This modelling will be used as an input document for the following Security Problem Definition.
  • Define the security problem
    By identifying which assets in the model of the network product class require protection and how these assets can be exploited by an attacker. The security problem definition also contains the security objectives of the network product class under analysis (i.e. which assets require what type of protection), and defines an attacker potential the network product class is supposed to resist. This step also contains the threat analysis employed to understand how an attacker performing the identified potential attacks may misuse the identified assets of the network product class. This provides a concrete security problem that is to be solved, which allows the selection of security requirements that are necessary and sufficient to solve the identified security problem. This material will be contained in a 3GPP Technical Report of the 900-series.
  • Identify the security requirements and test cases
    Security requirements are derived from the security problem definition. The fulfilment of these requirements ensures that the security objectives can be reached. Catalogues of security requirements and security requirement categories that have been used by operators in practice will be used as a starting point to help 3GPP in writing complete requirements.
    These requirements can and will be modified and adapted as seen necessary by 3GPP.
    In addition, if requirements, or terminology used to specify the requirements, are not clear or consistent there is an increased risk of different understanding of the requirements and this may unnecessarily result in heavy use of the dispute resolution process. For example if a requirement applies on the "management traffic", a clear definition on what the "management traffic" consist of would be needed. This could be in particular a difficulty for tests that consist of verifying whether a requirement is fulfilled by examining documentation and making a decision on whether the designed mechanism or used process fulfils the requirement; such tests are a judgment call and can be called differently by different parties.
    The consistency of the requirements format is ensured by the template for a security requirement described in clause 5.2.3.3.
    For each security requirement 3GPP will define a test case.
  • Verify the Security Requirements
    Once the security requirements have been identified it is verified that the security objectives are met by these security requirements, and that every security requirement contributes to defending an identified security objective. If any mismatch is found (e.g. security objective not covered with the existing security requirements or security requirements which do not resolve any security objectives), the list of security requirements is updated accordingly by removing or adding security requirements.
Up

5.2  SCAS documents structure and contentp. 17

5.2.1  Generalp. 17

According to clause 5.1, the SCAS documents contain three parts, a Network Product Class Description, a Security Problem Definition and the Security Requirements (including the test cases) for any specific Network Product Class (see clause 3.1), to counteract the risks outlined by the threat analysis. Consequently SCAS documents contain the following parts:
  • Network Product Class Description (NPCD): This clause includes the description of the network product class, e.g. the physical and logical interfaces the product class supports to interact with external entities and the major functionalities of the NPC. This material will be contained in a 3GPP Technical Report of the 900-series.
  • Security Problem Definition (SPD): This clause defines the security problem that is to be addressed and the security objectives of the network product class. This material will be contained in one or more 3GPP Technical Reports of the 900-series.
  • Security Requirements (SR): This clause defines the security requirements, which may include hardening requirements, selected according to the Security Problem Definition and the requirements strictly related to the 3GPP features implemented by the network product class under analysis. Requirements and test cases will be contained in one or more 3GPP Technical Specifications.
In the following a detailed description of the SCAS parts SPD and SR is provided.
Up

5.2.2  Security Problem Definition (SPD)p. 17

5.2.2.1  Introductionp. 17

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.
Up

5.2.2.2  Threatsp. 18

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.
Up

5.2.2.3  Security Objectivesp. 19

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.
Up

5.2.3  Security Requirementsp. 19

5.2.3.1  Introductionp. 19

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).
Copy of original 3GPP image for 3GPP TS 33.916, Fig. 5.2.3.1-1: Process for deriving security requirements in a SCAS document
Up
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).
Up
5.2.3.1.1  Level of detail of security requirementsp. 21
Security requirements can be specified in different levels of detail, with a tradeoff between precision of the requirement and its general applicability.
Detail Level 1:
Security requirements of general system-independent nature: What needs to be secured?
Example: data storage in general
Detail Level 2:
Security requirements that are system-specific but still product-independent: What needs to be secured, for this system type?
Example: data storage in databases
Detail Level 3:
Product-specific security requirements: How does this specific product need to be secured?
Example: data storage in an Oracle database Vx.y
In order to ensure consistency between all requirements in a SCAS, every requirement of detail level 2 or 3 should be derived from a generic level 1 requirement or security objective.
In general, requirements on detail level 3 should be avoided in a SCAS because that would limit direct applicability of a SCAS for some network products.
Up

5.2.3.2  Incorporation of security requirements from existing 3GPP TSs in current releasesp. 21

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.
Up

5.2.3.3  Handling of security requirementsp. 22

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:
Template for a Security Requirement Description
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.
Example of an "hardening type" security requirement:
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.
Up

5.2.3.4  Guidelines for writing test casesp. 24

5.2.3.4.1  Generalp. 24
Requirements are to be testable. That is, they are to be specific enough so that a test can be written that effectively decides whether the requirement is fulfilled or not.
Some general guidelines for writing test cases are:
The test case should describe what the aim of the test is and what it is trying to demonstrate. It is not necessary to describe in details what needs to be done and what equipment is to be used. It should be left up to the lab to determine what are suitable tools and methods but it should also be specified what is suitable on high-level in order to ensure that the lab is using the right type of tools.
The test case is to match the requirement and is not allowed to extend the requirement. It is allowed that a test case may test only a subset of what is covered by the requirement as exhaustive testing may be impossible in certain cases.
Duplications should be avoided, e.g. it should be allowed to refer from one test case to (a part of) another test case already covering (part of) the requirement or to state in one test case that another test case should be run successfully before.
It should be possible to execute a test case efficiently and automation is to be preferred over manual work.
Test cases should be applicable to all elements in one or more network product classes and not assume implementation-specific details, e.g. on operating systems, that are not present in the requirement. But examples for specific environments, e.g. specific operating systems, are allowed.
The network product as defined in the present TR shall be the object on which test cases are executed. This means, in particular, that no assumptions on installing additional software, e.g. a network sniffer, on the network product are to be made.
In general, configuration changes (e.g. creating additional accounts) are to be avoided unless they are needed for the purpose of the test. But when modification of the network product is a necessary precondition for testing the requirement (e.g. when the requirement asks for configurability of the product such as in a password policy) configuration changes are allowed.
Up
5.2.3.4.2  Verifiability and repeatabilityp. 24
Tests are verifiable. That is, after the test is executed there cannot be any doubt whether the test passed or failed. If there is doubt, it is a matter of opinion whether the test passed or failed which may result in unnecessary disputes. One of the purposes of the tests in SECAM is to remove opinion based verdicts of test outcome.
The detail level of a test case corresponds to the detail level of its associated requirement (see clause 5.2.3.1.1). In order to be repeatable, every test case performed with a network product needs to be described on detail level 3, i.e. specific for every individual network product. This means that the test laboratory needs to define and document test cases on detail level 3 for the security requirements on detail level 1 and 2 in the SCAS. This documentation needs to be included in the evaluation report.
Tests are repeatable when based on this documentation of test cases on detail level 3. That is, given this documentation, the network product and the corresponding SCAS, a third party should be able to repeat the tests and verify whether the network product passes or fails the test.
For a test to be verifiable, it needs to clearly specify the starting state of the system, pre-requisites for the tester, what actions are taken by the tester, and what the expected results are. The actions taken by the tester are sufficiently detailed to enable someone else to repeat the test. The expected outcome are sufficiently detailed to unambiguously determine whether the test passed or failed.
There is no need to deeply formalize how the tests are written in SECAM, but the three identified pieces of information need to be present, and they need to be clear and unambiguous:
  • The initial state of the network product and pre-requisites for the tester.
  • The steps taken to perform the test.
  • The expected results of a successful test.
Specifying the tests clearly also helps in formulating clear requirements.
Up
5.2.3.4.3  System under testp. 25
The SCAS applies to a network product class. In particular, the security requirements in the SCAS apply to the network product class. It is therefore important that the tests that verify whether a security requirement is met by a network product or not are mapped to the specific network product. More precisely, the expected results of the test show that the network product is acting as expected. The expected results cannot describe behavior of other network entities or personnel in the environment of the network product.
Up
5.2.3.4.4  Template to be used for writing the test casesp. 25
Table 5.2.3.4.4-1 describes the template to be used while writing the test cases identified for each security requirement.
Test Name:
To each test case is assigned a unique name, indicating the covered topic.
Purpose:
In this section the goal of the test (i.e. what it is intended for) should be reported
Procedure and execution steps:
In this section the pre-conditions and the operational steps to perform the test should be reported.
Expected Results:
In this section the expected result should be reported (i.e. the behaviour expected for the referenced requirement).
Expected format of evidence:
In this section the expected format of the evidence should be reported. If not applicable for a specific test, then NA should be used.
Up

5.3  Improvement of SCAS and new security requirementsp. 25

Vendors, operators or other bodies can propose new security requirements for addition to 3GPP SCASs if a new threat or vulnerability has been identified. This gives 3GPP the flexibility to continuously review and improve their SCASs .

Up   Top   ToC