Questioning the Status Quo

00:05 Richard Bird – opening quote  

"The more that we distribute, the more that we decentralize, the more that we fragment. The more that we go down pathways of things like no code, low code, the more that we go down serverless; we're just creating a distributed environment that is a target rich environment for the bad actors, and an incredibly difficult landscape for us to manage from a security standpoint."

00:28 Raghu Nandakumara

Welcome to The Segment, a Zero Trust leadership podcast. I'm your host, Raghu Nandakumara, head of Industry Solutions at Illumio, the Zero Trust segmentation Company. Today, I'm joined by Richard Bird, Chief Security Officer at Traceable, a leader in API security. With decades of cybersecurity and IT experience spanning the corporate and startup worlds. Richard is a senior fellow with the cyber theory Zero Trust Institute and an executive member of Cyber Edboard. He's known around the world for his tattoos, bow ties, and expert insights on API security, Zero Trust, and digital identity. Today, Richard joins us to discuss how to be a non-traditional technologist addressing cognitive dissonance in cybersecurity and the intersection between Zero Trust and API security. So, we've had the pleasure of [having] the godfather of Zero Trust on this podcast. We've had Dr. Zero Trust himself. We've had a whole collection of other cybersecurity and technology luminaries. But this is absolutely the first time that we've had a rock star on our podcast. So, with that, it gives me great pleasure to welcome today's guest, Richard Bird, Chief Security Officer at Traceable AI. Richard, thanks for joining us. 

02:01 Richard Bird

Very excited for the conversation. Thank you for having me.

02:04 Raghu Nandakumara

You can't be more excited than I am, Richard. I was looking at your LinkedIn profile, and I noticed that we have at least very similar career arcs. We both spent 15 to 20 years in the financial services industry before moving into "vendor land." At that point, comparisons all stop. I'm just glad to say that there is that parallel before we get into it: a bit of background about yourself and what's brought you here to what you're doing today.

02:31 Richard Bird

Well, I think what brought me here was my association with some of the shady characters that you mentioned, all friends of mine. And when we when we talk about Chase Cunningham and John Kindervag, the stories which we'll share over the course of this discussion, really kind of rotate around how we've continuously volunteered each other to be a part of each other's particular career trajectories or control domains of expertise and background. And it's resulted in just a great opportunity in synergy to be on a number of different channels together, or be voluntold by one or the other, that I have to join them. So, I just keep good company, I guess is why I'm here. But you know, it's gotten to be – my bio is a little threadworn after a few years saying the same things over and over again. But yeah, I did corporate roles for 20, almost 25 years. And in the course of those 25 years, about 16 or 17 of them in banking and financial services, payment processing, early days of the internet bubble, and payment person-to-person payments and that kind of thing and got elected by friends and colleagues to come into information security back in the first beginnings of Centralized Information Security as a service within specifically JPMorgan Chase. I tell people my collective number of years at Chase were 11, which is 137 years of my life that I'll never get back again. You definitely age in dog banker years. But I also saw a lot of things early on many things that are now coming into focus for organizations and companies today, that were problems that an organization like Chase were seeing a decade ago or more. But also that an organization like Chase had the financial resources and expertise to tackle back then. So, I always like to tell people I'm not an expert. I just took a lot of the beatings and accumulated bruises and scars before a lot of other people did in security. And I am usually a better-sounding post for what not to do than I am for what are great best practices because I've done it wrong a lot in my career and still managed to survive and get an opportunity to talk with you today. 

04:51 Raghu Nandakumara

I've just been laughing, smiling so much hearing you say that because it completely resonates with my own experience. Seeing so many of those challenges, often a couple of years before the rest of organizations and other industries see those same challenges. And essentially having the scars to now be able to sort of join the other side and say, "Yeah, this is how you should be solving the problem," or "This is the learnings that I've had, and here's how you could do it better." So absolutely associated with that. Before we get further, I'm really excited to talk to you about the work that you're doing at Traceable. But I enjoyed reading your LinkedIn post about that Joe Strummer and the influence of music on your career. I'd love you to sort of share that with the audience before we go any further about how your interest in music, your passion for music has really influenced how you think about and how you communicate key ideas and 10 key challenges today.

05:57 Richard Bird 

