Merge pull request #850 from Jonathan-Scott14/patch-3

Update secrets-auditing.html.md.erb

source/standards/secrets-auditing.html.md.erb

@@ -1,6 +1,6 @@
 ---
 title: Secret Auditing
-last_reviewed_on: 2023-04-26
+last_reviewed_on: 2023-11-15
 review_in: 6 months
 ---
 # <%= current_page.data.title %>
@@ -13,14 +13,17 @@ Ideally, each secret is:
 - 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.
+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
@@ -30,7 +33,15 @@ You may wish to carry out secrets auditing if you want to:
 
 Your team should:
 
-- log any changes to your [access control list](/standards/secrets-acl.html) (ACL) and capture any deviations from your default, or expected access, ideally in Splunk
+- log any changes to your [access control list](/standards/secrets-acl.html) (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
-- 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.
+  - 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.
+
+[Github's Secret Scanning]: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning
+[Partner Program]: https://docs.github.com/en/code-security/secret-scanning/secret-scanning-partner-program