RA-1, RI-1 and RC-1 Traceability and Gap Analysis

RM 4.2.1.1

RM 4.2.4

RM 4.2.5

Also  RM 5.2.1

Profile Capabilities includes specifications for capabilities such as CPU Pinning, NUMA support, SR-IOV, FPGA, etc.

Manifests

with Airship 2.0 will replace with helm operator

Functional

Functional

Functest supports tuning a few inputs such flavor extra specs (e.g. hugepages). All tests can be executed multiple times (basic then network intensive) 

comment acknowledged, no action required

Functest supports tuning a few inputs such flavor extra specs (e.g. hugepages). All tests can be executed multiple times (basic then network intensive) 

comment acknowledged, no action required

Functest supports tuning a few inputs such flavor extra specs (e.g. hugepages). All tests can be executed multiple times (basic then network intensive) 

comment acknowledged, no action required

too generic and should mention the ref to the mandatory capabilities and the status expected.

130 single tests about volumes amongst tempest_cinder, tempest_full, tempest_scenario and tempest_slow ( +indirect testing in case of tempest_heat)

addressed in req.int.api.03 below

(PR #1622 merged)

too generic and should mention the ref to the mandatory capabilities and the status expected.

140 single tests about object storage amongst tempest_full, tempest_scenario and tempest_slow ( +indirect testing in case of tempest_heat)

addressed in req.int.api.04 below

(PR #1622 merged)

req.inf.stg.03

move to Recommendations

Out of CNTT RC (may)

+ an API proposing this feature should be proposed in CNTT first

The tempest plugin could be added in Functest if it makes sens (IaaS verification). Useless on CNTT side right now

Bug here!

req.inf.stg.04

move to Recommendations

Out of CNTT RC (may)

As far as I understand It's out of CNTT (implementation design) 

Ceph is tested thought the mandatory service API by Functest

req.inf.stg.06

move to Recommendations

It's a must requirement according RA1 Chapter5

Bug here !

Glance is required but not necessarily immutable images – some operators make changes to install needed tools such anti-virus etc.

req.inf.stg.07

move to Recommendations

As far as I understand It's out of CNTT (implementation design) and the related API is a must requirement.

Does it make sens to cover ceph from a functional pov (why not benchmarking)?

Bug here!

ceph is not required – during requirement creation there was opposition

req.inf.stg.10

duplicate and wrong – modify

this reqt is for local, req.inf.stg.01  was for "remote"

move to Recommendations

req.inf.stg.11

duplicate and wrong - modify

move to Recommendations

It's a must requirement according RA1 Chapter5

Bug here !

The original reuirement is to support all Cinder capabilities listed in the refererred to document – and that is not rquired only some features are required

missing

VSPERF BM Tests: p2p and pvp

Cloud tests possible with PROX and NFVBench

As far as I understand It's out of CNTT (implementation design).

RA1 Chapter5 sets as mandatory the networking capabilities (already verified by neutron agents and OVN) 

This requirement is about the support of network options such as SDN through the use of plugins.

req.int.api.05 below

(PR #1622 merged) deals with your comment about mandatory capabilities

req.inf.ntw.17

move to Recommendations

Must be clarified. Endpoints are registered by IPv4 or IPv6.

Bug ?

THis is not about APIs but the use of dual stack in Controller nodes

It's a must requirement according RA1 Chapter5

Bug here !

Not all network extensions are mandatory – the mandatory are now covered under req.int.api.05

req.inf.acc.01

move to Recommendations

keep for Baraque

Out of CNTT RC (should)

+ an API proposing this feature should be proposed in CNTT RA1 first

req.inf.acc.02

move to Recommendations

keep for Baraque

Out of CNTT RC (should)

+ an API proposing this feature should be proposed in CNTT RA1 first

req.vim.02

move to Recommendations

Image Service (Glance)

(installed as part of OpenStack core services)

OpenStack APIs

for deployment manifests should include the details

OpenStack APIs

for deployment manifests should include the details

OpenStack APIs

for deployment manifests should include the details

OpenStack APIs

for deployment manifests should include the details

OpenStack APIs

for deployment manifests should include the details

OpenStack APIs

for deployment manifests should include the details

OpenStack APIs

for deployment manifests should include the details

OpenStack APIs

for deployment manifests should include the details

OpenStack APIs

for deployment manifests should include the details

OpenStack APIs

for deployment manifests should include the details

req.int.acc.01

move to Recommendations

Acceleration Service (Cyborg)

for deployment manifests should include the details

Horizon

(installed as part of OpenStack core services)

missing

(Airship?)

6.3.1.4 RBAC

6.3.1.2 Authentication and

6.3.1.3 Authorization

Keystone

(installed as part of OpenStack core services)

6.3.1.1 Identity

Keystone

(installed as part of OpenStack core services)

Barbican

(installed as part of OpenStack core services)

TLS 1.2+(in-flight)

at-rest use ceph default encryption

4.2.3.2 High Level Logical Network Layout

 sec.gen.001

 Hardening

 The Platform must maintain the state to what it is specified to be and does not change unless through change management process.

7.2.2. Configuration Management

security hardening 

 sec.gen.002

 Hardening

 All systems part of Cloud Infrastructure must support password hardening (strength and rules for updates (process), storage and transmission, etc.)

security hardening

 sec.gen.003

 Hardening

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

6.3.6 Security LCM  

security hardening  

 sec.gen.004

 Hardening

 The Operating Systems of all the servers part of Cloud Infrastructure must be hardened

6.3.2 System Hardening

security hardening  

 sec.gen.005

 Hardening

 The Platform must support Operating System level access control

6.3.1 Platform Access  

security hardening  

 sec.gen.006

 Hardening

 The Platform must support Secure logging

6.3.7 Security Audit Logging

security hardening  

 sec.gen.007

 Hardening

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

security hardening  

 sec.gen.008

 Hardening

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

6.3.2 System Hardening  

security hardening  

 sec.gen.009

 Hardening

 The Platform must support Software integrity protection and verification

6.3.3 Confidentiality and Integrity  

security hardening  

 sec.gen.010

 Hardening

 The Cloud Infrastructure must support Secure storage (all types)

6.3.6 Security LCM

security hardening  

 sec.gen.012

 Hardening

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

security hardening  

 sec.gen.013

 Hardening

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

6.3.1 Platform Access  

security hardening  

 sec.sys.001

 Access

 The Platform must support authenticated and secure APIs, API endpoints. The Platform **must** implement authenticated and secure access to GUI

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

security access  

 sec.sys.002

 Access

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

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

security access

 sec.sys.003

 Access

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

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

security access

 sec.sys.004

 Access

 The Cloud Infrastructure must support Secure network channels

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

security access

 sec.sys.005

 Access

 The Cloud Infrastructure must segregate the underlay and overlay networks

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

security access

 sec.sys.006

 Access

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

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Keystone

(installed as part of OpenStack core services)

security access

 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)

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Functional

Functest

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

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

security access

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

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

security access

 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

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

security access

 sec.sys.011

 Access

 The Platform must not reuse the same authentication key-pair (for example, on different hosts, for different services)

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

security access

 sec.sys.012

 Access

 The Platform must only use secrets encrypted using strong encryption techniques, and stored externally from the component (e.g., Barbican (OpenStack))

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Barbican

(installed as part of OpenStack core services)

security access

 sec.sys.013

 Access

 The Platform must provide secrets dynamically as and when needed

 [6.3.1 Platform Access](https://github.com/cntt-n/CNTT/blob/master/doc/ref_arch/openstack/chapters/chapter06.md#631-platform-access)

Barbican

(installed as part of OpenStack core services)

security access

 sec.ci.001

 Confidentiality/Integrity

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

 [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

Keystone

(installed as part of OpenStack core services)

security confidentiality & integrity

 sec.ci.003

 Confidentiality/Integrity

 The Platform must support Confidentiality and Integrity of data related metadata

  [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

security confidentiality & integrity

 sec.ci.004

 Confidentiality

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

  [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

 Functional

 Functest

Tenant isolation

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

  [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

security confidentiality & integrity

 sec.ci.006

 Confidentiality/Integrity

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

  [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

security confidentiality & integrity

 sec.ci.007

 Confidentiality/Integrity

 The Platform must not allow Memory Inspection by any actor other than the authorized actors for the Entity to which Memory is assigned (e.g., tenants owning the workload), for Lawful Inspection, and by secure monitoring services. Admin access must be carefully regulated 

  [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

security confidentiality & integrity

 sec.ci.008

 Confidentiality

 The Cloud Infrastructure must support tenant networks segregation

 [6.3.3 Confidentiality and Integrity](./chapter06.md#633-confidentiality-and-integrity)

 Functional

Functest

Tenant isolation

 sec.wl.001

 Workload

 The Platform must support Workload placement policy

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

security workload

 sec.wl.002

 Workload

 The Platform must support operational security

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

security workload

 sec.wl.003

 Workload

 The Platform must support secure provisioning of workloads 

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

security workload

 sec.wl.004

 Workload

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

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

security workload

 sec.wl.005

 Workload

 Production workloads must be separated from non-production workloads

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

 sec.wl.006

 Workload

 Workloads must be separable by their categorisation (for example, payment card information, healthcare, etc.)

 [6.3.4 Workload Security](./chapter06.md#634-workload-security)

security workload

 sec.img.001

 Image

 Images from untrusted sources must not be used

6.3.5 Image Security

security image

 sec.img.002

 Image

 Images must be maintained to be free from known vulnerabilities

security workload

 sec.img.003

 Image

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

 sec.img.004

 Image

 Images must only be accessible to authorized actors

security workload

 sec.img.005

 Image

 Image Registries must only be accessible to authorized actors

 sec.img.006

 Image

 Image Registries must only be accessible over secure networks

security workload

 sec.img.007

 Image

 Image registries must be clear of vulnerable and stale (out of date) versions

security workload

 sec.lcm.001

 LCM

 The Platform must support Secure Provisioning, Maintaining availability, Deprovisioning (secure Clean-Up) of workload resources; Secure clean-up: tear-down, defending against virus or other attacks, or observing of cryptographic or user service data

(7.2.2. Configuration Management)

security LCM

 sec.lcm.002

 LCM

 Operational must use management protocols limiting security risk such as SNMPv3, SSH v2, ICMP, NTP, syslog and TLS

(7.2.2. Configuration Management)

security LCM

 sec.lcm.003

 LCM

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

(7.2.2. Configuration Management)

security LCM

 sec.lcm.005

 LCM

 Platform must provide logs and these logs must be regularly scanned

6.3.7 Security Audit Logging

security LCM

 sec.lcm.006

 LCM

 The Platform must verify the integrity of all Resource management requests

6.3.7 Security Audit Logging

 sec.lcm.007

 LCM

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

(7.2.2. Configuration Management)

 sec.lcm.008

 LCM

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

(7.2.2. Configuration Management)

security LCM

 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

(7.2.2. Configuration Management)

security LCM

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

(7.2.2. Configuration Management)

security LCM

 sec.lcm.011

 LCM

 The Platform must implement Security life cycle management processes including proactively update and patch all deployed Cloud Infrastructure software.

(7.2.2. Configuration Management)

security LCM

 sec.mon.001

 Monitoring/Audit

 Platform must provide logs and these logs must be regularly scanned for events of interest

7.4.1. Logging

 sec.mon.002

 Monitoring

 Security logs must be time synchronised

6.3.7 Security Audit Logging  and 7.4.1. Logging

 sec.mon.003

 Monitoring

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

7.4.1. Logging

 sec.mon.004

 Audit

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

6.3.7 Security Audit Logging  and 7.4.1. Logging

 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

7.4. Logging, Monitoring and Analytics (includes Alerting)

 sec.mon.006

 Monitoring/Audit

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

7.4. Logging, Monitoring and Analytics (includes Alerting)

 sec.mon.007

 Monitoring/Audit

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

7.2.2. Configuration Management

 sec.mon.008

 Monitoring/Audit

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

 sec.mon.009

 Monitoring/Audit

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

7.4. Logging, Monitoring and Analytics (includes Alerting) - partial

 sec.mon.010

 Monitoring/Audit

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

 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

7.4. Logging, Monitoring and Analytics (includes Alerting)

 sec.mon.012

 Monitoring/Audit

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

(7.4. Logging, Monitoring and Analytics (includes Alerting))

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

(7.4.4. Logging, Monitoring, and Analytics (LMA) Framework)

 sec.mon.015

 Monitoring

 The Platform must ensure that the Monitoring systems are never starved of resources

 sec.lcm.017

 Audit

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

(7.2.2. Configuration Management)

 sec.std.018

 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