Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.117  Word version:  17.2.0

Top   Top   Up   Prev   Next
1…   4.2…   4.2.3…   4.2.3.4…   4.2.3.5…   4.2.4…   4.3…   4.3.4…   4.4…

 

4.2.3  Technical baselinep. 17

4.2.3.1  Introductionp. 17

The technical baseline is a generic set of security requirements to be fulfilled by all network products.
In particular these requirements counter the security threats and objectives identified in the TR 33.926 and they basically aim to guarantee the network product confidentiality, integrity and availability.

4.2.3.2  Protecting data and informationp. 17

4.2.3.2.1  Protecting data and information - generalp. 17
Adequate security measures for protecting sensitive data shall be implemented as defined in the present document. Further measures (that are beyond the scope of the present document) may be required by local regulation depending on the classification of the data and other factors such as type of network used during transmission, storage location for data, etc.
4.2.3.2.2  Protecting data and information - Confidential System Internal Datap. 17
Requirement Name:
Unauthorized Viewing
Requirement Description:
When the system is not under maintenance, there shall be no system function that reveals confidential system internal data in the clear to users and administrators. Such functions could be, for example, local or remote OAM CLI or GUI, logging messages, alarms, configuration file exports etc. Confidential system internal data contains authentication data (i.e. PINs, cryptographic keys, passwords, cookies) as well as system internal data that is not required for systems administration and could be of advantage to attackers (i.e. stack traces in error messages).
Security Objective references:
tba.
Test case:
Test Name:
TC_CONFIDENTIAL_SYSTEM_INTERNAL_DATA
Purpose:
Verify that no system function reveals sensitive data in the clear
Procedure and execution steps:
Pre-Condition:
The vendor shall provide documentation describing how confidential system internal information that could possibly be revealed in clear-text is handled by system functions.
A list of all system functions in the network product, information on how to enable and execute them should be provided as a part of the vendor's documentation. A system function is every function implemented in the network product needed by the services/functionalities provided by the network product itself.
Execution Steps:
Execute the following steps:
  1. Review the documentation provided by the vendor describing how confidential system internal information is handled by system functions.
  2. The tester checks whether any system functions as described in the product documentation (e.g. local or remote OAM CLI or GUI, logging messages, alarms, error messages, configuration file exports, stack traces) reveal any confidential system internal data in the clear (for example, passphrases).
Expected Results:
There should be no confidential system internal data revealed in the clear by any system function.
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot containing the operational results.
Up
4.2.3.2.3  Protecting data and information in storagep. 18
Requirement Name:
Protecting data and information in storage
Requirement Description:
For sensitive data in (persistent or temporary) storage read access rights shall be restricted. Files of a system that are needed for the functionality shall be protected against manipulation.
In addition, the following rules apply for:
  • Systems that need access to identification and authentication data in the clear, e.g. in order to perform an authentication. Such systems shall not store this data in the clear, but scramble or encrypt it by implementation-specific means.
  • Systems that do not need access to sensitive data (e.g. user passwords) in the clear. Such systems shall hash this sensitive data .
  • Stored files on the network product: examples for protection against manipulation are the use of checksum or cryptographic methods.
Security Objective references:
tba
Test case:
Test Name:
TC_PSW_STOR_SUPPORT
Purpose:
Verify that Password storage use one-way hash algorithm.
Procedure and execution steps:
Pre-Conditions:
  • The tester can access the storage of own user account password.
  • The tester has privileges to change the password.
  • The original password is P1.
Execution Steps:
  1. The tester accesses the storage where the result of P1 is, and the corresponding hash value is recorded as A
  2. The tester changes the password with P2, then the tester records the storage hash value of the new password as B
  3. The tester repeats the step 2 to get other records.
  4. The tester verifies whether all the records comply with the characteristic of one-way hash result.
