Secrets Management vs Secrets Detection: Here’s What You Need to Know
As the name might imply, it’s important to keep secrets secret. Access to even the smallest of secrets can open a window for attackers who can then escalate their access to other parts of the system, allowing them to find more important secrets along the way. Poor practices can leave many secrets lying around unprotected and just one seemingly unimportant secret can lead to a broad security breach.
What are secrets?
Secrets are private credentials that are often the keys to highly sensitive data. They include:
- Database passwords
- Privileged account credentials
- SSH keys
- Encryption keys
- Third party tokens
- API keys
- Private certificates
Secrets themselves are fairly straightforward, but tracking and managing them manually can be a complicated if not impossible task. Many applications rely on thousands or even millions of secrets to function. Secrets accumulate in all directions over time and across versions, installations, and layers of code, so it’s important to manage your secrets well and detect (and revoke) any secrets that have been left where they shouldn’t be.
How are secrets mismanaged?
Hardcoded secrets. Hardcoded secrets are stored in plain text in source code which may be revealed accidentally, such as in public repositories or code snippets shared on forums or blogs, or maliciously via hackers using other application vulnerabilities and weaknesses to expose the source code.
Use of default credentials. Products often ship with default credentials to make deployment and administration a simpler process. If these credentials aren’t changed for each installation, bad actors can quickly exploit multiple organizations. Hardcoded default credentials are especially risky.
Stored in configuration files. To avoid having secrets in the source code, developers will sometimes instead store the unencrypted secrets in config files. These files sometimes end up in public repositories (oops) or threat actors can gain access to them in other ways and even change passwords to ones of their choosing. Beyond that, having different secrets in different config files just makes things more difficult to track and secure.
Manual management. Manually managing secrets tends to lead to the use of easier-to-remember (and easier to guess) passwords that are shared among coworkers and not changed often enough. Modern applications are huge and complex, making secret management extremely difficult, especially when they’re spread across many layers.
Secrets management
Secrets need to be protected both in transit and at rest with strong encryption. Good practices include:
- Role-based access control
- Using the principle of least privilege
- Keeping an audit trail
- Keeping secrets in protected locations
While secrets management isn’t one thing or one tool, tools do help automate the process. Secrets management tools allow you to centralize your secrets in a secure repository, not unlike a personal password vault geared toward machine use. They also enforce best practices like changing passwords frequently and offer access control, rotation, and monitoring.
There are many built-in and third-party tools that automate the process of secret generation and distribution. Many cloud providers offer their own tools, such as AWS Secrets Manager (Amazon), GCP’s Secret Manage (Google Cloud), and Key Vault (Azure). Orchestration platforms like Kubernetes also have their own ways of helping you manage secrets.
Secrets scanning and secrets detection
So you’re managing your secrets correctly now. But what about those secrets that are already out in the open? Or the ones that developers might neglect to follow best practices for in the future?
Secrets scanning tools detect secrets in unprotected locations so you can find the layer they’re on, revoke them, and put new ones securely where they belong.
If you are only beefing up your secrets management for the first time, you’ll need to know where they’re still hiding in your codebase.
But don’t stop after scanning your currently deployed code. Secrets may also exist in previous versions of code that are no longer used, but are still accessible, as version control systems by their nature keep a history of all modifications to the codebase. If these secrets are or can be publicly exposed and not detected and revoked, the current version of the application can still be at risk. You should use scanning tools not only across your current source code, but across historical versions of your application as well.
Even after secrets management tools have been put solidly in place, it may be necessary to scan for secrets in order to find newly created weaknesses created by bad developer practices.
Just between you and me…
Secrets are a big deal, and mismanagement of secrets is one of the most overlooked weaknesses in AppSec. Only the very smallest of projects can securely manage secrets manually. For everything else, tools are necessary to both detect secrets and automate the processes of securely storing and accessing them.
