Episode 108: Adam Shostack on Cybersecurity and What Every Engineer Should Learn From Star Wars

Informing your decisions with intelligence analysis and insight brought to you by the team@ooda loop.com hello, I'm Bob Gourley, the Chief Technology Officer of OODA llc. And today on the oodacast, Adam Szostak. Adam, it's great seeing you.

Great to be here.

You know, Adam, there's so many things I want to talk to you about, but I'd also like to introduce you to friends and associates and viewers. Let me tell people who I think you are and then you can correct the record. Adam, you are widely known as a security professional. You've written many books. You've helped further in advanced concepts like threat modeling. You've helped keep big community activities like Black Hat professionally run by being on the Black Hat Review board and helping shape the content there. You've also written things of use for executives and engineers, including a book I want to spend a little time on today about how you can apply the lessons of Star wars to security engineering. Those are the things I think of when I think of Adam, but I think that's a.

It's a. Thank you. It's a great list. The only other thing I like to add is or mention is early in my career I helped to create the cv and we were talking before about simplicity. And I think the CVE is another example of something very simple yet very powerful. And I think there's a lot of power to simplicity and I think we're going to talk about that today.

Yeah, let's do that. And let's also, I think I should ask it this way. What is the cve? So this.

So I have a weirdly jargony term that I like to use for the cve, which is the CVE is a concordance. And a concordance is an old school way of indexing things. It's a way of referencing between things. And so what a CVE really is is a tag that says I think this relates to other things that also have this tag. And so a CVE is used to tag a vulnerability. And so If I use CVE 19991234 and you use it, we are almost certainly talking about the same thing. And when we have something like a vulnerability, you know, maybe I want to talk about the proof of concept code, maybe I want to talk about the code in which the vuln exists, maybe I want to talk about the patch. And I need a way to cross reference all of those things. And the CVE is that simple thing that lets us do that cross referencing and create concordances between the way we work in the world.

I know it certainly helped standardize conversations, strategies, approaches, and led to even more technical standards as we build technologies to help rapidly assess vulnerabilities and prioritize which ones to fix first.

Absolutely. And you know, there's a fascinating evolution. We went from having nothing to do that to having CVSS v2, v3 EPSs. And the fact that CVEs are so simple enables that innovation to happen because you don't have to change the CVE standard to change the risk rating standard.

Adam let me also another foundational question. How did you get your start in cybersecurity and risk mitigation?

So I got started as a systems administrator. I was working at a medical research lab and we were doing amazing stuff. They're still doing amazing stuff in surgical planning, bringing computers into the operating room to control surgery. And if you're going to do, if you're going to do things to a human being and bring a computer in, you need to secure that computer, you need to protect it so that it's safe and effective what you're doing. And this was in the early 90s. And that's how I got started in security.

Right. Early 90s. I remember those days. There was an Internet, but maybe, you know, 50, 60 million users on the Internet, soon ramping up to maybe 100 million users. These were the halcyon days of cyber security when there was not. I don't even know if there was a CISO then the first CISO would have been the mid-90s. So this is the early days of cyber security.

I remember when both Applied Cryptography and Bill Cheswick and Steve Bellavin's Firewalls and Internet Security came out. The only book I could find on the subject at my local bookstore, because this is also before Amazon existed, was Gene Spafford and Simpson Garfinkel's Practical Unix in Internet Security. That was the one book on the topic back when I got going, oh.

This is, you're bringing back a lot of memories. I, I really got focused on cyber a little bit after you, but it was say, 98, and there was still the early days. And I wanted to use that as a segue to threat modeling because when I, by 98, I was a Director of Intelligence at Department of Defense's first real Cyber Command. JTFCND we did not use the term threat modeling. We were big on the threat. We were, you know, track your adversaries, penetrate your adversaries, understand what they're doing, inform operational decisions. But threat modeling was not a concept that we were using. And years later we, I would start to hear it and it never really seemed like there was a professional approach until I saw people like you writing about it and teaching. But that came much later, correct?