Well, I'm really glad that you brought that one out because it's going to give me an opportunity for a shameless plug about something that I'm working on. But it also gives me an opportunity to share. There are very few things in my career that I'm just super proud of. The one thing that I am really proud of, and don't reserve ego on as being a non-traditional technologist. I didn't come from MIS or CIS background, not saying that in a technology trades, there's anything wrong with that. But I came from a totally different track. I came from a major in political science with a focus on international relations theory and a minor in Japanese language. And I was a construction project manager. After I came out of the military, it just happened to be right at the nexus of time when project management was an extremely critical skill needed in technology, and somebody saw something in me that I didn't see myself. And they hired me. And that person is still a mentor nearly 30 years later. I share that background because the touchstones for me about being a passionate speaker, or being a passionate presenter, or being a passionate researcher around issues that are happening in society, whether they be technical or otherwise. It is this notion, this artistic notion of muses. What inspires you is different than what you are passionate about. What inspires you and, for me, my inspirations are, are very strongly aligned to the arts. Music just happens to be one of them. And as the piece that I wrote seems to touch a lot of people's hearts and their souls a little bit. You know, I grew up at the very beginnings of punk rock music. I'm not ashamed to say that it probably seated a pretty strong contrarian or cynical, or even anti-establishment kind of thinking in me as a kid, and it's still there. I buried it under 20-plus years in the corporate world, where you're not allowed to say things in public, you're not allowed to share thoughts. You have to get through 17 different approvals to even be on a podcast, let alone go speak publicly. And I kept a cap on that for a quarter of a century. And that piece came to me when somebody asked me, "How was it that you come up with so many wild analogies or metaphors?" or, "This whole storytelling approach that you take to things." I said, "Well, it's two things. first, I grew up a fishing boat captain son, so I got a Ph.D. in storytelling." And the second is that all of these elements of my past and my experience, growing up listening to music, hearing incredible lyricists and musicians attack issues and problems within society with their words, it just became a natural inspiration and touchstone for motivation for me personally." When I speak publicly, one of my goals is to really connect with people emotionally. And that's complicated because you're not connecting with one emotion. Just like music, you're not connecting on one emotion. Somebody might be jubilant hearing a song, but jubilant and dancing are two different components of that experience, not a single one. And I said shameless plug, since I've been doing this, kind of a personality and speaking and that type of role for the last five or six years, I realized that what I've experienced and what I think is teachable. I'm going to curse it, but I'm in the final edits of a book called Famous with 12 People. The subtitle is a career guide on how to be an internationally recognized expert in something that nobody cares about. And the notion for the book is that in my journey in the last five or six years, I have met a tremendous number of micro-famous people. And most of those micro-famous people are like me. Their inspired by things that are far afield from our careers and our work experience. And these micro famous people aren't just in security. I sat next to a guy on an airplane, and we got to talking and, and he goes, "Yeah, well, I'm a stunt coordinator." I got off the plane and found out he's the stunt coordinator. He's the guy that teaches all the other stuntmen and stuntwomen in Hollywood. He's got 1,000s of people that follow him. And I thought I never heard of him before and I'll probably never hear of him again. But what an interesting dynamic for somebody to be able to have that kind of an impact on people's lives. And that's really where all of that energy to write that Joe Strummer piece came from. Like what can we do as not being rock stars and musicians? What can we do to inspire that same kind of excitement, motivation, and passion and be even a muse for others in our own field of expertise? And that's really how that all came about.

11:12 Raghu Nandakumara

I love that. Thank you so much for sharing that. And a humble request from me: When that book publishes, I hope it's an actual sort of physical book format, not just as an ebook. I would love a signed copy from yourself. 

11:27 Richard Bird

That's the plan. I'm old enough that I still love paper. 

11:12 Raghu Nandakumara

My wife jokes with me that the reason I buy books is just to populate our bookshelf. And I say, "Yeah, absolutely, shamelessly, it's for the backdrop when I'm on calls." But the storytelling point that you made, and really finding that inspiration to tell stories, I personally find in the role that I do today, and I'm sure you find in your role, is that it's so important to connect, sort of, I guess, the technical value that the products our companies build, really connect to the essence of the buyer, and really the outcome they're trying to achieve. It's not about the technology; it's not about how you go and do something. It's about how I am going to help you. Why is it important to you? And I think storytelling is so important, do you find that?

12:15 Richard Bird 

Well, not only do I find that I think that in the process of writing, which does not come natural for me. Long-format writing does not come natural for me. In the process of writing, I had to really kind of figure out why it is that in, security specifically, that we struggle to communicate with each other. We struggle to communicate as it relates to, here's the business problem, I need to help you solve. As a technical solution provider, we struggle as technologists with this, as the business requirement that I have. And technologists don't get it. And I think that what I realized was when we talk about people in the marketplace, that we're trying to show a pathway to solving problems for those buyers really universally, are operating at the abstract layer. It's an abstraction. They recognize that there is a problem; they recognize that they see some kind of breach or hack in the news. But equating that to all of the different levers and pieces and opponents within an organization that have to be pulled or pushed or twisted or tuned in order to keep that bad thing from happening. It's extremely difficult. And then when we take it back to engineers, solution engineers, and security architects. We all live in the world of specification. We're all talking about those levers, we're all talking about those switches, and we're talking about…And we have this big cognitive dissonance gap. That happens. And I do think that storytelling is one of the major components, one of the major tools that fills that gap. There creates a possibility of some universal translation layer between those parties between those different entities. Because at the end of the day, we're all in the same business trying to solve these problems. And when we ask ourselves, why are we going so slowly and getting there? I think a large part of it is just this: a substantial fracture in communication and understanding. That is, I'm working at the abstraction layer, I'm working at the specification layer. And there's nothing kind of bolting it all together. And I think storytelling is a critical component of that.

14:38 11:12 Raghu Nandakumara

