Difference between revisions of "Solum/SecurityRequirements"
| Line 6: | Line 6: | ||
* Define each log level and when to use each (check first to see if there is an OpenStack guide) | * Define each log level and when to use each (check first to see if there is an OpenStack guide) | ||
* Add Remarks section in Solum-specific requirements | * Add Remarks section in Solum-specific requirements | ||
| + | |||
| + | # header1 | ||
| Line 70: | Line 72: | ||
|} | |} | ||
| + | |||
| + | |||
| + | [[Link-name1|#Header1]] | ||
Revision as of 22:19, 11 December 2013
Note: This is currently a living document under frequent updates. This is meant to capture the Solum community's collective stance on security features but is not approved at this point.
TODO:
- Add links to each requirement table row for easy linking during reviews.
- Add OSSG applicability field to Solum-specific security requirements
- Define each log level and when to use each (check first to see if there is an OpenStack guide)
- Add Remarks section in Solum-specific requirements
- header1
Contents
Solum Security Requirements
Solum is a relatively large project with a diverse set of contributors. This page will attempt to capture the security features which will be implemented in Solum's core code base in order to coordinate efforts with the community. This will also include a list of features that the Solum operator/administrator should implement.
Why doesn't Solum implement all security features? There are many Solum implementation options and local environment requirements that would make this extremely difficult to impossible. Each operator will likely have their own level of security requirements.
Much of the material used in this document comes from the OpenStack Security Guide: http://docs.openstack.org/security-guide/content/openstack_user_guide.html
Assumptions:
- Will consider Solum to be equivalent to an OSSG-defined "public cloud" with regard to threat model
Solum-specific Security Requirements
These requirements were derived from discussions in the Solum community.
| Req # | Status | Milestone | Description | External Link |
|---|---|---|---|---|
| Not Started | Follow prescribed logging guidelines to prevent confidential data leaks | Solum/Logging Wiki |
OSSG-based Solum Security Features
These are security requirements for the core Solum implementation to address.
| Req # | Status | Milestone | Doc Link | Description | External Link (BPs, etc) |
|---|---|---|---|---|---|
| Not Started | >M1 | [link link_text] | desc |
OSSG-based Operator Security Features
These are recommended security features that an operator should implement but it is ultimately the operator's choice. These requirements are outside the scope of Solum's core code.
| Req # | Doc Link | Description |
|---|---|---|
| Chapter 6 - System Inventory | Documentation should provide a general description of the OpenStack environment and cover all systems used (production, development, test, etc.). Documenting system components, networks, services, and software often provides the bird's-eye view needed to thoroughly cover and consider security concerns, attack vectors and possible security domain bridging points. A system inventory may need to capture ephemeral resources such as virtual machines or virtual disk volumes that would otherwise be persistent resources in a traditional IT system. | |
| Chapter 9 - Vulnerability Management | Operators should sign up for the OpenStack Announce mailing list to receive security notifications and monitor the OpenStack Security Advisories (OSSA) and OpenStack Security Notes (OSSN). | |
| Chapter 9 - Secure Backup and Recovery | Ensure only authenticated users and backup clients have access to the backup server, use data encryption options for storage and transmission of backups, Use a dedicated and hardened backup server(s). The backup server's logs should be monitored daily and should be accessible by only few individuals and Test data recovery options regularly | |
| Chapter 9 - Security Auditing Tools | Security auditing tools automate the process of verifying that a large number of security controls are satisfied for a given system configuration | |
| Chapter 10 - Secure Bootstrapping | Nodes in the cloud should utilize a secure boot technology such as TPM, Intel TXT, DRTM and UEFI to ensure that nodes are provisioned consistently and correctly. This also includes using PXE to provision nodes. | |
| Chapter 10 - Node Hardening | Implement security features such as: Use a read-only file system where possible, Use a mandatory access control policy to contain the instances, the node services, and any other critical processes and data on the node (such as SELinux) and Remove any unnecessary software packages | |
| Chapter 10 - Intrusion Detection System | Implement an intrusion detection system for runtime verification of correctness | |
| Chapter 11 - Dashboard Security Considerations | The web server that hosts dashboard (Horizon) must be configured for SSL to ensure data is encrypted | |
| [link link_text] | desc |