Yeah. So the first time I used it was 1999, at least the first time I used it in like a published paper. And Bruce Schneier and I wrote a paper on threat modeling smart cards. And the way we did that was we talked on the telephone and we talked about what would go wrong with smart cards and we organized our thoughts. But essentially this was an approach of smart people are going to think hard about the problem and help you think about it. There was no structure, there was no organization. And right around the time that we were doing that, some folks at Microsoft were writing a paper on stride and that paper was hidden in the archives for years they talked about it, but they never released the paper for like a decade. So we didn't know that was happening. And it really wasn't until I joined Microsoft 2006 that I was really pushed hard to think about don't do the work, empower others to do the work. Because you just don't scale to really any of the products that Microsoft works on. You can't have one person who has all the knowledge in their head influencing all of the engineering decisions that are being made across something like Windows or Xbox or even, even a smaller product like Encarta or something like that is just big enough that you need to bring, you need to teach it, you need to make it repeatable, you need to make it consistent. And that was a, that was a really hard shift because we had all learned how to do this in this apprenticeship sort of model. I, I remember conversations with like Steve Bellavin, Marcus Raynham on the firewalls mailing list in which we thought about these things. I remember conversations on like the cypherpunks mailing list in which we thought about how do we think about threats and how do we abstract them a little bit so we're not totally in the weeds. And it was all osmosis. It was a hundred percent. Spend days, weeks, months talking to people and eventually you learn to make these things go.

You know. Around that time, the world started getting even more interconnected and complex. By 2006, smartphones had been invented, but they had not proliferated everywhere. Now it's just the Internet's grown to touch almost every person in the world. Smartphones are all over the place, Iots, everywhere. There's it in space, it's just even more complex and interconnected. And I think it just underscores that we do need scalable methods to really teach and think about threats and threat modeling or it's just not going to work.

You know, I, I really believe that if we don't ask engineers to think about security, we don't tell them what success looks like as they're doing it. They're not going to. And, and so this is sort of, this is sort of self evident, but all of that stuff is being built by engineers. And then the way we often talk about what are we going to do to help them is we're going to have a pen test at the end and a bug bounty. Once the satellite is in space, it's somewhat difficult to replace the hardware. Once you've shipped 100,000 devices, a million devices, 50 million devices, you're never going to replace the software on all of them. You might have a good update rate, 80, 90%. But if we get it right the first time, if we get it, if we bring security into our thinking so that we can think about updates, we can think about what the categories of issues might be. We deliver better systems from the get go. It's cheaper to, you know, there's the old, there's the old expression, there's never time to do it right. There's always time to do it over.

Yeah, yeah.

Threat modeling is a little bit of, let's try to do it right the first time.

Yeah. You know, another point I want to mention about your approach to threat modeling is you organize things around four simple questions that I'd like to read right now because I think everybody should appreciate these. Your four questions in your framework are what are we working on? What can go wrong? What are we going to do about it? Did we do a good job? And these are all important questions. But one observation I have is these are also easy to understand questions. You don't have to have an engineering degree to understand these questions. Now you may need to be, you know, pretty technical to get deep into the answers to these questions. But it strikes me that these are the kind of things that will work not just with engineers, but executives. These are easy to understand questions.

You know, one of, there was, there was some news, we're recording this on February 2nd. There was news this morning about the Federal Trade Commission finding some medical good Rx, I think it was. They do prescriptions. And one of the things I read about this was the questions that you should be asking yourself as an executive is, does Our technology, meet our brand promise, and we can get into all sorts of details. But you, as an executive, can ask that question, Bob, are we doing anything that would shock our customers in your code? Yeah, we are. Tell me about that. I see you nodding. I didn't get a quick answ.

Yeah.

Right. And these. And we're joking, but I'm not joking. Sometimes we want the technology to be complicated so that we can be wizards in the tower doing our wizardy thing. But as an executive, if. When I work with executives.

The.

The thing is, what we're doing in most companies today is we're attempting to generate a product which has value to some customers who will give us money or something else we want in exchange for that. Right. Their time, their attention, including that we show them ads. But at the end of the day, we're making these. We're making these products and we're delivering them to people. And if you can't understand, and I hate to say this because this is going to sound a little confrontational, as an executive, you have to understand the business you're in.

Yeah. Yep. And it pays to understand what could go wrong.

