KeyConf NYC Interviews – Secrets Management Best Practices

David Spark: You just did a panel on secrets management. Give me the summary.

Vinay Puri: The summary is here getting the panel though, but the summary here why I’m here today is want to talk about brainstorm about what are those best practices we should be following. When we have this product build right from the stage of build and we take it all the way back to the clients, how do we embed the secrets principles and make that confidence level higher from that product when it is offered in a size space service or maybe even at the product is offered as a service, right. Or not only that within our space within the Thomson Reuters let’s say my company if we have the tons of applications how do we utilize those secrets. Whether internal facing threats or external facing threats or middle level threats, right. Or the interface threats or hybrid environment threats.

How do we embed the secrets into right from the design stage and how we have these best practices labeled? So, that’s all we about we want to discuss that.

DS: Perfect. Vine, best practices in Secrets Management. Where do we begin?

VP: I think we need to begin from the right architecture, right. If we know the use cases, if we know the scenarios in our environment and if we clearly have a road map with respect to those use cases and the scenarios we want to tackle. I think that’s a very futuristic road map rather than just hunting for the product building that product and then we miss 50% of the cases. So, build architecture with the great scenarios and have the integrated view of the architecture and then roll it out as a plan.

DS: So, you’re talking about understand the policy you’re setting up first. Who’s going to be using what for what purposes? On your, again this is a moving target I’m assuming. How should I build out that beginning, so I’m not causing too many problems at the very beginning? Because again it’ll be a moving target. You’ll step on a few toes at the beginning. How do I build it out as best at the beginning?

VP: Perfect. So, they can be use cases when the product is already rolled out, it’s already built, then you have some certain practices you can bring it back, right. And you can do these high-level architecture reviews and you can embed there but the ideal state is when you start building the product itself. When you start building the product itself, what do you build the product for? There is always the user stories around that product, right. Start building your security user stories along in parallel with the user stories.

Have the buy-in from those owners which are building those products. Have them understand. It’s a value add. It’s not the security you’re building, it’s not the fences you are turning around, it’s a value add right from beginning. And if you bring this value add, you have the customer trust right from the day one. So, first have the buy-in of those owners. Start building your security users stories and those security users’ stories are going to cover all the scenarios across the organization. Which secrets and which kind of a secret we will be using, right. Secret can be API secrets; secret secrets can be as complex as ah some of the strengths and some of those particular things in the tokenized way.

Secrets can be as simple as user and password which are floating around in a very, you know it’s not even encrypted. So, entire space of the use cases once we are built. We have this inventory of the secrets we would be. Then second stage is, how do we commonalize those patterns. What are those patterns? How those secrets will be floating in this organization. Is the pattern is application to application? Is the pattern is going to be application access to the outside party, third parties, those who going to be using this product. Build all those patterns.

Now you have the patterns. You know what secrets you want to use it. Create the architecture. Create the best dependable architecture which is going to be future looking not backward looking. So, what that means is basically take care of some of those latest technologies which are coming. For example, container eyes, right. Every word is moving towards not in the on from servers, right. We are moving towards container. Think about the containers. How they will be utilizing those secrets. How when the tokens will be rotated when we are going to the cloud.

So, think futuristic, build those architectures and realize those architecture and then look for the best product. Which is that best product in the market which is going to take care of all those patterns and all these use cases and then realize the trade. Then build the implementation milestone plan and go for it. That’s a right view of doing it.

DS: Alright. So, let me go off of that what you were just saying of the criteria’s one should look at when considering a Secrets Management program are, how would you answer that?

VP: So, criteria’s with respect to so I would say that I think I answered it a little bit in the previous version

DS:  Right.

VP: So, criteria should be with respect to the particular Secrets Management program. How you are using particular secret when you want to talk as a user to that resource. Resource can be application resource can be the outside out road facing application. This is the criteria one of the criteria which should be there. And certainly, it should be aligned to the company policy. It should be aligned to the way the product needs to be launched, right. What is that if the product needs to be FedRAMP compliant. Let’s say it needs to be PCDS is compliant, the things will change, those criteria will change. So, certainly have those policies aligned standards aligned and then follow the best practices. Best practice comes with the guidelines which you build around those which are upward looking to the standards and policies. Follow those criteria’s, right. So, these should be all part of the criteria.

So, scenarios use cases and should be map to those policies as a standard we meet everything in a well-rounded one big bucket and then go for it.

DS: And when someone is first adopted secrets management, they’ve done the criteria they’ve deployed it. What are some of the common sort of first user mistakes that you are seeing?

VP: Yeah, that’s a great question. Some of those common mistakes we do it, we build those things in, let’s say I build API. Let’s take this scenario here. I build the API thinking my organization. I won’t build the API how the third parties will be utilizing that. That’s a common mistake we generally do it. So, I think build that API and then build the security embedded into that – how we would be utilizing insight, but also build the strategy around how I will be exposing that APIs to the outside world if I am boosting that product in my use case. If my use case is I’m going to host that product my external parties are going to be using it.

From the developer standpoint internally how, I will be using it, I have well taken care of. But how the external parties will be using it I am not well taken care of. So, I think that’s where some of the practices, how the authorization will take place for the external parties when they arrive. Are we using the best protocols, OAuth2 and whatever, right? And then have the access mechanism sorted out? Are we using the API gate phase for them to allow? Do we white label those particular clients when they come and use our APIs? Am I limiting when the API call comes in this scenario in my use case? Am I limiting the amount of information I’m passing from my systems to them, right? Am I end up passing your information as a PII as well? That’s a common mistake which can happen, right.

So, some of those trains, some of those patterns which needs to come as a calls, right. In the IT world, those are the API calls we call it and it should only be contain with the sufficient information which needs to be given basis and which is required to be not that everything should be available, right. So, when the call comes its very particular workload should take information from and give it back to the client. Rather than whole landscape lateral landscape is available, right. That’s a major mistake we do it and that’s where if we can contain it in the design, that’s a win-win story.

DS: Excellent. Thank you so much Vinay.