Expected Results:
All records comply with the characteristic of one-way hash result.
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot containing the operation results.
Up
4.2.3.2.4  Protecting data and information in transferp. 19
Requirement Name:
tba
Requirement Description:
  • Usage of cryptographically protected network protocols is required.
  • The transmission of data with a need of protection shall use industry standard network protocols with sufficient security measures and industry accepted algorithms. In particular, a protocol version without known vulnerabilities or a secure alternative shall be used.
Security Objective references:
tba
Test case:
Test Name:
TC_PROTECT_DATA_INFO_TRANSFER_1
Purpose:
Verify the mechanisms implemented to protect data and information in transfer to and from the Network Product's OAM interface.
Procedure and execution steps:
Pre-Conditions:
Network product documentation containing information about supported OAM protocols is provided by the vendor,
A peer implementing the security protocol configured by the vendor (e.g SSH client supporting SSHv2 or HTTPS client) shall be available.
Network product documentation stating which security protocols for protection of data in transit are implemented and which profiles in TS 33.310 and TS 33.210 are applicable is provided by the vendor
For TLS/DTLS, the tester shall base the tests on the profile defined by 3GPP in TS 33.310 and TS 33.210. For IKE and IPsec, the tester shall base the tests on the profile defined by 3GPP in TS 33.210. For protocols, for which 3GPP did not define a security profile, e.g. SSH, the tester shall base the tests on a widely recognised and publicly available security profile.
Execution Steps:
  1. The tester shall check that compliance with the selected security profile can be inferred from detailed provisions in the product documentation.
  2. The tester shall establish a secure connection between the network product and the peer and verify that all protocol versions and combinations of cryptographic algorithms that are mandated by the security profile are supported by the network product.
  3. The tester shall try to establish a secure connection between the network product and the peer and verify that this is not possible when the peer only offers a feature, including protocol version and combination of cryptographic algorithms, that is forbidden by the security profile.
Expected Results:
The traffic is properly protected, and insecure options are not accepted by the Network Product.
Expected format of evidence:
Provide evidence of the check of the product documentation in plain text. Save the logs and the communication flow in a .pcap file.
Up
4.2.3.2.5  Logging access to personal datap. 20
Requirement Name:
Logging access to personal data
Requirement Description:
In some cases access to personal data in clear text might be required. If such access is required, access to this data shall be logged, and the log shall contain who accessed what data without revealing personal data in clear text. When for practical purposes such logging is not available, a coarser grain logging is allowed.
In some cases, the personal data stored in the log files may allow the direct identification of a subscriber. In such cases, the revealed personal information may not expose the subscriber to any kind of privacy violation.
Test case:
Test Name:
TC_LOGGING_ACCESS_TO_PERSONAL_DATA
Purpose:
Verify that in cases where a network product presents personal data in clear text, access attempts to such data are logged and the log information includes the user identity that has accessed the data. The test case also verifies that the personal data itself is not included in clear text in the log.
Procedure and execution steps:
Pre-Conditions:
A document which provides a description of where personal data in clear text is accessible on the network product, how it can be accessed, and details of where such access attempts are logged and how to view these logs.
Execution Steps:
  • The tester verifies, for cases where personal data is accessible in clear text, that attempts to access it are recorded in a log, that the log includes the identity of the user that has attempted to access the data, and that the log does not include the actual personal data in clear-text.
  • The tester repeats the check for each case where personal data is accessible.
Expected Results:
All access attempts to personal data (in clear text) are recorded in the described logs, with the user identity included and no personal data visible in the log.
Expected format of evidence:
Sample copies of the log files.
Up

4.2.3.3  Protecting availability and integrityp. 21

4.2.3.3.1  System handling during overload situationsp. 21
Requirement Name:
System handling during overload situations
Requirement Description:
The system shall provide security measures to deal with overload situations which may occur as a result of a denial of service attack or during periods of increased traffic, or reach the congestion threshold. In particular, partial or complete impairment of system availability shall be avoided. Potential protective measures include:
  • Restricting available RAM per application.
  • Restricting maximum sessions for a Web application.
  • Defining the maximum size of a dataset.
  • Restricting CPU resources per process.
  • Prioritizing processes.
  • Overload control method, e.g. limiting amount or size of transactions of a user or from an IP address in a specific time range.