Yeah. And, you know, your answer as an exec may be different than my answer as a developer, but asking the question in the frame of what can go wrong enables us to start talking about our different answers. And at least we know I. I like to talk about it as singing from the same page in the songbook.

Yeah.

Right. We, we might be in different keys, we might be a little bit off, but we're at least trying to do the same thing. And we know it.

Yeah. And then the final question is also so critically important because it hits on metrics. How do you know if you're doing a good job? And I know that would be different for a development team or the CISO team or maybe the incident responder team or the board, but how do you know? The metrics is critically important.

Yes. And even before we get to metrics, the reason I include that question is when you're starting to do something new, it doesn't feel great. Right. You're, you're, you're figuring out, how does this thing fit, what am I doing? And giving people a chance to talk about. I felt really at sea when we were doing this. How can I get more grounded? How can I. How can I check my work? That.

Is.

So. It's just crucial. And I tell executives there's a really easy way to figure out if your threat modeling is working. And you've done this before. In fact, as an executive, would you recommend threat modeling to a colleague? Right. It's the net promoter score question. And if the answer is not the enthusiastic yes, what's going on? What is it not worth the time? Do you not feel skilled? Are you not finding good results? Why are you not recommending this? And your answer might come out in like, I tried to apply the Lockheed Martin kill chain and I wasn't sure about the difference between exploitation and persistence. And so I felt bad about the work. Okay, great. I have no idea what that word salad just meant. You might be thinking as an executive or you might be a cyber executive and say, okay, let's talk about what that means. But if you're not getting the yes, you know that the person doing the work who you're paying because they have a brain is not happy. They're not, they're not taking pride in the work that they've done, and that means something. And by the way, we can get into metrics. We can talk about things like how many people have reviewed the threat model and how many elements are in your diagram and how many threats did you find and how many bugs did you open? And much more crunchy, hard, technical metrics. But if we leap to those technical metrics instead of starting with some strategy, we may miss the most important thing. And I think it's a shame to orient ourselves to the purely technical metrics and forget where we're going and why we're doing the work.

Adam, I want to segue now and talk about your most recent book, because I really enjoyed that now. It's a book, really. I think the folks will get the most use of that book are the engineers and the people that need to interact with engineers. I have to admit, although I've got technical degrees and a lot of hands on time, I'm not an engineer. But I really have to track all those topics. I need to have those in my vocabulary and it can become hard for me to remember these things. Reading your, your book, I saw a good framework of ways for me to keep things front of mind because you are drawing analogies to movies that I know and love. So the, the title of the book is Threats, Threats Securing what Every Engineer Should Learn from Star Wars. Until I read your book. If you ask me, what is Star wars about? Well, it's a hero's journey. It's a young man from a moisture farm who gets pulled into a space western. After reading your book, I have a totally different view of those movies. What do you think Star wars is.

It's. Star wars is so many things, but fundamentally, one of the things that Star wars is about is it's about hope. And my book is about hope. And it's a book about this hope that every engineer will start to take security into consideration as they build things. So, you know, if you're building an astromech droid, maybe it needs a way to authenticate the people around it so it can decide it's going to play the recording of Princess Leia saying, help us, Obi Wan. You're my only hope. To Obi Wan, but not to Luke skywalker. And if R2, D2 is going to be able to do that, you need to be able to construct some sort of authentication technology that R2 can use. You need a database of people. R2 will need a database of people. That includes Obi Wan and Leia. And you're going to need some sort of user interface like, that allows Leia to say somehow magically, you know who Obi Wan is, and play this video for him. But. And so Star wars can act as. It's all the things you said, right? It's a space Western. It's a hero's journey. It's a boy's relationship to his father. It's a great movie. It's a wonderful franchise. But the way in which the George Lucas and then everyone involved built a world in which the technology is part of the storytelling really gave me a canvas and a palette on which to draw and to tell a new story, which is all about threats. And it is a somewhat technical book, but it doesn't. It doesn't require huge amounts of technical knowledge. Right. There's. I think there's a little bit of code in a couple of chapters, like five line snippets to be explicit about this or that. But it's really designed, as you say, for engineers and the people around them to be able to have new conversations. That was a long answer. Sorry. It's great.