So you use the term cognitive dissonance, and actually, you're not going to believe this, but I was in my research for this and listening some of the other pieces that you've put out, and I quote you, you said, "cognitive dissonance, there is a massive gap between I know I have a problem, and I'm doing something about it." So, let's now kind of dig getting to that level. You've seen this in your experience, and I've seen this in my experiences that you do an assessment. Let's say a red team exercise. You identify your areas of vulnerability and say, "Oh, yeah, I know I'm vulnerable there. I understand I need to do something about it." Six months down the line, 12 months down the line, repeat the exercise, same vulnerabilities exist. I need to do something about it: repeat, repeat, repeat. Why that gap? Why that inability to make the leap and fix the problems that need fixing?

15:35 Richard Bird 

Yeah, there's a couple of components there. The first is that the gap represents the gap between knowledge and threat, or knowledge and risk or knowledge and experience. I had mentioned I was in the military. We had a drill sergeant as I was going through one of our schools. And a young troop came in and was standing in front of them complaining about a situation that we were experiencing on a particular exercise. And the drill sergeant looked at him, and he said, "I hear you, but I can't quite feel you." And I thought that was brilliant. I've used that for years. He said, "I register your problem. However, there's nothing that I can or will do about it. And I think there's a lot of that in the corporate world because it's easy to throw rocks. I think that's one of the benefits that I have is that my rocks are thrown a little less hard because I've been on that side of the wall. I've been on that side of the equation that you have so many competing priorities. You have so many burning platforms; you have so many issues. I've had entire programs that were derailed to try and reduce risk, tangibly, in an area that we've worked on for a couple of years, because some executives called up and said, "Hey, I went to some conference, I heard this, you guys need to get to work on that now."  There's just a tremendous amount of distraction in the corporate world. So, knowing about a thing is not enough. And I think that over and over again, we keep proving that knowing about a thing doesn't drive behavioral changes. As it relates to mitigating risk associated with a thing, it’s something that we have to put back on the risk trades. The risk trades have struggled over the years to create formulas that really kind of hones in on costs and consequences of risks. For risk classifications, I always bring up Nassim Qualy's book, The Black Swan, anytime I'm talking about risk because it is such a confirming book about "why." To answer your question, we can't make progress because we continuously operate as executives and practitioners with the belief that these long-tail risks are not going to happen. And as you know, Qualys talks about in his book that history proves that those long-tail events happen a lot more frequently than we would ever expect. And so that is back to that cognitive dissonance. If I believe that a risk is so far out there that I don't have to be worried about it. I'm sure, like your background, you've heard this over and over again: "Yeah, I guess that that's a really big problem. But I'm not in banking, so I'm not really worried about that." You know, how's that worked out for everybody on ransomware? Right. You know, there's this expectation that there's a gradient of attack types that represent the scale of complexity and maturity.  And this just came up in a conversation yesterday, like, somebody asked me, they were like, well if somebody is attacking a Chase, or Bank of America or city this way, because really large enterprise and a really complicated organization, small or medium-sized companies don't need to worry about the same attack. And I was like, that, boy, you just nailed it. I mean, there will be very cynical about it was like, you just nailed it. You know, people are dimensioning their security programs based on what they think their risks are for their particular domain or vertical. In the meantime, bad actors aren't thinking about it like that. If the bad guys are going, wherever I can get in, like, if I'm going to use a sophisticated attack, cool. I'm going to use a non-sophisticated attack. Cool. If I get your data. That's all that really matters. And I think that that's really all of the confusion of the complexity that we have in this marketplace. That keeps that cognitive dissonance wheel turning and spinning from year to year in security performance.

19:50 Raghu Nandakumara

How do we change that?

19:53 Richard Bird

There's the grownup practitioner answer, and then there's the cynical answer.

19:58 Raghu Nandakumara

I want both. 

20:02 Richard Bird

