...
VNF General Security Requirements
| VNF Security Ref | Description | Notes | CNTT Relevant | Exists | CNTT Ref# | Current Description, if exists | Recommended Description (may be a modification of existing) | ||
|---|---|---|---|---|---|---|---|---|---|
| 1 | R-118669 | Login access (e.g., shell access) to the operating system layer, whether interactive or as part of an automated process, MUST be through an encrypted protocol such as SSH or TLS. | Y | N | All login access (e.g., shell access) to any service, whether interactive or as part of an automated process, must be through an encrypted protocol such as SSH or TLS 1.2 or higher. | ||||
| 2 | R-19082 | The VNF MUST not contain undocumented functionality. | |||||||
| 3 | R-19768 | The VNF SHOULD support the separation of (1) signaling and payload traffic (i.e., customer facing traffic), (2) operations, administration and management traffic, and (3) internal VNF traffic (i.e., east-west traffic such as storage access) using technologies such as VPN and VLAN. | |||||||
| 4 | R-21819 | VNFs that are subject to regulatory requirements MUST provide functionality that enables the Operator to comply with ETSI TC LI requirements, and, optionally, other relevant national equivalents. | |||||||
| 5 | R-23740 | The VNF MUST implement and enforce the principle of least privilege on all protected interfaces. | Y | Y | RA-1 2.3.8.2 Platform and Access sec.sys.007 | ||||
| 6 | R-240760 | The VNF MUST NOT contain any backdoors. | |||||||
| 7 | R-256267 | If SNMP is utilized, the VNF MUST support at least SNMPv3 with message authentication. | |||||||
| 8 | R-258686 | The VNF application processes SHOULD NOT run as root. If a VNF application process must run as root, the technical reason must be documented. | |||||||
| 9 | R-353637 | Containerized components of VNFs SHOULD follow the recommendations for Container Base Images and Build File Configuration in the latest available version of the CIS Docker Community Edition Benchmarks to ensure that containerized VNFs are secure. All non-compliances with the benchmarks MUST be documented. | |||||||
| 10 | R-381623 | Containerized components of VNFs SHOULD execute in a Docker run-time environment that follows the Container Runtime Configuration in the latest available version of the CIS Docker Community Edition Benchmarks to ensure that containerized VNFs are secure. All non-compliances with the benchmarks MUST be documented. | |||||||
| 11 | R-46986 | The VNF provider MUST follow GSMA vendor practices and SEI CERT Coding Standards when developing the VNF in order to minimize the risk of vulnerabilities. See GSMA NESAS Network Equipment Security Assurance Scheme – Development and Lifecycle Security Requirements Version 1.0 (https://www.gsma.com/ security/wp-content/uploads/2019/11/FS.16-NESAS-Development-and-Lifecycle-Security- Requirements-v1.0.pdf) and SEI CERT Coding Standards (https://wiki.sei.cmu.edu/ confluence/display/seccode/SEI+CERT+Coding+Standards). | |||||||
| 12 | R-56904 | The VNF MUST interoperate with the ONAP (SDN) Controller so that it can dynamically modify the firewall rules, ACL rules, QoS rules, virtual routing and forwarding rules. This does not preclude the VNF providing other interfaces for modifying rules. | |||||||
| 13 | R-61354 | The VNF MUST provide a mechanism (e.g., access control list) to permit and/or restrict access to services on the VNF by source, destination, protocol, and/or port. | |||||||
| 14 | R-62498 | The VNF MUST support only encrypted access protocols, e |
| .g., TLS, SSH, SFTP. | Y | Y | RA-1 2.3.8.2 Platform and Access sec.sys.003 (doesn't mention technologies) | ||||||
| 15 | R-638682 | The VNF MUST log any security event required by the VNF Requirements to Syslog using LOG_AUTHPRIV for any event that would contain sensitive information and LOG_AUTH for all other relevant events. | |||||||
| 16 | R-69649 | The VNF Provider MUST have patches available for vulnerabilities in the VNF as soon as possible. Patching shall be controlled via change control process with vulnerabilities disclosed along with mitigation recommendations. | RA-1 includes requirements for the platform | ||||||
| 17 | R-756950 | The VNF MUST be operable without the use of Network File System (NFS). | |||||||
| 18 | R-80335 | For all GUI and command-line interfaces, the VNF MUST provide the ability to present a warning notice that is set by the Operator. A warning notice is a formal statement of resource intent presented to everyone who accesses the system. | |||||||
| 19 | R-842258 | The VNF MUST include a configuration (e.g. a heat template or CSAR package) that specifies the targeted parameters (e.g. a limited set of ports) over which the VNF will communicate; including internal, external and management communication. | |||||||
| 20 | R-86261 | The VNF MUST be able to authenticate and authorize all remote access. | |||||||
| 21 | R-872986 | The VNF MUST store Authentication Credentials used to authenticate to other systems encrypted except where there is a technical need to store the password unencrypted in which case it must be protected using other security techniques that include the use of file and directory permissions. Ideally, credentials SHOULD rely on a HW Root of Trust, such as a TPM or HSM. | Y | Y | sec.sys.003 | modify to add, "such as TPM or HSM." | |||
| 22 | R-92207 | The VNF SHOULD provide a mechanism that enables the operators to perform automated system configuration auditing at configurable time intervals. | Y | N | The platform must perform automated system configuration auditing at configurable time intervals. | ||||
| 23 | R-99771 | The VNF MUST have all code (e.g., QCOW2) and configuration files (e.g., HEAT template, Ansible playbook, script) hardened, or with documented recommended configurations for hardening and interfaces that allow the Operator to harden the VNF. Actions taken to harden a system include disabling all unnecessary services, and changing default values such as default credentials and community strings. |
VNF Identity and Access Management Requirements
| VNF Security Ref | Description | Notes | CNTT Relevant | Exists | CNTT Ref# | Current Description, if exists | Recommended Description (may be a modification of existing) | ||
|---|---|---|---|---|---|---|---|---|---|
| 1 | R-23135 | The VNF MUST, if not integrated with the Operator’s identity and access management |
| system, authenticate all access to protected resources. | |||||||||
| 2 | R-231402 | The VNF MUST provide a means to explicitly logout, thus ending that session. | Y | N | The Platform must provide a means to explicitly logout from an interactive session, thus ending that session. The Platform must provide a means to |
automatically logout, thus ending that session, of any interactive session after a configurable period of inactivity. | |||||||||
| 3 | R-251639 | The VNF MUST provide explicit confirmation of a session termination such as a message, new page, or rerouting to a login page. | |||||||
| 4 | R-358699 | The VNF MUST support at least the following roles: system administrator, application administrator, network function O&M. | |||||||
| 5 | R-373737 | The VNF MUST, if not integrated with the operator’s IAM system, provide a mechanism for assigning roles and/or permissions to an identity. | |||||||
| 6 | R-39562 | The VNF MUST disable unnecessary or vulnerable cgi-bin programs. | |||||||
| 7 | R-42874 | The VNF MUST allow the Operator to restrict access to protected resources based on the assigned permissions associated with an ID in order to support Least Privilege (no more privilege than required to perform job functions). | |||||||
| 8 | R-45719 | The VNF MUST, if not integrated with the Operator’s Identity and Access Management system, enforce a configurable “terminate idle sessions” policy by terminating the session after a configurable period of inactivity. | |||||||
| 9 | R-46908 | The VNF MUST, if not integrated with the Operator’s Identity and Access Management system, comply with “password complexity” policy. When passwords are used, they shall be complex and shall at least meet the following password construction requirements: (1) be a minimum configurable number of characters in length, (2) include 3 of the 4 following types of characters: upper-case alphabetic, lower-case alphabetic, numeric, and special, (3) not be the same as the UserID with which they are associated or other common strings as specified by the environment, (4) not contain repeating or sequential characters or numbers, (5) not to use special characters that may have command functions, and (6) new passwords must not contain sequences of three or more characters from the previous password. | |||||||
| 10 | R-479386 | The VNF MUST provide the capability of setting a configurable message to be displayed after successful login. It MAY provide a list of supported character sets. | |||||||
| 11 | R-581188 | The VNF MUST NOT identify the reason for a failed authentication, only that the authentication failed. | |||||||
| 12 | R-59391 | The VNF MUST NOT allow the assumption of the permissions of another account to mask individual accountability. For example, use SUDO when a user requires elevated permissions such as root or admin. | |||||||
| 13 | R-75041 | The VNF MUST, if not integrated with the Operator’s Identity and Access Management system, support configurable password expiration. | |||||||
| 14 | R-78010 | The VNF MUST support LDAP in order to integrate with an external identity and access manage system. It MAY support other identity and access management protocols. | Y | N | The Platform must support LDAP in order to integrate with an external identity and access manage system. It MAY support other identity and access management protocols. | ||||
| 15 | R-79107 | The VNF MUST, if not integrated with the Operator’s Identity and Access Management system, support the ability to lock out the userID after a configurable number of consecutive unsuccessful authentication attempts using the same userID. The locking mechanism must be reversible by an administrator and should be reversible after a configurable time period. | |||||||
| 16 | R-81147 | The VNF MUST, if not integrated with the Operator’s Identity and Access Management system, support multifactor authentication on all protected interfaces exposed by the VNF for use by human users. | |||||||
| 17 | R-814377 | The VNF MUST have the capability of allowing the Operator to create, manage, and automatically provision user accounts using one of the protocols specified in Chapter 7. | |||||||
| 18 | R-844011 | The VNF MUST not store authentication credentials to itself in clear text or any reversible form and must use salting. | |||||||
| 19 | R-86835 | The VNF MUST set the default settings for user access to deny authorization, except for a super user type of account. | |||||||
| 20 | R-931076 | The VNF MUST support account names that contain at least A-Z, a-z, and 0-9 character sets and be at least 6 characters in length. | |||||||
| 21 | R-99174 | The VNF MUST, if not integrated with the Operator’s Identity and Access Management system, support the creation of multiple IDs so that individual accountability can be supported. |
VNF API Security Requirements
...
| VNF Security Ref | Description | Notes | CNTT Relevant | Exists | CNTT Ref# | Current Description, if exists | Recommended Description (may be a modification of existing) | |||
|---|---|---|---|---|---|---|---|---|---|---|
| 1 |
| The VNF SHOULD support an automated certificate management protocol such as CMPv2, Simple Certificate Enrollment Protocol (SCEP) or Automated Certificate Management Environment (ACME). | ||||||||
| 2 | R-93860 | The VNF SHOULD provide the capability to integrate with an external encryption service. | ||||||||
| 3 | R-44723 | The VNF MUST use symmetric keys of at least 112 bits in length. | ||||||||
| 4 | R-25401 | The VNF MUST use asymmetric keys of at least 2048 bits in length. | ||||||||
| 5 | R-52060 | The VNF MUST provide the capability to configure encryption algorithms or devices so that they comply with the laws of the jurisdiction in which there are plans to use data encryption. | ||||||||
| 6 | R-83500 | The VNF MUST provide the capability of allowing certificate renewal and revocation. | ||||||||
| 7 | R-29977 | The VNF MUST provide the capability of testing the validity of a digital certificate by validating the CA signature on the certificate. | ||||||||
| 8 | R-24359 | The VNF MUST provide the capability of testing the validity of a digital certificate by validating the date the certificate is being used is within the validity period for the certificate. | ||||||||
| 9 | R-39604 | The VNF MUST provide the capability of testing the validity of a digital certificate by checking the Certificate Revocation List (CRL) for the certificates of that type to ensure that the certificate has not been revoked. | ||||||||
| 10 | R-75343 | The VNF MUST provide the capability of testing the validity of a digital certificate by recognizing the identity represented by the certificate - the “distinguished name”. | ||||||||
| 11 | R-49109 | The VNF or PNF MUST support HTTPS using TLS v1.2 or higher with strong cryptographic ciphers. | ||||||||
| 12 | R-41994 | The VNF MUST support the use of X.509 certificates issued from any Certificate Authority (CA) that is compliant with RFC5280, e.g., a public CA such as DigiCert or Let’s Encrypt, or an RFC5280 compliant Operator CA. Note: The VNF provider cannot require the use of self-signed certificates in an Operator’s run time environment. |
...