And, you know, because there's so many scenes you pull out of the movies, one that you have me thinking about now is the opening scene, which is really about an attempt to recover some stolen intellectual property. Now it's stolen from the bad guys, but it's, you know, why wasn't that property protected? Why didn't they have digital rights management of some sort? Why wasn't it encrypted where only some entities can get it? And look at the importance to them of that small amount of data that they would launch an entire force to go out and Recover this.

Yeah. So. Okay, so I'm going to do this. I'm going to do this. The reason the data tape is not encrypted is, is because key management is hard. And if somebody can break into your planet, which is secured by some crazy shield thing, and get past all your guards to the Tower of Tapes and get the data tape they need, maybe that risk is smaller than the risk that you're going to lose your encryption key and be unable to read the tape later. And so it goes to what can go wrong and the various defenses. Right. Should we. Should we have encrypted this? Maybe, maybe not. We can make an engineering decision about that.

Yeah. And so the people making the decision on should it be encrypted need to have an understanding of the potential impact if it gets lost.

Yeah, yeah, absolutely. And by the way, and this is a point someone else made before I did in, in Star wars, on what we now call A New Hope, the first movie, the scene in which they're discussing the loss of the data tape, actually a reasonably well done depiction of a data breach board meeting until the moment that Darth Vader walks in. They're talking about what happened, they're talking about impact, they're talking about response options. And then Darth Vader comes in and the whole meeting derails. It's bizarrely well done as a thing in the movie. But that's just Star wars for you is so much of it. Is somebody thought about what conversation would these folks be having at this point and wrote the dialogue and the dialogue still works.

It is fascinating to think about. And maybe, I mean, it's the master storyteller, George Lucas, who understands humans and human natures and their dynamics. But I can think of how incident response could be impacted by the wrong leaders coming in and doing the wrong things. And I've been so fortunate to work with a lot of good leaders who are interested in doing the good things. But I hear stories of folks who shut things down too quick or this was not a breach. There's no evidence that was taken. There's no evidence this was disclosed. This is not of material impact. No. And no shareholder would be interested in this. Shut it down or we don't have to comply with GDPR because no one actually took that data. Or, you know, name your 50 other regulatory regimes. Oh, it's fascinating. You know, one, one area that seemed to be a little hard to get lessons from the Star wars movies for was dos. But you did manage to. To find one. I think it's the only one I could think of is Han Solo was, in a way, shut down.

Han Solo was shut down. And I think. I think in that chapter, I actually go outside the core movies to episode one, where, although that's not really a dos, it's a denial of service where Anakin blows up a ship and all the droids shut down because the intellig is centralized and there's one brain for all of them. But that's not really a DDoS. But yet, you know, one of the things I learned in writing this book is you can't stretch. If you stretch and you're like, well, this is sort of like a DDoS. And so I'll talk about it as if it is a DDoS, you risk the reader's trust. And so if there's no DDoS example in there, the reason is I couldn't think of a way that it felt natural and good to talk about. And so rather. And yeah, that makes a lot of sense.

What other scenes do you think we should talk about?

So we're talking about leadership a lot. And I actually want to go back to the theft of the plans, and I want to. Again, I want to. Okay, so in the book. Let me just be upfront. The book really focuses on Star Wars, Empire, and Jedi. This conversation is taking us in ways that don't quite take us there. But the book tries to stay focused because I believe your viewers are more likely to have watched those over and over and remember them.

Yeah.

In. Anyway, in Rogue One, there's a scene. There's a scene where the Death Star designer says the flaw is so subtle that no one could ever find it.

Yeah.

