Difference between revisions of "Solum/SecurityRequirements"
< Solum
| Line 19: | Line 19: | ||
* Simplify Gerrit reviews by copying the appropriate "Requirement Link" and pasting it into the review comments | * Simplify Gerrit reviews by copying the appropriate "Requirement Link" and pasting it into the review comments | ||
* Link discussion logs to the appropriate security feature so that others may understand the background discussions and reasons (please help keep this up to date) | * Link discussion logs to the appropriate security feature so that others may understand the background discussions and reasons (please help keep this up to date) | ||
| + | * Feed security architecture back to the OpenStack Security Group to help make OpenStack wide security best practices documentation | ||
| Line 39: | Line 40: | ||
|- | |- | ||
| [[#logging_guidelines]] || Not Started || || Follow prescribed logging guidelines to prevent confidential data leaks || [https://wiki.openstack.org/wiki/Solum/Logging Solum/Logging Wiki] <span id="logging_guidelines"></span> || || Yes | | [[#logging_guidelines]] || Not Started || || Follow prescribed logging guidelines to prevent confidential data leaks || [https://wiki.openstack.org/wiki/Solum/Logging Solum/Logging Wiki] <span id="logging_guidelines"></span> || || Yes | ||
| + | |- | ||
| + | | [[#secure_defaults]] || Not Started || || All configuration options must utilize a secure setting by default. For example, if there is an option to enable or disable user authentication, the default must be enabled. || <span id="secure_defaults"></span> || || Yes | ||
| + | |- | ||
| + | | [[#log_insecure_config]] || Not Started || || If there is a configuration option that could potentially expand the attack surface of the project in a meaningful way, log the configuration option in question and a brief description of the potential results (use a log level of warning or more serious at a minimum). This provides operators an early warning. || <span id="log_insecure_config"></span> || || Yes | ||
| + | |- | ||
| + | | [[#crypto_algorithms]] || Not Started || || Unless there is a legal or industry compliance reason, all cryptographic algorithms/key lengths must be at least as strong as: symmetric cryptography: AES-128, asymmetric cryptography: RSA-2048, hashing: SHA-256. || <span id="crypto_algorithms"></span> || || Yes | ||
| + | |||
|} | |} | ||
TODO: Add contents from this link to the table - https://wiki.openstack.org/wiki/Solum/Security | TODO: Add contents from this link to the table - https://wiki.openstack.org/wiki/Solum/Security | ||
Revision as of 16:50, 13 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.
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.
Reference Material
- OpenStack Security Guide: http://docs.openstack.org/security-guide/content/openstack_user_guide.html
Goals
- Consolidate Solum security requirements
- Enable easy community discussion/voting on security topics
- Simplify Gerrit reviews by copying the appropriate "Requirement Link" and pasting it into the review comments
- Link discussion logs to the appropriate security feature so that others may understand the background discussions and reasons (please help keep this up to date)
- Feed security architecture back to the OpenStack Security Group to help make OpenStack wide security best practices documentation
Disclaimers
- This is a reference document and is not a substitute for reading the original documents
- Some requirement language quoted from external references has been modified for Solum purposes. Usually this causes "should"s to change into "must"s for more clarity.
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.
| Requirement Link | Status | Milestone | Description | External Link | Remarks | Applicable to OSSG? |
|---|---|---|---|---|---|---|
| #logging_guidelines | Not Started | Follow prescribed logging guidelines to prevent confidential data leaks | Solum/Logging Wiki | Yes | ||
| #secure_defaults | Not Started | All configuration options must utilize a secure setting by default. For example, if there is an option to enable or disable user authentication, the default must be enabled. | Yes | |||
| #log_insecure_config | Not Started | If there is a configuration option that could potentially expand the attack surface of the project in a meaningful way, log the configuration option in question and a brief description of the potential results (use a log level of warning or more serious at a minimum). This provides operators an early warning. | Yes | |||
| #crypto_algorithms | Not Started | Unless there is a legal or industry compliance reason, all cryptographic algorithms/key lengths must be at least as strong as: symmetric cryptography: AES-128, asymmetric cryptography: RSA-2048, hashing: SHA-256. | Yes |
TODO: Add contents from this link to the table - https://wiki.openstack.org/wiki/Solum/Security
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.
| Requirement Link | Doc Link | Description |
|---|---|---|
| #system_inventory | 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.
|
| #vulnerability_management | 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).
|
| #secure_backup_and_recovery | 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
|
| #secure_auditing_tools | 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
|
| #secure_bootstrapping | 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.
|
| #node_hardening | 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
|
| #intrusion_detection_system | Chapter 10 - Intrusion Detection System | Implement an intrusion detection system for runtime verification of correctness
|
| #dashboard_security_considerations | Chapter 11 - Dashboard Security Considerations | The web server that hosts dashboard (Horizon) must be configured for SSL to ensure data is encrypted
|
| #dashboard_security_groups | Chapter 11 - Dashboard Security Considerations | Create and manage security groups through dashboard. The security groups allows L3-L4 packet filtering for security policies to protect virtual machines
|
