2. Architecture Requirements

This chapter includes both “Requirements” that must be satisfied in an RA-1 conformant implementation and “Recommendations” that are optional for implementation.

2.1. Reference Model Requirements

The tables below contain the requirements from the Reference Model [1] to cover the Basic and High-Performance profiles.

To ensure alignment with the infrastructure profile catalogue, the following requirements are referenced through:

  • Those relating to Cloud Infrastructure Software Profiles

  • Those relating to Cloud Infrastructure Hardware Profiles

  • Those relating to Cloud Infrastructure Management

  • Those relating to Cloud Infrastructure Security

2.1.1. Cloud Infrastructure Software Profile Requirements for Compute

Table 2.1 Reference Model Requirements: Cloud Infrastructure Software Profile Capabilities

Reference

Description

Requirement for Basic Profile

Requirement for High-Performance Profile

Specification Reference

e.cap.001

Max number of vCPU that can be assigned to a single instance by the Cloud Infrastructure

At least 16

At least 16

Compute Nodes

e.cap.002

Max memory that can be assigned to a single instance by the Cloud Infrastructure

at least 32 GB

at least 32 GB

Virtual Storage

e.cap.003

Max storage that can be assigned to a single instance by the Cloud Infrastructure

at least 320 GB

at least 320 GB

Virtual Storage and Storage Backend

e.cap.004

Max number of connection points that can be assigned to a single instance by the Cloud Infrastructure

6

6

Not Detailed

e.cap.005

Max storage that can be attached / mounted to an instance by the Cloud Infrastructure

Up to 16TB [*]

Up to 16TB [*]

Storage Backend

e.cap.006 /

infra.com.cfg.003

CPU pinning support

Not required

Must support

Consumable Infrastructure Resources and Services

e.cap.007 /

infra.com.cfg.002

NUMA support

Not required

Must support

Consumable Infrastructure Resources and Services

e.cap.018 /

infra.com.cfg.005

Simultaneous Multithreading (SMT) enabled

Must

Optional support

Consumable Infrastructure Resources and Services

i.cap.018 /

infra.com.cfg.004

Huge pages configured

Not required

Must support

Consumable Infrastructure Resources and Services

[*] Defined in the .bronze configuration in “Storage extensions” in [1].

2.1.2. Cloud Infrastructure Software Profile Extensions Requirements for Compute

Table 2.2 Cloud Infrastructure Software Profile Extensions Requirements for Compute

Reference

Description

Profile Extensions

Profile Extra-Specs

Specification Reference

e.cap.008 /

infra.com.acc.cfg.001

IPSec Acceleration using the virtio-ipsec interface

Compute Intensive GPU

Acceleration

e.cap.010 /

infra.com.acc.cfg.002

Transcoding Acceleration

Compute Intensive GPU

Video Transcoding

Acceleration

e.cap.011 /

infra.com.acc.cfg.003

Programmable Acceleration

Firmware-programmable adapter

Accelerator

Acceleration

e.cap.012

Enhanced Cache Management: L=Lean; E=Equal; X=eXpanded

E

E

Not detailed

e.cap.014 /

infra.com.acc.cfg.004

Hardware coprocessor support (GPU/NPU)

Compute Intensive GPU

Acceleration

e.cap.016 /

infra.com.acc.cfg.005

FPGA/other Acceleration H/W

Firmware-programmable adapter

Acceleration

2.1.3. Cloud Infrastructure Software Profile Requirements for Networking

The features and configuration requirements related to virtual networking for the two (2) types of Cloud Infrastructure Profiles are specified below followed by networking bandwidth requirements.

Table 2.3 Reference Model Requirements - Virtual Networking

Reference

Description

Requirement for Basic Profile

Requirement for High-Performance Profile

Specification Reference

infra.net.cfg.001

IO virtualisation using virtio1.1

Must support

Must support

Virtualisation layer

infra.net.cfg.002

The overlay network encapsulation protocol needs to enable ECMP in the underlay to take advantage of the scale-out features of the network fabric

Must support VXLAN, MPLSoUDP, GENEVE, other

No requirement specified

Network Fabric

infra.net.cfg.003

Network Address Translation

Must support

Must support

Network Fabric

infra.net.cfg.004

Security Groups

Must support

Must support

Workload Security

infra.net.cfg.005

SFC support

Not required

Must support

Virtual Networking - 3rd party SDN solution

infra.net.cfg.006

Traffic patterns symmetry

Must support

Must support

Not detailed

The required number of connection points to an instance is described in e.cap.004 above. The table below specifies the required bandwidth of those connection points.

Table 2.4 Reference Model Requirements - Network Interface Specifications

Reference

Description

Requirement for Basic Profile

Requirement for High Performance Profile

Specification Reference

n1, n2, n3, n4, n5, n6

1, 2, 3, 4, 5, 6 Gbps

Must support

Must support

Not detailed

n10, n20, n30, n40, n50, n60

10, 20, 30, 40, 50, 60 Gbps

Must support

Must support

Not detailed

n25, n50, n75, n100, n125, n150

25, 50, 75, 100, 125, 150 Gbps

Optional

Must support

Not detailed

n50, n100, n150, n200, n250, n300

50, 100, 150, 200, 250, 300 Gbps

Optional

Must support

Not detailed

n100, n200, n300, n400, n500, n600

100, 200, 300, 400, 500, 600 Gbps

Optional

Must support

Not detailed

2.1.4. Cloud Infrastructure Software Profile Extensions Requirements for Networking

Table 2.5 Cloud Infrastructure Software Profile Extensions Requirements for Networking

Reference

Description

Requirement for Basic Profile

Requirement for High-Performance Profile

Specification Reference

e.cap.013 /

infra.hw.nac.cfg.004

SR-IOV over PCI-PT

N

Y

Compute Nodes

e.cap.019 /

infra.net.acc.cfg.001

vSwitch optimisation (DPDK)

N

Y

Compute Nodes and Network quality of service

e.cap.015 /

infra.net.acc.cfg.002

SmartNIC (for HW Offload)

N

Optional

Acceleration

e.cap.009 /

infra.net.acc.cfg.003

Crypto acceleration

N

Optional

Not detailed

infra.net.acc.cfg.004

Crypto Acceleration Interface

N

Optional

Not detailed

2.1.5. Cloud Infrastructure Software Profile Requirements for Storage