Well, I'll start with the cynical answer. And it's reflective of a conversation I was just having with a mentor the other day; the mentor said to me, like, "Maybe we should just advise start advising the bad guys. Because they listen, and our colleagues and our friends and our fellow practitioners don't." And I think that's a harsh statement, but I don't think it's entirely unfair. And I think that that raises that the cynical answer to that is, is that for a long time, all of us as practitioners say, well, we just need to wait for the biggest the next biggest breach to happen and people finally change. That hasn't worked.  And that starts to raise the question of what if we see a chain reaction? A catastrophic event? What if we see a national infrastructure grid in some nation come down? What if we see a massive outage for an entire hospital network? We've seen isolated cases of surgical suites and emergency rooms being closed down. I've always been a firm believer that the thing that really changes the game is when there are some form of mass casualty associated with the action of a bad actor in the digital world. And when I said that a few years ago, people thought I was the darkest thing that I could possibly say, and now I say people go, "Yeah, I get it." Like that could happen. So, I think that there's a certain amount of this problem reflected in that cognitive dissonance that we're talking about right, which is, we still haven't seen something big and bad enough to finally wake people up. Now, the professional answer to that is, that where we really begin to make progress is when we start to see a significant change. In one of the most bizarre behaviors, I think, that I've seen in security, which is, and a lot of security practitioners get mad when I say this, but I firmly believe that security is the only discipline in the corporate world where we refuse to learn from history, data, and evidence. We have evidence clearly in front of us. So, I'll give just a very specific example. We have evidence clearly in front of us with 25 to 30 years of history: when a bad actor gets into your system, the very first thing that they do is go to your Active Directory. And going to the Active Directory, they're looking for obsolete, antiquated, disabled, but not deleted, capabilities and identities. They wrap themselves in all of these entitlements and access grants and authorizations, they go do bad things. And because it was all on your AD, your internal systems for security don't catch up because they look like they should be there. Now, that is a pattern that anybody that in security knows is actual; they know that it's evidence supported. And they know that it is the primary pathway for bad actors. And yet, you can walk into eight, nine out of every ten companies today and ask them, "When was the last time you cleaned up your AD?" Whether it's Azure, whether it's on-premises, you'll hear crickets. You'll hear somebody go, "Well, you know what, that was funded last year and the year before, but it went below the bottom line, and we didn't get it done." And I'm like, so universally, we know, this is one of the most capitalizable attack surfaces in any company. And yet, we all sit around and go, "Yeah, I got defunded, and we're not going to work on that this year." That's what I'm saying when I say we continuously refuse. And that comes back to a lot of questions used to be it was like, well, you just need to get the basics right. I personally don't think that that's a helpful statement. It gets back to foundational security. Are you doing foundational security correctly? And you know, not to kind of lead the witness here, but that was what eventually, after being a long-time resister to Zero Trust, that's essentially what led me to Zero Trust. Because there are aspects of Zero Trust that I think we'll pick apart here a little bit that actually go back to the very beginnings of compute and are foundational. And I think that while a lot of people think that Zero Trust is, let's go forward to the future; the reality is there are aspects of Zero Trust that are more or less of, let's get back to the principles of the past that we know that worked, that are extremely helpful in today's environment, but we've forgotten about and I think that's where we start to see improvements when we go back and embrace our roots. And secondarily, when we start paying attention to what clearly published data and clearly disclosed data keep telling us as our weakness over and over again. 

24:40 Raghu Nandakumara

Just listening to all of that and sort of so many things that we could have delved deep into that I suspect would be here all day and all evening, while my time allows that I'm not sure yours does. So, just a couple of things. One of the things that you touched on is that this now, probably that need for awakening may be driven by that truly catastrophic event that has been triggered by a cyberattack. And I feel that we are getting sort of to the cusp of that realization. I mean, everyone sort of points back to Colonial Pipeline as being one possible example of that. And then changes that have then resulted in, in terms of sort of government level or industry-specific sort of requirements regulation in terms of how to improve cybersecurity posture, both of individual organizations, but also it's collective. And then you've spoken about Zero Trust as kind of almost being a bit of a back to the future in terms of how we can realistically improve security posture. And the way you explained it, Zero Trust isn't necessarily about this sort of future-looking cybersecurity strategy. But actually, going back to what was always at the essence of cybersecurity. Right back, sort of at the beginning of time. Where did we forget that? And why did we forget it?

26:01 Richard Bird

Well, the mechanics of why it's forgotten are interesting because we see them every day. The world in the digital space has gotten less and less safe as we've gone from monolithic decentralized to distributed to highly decentralized. The more the IT architecture becomes fragmented and the more it becomes distributed and decentralized, the worse the security breaches and exploits become because you don't have the command and control that you used to have. Now that I don't say that as a get off my lawn cloud kids, right kind of statement. What I'm saying is, this is the mechanic has driven the explosion and bad security consequences. And that's something that is very clearly going to get worse. And the reason is because we are in this phase of technology where we are reaching the ultimate current capabilities for virtualization, which is application to application layer seven HTTP, HTTPS. I remember a few years ago, a very large bank that I was working with in Europe said to me that their goal in five years was to run all of their applications on the public internet. And I was like, "You guys are nuts." I was like, "That is insane." And yet, that's this world. Now that was a case where I was short-sighted. I was like, "That's not possible, we're never going to get there." And then the reality is that's the world that we're in. But now, more and more of the assets that you're using to drive value to manage and distribute transactions is not your stuff. And the more it's not your stuff, the more we have extended supply chain risks of everybody in that chain doing things without ever conversing with each other, without ever talking to each other about each other's security controls. Somewhere down the chain is some dude that yanked a couple of lines of code at some public repository somewhere, and it's already compromised. And you don't have any control over that anymore. So, that’s been the driver. The more that we distribute, the more that we decentralize, the more that we fragment, the more that we go down pathways of things like no code, low code, and more that we go down serverless, the more that we we're just creating a distributed environment that is a target-rich environment for the bad actors, and incredibly difficult landscape for us to manage from a security standpoint. So that definitely is the causal factor. And, like I said, I don't want anybody sending me any nasty grams; there's that anti-Cloud Guy again. Distributed computing has been around a long time. Don't think that because AWS and Google managed to park some VMs with load balancers in their own data center, that those of us with gray hair don't know what decentralized and distributed looks like. But yeah, I think that the foundational piece back to Zero Trust obviously gets to the game changer for me, where I said I was a resistor of Zero Trust in the early days because I'm an old identity guy by practice, which is Zero Trust feels like friction. Friction is what gets you fired. But I was completely wrong because back behind that friction is this reality and we go back to early days of compute, that the driver for these bad things in these highly distributed environments is the existence, the intentional, the design, the engineered the allowed existence of implied and persistent trust in everything. And that existence of applied and persistent trust is what the bad actors love. That AD example I have an old AD account with god rights that nobody ever pulled out of the directory, that is implied in persistent trust exemplified. And I have chosen, either by ignoring it or willfully ignoring it, not to fix that. I'm allowing a portal for bad things to happen. That is all trust-based. And that was really the kind of change for me. So, I think that you know, the improvement pathway, even with the massive distribution of computing platforms and infrastructure, the improvement pathway is to greatly reduce with a goal to eliminate implied and persistent trust in as much of the digital estate as possible, as fast as possible.

