-
Task
-
Resolution: Done
-
Medium
-
None
-
None
-
VNFRQTS Sprint 7
El Alto Update
Current Requirement: The VNF Vendor MUST provide all code (e.g., QCOW2) and configuration files (e.g., HEAT template, Ansible playbook, script) in a hardened state, with documented recommended configurations for hardening, and interfaces that allow the Operator to harden the VNF. Actions taken to harden a system include disabling all unnecessary services, and changing default values such as default credentials and community strings.
Proposed Requirement: All architectural layers of the VNF MUST be hardened, or have documented recommended configurations for hardening and interfaces that allow the Operator to harden all architectural layers. This includes but is not limited to all code (e.g., QCOW2), configuration files (e.g., HEAT template, Ansible playbook, script), and interfaces (e.g., ports, APIs). Actions taken to harden a system include disabling all unnecessary services, and changing default values such as default credentials and community strings.
Casablanca Update
Current Requirement: The VNF MUST provide all code/configuration files in a “Locked down” or hardened state or with documented recommendations for such hardening. All unnecessary services will be disabled. VNF provider default credentials, community strings and other such artifacts will be removed or disclosed so that they can be modified or removed during provisioning.
Proposed Requirement: The VNF Vendor MUST provide all code (e.g., QCOW2) and configuration files (e.g., HEAT template, Ansible playbook, script) in a hardened state, with documented recommended configurations for hardening, and interfaces that allow the Operator to harden the VNF. Actions taken to harden a system include disabling all unnecessary services, and changing default values such as default credentials and community strings.
Reason: Clarifies the hardening requirements.
- relates to
-
VNFRQTS-456 Security Requirement for VNF Hardening and Monitoring Functionality
- In Progress