Table 2.6 Reference Model Requirements - Cloud Infrastructure Software Profile Requirements for Storage

Reference

Description

Requirement for Basic Profile

Requirement for High-Performance Profile

Specification Reference

infra.stg.cfg.002

Storage Block

Must support

Must support

Storage and Cinder

infra.stg.cfg.003

Storage with replication

Not required

Must support

Storage and Transaction Volume Considerations

infra.stg.cfg.004

Storage with encryption

Must support

Must support

Storage

infra.stg.acc.cfg.001

Storage IOPS oriented

Not required

Must support

Storage

infra.stg.acc.cfg.002

Storage capacity oriented

Not required

Not required

Storage

2.1.6. Cloud Infrastructure Software Profile Extensions Requirements for Storage

Table 2.7 Reference Model Requirements - Cloud Infrastructure Software Profile Extensions Requirements for Storage

Reference

Description

Profile Extensions

Profile Extra-Specs

Specification Reference

infra.stg.acc.cfg.001

Storage IOPS oriented

Storage Intensive High-performance storage

Not detailed

infra.stg.acc.cfg.002

Storage capacity oriented

High Capacity

Not detailed

2.1.7. Cloud Infrastructure Hardware Profile Requirements

Table 2.8 Reference Model Requirements - Cloud Infrastructure Hardware Profile Requirements

Reference

Description

Requirement for Basic Profile

Requirement for High-Performance Profile

Specification Reference

infra.hw.001

CPU Architecture (Values such as x64, ARM, etc.)

infra.hw.cpu.cfg.001

Minimum number of CPU (Sockets)

2

2

Compute

infra.hw.cpu.cfg.002

Minimum number of Cores per CPU

20

20

Compute

infra.hw.cpu.cfg.003

NUMA

Not required

Must support

Compute

infra.hw.cpu.cfg.004

Simultaneous Multithreading/Symmetric Multiprocessing (SMT/SMP)

Must support

Optional

Compute

infra.hw.stg.hdd.cfg.001

Local Storage HDD

No requirement specified

No requirement specified

Consumable Infrastructure Resources and Services

infra.hw.stg.ssd.cfg.002

Local Storage SSD

Should support

Should support

Consumable Infrastructure Resources and Services

infra.hw.nic.cfg.001

Total Number of NIC Ports available in the host

4

4

Compute

infra.hw.nic.cfg.002

Port speed specified in Gbps (minimum values)

10

25

Consumable Infrastructure Resources and Services

infra.hw.pci.cfg.001

Number of PCIe slots available in the host

8

8

Not detailed

infra.hw.pci.cfg.002

PCIe speed

Gen 3

Gen 3

Not detailed

infra.hw.pci.cfg.003

PCIe Lanes

8

8

Not detailed

infra.hw.nac.cfg.003

Compression

No requirement specified

No requirement specified

Not detailed

2.1.7.1. Cloud Infrastructure Hardware Profile-Extensions Requirements

Table 2.9 Reference Model Requirements - Cloud Infrastructure Hardware Profile Extensions Requirements

Reference

Description

Requirement for Basic Profile

Requirement for High-Performance Profile

Specification Reference

e.cap.014 /

infra.hw.cac.cfg.001

GPU

N

Optional

Acceleration

e.cap.016 /

infra.hw.cac.cfg.002

FPGA/other Acceleration H/W

N

Optional

Acceleration

e.cap.009 /

infra.hw.nac.cfg.001

Crypto Acceleration

N

Optional

Acceleration

e.cap.015 /

infra.hw.nac.cfg.002

SmartNIC

N

Optional

Acceleration

infra.hw.nac.cfg.003

Compression

Optional

Optional

Acceleration

e.cap.013 /

infra.hw.nac.cfg.004

SR-IOV over PCI-PT

N

Yes

Compute node configurations for Profiles and OpenStack Flavors

2.1.8. Cloud Infrastructure Management Requirements

Table 2.10 Reference Model Requirements - Cloud Infrastructure Management Requirements

Reference

Description

Requirement (common to all Profiles)

Specification Reference

e.man.001

Capability to allocate virtual compute resources to a workload

Must support

Resources and Services exposed to VNFs

e.man.002

Capability to allocate virtual storage resources to a workload

Must support

Resources and Services exposed to VNFs

e.man.003

Capability to allocate virtual networking resources to a workload

Must support

Resources and Services exposed to VNFs

e.man.004

Capability to isolate resources between tenants

Must support

Tenant Isolation

e.man.005

Capability to manage workload software images

Must support

Glance

e.man.006

Capability to provide information related to allocated virtualised resources per tenant

Must support

Logging, Monitoring and Analytics

e.man.007

Capability to notify state changes of allocated resources

Must support

Logging, Monitoring and Analytics

e.man.008

Capability to collect and expose performance information on virtualised resources allocated

Must support

Logging, Monitoring and Analytics

e.man.009

Capability to collect and notify fault information on virtualised resources

Must support

Logging, Monitoring and Analytics

2.1.9. Cloud Infrastructure Security Requirements

2.1.9.1. System Hardening Requirements

Table 2.11 Reference Model Requirements - System Hardening Requirements

Reference

sub-category

Description

Specification Reference

sec.gen.001

Hardening

The Platform must maintain the specified configuration

Security LCM and Cloud Infrastructure provisioning and configuration management

sec.gen.002

Hardening

All systems part of Cloud Infrastructure must support hardening as defined in CIS Password Policy Guide [8]

Password policy

sec.gen.003

Hardening

All servers part of Cloud Infrastructure must support a root of trust and secure boot

Server boot hardening

sec.gen.004

Hardening

The Operating Systems of all the servers part of Cloud Infrastructure must be hardened by removing or disabling unnecessary services, applications and network protocols, configuring operating system user authentication, configuring resource controls, installing and configuring additional security controls where needed, and testing the security of the Operating System (NIST SP 800-123)

Function and Software

sec.gen.005

Hardening

The Platform must support Operating System level access control

System Access

sec.gen.006

Hardening

The Platform must support Secure logging. Logging with root account must be prohibited when root privileges are not required

System Access

sec.gen.007

Hardening

All servers part of Cloud Infrastructure must be Time synchronised with authenticated Time service

Security Logs Time Synchronisation

sec.gen.008

Hardening

All servers part of Cloud Infrastructure must be regularly updated to address security vulnerabilities

Security LCM

sec.gen.009

