KeyConf NYC Interviews – Centralizing Security and Secrets

David Spark: Chris, you just spoke here at KeyConf. Tell me, what was your presentation about?

Chris Holden: Yeah. So, I presented today on structuring a very segmented business organization with a lot of segmented business units and centralizing security in from with a single team. So, basically, wrangling the herd of cats that are all of our business units into one secure entity.

DS: Not an easy task, I’m sure.

CH: Not at all.

DS: Chris, about two years ago, you said that you had kicked off your secrets management journey. Take me just prior to two years ago a little bit before what made you realize we have to start a secrets management journey?

DS: Yeah, so I think it’s the thought process started much earlier even on premise. So, even before we started moving to the cloud and then once we started a big lift and shift to the cloud, it became even more of a requirement with multiple cloud. Very segmented cloud infrastructures, multi tenancy, stuff like the centralization for secrets became a growing problem. So, about two years ago, we kicked off starting to see what was out there from a provider standpoint. And that led to several iterations of the project starting and stopping from not really seeing a provider that we thought was a good fit for our company. Something with low cost of ownership. Something fairly easy to maintain. Something fairly easy to engineer. Something that we could purchase and deploy a reasonable amount of time, that did not require a whole lot of effort on the back end, but really provided the value of securely storing our secrets.

DS: Okay and what would be, let me ask you, if you could go back a few years ago, just as you began on the secrets management journey and looking for a solution. What is something you wish you knew back then that you definitely know now that you could tell to others? By the way, don’t do this.

CH: Yeah. So, get your users, the stakeholders, right. So, for me, my developers, get those folks involved as soon as possible in the process They’re going to be the end users. They’re going to be the ones interacting on a daily basis. If you can get them on board, it makes your life that much easier to sell the budgetary aspect of actually purchasing, onboarding, and deploying.

DS: What happened when you brought them in later? What was the response?

CH: Well, so it nobody wants to be told do this.

DS: No yeah. That’s just a human reaction right there.

CH: If you can help somebody though think it was their, not think it was their idea. But if they had some input in making that decision, they were a part of the testing group. They saw the value before we made the investment that makes it does two things, right. Selling to the business unit or the developing team is simplified A, and B the time to implement. They’re excited about it so they’re going to implement it quicker.

DS: Right, and you bring up an interesting point, because let’s say you do all your due diligence, you see the product and like, oh this looks great, oh we’re definitely going to employ. this I mean this works phenomenal and you don’t have others on board. This could be deep sixth, because we don’t know what this is, we got to go start at square one. And that could cost you a fortune to go begin all over again.

CH: Exactly.

DS: And you may not come back to the correct the same solution you wanted at the beginning.

CH: That’s exactly correct. So yeah, I’ve seen it happen before and especially we’re not dealing with one team of stakeholders, right. We have multiple teams of stakeholders. So, it’s not just one group that we have to get buy in from, it’s 5 or 6 different groups.

DS: And also, this is going to and what, let me also ask you, you know there’s more now than later. But because of that and I’m assuming the ultimate decision to purchase took a little bit longer because of that. Did they bring some things to like you’re like, oh well we didn’t think about that, let’s just double check that the solution can handle it. Did you run into that?

CH: Of course, yeah, and I think that’s again like to go back to having your stakeholders involved isn’t just to make your life easier as a CISO trying to bring in a solution but you’re not a developer, right. You’re not managing the development teams. You’re not managing the business unit teams. There’s a lot of nuances of their jobs that you’re not going to know or understand.

DS: Yeah, you don’t have hands on it.

CH: Exactly. Yeah.

DS: Yeah. Oh, so I mean and by the way, that is and I hear this again and again and again, the amount of knowledge and visibility you can get just having a conversation with a junior developer is astonishing sometimes.

CH: Oh, it’s yeah. It’s one of the, when I think about risk reporting, right. And who’s reporting these risks and other facets of our program. It’s the people with the hands on the keyboards. They’re better than our vulnerability management detection teams or detection scanners at some time. They’re better than our cement sometimes brings these issues to light. So yeah, that that reporting and that constant contact with the people with hands on the keyboard.

DS: And has that been, because I’ve worked at organizations like this where they have rigorous post mortems like once Project X is over, its like immediately feedback – what worked what didn’t work – especially to what didn’t work. Because I want to not do that the next time. Do you have a rigorous post mortem program?

CH: Yeah, so I wouldn’t call it rigorous but we’ve definitely adapted it over time. So, there we’ve moved more towards after action reports identifying kind of yeah, what went well, what didn’t go so well. And it’s just constant, I guess I don’t even look at it as a post mortem formally because I just.

DS: It’s you do this as an iteration type thing. It’s not a like, don’t tell me anything. Now, tell me something.

CH: Exactly.

DS: Tell me, tell me, tell me, tell me, tell me all the way down the line.

CH: Exactly So, formally, we’ve never called it that but yeah, I guess we do now that I described it.

DS: Okay. So, you have a more. It’s in a more of a DevOps model if you will.

CH: There you go.

DS: There you go.