Jump to: navigation, search

Difference between revisions of "Solum/SecurityRequirements"

Line 27: Line 27:
 
{| class="wikitable sortable"
 
{| class="wikitable sortable"
 
|-
 
|-
! Req # !! Status !! Milestone !! Description !! External Link
+
! Requirement Link !! Status !! Milestone !! Description !! External Link
 
|-
 
|-
| || Not Started ||  || Follow prescribed logging guidelines to prevent confidential data leaks || [https://wiki.openstack.org/wiki/Solum/Logging Solum/Logging Wiki]
+
| [[#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>
 
|}
 
|}
  
Line 54: Line 55:
 
<span id="system_inventory"></span>
 
<span id="system_inventory"></span>
 
|-
 
|-
| || [http://docs.openstack.org/security-guide/content/ch012_configuration-management.html#ch012_configuration-management-idp44720 Chapter 9 - Vulnerability Management] || Operators should sign up for the [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce OpenStack Announce mailing list] to receive security notifications and monitor the OpenStack Security Advisories (OSSA) and OpenStack Security Notes (OSSN).
+
| [[#vulnerability_management]] || [http://docs.openstack.org/security-guide/content/ch012_configuration-management.html#ch012_configuration-management-idp44720 Chapter 9 - Vulnerability Management] || Operators should sign up for the [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce OpenStack Announce mailing list] to receive security notifications and monitor the OpenStack Security Advisories (OSSA) and OpenStack Security Notes (OSSN).
 +
<span id="vulnerability_management"></span>
 
|-
 
|-
| || [http://docs.openstack.org/security-guide/content/ch012_configuration-management.html#ch012_configuration-management-idp10160 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_backup_and_recovery]] || [http://docs.openstack.org/security-guide/content/ch012_configuration-management.html#ch012_configuration-management-idp10160 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
 +
<span id="secure_backup_and_recovery"></span>
 
|-
 
|-
| || [http://docs.openstack.org/security-guide/content/ch012_configuration-management.html#ch012_configuration-management-idp131856 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_auditing_tools]] || [http://docs.openstack.org/security-guide/content/ch012_configuration-management.html#ch012_configuration-management-idp131856 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
 +
<span id="secure_auditing_tools"></span>
 
|-
 
|-
| || [http://docs.openstack.org/security-guide/content/ch013_node-bootstrapping.html#ch013_node-bootstrapping-idp44768 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.
+
| [[#secure_bootstrapping]] || [http://docs.openstack.org/security-guide/content/ch013_node-bootstrapping.html#ch013_node-bootstrapping-idp44768 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.
 +
<span id="secure_bootstrapping"></span>
 
|-
 
|-
| || [http://docs.openstack.org/security-guide/content/ch013_node-bootstrapping.html#ch013_node-bootstrapping-idp3728 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
+
| [[#node_hardening]] || [http://docs.openstack.org/security-guide/content/ch013_node-bootstrapping.html#ch013_node-bootstrapping-idp3728 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
 +
<span id="node_hardening"></span>
 
|-
 
|-
| || [http://docs.openstack.org/security-guide/content/ch013_node-bootstrapping.html#ch013_node-bootstrapping-idp135504 Chapter 10 - Intrusion Detection System] || Implement an intrusion detection system for runtime verification of correctness
+
| [[#intrusion_detection_system]] || [http://docs.openstack.org/security-guide/content/ch013_node-bootstrapping.html#ch013_node-bootstrapping-idp135504 Chapter 10 - Intrusion Detection System] || Implement an intrusion detection system for runtime verification of correctness
 +
<span id="intrusion_detection_system"></span>
 
|-
 
|-
| || [http://docs.openstack.org/security-guide/content/ch014_best-practices-for-operator-mode-access.html#ch014_best-practices-for-operator-mode-access-idp56400 Chapter 11 - Dashboard Security Considerations] || The web server that hosts dashboard (Horizon) must be configured for SSL to ensure data is encrypted
+
| [[#dashboard_security_considerations]] || [http://docs.openstack.org/security-guide/content/ch014_best-practices-for-operator-mode-access.html#ch014_best-practices-for-operator-mode-access-idp56400 Chapter 11 - Dashboard Security Considerations] || The web server that hosts dashboard (Horizon) must be configured for SSL to ensure data is encrypted
 +
<span id="dashboard_security_considerations"></span>
 
|-
 
|-
  

Revision as of 20:56, 12 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
  • Add links to the background IRC discussions around pertinent security topics


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.

Requirement Link Status Milestone Description External Link
#logging_guidelines 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.

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

[link link_text] desc