In this Spotlight episode of the Security Ledger podcast, I interview Richard Bird, the CSO of the firm Traceable AI about the challenge of securing application programming interfaces (APIs), which are increasingly being abused to steal sensitive data.
The term “API economy” has been given to the emergence of business models and business practices designed and built around the use of APIs – or Application Programming Interfaces. APIs, today, are everywhere – they’re the foundation of digital transformation initiatives: allowing organizations exchange of data and instructions seamlessly between applications – many hosted in cloud environments.
APIs abused in cyber attacks
But APIs can also facilitate cyber attacks and the theft of data. In 2022, insecure and leaky APIs were the common theme behind a number of major cyber incidents, including the leak of data on more than 5 million Twitter account holders as well as other incidents. While development organizations and the downstream consumers of APIs have enabled rapid development of new applications and capabilities – security, h however, has lagged.
What is the fix for API security issues? According to our guest today: organizations need to recognize the ability of APIs to be used and abused. Richard Bird is the Chief Security Officer at Traceable.ai., a company that specializes in API security. Traceable’s technology enables organizations to identify and monitor the internal and external APIs in use in their environment and grasp the API risk posture as well as “application context” – the complex interactions of APIs, users, data, and code.
In this conversation, Richard and I talk about the challenges of securing API ecosystems within organizations. The key, Bird said, is for organizations to understand the security risks that APIs pose and take steps to both monitor and constrain their use.
Richard Bird (Traceable): I’m the Chief Security Officer for Traceable. I always like to say that I’m in my Benjamin Button phase of my career. I’m aging backwards. I spent 20 plus years in the corporate world. And about 16 or 17 of those were in banking, financial services, hedge fund administration, all in technology.
Before I ever got into the solutions side of the business, I had already been a chief information officer and a Chief Information Security officer as I did two tracks in my own corporate career. And I made the decision that I wanted to try and help more than just one company at a time.
And and made the switch late in my career now into the solution side of the equation. And for the first couple of years I was heavily focused on what I’m known in the marketplace from from an expertise standpoint, which is identity human factors in security. And part of that is because I used to be the Global Head of Identity for JP Morgan Chase’s consumer businesses.
So I got to see it early at scale. I always tell people I’m not an expert. I just accumulated all the scars and bruises that most people are learning about today a dozen [00:01:00] years ago. And I try and share those stories and hopefully keep people from making the same mistakes that I did, but with traceable.
This has been a really interesting change in my focus. I was starting to see a number of really consistent. Parallel issues and threats in the API space that I had been seeing for years in the identity space. And as I of dove into it, I started to recognize that we are moving towards a world where. APIs are becoming the identity access pathway. The way that I like to phrase this and how traceable fits into the equation is that for the better part of 15 years now we have been consistently virtualizing each layer. Of the technology stack. If we go back to the mid aughts, we were, just at the very beginnings of virtualizing OS and infrastructure and servers and then into firewalls and then into each of the different respective pieces.
And now we’ve actually virtualized into the application layer which [00:02:00] means that all of the great things that happen in the lower, evolutions of this change to cloud and full hybrid infrastructure. All of those great things now are available in the application layer plus more massive amounts of business value.
But all of the types of attacks that used to be leveraged against all of those different layers can now be all executed in the application layer via APIs. So with APIs, it’s the old Spider-Man statement. With APIs comes great power also comes great responsibility. However, API security is lacking in the market today. Most companies don’t even recognize that they have an issue. Although that’s changing with the last six months of massive headline breaches and traceable weighted into this space because our founder was born in the DNA of application performance analytics with AppDynamics which he successfully was able to bring to.
And we’ve been able to take that, that, the genetic thread that runs through our capabilities and orient those towards security where we know everything about an a p I all the time, every time, which is creating opportunities for improvements of security in the API layer. That haven’t existed previously.
Interesting, fascinating, nascent market. I love being a part of it. But I also love driving the parallels in both patterns and histories that we through see throughout technology or throughout technology’s evolution over the last 30 years.
Paul Roberts (Security Ledger): And obviously you’re a former JP Morgan Chase employee. This is a company that not only is heavily regulated, incredibly high value target but also that does a lot of. Development on its own right. Huge development staff and teamwork, and a lot of just custom code coming out of a company like that.
Is this something that you saw coming down the road during your time there? Just this, again, I guess we talk about it as like digital transformation, DevOps, whatever you wanna call it.
Richard Bird (Traceable): Yeah, that, I really like the fact that you drew, drew the conclusions back to, JP Morgan Chase and the experiences in the large banking environment. The reason is because the patterns that we see today are only different in the API space in regards to volume and speed. And some of that has to do with the availability of the public internet and, all of the compute that’s now available in the cloud, but the patterns are not inconsistent with what we’ve seen in the past. So when you asked that question, I immediately cringed because there was a time in my career when I, and several of my colleagues lived through what at the time was the Syrian electronic Army DDoS attempt against all the major banks, which.
To a certain degree successful. It took many of the largest banks in the world offline for several days. And so that pattern obviously is now repeated a, in a slightly different fashion in that companies that are heavily dependent upon their digital channels, which are most companies today can now be DDOSed through the application layer and their digital channels and their digital avenues for commerce can be shut down. This is a, this is an attack and a breach pattern that used to require me to assemble millions upon millions of email clients, right? So that I could [00:05:00] attack people’s physical network. Now I just attack the application and the net result is the same.
There’s also another parallel, the early days of, like you said, the early days of what I was seeing that translate now into API security. There was a particular breach that had a due dwell time of months upon months. And it was realized that the bad actors in that particular case had leveraged SSH keys.
Which were encryption keys that were intended specifically for data transport from one application or one data source to another. And they used that EastWest capability, as we called it back then to stay inside of the network and find all of the traffic threads that had the highest value for, theft ne filtration, and then also have the least likelihood of being discovered.
That is exactly the pattern that we see in APIs today the leveraging and use of APIs, not just for North South. I’m gonna take your application out, but East, west, I’m gonna accumulate and aggregate information across multiple sources and [00:06:00] systems, and then bring them all together and extract them out.
Those patterns are common, similar, understood, and historical. And I always like to say that unfortunately I feel like cybersecurity sometimes is the only technology. Trade where we consistently ignore history, evidence, facts, and data. Because we keep getting into these situations where the suggestion is that we need to reinvent the wheel with new technology, new processes, new approaches.
And in reality, what we need to do is take the lessons that we learned the last time that we fixed it, maybe apply a higher volume, higher speed environment. But the basics and the principles are still.
Paul Roberts (Security Ledger): It’s really true. When dig into, quote unquote supply chain attacks, right? Which are the, what everybody’s talking about now and really look at how the attack played out. There aren’t really big differences between the nons supply chain attacks, right? In terms of the initial foothold in terms of what they’re doing within the environment. It’s just where they’re looking for the avenue in,
Richard Bird (Traceable): Yeah. And to add to that, I think that the most disingenuous statement that we constantly see in the news when a company is breached comes in three parts. First everything’s okay. No credit card information or banking information calling, right? When in fact your cell phone number and its confirmation that it actually has a live human being on the end is one of the most valuable pieces of information on the dark.
Not your bank account and your checking account number. But then the other disingenuous part is that we were the victims of yet another sophisticated attack. And yet if you really dig into the details, like you say, if you look at the news and the information that’s shared post breach the number of sophisticated attacks.
Is easily outnumbered by one to 99 in every a hundred attacks. The 99 attacks that are successful are typically poor hygiene credential theft token forgery. I’ve got another click on an yet another ransomware email. , There’s nothing sophisticated about that. Yet we recognize that the corporate world has to make [00:08:00] those statements from a liability standpoint. But it, it’s frustrating because it feels like Groundhog Day every single day.
Paul Roberts (Security Ledger): I, always love the, I always love the we have no evidence in any of the data that was stolen. It’s like a bank being like we have no evidence that the money they stole is being spent anywhere, and therefore, it’s just they stole it. So I think we can assume they’re gonna spend it.
Richard Bird (Traceable): Some of that ties back to as consumers and citizens we do hold some accountability for this because we have the attention span of. Flash of lightning, right? The, for during covid, I actually was very vocal and in a number of media channels talking about red flags as it related to the theft of unemployment benefits and PPP loans in the US economy.
And. And, a lot of pushback on the clanging of that bell. Yet now we see reports that are coming out that clearly show that, billions upon, billions of dollars were stolen. And the vast majority of that is being used to fund cyber threat activities by organized crime and by antagonistic nation states.
And yet it’s rolled on. Everyone’s like, it’s time to [00:09:00] move on. Those billions of dollars don’t mean anything. We gotta go on to the next problem. Thereby, once again, invalidating the importance of history, evidence of data
Paul Roberts (Security Ledger): Richard, what were you doing wading into the COVID era media scrum, to talk about how federal benefits are being used. Boy, that was that was brave.
Richard Bird (Traceable): People remind me I’m Liam Nesson, and I have a set of unique talents that people like to leverage. And in my case, I’m also one of the few cybersecurity folks in the industry that also was also an elected official. And now I wanna say I was a nonpartisan, elected official.
Paul Roberts (Security Ledger): Okay. Do, do tell. You gotta explain that.
Richard Bird (Traceable): I was an elected official. I was on the ninth largest school board in the state of Ohio. But when you’re in elected politics, you get an opportunity to interact with everybody in that in that space. And it gave me some interesting experiences. And then of course, when both COVID came along and issues around election security came along I had I had [00:10:00] participatory experience in both of those and the cybersecurity background. So th those are the kind of things that have really opened up lots of opportunities since I left the corporate world, to be an advocate and a voice. Not just, and things like unemployment loan theft but also, to be more directly engaged in kind of standards and community focuses on different aspects of cybersecurity, and that’s been great, because it’s it really has opened up my aperture, like I said, Benjamin button aging and verse reverse. I get to meet the coolest people and have the best experiences, and I’m way closer to retirement than I am to my next job.
Paul Roberts (Security Ledger): Maybe we should delve into your childhood, Richard. And
Richard Bird (Traceable): Yeah,
Paul Roberts (Security Ledger): that’s a different podcast.
Richard Bird (Traceable): yeah, that story is easy, but that story is easy. But it could be a different podcast. I grew up the son of a of a fishing boat captain,
Paul Roberts (Security Ledger): I’ve thought about doing a whole podcast series where I get cybersecurity people in to talk about anything but cybersecurity because there are so many, as in this industry, there are just so many , [00:11:00] interesting origin stories out there. Especially the generation that we’re of, there was no cybersecurity career that you could aim for.
It didn’t exist. So the way you found your way, into the profession is almost always interesting and bespoke and really fascinating. Yeah. So you Traceable and you talk a lot about API security, but in, its, in the context of Zero Trust and Zero Trust is a concept that came along out of Forrester, if I remember.
Really as a sort of evolution of enterprise IT security, away from perimeter defense and blocking and detection to something that’s much more kind of responsive to the reality of modern threats and attacks, which is. Somebody’s gonna get in eventually you, they’re inside your environment and you need to, basically account for that.
You can’t have this green zone within your organization in which people can just of move around unfettered. Talk about the role that addressing API risk plays in the larger kind of zero [00:12:00] trust like paradigm.
Richard Bird (Traceable): Sure. It probably helps to set the table a little bit with my, about my relationship with Zero Trust. So I’m very fortunate. I always like to say that I’m the I’m John Belushi’s Animal House character that gets invited to go to the cool fraternity. And and Bluto gets the opportunity to be invited to the Zero Trust and I’ve been working closely the last couple of years
Paul Roberts (Security Ledger): My advice to you start drinking heavily. Sorry.
Richard Bird (Traceable): I have had the opportunity to hang out with and opine and, sing songs with the best and brightest minds in Zero Trust. John Kinder Bag, chase Cunningham, Greg Tuel the, there’s a host, Eve Mahler. There’s a host of these fantastic folks that I get to work with in, in the Zero Trust Institute.
And it was always perplexing to me when I got invited. They said, come join the Zero Trust Institute. And I said, I’m the identity guy. What am I gonna bring to the table? I’ve actually been very resistant to many of the conversations around zero trust because it almost intuitively and reflexively causes an identity person to think about friction.
And then I dove into it and I realized how [00:13:00] horribly wrong I had been and how important the. The key components of both identity and APIs are in the context of zero trust. And by that I also like to simplify zero trust because I think that market messaging solutions providers have usurped the message of zero trust.
There are a lot of people in the practitioner space that feel overwhelmed with what they perceive to be complexity, but the, complexity is in the messaging, not in the. Concept, right? I like to boil down zero trust to just being as simple as the goal for zero trust is to eliminate implied and persistent trust in your networks, your systems, and your processes.
It’s just as simple. And then people go give me an example. And I’m like your developer logs on to their particular interface to do their programming and they’re given an option would you like to keep this session authenticated for the next five days? That’s an immediate violation of zero trust, right?
And the argument can be made while I’m doing that to make it [00:14:00] convenient for my developer, because those are rules that are actually set by the people, the customers that buy those solutions. Those aren’t what the solution providers are recommending. And and yet we tell ourselves that the availability of convenience or the availability of a frictionless experience is more important than security. Therefore, let me leave this session available for five days, right? And all it takes is a bad guy simply getting into the system, finding that available session, aggregating those credentials, and going off and doing the bad things, right?
So that’s both implied. I got a develop. And he should have this access, or she should have this access. For long durations of time and persistence, I’m gonna give them that access for a long period of time. Both of those are incredible security weaknesses. And they come right to the point as it relates to zero trust.
And now we roll in APIs. APIs really have a lot more to do with identity type transactions than they do with application security, right? If we [00:15:00] think about it, an API is requesting access usually associated with a, some kind of authentication token that allows them to attach to extract from the resource or asset that they’re reaching out from. So if we think about that example years and years ago about the persistent access that was available because of an SSH key breach. It was because that key was meant for a functional purpose. That wasn’t a bad purpose. It was designed to do a thing, and the bad actors went in and grabbed a hold of it and did a bad thing with it.
APIs are exactly like that. I’ve had people that have watched red team activities. I’ve had API developers that have watched a red team hacker, a white hat disassemble their a P I and turn it into a weapon. And I’ve watched a api. I developers go wait. But you’re not, that’s not what that’s supposed to do.
And I, of course, a hacker’s I don’t play by your rules, right? I think that the reality is that all too often in the technology world, people say, I’ve designed an API, [00:16:00] it’s fit for a purpose. And that’s what it’s supposed to do. Therefore, I’m okay from a security standpoint.
And they missed just a very simple example of how something that’s designed to do something specific in that case an API, but let’s take a claw hammer. I can take a claw hammer and I can do two things with it. It was designed specifically to drive nails, and the backside was designed specifically to remove nails.
It also has proven over, the course of history had been extremely effective murder weapon, right? It’s
Paul Roberts (Security Ledger): end really
Richard Bird (Traceable): It’s not designed to be one. But it, but now it comes down to intention, motives means what, why somebody would want to use it for that. And it, another fascinating thing about API security and zero trust and the use of a hammer is that obviously in the presence of a hammer – construction site, working with my kids on a home improvement project I have an expectation of that hammer to be used for a very specific purpose in a very specific way. The challenge there is that I have no idea that it’s going to be used for a bad purpose [00:17:00] until it’s too late. I don’t have the capacity to respond to something being used for something that it’s not intended to be used for if I have not conditioned my system to do that. In the API security space, our zero trust focus is addressing and bringing the conversation to what’s classically been called layer seven.
Which to be honest one of the big things that I’ve been doing over the last several months is rallying up all of this tremendous talent that I have in this hall of fame, group of friends that I’m associated with in Zero Trust and saying, Hey, I know you guys are super cool about, all the zero trust stuff, but we’re missing it in the application layer, and the way that we achieve it in the application layer is APIs, and I’m getting a lot of agreement to that, but the application of zero trust to the application layer or layer seven is new. It’s not new in terms of we already know how to do it, but it’s new in terms of thinking about exercising zero trust type control in the application.
Paul Roberts (Security Ledger): And what does that mean practically for organizations that are either, [00:18:00] either designing and deploying web applications for their customers or conversely the, know, the end users who are bringing those into their environment. Maybe accessing, using, leveraging APIs internally and and so on. What do they need to be doing differently than they may be doing right now?
Richard Bird (Traceable): Yeah, the, the initial steps all tie back to that same easy thesis, right? You need to be designing APIs. Let’s take the security component out of it for a minute. You need to be designing APIs with a mindset that I’m not going to allow. Implied trust or persistent trust, right? Now it, persistent trust may be ne necessary when you develop an api, right?
Traceable does billions and billions of calls from a security standpoint every month. The introduction of friction of some type of confirmation check every single time would probably be inefficient, but I know then that from an API security standpoint my weakness is gonna be this availability of persistent access on this API call.
[00:19:00] Therefore, I need to monitor it every single time it’s used, right? And I need to be able to aggregate information about its behavior every single time that it’s used. There is a beauty to APIs. It’s the same beauty that the Claw Hammer has. They are all designed for a specific purpose, right? And it is only once they’ve started to be used for something they weren’t intended for that you start to have red flags about.
Am I exposed? Do I have a risk? Is there a breach? And so it’s actually easier with today’s available compute for us to say, okay, in this case, in your documentation, this API says that you must be able to keep an authenticated session open for however long. But we know that we then need to monitor and provide enriched data about that API across the course of its time usage and life cycle.
Really in the API space, from API development standpoint, it is design out as much implied and persistent trust as you possibly can in your standards, practices and best practices within that [00:20:00] development lifecycle. And then on the security side, it is…. You have to know everything about that API at all times in order to be successful in knowing when it is leaving its lane. And it’s this leaving its lane principle that web application, firewalls can’t catch
Paul Roberts (Security Ledger): So what is that? What is leaving its lane? What are some examples of leaving your lane? If you’re an api,
Richard Bird (Traceable): The easiest examples tend to always be geolocation, right? An
Paul Roberts (Security Ledger): accessing it and where?
Richard Bird (Traceable): Yeah. An API has been associated with a specific endpoint, let’s call it, in this case, a third party endpoint, right? Supply the supply chain example, right? I have a third party provider. They provide me information that goes back into. I don’t know, my logistics system and I’m using this API to reach out, however as I’m doing this security monitoring over the course of this API’s available lifecycle my system security, API security system confirms that the actual geolocation of that endpoint has changed. It’s no longer [00:21:00] in Kansas City it’s in North Korea. And that probably means
Paul Roberts (Security Ledger): Just to throw a country out there.
Richard Bird (Traceable): Yeah, just throw our country out there. We actually have a very interesting real world exploit use case. We talk about it in one of our podcasts at Traceable where we caught a company.
We caught a facilitator here in the United States that was providing a IP platform. And there were there were eight different sanctioned nations that were sending traffic through that platform to fraudulently sign up for new accounts.
And they were coming from Russia, Syria Iraq other embargo nations. And and no other solution that’s out there could catch this. And the reason is because once it landed in the IP facilitated space here in the United States, and this is the most important thing about APIs and API security, it looked like normal traffic.
Paul Roberts (Security Ledger): Right.
Richard Bird (Traceable): You have to get down to the trace information level before you have the indicators that something may be [00:22:00] wrong. That causes the need for additional investigation. But this is the real struggle in the API security spaces that APIs that have been bent abused to do bad things still look like good traffic.
And it requires a lot of threat intelligence to be aggregated about the actual API not depending upon researchers and hoping catch a vulnerability, based on, MAL configuration or malformed API code. You actually have to understand the behaviors of these things, and that’s really where Traceable excels.
Paul Roberts (Security Ledger): There’s been a lot of really interesting research come out in the last six months or a year. Independent security researchers poking around. Web applications for, Fortune 500 companies often with some really interesting findings around just, underlying application security weaknesses.
Sam Curry did a whole bunch on like telematics apps SiriusXM this guy, Eaton Zveare did, has been camping out on Toyota’s application. I don’t know why in particular auto automotive [00:23:00] makers are attracting so much attention, but it might be because they’ve got, 3000 pound, endpoints road riding around on the streets. And finding some really…just head slappers. And so my question to you is, clearly these are well-resourced companies that are doing a lot of, it’s not like they’re new to application development. They’ve been doing application development for a long time.
How are they not tripping over these bodies that these independent security researchers are discovering? And what needs to change from a, internal, process perspective such that, they start to find these things before the third party guy does.
Richard Bird (Traceable): This goes back to, are we using the lens of history to really understand the core, the root cause of the type of problems that we’re seeing? And we look at Eaton’s work, right? It’s not just Toyota, bmw, Mercedes we look at the, the recent issues. Yeah, we look at the recent issues with Hyundai and Kia and look, there’s, I think that the, the automotive manufacturers are interesting, easy to understand example of what the [00:24:00] problem is and how we may have been trying to pursue the wrong or the solution from the wrong end of the equation.
And when we look at these automotive manufacturers, I got a. Sprinter van. This is my, the, my Sprinter van, adventure van is my wife’s and my boat. Instead of going to lakes, we travel all over the Western states and we love it. Right?
Paul Roberts (Security Ledger): Hashtag: van life.
Richard Bird (Traceable): Hashtag Van Life, right? But as a consumer, I love all the widgets, man.
I love all the bells and whistles. I love, yeah. I love the fact that I recharge my van on my using my phone this morning to make sure the battery stays up when it’s time for us to go out. And it’s this it’s this rush to consumer value the rush to consumer joy, right? The fact that it budgets are really only in theory controlled by the CISO.
IT budgets are controlled by the business, right? And IT actions, or it, or security actions are controlled by the business. And this continuous decades long rush to greatness, right? Speed to market, speed to value, all these kind [00:25:00] of things. I used to get so angry being an IT executive management at my, application developers, my DevOps team when I was in security because I’d say, you guys are the bane of my existence. You know what you’re supposed to do, but you code this thing and then we throw these vulnerabilities into production. What are we doing?
Paul Roberts (Security Ledger): Yeah.
Richard Bird (Traceable): And then the argument we have is we just need, we need to just make developers smarter about security.
Paul Roberts (Security Ledger): A boil the ocean solution.
Richard Bird (Traceable): Yeah. Here’s the bad news. After 30 plus years and the examples that we’re now seeing with these APIs, it ain’t never gonna happen.
Paul Roberts (Security Ledger): Yeah.
Richard Bird (Traceable): And I was wrong back in the day about being angry about it. It’s never gonna happen, and it never should. And the reason is because DevOps job is to deliver business value with technology solutions.
That is their job. That is what they do. And and we, and the security trades have typically tried to come in over top with truthfully onerous and challenging processes to keep developers in their [00:26:00] lane to use that again. And it doesn’t work. And it doesn’t work for a number of reasons.
The business has more money than all of us. The developers have a mission that they’re supposed to accomplish, and it causes them to, get blinders and locked into achieving that mission. Security is, and I’m sorry, corporate America security is grossly underfunded. When we look at the actual consequences that have been racking up in cyber crimes and losses and so that formula hasn’t changed as we’ve gone to the cloud world, right?
So I’ll go back to what I said earlier, the Spider-Man analogy, right? With APIs comes. Opportunity or, massive business value creation. But also comes great responsibility in managing those APIs and companies are just now getting started on that. And I’m gonna leave off with just one other important component of this historical piece, which is there’s not very much research on it.
I wish there was. But the reality is that if you worked in it for any length of time, what you know is that every new. Every new big thing, whether it’s cloud or it’s [00:27:00] serverless or passwordless or this, that and the other, every big thing. That comes along in it, security lags behind by five to six years consistently.
And so now we think about APIs. The API economy has been about 10, 12 years. And we only started wrestling around about our concerns about API security about three or four years ago. Only now am I seeing actual headcount, leaders for API security, API programs being stood up.
Interestingly enough, the vast majority of them are in highly regulated banking. But that does mean that we’re beginning this process of catching up with security. But all in all, like everyone’s loved the benefits that APIs have created. But if I’m a, if I’m an automotive manufacturer, never in my waking days did I think that the bad guys could use APIs that were inside of vehicles to get back to core corporate systems, right? That is something that happened in the web beginnings of the web world, but it took [00:28:00] years. When we look at how long it’s taken in the world to do that through APIs? It’s been months and that acceleration risk is because of how big, broad, deep and wide the API attack surfaces. And all of the bad actors in this world are rushing to see how they can capitalize on that attack layer that, that expanded attack, universal attack vector, if you will.
And obviously if the bad actors are going in that direction, some of the researchers who you talked about they’re gonna, they’re gonna play in that space too, because they just know that’s where the weakness is.
Paul Roberts (Security Ledger): Fish where the fish are.
Richard Bird (Traceable): You bet.
Paul Roberts (Security Ledger): Final question. So the. Biden administration has come out with a number of directives and initiatives and, since since 2021, obviously the executive order, and then more recently the National Cybersecurity S trategy. That they released a policy document but one that really does put the onus back on software publishers to secure their stuff.
In, in other [00:29:00] areas of the Biden administration has also talked up, zero trust as a model for federal agencies to be pursuing and contractors who sell to the federal government and so on.
So interested in your thoughts on the impact of all that and whether we should, whether that is going to move the needle in terms of federal cyber and then also adoption, elsewhere downstream.
Richard Bird (Traceable): Sure. The reality is that it’s gonna move the needle in terms of concerns at the board level. Both in the corporate as well as the solutions world. In terms of actual results and outcome, I’ve been on record I’ve been waiting in the the federal legislation space for several years now as well.
And have actually helped, along with other people, not individually, but helped other people to draft. Legislation that’s gone in relative to data protection, privacies and that kind of thing. We’re continuing to bark up the wrong tree here. Specifically when I think about cisa and I think about the White House’s executive orders.
They have brought, successfully brought attention. To a woefully misunderstood and mismanaged attack threat that [00:30:00] we’ve had, for decades, and I appreciate that. The problem is that, our representatives, the, both the Congress and the executive branch have been gutless in the creation of a national data privacy standard. reality is this is no longer a theoretical argument. The GDPR under the EU was created specifically to make the EU the world’s leaders in the digital economy. And now we are at a disadvantage. We’re at a disadvantage in the global economy because we can’t get our act together around things like data privacy, which means that, when the new strategy comes out, here we are again recycling the old argument that we’re gonna contribute 81 or 91 million to improved incident breach reporting through the CISA organization and it incident reporting is not security.
Incident reporting is post. And incident security is just simply like an alarm system that goes off three days after your car was stolen, right? It, and yet we keep leaning a lot of our legislation and a lot of our thinking about security towards reporting. [00:31:00] And fines that go to self-funding, regulatory agencies and fines that don’t net to any of making the consumer of the citizen whole.
To be honest, I don’t think that we’re gonna see much in the way of advancement in cybersecurity until we actually start talking about real consumer. Digital consumer protections and citizen protection protections and holding, keep people accountable for that. The idea of pushing the risk back after the solution seller it’s appropriate in one context, right? Very few solutions, security solutions companies get stood up because the people that are associated with it wake up every day and they’re passionate about the mission, about solving that particular problem, right?
Most of those companies are stood up because there’s a market opportunity and there’s a potential for success financially, right? That doesn’t necessarily make for the best ingredients on creating the world-class security solutions that we need. And that, that’s proven right. We know that hundreds of new cybersecurity startups are created every month, right? And they’re the vast majority of number point solutions by design. But then, by pushing [00:32:00] that risk back to the solution providers, it invalidates and ignores the truth that and this is all data and evidence supported that the massive, the super majority terms of percentages of causes of breach are human error at the operator level, right? And there is truth and implemented correctly, or I’ve decided to invalidate or turn off that particular rule of configuration because it’s inconvenient. Or, the best example that I always like to use is multifactor authentication. I get people that say you know what? My system is too old. I can’t use multifactor authentication on that. That is not multifactor authentication’s weakness. That is your unwillingness to update your technology. Not saying that, legacy technologies are bad because if they’re still generating value in everything, but if you can’t achieve Secur, the best security practices available it’s not the solution provider’s problem If you are unwilling to refactor your application to modern technologies.
Some people think that the strategy is amazing and that should be pushed back up to solution providers. Some people think that, it’s [00:33:00] just a recipe for a whole lot of problems including, people being resistant to building security solutions because the risk outweighs the reward.
So I, on that end, I think it’s good that it’s opening up the cybersecurity community for a lot more debate and dialogue discussion. But I do think that we’re back to the point. I think that we’re trying to solve the problem from the wrong end of the equation. Let’s actually make a commitment to protect people in the digital world. And that will be begin, that will be the beginnings of improvement.
Paul Roberts (Security Ledger): You can certainly look at a lot of these, incidents, these reports or audits of these, whether they’re authorized or not of these companies. And say these are, these are very large and wealthy companies that are clearly not investing. Or invested in application security, like they just do not perceive it as a reputational or business risk, because if they did the, they wouldn’t have been able to find what they found.
Richard Bird (Traceable): Yeah. To that point, I’ll be very specific. I’m an outcome. Oriented human being. [00:34:00] I wanna see results. I don’t wanna see a whole bunch of, regulations and guidelines that don’t yield results.
But if we were really serious about it, what we would require with incident reporting is that any company that is breached has to publish its forensics report on how it was breached. And the gnashing of teeth and the ringing of hands that accompanies that statement when I bring it up is we’d just be telling the bad guys how to attack the next time.
We already are. Yeah, we’re, we already are. Like if we think that a breach and of any company, those methods aren’t shared almost instantaneously in the economy of the bad actor we’re kidding ourselves. Yeah. And look, there’s a certain, there’s a certain embarrassment. That comes with this. Publish your forensics so that people can see that 80 to 90% of the time. The reason that you got had was because you failed at the basics of cybersecurity. The very basics, the core fundamentals of cybersecurity are what caused you to get [00:35:00] hit, and that will start to change things, I think, because people will begin to
Paul Roberts (Security Ledger): It’s just, it’s like a public health thing, right? It’s like very, it’s very hard to understand. You think back to the original kind of typhus, where the guy plotted out the cases and found the wells that, were infected or, any, car accidents or gun shootings or whatever.
It’s very hard without the data to look at, to understand the problem and therefore respond to it. And I think that’s certainly true in cybersecurity. We have a very … like pointilist picture of cybersecurity. Some little dots here, but it’s very hard to see the big picture.
Richard Bird (Traceable): The point that you just made, the fact that we do not share. And collaborate amongst organizations in this country and amongst agencies in this country on the hows, whens, whys, and whats of each breach.
Confirms that we absolutely ignore history, evidence, fact, facts, and data, right? Like we are collectively choosing to say, I would rather stick my fingers in my ears. And also I would rather not [00:36:00] embarrass myself and expose the methods of breach that were used against me and because that information is not being shared, we repeat the same mistakes every single week.
Paul Roberts (Security Ledger): And therefore, as the saying goes, we are doomed to repeat it.
Richard Bird (Traceable): Doomed to repeat it. Absolutely.
Paul Roberts (Security Ledger): Richard Bird, Chief Security Officer at Traceable AI has been such a pleasure talking to you. We’re gonna have to have you on again. This has been great.
Richard Bird (Traceable): Good. I had a lot of fun!
(*) Disclosure: This post was sponsored by Traceable.ai. For more information on how Security Ledger works with its sponsors and sponsored content on Security Ledger, check out our About Security Ledger page on sponsorships and sponsor relations.