31:11 Raghu Nandakumara

For those who are not watching this on the video and are consuming this via audio, my head is about to fall off because I've just spent the last two minutes just vigorously nodding at every single word that Richard has uttered. I think that is amongst the most succinct but very direct and descriptive approaches to analyzing why Zero Trust is necessary and the root of the problem that we're trying to address. So, Richard, I appreciate that.

31:45 Richard Bird  

Well, it took a long time for me to figure it out. And I'm not the only one that makes this noise. One of the problems with the moniker Zero Trust is we don't get to the real root of what trust it is that we're talking about. I always thought we should have named the model "your sketchy brother-in-law, that might be a drug addict and always wants to borrow your tools security framework". Because everybody knows what we're talking about. That's a family member that you do not give them at your house and the code your garage door opener. And we have a lot of those; we have a lot of those sketchy brother-in-law's in our systems today. And that just gets back to the storytelling part, which is, I was reactive, emotionally reactive to the term Zero Trust initially. And it caused me to be horribly, horribly wrong about my own assumptions. And I John [Kindervag] has shared the story, I share the story all the time. I remember when I met John for the first time in person, we were having dinner. And I said, "Dude, I did not believe what you were selling." And he started talking to me, and the one thing he said, that just illuminated everything for me, he goes, "I think data should have an identity." And I was like, "Whoa, pump your brakes, dude." That is like Star Trek, and we are still in Fred Flintstone. As soon as John began to articulate it in a way – he's a great storyteller too – when he started articulating in a way that wasn't a whitepaper, it wasn't another engineering spec that opened my eyes. And like I said, I fully admit that I was a moron when it came to the notion of Zero Trust because I want to come and bring it back to the foundational. I've done a lot of mainframe security in my life for identity. And worked with some amazing pioneers in banking or mainframe operations. And I got this revelation at one point when I was doing a really massive program at Chase, Zero Trust had already been explained to me by these mainframe ops folks. Because Zero Trust, access control from its beginning days until we really started to kind of plug in other virtual devices to be able to get into core mainframe data has always been a Zero Trust, always. And I was like, Wow, this goes back to what I'm saying. Those principles worked, granted, centralized system for large centralized system, but those principles worked in that environment. And we can't make the argument that well it's not like the cloud. Because as I like to remind people, some 90% of all compute every night happens when a giant cartoon lever is pulled and mainframes process. They still, 90-some-odd percent of the workloads when everybody in the world is going cloud, could internet, cloud after 30 years of commercial cloud, and mainframes still rule the planet. We can't use that rationalization of the complexity of the cloud when they come complexity of the mainframe and the massive monolithic world is easily just as complex. But we do make those excuses out of convenience, I think. Because it just comes down to, I want my widget out there faster, I want my product in production faster. I want, I want, I want, I want, I want, and those "I wants" rarely come with; I'd also like it to be safe. You know, those were the drivers that are really making it complicated to secure these things. 

35:27 Raghu Nandakumara

Yeah, absolutely. When you are describing the need for a Zero Trust, essentially, the problem that has accumulated, you spoke about, essentially, this accumulation of too much implicit access, that we kind of, it's there, we believe that makes our roles easier, more productive. As soon as we hear the term Zero Trust, or, put it another way, the removal of as much implicit trust as possible, so that there is much less sort of freebie access for any kind of attacker to exploit. I think that is the hump. And I think you described as that is the hump that it takes so long for many organizations to get over. Because they already think that, oh my god. Are you going to remove that access, you're going to break this thing? And then how I can be productive? And, and I think when people think about this, and actually, I think actually going forward, if you think about it, from this perspective, is it easier to list all of the bad things that you want to stop happening? Right, and is that a finite list? Or is it easier to just define the very specific things? You absolutely need something to do? And just manage that? Which of those two is actually easier when you think about it?

36:49 Richard Bird  