Now, first off, that's a load of hooey because it takes the rebels, like, five minutes to find the flaw, plan an attack, and get the plan briefed to people. So it's not that subtle. But the Empire exists in such a culture of fear and such a political culture that nobody is able to bring this up and say, hey, designer, there's no blowout panels in this thing. Anytime anyone contradicts Darth Vader, he Force chokes them to death. This is not an environment in which people can raise concerns so that they come to an executive. And when we create environments in which these concerns can't be brought up, we may be successful for an extended period because of the brilliance of the leader, their drive, their ability to push people to do things they didn't think they could do. But at some point, it falls apart because it's all dependent on that One person and their force of personality. One of the things about the Rebel alliance is it's lots of people pulling in similar directions, and their leadership is not well structured for a military organization. Let's just go there. And sometimes they do crazy things because somebody is doing something crazy, and everyone follows them into it. But they at least have the benefit of lots of voices, lots of different ideas. And because they're able to act quickly and in synchronized but not lockstep ways, they're also able to win. And I think that the leadership styles that we see have lessons for us. And this is not the book that I've written primarily. Somebody else should write Leadership Lessons from Star Wars. Maybe they have. I'm not sure. I tried to read a lot of Star wars books as I was writing this. It was hard. It was. It. But I. I persevered.

You know, Adam, I know writing a book is extremely hard, and I would not wish this. I mean, I'm not trying to put more work on your plate, but this was such a good book. I would love for you to see. I would love for you to write part two, Star Wars Cyber Security and the Boardroom, as there's just so many lessons there. But I want to ask you another question before we get into that.

Okay.

Throughout my career in cyber stuff, I know there's the importance of raising the defense, of looking for the adversary inside your own networks, of protecting your crown jewels, the most important stuff. But there's this lure of attack. You got to take it to the adversary. You got to be operational. If they're in your network, you attack them there. If they're outside your network, maybe you need law enforcement or the government to attack them, but you got to take the fight to the enemy. And this cyber attack lure is really, at times, gone extreme and pulled resources away from defense in ways that I think our policy shouldn't support. And then I see this addressed in your book. There's dialogue from Star wars that kind of hits on this point. And I think I have it here somewhere. Give me a second. I can pull it up. It was Luke and Yoda talking. And Luke asked Yoda Vader, is the dark side stronger? And Yoda says, no, no. Quicker, easier, more seductive. And Luke says, but how am I to know the good side from the bad? And Yoda says, you will know when you're calm, at peace, passive. A Jedi uses the Force for knowledge and defense, never for attack. And I'm thinking, wow, this is like. It's a cyber security manual. I want our policymakers to read this scene.

I tell you, the riches that I found as I, as I watched the movies with an eye towards which pieces can I use and what you just said, the, the point about seductive, right, that especially in the military, where really there is an, I'm not a vet, I haven't been in the service. But my understanding is that the podcast that we're on here, uda, from Boyd's work, talks about operational tempo and getting inside the enemy's activity loop. And so it's seductive to bring that to cyber and to think that the way we're going to win is to put the enemy on the back foot, to punch them, to make them react to us. And operationally there's value in doing that. But I think it was General Hayden who said cyber is like a soccer game that's 325 to 422. And what he meant by that is it's 100% offense and no defense. Right? And so we can go and pop the enemy's networks and they can come and pop ours, but none of us can keep a secret.

And.

That certainly is seductive. I'm sure that lots of people have been promoted on the basis of their great activities, which were tactically important and strategically. And here I'm going to go beyond the point of the book. If you think about, okay, if you think about the first three movies, everything is shiny and bright and the galaxy is working and then war breaks out and we get the Star wars that we know in which everything is falling apart. It's all taped together, it's all gritty and grimy because 20 years of war has left the galaxy poor. And in cyber, if we're totally focused on these attack oriented activities instead of building defensive systems from the get go, we're just, we're just busting stuff up. We're not operating with the benefit of the systems. We're not operating with the benefit of being able to keep our things secure. And I think that's a shame. And so, and this is a point I, I, I, that's crucial is that cybersecurity, like the Force, has a light side and a dark side. And we need to know about the threats so that we can build defenses. And if we allow ourselves to be seduced by the power of the dark side, we, we just end up hitting each other over and over.

