Solum/SecurityRequirements
Note: This is currently a living document under frequent updates. Please contact paul.montgomery@rackspace.com for any questions or comments.
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. If the "OSSG Applicable" field contains "Yes", the requirement may be generally applicable to projects across OpenStack. Note: Unless the Status is "Approved", this feature has not been accepted by the Solum community yet.
Update: The OpenStack Security Group has accepted many of the Solum security requirements and will review each requirement in detail soon. This link, https://wiki.openstack.org/wiki/Security/Guidelines, will become the official repository for many of these requirements. TODO(wpm): Remove duplicate security requirements from this Solum page.
| Requirement Link | Status | Milestone | Description | External Link | Remarks | OSSG Applicable |
|---|---|---|---|---|---|---|
| #logging_guidelines | Not Started | Follow prescribed logging guidelines to prevent confidential data leaks (see external link for details) | 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 | |||
| #clearing_memory | Not Started | Only hold confidential data in memory the smallest amount of time possible and then zero out the memory after use as a defense in depth measure. Also clear environment variables which hold confidential data as soon as possible. | Yes | |||
| #network_isolation | Not Started | There must be complete network isolation between systems within the project unless there is an explicit need to enable connectivity. Any exceptions to this should be discussed by the community and documented. | Yes | |||
| #digital_signatures | Not Started | Any digital asset within the project which may cross trust boundaries must be digitally signed with RSA-2048 + SHA-256 or stronger algorithm/key. Example: If a Glance image will be executed on a system, the image should be digitally signed and authenticated before usage. | Yes | |||
| #exec_least_priv | Not Started | As a defense in depth measure, all software must run with the least privilege and with the most restrictive configuration possible. (Note: This may be an operator task.) | Yes | |||
| #auth_backoff | Not Started | Failed authentication attempts must trigger increasing backoff times before a user may attempt re-authentication. The backoff time must be configurable by the operator. | Yes | |||
| #auth_timing_attack | Not Started | There must be no feasibly discernible difference in response time to a valid vs a failed authentication attempt in order to prevent attackers from using timing attacks to locate valid accounts. | Yes | |||
| #secure_storage | Not Started | Confidential data such as credential information and private keys should not be stored unencrypted in non-volatile storage. This is a defense in depth topic to place a barrier in front of attackers in the event that they gain access to some part of the system. Where possible, distribute security responsibilities to user application storage / execution environments. Even encrypted data in non-volatile storage is potentially valuable (especially given the possibility bugs in implementation), creating a high value target. Pushing secure data out as far as possible reduces the value of any individual data store to an attacker. | Yes | |||
| #session_management | Not Started | Sessions must timeout and require the user to re-authenticate. The timeout value may be configured by the operator and it is recommended that a 24 hour timeout is the maximum value. This timeout must cancel all sessions belonging to this user. | Yes | |||
| #key_revocation | Not Started | The system must implement a key revocation system to quickly deactivate potentially compromised keys. | Yes | |||
| #req_load_man | Not Started | A number of proposed system operations are computationally/resource expensive. The fulfillment of those operations should be predictable and linear, and resist denial-of-service or amplification attacks on a per user / project / service basis as needed. This may involve queuing requests, having high water marks for these queues (where additional requests are rejected until existing requests clear), throttling delays on queue processing, separate work pools, or other load management techniques. The system must remain available for other tenants even if a subset are targeted or malicious. | Yes | |||
| #config_git_pull | Approved | The Solum git pull feature must include a configuration option which allows the operator to enable or disable the git pull feature. A cleverly crafted URL sent in by a user to perform a remote attack (apparently originating from Solum itself) instead of pointing to a git repository as expected could make Solum appear to be a malicious site. | Solum IRC Discussion Log | No | ||
| #git_pull_regex | Approved | Solum operators must be able to define a regex-like filter on user supplied git repository URLs to assist in the prevention of this feature from becoming an attack vector. | Solum IRC Discussion Log | No | ||
| #log_git_pull | Approved | If git pull is enabled in Solum, at least a warning level log must be created to warn the operator that the system may be in a potentially insecure state due to the ability for users to provide their own URLs for a git repository which Solum will contact. | Solum IRC Discussion Log | No | ||
| #encrypted_comm | Not Started | Unless there is an insurmountable overhead, all communications between services/systems must be encrypted. This is a defense in depth measure to limit the extent of an attack when a control plane system or service is compromised. | Yes |
OSSG-based Solum Security Features
These are security requirements for the core Solum implementation to address. Note: Unless the Status is "Approved", this feature has not been accepted by the Solum community yet.
| 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. Note: This is not an exhaustive list of all OpenStack Security Guide requirements. This is an attempt to quickly summarize some key recommendations and is not a replacement for the OSSG itself.
| 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
|
TODO: Continue in the OSSG from Chapter 11.
