Can you keep a secret? How about your organization’s data environment?
In an IT network, a “secret” is any compact datum that must remain confidential. Typically, secrets are used for authentication or as input to a cryptographic algorithm. Common secrets include:
Privileged account credentials
- SSH keys
- API and other application keys and credentials, including those used within containers, CI/CD systems, automation processes, remote desktop protocol (RDP) software, and even security software
- Database and other system-to-system passwords.
- TLS/SSL and other private certificates for secure communication
- Private encryption keys
Since IT network secrets unlock access to highly privileged systems and data, securing secrets is just as critical to preventing cyberattacks as securing end-user passwords. About 75% of ransomware attacks involve compromised credentials – most of the time, RDP credentials.
How Secrets Get Compromised
One of the biggest challenges to secrets management is secrets sprawl, which occurs when organizations use an ad-hoc approach to secrets management. Different departments, teams, and even team members all independently manage the secrets under their control.
This approach may seem reasonable at first. For example, a new microsite needs to access a database. The admin already has a configuration file with sensitive data, so why not secure the database access key in the same configuration file, then ensure that file is secured? This works when an organization has a relatively low number of secrets to guard.
However, as organizations grow, so do their data environments — and the secrets stored within them. Before the IT team realizes it, the secrets have multiplied like Tribbles — SSH keys alone can number in the thousands — and they’re sprinkled all over the network, in no particular order.
Hardcoded or embedded credentials are another obstacle to secrets management. Many software solutions, IoT devices, and other hardware are shipped with hardcoded, default credentials. If these devices and apps are deployed without changing the default credentials, cybercriminals can easily access them using scanning tools in conjunction with brute-force dictionary or other password attacks — or they can simply consult the device or app’s owner’s manual, which contains the default credentials.
In DevOps environments, common CI/CD pipeline tools such as Jenkins, Ansible, Github Actions, and Azure DevOps use secrets to access databases, SSH servers, HTTPs services, and other sensitive systems. These secrets are either stored in a config file for the deployment system or in one of a dozen different storage vaults, all of which provide wildly different capabilities depending on the product. In a scenario where admins aren’t storing credentials in config files or systems, they’re likely being stored in their DevOps environments. Whatever the case may be, admins may or may not have any auditability or alerting on usage of these secrets.
While some tools include built-in secrets managers, which enable organizations to remove the hardcoded/embedded credentials, the secrets managers work only with those tools, which doesn’t solve the secrets sprawl problem.
Keeper Secrets Manager: Zero-Trust, Zero-Knowledge Security for Your Network’s Secrets
Keeper is pleased to announce the launch of Keeper Secrets Manager, the first and only cloud-based, zero-trust, zero-knowledge solution for securing infrastructure secrets. Keeper Secrets Manager is fully managed and utilizes a new patent pending security architecture. Additionally, it leverages the same zero-knowledge security model as Keeper’s top-rated enterprise password management (EPM) platform.
With Keeper Secrets Manager, all servers, CI/CD pipelines, developer environments, and source code pull secrets from a secure API endpoint. Each secret is encrypted with a 256-bit AES key, and then encrypted again by another AES-256 application key. The client device retrieves encrypted ciphertext from the Keeper cloud, and secrets are decrypted and used locally on the device — not on Keeper’s servers.
Ready to see Keeper Secrets Manager for yourself?
Talk to an Expert
Additionally, all server requests are further encrypted with an AES-256 transmission key on top of TLS to prevent MITM or replay attacks. If you’re counting, that’s a lot of encryption keys! This multi-layered cryptography is handled transparently through our client-side SDKs, which are easy to integrate into any environment.
While competing secrets management solutions require customers to buy special hardware, install a proxy service, or use a specific cloud services provider, Keeper Secrets Manager seamlessly integrates into nearly any data environment, with no additional hardware or cloud-hosted infrastructure required. It offers out-of-the-box integrations with a wide variety of DevOps tools, including Github Actions, Kubernetes, Ansible and more.
Keeper Secrets Manager is a natural extension of the Keeper enterprise password manager (EPM). It is incorporated into the Keeper Web Vault, Desktop App and Admin Console, with integrations into Keeper’s Advanced Reporting and Alerts module, BreachWatch, Webhooks, SIEM integration, and compliance tools. For example, any hardcoded or embedded credentials stored in an organization’s Keeper Vault will be subject to BreachWatch scans, and IT admins will be notified if any of those credentials are compromised.
Find out more about Keeper Secrets Manager and schedule a demo!