CISO/Security Vendor Relationship Podcast Live Recording at KeyConf NYC
David Spark, Creator of CISO Series
David is the owner of CISO Series, a media brand specializing in cybersecurity. We currently have five shows on our network (three podcasts and a weekly live video chat). He also owns Spark Media Solutions, a B2B content marketing agency for the tech industry.
David Spark: Thank you very much that voice, wherever it’s coming from.
Admiral Mike Rogers: That’s it. Come on, baby.
David Spark: Hey everybody, come on in. Come on in. I guarantee this is going to be fun. Those of you having drinks, come on in. Come on in. Join us.
Admiral Mike Rogers: Remember, must be present.
David Spark: So, we’re going to start the recording in just a moment. Please come join us. Get a seat up front. We love it when you’re up front. Please, if you do need to talk, if you do need to have a conversation, do me a favor, go away from us. Stay far away.
Admiral Mike Rogers: He meant that in a very warm loving way.
David Spark: Because we’re trying to record a show and we don’t want your conversation a part of it. But we want you here. Thank you. Oh, thank you so much. Alright. Ah, you’re so kind thank you so much. Alright, so here’s how it’s going to work. We’re going to do a live show. We’re going to start the recording. If any of you have ever heard the show the CISO Security Vendor Relationship podcasts, that show right there, you know that we have all these musical bumpers and it goes all through, we’re going to play that. And you, we have microphones on the audience as well. So, you are going to be part of the show. So, please, make the appropriate noise when appropriate at any time through the show. Please feel free to do that. If there’s a little flub, no big deal. We edit things out. But we’re going to try to make a nice clean, roll a show for you, make a real fun show for you in general. Just so you know, the episode that we are recording right now will be on November 30th on cisoseries.com. So, you can look for it there. Also, just keep in mind, we’re going to have a series of rotating guests too, but I’ll explain that also we show. Anyways, gentlemen, are you ready?
Admiral Mike Rogers: Ready to go, baby.
David Spark: Alright, we’re ready back there. We’re recording? Yes. Yes, we are recording. Alright, good. Let’s begin.
Moderator: 10 second security tip. Go.
Admiral Mike Rogers: CISOs must learn how to communicate their activities, their intent, and their strategies in ways that non-technical people understand. And the way a CISO talks to an HR person is not the same way you’re going to talk to the CEO, it’s not the same way you’re going to talk to the general counsel. Last quick story. The very first time in the job, I’m getting ready to go out and see the President of the United States and I’m going to brief him on cyber security strategy. I sit down with my team, they go through this great presentation, at the end of which, I look at them and go, “Guys, that’s great. You and I understand this. If I talk this way to the President, he will just look at me like I am an idiot. We have got to learn how to communicate in ways that he and others can understand.” So, I’ve lived this myself.
Moderator: It’s time to begin the CISO Security Vendor Relationship podcast, recorded in front of a live audience in New York City.
[Applause]
Admiral Mike Rogers: Work it, baby. Work it.
David Spark: Welcome, everybody, to the CISO Security Vendor Relationship Podcast. We are live in New York City. Prove it to you that you’re actually here.
[Applause]
David Spark: Yes, we’re actually here. Those of you standing in the back, I see plenty of chairs up here in the front. Please, feel free. There’s not going to be a point where you’re going to want to run out of here. We’re going to have fun for the next 45 minutes. Joining me on stage is a guest CISO that I’ve had on the stage before, but he’s taken on a new title. He is JJ Agha, the CISO of Compass. JJ, thanks so much for joining us.
JJ Agha: Thank you for having me. And I was telling David, this is my second time in the city since the pandemic, and both have been for the CISO podcast. So, I’m glad to be here and guest co-hosts with David.
David Spark: So, this is a reason to come into the city, as evidenced by this nice, wonderful crowd out here as well. Our sponsor for today’s show, who happens to be the sponsor of this conference called KeyConf, which is happening here in lovely New York City, is Akeyless. They are a secrets management company. And we are going to talk a lot about secrets management tonight. And we’ll be talking about things related to that, like Zero Trust and secure access and whatnot. But the gentlemen that you heard at the beginning, he’s going to be our first guest. We’re going to have a series of rotating guests throughout the show, and really thrilled to have him here. As you can see that he’s worked in a high-profile position before, as you have heard in this to beginning tip. It is the former NSA Director and commander of US Cyber Command, Admiral Mike Rogers. Mike, thank you for joining us.
Admiral Mike Rogers: Hey, David, thanks. Great to be here today.
Moderator: Close your eyes and visualize the perfect engagement.
David Spark: So, on May 12th, President Biden signed Executive Order 14028, quote, “Improving the nation’s cybersecurity.” There were tons of key points, but I’ll zero in on the need to improve sharing between the government and private sector, improving standards and supply chain security and the need to adjust network architectures so as to adopt Zero Trust cybersecurity principles. Mike, I’m going to start with you on this one.
Admiral Mike Rogers: Okay.
David Spark: Three questions. Of the items on the executive order, which is a lot more than what I just listed…
Admiral Mike Rogers: Correct.
David Spark: … what’s going to be the easiest to accomplish, the hardest, and which one do you believe is the most critical?
Admiral Mike Rogers: So easiest, I would say is probably Zero Trust. Now it’s not easy, but it is within the span of control of most organizations.
David Spark: A lot of people are shocked. I’m shocked to hear you say that.
Admiral Mike Rogers: You can do this yourself. Well, compare the other 2.
David Spark: Okay.
Admiral Mike Rogers: The one that I think is the hardest is supply chain. Because in part, much of it is outside of your direct span of control. And quite frankly, you are going to have to work with others to create the changes you need. And that’s not always easy. The one that I think is the most, in some ways, most important in terms of long-term, I would argue the information sharing piece. Because, quite frankly, if we cannot come up with a better collaborative… I don’t like the phrase collaboration. I like integration. I like the idea we’re going to work side by side 24/7, particularly in key areas within the private sector in the government. The whole idea of the government supporting the private sector, not the other way around. I think the information sharing piece is the hardest. Because if we can’t get that, it’s like you are fighting with 1 hand tied behind your back.
David Spark: So, this is a discussion we’ve had time and time again. And then always the issues of the, “But well, and we can let this information get out,” let’s just start with the positive here. And I’ll start with you, JJ. Where have you shared information and it’s actually worked?
JJ Agha: So, I share information typically through the FBI, if there’s ever a ransomware. And then secondly, it’s through your peer network. You have a trusted peer network where you would want to share hashes and IOCs. That transparency where you already have a built agreed-upon trust, you’re using typical flags on how to share information. But I think one of the big things looking at the executive order is just having a repeatable runbook. Right? So, following what Mike talked about with transparency, well, how do I actually give this information out? How do I share? Right? Do I called every AG and every State AG attorney? Do I go down and reach out to every single FBI bureau that that I need to reach out to? We need a repeatable process for the private sector. And using a runbook will just help unlock every single step. Very similar to the Zero Trust conversation, very similar to the transparency conversation about sharing information.
Admiral Mike Rogers: Yeah. There is no doubt we’ve got make this… I give you 2 examples that come to mind. SolarWinds. So, the main the main target was governments. Not the only one, but the primary target. And yet who discovered it? Wasn’t US government, was the private sector. And I’ve kidded Kevin Mandy, about this, it’s great that FireEye came forward. I said, “But Kevin, you spent 2 weeks internally investigating this, then by the time the government gets it, we’ve got to be working together side by side.
David Spark: This is just more eyeballs on the problem. Like as great as the government could be, or is great as a private sector can be, if you just got more eyes on the problem, everyone’s in better shape.
Admiral Mike Rogers: And you get more data, more data this way.
JJ Agha: Yeah, I think the issue is that we stigmatize incidents. We stigmatize breaches. You see on every single ambulance chasing with every single vendor. You see it on the news where everyone’s worried about the stock price dropping. But typically, you see a drop and then jumps to 20% above market value.
David Spark: We just had a guy from the Verizon data breach investigation report at another conference I was at, showed a chart that 6 months after public companies that had a breach, there was absolutely no difference in terms of where their stock price went. It was equal essentially bell curve distributions.
Admiral Mike Rogers: Because I would argue some organizations use this as a way to come out stronger to build your reputation. Look at how FireEye was built. I thought they came out stronger. I think people were impressed by open, transparent, “Here’s what we know. Here’s what we don’t know. Hey, this happened to us, we acknowledge it. The important thing is to make sure it doesn’t happen to you. Now, let’s focus on how we’re going to make sure it doesn’t happen.” I give them big points. We need more like that.
David Spark: Alright. Final thoughts on this, JJ.
JJ Agha: So, I think a another example was the Co Cov incident, a supply chain attack on the application stack and talking about the SDLC. And they did a great job without being transparent and just giving you information as they found out. And it was a fluid conversation. It was a dynamic conversation. They weren’t scared about opening their doors and saying, “This is what’s happening.” And it caused them more eyeballs on the problem and more folks were providing solutions to the challenges that they were being faced with. So, I think just being open, being transparent will pay dividends than trying to keep it close to your chest and trying to hide it away. Because that’s where you’ll end up with cake on your face a year down the road.
Admiral Mike Rogers: And in the end, you can’t control it anyways. I used to say in government, “Guys, we need to work as if everything we do is going to become public knowledge. Okay? It just makes life so much easier.” The decisions aren’t easy, but in the long run, it’s the smartest way to do business.
Moderator: What’s the best way to handle this?
David Spark: So, as I mentioned, we’re going to have a host of characters who are on stage. And I’m very excited to have our next guest who is literally sitting right down now, and he’s got some stuffed animals for us.
JJ Agha: Thank you.
David Spark: These look like stuffed guerillas.
Oded Hareven: Well, people, I just I thought about this.
David Spark: Well, let me introduce you for a second. This is a Oded Hareven, who is the CEO and co-founder of Akeyless. And is this the Akeyless Guerrilla? What is this thing?
Oded Hareven: This is the Key Kong.
David Spark: Oh.
Oded Hareven: Key Kong. This is Key Kong.
David Spark: Oh my god.
Oded Hareven: Come one.
David Spark: Who’s getting blamed for that horrible joke? Is it you? Well,
Oded Hareven: We have [unclear]
David Spark: Alright. We’ll put a picture of the Key Kong on there. Alright. Here’s my question here. What are the problems with secure remote access that we’re still struggling with? Over on the Cloud Security Alliance blog, Alex Vaclav asked this very question. He brought up 2 interesting issues, that more of a company’s network is being transferred to the cloud, and that’s causing new issues that companies weren’t prepared for. And secondly, maybe I don’t want uniform access for all employees. So, certainly employees maybe should have higher tier access requirements. So, JJ, looking back at the beginning of COVID and now, what do you believe has been the biggest changes of how you’re handling secure remote access?
JJ Agha: So, I think when COVID broke out, it was a mass stash to getting secure remote access up and running. Right? We have to secure the workforce. We have to ensure that the business can continue to operate. Right? And that was the main operative. Now, if you look at where we currently are, it’s following kind of these Zero Trust models. Right? The idea of multiple concepts coming together, creating that conglomerate of ideas and really following kind of these privileges, really tackling IAM, tackling asset management to improve secure remote access and just kind of getting away from the, “You know what? We have a gateway. We have a proxy. Secure remote access has done.” That’s 1% of the problem. The problem is diving in deeper. And once you start kind of evolving that as the company matures, as you need to start bringing out different risks and different patterns, you could solve for the longer patterns or now I think, as we progressed over the time over the 2 years, it’s really solving and standardizing on patterns and moving away from kind of the anti-patterns. And our developers really have kind of embraced that. And they’re really diving into, “Hey, I have this SaaS app. I have this new endpoint. How can we actually look to get behind there secure remote access and not just say, “It’s behind the poxy?” It’s, “Well, what authorization is needed?” But I think that’s the next question. Right? You could solve authentication, but what are they authorized to do? And how can you make that dynamic and move away from static conversations?
David Spark: So, connecting the identity with the application and the data, all 3 together?
Oded Hareven: And the network.
David Spark: And the network.
JJ Agha: And the network.
Oded Hareven: I think that this is… I’m sorry to interrupt. But I think that this is one of the most interesting things around secure remote access. Basically, it’s an in… Yeah, I know, the Key Kong. Yeah, Key Kong. But anyway, so one of the most interesting part with secure remote access is that, today, well, usually or traditionally would have thought as the remote access as a problem along maybe a network security. Right? VPNs for that sense, then it’s done and it’s fine. But what happens the last few years is that we see convergence between those 2 worlds, between the network security and the IAM, or the access management for that sense. So, now, people are looking on more of a holistic approach, which means that you need to somehow combine your VPN together with your maybe privileged access management, together with some session recording tools, and so on. And their problem is, as this particular person that you were mentioning, the problem is sticking all of those all together. It’s a lot of tools. And what do you do with it? Obviously, I see it as an opportunity, both for those teams also to be working together the network of people that are usually entrusted with Zero Trust initiatives together with the IAM people.
David Spark: So, one of the things that this author Alex was mentioning about the fact that, if you have higher tier people, you put more checks in place. So, the idea is, if a person is sort of an employee that only needs sort of low access, doesn’t really need any high access administrative access, you’re not putting that many checks in place. Do you, in your environment, JJ, do you have more checks in place for people like who are transferring money or who have admin access? Or are you getting like kind of everybody the same level of checks?
JJ Agha: So, I think you have to look at the what you’re trying to solve with a secure gateway. If it’s a VPN, are you trying to solve for the network transport layer? You’re trying to encrypt all the packets that go over it? Well, could you put the controls as close to the application as possible to the software to the user? And I think that’s where you’re seeing this kind of idea where the convergence of networks and applications, that is happening when you’re going to the cloud. Right? You need a service. You need identity. You need asset. And they all need to talk to a data store. But you can’t conflate all 3 of these identities to be 1 of the same. A service-to-service authentication, a identity-to-service authentication to data store, they’re all different. But for us, I think the approach is the conversation, what is VPN actually solving? And I think it’s not solving anything anymore. Right? You have DNS SEC. The packet layer of what you’re trying to solve for for VPN kind of goes away.
David Spark: And what you’re seeing, it’s just too far away now?
JJ Agha: And if you look at the OSI model, potentially. Yeah, because if you’re looking at it, it’s sitting right in the middle. I want to get as close to the data store. I want to get as close to the application as possible. And this is kind of in the middle. So, it does a little bit of something. I could say, “Hey, you only have access to the subnet.” But what will exists in my subnet? I need a policy broker. I need a policy engine. And that’s where I really get down to the Zero Trust kind of solution. But again, it’s combining these multiple technologies and having kind of that holistic approach to solve for it. And then you could actually build something that’s scalable. But otherwise, you’re going to have a VPN here. You’re going to VPN out to your Azure network. Bastion host to get to your back end infrastructure. It’s just a mess of a hodgepodge of multiple solutions. And so, Zero Trust is there, secure remote access will follow the lines of what Zero Trust should be solving for. It’s just going to take a matter of time and continuous iteration to get there. It’s not a one shoe fits all. It’s what patterns is your organization need? And then what infrastructure could support your patterns? And then go implement that.
Oded Hareven: Well, I couldn’t agree.
David Spark: Okay.
Oded Hareven: No, that’s fine. I couldn’t agree more. No addition on that.
Moderator: It’s time to play, “What’s worse?”
David Spark: Alright, everybody. For those who are not familiar with our show, we play this game called, “What’s worse?” where we give you 2 scenarios, they’re both horrible, you’re not going to like either one of them. And it’s a risk management exercise. You have to determine which of these 2 scenarios is truly worse. And I reached out to Nir Rothenberg, who’s the CISO of Rapyd, and asked, “Hey, could you give me a couple of ‘what’s worse?’ scenarios in the area of secrets management?” So, it’s tailored just for you.
Oded Hareven: Oh, thank you.
David Spark: Good?
Oded Hareven: Thank you so much. What a surprise. I like it.
JJ Agha: A lot of pressure.
David Spark: So, they’re going to be 2 horrible situations. And we’re going to play 2 rounds of this, by the way. And by the way, the audience, you’re going to be voting too which one you do like and don’t like. I always ask my co-hosts to answer first. So, this gives you more time, Oded, to think of your answer. Alright? So, here we go. First scenario, again, both from Nir Rothenberg, so thank you very much. Scenario number 1, you have short, easily brute force keys that are rotated every 9 days to more new short keys. Okay? Crappy length keys, but they’re rotated every 90 days. And now the opposite, which I think you can see where this is going, you have long, complex keys that are never rotated. What’s worse?
JJ Agha: Option 2, long-term that never rotates.
David Spark: And why is that?
JJ Agha: I think you’ll get to… one of the speakers talked about an incident or a challenge, and you have to rotate. It’s just best practices about having kind of short-lived ephemeral keys that are immutable. but you want to kind of leverage short TTLs and have easily rotatable…
David Spark: So, you think that you’re going to get more damage from that than a short key, again, easily brute force? Again, we’re not assuming that this long key has appeared on some public database anywhere, or that it’s been hard coded. It’s just [unclear]. You still believe that?
JJ Agha: Still believe it. Because the day I say, “Hey, this key was leaked. I saw it in a Git repo. It’s on a Payspan, it’s on a Gits that’s publicly available,” I asked the service owner, “Hey, can you rotate this?” I’m going to be staring at a blank wall and 3 days of that service.
David Spark: Well, you are permanently owned at that point. Okay. Alright. Agree or disagree?
Oded Hareven: Well, I definitely agree. But I’ll tell you even more, when you’re going after that long lived keys for that sentence, you miss an opportunity to change in the terms of crypto agility. And that’s the major problem when you’re having keys that are constantly rotated, although it might be compromised…
David Spark: Although probably because it’s brute force.
Oded Hareven: But you do have the opportunity because your organization basically is used to rotating them.
David Spark: Okay.
Oded Hareven: So, you actually know where they are. Right? With the long care longer keys, there is a major risk of actually losing track of them, because no one really remembers where they are. Right? That’s the major problem. So, I would definitely go with a short-lived, rotated keys, because that would allow us or whatever, that would allow you to basically 1 day more easily to change their strength.
David Spark: Okay, so you have this sort of temporary insensitive… or temporary sensitivity, I’m sorry, that gets rebooted. Again, they both stink. We’re agreeing on that.
Oded Hareven: Yeah.
David Spark: Alright. Now I want audience response. In scenario number 1, short keys, always rotated, is that the worst scenario, or no? By applause? Nobody. So, I think you’re agreement here. Applause second scenario, long keys, never rotate.
[Applause]
JJ Agha: That was easy, David. I’m sorry.
David Spark: Alright. We’re in…
Oded Hareven: Sorry to ruin your surprise.
JJ Agha: I’ll take that soft ball.
David Spark: Alright. Hopefully we’ll get a little bit more split on the second scenarios. Here we go 2 scenarios. You manage secrets in a secrets manager, a vault. It sounds great. But here’s where it gets bad, Oded. Like, you’re not going to like this part. That everyone in the company has access to, everybody. Alright. That’s scenario 1. Scenario 2, again, you’re not going to like this, your keys are hard coded. Ooh, that hurts. But your access controls are super tight. Only the few people who need to see a repo have access to it. And this is audited frequently. JJ, what’s worse?
JJ Agha: This is a better question than 1. This is hard. I’m going to hopefully pick the contrarian one for Oded. So, it’s a nice little conversation, but I’m going to pick 2 that everyone has access…
David Spark: Is worse?
JJ Agha: … Is worse. Just because everyone could see your keys, everyone can now access a service. And so, you have insider risk. You have a lot of you know, copy/paste. Privilege escalation, great that you could see everything, and it might be auditable. I’d rather have my keys hard coded with tighter access controls, so that I could say, “Hey, these 3 people have access to it.” I know it’s a smaller blast radius. It’s still not ideal. They’re both terrible. But at least I could kind of shrink my blast radius is where I’m thinking about it.
Oded Hareven: So, I disagree here.
David Spark: Which is good.
Oded Hareven: You love that. So, hard coded within your source code, this can turn out into a massive or major problem of a leakage.
David Spark: Well, it sounds like it’s the same scenario as scenario 2 from the last question, yes?
Oded Hareven: Well, not exactly. Because with this problem, when you have them hard coded, you’re actually having the risk of having your source code to be exposed. And that means to expose your internal keys or secrets for that sense to the external world. Where in the first option, you said, the entire company inside, or the entire development know, they have access to it.
David Spark: At least they’re employees you hired, and you trust them.
Oded Hareven: But that’s an insider threat problem. Right? So, it depends where you feel that you’re stronger, but…
David Spark: So, people you know, versus the people you don’t know.
Oded Hareven: Who do you afraid more, right? From your employees, or the problem that they might have do a mistake that would cause a leakage outside within your hardcoded?
David Spark: So, if you fear your employees inside, then the problem is an HR. That’s where it is.
JJ Agha: Well, that’s a different that’s a different question. You can save that for later.
David Spark: Okay. Alright. Now, audience, I want audience applause on this. Worst scenario, we have a split decision up here. Is secrets and secrets manager, but everyone has access to it, who thinks that’s the worst by applause?
[Smaller applause]
David Spark: Good amount. Good amount.
Oded Hareven: That’s half.
David Spark: Alright. Number 2, your keys are hard coded, like what Oded says, but you got super tight controls on them, who thinks that’s worse?
Oded Hareven: That’s the worse.
[Larger applause]
Oded Hareven: That’s the worse.
David Spark: Alright, a little bit more for you, Oded.
That’s the worse.: That’s not even half. That’s 80.
JJ Agha: Who’s our sponsor for this one.
Moderator: That’s something I’d like to avoid.
David Spark: So, on Medium, a developer, Boemo Mmopelwa, wrote about ‘Costly mistakes developers make when managing secrets and how to avoid them’. His list is pretty much a hit list of top errors, such as hard coding secrets, exposing them on GitHub, poor password management, using weak encryption algorithm, and poor protection of secrets in transit. And lastly, not using a secrets manager. So, Oded.
Oded Hareven: Sounds like a smart guy.
David Spark: Yes. How many…? Because my feeling is secrets, management does not come up at the beginning. My question to you is, how many black eyes do companies get before they finally choose to use a secret manager?
Oded Hareven: So, today, as far as we see it, it is no longer a question. So, back then, let’s say even 3 years ago, 2 years ago when we were speaking with people about secrets management, might be the most of them would not necessarily know what you’re talking about and where there was the problem. Right? Not everyone were exposed to that problem. But today, they don’t really need to have some kind of a breach to actually see the problem because it’s becoming more and more best practices.
David Spark: And by the way, have you seen your sales cycle change as a result being that like, when you…? Because you’ve been around for how many years now?
Oded Hareven: You can say 2.
David Spark: 2 years.
Oded Hareven: Since first funded,
David Spark: Yeah. So, when you were first talking about this with potential customers, my guess at the beginning, there was a considerable amount of education around just the concept of secrets management.
Oded Hareven: So, the change was phenomenal as the COVID came actually. Beforehand, it was like, yeah, you had to speak with people about what it is. But then what happened, especially in the last 18 months is that something happened there. The cloud, obviously, the cloud demand was happening. was increasing. And as a result of remote work, everything was tied up together. And then when the cloud initiatives turned on, then suddenly secrets became a problem for many companies. So, we’ve definitely seen rate rise of that production in the requirements of secrets management specifically.
David Spark: JJ, I’m going to ask you, you’ve worked at a few companies in security, when did secrets management, just the discussion of it, all of a sudden say, “Hey, we got to start taking this seriously,”?
JJ Agha: I want to say probably 10 years ago, but we were an infrastructure as a service. Right? We were a CDN. And that was kind of my first foray into secrets management. Right?
David Spark: So, you were enlightened to it early on.
JJ Agha: Yeah. I mean, I, again, had luckily to be kind of enlightened and exposed to that problem. But I would say from the conversations and what I’ve seen in the vendor space has probably been, what Oded said, probably the last 3 to 2 years, you see this conversation, kind of pivoting past privilege access management. That problem of, “Hey, store all your secrets here,” or you could SSH, you could pull it down, that works for the network layer. But now as that convergence conversation about what you’re doing for SIEM, what you’re doing for Google Vault, like, how do you solve for this multi-cloud, multi-infrastructure environment? I think that’s where we talked about what are the best practices, keeping it ephemeral, keeping it immutable, having it easily rotatable, that’s where you’re going to need that platform.
And then that’s just a service. But when you start talking about, “I have a key that is overprivileged,” well, I want to start thinking about overlaying like detection response to it. Right? I want to start having honey keys and honey tokens. So, identify, “Well, hey, I think everything looks great. But if someone checks out this key, I know I’m hosed now immediately.” And then also just the idea of like, Repo Man of what Netflix can open source, but kind of looking at the privileges that are constantly being used, looking at the service that a key console uses. If we see a new service, check out that key, raise a flag. Why is this happening? Do we have this kind of checked in? Is this appropriate? And I think that’s where we’re seeing the Services heading toward from a secret manager. And even you see other companies that have started off as a password manager but realizing for humans, and now pivoting towards saying, “I have to solve this for services. I have to solve this for non-human keys.”
Oded Hareven: I think it took us time as an industry, as a security industry to basically understand the shift that happened very fast within 10 years. Since containers have become to be like such a great use. Well, think of it, 10 years ago, or 15 years ago, you’ve had more employees in larger companies, more employees than actual servers. Right? And, today, you have an order of magnitude, a major change of number of computers, servers and workloads much, much higher than your privileged users. Right? This change that shifts to custom as an industry you actually understand, “What does it mean? What do we do? Oh, workload, this is now the big thing.”
David Spark: I want to set you up here because I want you to give an opportunity to tell our audience exactly what Akeyless does. Because I actually, all day prior to me recording this podcast, I’ve been interviewing people, some of them your customers, and they talked about that they looked a lot of secrets management programs. I’m interested, just give me an idea, or our audience really an idea, what Akeyless is doing in this space, and what sets you apart from your competition in the space, and why you think your customers choose you over others?
Oded Hareven: Oh, sure. So, we are the secrets management company. Right? So, we provide secrets management in short. Obviously, it’s the ability to completely eliminate the secrets within the places that they don’t need to be, and then to be able to simply manage them. And what differentiates us from our competitors, obviously, is the number 1 SaaS. Right? It’s much more easier to use. Faster production, obviously, no maintenance require, no heavy maintenance for that sense. Obviously, we’re providing a product which is wider with some greater functionality that we provide. We have a strongest security model in terms of the cryptography that we’re leveraging, which is called Akeyless DFC, distributed fragments, cryptography. And which is an innovative KMS as is. And fine, at least the TCO is much, much, much better in terms of much more appealing. Right? The TCO for all of that, you can save your engineering times.
David Spark: Total cost of ownership.
Oded Hareven: Yeah. Sorry for the ones… yeah, total cost of ownership. So, less of engineering, significantly changed. Less of compute resources. And that’s it, you can just drive on. And the onboarding is easy. There’s automatic migration. That’s a major significant differentiator between us and the competition.
Moderator: Is this a cybersecurity disinformation campaign?
David Spark: Alright, we have our next guest on stage. It is Dr. Zero Trust himself, Dr. Chase Cunningham. Please welcome Dr. Chase Cunningham. Alright, I have a question about Zero Trust for you, Chase. Alright? Are we taking Zero Trust too far? Over on the government technology blog, Dan Lohrmann, who’s the field CISO at Presidio said that, “Over time, our perception of Zero Trust has expanded beyond what wasn’t originally intended. It’s evolved into the throwing away of the foundation of business, which is trusted human relationships. But that’s not the purpose of Zero Trust methodology.” Lohrmann quoted John Kindervag, who is credited with driving the Zero Trust trend more than a decade ago, “Online trust is the vulnerabilities,” said Kindervag. Quote, “People aren’t the issue. Packets are the issue.” By way of context, Winn Schwartau of SAC Labs said, quote, “Trust is a dynamic, not a static criteria.” So, Chase, I know you’ve been following this for a while. In the past decade, how has the Zero Trust concept evolved for the better and for the worst?
Dr. Chase Cunningham: So, originally, the idea for Zero Trust was called de-perimeterisation, which was actually much… it’s kind of gobbledygook to say, but the concept was there of, “We will eventually live beyond the bounds of the perimeter. We got to do something that recognizes that.” And then it started, to John’s point (because he was a visionary with this) of the network is the thing. Because at that time, the network was where the power lie. So, you solve that problem. We’ve evolved since that. Now the users are the ones, the admins, the accesses. If you look at where the bad guys go, which is where I always look, they don’t pack firewalls necessarily. They don’t care about packet manipulation. They go social engineering, go after humans, get access creds, and then wreck shop.
So, yes, it’s evolved, and yes, it’s evolved correctly, which I think, now we see it rotating and revolving around identity, and those other things are part of ZT. But if you solve this problem first, you solve a very key and core problem, which is where the adversary goes after you. I have to kind of remind people that, in the evolution, we’re not in the straight up defensive posture anymore. I want to take the fight to the enemy. I’m going to meet you at the door, I’m not waiting for you to come in the door and come into my home.
David Spark: That’s a good point. Alright. I’m assuming, JJ, that when you first heard the term Zero Trust, and today, that understanding, that evolution of what that term meant, or it’s changed over time. And maybe you’ve heard a lot of definitions, of which some you agree with and some you don’t. Yay, nay?
JJ Agha: I think Chase hit it spot on. So, his name, Dr. Zero Trust, really does live up. But yeah, I think when I first started and learned about Zero Trust, it was with BeyondCorp. It was the Googles, the Aurora hacks. And very similar, they went to the network layer. Then they start looking at the devices, started talking about TPM, and looked at it with a cryptography to solve some of this and had a policy engine and whatnot. But they started overlaying concepts. So, I think one thing to not jump the shark here is we need to do the basics, and then converging and compile all the other concepts. Right? So, IAM, do we have appropriate asset management? Do we have appropriate IAM? Are we following least privilege and need to know? If we can solve for any of those, then the journey down Zero Trust is going to be a very tough and uphill battle to solve for, because you don’t know what permissions to grant, what user, what asset, to what data store. You’re just kind of chasing your tail saying, “Hey, we’re doing Zero Trust.” At best, you’re doing what the vendor tells you is Zero Trust.
And so, to go back to the original question of, “Are we overdescribing Zero Trust?” I think as in organizations and private sector, public sector, no. As vendors, I think it’s coming from the executive order. It’s a new ambulance to chase a bit. But the concept is dynamic. It’s going to be ever changing. And we really do need to kind of evolve. 10 years ago, IoT and this large microcomputing at the edge didn’t exist. Right? Really is now becoming day-to-day where you pull your phone, you have 10 different devices, how are you managing 10 different identities for 1 different user, multiple assets? What asset should have access to what data store? So, I think to follow up to Chase’s comments, it is going to change and has to be dynamic.
David Spark: So, explain, you did a presentation about this earlier today, Chase. Walk our listening audience through sort of the 3 just stages of Zero Trust.
Dr. Chase Cunningham: So, in the identity space, really, I talked about the kind of the 3Js, right? Justify, just in time, and just once. If I can do those things, and honestly, like we’ve talked about, justify is probably the most difficult thing to get right in a policy engine. But if you do those things, you’re taking the power back from the adversary. And that’s it.
David Spark: Let’s focus on justify. Justify is, “Why is this person connecting to this database, this app at this time? This person’s identity, is this, quote, ‘justified’?”
Dr. Chase Cunningham: It’s the ‘should’, not the ‘could’.
David Spark: The ‘should’. So, how do we develop that, I guess, understanding of the ‘should’?
Dr. Chase Cunningham: So, the policy engines here have to be really powerful. They have to be able to take in lots of information. They have to be able to do the telemetry sort of coordination, and then enable decisions to happen, which is a justification. You have a lot of these things. You have ticketing systems. You have contract management. You have all these other pieces, and everything out there nowadays has got an API. Pulling that information and using it to fill that sort of process engine and actually make a decision that this needs to happen, that’s key and core to this. And the funny thing is, the more you do this, the better you get at it. Everybody in this space talks about AI and ML, I’m a math guy. ML gets better with more.
David Spark: Well, I’m going to throw a little wrench into it. It does get better with more…
Dr. Chase Cunningham: With good more.
David Spark: With good more, right?
Dr. Chase Cunningham: If that’s a thing.
David Spark: There is a point where, like anything, there is no kind of point of return.
Dr. Chase Cunningham: There’s always risk. Right? And, I mean, you never going to be a billion percent. And the other the other thing that actually the guy that wrote this thing also said that there is no Zero Trust, I would agree with you. Just like a bodybuilder that has zero body fat will die. So, you have to have some. There’s always going to be some.
David Spark: Right, we live with some, yes.
Dr. Chase Cunningham: But it’s really not a good way to get people wrapped around the concept of go, “Let’s have some trust.”
David Spark: The other 2 ‘justs’, just quickly cover those 2 as well.
Dr. Chase Cunningham: Just in time. You get it now, you do something, and then that’s it. It’s usually going to be session based. And then just once. And you do it again. If you need it again, I do it again. And you can do this and it doesn’t interrupt the user’s lifecycle. You just make it fast.
David Spark: It seems that most programs out there, and that there are solutions for those last 2. And like you said, and I’ll throw this to you, JJ, is how difficult is it to create policies to create a justifying engine?
JJ Agha: I mean, to Chase’s point, it’s a math problem. So, you’re looking at kind of data models, figuring out what are the patterns. And that solves for your repeatable patterns, the 80, the 90. And then you have to think about the break glass scenarios. Right? And really think about, as a business, what are the different risks, and what are the different ways to get in if something does occur? And then it’s just like programming and allowed risk on any firewall, you know, “This server needs to talk to this server. So, I’m going to create the ACLs.” It’s the same conversations, whether it’s a human to a data store, a human to application, application to a server, what services should they talk to, and then prevent the ‘could they talk to’ conversation. You do that, it’s just a simple conversation of policy. There’s just a lot of legwork. And you have to kind of, going back to Mike’s conversation, have the appropriate conversation and communication to the right business partners and speak their language.
I can’t go to my CFO and say, “Well, you can’t connect to SAP and I’m going to start blocking port 443.” They’re eyes are going to roll and they’re going to be like, “What are you talking about?” Right? We need to speak the language as practitioners, whether you’re an engineer and analysts. I think that’s the biggest hurdle for number 1. It’s not about the systems, it’s really just about us as practitioners of selling why Zero Trust is important.
Moderator: It’s time for the audience question speed round.
David Spark: Alright, I have here in my hand, a handful of questions. I thought I had more. Hold on. I had a few more than this. Yes, I do. Here we go. Yeah, here we go. I got plenty.
Dr. Chase Cunningham: I like long walks on the beach.
David Spark: Those are not the questions the audience has for you, Chase.
Dr. Chase Cunningham: Alright. It was worth a shot. It was worth a shot.
David Spark: I got 6 questions, I think. Let’s try to see if we can hit all 6. So, I’m not looking for long answers. Some quick answers on this and give me what you got here. Alright. Feel free, either one of you, to jump in with your first answer to this, “Do you feel safer with your data all in one place or distributed?” And this is from David Berger at the SDG Corp.
Dr. Chase Cunningham: Distributed if done correctly.
David Spark: Okay. What does, “If done correctly,” mean?
Dr. Chase Cunningham: There are ways to do distributed ledger stuff the right way and without the shenanigans of blockchain and actually have it be correct.
David Spark: Alright. I like that answer. JJ.
JJ Agha: I think I’ll pick distributed as well, but again, done the right way. Right? You need to have the right IAM ACL strategy to solve for distributed. You then have a whole other conversation around data lakes and data warehouses that we could tackle some other time.
David Spark: Alright. And have you traditionally been distributed?
JJ Agha: Yeah. I mean, everyone, every application owner wants to manage their own data store. Right? So, you’re going to have to…
David Spark: Unless you’re building it yourself. Right. Alright, second question. This comes from Gui Martins of ObjectSharp. This is going to go to you first because he’s teasing your justify, just in time, and just once.
Dr. Chase Cunningham: Oh. Alright.
David Spark: So, how do you reduce friction (with the whole business, that is) where security is trying to implement justify, just in time, and just once?
Dr. Chase Cunningham: I tell them that, like anything else in life, change sucks, and it’s going to hurt. But we will get better over time, and the policy engine and everything else will catch up to the pain we feel now. I would rather suffer for 30 minutes than die because I didn’t do something. So, my honest answer to them, and not our technology speak, is, “Change sucks. Buckle up. Let’s get through this.”
David Spark: So, to some level, I agree with you. But to some level, people are like, “I don’t know. I don’t like… that means I have to trust what you’re saying.”
Dr. Chase Cunningham: Then you will fail that.
David Spark: You will fail?
Dr. Chase Cunningham: That’s what I would tell them. Your choice is, do this, or you will fail. And if you think you’re better than all these other companies that have failed at it, then show me how you do it differently.
David Spark: Alright, I’m going to jump to the next question. This comes from Daniel Fabo of Cimpress. And I’ll start with you, JJ. “What is your biggest headache with regard to identity access management?”
JJ Agha: Too many vendors. I mean, yeah, when you think about all these applications, and the biggest headache is that security wants a single IAM strategy. And now I have 100 different SaaS applications that 10 of them could support skim, 10 of them could support SSO, 2 of them are standalone, 3 of them have no MFA support. That’s my biggest pain is kind of the IAM sprawl. Secret manager’s here to help you, but I think that’s the challenge that we’re going to have to solve as an industry. There’s OIDC. There’s WebAuthn. There’s protocols out there that are hopefully as we go to HTTP/3, Web 3.0, it really starts becoming a repeatable pattern. But that’s my biggest pain point is, very similar to data sprawl is identity sprawl.
David Spark: Alright. I’m going to throw this one to you, Chase. This comes from Rolando Galan of GOBI IT. He asks, “What would it take for us to live in a world with identity but no passwords?”
Dr. Chase Cunningham: We need self-sovereign identity. We need biometrics. And we need the rapid adoption of those technologies for as much as possible as fast as possible.
David Spark: Those texts have been around, especially biometrics, for quite some time. It’s not happening fast now. Why?
Dr. Chase Cunningham: It’s not happening fast now, because there’s still this reliance on the old paradigm. And like we said earlier, people are resistant to change. Even though you can say like, “Look, this change is better,” people look at it and go, “But change sucks. So, I’m going to do what I’m doing. Thanks.” And you stay where you are.
David Spark: Alright, I’m throwing this one to you, JJ. This comes from Carla Mensia-Foley, and she’s with CaptionCall. And she asked, “What ways are you engaging with vendors today…?” Remember, this is the CISO Security Vendor Relations Podcast.
Dr. Chase Cunningham: Fighting in the parking lot.
David Spark: Fighting in the parking lot? “What ways are you engaging with vendor today that you didn’t do before?” First of all, are you engaging with vendors?
JJ Agha: Yes, yes.
David Spark: Okay. So, what ways are you engaging with them today that you didn’t do before?
JJ Agha: I mean, everything is virtual. But I think I typically get phone calls, and I just tell everyone, “I will reach out to you, when I know I want to solve this problem.” I don’t need a vendor to pitch that, “Hey, this is the challenge that you don’t know about, you need to solve for.” From an external face, I just think it comes off arrogant to say, “Hey, I know your problems, I know your challenges better than you do.” Because I do [unclear] guys, “I wish you did.”
David Spark: But has any vendor really done true… not a lot do this, but do true due diligence to try to learn about your environment?
JJ Agha: Yes. And so, the vendors that… and probably bad I’ve been on parental leave, so I take this with a grain of salt. But the vendors that actually… they’ll say, “Hey, listen to you on the CISO podcast,” or, “I listen to another podcast,” and kind of take a line or just do that digging and say…
David Spark: Sorry, you’re appearing on other podcasts besides mine?
JJ Agha: Sorry about that.
David Spark: Go on.
JJ Agha: But I think that’s where it goes a long way. Just make a human connection, and then we could have a conversation about and beyond just the company economy. I think when we have a human connection, especially nowadays, it goes far and a lot further.
David Spark: Alright. Last question, I want both of you to answer and it’s your time to trash a category here from Suki Suey from Cerner, she asked, “What’s the most overrated tech category now?”
Dr. Chase Cunningham: Most overrated tech category, as far as just in this space in particular? Because there’s a lot of tech categories.
David Spark: Yeah, I’d say in cyber. We’re going to say in cyber in general.
Dr. Chase Cunningham: Artificial intelligence, period, point blank, end of story.
David Spark: Yeah. JJ?
JJ Agha: That’s 1A. I will pick 1B, and I’ll probably pick XDR.
David Spark: And why do you believe these both overrated?
JJ Agha: For XDR, it’s just the same pattern. Right? Why do you need to throw an X? It’s still an endpoint to an asset.
Dr. Chase Cunningham: Because it’s sexy, and X is cool.
David Spark: My other co-host, Mike Johnson, said the same thing, “It’s the same darn product here. We’re just creating a new category.”
Dr. Chase Cunningham: But it has an X in it.
David Spark: It does have an X in it. That does help. That does make it sexy. And I should also mention, and I’ve talked about this before, why the heck is Gartner keeping building more categories? Enough. Just stop.
Dr. Chase Cunningham: Have you ever seen the threat cube?
David Spark: What, how many categories in that?
Dr. Chase Cunningham: Go look at that… well, I mean, it’s on the cube, right? Yeah, go look at the threat cube for Gartner. It’ll give you a headache.
David Spark: Oh, geez. We don’t need more categories. That brings us to the end of the show. Thank you. Thank you very much to all of my guests. Mike Rogers, Oded Hareven, and Chase Cunningham. By the way, Chase, I’m going to let you have the last word here. And I also have to thank our sponsor and the people who put on this phenomenal event in New York City, Akeyless Thank you very much for Akeyless. Let’s hear it for them.
David Spark: Go check them out for all your secrets management needs. Their web address is a, and then keyless, k e y l e s s.io. Check them out. I always asked my guests, and JJ, you’re here, are you hiring by the way?
JJ Agha: I am. I don’t know how much I have for 2022 because I’ve been slacking on parental leave. So, thank you, Compass, for allowing me to be here. But we are hiring in multiple positions for product infrastructure security, enterprise security. And so, definitely come on down, ping me on LinkedIn, or reach out to our careers page.
David Spark: Alright, JJ, any last thoughts on the topic in our discussion today?
JJ Agha: No, I mean, I think Zero Trust and secrets management, it’s a needed part of any security program. Right? Getting the right vendor, getting the right partner and getting your organization to believe in it is going to be the biggest thing. Very similar to what Chase said, he could tell everyone, but if they don’t believe in it, you’re not going to solve anything. And so, I think it’s you leverage and lean into the ROI. That it’s going to constantly… it will provide you better operational… will provide you exactly what you want at the end of the tunnel, but it’s just going to take some work. And just like everything worthwhile, change is going to be good. Just suck it up and go through it.
David Spark: Suck it up. Will that be the…? I think maybe that’ll be the title of our episode, “Suck it up, losers.” No, I don’t mean that too. Alright. Chase, any final thoughts on today’s topic?
Dr. Chase Cunningham: I mean, I think the most important thing really is think about it from the perspective of the adversary. Right? What are they going to use to cause problems? And then also look at the cyber-Serengeti and figure out how not to be the slow gazelle. If you don’t want to be them, do something different and you will not be them, which is a win.
David Spark: Excellent point. Again, I want to thank our audience here at KeyConf.
David Spark: And all the phenomenal people that Akeyless. And by the way, this production crew has been completely aces here. Kudos to the production crew. Come on, they have done an awesome job.
David Spark: These guys know how to produce an amazing show. So, thank you very, very much. Stick around. I believe we’re having drinks next. Thank you all, as always, to our audience for your contributions and for listening to the CISO Security Vendor Relationship Podcast.