I think we believe belabor the point about least privileged, not just in Zero Trust. I mean, at least privilege has been a functional component of high-risk environments for a long time. I think we'd be labor near the least privileged statement without ever coming back to what I think you're really kind of pushing the edges on, which is, how about least functional? Like, why from a transactional flow process? And boy, you talk about a rabbit hole that we could go down, and why is it so easy for the bad actors? You know, after they've gotten some form of entry, point authentication, forged credentials, hijack credentials, whatever the case might be. How is it that they can take a single authorization call and use and repurpose that authorization call to get into tons of other data that our authorization call was never intended for? And works as designed? The idea that I'm going to create authorization layer controls that are way over-privileged. Not from an identity standpoint but from a functional standpoint. Like, why the heck do I need to be able to authorize access to an application that has absolutely nothing to do with that customer's experience? Or that tech workers' experience? We do it all the time. And I think that that propagation that itemization of bad things versus functionality has become such a difficult equation. Because to bring it back to your reference point, like when I started in identity security, the big fight was wrestling proprietary authentication calls from application developers. And you would have thought that the world was going to end. It was like, no, no, no, I got my authentication call; it's my application. Go away, leave me alone. And we're like, Yeah, but you don't need an authenticated authentication call for every application. We can federate and do single sign-on standardized, and by the way, it becomes way more secure. By the way, it's service; you no longer have to deal with that overhead and all that type of issue and maintaining your own access control logs, and all this kind of stuff. That fight was a holy war. Like it was horrible. And the reason it was horrible is because the 15 or so years, or 20 years before, what we had done was we looked at our application developers, and we said, "Hey, go build an application." And they did. And they built an application. They were like, "Well, we need to have an authentication flow for this thing." There was no direction or no securitization, or no information security that was down as part of that plan. You know, getting back to the functionality piece, guess what? This is another example of security. We just have no respect for evidence, data in history. What did we do with authorization? Well, we said application developers go forth and conquer. What do we do with API's? It's just a widget. Just go ahead and use it. How bad could it be? Right and now has sitting here and, people are going, "I don't know how many authorization calls; I never know how many APIs I have." I don't know. And there's no time in security history where the answer equals good things are going to happen from a security standpoint. So, we've let this massive propagation. Obviously, we talk a lot about traceable API sprawl. But there's authorization, sprawl, there's feature functionality, sprawl, there's all of these, and we're not even remotely close to applying the idea of least anything to any of those things. And the more that we live in a world where the expectation is maximum massive access to everything at all times, whether or not we use it, the more that these problems are going to continue to accelerate exponentially. 

40:47 Raghu Nandakumara

So let's talk about API security and the work you do to get Traceable. So, the first question, I was looking through my favorite Zero Trust reference documents this week; those have been the CISA Zero Trust maturity Model and NIST 800 207. And I went through these specifically searching for the section where they're going to talk about Zero Trust and API security. And shock, horror, zero references, square root of zero. What does Zero Trust have to do with API security? Let's start there. 

41:29 Richard Bird

Well, you know that the shortest story answer is that I was sitting on stage with John Kindervag back in Miami. We were on a group speaking panel, and he's waving his hand at the screen. And he goes, "When we get Zero Trust right," he goes, "all security moves to layer seven by policy." And I was like, I think all the blood drained out of my body. But I pulled John aside. I was like, John, do you know how bad have security and internet and web security all that is like, that's the Nirvana state we've got to start talking about. And it happened to coincide with when I joined Traceable. One of the big contributing factors to joining Traceable was I gotten frustrated with kind of progress and innovation in the identity solution space. And I was talking a lot about exactly the example that I gave before about authorization, claim control and security. And there are no solutions for it. Even to this day, there are a couple of folks that are kind of experimenting, who got some science projects that was type stuff going on. Except what I realized was that authorization authentication is the fuel for API's authorization is the absolute nitrous for the engine API's. And also, it dawned on me I was like, well, if you can securitize APIs, now you can begin to securitize the authorization plane, among a host of other things. And one of the things that I find fascinating is just what you discovered. We live in a world that still treats universally, still treat APIs like there's some kind of widget. They're not; it's just an application call, application data store call just represents a microservice. Like, how bad could it get? Well, we're finding out. We are definitely finding out how bad it could get because what APIs represent is a micro encapsulation of the ultimate version of virtualization. They do a thing. And if you're an incredibly smart futurist, and you look back at history, you go, "Oh, wait a minute, we've seen this pattern before". we've seen what the world looked like when none of our engineers knew how many firewall rules we had. We see what our world looks like, when none of our operations center leaders knew how many virtual machines that we had, right, or how many protected self-protected domains we had versus ones that weren't protected. And so, the rise of the API, we just had six or seven or eight years of energy in the creation of API's that exploded. The value return proposition out of all kinds of things data stores that were stranded and assets and services, and it's been great. But it was all done without any security. And now, when we look at it the things that we see, I just, we can go on for hours on this, like, one of the things that I see as a functioning CISO, I'm the CISO for our company, as well as being a market facing voice about all these subjects. I see attacks every week; now, that blows my mind. And I'm like, where's this going if we don't get security around it? The beautiful thing about API's and its association to Zero Trust is API's to run on implied and persistent trust. Which is where this all starts to come together. If I looked at all of the primary five-pillar model of Zero Trust, if I look at the principles of Zero Trust, what I realize is that what John said is absolutely accurate. If I apply Zero Trust effectively to all other components of my security and technology, stacks or strata, or layers or whatever you want to call them. But I haven't done anything about securitizing APIs; I have just sub-optimized every bit of work and every bit of investment that I've made because bad actors can use API'sAPIs to serve as a proxy for every other kind of attack. At every other layer of the security stack. I can use API'sAPIs to das your app; I can use API'sAPIs to fraudulent account creation, takeover, sign up, I can use API's to do data payload scraping. I've seen situations where terabytes of data have been lost. And the bad guys have never come into core systems for that company all API driven. And that's the message that I've been communicating. To your point about SP 800 207, as well as a number of other both regulatory and compliance demands, the absence of the specific term API is problematic and it's challenging, and it is not going to last much longer. NIST has made very clear statements that they anticipate giving specific direction around API's, the FTC, the SEC, the OCC, and the banking industries are either all working on or have already dropped API specific references. For those that would doubt this, if you're extremely nerdy and you have nothing else to do, go look up the Office of the Comptroller of the Currencies Model Risk Compliance document. And in that compliance document, it specifically says, "If you use third-party APIs to drive any of the information into your corporate valuation models, you must account for them and ensure that they are secure and prove it is so." That is not an indicator of ignoring APIs for the rest of our adult lives. One regulator does its other regulators are going to hop in, there is going to be a wave of control demands that come in, and NIST is going to address this ISO, ISO cannot afford not to address it with things like 222, which is a spec that is going to take out Swift. And for those that again, don't know that banking side, Swift only moves all the international trade transactions that go on between large countries and investment banks, trading organizations trading across international lines. And you know, ISO is already cognizant of the fact that APIs are driving all of that traffic. So, we are on the cusp of an extremely different world as it relates to API recognition for the current state, my opening shot is you get everything else right in Zero Trust, you don't get API security right, you don't have Zero Trust. Sorry to deliver that bad news, but it is definitely gaining traction in the marketplace. 