Hardening

The Platform must support software integrity protection and verification

Integrity of OpenStack components configuration

sec.gen.010

Hardening

The Cloud Infrastructure must support encrypted storage, for example, block, object and file storage, with access to encryption keys restricted based on a need to know (Controlled Access Based on the Need to Know [9])

Confidentiality and Integrity

sec.gen.012

Hardening

The Operator must ensure that only authorised actors have physical access to the underlying infrastructure

This requirement’s verification must be part of the organisation’s security process

sec.gen.013

Hardening

The Platform must ensure that only authorised actors have logical access to the underlying infrastructure

System Access

sec.gen.015

Hardening

Any change to the Platform must be logged as a security event, and the logged event must include the identity of the entity making the change, the change, the date and the time of the change

Security LCM

2.1.9.2. Platform and Access Requirements

Table 2.12 Reference Model Requirements - Platform and Access Requirements

Reference

sub-category

Description

Specification Reference

sec.sys.001

Access

The Platform must support authenticated and secure access to API, GUI and command line interfaces

RBAC

sec.sys.002

Access

The Platform must support Traffic Filtering for workloads (for example, Firewall)

Workload Security

sec.sys.003

Access

The Platform must support Secure and encrypted communications, and confidentiality and integrity of network

Confidentiality and Integrity

sec.sys.004

Access

The Cloud Infrastructure must support authentication, integrity and confidentiality on all network channels

Confidentiality and Integrity

sec.sys.005

Access

The Cloud Infrastructure must segregate the underlay and overlay networks

Confidentiality and Integrity

sec.sys.006

Access

The Cloud Infrastructure must be able to utilise the Cloud Infrastructure Manager identity lifecycle management capabilities

Identity Security

sec.sys.007

Access

The Platform must implement controls enforcing separation of duties and privileges, least privilege use and least common mechanism (Role-Based Access Control)

RBAC

sec.sys.008

Access

The Platform must be able to assign the Entities that comprise the tenant networks to different trust domains. Communication between different trust domains is not allowed, by default

Workload Security

sec.sys.009

Access

The Platform must support creation of Trust Relationships between trust domains. These maybe uni-directional relationships where the trusting domain trusts another domain (the “trusted domain”) to authenticate users for them them or to allow access to its resources from the trusted domain. In a bidirectional relationship both domain are “trusting” and “trusted”

Logical segregation and high availability

sec.sys.010

Access

For two or more domains without existing trust relationships, the Platform must not allow the effect of an attack on one domain to impact the other domains either directly or indirectly

Logical segregation and high availability

sec.sys.011

Access

The Platform must not reuse the same authentication credentials (e.g., key pairs) on different Platform components (e.g., different hosts, or different services)

System Access

sec.sys.012

Access

The Platform must protect all secrets by using strong encryption techniques and storing the protected secrets externally from the component (e.g., in OpenStack Barbican)

Barbican

sec.sys.013

Access

The Platform must generate secrets dynamically as and when needed

Barbican

sec.sys.015

Access

The Platform must not contain back door entries (unpublished access points, APIs, etc.)

Not detailed

sec.sys.016

Access

Login access to the Platform’s components must be through encrypted protocols such as SSH v2 or TLS v1.2 or higher. Note: Hardened jump servers isolated from external networks are recommended

Security LCM

sec.sys.017

Access

The Platform must provide the capability of using digital certificates that comply with X.509 standards issued by a trusted Certification Authority

Confidentiality and Integrity

sec.sys.018

Access

The Platform must provide the capability of allowing certificate renewal and revocation

Confidentiality and Integrity

sec.sys.019

Access

The Platform must provide the capability of testing the validity of a digital certificate (CA signature, validity period, non revocation identity)

Confidentiality and Integrity

2.1.9.3. Confidentiality and Integrity Requirements

Table 2.13 Reference Model Requirements - Confidentiality and Integrity Requirements

Reference

sub-category

Description

Specification Reference

sec.ci.001

Confidentiality /

Integrity

The Platform must support Confidentiality and Integrity of data at rest and in transit

Confidentiality and Integrity

sec.ci.003

Confidentiality /

Integrity

The Platform must support Confidentiality and Integrity of data related metadata

Confidentiality and Integrity

sec.ci.004

Confidentiality

The Platform must support Confidentiality of processes and restrict information sharing with only the process owner (e.g., tenant)

Confidentiality and Integrity

sec.ci.005

Confidentiality /

Integrity

The Platform must support Confidentiality and Integrity of process- related metadata and restrict information sharing with only the process owner (e.g., tenant)

Confidentiality and Integrity

sec.ci.006

Confidentiality /

Integrity

The Platform must support Confidentiality and Integrity of workload resource utilisation (RAM, CPU, Storage, Network I/O, cache, hardware offload) and restrict information sharing with only the workload owner (e.g., tenant)

Platform Access

sec.ci.007

Confidentiality /

Integrity

The Platform must not allow Memory Inspection by any actor other than the authorised actors for the Entity to which Memory is assigned (e.g., tenants owning the workload), for Lawful Inspection, and for secure monitoring services. Administrative access must be managed using Platform Identity Lifecycle Management

Platform Access

sec.ci.008

Confidentiality

The Cloud Infrastructure must support tenant networks segregation

Workload Security

2.1.9.4. Workload Security Requirements

Table 2.14 Reference Model Requirements - Workload Security Requirements

Reference

sub-category

Description

Specification Reference

sec.wl.001

Workload

The Platform must support Workload placement policy

Workload Security

sec.wl.002

Workload

The Cloud Infrastructure must provide methods to ensure the platform’s trust status and integrity (e.g., remote attestation, Trusted Platform Module)

Cloud Infrastructure and VIM Security

sec.wl.003

Workload

The Platform must support secure provisioning of Workloads

Workload Security

sec.wl.004

Workload

The Platform must support Location assertion (for mandated in- country or location requirements)

Workload Security

sec.wl.005

Workload

The Platform must support the separation of production and non- production Workloads

Workload Security

sec.wl.006

Workload

The Platform must support the separation of Workloads based on their categorisation (for example, payment card information, healthcare, etc.)

Workload Security

sec.wl.007

Workload

The Operator must implement processes and tools to verify NF authenticity and integrity

Image Security

2.1.9.5. Image Security Requirements

Table 2.15 Reference Model Requirements - Image Security Requirements

Reference

