Secrets are digital keys, certificates or credentials such as passwords, SSH keys and tokens. They’re used for managing access permissions, encryption and decryption.
Ideally, each secret is:
- created for a particular purpose
- created for a particular entity (a person, machine or task)
- only valid for a set period of time
These parameters may not be practical in all the use cases, especially when the secrets management is a manual process, so we need auditing to know who accessed which secrets, and when.
When to carry out a secrets audit
You may wish to carry out secrets auditing if you want to:
- understand who has access to which secrets, and evaluate whether this is appropriate for your security model
- be able to provide evidence someone has gained access to some secrets to understand the impact of a security breach
- have confidence in rotating secrets
- see who has encrypted or decrypted a secret
- create alerts when sensitive secrets are being accessed
How to carry out a secrets audit
Your team should:
- log any changes to your access control list (ACL) and capture any deviations from your default, or expected access, ideally in Splunk
- automate the logging of secrets during the secrets life cycle, from generating secrets to rotating and destroying the secrets, if possible
- create alerts for use cases of access which may indicate a security breach
- look for any opportunities to replace secrets with ephemeral tokens, such as moving from hard coded AWS secrets in GitHub Actions to using Open ConnectID.