48:18 Raghu Nandakumara

So before, what I'd like to ask you, and we'll go there in a second, is that so what does Zero Trust for API security look like? But before we come there, I'd like to, I know that [at] Traceable, you've published I'd say in the last year, what I believe is this first state of API Security Research in collaboration with the Ponemon Institute. From your perspective, what is the most essential takeaway from that report? Like if there's one thing that executives' security leaders should take away from it, what is it? 

48:53 Richard Bird

Yeah, get your head in the sand. I don't know. I don't know that I could be any more in delicate. But I mean, that's the truth of it. It is the percentages, the numbers, the responses that came out of that report with Larry Ponemon was mind-blowing for me, troubling for me. It is a mathematical proof of what we've talked about earlier, which is, I know I have a problem, I am doing nothing about it. Two years ago, people would say I don't have an API security problem. I got a laugh and a gateway. That wasn't cognitive dissonance. That was willful ignorance. Now we're in this cognitive dissonance phase where it's very rare for me to talk with anybody in the marketplace, and they go, "Yeah, not worried about API's. Got it under control." However, the vast majority of people that give me that acknowledgment also say, "Yeah, but we're still thinking about it," "We're not doing anything about it," or "We don't know what to do." That will change, obviously, in the next 12-18 months, whether it's regulatory demands or more breaches or whatever. But that is certainly where we're at with it today. And the numbers in that state of API security, just backing up incredibly like, there was some 64% of the respondents who said, "Yep, I have definitely had an API related breach or exploit successful." And of those 64%, 75% have basically said, "And it's happened three times, at least." I'm super bad at math, so I don't know 74%, over 75% of 64% is out of the total population of 1,800 companies. But it's a big number, and more importantly, it's a big number and highly decentralized, distributed and incredibly over-connected world.

50:40 Raghu Nandakumara

I'm not sure you can see my screen because the stat that you quoted "60% experience and API related breach and 75% experienced at least three" is literally the one that I'm looking at, at the moment. So that brings me to the to the question: Zero Trust and API security. When you're applying the principles of Zero Trust to API security, what does that mean?

51:04 Richard Bird