Yeah, Adam, another point. And I was, I was in a session just a few days ago and it was Chatham House rules, so I won't reveal who said this, but it was a government person who's in the DOD who was talking about attacks, cyber attacks. And he said for him, the Solar Winds attack was not an attack. There was nothing destroyed there. It was not an attack. It was an attempt to get an implant in. And definitely spreading that implant to collect espionage. And of course, immediately I'm thinking, well, I guess where you sit decides what you see. Because I imagine the CEO of SolarWinds definitely saw that as an attack. And that company was almost destroyed. It was such a big attack. They recovered. They're doing the best they can in a horrible situation. But if I had to pick a scene from Star wars that fits that, it might be Darth Vader saying that he has altered the deal. Pray he doesn't alter it more, because the deal should be from the government. That the government helps support free enterprise and protects our companies from extremely hostile nations that are attempting to attack them like that. And in that particular case, the individual seemed to not care that much about this major attack on a. An entity.

Wow, there's so much there. But let me start from Star Wars. You're going to learn what I told you was true from a certain point of view. Yeah, but this gets in the metaphors we have that shaped us of espionage and war, of companies being local. You know, back when I was at Microsoft, we had offices in, I think over a hundred countries. And it gets very complicated very quickly when you have a multinational company. What government should be defending it, what governments should be a can. Are allowed to attack it. And this whole idea that companies can be combatants or attacked, like combatants, I think is. It leads to. It leads to suffering. Right. If we're going to say that it's legitimate for the. For one nation's spy agency to bust into these other, you know, to treat companies that are just normal companies as participants in espionage, and they do, right. Spies will do this. They will break your laws. That's why they're spies. Or it's part of being a spy anyway. And how do we restrain that behavior? How do we get to a point where not everyone has to invest in trying to defend against that level of attack? Or do we say every company needs to be ready to defend against foreign espionage?

Yeah, I sure don't know the answer to that, Adam. I tell you, I feel like many of these companies feel like they have to, and I want to give them the advice to do it all on their own and, you know, build a good, smart approach because it looks like the government is not helping them out.

You know, I think there's really and this, this is way outside my area of expertise, by the way. And so I think we quickly get into complicated questions of what is what does it look like for a government to help you out? Is it the government is going to put monitoring devices into your network. Maybe your customers won't like that. Would Right. For example, we're seeing a lot of back and forth over TikTok these days. Should the Chinese government help them defend against American government attacks? It gets incredibly messy very, very quickly when to say the government will help, to say a government will help a company or a government will attack a company. And I think we need to figure these things out and I'm just not sure where all of that brings us. I'm sure there are good lessons from Star wars, but I don't think all the good lessons are in Star Wars.

Very good point. Because Star wars is definitely informed by human nature, but it's not informed by all human nature. Now that said, you wrote a very good book that I really like and I like the analogies and I like the way it makes things memorable. So we'll definitely be recommending that and we'll have a link to that in our show.

Notes. Thank you.

Let me transition to another subject, Adam, and kind of a concluding wrap up discussion. Would love your thoughts on what boards today need to be thinking about regarding cybersecurity. As you may know, publicly traded boards are going to have to comply with new SEC requirements which will probably be published in April, which among other things will tell them that you need to designate somebody on your board who is your cyber lead. And also another requirement is going to be that they identify in their open reporting their approaches to cyber risk mitigation. I generally think these are good things, but I also think that the board is going to need a lot of advice from plain spoken people like you who can inform them on what to do. And so I wanted to ask that what is your thoughts, Adam? What would you recommend for boards when it comes to cyber?

