Interview: How To Better Manage Your Corporate Secrets

The importance of corporate secrets when it comes to securing the applications, services, and devices we use every day cannot be overstated. Over 80% of data breaches involve the use of stolen credentials and, with the average cost of a breach rising to $4.24 million USD in 2021, the problem is now more acute than ever. 

However, securing important secrets such as API-keys, database passwords, access keys and certificates is a major challenge. These critical credentials are often hardcoded into CI/CD systems, source code or config files, making them far too easily accessible to hackers. 

To help DevOps teams, IT security and software development teams to securely manage these infrastructure secrets, Keeper Security, a leading cybersecurity platform known for its consumer and enterprise password management solution, has launched a new product: Keeper Secrets Manager.

We spoke to Zane Bond, Keeper’s director of product management, to discuss this new solution and the need for better management of corporate secrets. Bond has worked in the cybersecurity industry for the past 20 years, working across various areas including endpoint security, network vulnerability scanning and remote access control. 

What is Keeper Secrets Manager, and what are its use cases for securing corporate secrets?

Keeper does a really good job of managing, storing, and handling credentials and passwords for users. But there’s a series of use cases now around a very similar set of workflows and credentials, except the users are machines. If your website starts up, and it needs to connect to a database to get a list of things to present on a page, generally what happens is somebody within the organization decides; “I’ve got this website, I’ve got this credential,” and it has to make the connection. But where the credential is stored becomes tricky. And there’s three main places they end up.

First off, you could just store it in a flat file, or a config file and hard code it in there. Generally, when you do that, your spidey-sense goes off. Like, “I’m putting this plaintext password in a configuration file on the server, I really should protect that somehow. I don’t know how, I need to get the website up and running, we’ll figure that out some other day.” Some other day doesn’t always come. 

The second use case is, “Alright, I’m going to get smart about this, I’m not going to hard code it in the configuration file, I’m going to put it in the source code. And when the source code deploys, it’ll encrypt it or abstract it or compile it.” And again, every time you go through that page, or any other engineer reviews the source code, you see that plain text password, it’s just sitting there.

The third area is, “I’m going get extra smart. And it’s not going to be in my source, it’s going to be in my CI/CD system. So, it’s only going to get used when I deploy it.” And, again, you run into a similar issue where it’s a static password, it gets put into your CI/CD system, and there are potentially too many eyes on this secret. And if you’ve got five different systems, you’ve five different repositories, and everything’s all over the place. 

Keeper Secrets Management solves all of these not-great practices around managing your secrets credentials, API tokens, SSL certs, SSH keys; all this stuff you need for business to successfully run. We keep the credential stored in a secure vault with zero knowledge zero trust, enterprise-grade encryption, and when the system needs it, it’ll get the credential from the cloud.

Why is it so important that corporate secrets are stored in a secure platform?

You hear this statistic all the time: 80% of breaches involve credentials in some way, shape or form. They are a high-value target for an attacker. But in general, the attacker is not trying to get your desktop password. That’s not the goal. The valuable information is in your environment––it could be your source code, it could be your customer lists, it could be where you store credit card information, it could be where you store all HR information or documents. 

Those types of data are usually accessed exclusively by machines. So typically, the entry point [for an attack] will be a desktop or laptop, because somebody clicked on something. But after that, there’s going to be recon to figure out the environment and there’s going to lateral movement in your environment to get to the crown jewels.

Secrets management helps protect those most sensitive credentials. So that when somebody is spelunking around your network and doing recon, and they find an apache config file and they’re like, “Sweet, I’m on the web server, I found it!” there’s no password in there, so they can’t directly connect to the database. That’s why it’s so important to protect these secrets—they access your crown jewels.

Who are the target customers for Keeper Secrets Manager?

Keeper as a whole is an enterprise and a consumer password manager. If you have a heartbeat and you’re on the internet, you are a target customer. You can’t exist in today’s digital world without having dozens, if not hundreds of logins, passwords, and accounts. So, the Keeper platform itself is built for anyone, everywhere. 

Keeper Secrets Manager is targeted more towards engineers, developers, DevOps shops, IT—the people that actually access and configure and deploy an app to manage those most privileged credentials that exist in your environment, and your most sensitive assets. 

For that group, what features are most important when it comes to secret management?

Security gets in the way of getting your job done. It’s a difficult challenge to complete all of your business objectives, do whatever you need to do to make your business successful, and keep that secure. 

Secrets Manager tries to make the introduction of robust security as simple and easy as possible. You don’t have to deploy a new server or a new vault, it’s all in the cloud. You don’t have to pick up or rewrite how you authenticate to a completely new mechanism. It’s asking, “What are you already doing? Let’s integrate with that.”

If developers are putting it in their source code, that’s great. We have an SDK in every popular language. Whatever you are developing in, just use our SDK, and it’ll pull the tokenized passwords instead of hard coding them, which makes it safer. 

If you’re on the deployment side, what are you already doing today? Do you have Jenkins? Do you have Kubernetes? Do you have GitLab? All those solutions out there, that’s great. We integrate with those. And maybe you’re an IT pro who just has some configuration files or some scripts, right? When a script initializes, you can have it call the Keeper system and pull the credentials dynamically, without having to rewrite the whole script.

Some of the strong advantages in what we provide are: it’s super easy to use, you don’t have to rewrite your code, and it integrates with your existing workflow, however you’re already deploying and developing your systems.

What advice would you give to developers who are currently managing corporate secrets, but may be unsure about using a single platform to manage them?

Stop hard coding stuff! If you’re not going to use our product, that’s fine. Just don’t put hard coded credentials out there. It causes so many of these breaches, the big-ticket ones. 

Look at the Target breach, that was a default password in some server management software. Look at the recent SolarWinds breach, they used “SolarWinds123”. There are so many bad password practices in our industry, that we know better. Just do better.

You can find out more about Keeper Security here. 

Expert Insights provides leading research, reviews, and interviews to help organizations make the right IT purchasing decisions.