Key Management Policy

Purpose#

The purpose of this policy is to ensure the proper lifecycle management of encryption keys to protect the confidentiality and integrity of confidential information. Additionally, it informs all DefectDojo employees and external parties with access to DefectDojo equipment, systems, or networks (DefectDojo Staff) of their obligations regarding the management of encryption keys across all systems, networks, IT assets, and licensed software owned, operated, or used by DefectDojo.

Scope#

This policy applies to confidential and personal information processed, stored, or transmitted at DefectDojo.

Compliance#

Compliance Measurement#

The Information Security Management team will verify compliance to this document through various methods, including but not limited to business tool reports, internal and external audits, and feedback to the document owner.

Exceptions#

Any exception to this document must be reviewed and approved in advance by the Management Review Team.

Non-Compliance#

Any DefectDojo Staff found to have violated this document may be subject to disciplinary action, up to and including termination of employment.

Continual Improvement#

This document is updated and reviewed as part of the continual improvement process.

Requirements#

Principle#

Cryptographic Key Management is based on OWASP guidelines - Key Management - OWASP Cheat Sheet Series. All cryptographic keys must be managed as confidential information.

Key Generation#

• Keys should be generated using industry-standard tools provided by DefectDojo and managed via cloud provider key management vaults.
• If keys must be generated outside of industry-standard IaaS/SaaS tools, they must be generated within a cryptographic module with at least FIPS 140-2 compliance. The Random Bit Generator must also be implemented within the module.
• Hardware cryptographic modules are preferred over software modules.

Key Distribution#

• Keys must be transported using secure channels and used by their associated cryptographic algorithm within at least a FIPS 140-2 compliant module.
• For further guidance, refer to NIST Special Publication 800-133.

Key Storage#

• Developers must track where keys are stored within applications and memory devices. Application-level code must only use key management libraries.
• Keys must be protected on both volatile and persistent memory, never stored in plaintext, and stored in cryptographic vaults such as HSMs or isolated cryptographic services.
• Offline keys must be encrypted using Key Encryption Keys (KEKs) prior to export. KEKs should be of equal or greater strength and stored in a vault owned by the Security Operations team.
• Integrity protections such as MAC must be applied while keys are in storage.

Key Operations#

• All key operations (access, encryption, decryption, signing) must occur inside a vault.
• Key use should trigger alerts to the Security Operations team.
• Master keys should be used only to create signing keys, and never in day-to-day operations.

Key Rotation and Master Key Access#

• Keys must be rotated at least annually; lifetime must not exceed 2 years.
• Key rotation ceremonies must include at least two witnesses, one being the CISO or Director of Cybersecurity.
• Any use or change of a master key requires at least two witnesses.

Key Sharing#

• Keys may not be shared with third parties without explicit approval from the Security Operations team via an Exception Request ticket. Documentation of key use is required.

Key Escrow and Backup#

• Manual backup keys outside cloud provider replication must be encrypted using at least a FIPS 140-2 validated module.
• Key escrow should only be used for investigations or re-provisioning in case of loss or corruption. Certificate Authorities and key management systems should be used whenever possible.

Trust Stores#

• Trust Stores must be secured against third-party root certificate injection.
• Access controls must be enforced at the entity and application level.
• Integrity controls should be implemented, and keys exported only after authentication and authorization.

Cryptographic Key Management Libraries#

• Only well-maintained, updated, and validated cryptographic libraries (e.g., NIST or FIPS certified) should be used.

Relevant Documents#

• Cryptographic Controls Policy
• Data Classification Policy
• Data Classification Standard