Let me first say what many people mistakenly think it means. Well, many people mistakenly think it means that you need to have APIs encrypted. I need to have some form of authentication, encryption, and some form of authorization encryption. And the reason why they say that's a mistaken assumption is, again, let's look at 30 years of history. How has authentication and authorization control worked out for us so far? It is just as easy to forge and or steal authentication credentials for an API, possibly easier, as it is for a given account and identity. One of the very first things I can remember saying to our co-founders when I joined when they asked me what my perception of API security was I said, "I've seen this before." And they go, "What would you see?" And I said, "Well, I can't name the company, very large bank was sitting in the command center with various numbers of members of different enforcement and intelligence agencies, because a certain bad actor nation had gotten into our systems. And what they figured out was, is that SSH keys were meant for application, application server to server device, device, communications. But if you get hold of them, and use them as a human being, and use those to do east-west lateral traffic, you can do a massive amount of damage to a very large bank." All right. And SSH key hijacking, while not exactly comparable to API security, is on a transactional basis, a very strong comparative, right, which is, I can leverage an API to get in, I leverage an API to do things. And if the only thing that's keeping me from doing it is the authentication encryption on a JSON or a JOT, on the authorization, I love that as a bad guy. So, first of all, encryption is not going to do it for you which means that when encryption is no longer your failsafe, then you have to be in the business of continuous monitoring and threat intelligence about an API's behavior. Google actually came out recently with research about an API that was exploitable. And Google actually said, "Well, that API works as designed". And my response was, a claw hammer works is designed for the vast percentage of the time that it's used, driving nails and pulling nails out of boards. But that one time that it's used for a murder weapon, it's really effective as well. It wasn't designed to be a murder weapon. No dude that was sitting in there making his first claw hammer goes, "Well, I want to drive nails, and I think we can use this to kill somebody".  And this is the nature of APIs. APIs are designed to do a thing. But APIs can be leveraged to do many other things, including a lot of bad things. And if you don't recognize that principle, Zero Trust is not a possibility within your environment. Because you're going to design overprivileged over, entitled, over trusted APIs that are swimming around in your environment. And by the way, you can't do anything else to securitize yourself from them because they look like they're doing what they're supposed to be doing. There's a lot of people in the technology world that want more meat on the bone; I get that. They want to get down to design specs and engineering specs and show me how to do this and, and I don't disagree that that's needed, and there is a lot of that. But the real problem here is that we haven't come to the foundational top-level agreement that this is a problem. I can tell you how to securitize your APIs all day long. If you're not ready to do, it doesn't matter. If it isn't operationalized, it doesn't exist. And I think that a lot of the discussion today is once again convincing people that they don't just have a problem. But this problem is existential. This problem is going to create catastrophic consequences. And if you want to argue that I'm just selling fear, uncertainty, and doubt, and you haven't been paying attention because last I checked, we should all be scared. If you look at the results that have happened in security failures today, we should all be scared. And that needs to be what's driving us to be more intellectually curious. And also, to pursue security strategies like Zero Trust, I'll kind of buckle this all up. Like when people argue with me about Zero Trust. And it's just too much and it's very complicated, or whatever the argument might be. My response is always the same, "how's implied and persistent trust working out for you?" Right, because unless you've got an alternative to the status quo, then don't argue with me about how difficult Zero Trust is, because you're not even going to know what that looks like until you start on that journey.  Otherwise, you're just theorizing. And I know what you're working on, what your base assumption now that you're working with; It ain't working. 

56:07 Raghu Nandakumara

I think just to summarize what you said about the sort of API security, and it's sort of like that split between what it's designed to do and what you can what is actually being done over it. And it brings you back to a parallel that John Kindervag often quotes around sort of firewall rules. Bad things happen within allowables because that's what attackers are exploiting.  So, before we wrap up, what does the future of Zero Trust and API security look like from your perspective?

56:52 Richard Bird

Well, I think the future, and there's an argument to be made that I'm overly optimistic on what I'm ready to share. But I, I believe it fervently, which is, I do believe that there's the potential for a future with Zero Trust, that is the utopian state that which is, if you could apply Zero Trust to the largest percentage of your digital estate, every layer, whatever your hybrid architecture is, or if you're still on-premise, it doesn't matter. You can apply those Zero Trust principles to every piece of the componentry. And you drive everything into the ultimate virtual layer, the layer seven space. I think that we can actually be successful and securitizing layer seven, which is in API security, will have a very substantial part to play in that. I think advanced next generation identity control will have a big part to play in that. I think that there are other pieces that will come into focus for layer seven. But if we arrived at a state where those major pieces of componentry were, were fully locked down in a Zero Trust frame, then we could put all of our resources and heavily focus on that layer seven. And I think then, we are in a space where we're on a more equal footing with the bad actors than just another news story about another bunch of servers getting locked down because of ransomware.

58:30 Raghu Nandakumara

I love that. And I think it's what you said. Today, ransomware attackers don't actually even need to be that good to be successful. So, let's actually make them work significantly harder.  So that if they're going to be successful, they better be very, very good.

58:49 Ricard Bird  

Another topic for another day, but a big thing about let's look at physical patterns and security and then look at them in the digital. Like, people can argue all they want, but if you make it harder for bad actors, you do improve security, and you do drive down risk. Yeah, if you disagree with that, ask me how many courthouses you've gone by that don't have large cement barriers and pylons and all kinds of other physical security devices now blocking them. It's because we learned our lesson that we need to slow people down before they do bad things in that building. We need to apply those same kinds of patterns. And I really love the way that you phrased it. Make it harder for the bad guys. Drive them into spaces where you then have a fighting chance against them from a security standpoint, but don't give them the easy ground. And I think that that's what Zero Trust does. I think Zero Trust eliminates the easy ground.

59:42 Raghu Nandakumara

I love that. I was going to ask you to sort of share your favorite Zero Trust analogy, but I think that is such a powerful statement to end on. I should say thank you very much, Richard. It's been such a such a pleasure speaking to you, and I feel that however long we've been sort of conversing for is nearly not enough. So, thank you again, Richard Berg, Chief Security Officer at Traceable AI. I encourage everyone to go and check out The State of API Security Report that is available on the Traceable AI website and really delve deep into the state of API security and how Zero Trust and the application of Zero Trust can help improve that. Richard, thank you.

1:00:25 Richard Bird

Thank you really enjoyed it.

1:00:27 Raghu Nandakumara

Thanks for tuning in to this week's episode of the segment. We'll be back with our next episode in two weeks. In the meantime, for more Zero Trust resources, be sure to visit our website, www.illumio.com and find us on LinkedIn and X using the links in our show notes. That's all for today. I'm your host Raghu Nandakumara and we'll be back with more soon. 

‍