Are You Managing Your Secrets?

Do you know where your organization’s secrets are kept? The modern IT landscape is filled with secrets: certificates, cryptocurrency wallets, SQL connection strings, storage account keys, passwords, and encryption keys. Getting a handle on secrets management can be a top challenge.

Knowing where secrets are kept in the company is critical – and sometimes easier said than done. Maybe everything is encrypted, but scattered?

I hosted the webinar, The Secret to Secrets Management, to help shed light on helping organizations better store, manage, and protect their secrets, and ultimately, their data.

Here are questions I was asked, along with my answers:

How do you ensure that the third-party vendor is adequately managing secrets?

In short, you don’t. When we’re dealing with third parties and cloud providers, the best we can do is have a conversation with them. If they have some type of independent audit or review that is done, maybe some reporting from a trusted source that you could use as well. But if not, the best you can do is have a conversation with them around what you’re trying to achieve it and find out what they are doing and if you need proof, they can provide you more information.

How do you eliminate hard-coded in default passwords?

There probably isn’t a way to eliminate default passwords. Almost everything comes today with some type of a default password. I am often impressed with systems and applications that come with a setup process that have you set a default password. They’re not in an operational state. It actually reminds me of the early days of Windows; Microsoft used to ship its servers so that when you installed it, it didn’t open itself directly to the network until you clicked a button that said, yes, I’m ready to go on the network. What was nice about that is it didn’t automatically assume that whatever the default security was, that it was going to be sufficient for the environment. When it comes to default passwords, the one good thing is as a business, you usually have a fairly good idea of what systems you’re bringing into the environment, especially if you’re standardizing on certain hardware or certain applications or cloud services. You may be able to identify which of those have some type of default password. And sometimes the manufacturer will even work with you to change those things. I know Dell is pretty active in working with companies that buy volume to help set up things ahead of time. So you may be able to change some of those things.

Hard-coded passwords is hard. It happens for a reason. It could be hidden away, it could be buried in code and no one knows it’s there. So, it’s not great. But one thing you can do is by having source code repositories like GitHub or something like that, it makes it a little bit easier to do research on the source code that you have, at least the stuff that you’re writing in-house to look for that kind of stuff.

What are your thoughts on leveraging BYOK (bring your own key) as a root of trust for third-party or public cloud key management solutions?

I’m a big fan of BYOK and we’re actually trying to term a new one called Hold Your Own Key. BYOK is an interesting phenomenon, in this scenario you create your own public and private key pair inside of a hardware security module, and then provide it to a cloud provider in a secure way. The intent is if anything happens the cloud space or if I want to move my work load, I still have my key. I still have the ability to move it around. One of the things you need to keep in mind though, is just because you brought your own key doesn’t really mean that you have any way of affecting the security and control of that key once it’s copied to the cloud provider. Now if you’re using something like the Azure BYOK, you know that you created the key inside of the hardware security module, so that’s pretty straightforward. But the access and the use and the auditability of the key inside of the cloud provider is still very obtuse; it’s not very transparent to the end user. But you do have the ability to say “I’m not going to do business with you anymore. I’m going to take my copy of the key and put into another cloud provider.” I really look at BYOK as who owns the key, not necessarily who can control the key. Just because you’ve got it in your HSM for instance, you can’t somehow magically make those keys disappear out of Azure if they don’t comply.

Should we define a trust store as a secret?

If we’re talking about things such as certificate trust stores, I haven’t traditionally thought of that as a secret, in that a trust store really goes back to what types of secrets are we going to potentially trust. It’s not a secret itself, but that being said I think there are potentially some advantages to controlling the trust stores of not just individual certificates but trusted roots. We certainly see management of this space when it comes to the browsers from Microsoft and Apple and Mozilla, for instance. They trust CAs as a set of secrets and what they’re going to trust. And there are certainly ways of circumventing protections if that trust store were somehow circumvented. You certainly could classify and say there are certain threats that we have that we’re concerned about in our organization and we’re going to centrally manage that trust. Microsoft provides a mechanism where you can control what that trust list is going to be in your organization. So that certainly could be classified depending on your threat profile.

What are the best practices you would recommend for storing secrets securely on the CI/CD process?

I don’t know if I have a specific answer there. My general answer when it comes to passwords is: 1) Avoid them whenever possible. If passwords must be used, and this a personal preference here, if we’re going to use passwords, I’d much rather there be some type of secondary factor. Multi-factor authentication we talk about a lot. I really look at passwords as regardless of how securely I keep them, they are still guessable, still hackable. It’s simply a piece of information I know that somebody else could guess or steal or figure out. Regardless of how secure I do that, I could take a password and lock it in the best vault in the world, but if somebody guesses it, it doesn’t matter that it’s in my vault. Passwords and securely keeping them really should be seen as one step to the authentication process. So, use password vaulting systems, use some type of control around it, make them complex and don’t make it easy – but, I would not see that as the end of the story. I would classify any kind of password best practice as something that includes a multi-factor or some other type of secret that I can physically control or otherwise ensure is used that just can’t be guessed like a password.

Do you have a question that didn’t get answered? Send me an email anytime: thepkiguy@pkisolutions.com Did you miss the webinar? Listen to it here: https://www.pkisolutions.com/webinars/. Throughout the year, we’ll be hosting several webinars — keep checking back: https://www.pkisolutions.com/webinars/