Security Objective references:
tba.
Test case:
Refer to test case in clause 4.2.3.3.3.
Up
4.2.3.3.2  Boot from intended memory devices onlyp. 21
Requirement name:
Boot from intended memory devices only
Requirement reference:
to be done later
Requirement Description:
The network product can boot only from the memory devices intended for this purpose.
Test case:
Test Name:
TC_BOOT_INT_MEM_1
Purpose:
Verify that the network product can only boot from memory devices intended for this purpose (e.g. not from external memory like USB key).
Procedure and execution steps:
Pre-Conditions:
A document which contains information regarding the firmware access mechanism supported by the product and about the memory devices from which the network product can boot.
Execution Steps:
  1. The tester verifies that the network product is configured to boot from memory devices declared in the network product document only.
  2. The tester verifies that there is no possibility to access and modify the firmware of the network product without successful authentication.
Expected Results:
The network product cannot boot from a memory device that is not configured in its firmware, and access to the firmware is only possible with the correct authentication.
Expected format of evidence:
NA
Up
4.2.3.3.3  System handling during excessive overload situationsp. 22
Requirement Name:
System handling during excessive overload situations
Requirement Description:
The system shall act in a predictable way if an overload situation cannot be prevented. A system shall be built in this way that it can react on an overload situation in a controlled way. However it is possible that a situation happens where the security measures are no longer sufficient.
In such case it shall be ensured that the system cannot reach an undefined and thus potentially insecure state. In an extreme case this means that a controlled system shutdown is preferable to uncontrolled failure of the security functions and thus loss of system protection.
The vendor shall provide a technical description of the network product's Over Load Control mechanisms (especially whether these mechanisms rely on cooperation of other network elements e.g. eNode B) and the accompanying test case for this requirement will check that the description provides sufficient detail in order for an evaluator to understand how the mechanism is designed.
Security Objective references:
tba.
Test case:
Test Name:
TC_SYSTEM_HANDLING_OF_OVERLOAD_SITUATIONS
Purpose:
Verify that the network product:
  • has a detailed technical description of the overload control mechanisms used to deal with overload scenarios;
  • has test results verifying the operation of the overload control mechanisms.
Procedure and execution steps:
Pre-Conditions:
  • A document which provide a detailed technical description of the overload control mechanisms.
  • Test results from a test execution phase of overload control mechanism testing.
Execution Steps:
  • The tester verifies that there is:
    • A technical description providing a high-level overview of the overload control design:
      • An overview of the types of overload scenarios that the network product overload control mechanisms are expected to handle.
      • An overview of the overload control thresholds that the network product uses to trigger overload control mechanisms.
      • Description of the types of attacks that may cause an overload to the network product and how these are handled.
      • A description of how the network product discards or handles input during various overload situations including excessive overloads. i.e. where the overload is significantly greater than the thresholds where overload detection is triggered.
      • A description of how the network product security functions operate and perform during overload.
      • A description of how the network product shuts down or performs or takes other abatement or corrective actions during excessive overload conditions.
  • The tester verifies that the test results:
    • Contain details of the overload conditions used in the test execution that are consistent with the technical description document.
    • Describe test procedures used to verify the overload control mechanisms.
    • Contain data which demonstrates/indicates that the overload control mechanisms described in the technical description document have been implemented.
    • Contain details of the test set-up including the mechanisms for creating the overload. Where simulators and/or scripts are used to artificially create a load then details of these should also be included.
Expected Results:
  • A technical description provides a high-level overview of the overload control design.
  • A overview of the types of overload scenarios and overload control thresholds that are considered.
  • Description on the types of attacks that may cause an overload to the system and how these are handled.
  • A description of how the network product discards or handles input during various overload situations.
  • Describes if or how the network product security functions operate and perform during overload.
  • If parts of the system shutdown or take other abatement or corrective actions these should be described.
