Secret Auditing
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, when, and for what purpose.
When to carry out a secrets audit
Secrets auditing can be a continuous or sporadic process (i.e. automated or manual).
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
- confirm whether your onboarding/offboarding processes are working as intended (particularly in evolving privilege for movers)
- 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. If you have documentation of secrets, you should make sure this is up to date as it can be used to underpin the audit process.
- 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
- this should include use of high risk secrets, such as break-glass accounts or root
- look for any opportunities to replace secrets with ephemeral tokens, such as moving from hard coded AWS secrets in GitHub Actions to using OpenID Connect.
- consider using Github’s Secret Scanning features, as well as using their Partner Program features
- consider whether your use of secrets can be reduced by relying on e.g. automated CI/CD processes (such as Terraform etc)
You should be conscious of the impacts of automated secrets rotation on service users. There may also be legal/contractual obligations to consider if you are changing how you manage user secrets.