sub-category

Description

Specification Reference

sec.img.001

Image

Images from untrusted sources must not be used

Image Security

sec.img.002

Image

Images must be scanned to be maintained free from known vulnerabilities

Image Security

sec.img.003

Image

Images must not be configured to run with privileges higher than the privileges of the actor authorised to run them

Image Security

sec.img.004

Image

Images must only be accessible to authorised actors

Integrity of OpenStack components configuration

sec.img.005

Image

Image Registries must only be accessible to authorised actors

Integrity of OpenStack components configuration

sec.img.006

Image

Image Registries must only be accessible over networks that enforce authentication, integrity and confidentiality

Integrity of OpenStack components configuration

sec.img.007

Image

Image registries must be clear of vulnerable and out of date versions

Image Security

sec.img.008

Image

Images must not include any secrets. Secrets include passwords, cloud provider credentials, SSH keys, TLS certificate keys, etc.

Image Security

2.1.9.6. Security LCM Requirements

Table 2.16 Reference Model Requirements - Security LCM Requirements

Reference

sub-category

Description

Specification Reference

sec.lcm.001

LCM

The Platform must support Secure Provisioning, Availability, and Deprovisioning (Secure Clean-Up) of workload resources where Secure Clean-Up includes tear-down, defense against virus or other attacks

Monitoring and Security Audit

sec.lcm.002

LCM

The Cloud Operator must use management protocols limiting security risk such as SNMPv3, SSH v2, ICMP, NTP, syslog and TLS v1.2 or higher

Security LCM

sec.lcm.003

LCM

The Cloud Operator must implement and strictly follow change management processes for Cloud Infrastructure, Infrastructure Manager and other components of the cloud, and Platform change control on hardware

Monitoring and Security Audit

sec.lcm.005

LCM

Platform must provide logs and these logs must be monitored for anomalous behaviour

Monitoring and Security Audit

sec.lcm.006

LCM

The Platform must verify the integrity of all Resource management requests

Confidentiality and Integrity of tenant data (sec.ci.001)

sec.lcm.007

LCM

The Platform must be able to update newly instantiated, suspended, hibernated, migrated and restarted images with current time information

Not detailed

sec.lcm.008

LCM

The Platform must be able to update newly instantiated, suspended, hibernated, migrated and restarted images with relevant DNS information

Not detailed

sec.lcm.009

LCM

The Platform must be able to update the tag of newly instantiated, suspended, hibernated, migrated and restarted images with relevant geolocation (geographical) information

Not detailed

sec.lcm.010

LCM

The Platform must log all changes to geolocation along with the mechanisms and sources of location information (i.e. GPS, IP block, and timing)

Not detailed

sec.lcm.011

LCM

The Platform must implement Security life cycle management processes including the proactive update and patching of all deployed Cloud Infrastructure software

Patches

sec.lcm.012

LCM

The Platform must log any access privilege escalation

What to Log / What NOT to Log

2.1.9.7. Monitoring and Security Audit Requirements

The Platform is assumed to provide configurable alerting and notification capability and the operator is assumed to have automated systems, policies and procedures to act on alerts and notifications in a timely fashion. In the following the monitoring and logging capabilities can trigger alerts and notifications for appropriate action.

Table 2.17 Reference Model Requirements - Monitoring and Security Audit Requirements

Reference

sub-category

Description

Specification Reference

sec.mon.001

Monitoring / Audit

Platform must provide logs and these logs must be regularly monitored for events of interest. The logs must contain the following fields: event type, date/time, protocol, service or program used for access, success/failure, login ID or process ID, IP address and ports (source and destination) involved

Required Fields

sec.mon.002

Monitoring

Security logs must be time synchronised

Security Logs Time Synchronisation

sec.mon.003

Monitoring

The Platform must log all changes to time server source, time, date and time zones

Security Logs Time Synchronisation

sec.mon.004

Audit

The Platform must secure and protect Audit logs (containing sensitive information) both in-transit and at rest

Security LCM

sec.mon.005

Monitoring / Audit

The Platform must Monitor and Audit various behaviours of connection and login attempts to detect access attacks and potential access attempts and take corrective accordingly actions

What to Log / What NOT to Log

sec.mon.006

Monitoring / Audit

The Platform must Monitor and Audit operations by authorised account access after login to detect malicious operational activity and take corrective actions

Monitoring and Security Audit

sec.mon.007

Monitoring / Audit

The Platform must Monitor and Audit security parameter configurations for compliance with defined security policies

Integrity of OpenStack components configuration

sec.mon.008

Monitoring / Audit

The Platform must Monitor and Audit externally exposed interfaces for illegal access (attacks) and take corrective security hardening measures

Confidentiality and Integrity of communications (sec.ci.001)

sec.mon.009

Monitoring / Audit

The Platform must Monitor and Audit service for various attacks (malformed messages, signalling flooding and replaying, etc.) and take corrective actions accordingly

Monitoring and Security Audit

sec.mon.010

Monitoring / Audit

The Platform must Monitor and Audit running processes to detect unexpected or unauthorised processes and take corrective actions accordingly

Monitoring and Security Audit

sec.mon.011

Monitoring / Audit

The Platform must Monitor and Audit logs from infrastructure elements and workloads to detected anomalies in the system components and take corrective actions accordingly

Creating Logs

sec.mon.012

Monitoring / Audit

The Platform must Monitor and Audit Traffic patterns and volumes to prevent malware download attempts

Confidentiality and Integrity

sec.mon.013

Monitoring

The monitoring system must not affect the security (integrity and confidentiality) of the infrastructure, workloads, or the user data (through back door entries)

Not detailed

sec.mon.015

Monitoring

The Platform must ensure that the Monitoring systems are never starved of resources and must activate alarms when resource utilisation exceeds a configurable threshold

Monitoring and Security Audit

sec.mon.017

Audit

The Platform must audit systems for any missing security patches and take appropriate actions

Patches

sec.mon.018

Monitoring

The Platform, starting from initialisation, must collect and analyse logs to identify security events, and store these events in an external system

Where to Log

sec.mon.019

Monitoring

The Platform’s components must not include an authentication credential, e.g., password, in any logs, even if encrypted

What to Log / What NOT to Log

sec.mon.020

Monitoring / Audit

The Platform’s logging system must support the storage of security audit logs for a configurable period of time

Data Retention

sec.mon.021

