Difference between revisions of "Solum/Security"
< Solum
(Solum Security Architecture) |
|||
| Line 1: | Line 1: | ||
This is currently a non-approved discussion of potential security measures that Solum may incorporate. Once we get alignment on the high level topics, blueprints may be created for specific topics. | This is currently a non-approved discussion of potential security measures that Solum may incorporate. Once we get alignment on the high level topics, blueprints may be created for specific topics. | ||
| − | + | * '''Logging''': Identify confidential data which should not be disclosed to end users/customers and flag it in the logs for easy filtering on the backend. Recently Ceilometer had a security issue where logs (INFO level) contained backend database credentials as an example of why this is important. It is strongly recommended to utilize a structured log format such as JSON to hold log data. | |
| + | * '''Default Secure Configuration''': The default Solum installation must be placed into a highly secure mode by default. It will be up to the Solum operator to change that configuration. | ||
| + | * '''Log Potentially Insecure Configurations''': If there is a configuration option that could potentially expand the attack surface of Solum in a meaningful way, log the configuration option in question and a brief description of the potential results. | ||
| + | * '''Authentication Backoff''': In order to prevent dictionary attack spam, failed authentication should trigger backoff times where a user must wait an increasing amount of time before attempting re-authentication. | ||
| + | * '''Prevent Authentication Timing Attacks''': There should be no easily discernible difference in response to a valid vs a failed authentication attempt in order to prevent attackers from using timing attacks to locate valid accounts in �Solum. | ||
Revision as of 16:33, 26 November 2013
This is currently a non-approved discussion of potential security measures that Solum may incorporate. Once we get alignment on the high level topics, blueprints may be created for specific topics.
- Logging: Identify confidential data which should not be disclosed to end users/customers and flag it in the logs for easy filtering on the backend. Recently Ceilometer had a security issue where logs (INFO level) contained backend database credentials as an example of why this is important. It is strongly recommended to utilize a structured log format such as JSON to hold log data.
- Default Secure Configuration: The default Solum installation must be placed into a highly secure mode by default. It will be up to the Solum operator to change that configuration.
- Log Potentially Insecure Configurations: If there is a configuration option that could potentially expand the attack surface of Solum in a meaningful way, log the configuration option in question and a brief description of the potential results.
- Authentication Backoff: In order to prevent dictionary attack spam, failed authentication should trigger backoff times where a user must wait an increasing amount of time before attempting re-authentication.
- Prevent Authentication Timing Attacks: There should be no easily discernible difference in response to a valid vs a failed authentication attempt in order to prevent attackers from using timing attacks to locate valid accounts in �Solum.
