Note - this document is currently a work in progress.
Cross Project Security Guidelines
- Establish and consolidate cross-project security best practices.
- Enable easy community discussion/voting on security topics.
- Simplify Gerrit reviews by copying the appropriate "Requirement Link" and pasting it into the review comments.
- Simplify community discussion on security topics by serving as a central reference to the background and reasoning around security best practices.
|Requirement Link||Description||Details Link|
|#auth_backoff||Failed authentication attempts must trigger increasing backoff times before a user may attempt re-authentication. The backoff time must be configurable by the operator.||auth_backoff|
|#auth_timing_attack||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.||auth_timing_attack|
|#clearing_memory||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.||clearing_memory|
|#crypto_algorithms||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.||crypto_algorithms|
|#digital_signatures||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.||digital_signatures|
|#encrypted_comm||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.||encrypted_comm|
|#exec_least_priv||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.)||exec_least_priv|
|#key_revocation||The system must implement a key revocation system to quickly deactivate potentially compromised keys.||key_revocation|
|#log_insecure_config||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.||log_insecure_config|
|#logging_guidelines||Follow prescribed logging guidelines to prevent confidential data leaks (see external link for details)||logging_guidelines|
|#network_isolation||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.||network_isolation|
|#req_load_man||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, rate limiting, separate work pools, or other load management techniques. The system must remain available for other tenants even if a subset are targeted or malicious.||req_load_man|
|#secure_defaults||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.||secure_defaults|
|#secure_storage||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.||secure_storage|
|#session_management||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.||session_management|
|#input_validation||Any inputs to the system may introduce different command injections to the system if not properly managed. For instance user inputs in web forms / cli commands, or XML/JSON inputs from un-trusted sources may lead to SQLi, XMLi, JSONi, XSS, etc. implying undesired execution of code in the system. For mitigating such kind of attacks make sure all input introduced in the systems is trusted and is properly validated, and if presented back to the user it is properly escaped/sanitized assuring that any introduced code is just interpreted as text and not executed.||input_validation|