Monitoring

The Platform must store security events locally if the external logging system is unavailable and shall periodically attempt to send these to the external logging system until successful

Where to Log

2.1.9.8. Open-Source Software Security Requirements

Table 2.18 Reference Model Requirements - Open-Source Software Security Requirements

Reference

sub-category

Description

Specification Reference

sec.oss.001

Software

Open-source code must be inspected by tools with various capabilities for static and dynamic code analysis

Image Security

sec.oss.002

Software

The CVE (Common Vulnerabilities and Exposures) must be used to identify vulnerabilities and their severity rating for open-source code part of Cloud Infrastructure and workloads software

Patches

sec.oss.003

Software

Critical and high severity rated vulnerabilities must be fixed in a timely manner. Refer to the CVSS (Common Vulnerability Scoring System) to know a vulnerability score and its associated rate (low, medium, high, or critical)

Patches

sec.oss.004

Software

A dedicated internal isolated repository separated from the production environment must be used to store vetted open-source content

Workload Security

2.1.9.9. IaaC security Requirements

Secure Code Stage Requirements

Table 2.19 Reference Model Requirements: IaaC Security Requirements, Secure Code Stage

Reference

sub-category

Description

Specification Reference

sec.code.001

IaaC

SAST -Static Application Security Testing must be applied during Secure Coding stage triggered by Pull, Clone or Comment trigger. Security testing that analyses application source code for software vulnerabilities and gaps against bestpractices. Example: open source OWASP range of tools

Workload Security

Continuous Build, Integration and Testing Stage Requirements

Table 2.20 Reference Model Requirements - IaaC Security Requirements, Continuous Build, Integration and Testing Stage

Reference

sub-category

Description

Specification Reference

sec.bld.003

IaaC

Image Scan must be applied during the Continuous Build, Integration and Testing stage triggered by Package trigger, example: A push of a container image to a containerregistry may trigger a vulnerability scan before the image becomes available in the registry

Image Security

Continuous Delivery and Deployment Stage Requirements

Table 2.21 Reference Model Requirements - IaaC Security Requirements, Continuous Delivery and Deployment Stage

Reference

sub-category

Description

Specification Reference

sec.del.001

IaaC

Image Scan must be applied during the Continuous Delivery and Deployment stage triggered by Publish to Artifact and Image Repository trigger. Example: GitLab uses the open source Clair engine for container image scanning

Image Security

sec.del.002

IaaC

Code Signing must be applied during the Continuous Deliveryand Deployment stage and Image Repository trigger. Code Signing provides authentication to assure that downloaded files are form the publisher named on the certificate

Image Security

sec.del.004

IaaC

Component Vulnerability Scan must be applied during the Continuous Delivery and Deployment stage triggered by Instantiate Infrastructure trigger. The vulnerability scanning system is deployed on the cloud platform to detect security vulnerabilities of specified components through scanning and to provide timely security protection. Example: OWASP Zed Attack Proxy (ZAP)

Image Security

Runtime Defence and Monitoring Requirements

Table 2.22 Reference Model Requirements - IaaC Security Requirements, Runtime Defence and Monitoring Stage

Reference

sub-category

Description

Specification Reference

sec.run.001

IaaC

Component Vulnerability Monitoring must be continuously applied during the Runtime Defence and monitoring stage. Security technology that monitors components like virtual servers and assesses data, applications, and infrastructure forsecurity risks

Not detailed

2.1.9.10. Compliance with Standards Requirements

Table 2.23 Reference Model Requirements: Compliance with Standards

Reference

sub-category

Description

Specification Reference

sec.std.012

Standards

The Public Cloud Operator must, and the Private Cloud Operator may be certified to be compliant with the International Standard on Awareness Engagements (ISAE) 3402 (in the US:SSAE 16); International Standard on Awareness Engagements (ISAE) 3402. US Equivalent: SSAE16

Not detailed

2.2. Architecture and OpenStack Requirements

“Architecture” in this chapter refers to Cloud Infrastructure (referred to as NFVI by ETSI) and VIM, as specified in Reference Model Chapter 3.

2.2.1. General Requirements

Table 2.24 General Requirements

Reference

sub-category

Description

Specification Reference

gen.ost.01

Open source

The Architecture must use OpenStack APIs

Consolidated Set of APIs

gen.ost.02

Open source

The Architecture must support dynamic request and configuration of virtual resources (compute, network, storage) through OpenStack APIs

Consolidated Set of APIs

gen.rsl.01

Resiliency

The Architecture must support resilient OpenStack components that are required for the continued availability of running workloads

Containerised OpenStack Services

gen.avl.01

Availability

The Architecture must provide High Availability for OpenStack components

Underlying Resources Configuration and Dimensioning

2.2.2. Infrastructure Requirements

Table 2.25 Infrastructure Requirements

Reference

sub-category

Description

Specification Reference

inf.com.01

Compute

The Architecture must provide compute resources for instances

Cloud Workload Services

inf.com.04

Compute

The Architecture must be able to support multiple CPU type options to support various infrastructure profiles (Basic and High Performance)

Support for Cloud Infrastructure Profiles and flavors

inf.com.05

Compute

The Architecture must support Hardware Platforms with NUMA capabilities

Support for Cloud Infrastructure Profiles and flavors

inf.com.06

Compute

The Architecture must support CPU Pinning of the vCPUs of an instance

Support for Cloud Infrastructure Profiles and flavors

inf.com.07

Compute

The Architecture must support different hardware configurations to support various infrastructure profiles (Basic and High Performance)

Cloud partitioning: Host Aggregates, Availability Zones

inf.com.08

Compute

The Architecture must support allocating certain number of host cores for all non-tenant workloads such as for OpenStack services. SMT threads can be allocated to individual OpenStack services or their components. Dedicating host cores to certain workloads (e.g., OpenStack services) [10]. Please see example, Configuring libvirt compute nodes for CPU pinning [11]

Cloud partitioning: Host Aggregates, Availability Zones

inf.com.09

Compute

The Architecture must ensure that the host cores assigned to non-tenant and tenant workloads are SMT aware: that is, a host core and its associated SMT threads are either all assigned to non-tenant workloads or all assigned to tenant workloads

Pinned and Unpinned CPUs

inf.stg.01

Storage

The Architecture must provide remote (not directly attached to the host) Block storage for Instances

Storage

inf.stg.02

Storage

