Table 2-1a: Reference Model Requirements: Cloud Infrastructure Software Profile Capabilities
> **1** Defined in the `.bronze` configuration in [RM section 4.2.6 Storage Extensions](../../../ref_model/chapters/chapter04.md#4.2.6)Table 2-1b: Cloud Infrastructure Software Profile Extensions Requirements for Compute
### 2.2.2 Cloud Infrastructure Software Profile Requirements for Netwokring (source [RM 5.2.3](../../../ref_model/chapters/chapter05.md#5.2.3)) 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. | 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 | | | 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* | | | infra.net.cfg.003 | Network Address Translation | Must support | Must support | | | infra.net.cfg.004 | Security Groups | Must support | Must support | | | infra.net.cfg.005 | SFC support | Not required | Must support | | | infra.net.cfg.006 | Traffic patterns symmetry | Must support | Must support | |Table 2-2a: Reference Model Requirements - Virtual Networking
The required number of connection points to an instance is described in `e.cap.004` [above](#2.2.1). The table below specifies the required bandwidth of those connection points. | 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 | | | n10, n20, n30, n40, n50, n60 | 10, 20, 30, 40, 50, 60 Gbps | Must support | Must support | | | n25, n50, n75, n100, n125, n150 | 25, 50, 75, 100, 125, 150 Gbps | Optional | Must support | | | n50, n100, n150, n200, n250, n300 | 50, 100, 150, 200, 250, 300 Gbps | Optional | Must support | | | n100, n200, n300, n400, n500, n600 | 100, 200, 300, 400, 500, 600 Gbps | Optional | Must support | |Table 2-2b: Reference Model Requirements - Network Interface Specifications
### 2.2.2.1 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 | | | e.cap.019/ infra.net.acc.cfg.001 | vSwitch optimisation (DPDK) | N | Y | | | e.cap.015/ infra.net.acc.cfg.002 | SmartNIC (for HW Offload) | N | Optional | | | e.cap.009/ infra.net.acc.cfg.003 | Crypto acceleration | N | Optional | | | infra.net.acc.cfg.004 | Crypto Acceleration Interface | N | Optional | |Table 2-2c: Cloud Infrastructure Software Profile Extensions Requirements for Networking
### 2.2.3 Cloud Infrastructure Software Profile Requirements for Storage (source [RM 5.2](../../../ref_model/chapters/chapter05.md#5.2)) | Reference | Description | Requirement for Basic Profile | Requirement for High-Performance Profile| Specification Reference | |---|---|---|---|---| | infra.stg.cfg.002 | Storage Block | Must support | Must support | | | infra.stg.cfg.003 | Storage with replication | Not required | Must support | | | infra.stg.cfg.004 | Storage with encryption | Must support | Must support | | | infra.stg.acc.cfg.001 | Storage IOPS oriented | Not required | Must support | | | infra.stg.acc.cfg.002 | Storage capacity oriented | Not required | Not required | |Table 2-3a: Reference Model Requirements - Cloud Infrastructure Software Profile Requirements for Storage
### 2.2.3.1 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 | | | | infra.stg.acc.cfg.002 | Storage capacity oriented | High Capacity | | |Table 2-3b: Reference Model Requirements - Cloud Infrastructure Software Profile Extensions Requirements for Storage
### 2.2.4 Cloud Infrastructure Hardware Profile Requirements (source [RM 5.4](../../../ref_model/chapters/chapter05.md#5.4)) | 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 | | | infra.hw.cpu.cfg.002 | Minimum number of Cores per CPU | 20 | 20 | | | infra.hw.cpu.cfg.003 | NUMA | Not required | Must support | | | infra.hw.cpu.cfg.004 | Simultaneous Multithreading/Symmetric Multiprocessing (SMT/SMP) | Must support | Optional | | | infra.hw.stg.hdd.cfg.001 | Local Storage HDD | *No requirement specified* | *No requirement specified* | | | infra.hw.stg.ssd.cfg.002 | Local Storage SSD | Should support | Should support | | | infra.hw.nic.cfg.001 | Total Number of NIC Ports available in the host | 4 | 4 | | | infra.hw.nic.cfg.002 | Port speed specified in Gbps (minimum values) | 10 | 25 | | | infra.hw.pci.cfg.001 | Number of PCIe slots available in the host | 8 | 8 | | | infra.hw.pci.cfg.002 | PCIe speed | Gen 3 | Gen 3 | | | infra.hw.pci.cfg.003 | PCIe Lanes | 8 | 8 | | | infra.hw.nac.cfg.003 | Compression | *No requirement specified* | *No requirement specified* | |Table 2-4a: Reference Model Requirements - Cloud Infrastructure Hardware Profile Requirements
#### 2.2.4.1 Cloud Infrastructure Hardware Profile-Extensions Requirements (source [RM 5.4](../../../ref_model/chapters/chapter05.md#5.4)) | Reference | Description | Requirement for Basic Profile | Requirement for High-Performance Profile| Specification Reference | |---|---|---|---|---| | e.cap.014/ infra.hw.cac.cfg.001 | GPU | N | Optional | | | e.cap.016/ infra.hw.cac.cfg.002 |FPGA/other Acceleration H/W | N | Optional | | | e.cap.009/ infra.hw.nac.cfg.001 | Crypto Acceleration | N | Optional | | | e.cap.015/ infra.hw.nac.cfg.002 | SmartNIC | N | Optional | | | infra.hw.nac.cfg.003 | Compression | Optional | Optional | | | e.cap.013/ infra.hw.nac.cfg.004 | SR-IOV over PCI-PT | N | Yes | |Table 2-4b: Reference Model Requirements - Cloud Infrastructure Hardware Profile Extensions Requirements
### 2.2.5 Cloud Infrastructure Management Requirements (source [RM 4.1.5](../../../ref_model/chapters/chapter04.md#415-cloud-infrastructure-management-capabilities)) | Reference | Description | Requirement (common to all Profiles) | Specification Reference | |---|---|---|---| | e.man.001 | Capability to allocate virtual compute resources to a workload | Must support | | | e.man.002 | Capability to allocate virtual storage resources to a workload | Must support | | | e.man.003 | Capability to allocate virtual networking resources to a workload | Must support | | | e.man.004 | Capability to isolate resources between tenants | Must support | | | e.man.005 | Capability to manage workload software images | Must support | | | e.man.006 | Capability to provide information related to allocated virtualised resources per tenant | Must support | | | e.man.007 | Capability to notify state changes of allocated resources | Must support | | | e.man.008 | Capability to collect and expose performance information on virtualised resources allocated | Must support | | | e.man.009 | Capability to collect and notify fault information on virtualised resources | Must support | |Table 2-5: Reference Model Requirements: Cloud Infrastructure Management Requirements
### 2.2.6 Cloud Infrastructure Security Requirements #### 2.2.6.1. System Hardening (source [RM 7.9.1](../../../ref_model/chapters/chapter07.md#791-system-hardening)) | Reference | sub-category | Description | Specification Reference | |-------|------|------|-------| | sec.gen.001 | Hardening | The Platform **must** maintain the specified configuration. | [RA-1 6.3.6 "Security LCM"](./chapter06.md#636-security-lcm), [RA-1 7.2 "Cloud Infrastructure and VIM configuration management"](./chapter07.md#72-cloud-infrastructure-and-vim-configuration-management) | | sec.gen.002 | Hardening | All systems part of Cloud Infrastructure **must** support password hardening as defined in [CIS Password Policy Guide](https://www.cisecurity.org/white-papers/cis-password-policy-guide/). | [RA-1 6.3.1.3 "Password policy"](./chapter06.md#6313-password-policy) | | sec.gen.003 | Hardening | All servers part of Cloud Infrastructure **must** support a root of trust and secure boot. | [RA-1 6.3.1.1 "Server boot hardening"](./chapter06.md#6311-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). | [RA-1 6.3.1.4 "Function and Software"](./chapter06.md#6314-function-and-software) | | sec.gen.005 | Hardening | The Platform **must** support Operating System level access control. | [RA-1 6.3.1.2 "System Access"](./chapter06.md#6312-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. | [RA-1 6.3.1.2 "System Access"](./chapter06.md#6312-system-access) | | sec.gen.007 | Hardening | All servers part of Cloud Infrastructure **must** be Time synchronised with authenticated Time service. | [RA-1 6.3.7.6 "Security Logs Time Synchronisation"](./chapter06.md#6376-security-logs-time-synchronisation) | | sec.gen.008 | Hardening | All servers part of Cloud Infrastructure **must** be regularly updated to address security vulnerabilities. | [RA-1 6.3.1.5 "Patches"](./chapter06.md#6315-patches), [RA-1 6.3.6 "Security LCM"](./chapter06.md#636-security-lcm) | | sec.gen.009 | Hardening | The Platform **must** support software integrity protection and verification. | [RA-1 6.3.3.2 "Integrity of OpenStack components configuration"](./chapter06.md#6332-integrity-of-openstack-components-configuration), [RA-1 6.3.5 "Image Security"](./chapter06.md#635-image-security) | | 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](https://www.cisecurity.org/controls/controlled-access-based-on-the-need-to-know/)). | [RA-1 6.3.3.3 "Confidentiality and Integrity of tenant data"](./chapter06.md#6333-confidentiality-and-integrity-of-tenant-data-secmon012-and-secmon013) | | sec.gen.012 | Hardening | The Operator **must** ensure that only authorised actors have physical access to the underlying infrastructure. | This requirement’s verification goes beyond Anuket testing scope | | sec.gen.013 | Hardening | The Platform **must** ensure that only authorised actors have logical access to the underlying infrastructure. | [RA-1 6.3.1.2 "System Access"](./chapter06.md#6312-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. | [RA-1 6.3.6 "Security LCM"](./chapter06.md#636-security-lcm) |Table 2-6: Reference Model Requirements - System Hardening Requirements
#### 2.2.6.2. Platform and Access (source [RM 7.9.2](../../../ref_model/chapters/chapter07.md#792-platform-and-access)) | 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 | [RA-1 6.3.2.4 "RBAC"](./chapter06.md#6324-rbac) | | sec.sys.002 | Access | The Platform **must** support Traffic Filtering for workloads (for example, Firewall). | [RA-1 6.3.4 "Workload Security"](./chapter06.md#634-workload-security) | | sec.sys.003 | Access | The Platform **must** support Secure and encrypted communications, and confidentiality and integrity of network traffic. | [RA-1 6.3.3.1 "Confidentiality and Integrity of communications"](./chapter06.md#6331-confidentiality-and-integrity-of-communications) | | sec.sys.004 | Access | The Cloud Infrastructure **must** support authentication, integrity and confidentiality on all network channels. | [RA-1 6.3.3.1 "Confidentiality and Integrity of communications"](./chapter06.md#6331-confidentiality-and-integrity-of-communications)| | sec.sys.005 | Access | The Cloud Infrastructure **must** segregate the underlay and overlay networks. | [RA-1 6.3.3.1 "Confidentiality and Integrity of communications"](./chapter06.md#6331-confidentiality-and-integrity-of-communications) | | sec.sys.006 | Access | The Cloud Infrastructure **must** be able to utilise the Cloud Infrastructure Manager identity lifecycle management capabilities. | [RA-1 6.3.2.1 "Identity Security"](./chapter06.md#6321-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). | [RA-1 6.3.2.4 "RBAC"](./chapter06.md#6324-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.) | [RA-1 6.3.4 "Workload Security"](./chapter06.md#634-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 or to allow access to its resources from the trusted domain. In a bidirectional relationship both domain are “trusting” and “trusted”. | | | 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. | | | 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). | [RA-1 6.3.1.2 "System Access"](./chapter06.md#6312-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) | | | sec.sys.013 | Access | The Platform **must** generate secrets dynamically as and when needed. | | | sec.sys.015 | Access | The Platform **must not** contain back door entries (unpublished access points, APIs, etc.). | | | 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 | [RA-1 6.3.6 "Security LCM"](./chapter06.md#636-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. | [RA-1 6.3.3.1 "Confidentiality and Integrity of communications"](./chapter06.md#6331-confidentiality-and-integrity-of-communications) | | sec.sys.018 | Access | The Platform **must** provide the capability of allowing certificate renewal and revocation. | | | 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). | |Table 2-7: Reference Model Requirements - Platform and Access Requirements
#### 2.2.6.3. Confidentiality and Integrity (source [RM 7.9.3](../../../ref_model/chapters/chapter07.md#793-confidentiality-and-integrity)) | 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. | [RA-1 6.3.3 "Confidentiality and Integrity"](./chapter06.md#633-confidentiality-and-integrity) | | sec.ci.003 | Confidentiality/Integrity | The Platform **must** support Confidentiality and Integrity of data related metadata. | | | sec.ci.004 | Confidentiality | The Platform **must** support Confidentiality of processes and restrict information sharing with only the process owner (e.g., tenant). | | | 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). | | | 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). | | | 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. | | | sec.ci.008 | Confidentiality | The Cloud Infrastructure **must** support tenant networks segregation. | [RA-1 6.3.4 "Workload Security"](./chapter06.md#634-workload-security) |Table 2-8: Reference Model Requirements: Confidentiality and Integrity Requirements
#### 2.2.6.4. Workload Security (source [RM 7.9.4](../../../ref_model/chapters/chapter07.md#794-workload-security)) | Reference | sub-category | Description | Specification Reference | |---|----|---|----| | sec.wl.001 | Workload | The Platform **must** support Workload placement policy. | [RA-1 6.3.4 "Workload Security"](./chapter06.md#634-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). | | | sec.wl.003 | Workload | The Platform **must** support secure provisioning of Workloads. | [RA-1 6.3.4 "Workload Security"](./chapter06.md#634-workload-security) | | sec.wl.004 | Workload | The Platform **must** support Location assertion (for mandated in-country or location requirements). | [RA-1 6.3.4 "Workload Security"](./chapter06.md#634-workload-security) | | sec.wl.005 | Workload | The Platform **must** support the separation of production and non-production Workloads. | This requirement’s verification goes beyond Anuket testing scope | | sec.wl.006 | Workload | The Platform **must** support the separation of Workloads based on their categorisation (for example, payment card information, healthcare, etc.) | [RA-1 6.3.4 "Workload Security"](./chapter06.md#634-workload-security) | | sec.wl.007 | Workload |The Operator **must** implement processes and tools to verify NF authenticity and integrity. | |Table 2-9: Reference Model Requirements - Workload Security Requirements
#### 2.2.6.5. Image Security (source [RM 7.9.5](../../../ref_model/chapters/chapter07.md#795-image-security)) | Reference | sub-category | Description | Specification Reference | |---|----|---|----| | sec.img.001 | Image | Images from untrusted sources **must not** be used. | [RA-1 6.3.5 "Image Security"](./chapter06.md#635-image-security) | | sec.img.002 | Image | Images **must** be scanned to be maintained free from known vulnerabilities. | [RA-1 6.3.5 "Image Security"](./chapter06.md#635-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. | | | sec.img.004 | Image | Images **must** only be accessible to authorised actors. | [RA-1 6.3.3.2 "Confidentiality and Integrity of communications"](./chapter06.md#6332-integrity-of-openstack-components-configuration)| | sec.img.005 | Image | Image Registries **must** only be accessible to authorised actors. | [RA-1 6.3.3.2 "Confidentiality and Integrity of communications"](./chapter06.md#6332-integrity-of-openstack-components-configuration) | | sec.img.006 | Image | Image Registries **must** only be accessible over networks that enforce authentication, integrity and confidentiality. | [RA-1 6.3.3.2 "Confidentiality and Integrity of communications"](./chapter06.md#6332-integrity-of-openstack-components-configuration) | | sec.img.007 | Image | Image registries **must** be clear of vulnerable and out of date versions. | [RA-1 6.3.3.2 "Confidentiality and Integrity of communications"](./chapter06.md#6332-integrity-of-openstack-components-configuration), [RA-1 6.3.5 "Image Security"](./chapter06.md#635-image-security) | | sec.img.008 | Image | Images **must not** include any secrets. Secrets include passwords, cloud provider credentials, SSH keys, TLS certificate keys, etc. | |Table 2-10: Reference Model Requirements - Image Security Requirements
#### 2.2.6.6. Security LCM (source [RM 7.9.6](../../../ref_model/chapters/chapter07.md#796-security-lcm)) | 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. | [RA-1 6.3.7 "Monitoring and Security Audit"](./chapter06.md#637-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. | [RA-1 6.3.6 "Security LCM"](./chapter06.md#636-security-lcm) | | sec.lcm.003 | LCM | The Cloud Operator **must** implement and strictly follow change management processes for Cloud Infrastructure, Cloud Infrastructure Manager and other components of the cloud, and Platform change control on hardware. | [RA-1 6.3.7 "Monitoring and Security Audit"](./chapter06.md#637-monitoring-and-security-audit) | | sec.lcm.005 | LCM | Platform **must** provide logs and these logs must be monitored for anomalous behaviour. | [RA-1 6.3.7 "Monitoring and Security Audit"](./chapter06.md#637-monitoring-and-security-audit) | | sec.lcm.006 | LCM | The Platform **must** verify the integrity of all Resource management requests. | [RA-1 6.3.3.3 "Confidentiality and Integrity of tenant data"](./chapter06.md#6333-confidentiality-and-integrity-of-tenant-data-secmon012-and-secmon013) | | sec.lcm.007 | LCM | The Platform **must** be able to update newly instantiated, suspended, hibernated, migrated and restarted images with current time information. | | | sec.lcm.008 | LCM | The Platform **must** be able to update newly instantiated, suspended, hibernated, migrated and restarted images with relevant DNS information. | | | 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. | | | 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). | | | 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. | [RA-1 6.3.1.5 "Patches"](./chapter06.md#6315-patches) | | sec.lcm.012 | LCM | The Platform **must** log any access privilege escalation. | [RA-1 6.3.7.2 "What to Log"](./chapter06.md#6372-what-to-log--what-not-to-log) |Table 2-11: Reference Model Requirements - Security LCM Requirements
#### 2.2.6.7. Monitoring and Security Audit (source [RM 7.9.7](../../../ref_model/chapters/chapter07.md#797-monitoring-and-security-audit)) 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. | 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.| [RA-1 6.3.7.1 "Creating logs"](./chapter06.md#6371-creating-logs), [RA-1 6.3.7.4 "Required Fields"](./chapter06.md#6374-required-fields) | | sec.mon.002 | Monitoring | Security logs **must** be time synchronised. | [RA-1 6.3.7.6 "Security Logs Time Synchronisation"](./chapter06.md#6376-security-logs-time-synchronisation) | | sec.mon.003 | Monitoring | The Platform **must** log all changes to time server source, time, date and time zones. | [RA-1 6.3.7.6 "Security Logs Time Synchronisation"](./chapter06.md#6376-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. | [RA-1 6.3.6 "Security LCM"](./chapter06.md#636-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 actions accordingly | [RA-1 6.3.3.2 "Confidentiality and Integrity of communications"](./chapter06.md#6332-integrity-of-openstack-components-configuration), [RA-1 6.3.7.2 "What to log, what not to log"](./chapter06.md#6372-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. | [RA-1 6.3.3.2 "Integrity of OpenStack components configuration"](./chapter06.md#6332-integrity-of-openstack-components-configuration), [RA-1 6.3.7 "Monitoring and Security Audit"](./chapter06.md#637-monitoring-and-security-audit) | | sec.mon.007 | Monitoring/Audit | The Platform **must** Monitor and Audit security parameter configurations for compliance with defined security policies. | [RA-1 6.3.3.2 "Integrity of OpenStack components configuration"](./chapter06.md#6332-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. | [RA-1 6.3.3.1 "Confidentiality and Integrity of communications"](./chapter06.md#6331-confidentiality-and-integrity-of-communications) | | 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. | [RA-1 6.3.3.2 "Confidentiality and Integrity of communications"](./chapter06.md#6332-integrity-of-openstack-components-configuration), [RA-1 6.3.7 "Monitoring and Security Audit"](./chapter06.md#637-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. | [RA-1 6.3.7 "Monitoring and Security Audit"](./chapter06.md#637-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. | [RA-1 6.3.7.1 "Creating logs"](./chapter06.md#6371-creating-logs) | | sec.mon.012 | Monitoring/Audit | The Platform **must** Monitor and Audit Traffic patterns and volumes to prevent malware download attempts. | [RA-1 6.3.3.3 "Confidentiality and Integrity of tenant data"](./chapter06.md#6333-confidentiality-and-integrity-of-tenant-data-secmon012-and-secmon013) | | 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). | | | 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. | [RA-1 6.3.7 "Monitoring and Security Audit"](./chapter06.md#637-monitoring-and-security-audit) | | sec.mon.017 | Audit | The Platform **must** audit systems for any missing security patches and take appropriate actions. | [RA-1 6.3.1.5 "Patches"](./chapter06.md#6315-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. | [RA-1 6.3.7.3 "Where to Log"](./chapter06.md#6373-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. | [RA-1 6.3.7.2 "What to Log"](./chapter06.md#6372-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. | [RA-1 6.3.7.5 "Data Retention](./chapter06.md#6375-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. | [RA-1 6.3.7.3 "Where to Log"](./chapter06.md#6373-where-to-log) |Table 2-12: Reference Model Requirements - Monitoring and Security Audit Requirements
#### 2.2.6.8. Open-Source Software (source [RM 7.9.8](../../../ref_model/chapters/chapter07.md#798-open-source-sotfware)) | 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. | | | sec.oss.002 | Software | The [CVE (Common Vulnerabilities and Exposures)](https://cve.mitre.org/) **must** be used to identify vulnerabilities and their severity rating for open-source code part of Cloud Infrastructure and workloads software. | | | 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)](https://www.first.org/cvss/) to know a vulnerability score and its associated rate (low, medium, high, or critical). | | | sec.oss.004 | Software | A dedicated internal isolated repository separated from the production environment **must** be used to store vetted open-source content. | |Table 2-13: Reference Model Requirements - Open-Source Software Security Requirements
#### 2.2.6.9. IaaC security (source [RM 7.9.9](../../../ref_model/chapters/chapter07.md#799-iaac---secure-design-and-architecture-stage-requirements)) **Secure Code Stage Requirements** | 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 best practices. Example: open source OWASP range of tools.| |Table 2-14: Reference Model Requirements: IaaC Security Requirements, Secure Code Stage
**Continuous Build, Integration and Testing Stage Requirements** | 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 container registry may trigger a vulnerability scan before the image becomes available in the registry. | |Table 2-15: Reference Model Requirements - IaaC Security Requirements, Continuous Build, Integration and Testing Stage
**Continuous Delivery and Deployment Stage Requirements** | 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.| | | sec.del.002 | IaaC | Code Signing **must** be applied during the Continuous Delivery and Deployment stage triggered by Publish to Artifact and Image Repository trigger. Code Signing provides authentication to assure that downloaded files are form the publisher named on the certificate. | | | 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). | |Table 2-16: Reference Model Requirements - IaaC Security Requirements, Continuous Delivery and Deployment Stage
**Runtime Defence and Monitoring Requirements** | 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 for security risks.| |Table 2-17: Reference Model Requirements - IaaC Security Requirements, Runtime Defence and Monitoring Stage
#### 2.2.6.10. Compliance with Standards (source [RM 7.9.10](../../../ref_model/chapters/chapter07.md#7910-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. | |Table 2-18: Reference Model Requirements: Cloud Infrastructure Security Requirements
## 2.3 Architecture and OpenStack Requirements "Architecture" in this chapter refers to Cloud Infrastructure (referred to as NFVI by ETSI) + VIM (as specified in Reference Model Chapter 3). ### 2.3.1 General Requirements | Reference | sub-category | Description | Specification Reference | |----|---------------|---------------------|---------------| | gen.ost.01 | Open source | The Architecture **must** use OpenStack APIs.| [RA-1 5.3](./chapter05.md#5.3) | | gen.ost.02 | Open source | The Architecture **must** support dynamic request and configuration of virtual resources (compute, network, storage) through OpenStack APIs. | [RA-1 5.3](./chapter05.md#53-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. | | | gen.avl.01 | Availability | The Architecture **must** provide High Availability for OpenStack components. | [RA-1 4.2 "Underlying Resources"](./chapter04.md#42-underlying-resources) |Table 2-19: General Requirements
### 2.3.2 Infrastructure Requirements | Reference | sub-category | Description | Specification Reference | |----|--------------|---------------------|-----------| | inf.com.01 | Compute | The Architecture **must** provide compute resources for instances. | [RA-1 3.3.1.4 "Cloud Workload Services"](./chapter03.md#3314-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).| [RA-1 4.4.1. "Support for Cloud Infrastructure Profiles and flavors"](./chapter04.md#4.4.1) | | inf.com.05 | Compute | The Architecture **must** support Hardware Platforms with NUMA capabilities.| [RA-1 4.4.1. "Support for Cloud Infrastructure Profiles and flavors"](./chapter04.md#4.4.1) | | inf.com.06 | Compute | The Architecture **must** support CPU Pinning of the vCPUs of an instance.| [RA-1 4.4.1. "Support for Cloud Infrastructure Profiles and flavors"](./chapter04.md#4.4.1) | | inf.com.07 | Compute | The Architecture **must** support different hardware configurations to support various infrastructure profiles (Basic and High Performance).| [RA-1 3.3.3. "Host aggregates providing resource pooling"](./chapter03.md#333-host-aggregates-providing-resource-pooling) | | 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)](https://docs.openstack.org/nova/latest/configuration/config.html#compute.cpu_dedicated_set). Please see example, ["Configuring libvirt compute nodes for CPU pinning"](https://docs.openstack.org/nova/latest/admin/cpu-topologies.html) | [RA-1 4.2.2.7 "Reservation of Compute Node cores"](./chapter04.md#4227-reservation-of-compute-node-cores) | | 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. | [RA-1 4.2.2.7 "Reservation of Compute Node cores"](./chapter04.md#4227-reservation-of-compute-node-cores) and [RA-1 4.2.2.8 "Pinned and Unpinned CPUs"](./chapter04.md#4228-pinned-and-unpinned-cpus) | | inf.stg.01 | Storage | The Architecture **must** provide remote (not directly attached to the host) Block storage for Instances. | [RA-1 3.4.2.3. "Storage"](./chapter03.md#3423-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 risk of "Compliant VNFs" failing in their environment. | [RA-1 4.3.1.4 "Swift"](./chapter04.md#4314-swift) | | inf.ntw.01 | Network | The Architecture **must** provide virtual network interfaces to instances. | [RA-1 5.2.5. "Neutron" ](./chapter05.md#525-neutron) | | inf.ntw.02 | Network | The Architecture **must** include capabilities for integrating SDN controllers to support provisioning of network services, from the OpenStack Neutron service, such as networking of VTEPs to the Border Edge based VRFs. | [RA-1 3.2.5. "Virtual Networking – 3rd party SDN solution"](./chapter03.md#325-virtual-networking--3rd-party-sdn-solution) | | inf.ntw.03 | Network | The Architecture **must** support low latency and high throughput traffic needs. | [RA-1 4.2.3. "Network Fabric"](./chapter04.md#423-network-fabric) | | inf.ntw.05 | Network | The Architecture **must** allow for East/West tenant traffic within the cloud (via tunnelled encapsulation overlay such as VXLAN or Geneve). | [RA-1 4.2.3. "Network Fabric"](./chapter04.md#423-network-fabric) | | inf.ntw.07 | Network | The Architecture **must** support network [resiliency](../../../common/glossary.md#cloud-platform-abstraction-related-terminology). | [RA-1 3.4.2.2. "Network"](./chapter03.md#3422-network) | | inf.ntw.10 | Network | The Cloud Infrastructure Network Fabric **must** be capable of enabling highly available (Five 9’s or better) Cloud Infrastructure. | [RA-1 3.4.2.2. "Network"](./chapter03.md#3422-network) | | inf.ntw.15 | Network | The Architecture **must** support multiple networking options for Cloud Infrastructure to support various infrastructure profiles (Basic and High Performance).| [RA-1 4.2.3.4. "Neutron ML2-plugin Integration"](./chapter04.md#4234-neutron-ml2-integration) and ["OpenStack Neutron Plugins"](https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers) | | inf.ntw.16 | Network | The Architecture **must** support dual stack IPv4 and IPv6 for tenant networks and workloads.| |Table 2-20: Infrastructure Requirements
### 2.3.3 VIM Requirements | Reference | sub-category | Description | Specification Reference | |----|----------------|----------------------|-----------| | vim.01 | General | The Architecture **must** allow infrastructure resource sharing. | [RA-1 3.2. "Consumable Infrastructure Resources and Services"](./chapter03.md#32-consumable-infrastructure-resources-and-services) | | vim.03 | General | The Architecture **must** allow VIM to discover and manage Cloud Infrastructure resources. | [RA-1 5.2.7. "Placement"](./chapter05.md#527-placement) | | vim.05 | General | The Architecture **must** include image repository management. | [RA-1 4.3.1.2. "Glance"](./chapter04.md#4312-glance) | | vim.07 | General | The Architecture **must** support multi-tenancy. | [RA-1 3.2.1. "Multi-Tenancy"](./chapter03.md#321-multi-tenancy-execution-environment) | | vim.08 | General | The Architecture **must** support resource tagging. | ["OpenStack Resource Tags"](https://specs.openstack.org/openstack/api-wg/guidelines/tags.html) |Table 2-21: VIM Requirements
### 2.3.4 Interfaces & 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. | [RA-1 5.2.1 "Keystone"](./chapter05.md#521-keystone) | | int.api.02 | API | The Architecture **must** provide APIs to access the image management service and the associated mandatory features detailed in chapter 5. | [RA-1 5.2.2 "Glance"](./chapter05.md#522-glance) | | 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. | [RA-1 5.2.3 "Cinder"](./chapter05.md#523-cinder) | | 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. | [RA-1 5.2.4 "Swift"](./chapter05.md#524-swift) | | int.api.05 | API | The Architecture **must** provide APIs to access the network management service and the associated mandatory features detailed in chapter 5. | [RA-1 5.2.5 "Neutron"](./chapter05.md#525-neutron) | | 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. | [RA-1 5.2.6 "Nova"](./chapter05.md#526-nova) | | int.api.07 | API | The Architecture **must** provide GUI access to tenant facing cloud platform core services except at Edge/Far Edge clouds. | [RA-1 4.3.1.9 "Horizon"](./chapter04.md#4319-horizon) | | int.api.08 | API | The Architecture **must** provide APIs needed to discover and manage Cloud Infrastructure resources. | [RA-1 5.2.7. "Placement"](./chapter05.md#527-placement) | | int.api.09 | API | The Architecture **must** provide APIs to access the orchestration service. | [RA-1 5.2.8 "Heat"](./chapter05.md#528-heat) | | 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. | [RA-1 5.2 Core OpenStack Services APIs](./chapter05.md#52-core-openstack-services-apis) |Table 2-22: Interfaces and APIs Requirements
### 2.3.5 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. | [RA-1 4.3.1.9 "Horizon"](./chapter04.md#4319-horizon) and [3.3.1.4 Cloud Workload Services](./chapter03.md#3314-cloud-workload-services) |Table 2-23: Tenant Requirements
### 2.3.6 Operations and LCM | 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. | | | 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). | |Table 2-24: LCM Requirements
### 2.3.7 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. | | | asr.mon.03 | Monitoring | The Architecture **must** allow for the collection and dissemination of performance and fault information. | | | 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. | |Table 2-25: Assurance Requirements
### 2.4 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.4.1 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](https://docs.openstack.org/ha-guide/control-plane-stateful.html)"| | 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](https://docs.openstack.org/senlin/wallaby/), cluster management service. | | gen.rsl.02 | Resiliency | The Architecture **should** support resilient OpenStack service components that are not subject to gen.rsl.01. | |Table 2-26: General Recommendations
### 2.4.2 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. | [RA-1 "Virtual Storage"](./chapter03.md#323-virtual-storage) | | inf.ntw.04 | Network | The Architecture **should** support service function chaining. | | | inf.ntw.06 | Network | The Architecture **should** support Distributed Virtual Routing (DVR) to allow compute nodes to route traffic efficiently. | | | inf.ntw.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.ntw.09 | Network | The Cloud Infrastructure Network Fabric **should** embrace open-based standards and technologies. | | | inf.ntw.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.ntw.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). | [RA-1 3.2.6. "Acceleration"](./chapter03.md#326-acceleration) | | inf.acc.02 | Acceleration | The Architecture **should** support Cloud Infrastructure Acceleration (such as SmartNICs). | ["OpenStack Future - Specs defined"](https://specs.openstack.org/openstack/neutron-specs/specs/stein/neutron-ovs-agent-support-baremetal-with-smart-nic.html) | | inf.acc.03 | Acceleration | The Architecture **may** rely 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. | [RA-1 4.3.1.2. "Glance"](./chapter04.md#4312-glance) |Table 2-27: Infrastructure Recommendations
### 2.4.3 VIM Recommendations | Reference | sub-category | Description | Notes | |----|----------------|----------------------|-----------| | vim.02 | General | The Architecture **should** support deployment of OpenStack components in containers. | [RA-1 4.3.2. "Containerised OpenStack Services"](./chapter04.md#432-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. | |Table 2-28: VIM Recommendations
### 2.4.4 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 Recommendations" |Table 2-29: Interfaces and APIs Recommendations
### 2.4.5 Tenant Recommendations This section is left blank for future use. | Reference | sub-category | Description | Notes | |----|-------|---------------------|-------------|Table 2-30: Tenant Recommendations
### 2.4.6 Operations and 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. | |Table 2-31: LCM Recommendations
### 2.4.7 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. | |Table 2-32: Assurance Recommendations
### 2.4.8 Security Recommendations #### 2.4.8.1. System Hardening (source [RM 7.9.1](../../../ref_model/chapters/chapter07.md#791-system-hardening)) | 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. | |Table 2-33: System Hardening Recommendations
#### 2.4.8.2. Platform and Access (source [RM 7.9.2](../../../ref_model/chapters/chapter07.md#792-platform-and-access)) | 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 |Table 2-34: Platform and Access Recommendations
#### 2.4.8.3. Confidentiality and Integrity (source [RM 7.9.3](../../../ref_model/chapters/chapter07.md#793-confidentiality-and-integrity)) | 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. | |Table 2-35: Confidentiality and Integrity Recommendations
#### 2.4.8.4. Workload Security (source [RM 7.9.4](../../../ref_model/chapters/chapter07.md#794-workload-security)) | Reference | sub-category | Description | Notes | |---|----|---|----| | sec.wl.007 | Workload | The Operator **should** implement processes and tools to verify VNF authenticity and integrity. | |Table 2-36: Workload Security Recommendations
#### 2.4.8.5. Image Security (source [RM 7.9.5](../../../ref_model/chapters/chapter07.md#795-image-security)) This section is left blank for future use. | 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. | |Table 2-37: Image Security Recommendations
#### 2.4.8.6. Security LCM (source [RM 7.9.6](../../../ref_model/chapters/chapter07.md#796-security-lcm)) | 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 | |Table 2-38: LCM Security Recommendations
#### 2.4.8.7. Monitoring and Security Audit (source [RM 7.9.7](../../../ref_model/chapters/chapter07.md#797-monitoring-and-security-audit)) 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. | 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 | |Table 2-39: Monitoring and Security Audit Recommendations
#### 2.4.8.8. Open-Source Software Security (source [RM 7.9.8](../../../ref_model/chapters/chapter07.md#798-open-source-sotfware)) | 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 | https://www.ntia.gov/SBOM. |Table 2-40: Open-Source Software Security Recommendations
#### 2.4.8.9. IaaC security (source [RM 7.9.9](../../../ref_model/chapters/chapter07.md#799-iaac---secure-design-and-architecture-stage-requirements)) **Secure 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. |Table 2-41: Reference Model Requirements: IaaC Security, Design and Architecture Stage
**Secure Code Stage Requirements** | 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. | |Table 2-42: Reference Model Requirements: IaaC Security, Secure Code Stage
**Continuous Build, Integration and Testing Stage Requirements** | 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 | DAST – 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. |Table 2-43: Reference Model Requirements: IaaC Security, Continuous Build, Integration and Testing Stage
**Continuous Delivery and Deployment Stage Requirements** | 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. |Table 2-44: Reference Model Requirements: IaaC Security, Continuous Delivery and Deployment Stage
**Runtime Defence and Monitoring Requirements** | 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. |Table 2-45: Reference Model Requirements: Iaac Security, Runtime Defence and Monitoring Stage
#### 2.4.8.10. Compliance with Standards (source [RM 7.9.10](../../../ref_model/chapters/chapter07.md#7910-compliance-with-standards)) | Reference | sub-category | Description | Notes | |---------|---------------|----------------|------------| | sec.std.001 | Standards | The Cloud Operator **should** comply with [Center for Internet Security CIS Controls](https://www.cisecurity.org/) | | | 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](https://cloudsecurityalliance.org/) | | | sec.std.003 | Standards | The Platform and Workloads **should** follow the guidance in the [OWASP Cheat Sheet Series (OCSS)]( https://github.com/OWASP/CheatSheetSeries)- OWASP, [Open Web Application Security Project](https://www.owasp.org) | | | 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](https://owasp.org/www-project-top-ten/) | | | sec.std.005 | Standards | The Cloud Operator, Platform and Workloads **should** strive to improve their maturity on the [OWASP Software Maturity Model (SAMM)](https://owaspsamm.org/blog/2019/12/20/version2-community-release/) | | | sec.std.006 | Standards | The Cloud Operator, Platform and Workloads **should** utilise the [OWASP Web Security Testing Guide]( https://github.com/OWASP/wstg/tree/master/document) | | | sec.std.007 | Standards | The Cloud Operator, and Platform **should** satisfy the requirements for Information Management Systems specified in [ISO/IEC 27001]( https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-2:v1:en); 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)](https://www.iso.org/obp/ui/#iso:std:iso-iec:27002:ed-2:v1:en) | | | sec.std.009 | Standards | The Cloud Operator, and Platform **should** implement the [ISO/IEC 27032:2012 (or latest) Guidelines for Cybersecurity techniques](https://www.iso.org/obp/ui/#iso:std:iso-iec:27032:ed-1:v1:en); 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 | |Table 2-46: Security Recommendations