First principle strategies with CJ Moses.
Rick Howard: For most of you, you probably didn't notice anything out of the ordinary for this season of "CSO Perspectives." But for the astute listeners out there, you may have noticed a slight break this season between Episode 2, and this episode, Episode 3. Guilty. You caught me. But it's for a good reason. You all know that we published my book, Cybersecurity First Principals, A Reboot of Strategy and Tactics, this past spring. You can get a Kindle version or a hardback version at amazon.com. A link is in the show notes. And the audiobook should be published any week now. But since publication, I've been getting asked to talk about the book at various venues. I spoke at the Google sales engineering conference. I keynoted the Denver Rocky Mountain Information Assurance conference. And I hosted a security vendor dinner with about ten CISOs talking about first principal strategies. But the best part was because the CyberWire is an Amazon Web Services media partner, AWS leadership asked Jen Eiben, the CyberWire's Senior Producer, and me. To come out to the magical world of Disneyland in Anaheim, California to attend their AWS re:Inforce conference, essentially, their standalone security conference. Jen, a rabid Disney fan, by the way, guided me for one evening of Disneyland adventure riding the relatively new, for me, anyway, Stars Wars attractions. And the older Pirates of the Caribbean, Haunted Mansion, and the Jungle Cruise. And generally, having a blast. We also got to sit down with CJ Moses, the Chief Information Security Officer, at AWS. But because of all that, I've been a little late in getting the next episode of "CSO Perspectives" out the door. But, hold on to your buts.
Unidentified Person: Hold on to your buts, buts, buts, buts.
Rick Howard: We're about to get caught up.
Rick Howard: My name is Rick Howard and I'm broadcasting from the N2K Cyber Secret Sanctum Sanctorum Studios located under water somewhere along the Patapsco River. Near Baltimore Harbor, Maryland, in the good ole US of A. And you're listening to "CSO Perspectives," my podcast about the ideas, strategies, and technologies that senior security executives wrestle with on a daily basis.
CJ Moses: CJ Moses. I am the AWS Chief Information Security Officer, or CISO, as many people refer to it. And I've been with AWS 15 1/2 years now.
Rick Howard: CJ got his start in the US Air Force back in the late-1990s working for the Office of Special Investigations as a computer crime investigator chasing hackers around the world. Back when the Internet was still the Wild, Wild West. He had a stint working for the FBI and the Air Force as the interagency coordination sale chief deconflicting cyber law enforcement and counter intelligence investigations. And then he moved over to Miter [assumed spelling] for a couple of years providing case support for the FBI. And then joined the FBI proper for four years running the 450-person team of technical investigative analysts. In 2010, he joined Amazon and worked his way up the ladder and became the AWS CISO two years ago. By the way, if AWS was its own company and not owned by Amazon, it would be a Fortune 500 company in its own right with $58.7 billion in revenue in 2022. Slightly below Morgan Stanley and slightly above Tesla. So CJ has a huge job. And, of course, he spends a lot of time thinking about strategy and tactics.
CJ Moses: So the number one thing that I've conveyed to the team is to be strategically patient and tactically impatient for those things that we know we must need to do and we know the path. And especially if they are two-way door decisions, meaning that you can easily revert them without major cause or issues.
Rick Howard: You mean you can back out of it if you- if something catches fire.
CJ Moses: Can back out of it and try again a different way.
Rick Howard: Yeah, yeah. Yeah.
CJ Moses: In those circumstances, the- given the speed of the Internet and the speed of the adversaries, it's time to go. Once you have that, you have enough to move out. And from a tactical perspective, that's how we think and how we work. The strategically patient means that you may be facing a one-way door decision meaning that you're- if you make the decision, the ship has sailed. It's either exceptionally hard to revert or impossible. So in those circumstances, we spend a little bit more time. We make sure that we're thinking long term and, you know, focusing on what is best for the customers. Working back from them in order to derive that and make sure that we have all the diverse perspectives that we can have in order to get to the right decision. We have lots of strategic planning, as you might imagine. Operational planning is done many times a year because strategic planning in a fast-moving environment, you can do, you know, one, three, five-year plans. We have all of the above. The reality is is that a one-year plan turns into you have to revalidate within six months because things are changing so quickly. Some of the discussions on generative AI is a good- are a good example. Out of nowhere, in six months, it became like one of the biggest, hottest things that everybody's talking about. Whereas in, you know, go a few months earlier and you might have talking about AI but it's not gen AI, specifically. And so that may change a bit of the vectoring. So you have a combination of tactical and strategic tied into one because 90% of the things that we do come directly from customers. The other 10% are us still coming from the customer but we need to be playing chess. We can't play checkers and just give the customers what they want. We actually have to be thinking far in advance of what they really- what they're going to need. And that's a lot of the work that we've been doing in more traditional AI. And I look at gen AI as essentially the large language model that allows easier access or democratized access to AI. Because you can do the same things with "regular AI," and I air quote that, you know, for all the listeners. They can see that, of course.
Rick Howard: Sure, yeah, 'cause, you know, audio really helps that out.
CJ Moses: Audio lets us- lets you see the vision. But they- but, you know, from the- from that perspective, you have to, I mean, large language models just make easier access democratizing that access to AI. In our case, obviously, Amazon's a very technical company. We have lots of software development engineers [inaudible] everywhere. So the focus hadn't been towards large language models, per se. And actually, if you look at most of the tech companies, I mean, that wasn't the focus in a lot of the cases and where it really started to get its roots was in a startup that went all in.
Rick Howard: Right.
CJ Moses: And God bless them. It's working out, right?
Rick Howard: Well, I mean, but large language models are- it's a technology, right? It's not a strategy, right?
CJ Moses: Oh, no, yeah. I took a left turn on you there.
Rick Howard: Yeah, yeah, thank you, yeah. So, you know, you and I have both been doing this for a long time, right? There's a number of strategies that we could deploy. And what I mean by strategy and just so our listeners know what we're talking about, these are what we want to do, not how we're gonna do it. These are big ideas about how we want to get there. And there's been a number of strategies that we could choose.
CJ Moses: Mm-hmm, mm-hmm.
Rick Howard: And some organizations choose one, maybe two, but, you know, AWS is big. You could probably be able to do a bunch of different strategies.
CJ Moses: So we have a lot of different strategies but we route or we essentially have a lot of our security model based in our culture. You know, I'm not sure how much the listeners understand our culture, so I'll explain it.
Rick Howard: Yeah, please.
CJ Moses: And essentially, you know, telling a little bit of a story, I'm a bit of a storyteller. When I started at Amazon, one of the things that was clear is that they had a very strong ownership culture, meaning that you own- builders owned, and they built, and off they went. There wasn't a, you know, a hang out and wait for approvals. Military days and my background in the government, it was kind of weird to, you know, bias for action was one of the core leadership principles at Amazon. In the military, if they didn't tell you you needed to do it or you should be doing it and didn't need approval to do it, it's a little different environment. And I learned early on that we really needed to take the initiative and go do the thing. So thus my little quip about tactical invasion. That was a lesson learned. So going back to the ownership culture is that that essentially comes down to how does that play to security is a single-threaded leader, owners in the company, in general. Own the success and failure of the profit and loss and the security of their business. Meaning that we're talking about say EC2, the leader of EC2 owns the security of EC2.
Rick Howard: But does it mean like the business leader of EC2 has a- might have a different strategy to protect his business versus --
CJ Moses: So he'll have a micro strategy that is part of our larger strategy that we put forth.
Rick Howard: Mm-hmm.
CJ Moses: We establish, and this is part of the strategic- kind of getting to your question, have these multiyear security expectations. And we set forth the goals, essentially, and these expectations will be around access control, vulnerability management, police privileging, kind of go down the normal list. And actually, if you look at how we've prioritized them, they're pretty close to if you look at where the big challenges in security have been over the last few years. Making sure that we're actually paying attention to the things that are most likely to cause us pain. And those security expectations are then, you know, implemented by each individual team. We set the bar. We audit against that bar. We create tools and pathways, services, in many cases, to make the path to security the easiest path. That's where we actually see the biggest adoption and the ability to meet those requirements. Is when we're able to deploy actual internal services that are, you know, natively patching as part of the CICD pipeline or, you know, things of that nature. Rather than saying- sending a ticket and saying, oh, thou shalt patch. For us, an organization as large as ours can take a long time to [inaudible].
Rick Howard: I'm sure.
CJ Moses: And that's where, you know, thinking a little bit differently. So --
Rick Howard: But I would look at, you know, the things you listed there, vulnerability management and the other things, those are tactics, right, to accomplish some goal. So what's the goal? I'm trying to get you to tell me what the AWS strategy is.
CJ Moses: I want to tell you my strategy.
Rick Howard: I know. I was- I'm getting this. It's coming through clearly. Yeah, no.
CJ Moses: No, it's really one of those things that we actually, you know, the goal in vulnerability management, very clearly, patch it all within the SLA's established. SLA's are different based upon the severity of the risk and it's all risk-based analysis and that. We also have to make sure that we're meeting industry compliance requirements. And in our case, 143 different data stations, regulatory requirements, and all of the above. And that means that we have to align to those, as well as anything that, you know, from our own risk perspective. Traditionally what we'll do, and this has just come out of our, you know, kind of being paranoid, and it's not really being paranoid if they're out to get you, and we know they are.
Rick Howard: Which they are.
CJ Moses: Which they are, we know.
Rick Howard: We know, yeah.
CJ Moses: So we traditionally take the high bar and that is whatever the shortest period of time for in the case of that. So as part of our major strategy, some of the things that we focused on is, you know, obviously our number one goal is to make sure that we keep our customers data safe. Or our customers, you know, secure is probably a better term than safe, even. And our best way to do that and the things that we've annually started off our annual planning with is that we need to continue the investment in our ability to scale. And that scaling is done through various types of automation. Automation, although is not a strategic thing. It's a means by which to meet our strategic goals. We've laid those strategic goals out and those expectations as part of the pre-work to all of the planning across the totality of Amazon.
Rick Howard: I would definitely say automation is a strategy, the what we want to do to help with this, right?
CJ Moses: Mm-hmm.
Rick Howard: And then there's some tactics we can do to, you know, integrating in the CICD pipeline and automating a bunch of stuff. I totally agree with that.
CJ Moses: Mm-hmm. And our best way to do that and the things that we've annually started off our annual planning with is that we need to continue the investment in our ability to scale. And that scaling is done through various types of automation.
Rick Howard: What you guys- it's a unique thing to you as opposed to my little startup that I'm working at, right?
CJ Moses: Mm-hmm.
Rick Howard: That when we talk about scale, it's a completely different thing than when you talk about scale, yeah.
CJ Moses: Yeah, and that's why I kind of started off with the whole ownership thing because ownership is a means for by which for us to scale. Because if I have to create a security team that's directly embedded. And we do have means to do that and we talk about that later. But that are, you know, responsible for the security of each and every service and every last detail, my team is going to be many more thousands than it already is. And that's not a good use of resources when you can actually have people that are trained in security and have the tooling and the capabilities built in to the IDE, the CIDC pipelines that they're already using. This is much more efficient, and, oh, yeah, by the way. When you find something in that process that has created a vulnerability or is, you know, caught in the software, we can immediately look back to where it was created. And then fix that class of error, not just the one, fix the class of error going forward for the entire- not only that pipeline, but our entire environment. And this is where, you know, you don't, you know, bad enough if you whack yourself in the foot one time. And if you keep doing it, it's not, you know, not a good look and it's kind of stupid.
Rick Howard: In my book, I devote an entire chapter to automation as a key and essential strategy to cybersecurity first principles thinking. But I mainly considered it as a means to approach consistency and agility. I never considered scale. CJ is absolutely right, though. As your organization continues to grow in terms of infrastructure and services offered, at some point, it doesn't make any sense to keep throwing more people at the problem to maintain it. I had an old boss of mine tell me that one metric he was using to evaluate my performance was the dynamic nature of my team size over time. He said that if I was growing my team for each new company initiative, I was going the wrong way. He advised me to automate the mundane tasks that were causing me that technical debt. To CJ's point, automation isn't only a means to consistency and agility, it's a prime driver for scale. He also offered some insights about another strategy I cover in the First Principle book, resilience. I defined it as the ability to continuously deliver the intended outcome despite adverse cyber events. If that's true, I said that the tactics you might employ to achieve the resilient strategy orbited around crisis handling, backups and restores, encryption, and incident response. But CJ offered some nuance about backups that I hadn't considered before. He says there is a difference between availability and durability.
CJ Moses: You can look at resilience from different dimensions. You know, obviously your traditional availability type of thing, but then you also have a durability. And quite honestly, if you're prioritizing, you want to prioritize durability. Because if I'm down for two minutes but yet I still have your data and it's available when it comes back on, you're accepting that sometimes things happen.
Rick Howard: Yeah.
CJ Moses: And we'll- there's a whole process we go through to make sure it doesn't happen, again. But the inverse is not the case. If we lose your data or somehow there's an issue from a durability perspective, then that's not a good day for either of us and you're really not happy with us.
Rick Howard: Right.
CJ Moses: So there's prioritization placed on durability over availability, but at the same time, both are exceptionally high bars. And from a resiliency perspective, we have planning that we have to do with each of the teams, the different services, because the models for each are different.
Rick Howard: I'm not sure I get the difference between durability and availability. Tell me- walk me through that, again.
CJ Moses: So, yes, very specifically, availability is if you have a piece of data stored in S3, our simple storage service, and you request access to it, and it's available, you then get it. If it's- if there's an availability issue, you don't get it.
Rick Howard: Okay.
CJ Moses: Durability is if you ask for that piece of data and I come back with a fault saying I don't have it. It's no longer durable. I no longer have the data, and therefore, we have a problem.
Rick Howard: And can't get it.
CJ Moses: Yes. And the durability model, you know, S3 was created on a durability model of, you know, of nine nines. It's like lots of nines. So it's essentially we'll lose one piece of the data every gazillion years or something in that nature. I'm not good at math, so don't quote me on that.
Rick Howard: Wait, let me write that down.
CJ Moses: Yeah, right. It's all in the documentation. Feel free to read the website. I used to actually know all that stuff, but my brain's been filled with other things these days.
Rick Howard: Yeah.
CJ Moses: But so there is a huge difference between availability and durability. At the same time, customers really demand and should be given both, and that's when you tie those things together, resilience is a big part of that. The benefit of the cloud is that we are highly resilient, that we can stay up in the face of all kinds of threats. Can we always do so? No. At large scale, things will fail.
Rick Howard: Sometimes fail.
CJ Moses: And we have a plan and we've seen those things happen, you know, recent days included. And although things happen, one of the things you have to do is make sure- I know we're far away from strategy, so we'll someday get back to that, but yeah.
Rick Howard: No, no. Resiliency is a strategy.
CJ Moses: Okay, yeah.
Rick Howard: So I'm fine with that, okay.
CJ Moses: No, but so one of the things that you have to make sure is is that you'll learn a lot more in failure than you ever will in success. And every time we have any kind of issue, we are very diligent in reviewing that to ensure that we've done the right things and are continuing to do the right things. You've likely heard of this before, correction of error, COE?
Rick Howard: Yes. Mm-hmm.
CJ Moses: And a, you know, essentially a root cause analysis with on top of that root cause analysis, what are the action items that you are definitively taking with named actors. And due dates for doing those things, and we track them to make sure that they are done such that, again, don't want to, you know, ball peen hammer your toe a- or your thumb, whatever, a second time. So I'm looking at those things.
Rick Howard: So I'm putting my customer hat on, right, watching how Amazon handles a major outage, I would like to have the same capability on my little startup, right? When I do something stupid and it breaks, I would like to have a push button. The- it just starts over there now, right, and I can continue delivering my service, right?
CJ Moses: Well, the capability exists for you to be able to do so.
Rick Howard: Yeah, it's a little bit hard right now.
CJ Moses: So I totally get where you're going and that's the thing is is that we're not there yet for all the things.
Rick Howard: Yeah, I get it.
CJ Moses: But 15 1/2 years ago, when I started, you have to take into account, you know, I'll give you some history, back in the day type of stuff. I'm feeling older by the second.
Rick Howard: Oh, yeah, more stories.
CJ Moses: When I started, AWS was five services, one region. The security model was a user ID and password that you used to buy books with, same one.
Rick Howard: Is that right?
CJ Moses: There were no multi-accounts.
Rick Howard: Is that right?
CJ Moses: There was no nothing. Your whole account, you're running your business, although it might have been out of Starbucks off your laptop, that's what it was. So we've come a long way. We still have a ways to go and some of the things that essentially in the military, we used to call it the football. Press the button. We had a whole new disaster recovery environment. This is something that has been created. We do have lots of companies use very similar things. You know, infrastructure as a code is a wonderful thing. The days of, you know, back in the day when I was at the FBI, or actually, when I was at OSI, we didn't call them advanced persistent threats 'cause that didn't even exist, yet. But that's what we were dealing with. And if you had one of those get into a network that you're somehow responsible for, you had a hard time getting them out. In some cases, you had to shut everything down and start from scratch elsewhere. In the physical world, that's a nightmare. That's expensive. You're down for a long time. In the cloud, just like you just said, you're a startup.
Rick Howard: Flip the switch.
CJ Moses: Press a button. Boom, you've got another and it's maybe in another region elsewhere or maybe that's the reason you're doing it is 'cause of survivability, or as we were talking about earlier, you know, resilience. But the- that model is very doable and understanding that we don't have the service that says, okay, you've established your whole environment where you're just gonna- well, we do have the tools to do it. But a service to do it on your behalf, the cookie-cutter copy.
Rick Howard: Yeah, we looked at the tools. Yes, I would, yeah, just make it a little bit easier. That's all I'm asking you.
Again, from my Cybersecurity First Principle book, the two main prevention strategies that I recommend are the passive zero trust strategy and the more aggressive intrusion kill chain strategy. For zero trust, CJ addressed his priorities when he gave the conference keynote in terms of least privilege and vulnerability management, or VM, as he refers to it here. And he flips the zero trust mantra from trust but verify to verify then trust. And for intrusion kill chain, he talks in terms of mean time to defense and is moving AWS in that general direction.
CJ Moses: It's literally down to, you know, this is our goal towards least privilege, you know. And the thing is is that given the different nature of the different businesses that we're in and the alignment due to state, you know, there are some absolute ones.
Rick Howard: Sure.
CJ Moses: VM we have percentages and it's essentially 100% is really what it boils down to. Knowing that, that's aspirational, because trying to maintain patching across millions of systems without aberrations that drop you off with 100% is, you know, it truly is aspirational. But at the same time, keeping within SLA over that period of time, for the most part, we can attain roughly, you know, obviously there's aberrations to everything like that. But we establish that in, you know, those expectations are actually part of our annual planning and subsequently into our three-year plan as to how we're looking in the out years. And we've established this, you know, the model, if you will, to strategically meet our, you know, our demands or our customers' demands by looking at the various different parts of security. And making sure that we're meeting each of those expectations. When I say we, I'm talking the totality of all of the service teams in aggregate.
Rick Howard: So let's go back to your FBI days, right, and talk about a third strategy that we might look at, right?
CJ Moses: Yeah.
Rick Howard: You used to track down bad guys in cyberspace all the time.
CJ Moses: Just a few.
Rick Howard: Right, and I'm a huge fan of the intrusion kill chain and we know that- we know what most of the adversaries do as an attack sequence.
CJ Moses: Yeah.
Rick Howard: Right? But so that's a strategy you could employ, right? Meaning I'd like to do- to deploy to my security stack, your security stack, everything we know about let's say, you know, Wicked Panda, okay? And be able to tell me that I know that we saw one of the things that Wicked Panda does out of 100, let's say, okay? So maybe it's not Wicked Panda. But if we saw 80 of the 100, you got Wicked Panda in your environment, right? And I don't see organizations doing that and is that something that AWS looks at as a thing that we should be pursuing?
CJ Moses: So absolutely. Security of the cloud, we do tons of that, so that is, you know, coming from that background, you know, my whole keynote, or the beginning part of the keynote. Was all about understanding who the adversaries are and knowing as much as you can about them such that you can protect the rest of the environment. So without a doubt, we're doing it there. I think we have most of the pieces and, quite honestly, if you ask me what's the one thing if you're a new CISO that's gonna be sitting in and you're looking at your environment. Don't know if your AWS environment is secure or otherwise, it's like click on GuardDuty and do it quick. It's going to be the thing that's going to give you that information because it's integrated with a lot of the threat intelligence, not only ours but the likes of other partners, CrowdStrike and the like. So that we're learning about the Wicked Pandas from them, as well as we're adding to that corpus of intelligence from our own environment and pulling that. And that was the mean time to defense that I focus on.
Rick Howard: Right.
CJ Moses: And I push the teams on and we really need that kind of a metric because we're a very distributed environ- or distributed teams. And we need to be able to make sure that if my team finds something on a, you know, security of the cloud space where we're doing security incident response related things. That that information is as quickly as possible getting to the external security enterprise security services that we're offering for customers. Even more so, it's getting to the core services. There's a lot of things that can be done in the S3 EC2s and otherwise to make sure that they're, you know, buttressed in certain circumstances. So that- that's been a, you know, it's a weird metric. People are like what do you mean? Like how many times have I been asked, "You must see all the stuff on the Internet. You can see the weather of the Internet." I was like, absolutely. And, you know, everybody wants to sign up for the midnight phone call.
Rick Howard: Yeah.
CJ Moses: And I've done the midnight, or the 2:00 AM, or the 3:00 AM phone call for lots of companies, but just like anything else, you want to automate that as much as you can.
Rick Howard: Well, it's my experience, though, that people like us, our peers, right? We tend to focus on the technical things. We want to stop the malware. We want to stop the- anything technical happening, whatever that is.
CJ Moses: Mm-hmm. Yeah, yeah.
Rick Howard: But my view on this is that that's not the goal of this, right? That's one of the things we do but what we really want to do is stop the adversary, right? And so if the adversary does 100 things across the intrusion kill chain and you stop 90 of them because of- and you know that you. Even if they come up with something new, you're protected, right?
CJ Moses: Yeah, and that's, I mean, on the kill chain side of the thing is that we're, like you said, you don't have to stop all the things. Because once you have essentially the details and if you get in the way anywhere along the line. And we have many- that's the nice thing about the cloud, in general, is we have so many- matter of fact, to some extent, the granularity of the ability of do access control. And [inaudible] access management is to the point where sometimes people are complaining that it's too granular now. I was like I couldn't believe I ever heard that, because back in the day, that would be like heresy.
Rick Howard: What are you saying, yeah.
CJ Moses: Yeah, but honestly, it gets down to the point that some of the things that we released are essentially trying to make it a bit easier for people to understand. You know, to get to a zero trust model or a getting away from a, you know, trust or trust but verify to a verify then trust model. And that's really what we're really focused on.
Rick Howard: I like that you said that in the keynote. That's a really good way to express that, right, so.
CJ Moses: It's, you know, I think like 2010 when I was in Amazon writing a, you know, a presentation, and I used, you know, trust but verify. And within a few years, it dawned on me. I was like we don't want to trust anybody until we already verified because we're security people. We're not very trusting people by nature and we should flip that around. And zero trust, or what is now known as zero trust, a lot of these names and stuff like that didn't exist back in the day. But the model of making sure that you're not trusting the network authentication. Or the fact that someone has been able to get on to a network to be the security barrier that's keeping them from accessing things.
Rick Howard: So we're at the of this, CJ. What's the Twitter line for the conference, right? What are- what's the takeaway that we should have here?
CJ Moses: Any chance we get, we need to make the most secure methods be path of least resistance. Humans by nature are lazy. I'm lazy.
Rick Howard: I'm lazy.
CJ Moses: Or, yeah, it's just the nature of humans and if you make the more secure path, path of least resistance, we'll all be better off for it.
Rick Howard: That's a fantastic way to end this conversation. I appreciate it, CJ. That's some really good stuff. Thank you very much.
CJ Moses: Oh, absolutely. I appreciate it. I look forward to trying to come back and we can talk some more.
Rick Howard: Excellent, man. Thank you, sir.
CJ Moses: Oh, thank you.
Rick Howard: And that's a wrap. I'd like to thank CJ Moses, the AWS CISO, for coming on the show and sharing his experience with us, and all the AWS team that helped make that happen. And don't forget, you can buy copies of my new book, Cybersecurity First Principles, A Reboot of Strategy and Tactics. Order it now at Amazon or wherever you buy your books. Also, we'd love to know what you think of this podcast. Send e-mail to cyberwire@n2k.com. Your feedback helps us ensure we're delivering the information and insights that help keep you a step ahead in the rapidly-changing world of cybersecurity. We're privileged that N2K and podcasts like "CSO Perspectives" are part of the daily intelligence routine of many of the most influential leaders and operators in the public and private sector. As well as the critical security teams supporting the Fortune 500 and many of the world's preeminent intelligence and law enforcement agencies. N2K strategic workforce intelligence optimizes the value of your biggest investment, people. We make you smarter about your team while making your team smarter. Learn more at n2k.com. N2K Cyber's "CSO Perspectives" is edited by John Petrik and executive produced by Peter Kilpe. Our producers are Liz Irvin and Senior Producer, and, by the way, Disneyland guide, Jennifer Eiben. Our theme song is by Blue Dot Sessions, remixed by the insanely talented Elliott Peltzman, who also does the show's mixing, sound design, and original score. And I'm Rick Howard. Thanks for listening.