The Architecture must provide Object storage for Instances. Operators may choose not to implement Object Storage but must be cognizant of the the risk of “Compliant VNFs” failing in their environment

Swift

inf.nw.01

Network

The Architecture must provide virtual network interfaces to instances

Neutron API

inf.nw.02

Network

The Architecture must include capabilities for integrating SDN controllers to support provisioning of network services, from the SDN OpenStack Neutron service, such as networking of VTEPs to the Border Edge based VRFs

Virtual Networking - 3rd party SDN solution

inf.nw.03

Network

The Architecture must support low latency and high throughput traffic needs

Network Fabric

inf.nw.05

Network

The Architecture must allow for East/West tenant traffic within the cloud (via tunnelled encapsulation overlay such as VXLAN or Geneve)

Network Fabric

inf.nw.07

Network

The Architecture must support network resiliency

Network

inf.nw.10

Network

The Cloud Infrastructure Network Fabric must be capable of enabling highly available (Five 9’s or better) Cloud Infrastructure

Network

inf.nw.15

Network

The Architecture must support multiple networking options for Cloud Infrastructure to support various infrastructure profiles (Basic and High Performance)

Neutron Extensions and OpenStack Neutron Plugins [12]

inf.nw.16

Network

The Architecture must support dual stack IPv4 and IPv6 for tenant networks and workloads

Not detailed

2.2.3. VIM Requirements

Table 2.26 VIM Requirements

Reference

sub-category

Description

Specification Reference

vim.01

General

The Architecture must allow infrastructure resource sharing

Resources and Services exposed to VNFs

vim.03

General

The Architecture must allow VIM to discover and manage Cloud Infrastructure resources

Placement API

vim.05

General

The Architecture must include image repository management

Glance API

vim.07

General

The Architecture must support multi-tenancy

Multi-Tenancy (execution environment)

vim.08

General

The Architecture must support resource tagging

OpenStack Resource Tags [13]

2.2.4. Interfaces & APIs Requirements

Table 2.27 Interfaces and APIs Requirements

Reference

sub-category

Description

Specification Reference

int.api.01

API

The Architecture must provide APIs to access the authentication service and the associated mandatory features detailed in chapter 5

Keystone API

int.api.02

API

The Architecture must provide APIs to access the image management service and the associated mandatory features detailed in chapter 5

Glance API

int.api.03

API

The Architecture must provide APIs to access the block storage management service and the associated mandatory features detailed in chapter 5

Cinder API

int.api.04

API

The Architecture must provide APIs to access the object storage management service and the associated mandatory features detailed in chapter 5

Swift API

int.api.05

API

The Architecture must provide APIs to access the network management service and the associated mandatory features detailed in chapter 5

Neutron API

int.api.06

API

The Architecture must provide APIs to access the compute resources management service and the associated mandatory features detailed in chapter 5

Nova API

int.api.07

API

The Architecture must provide GUI access to tenant facing cloud platform core services except at Edge/Far Edge clouds

Horizon

int.api.08

API

The Architecture must provide APIs needed to discover and manage Cloud Infrastructure resources

Placement API

int.api.09

API

The Architecture must provide APIs to access the orchestration service

Heat API

int.api.10

API

The Architecture must expose the latest version and microversion of the APIs for the given Anuket OpenStack release for each of the OpenStack core services

Core OpenStack Services APIs

2.2.5. Tenant Requirements

Table 2.28 Tenant Requirements

Reference

sub-category

Description

Specification Reference

tnt.gen.01

General

The Architecture must support self-service dashboard (GUI) and APIs for users to deploy, configure and manage their workloads

Horizon and Cloud Workload Services

2.2.6. Operations and LCM

Table 2.29 LCM Requirements

Reference

sub-category

Description

Specification Reference

lcm.gen.01

General

The Architecture must support zero downtime of running workloads when the number of compute hosts and/or the storage capacity is being expanded or unused capacity is being removed

Not detailed

lcm.adp.02

Automated deployment

The Architecture must support upgrades of software, provided by the cloud provider, so that the running workloads are not impacted (viz., hitless upgrades). Please note that this means that the existing data plane services should not fail (go down)

Containerised OpenStack Services

2.2.7. Assurance Requirements

Table 2.30 Assurance Requirements

Reference

sub-category

Description

Specification Reference

asr.mon.01

Integration

The Architecture must include integration with various infrastructure components to support collection of telemetry for assurance monitoring and network intelligence

Logging, Monitoring and Analytics

asr.mon.03

Monitoring

The Architecture must allow for the collection and dissemination of performance and fault information

Logging, Monitoring and Analytics

asr.mon.04

Network

The Cloud Infrastructure Network Fabric and Network Operating System must provide network operational visibility through alarming and streaming telemetry services for operational management, engineering planning, troubleshooting, and network performance optimisation

Logging, Monitoring and Analytics

2.2.8. Architecture and OpenStack Recommendations

The requirements listed in this section are optional, and are not required in order to be deemed a conformant implementation.

2.2.9. General Recommendations

Table 2.31 General Recommendations

Reference

sub-category

Description

Notes

gen.cnt.01

Cloud nativeness

The Architecture should consist of stateless service components. However, where state is required it must be kept external to the component

OpenStack consists of both stateless and stateful services where the stateful services utilise a database. For latter see Configuring the stateful services [14]

gen.cnt.02

Cloud nativeness

The Architecture should consist of service components implemented as microservices that are individually dynamically scalable

gen.scl.01

Scalability

The Architecture should support policy driven auto-scaling.

This requirement is currently not addressed but will likely be supported through Senlin [15], cluste management service

gen.rsl.02

Resiliency

The Architecture should support resilient OpenStack service components that are not subject to gen.rsl.01

2.2.10. Infrastructure Recommendations

Table 2.32 Infrastructure Recommendations

Reference

sub-category

Description

Notes

inf.com.02

Compute

The Architecture should include industry standard hardware management systems at both HW device level (embedded) and HW platform level (external to device)

inf.com.03

Compute

The Architecture should support Symmetric Multiprocessing with shared memory access as well as Simultaneous Multithreading

inf.stg.08

Storage

The Architecture should allow use of externally provided large archival storage for its Backup / Restore / Archival needs

inf.stg.09

Storage

The Architecture should make available all non-host OS / Hypervisor / Host systems storage as network-based Block, File or Object Storage for tenant/management consumption