The test results should:
  • Contain details of the overload conditions used in the test execution that are consistent with the technical description document.
  • Describe the test procedures used to verify the overload control mechanisms.
  • Contain data which demonstrates/indicates that the overload control mechanisms described in the technical description document have been implemented.
  • Contain details of the test set-up including the mechanisms for creating the overload.
Expected format of evidence:
Documentation showing each of the points in the results sections.
Up
4.2.3.3.4  System robustness against unexpected inputp. 24
Requirement Name:
System robustness against unexpected input.
Requirement Description:
During transmission of data to a system it is necessary to validate input to the network product before processing. This includes all data which is sent to the system. Examples of this are user input, values in arrays and content in protocols. The following typical implementation error shall be avoided:
  • No validation on the lengths of transferred data
  • Incorrect assumptions about data formats
  • No validation that received data complies with the specification
  • Insufficient handling of protocol errors in received data
  • Insufficient restriction on recursion when parsing complex data formats
  • White listing or escaping for inputs outside the values margin
Security Objective references:
tba.
Test case:
This requirement will be verified by Robustness and Protocol fuzzing tests as defined in clause 4.4.4 Robustness and fuzz testing.
Up
4.2.3.3.5  Network Product software package integrityp. 24
Requirement name:
Network product Software integrity validation
Requirement reference:
to be done later
Requirement Description:
  1. Software package integrity shall be validated in the installation/upgrade stage.
  2. Network product shall support software package integrity validation via cryptographic means, e.g. digital signature. To this end, the network product has a list of public keys or certificates of authorised software sources, and uses the keys to verify that the software update is originated from only these sources.
  3. Tampered software shall not be executed or installed if integrity check fails.
  4. A security mechanism is required to guarantee that only authorized individuals can initiate and deploy a software update, and modify the list mentioned in bullet 2.
Security Objective references:
SOFTWARE INTEGRITY
Test case:
Test Name:
TC_SW_PKG_INTEGRITY_1
Purpose:
Verify that:
  1. The Network Product validates the software package integrity during the installation/upgrade stage.
  2. The software package integrity validation mechanism is performed using cryptographic mechanisms, e.g. digital signature using the public keys or certificates configured in the network product.
  3. Software that fails an integrity check is rejected by the network product.
  4. Only authorized users are allowed to install software.
Procedure and execution steps:
Pre-Conditions:
  • A network product document containing information regarding software package integrity checks, including details of how the integrity check is carried out, where public keys or certificates of sources authorised to sign software packages are stored on the network product and who these sources are, and what evidence is created to prove that the integrity check has been executed and what the result of the check was. Documentation which describes the installation procedure including how a user is authorized and authenticated to perform installation process.
  • A valid network product software load/package and one that is not-valid (or could be deemed to have been tampered with) are available.
Execution Steps:
The tester checks the permissions required to install software on the network product ensuring that a user is properly authenticated by the network product and that they have the required access privileges to perform the installation activity.
The tester checks, when a software package is attempted to be installed on the network product, that the software package integrity check is executed (check for evidence of execution as described in network product documentation) and that valid software is allowed to be installed but invalid software is rejected.
The tester checks the access control permissions for the software package integrity checking process, the list of public keys of authorised software sources, and any related credentials or keys for the process, to ensure that the process cannot be controlled by persons that are not authorized to do so.
Expected Results:
  • Evidence that the software package integrity check has been executed for both cases of software installation (valid and invalid software packages).
  • Authentication and access control mechanisms are in operation for software package installation and around the software package integrity checking mechanism.
  • The installation/upgrade operation fails when using an invalid software package.
  • The installation/upgrade operation is successful when using a valid software package.
Expected format of evidence:
Snapshots containing the result of the installation of package A and B.
Up

Up   Top   ToC