This blog series is split into four parts:
- General information of secrets management
- Example how to store secrets into a version control
- Example how to use encrypted secrets in CI-pipelines
- Security issue and threat analysis based on previous examples
I’ll provide a small threat and security issue analysis based on this blog post series and the examples used, case-by-case.
Compromised personal or service account cloud credentials
It is possible that some member’s or service account’s credentials are compromised one way or another.
Simple steps for protecting compromised accounts:
- Revoke and reissue credentials
- Regenerate API keys
- Look logs for unauthorised access and usage
- Remove unexpected resources on a cloud platform
At least the Google Cloud Platform (GCP) has its own detailed guide for compromised credentials which can be read here: https://cloud.google.com/security/compromised-credentials
Last but not least: always use the multi-factor authentication for personal credentials.
Reducing vulnerability to a key compromise
If an attacker gets access to the key and encrypted secrets then all the secrets can be exposed – well, game over. The attacker can take your skeletons from version control and use them to carry out harmful acts like exposing IP addresses, passwords, API keys or even something worse.
However, you can reduce vulnerability to a key compromise with a few simple things.
Don’t re-use keys too often
With proper secrets management, you should never use a single, ”one-and-only”, key for encrypting and decrypting all the secrets you have. You should create a new key which has its own purpose and encryption and is only for specific data.
In this blog series, I’ve used only one key to demonstrate how Mozilla SOPS work. You could make environment or version control repository based keys which would make things harder for an attacker. In the Very secret development operations, part II: Storing skeletons into a version control -blog, there was an example of how multiple different keys can be used with environment-specific rules (Advanced usage – Creation rules configuration).
Rotate keys and remove old versions of a key
Key rotation is a simple method to prevent key compromise: the old version of the key is versioned to history and a new, primary version of the key is created. Only the primary key is used for encrypting (and decrypting) the secrets while the old versions of key are used only for decrypting the secrets. Still, an attacker can have an old version of the key and use that for data leakage – but not for long if you remove old versions of the key!
You can manually or automatically rotate or destroy keys in cloud platforms. GCP has multiple guides regarding key management like:
In the Very secret development operations, part III: CI-pipelines -blog, there was an example of how to setup rotation period for a key, so GCP rotates keys automatically.
With SOPS you can renew the data key from the secret by command:
sops -r test.enc.yaml |
For further reading about key rotation with SOPS: https://github.com/mozilla/sops#key-rotation
A person leaving the project/organisation
If a person is leaving a company or a project they can be a sort of security issue if they still have access to resources after they have left. You have to always revoke access to all systems and keys which they have used.
While SOPS handles access to keys automatically, you only have to revoke access to cloud platforms and servers where your keys are stored. GCP has a good guide for revoking access to different resources: https://cloud.google.com/security/data-loss-prevention/revoking-user-access
Also, remember to revoke access to version control – like remove a member from a Gitlab group or project.
What could happen after a compromise?
As I mentioned earlier, an attacker could use a compromised key to make harmful acts like exposing IP addresses and passwords. But things can be even worse than that, so I’ll mention a few aspects.
- Loss of sensitive information
- Personal data
- Industry secrets
- IP addresses
- Financial losses
- Illegitimate financial transactions
- Fines
- Compensation to customers
- Loss of reputation
- Customer
- Professional
- Business
After all, your business can close down pretty quickly after the security breach. So keep your skeletons well hidden and secure secrets with proper secrets management, follow common security practices and follow, or even create security policies for your business and project.
Further reading:
- https://www.cryptomathic.com/news-events/blog/cryptographic-key-management-the-risks-and-mitigations
- https://info.townsendsecurity.com/definitive-guide-to-encryption-key-management-fundamentals
- https://www.ekransystem.com/en/blog/best-cyber-security-practices
- https://www.infosec.gov.hk/english/technical/standards.html