inf.stg.10

Storage

The Architecture should provide local Block storage for Instances

Virtual Storage

inf.nw.04

Network

The Architecture should support service function chaining

inf.nw.06

Network

The Architecture should support Distributed Virtual Routing (DVR) to allow compute nodes to route traffic efficiently

inf.nw.08

Network

The Cloud Infrastructure Network Fabric should embrace the concepts of open networking and disaggregation using commodity networking hardware and disaggregated Network Operating Systems

inf.nw.09

Network

The Cloud Infrastructure Network Fabric should embrace open-based standards and technologies

inf.nw.11

Network

The Cloud Infrastructure Network Fabric should be architected to provide a standardised, scalable, and repeatable deployment model across all applicable Cloud Infrastructure sites

inf.nw.17

Network

The Architecture should use dual stack IPv4 and IPv6 for Cloud Infrastructure internal networks

inf.acc.01

Acceleration

The Architecture should support Application Specific Acceleration (exposed to VNFs)

Acceleration

inf.acc.02

Acceleration

The Architecture should support Cloud Infrastructure Acceleration (such as SmartNICs)

OpenStack Future - Specs defined [16]

inf.acc.03

Acceleration

The Architecture may rely on on SR-IOV PCI-Pass through to provide acceleration to VNFs

inf.img.01

Image

The Architecture should make the immutable images available via location independent means

Glance

2.2.11. VIM Recommendations

Table 2.33 VIM Recommendations

Reference

sub-category

Description

Notes

vim.02

General

The Architecture should support deployment of OpenStack components in containers

Containerised OpenStack Services

vim.04

General

The Architecture should support Enhanced Platform Awareness (EPA) only for discovery of infrastructure resource capabilities

vim.06

General

The Architecture should allow orchestration solutions to be integrated with VIM

vim.09

General

The Architecture should support horizontal scaling of OpenStack core services

2.2.12. Interfaces and APIs Recommendations

Table 2.34 Interfaces and APIs Recommendations

Reference

sub-category

Description

Notes

int.acc.01

Acceleration

The Architecture should provide an open and standard acceleration interface to VNFs

int.acc.02

Acceleration

The Architecture should not rely on SR-IOV PCI-Pass through for acceleration interface exposed to VNFs

duplicate of inf.acc.03 under “Infrastructure Recommendation”

2.2.13. Tenant Recommendations

This section is left blank for future use.

2.2.14. Operations and LCM Recommendations

Table 2.35 LCM Recommendations

Reference

sub-category

Description

Notes

lcm.adp.01

Automated deployment

The Architecture should allow for cookie cutter automated deployment, configuration, provisioning and management of multiple Cloud Infrastructure sites

lcm.adp.03

Automated deployment

The Architecture should support hitless upgrade of all software provided by the cloud provider that are not covered by lcm.adp.02. Whenever hitless upgrades are not feasible, attempt should be made to minimise the duration and nature of impact

lcm.adp.04

Automated deployment

The Architecture should support declarative specifications of hardware and software assets for automated deployment, configuration, maintenance and management

lcm.adp.05

Automated deployment

The Architecture should support automated process for Deployment and life-cycle management of VIM Instances

lcm.cid.02

CI/CD

The Architecture should support integrating with CI/CD Toolchain for Cloud Infrastructure and VIM components Automation

2.2.15. Assurance Recommendations

Table 2.36 Assurance Recommendations

Reference

sub-category

Description

Notes

asr.mon.02

Monitoring

The Architecture should support Network Intelligence capabilities that allow richer diagnostic capabilities which take as input broader set of data across the network and from VNF workloads

2.2.16. Security Recommendations

2.2.16.1. System Hardening Recommendations

Table 2.37 System Hardening Recommendations

Reference

sub-category

Description

Notes

sec.gen.011

Hardening

The Cloud Infrastructure should support Read and Write only storage partitions (write only permission to one or more authorised actors)

sec.gen.014

Hardening

All servers part of Cloud Infrastructure should support measured boot and an attestation server that monitors the measurements of the servers

2.2.16.2. Platform and Access Recommendations

Table 2.38 Platform and Access Recommendations

Reference

sub-category

Description

Notes

sec.sys.014

Access

The Platform should use Linux Security Modules such as SELinux to control access to resources

sec.sys.020

Access

The Cloud Infrastructure architecture should rely on Zero Trust principles to build a secure by design environment

Zero Trust Architecture (ZTA) described in NIST SP 800-207

2.2.16.3. Confidentiality and Integrity Recommendations

Table 2.39 Confidentiality and Integrity Recommendations

Reference

sub-category

Description

Notes

sec.ci.002

Confidentiality /

Integrity

The Platform should support self-encrypting storage devices

sec.ci.009

Confidentiality /

Integrity

For sensitive data encryption, the key management service should leverage a Hardware Security Module to manage and protect cryptographic keys

2.2.16.4. Workload Security Recommendations

Table 2.40 Workload Security Recommendations

Reference

sub-category

Description

Notes

sec.wl.007

Workload

The Operator should implement processes and tools to verify VNF authenticity and integrity

2.2.16.5. Image Security Recommendations

Table 2.41 Image Security Recommendations

Reference

sub-category

Description

Notes

sec.img.009

Image

CIS Hardened Images should be used whenever possible

sec.img.010

Image

Minimalist base images should be used whenever possible

2.2.16.6. Security LCM Recommendations

Table 2.42 LCM Security Recommendations

Reference

sub-category

Description

Notes

sec.lcm.004

LCM

The Cloud Operator should support automated templated approved changes; Templated approved changes for automation where available

2.2.16.7. Monitoring and Security Audit Recommendations

The Platform is assumed to provide configurable alerting and notification capability and the operator is assumed to have automated systems, policies and procedures to act on alerts and notifications in a timely fashion. In the following the monitoring and logging capabilities can trigger alerts and notifications for appropriate action.

Table 2.43 Monitoring and Security Audit Recommendations

Reference

sub-category

Description

Notes

sec.mon.014

Monitoring

The Monitoring systems should not impact IaaS, PaaS, and SaaS SLAs including availability SLAs

sec.mon.016

Monitoring

The Platform Monitoring components should follow security best practices for auditing, including secure logging and tracing

2.2.16.8. Open-Source Software Security Recommendations

Table 2.44 Open-Source Software Security Recommendations

Reference

sub-category

Description

Notes