So let me go back to the thing you quoted me as saying. What are we working on? What can go wrong? What are we going to do about it? And did we do a good job? And I think that those questions you can map your company's data flows, right? We market to consumers and so we have a bunch of advertising companies here and they're collecting data and that comes into Salesforce and then Salesforce sends orders to SAP and we build things and we ship them via UPS to the people who have given us money and so let's think about how they gave us money, right? And I think it is reasonable for you as a board member to be able to express that and to be able to think about the question of what can go wrong at each stage and what we're going to do about each of those things. And this recasts us from thinking about security as a matter of compliance to thinking about security as a matter of threats, the negative outcomes we want to avoid. There's one other thing I want to bring into this. When we think about what are we working on at the board level, I think there are two types of code. There's code we deploy and there's code we deliver to other people, right? So we build our business, we build our websites, we build our operations. We inform all of that with software. And even if you're not a software company, you might have an app that you deliver to other people. We have to think about what can go wrong, what are we doing about it as we deploy that code. And I believe, like Marc Andreessen said, that every company is now a software company. And so thinking about it in terms of the code we deploy and the code we deliver, those come from three places. There's the code we incorporate from others, right? Code from Microsoft, code from open source, code from Apple. There's code that we incorporate. We have to think about that. There's code that we write. We have to think about that. And there's the code that we build. We have to think about the pipeline that creates it. And that was how Solar Winds got broken into, or that's what the attackers did when they broke into Solar Winds, excuse me, is they went to the build pipeline where the code that Solar Winds delivered to other people was modified. And so if we're thinking about this in terms of code we deploy and code we deliver, SolarWinds could have been thinking about how do we protect the code we deliver better. Everyone else could have been thinking about it in terms of how do we protect ourselves from the code we deploy better. And I think that that framework, which frankly, is a little bit different than what you might hear from others, is something that a board member can think about. You can ask about code we deploy and code we deliver. And you can ask, what is that? What are we working on? You can ask, what can go wrong? You can ask, what are we going to do about it? And all of the things that you've been thinking about and hearing about in terms of, like, the NIST cybersecurity framework, which is a great framework, but it is almost 100% focused on the code we deploy. It's focused on our operational networks, it's focused on our enterprise networks. And all of the stuff that you do because of NIST CSF are answers to the question of what are we going to do about these things? Right? How do we identify what we've got? How do we protect it? How do we detect problems? All of that stuff is in this. And you know, don't usually do this, but I'm going to quote another General Eisenhower said, you can solve a problem by making it bigger. And I think that if we make the problem bigger than just Ms. CSF, it actually simplifies it because it lets us put, put that into the, into the bucket of what are we doing about these problems? And then we can say, well, which problems are we really focused on? Ah, and what are we working on? We can ask what can go wrong with each of those things. And when we start to do that, even though we've expanded the scope of the problem, we simplify it because we can organize our thinking in a better way than we can if we just jump in. In what sometimes seems a little bit like the weeds that we get into in cyber security.

Yeah. Adam, I think when I listen to you and read you write about things like what are we working on at the board level? I see that as being a very scalable question too, and an important one because to me that's far more than just the technology. It's the what are we working on? Why does this corporation exist? What's our business? What are we planning on doing in the market over the next decade? What are we working on? Those big scalable thoughts. And that's the reason I like your. A very simple expression of this question.

You know, one of. Yeah, so one of the things, and we've talked about this, these new AI driven conversational systems like chat GPT. One of the things that I think every board is asking itself is what does this thing mean to us? Right? Does this change our business in a meaningful way? And we can ask what can go wrong? It can give dumb answers, it can give embarrassing answers. What are we going to do about it? We should think about how we control for those business level problems as we're doing this new thing. And we should ask the people responsible, not just in security, but the people in production. Okay, what are you doing? We're, we're planning this AI pilot what can go wrong? And if they don't have a good list of what can go wrong, that's convincing to you as a board member. I. I hate to say it, but your job as a board member is governance. And if you're not getting good answers to that question, what's your governance answer?

Yeah. Yeah, that's. You're right. You got to keep driving at that or maybe shut it down.

And. And that's something. It. This doesn't require intense, different knowledge. It requires some thoughtfulness, and it requires. We can go back to Star wars for just a moment, a little bit of Search your feelings. You will know the difference between the good light, the good side of the Force, and the dark side of the Force. Make sure you stay on the good side.

This is fascinating. It's great talking with you. And you also make me think of Socrates, the the founder of Western philosophy who dealt with questions like this. For him, it was who guards the guardians, who protects the protectors? And the answer in the dialogues of Socrates, as, if I understand correctly, was just like this dialogue with Yoda is, well, you trust your feelings, and Socrates talked about working on your soul and making sure it's good people who are guarding us. But it's very much like Star Wars.

There's. There's a whole book there.

Well, Adam, thanks for the time today. This was extremely helpful and great context, and I really appreciate it.

You're welcome. This was loads of fun. Really. It was different than I expected, but I love where we went. We should totally do it again.

Awesome. Let's do it. Thanks for listening to this. Ooda Loop Production for the latest analysis on cybersecurity technology and global risks, please visit www.ooda loop.com.