sec.oss.005

Software

A Software Bill of Materials (SBOM) should be provided or build, and maintained to identify the software components and their origins. Inventory of software components

NTIA SBOM [17]

2.2.16.9. IaaC security Recommendations

Secure Design and Architecture Stage

Table 2.45 Reference Model Requirements: IaaC Security, Design and Architecture Stage

Reference

sub-category

Description

Notes

sec.arch.001

IaaC

Threat Modelling methodologies and tools should be used during the Secure Design and Architecture stage triggered by Software Feature Design trigger. Methodology to identify and understand threats impacting a resource or set of resources

It may be done manually or using tools like open source OWASP Threat Dragon

sec.arch.002

IaaC

Security Control Baseline Assessment should be performed during the Secure Design and Architecture stage triggered by Software Feature Design trigger

Typically done manually by internal or independent assessors

Secure Code Stage Recommendations

Table 2.46 Reference Model Requirements: IaaC Security, Secure Code Stage

Reference

sub-category

Description

Notes

sec.code.002

IaaC

SCA - Software Composition Analysis should be applied during Secure Coding stage triggered by Pull, Clone or Comment trigger. Security testing that analyses application source code or compiled code for software components with known vulnerabilities

Example: open source OWASP range of tools

sec.code.003

IaaC

Source Code Review should be performed continuously during Secure Coding stage.

Typically done manually.

sec.code.004

IaaC

Integrated SAST via IDE Plugins should be used during Secure Coding stage triggered by Developer Code trigger. On the local machine: through the IDE or integrated test suites; triggered on completion of coding by developer

sec.code.005

IaaC

SAST of Source Code Repo should be performed during Secure Coding stage triggered by Developer Code trigger. Continuous delivery pre -deployment: scanning prior to deployment

Continuous Build, Integration and Testing Stage Recommendations

Table 2.47 Reference Model Requirements: IaaC Security, Continuous Build, Integration and Testing Stage

Reference

sub-category

Description

Notes

sec.bld.001

IaaC

SAST -Static Application Security Testing should be applied during the Continuous Build, Integration and Testing stage triggered by Build and Integrate trigger

Example: open source OWASP range of tools.

sec.bld.002

IaaC

SCA - Software Composition Analysis should be applied during the Continuous Build, Integration and Testing stage triggered by Build and Integrate trigger

Example: open source OWASP range of tools

sec.bld.004

IaaC

SDAST - Dynamic Application Security Testing should be applied during the Continuous Build, Integration and Testing stage triggered by Stage & Test trigger. Security testing that analyses a running application by exercising application functionality and detecting vulnerabilities based on application behaviour and response

Example: OWASP ZAP

sec.bld.005

IaaC

Fuzzing should be applied during the Continuous Build, Integration and testing stage triggered by Stage & Test trigger. Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program

Example: GitLab Open Sources Protocol Fuzzer Community Edition

sec.bld.006

IaaC

IAST - Interactive Application Security Testing should be applied during the Continuous Build, Integration and Testing stage triggered by Stage & Test trigger. Software component deployed with an application that assesses application behaviour and detects presence of vulnerabilities on an application being exercised in realistic testing scenarios

Example: Contrast Community Edition

Continuous Delivery and Deployment Stage Recommendations

Table 2.48 Reference Model Requirements: IaaC Security, Continuous Delivery and Deployment Stage

Reference

sub-category

Description

Notes

sec.del.003

IaaC

Artifact and Image Repository Scan should be continuously applied during the Continuous Delivery and Deployment stage

Example: GitLab uses the open source Clair engine for container scanning

Runtime Defence and Monitoring Recommendations

Table 2.49 Reference Model Requirements: Iaac Security, Runtime Defence and Monitoring Stage

Reference

sub-category

Description

Notes

sec.run.002

IaaC

RASP - Runtime Application Self-Protection should be continuously applied during the Runtime Defence and Monitoring stage. Security technology deployed within the target application in production for detecting, alerting, and blocking attacks

sec.run.003

IaaC

Application testing and Fuzzing should be continuously applied during the Runtime Defence and Monitoring stage. Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program

Example: GitLab Open Sources Protocol Fuzzer Community Edition

sec.run.004

IaaC

Penetration Testing should be continuously applied during the Runtime Defence and Monitoring stage

Typically done manually

2.2.16.10. Compliance with Standards Recommendations

Table 2.50 Compliance with Security Recommendations

Reference

sub-category

Description

Notes

sec.std.001

Standards

The Cloud Operator should comply with Center for Internet Security CIS Controls [18]

sec.std.002

Standards

The Cloud Operator, Platform and Workloads should follow the guidance in the CSA Security Guidance for Critical Areas of Focus in Cloud Computing (latest version)- CSA, Cloud Security Alliance [19]

sec.std.003

Standards

The Platform and Workloads should follow the guidance in the OWASP Cheat Sheet Series (OCSS) [20] - OWASP, Open Web Application Security Project [21]

sec.std.004

Standards

The Cloud Operator, Platform and Workloads should ensure that their code is not vulnerable to the OWASP Top Ten Security Risks [22]

sec.std.005

Standards

The Cloud Operator, Platform and Workloads should strive to improve their maturity on the OWASP Software Maturity Model (SAMM) [23]

sec.std.006

Standards

The Cloud Operator, Platform and Workloads should utilise the OWASP Web Security Testing Guide [24]

sec.std.007

Standards

The Cloud Operator, and Platform should satisfy the requirements for Information Management Systems specified in ISO/IEC 27001 [25]; ISO/IEC 27001 is the international Standard for best-practice information security management systems (ISMSs)

sec.std.008

Standards

The Cloud Operator, and Platform should implement the Code of practice for Security Controls specified ISO/IEC 27002:2013 (or latest) [26]

sec.std.009

Standards

The Cloud Operator, and Platform should implement the ISO/IEC 27032:2012 (or latest) Guidelines for Cybersecurity techniques [27]; ISO/IEC 27032 is the international Standard focusing explicitly on cybersecurity

sec.std.010

Standards

The Cloud Operator should conform to the ISO/IEC 27035 standard for incidence management; ISO/IEC 27035 is the international Standard for incident management

sec.std.011

Standards

The Cloud Operator should conform to the ISO/IEC 27031 standard for business continuity; ISO/IEC 27031 - ISO/IEC 27031 is the international Standard for ICT readiness for business continuity