Behind the Book: Threat-Driven Software Development

Sherrod DeGrippo: Welcome back to the "Microsoft Threat Intelligence Podcast." Today's episode is a little unusual because, instead of just like interviewing a guest, I am joined by my fellow coauthors, Michael Howard, Lee Holmes, and Shawn Hernan to talk about our new book, "Threat Driven Software Development: Defending Online Services for Modern Threat Actors." What's unique about the book is that it brings together four different perspectives. So, Michael Howard helped define secure software development at Microsoft. Lee Holmes helped build and secure some of the platforms and tools millions of people use every day. Shawn Hernan has spent years helping organizations think about risk, vulnerabilities and threat modeling. And then there's me. I don't build software. I study the people that try to break it. And we have a conversation in the book about threat actors, bringing that perspective into the conversation, and talk about how attackers actually think about software systems, identities and operations. And that's really what the book is about. So, welcome to the podcast, guys.

Michael Howard: Thank you very much.

Lee Holmes: You've got a good team.

Shawn Hernan: Morning, Sherrod.

Sherrod DeGrippo: I'll tell a quick story before I start interrogating you with questions. I'm very good friends with Andrew Morris from GreyNoise. We've been friends for many years. We're really close. I often tell people that we're basically the same person, which is horrifying to all of them if they know him. And I was really excited that the book came out. As you guys know, this has been quite the journey for all of us. It's been tough.

Lee Holmes: Yes.

Sherrod DeGrippo: And when it came out for pre order, I sent it to Andrew Morris. I was so proud of myself. And I said, "Look what is available for pre-order." And I expected the first thing he said to me to be, "Congratulations. That's so cool. You know, that's -- great accomplishment." The first thing he said to me was, "Oh, my God, you know Lee Holmes?" And I was like, "Yes, I do. He's my coworker at work. What do you mean?" And that has happened a few times now that I've sent it to people, and they don't -- they're not excited for me. They're asking me that I know Lee Holmes. And I'm like, "Yes." And they're like, "You know who he is, right?" And I'm like, "Well, yes. Like, he's my coworker at work, the PowerShell guy." And they're really impressed. So, I also get asked about Mark Russinovich a lot. And I'm like, "Yes, he's in the meeting -- he's in meetings a lot at work with us, doing work here." These aren't just mythical figures. These are people that do work every day at our jobs. So, let's talk about kind of why we had to have this book. Michael, I'll start with you, because you were like, the captain of the Motley Crue of us, I feel. You were really the experienced like taskmaster. What -- what happened? How did this happen? I don't even -- I don't actually know.

Michael Howard: Yes, it's actually a very simple story, actually. So, I was having a conversation with John Lambert. Not sure what his title is this week. But it's -- you know, I mean he's a security fellow.

Sherrod DeGrippo: Security fellow.

Michael Howard: DC SO, CTO, I think. Am I right in all those things?

Sherrod DeGrippo: Yes.

Shawn Hernan: I think that's all right.

Michael Howard: That's all right. I think him and Russinovich are vying for the longest title. But that's a discussion for another day. So, anyway, a discussion one day with John. And he said, "Michael," he said, you know, "remember all the SDL stuff, you know, we worked on back in the day? Security development, lifecycle stuff?" I'm like, "Yes, yes, yes." He said, "You know, we really need to think of it through the lens of -- of threats, not just doing the right things for the sake of doing the right things." He said, "We need to do the right things, prioritized through the angle or through the lens, I should say, of threat actors. Like what are threat actors actually doing? And how can we look at what we need to do from a security perspective, both design and coding and libraries and tooling and AI and the whole, you know, the whole nine yards, to streamline what we do by focusing on what threat actors actually do." And I'm like, "Yes, that's a good idea. It's almost it's, you know, like threat driven software development. Right?" And he's like, "Yes, that's a great idea. Oh, great." I said, You know, that's a great name for a book?" And John said, "Yes." And he said, "And you're the guy to help drive that book." You know, this is book number ten for me. So -- so yes, that's -- that's literally how it started. It was a conversation one day in John's office. I was just literally walking past his office one day, and I said, "Hey, John, how's it going?" And, yes, that's how it all -- that's how it all started. And then I thought, "Okay, so, you know, who would be involved in this, in a book like this?" And obviously, Sherrod, you came to mind because it had threatened, you know, threat intel and threat driven in its -- in its title. So, you know, who else would I choose? And then I thought, "Okay, so, and then who else could we use for other technical coauthors who have been around the traps?" So, I'm like, "Oh, you know," So, Shawn Hernan. So, Shawn and I have known each other for a long, long, long time. And -- and then Lee Holmes. So, Lee and I worked on, back in the day, and this is really showing how old we are. Lee and I worked on PowerShell back then. I was the SDL contact for PowerShell when it was still Monad. And Lee was the security guy. And, you know, Shawn and I again, have worked, you know, for a long time over the years on various products, including the SDL. Yes, so that's kind of how it all came to fruition. You know, I could keep going. There's lots more to it, but that's essentially the -- the -- the core of the start of the story.

Sherrod DeGrippo: I remember at the end of last year, I saw John at an offsite and I was like, yes, we're -- it was like the happy hour before the offsite. And I was like, "Yes, we're -- we're going to do that book. We've been working on it." And he's like, "What? You're doing that? You're actually doing that?" And I was like, "Yes, that wasn't just like a random fantasy idea. It's actually happening." And then, so immediately he started talking and I -- he's like, "Well, you got to talk about this. You have to talk about this. Software developers, can't tell him what to do. You can't tell software -- software developers what to do. You have to give them the problem and let them figure out what to do." And he's talking at me so fast and he's kind of going back and forth and like, "This, this, this." I literally pulled my phone out and hit the voice note button and was like, "Talk into my phone, John. Just -- just talk right into my phone." And I took what he said, and I put a lot of it in the book. So, let me ask, like Lee, you've done these books before. You've done a lot of them before. What was different about writing this? Like, how was your approach different?

Lee Holmes: Well, you know, the -- the thing that I really loved about this book is that it was just the coming together of so many unique skills. You know, the story about Andrew was funny, but like there's just so many different like perspectives that made this book good. You know, the -- before I had you know, done a couple iterations on the PowerShell Cookbook, and it was very much a, you know, one person's perspective, one person's insight and -- and what comes out is -- is just all of that. But you know, getting to have the four of us together, coming with our different experiences, like this has been the kind of book that -- that we've needed to put out for so long. You know, there's so much of the stuff out there in the industry is about like, how to attack stuff and how to break stuff. And I think those are really, really important skills to have as defenders to be able to understand like, what are the attacks that you're going against. But then we tend to leave it up to everybody individually to figure out the right way. Like, but how do you actually address this stuff at scale in a way that folks have like thought through deeply and -- and been able to actually execute on? You know, Sherrod, your perspective on all of this of like -- like every day, you're thinking about how the threat actors are working and -- and understanding their -- their work styles, what they focus on, what they don't. It's really easy to create a book that is just a bunch of what to do like you're talking about with -- with John's quote, right? But like to have you bring this insight of like high, high skill in that perspective. And frankly, it's the most interesting stuff in the book to read because it gives all the background behind everything else. And -- and so, having the four of us work together was just, you know, just really a pleasure.

Sherrod DeGrippo: It was definitely a fun time. And it was my first book. I'd never written a book before, so it was new for me. Shawn, you focus a lot on threat modeling, and you know a lot about that really deeply. Where did that come up in the book for you?

Shawn Hernan: Oh, well, I think a lot about the book. I think of the -- I think of the book as really people-centered. One of the early conversations we had, when we're laying out the chapters, was "Well, we need a book -- we need a chapter that or a section of the book that talks about security really is more than one team." And my favorite saying about threat modeling is that my threat model is not your threat model. It is -- security is one of the most -- security is one of the disciplines that demands the widest diversity and inclusion you can think of precisely for that reason. And that's really echoing what Lee said, is that all of these different perspectives coming together from different points of view, from different experience levels, I certainly learned a lot. Like you shared, I'm a first-time author. I learned a lot about how hard it is to write a book.

Sherrod DeGrippo: It's so hard. Oh gosh.

Shawn Hernan: I also learned details about perspectives that I had underappreciated before from reading and reviewing the book. And I hope what the book really captures from a threat modeling perspective or from a design perspective is really that you need to think about how is this software going to be attacked from the beginning, and your perspective really motivates a lot of that. The -- the underlying supported technical content gives people a path forward. But John's original idea of focusing this on what the attackers actually do and how they're motivated and how they work, I think it came together really well in this book and I'm really proud of the result, and proud of my association with the three of you.

Lee Holmes: One of the things I -- I think you point out, which is great about the threat modeling for example, and like just updating the book to talk about kind of modern design and -- and modern threat analysis is that there's a lot of the stuff that's come from kind of when Microsoft kicked all this stuff off in like the early 2000s where, you know, you started to get, you know, we made a huge, huge effort in the secure development life cycle and, you know, a lot of stuff came out of that and a lot of really excellent experts at Microsoft went out into the industry and described what we used to think of as threat modeling back in those days. And you've got a lot of folks who have been, you know, consultants that have, like really been driving like that kind of unique perspective on threat modeling that didn't previously exist. And I think as we've been now doing this over another 23 years, it's definitely adapted, right? It's become, threat modeling as a perspective and an approach, has become a lot more conversational. It's become a lot more open-ended. You know, I think the early frameworks around stride and stuff like that were really extremely rigorous and they -- they fell into this certain kind of brain trap of really doing this like brute force, five questions per thing. And the new approach of like really thinking about what attacks are we seeing in the world, what are actual threat actors doing, this is a very fresh perspective on the way to do threat modeling and secure design at scale. And -- and we've seen the industry shift, especially within Microsoft, over the past, you know, decade or so. But that really isn't represented very well in kind of online discussions about or, you know, other discussions about what threat modeling should be.

Sherrod DeGrippo: Yes, I think there's that. And I also think, Michael, I want to hear from you too if you share my perspective. I'm just, I'll admit it, I really need these software developers to get their together. Like, I -- I have never talked to so many software developers, engineers in my life since coming to Microsoft. I've never spent so much time with them. And man, they're -- they're really different. They are a different breed compared -- they seem happier to start. But they're different from information security people. And Michael, you've worked with developers for a long time. What do we need to tell them? What do we need to have them change?

Michael Howard: Yes, I mean, I think you bring up a really interesting point about you can't tell developers what to do. That's true to a point, I think. You've got to be very careful, right? You know, at the end of the day, you're going to get some -- you may get some pushback if you start, you know, thou shalt do this, this, this and this. But if you're really practical about things and do sort of position things in a way that doesn't introduce too much toil, toil's a world -- a word that we're throwing around now with inside Microsoft. You know, let's be -- there's a word, a term that we used to use in the back in the day is that sometimes the requirements on software developers seem like a tax. In other words, it's just something that -- that you pay because you got to pay it. Now the word that we're using more often, I know that Lee and Shawn will have their perspectives on this, is the word toil. And so, you really want to make sure that whatever we implement and whatever we require developers do, they have the least amount of toil possible. You want to make it as frictionless as possible. That's a term that I've used for a long time. If you can make things really frictionless, then it becomes really easy. And so, I think if you think of the -- you look at everything that the industry throws at you in terms of security best practices, when you're designing and developing and testing applications for security, that list is huge. It's -- it's massive. But one thing I love about this book is that we -- we recognize that those -- those requirements exist. But can't -- can we filter it down to what the attackers are actually doing? And look, and that's going to evolve over time. I mean, absolutely will evolve. But I think if you can reduce that amount of effort required, then I think you'll reduce toil and you'll reduce the friction and the burnout, you know, that a lot of software developers are going through. I'm surprised you said that -- that developers you meet are happy. I don't know about you, I -- I don't see a lot of happy developers. I mean I do --

Sherrod DeGrippo: I don't know if they're happy. They seem happier than us in security.

Michael Howard: Happier. Okay. Happier. Okay, fair enough. Yes, I think -- I think like the core lesson I think from this book is there's a bunch of stuff you got to do, but you can prioritize it today based on what the threat in -- the threat agents are actually doing, rather than just doing all this other stuff over here which is, you know, it's -- it's goodness. I'm not saying it's not bad -- I'm not saying it's bad, but I, you know, from a priority perspective, some of this other stuff may not be as important compared to what the -- the attackers are actually doing today. And I actually want to point something else out. When I was working on this book with you guys, I was actually in the Microsoft Red Team working for Craig Nelson at the time. So, everything I looked at was, you know, the Red Team's intel adjacent, shall we say. You know, we're sort of part of that group of teams across Microsoft that focuses on threats and -- and to -- to a certain degree, threat intel. So, everything I -- I did looked at life through that Red Team lens at the time. I've now moved on to post-quantum cryptography. But yes, at the time everything was -- as was in the Microsoft Red Team. So, Lee and Shawn, do you have any thoughts on -- on toil and all that sort of stuff?

Shawn Hernan: Yes, I've got a lot of thoughts on toil. I think Michael, I will agree with your perspective that you can motivate the developers up to a point, but there are right ways and wrong ways to do things, and crypto is a great example. Your work in post-quantum crypto now. There are ways in which we know that cryptography fails that are just non-obvious to ordinary developers. And I think the most important thing we can do for your typical developer is to enable the platform to provide the things they need. We can't leave fundamental choices like logging and cryptography and auth up to individual development teams. We've got to enable them, make it as simple as possible, reduce the degrees of freedom they have within certain business needs to get things right. We -- Michael, you and I have talked and Lee, you and I have talked many years about don't roll your own crypto. I say don't roll your own auth. Don't roll your own. Don't roll your own AuthN. Don't roll your own [inaudible 00:17:28]. Don't roll your own logging and alerting. Use the platform and one of the challenges we have is to continue to enable the platform to make it easier for the top of the stack developers to do the right thing with as little toil as possible.

Lee Holmes: Yes, and that's -- that's one of the things that I really -- I -- I think that comes out really well in -- in the book is our perspective on like durability and this is --

Shawn Hernan: Yes.

Lee Holmes: -- a huge lesson that we've learned within Microsoft. I shared your point about like why do devs keep on getting this stuff wrong all the time? It's because in general, companies haven't invested in giving them the platforms that only let them get it right. And so, you get these situations where traditionally security has been, "Okay, write your --." Even like high-performing security organizations. It'll be, "Write all your software, think about security from the start." And then you'll run other things around like, "Well, make sure -- here's this checklist of other things you want to make sure that you're doing right." And so, you make sure that you haven't done any network isolation issues or you haven't rolled your own crypto, those kind of things. But one of the things that we really learned in the rollout of SFI was that when we're introducing all of these new requirements of the different like engineering factors that they have to pay attention to, well, how do we get out of treating this like a checkbox and a clipboard exercise and instead roll it into the platforms that they're using? And so, when you're worried about making sure that you're using the right form of identity when you're accessing a storage account, you know, rather than a -- a SaaS connection string using an Entra identity, well then how do you make sure that the next service that starts up tomorrow doesn't make that mistake? Like, we've got to set up the right guardrails in the infrastructure they build on to make sure that they just can't get it wrong. And this is how you make sure that these engineers are shipping the right stuff, secure stuff from the start.

Michael Howard: I want to just riff off a point that Shawn made. I think it's really important. So, a chapter that he and I wrote together is called "Identity and Secrets." And there's a whole section in there on how to validate a JWT token. The fact that it spans five pages terrifies me. I even made a comment in the book about that. So, the fact that you have to check all these things, you know, is -- is terrifying because if you get something wrong, then you know, you've now got -- you've now got an authorization bypass potentially.

Lee Holmes: Yes, yes.

Michael Howard: So -- so, rather than doing all that stuff, let the underlying libraries do the work for you. It is added there as a background to the things you need to know about, you know. And I hark back to the old days of X.509 certificate validation where people would get it all -- all wrong in the early 2000s. And it's almost like, you know, 2000 has called and wants its vulnerabilities back. Right? But now we're doing JWT tokens as opposed to X.509 certificates. So, to -- I really want to stress what Shawn just said a moment ago is that you really, wherever possible, want the underlying libraries that you understand underlying infrastructure to do the work for you rather than you "air quotes" rolling your own. And JWT tokens are a really good example. Admittedly, not many people do validate JWT tokens. They don't have to. Clients don't have to. You know, those who are providing a resource have to do it. But even so, yes, call the underlying systems if you can rather than creating your own.

Shawn Hernan: I think that brings us full circle back to what the attackers are actually doing today. We -- people who have been around the security industry for a long time, memory corruption will be high on their list. And it's certainly very high. It ought to be and is of right high on everyone's list. But from my perspective, I see Auth by -- AuthN [inaudible 00:21:23] bypasses, token leaks, things like that being -- phishing also being very important to the modern threat landscape. And -- and that chapter was -- that chapter turned out to be the longest chapter in the book, if I recall right. Yes.

Sherrod DeGrippo: Part of --

Shawn Hernan: Yes, that's a good point. Actually, I don't mind, that's a good point actually. We aimed at the beginning to have every chapter around 20-ish pages roughly. And that chapter ended up being 60. Sorry.

Michael Howard: Yes, that might have been my fault.

Sherrod DeGrippo: Having Michael Howard essentially program and -- and project manage this book experience, see he's thinking like, "Well, we wanted each chapter." I don't want to speak too much for Lee and Shawn, but we didn't -- I don't think we -- I didn't want anything to be -- I was just like, "What do we do, Michael? What?"

Shawn Hernan: I got off easy, Michael. I'm just -- I'm so grateful to all your work here. Thank you so much.

Sherrod DeGrippo: Yes, you -- you really shepherded us through this because --

Shawn Hernan: Yes, you did.

Sherrod DeGrippo: -- I was very confused many times. I know people are listening, going, "What, you had to type some stuff?" No, it's a lot harder than that. There's a lot of review, and there's a lot of formatting and there's a lot of, "Put this right here in this right place and do it just like this or it won't work and it won't look right." And I was sort of like, "I'm having a struggle just talking about my content and now I have to do it perfectly too?"

Michael Howard: Yes, Yes. The template for Microsoft presses is horrible. I'll be honest with you.

Sherrod DeGrippo: It's hard. It's really hard.

Michael Howard: Look I -- look, I completely understand why they do what they do, but for those of you who don't know, I literally the number of styles in their template is close to 100.

Sherrod DeGrippo: It was really --

Michael Howard: It's a lot of styles.

Sherrod DeGrippo: -- it's an -- it's a new experience for someone who's never done it. It's not like just typing into a content management system to publish a blog. It's -- it's actually really hard.

Michael Howard: Yes. And then something else I will say though, is a critical part of writing a book is to get the table of contents done.

Sherrod DeGrippo: We did good with that. Right? We did well.

Michael Howard: Yes. I think if you -- if you know roughly what's in the TOC, then you can start divvying up the work between each -- each person. Lee, I mean, you and I, you know, we nutted out one of the very first versions of the TOC. We all thought, all four of us did, but you and I especially, it's [inaudible 00:23:37] like, you know, rapidly. It's fair to say that the draft that we did was pretty close to what we delivered, right?

Lee Holmes: Oh, yes, for sure. No, I think there was -- there's the mechanics of the book in terms of we're talking about style and making sure it goes through the reviews and all that kind of stuff. But you know, I think one of the things that is great is like with the combined expertise, we could say like, "Hey, Sherrod puts her sparkly cool insight here. And then, we'll put some technical stuff regarding the implementation here." And -- and like, gosh, this came together so well after we made sure we brainstormed and talked and discussed like, "What do we want the book end-to-end to focus on?" And it's pretty amazing to see how you can go from an idea to a fleshed-out idea to a couple hundred-page book. And it does, honestly, when you, especially Michael with your -- with your shepherding just does turn into kind of a, take the next step and take the next step and before you know it, you got a book.

Michael Howard: Yes, there's -- yes, it's a couple hundred pages. What do you mean it's 400 pages, man?

Lee Holmes: So, it means more than one in my vernacular.

Michael Howard: Oh, okay. Okay. The interesting part of it is, you're right. There's the mechanics of it and there's a lot of stuff that, you know, version control of the documents and that sort of stuff that was a little bit painful. But one thing I will say about the book that makes this book unique and I'll -- this is something I love about the book is so, Sherrod has a dedicated chapter. I think it's like Chapter One actually is, you know, the Threat Intel Landscape. But this is where I think what sets this book apart from every other book that's out there. I don't know a book that does this. Every single chapter starts with stories from Sherrod about that particular topic. So, for example, there's one on defensive AI. There's another chapter on how threat actors use AI. There's another one on, C++, like rethinking the role of C++. Every single one of those chapters starts with anywhere between a paragraph to much more. And it's called "Threat Intel Perspective." And that's the start of every single chapter. So, we introduce the chapter and then Sherrod has her bit, which is the Threat Intel Perspective. And then that's when we then get into the sort of the technical guts of the particular chapter. And I think that's what --

Shawn Hernan: I'm sorry, Michael. Go ahead.

Michael Howard: No, I think that's what sets this book apart because it makes -- it puts everything through that lens and then the word threat, threat intel, threat actor and so on appears, you know, hundreds of times afterwards because we bring everything back to what threat actors are actually doing. Sorry, Shawn, you go.

Shawn Hernan: I think that really is the secret sauce of the book, the -- that perspective. I don't see any place else in the literature brings this -- the motivating -- motivating the technical content through the threat intel lens. And I don't see that any place else. There's another part of the book I liked an awful lot, which is, it's a really short chapter at the beginning, but one I liked. We talked about the different perspectives from, I think the title was -- the chapter of the title was, "Security is More Than One Team." And that's reflected here. And I know so many organizations where security engineers, security professionals, threat intel, vulnerability hunters, whatever it is, often, think of themselves individually as the security team. One of the things I hope that the security community will get out of this is working better together with their peers across disciplines, between threat intel and vulnerability hunting and compliance and red teaming and pen testing and all of the different stuff that goes into securing a system. I hope maybe this will help bridge some connection between teams.

Sherrod DeGrippo: One of the things that -- so -- so, really quickly, I want to say a lot of the motivation and energy for doing this came from, when I first started at Microsoft, which wasn't that long ago, I joined Mystic to do threat intelligence. But we got thrown very quickly into incidents, including Storm-0558 or Antique Typhoon. And you can read the CSRB report if you want to walk through all the technical pieces of that. But I got thrown into an incident very, very quickly upon coming to Microsoft. And it was trauma. It was traumatizing for me. That incident, that incident, some of the others really were hard on me. And I think John, I remember at one point, John Lambert said to me, "I'm really glad that you're here to experience this." And I was, too. But what he saw was, "Sherrod, I need you to go talk to these developers and tell them the reason these incidents have happened are because of this. Because these tokens weren't revoked. Because you made 500 test tenants. Because you gave over-permissioned authentication. You did all of these things. These developers made all these choices, and that's what led to this incident, Sherrod, that has traumatized you." And I used that very much to power me through, you know, really kind of a reckoning of, if these developers would work differently, they would have saved my mental health a little bit. And one of the things that I try to tell them when I do these workshops is developers are terraforming the battlefield that defenders have to fight on. So, we're just asking you to give us the higher ground, because there is going to be a fight on what you have created at some point. Help us be safe. Help us defend your terrain. Help us do the right thing as defenders, so that we're in league with software developers, in league with engineers and architects, and not feeling like we're cleaning up a mess that was left to us by them.

Michael Howard: And I think a really important part of this book, and I know Lee can talk to this because he wrote most of the content on this, is this isn't an AppSec book. It's not even an OpSec book. It has AppSec and OpSec, but it combines the two of them. And I know, Lee, you wrote a lot on the operational security aspects. And if you look at -- so, you mentioned SFI before, which is the secure future initiative. You know, a big part of that is driven by -- by -- by risk. And it's not just AppSec, it's OpSec. And to your point before Sherrod, about having 500 test tenants or, you know, apps or whatever, you know, this is all about operational security as well, not just AppSec. So Lee, do you want to just sort of continue those thoughts? I know you wrote a lot of that material.

Lee Holmes: Yes. And this is, you know, another example like we were talking about threat modeling before, right, where there was a perspective that kind of crystallized about what security meant in the early 2000s and that was fully application security. And you hear about all online and, you know, resources as of, you know, watch out for your cross-site scripting. Watch out for your SQL Injection. And then there's this aspect that, you know, as you start to hear breach reports and -- and stories, Sherrod, especially the kind of stuff that -- that you've been able to explain of like in the real world, sometimes yes, maybe it was SQL Injection, but in the real world, somebody left a key checked into GitHub and that key had access to the following things. And that operational security is more of a -- it's a commitment versus a promise. This is something that you need to find a way to like recognize some -- some guardrails. You know, in that case it's like the secret scanners and whatever. But like, there needs to be a way to recognize that if you leave your room a mess, you're going to be tripping all over garbage all the time. And this is what we get stuck with in security. And you hear about all these breaches where nowadays you look back and you say, "Well, why did that customer service agent have direct unmitigated non 2FA, non-JIT access to production?" Like, we're not at the point in the industry where that's a jaw dropping revelation. It's -- happens all the time. And this is where we can keep on -- this is in my opinion, another huge offering of the book is to really, really go down like what does secure operational security look like?

Sherrod DeGrippo: I think too, now that we are in so much of an AI code written driven world, this book is even more important because you need to understand these concepts so that you can get whatever coding assistant you're using to implement your code securely so that you don't lose it. And -- and that's to me I think one of the scariest sort of realities of today's you know, easy -- easy to create world is you need to understand these concepts to make sure that you are instructing and prompting properly with these concepts. No matter how great your coding assistant is, it is not the level of system design that you as an individual should be able to do.

Shawn Hernan: I want to double down on what Lee said about OpSec, and Lee was a fanatic about this book is not just an AppSec book. And that was -- that really helped set the tone for the book. I think one of the things that's difficult for a Microsoft developer or a developer at any large company is to get over the idea that their -- their -- their peer development teams aren't trusted. We -- we say -- we try to take an assumed reach mindset in my org and across the company and say, "You should imagine what happens if this other service is compromised." And one of the frequent conversations we have is, "Well, but that's okay. They're -- they're Microsoft. They could do a lot of other damage. We -- we can trust them." And it's a mindset shift that's difficult for people to get across. Because I think one of the things that makes developers happier than security people, if in fact that's true, is that security people are sort of more naturally suspicious. So, we have to help developers be a little more suspicious of their peer development teams.

Michael Howard: I also want to just continue a thought that Sherrod just had about AI. So, there are four chapters in the book that are dedicated to AI. One is sort of an introduction to AI. You may think, oh, you know, "Why do you have an introduction to AI?" It's a technical introduction to what all the words mean. And the reason why that's added is because I think there's a lot of people out there who are, you know, who don't know all the stuff, and they're afraid to ask at this point. So, we wrote a chapter on that which is, "Hey, if you don't know all the stuff, don't worry about it, because here's all the stuff you need to know." That's the first. That's the first chapter in the series of AI chapters. Next one is on -- on defensive AI, like how you can use AI to defend your environment. And also, how to defend your AI, which is a different topic, but it's still defensive AI, you know? And we talk about jailbreaking, we talk about guard rails, we talk about also how to construct prompts correctly if you're taking untrusted data, all that sort of stuff. The next chapter is on how threat actors use AI, like how they're actually using AI. And honestly, the introduction that Sherrod gave in that chapter should absolutely terrify you to death. And then the rest of the chapter just helps cement the fact that you should be terrified to death. And then the fourth chapter is on how you can actually use AI to help with your development environments, like how you can actually use it for analysis and so on and so forth. The other interesting thing is that in the chapter on identity and secrets, I included an abridged prompt that we used inside of Microsoft because we had some issues with parsing JWT tokens. I won't go into all the details. It's public information though. It's all in the book. But we end up writing a very complex prompt, multi-page prompt to find some of these issues. And it -- it kind of amazes me how many people are kind of amazed when they see a problem that's more than draw me a picture of a pig sitting on the beach eating an ice cream. You know, and they realize you can actually write multi-page prompts with a lot of information and get some really, really, good quality results back. So, a big part of that chapter as well includes the fact that you should use AI to find, you know, design problems or to find coding problems, in conjunction to threat modeling and static analysis and dynamic analysis. AI is just another -- another essentially arrow in your quiver.

Sherrod DeGrippo: And I hope that people that are doing AI driven software development will take this book super seriously because it is a roadmap guide to everything you need to do to secure what you're creating. You can go chapter by chapter and make sure that those concepts are implemented.

Lee Holmes: Hey, Sherrod, I got a question for you. From your perspective of putting all the -- the threat intel stuff together, this is probably the first time you've seen it with like a bow on it in terms of threatened AI. Threat intel about engineering systems. Threat intel around the way that -- that threat actors are adapting to the modern landscape. Like, what -- what has this meant to you in terms of seeing this kind of all with a bow on it and -- and the -- the process of getting -- getting to that?

Sherrod DeGrippo: Yes, that's a great question, Lee. Like, it's -- it's been -- it's been like peeking into the other world for me. I'm not a software engineer. Most of us in -- in security and threat don't do that stuff really. We've never had to. Or we'll write shell scripts or we'll write things that will facilitate our processes a little bit. We're not building big enterprise software. And so, it's interesting to almost like look in the other side of the mirror, like through the looking glass. Because in my world, okay, a threat actor just did this and this and this. And the reason that the threat actor was able to successfully do that was because auth was wrong. Over permissions were in place. There was some kind of input checking that wasn't done. We know what the threat actor did. Making it so the threat actor could not have done that from the beginning is something we don't think about in intel. We just go, "This was the vuln. This is how they used it. This is what we got to do to get them out of here." We don't see that proto life cycle of how it gets there in the beginning. And so, for me, it really was this sort of view of, "Wow, this is what they're not supposed to do. And now I know what they're supposed to do." We don't work in that world very often. So, I was learning so much about, "Oh, this is what you're -- this is the actual best practice. This is where you're supposed to go. This is how it's supposed to look." Whereas I'm normally on the side of it that's like, "Oh, these are all the bad things that happen. It's very broken."

Lee Holmes: Well, the true best practice is getting to the point that the things that you're pointing out with the threat intel aren't happening. Right?

Sherrod DeGrippo: Right.

Lee Holmes: Like, and I think this is that industry perspective is what so many people miss. And -- and whenever I have a security discussion with any team, whenever I can pin something back to a thing that happened in the real world, you know, an actual threat actor or actual threat actor technique, I think this is what, like, what people started to realize when APT1 was first being discussed was there are actual people who go to work eight to six or whatever, seven days a week, go to an actual building, they hack all day and they go back home. Like, being able to help people understand that like they don't care. They're looking for anything that's out there. They're trying to get into it and maybe it's useful. Maybe it's mom and pop's grocery shop, who knows? But they're going to go after and get into it.

Michael Howard: I remember something you said to me years ago, Sherrod, was for threat actors, it's -- it's just their job, and to your point, Lee. It's just their job. And in fact, every year they're sort of measured on their success just like anyone else does in any other job. They get bonuses for doing things and they, you know, they go home at the end of the day. You have this mental model and that mental model is -- is kind of wrong. It's just some people, it's just -- just their job. That's all they do.

Shawn Hernan: It's -- it's not script kitties, it's not vandals, it is professional organizations who have intent and purpose and resourcing and patience. And it is something that if unless you have been on the front lines of it, like Sherrod has, you might not really appreciate it.

Michael Howard: Actually, I want to go -- it's funny you bring that up. I was literally, I'm not kidding, earlier today on a call with an old friend of mine in the Microsoft Red Team. We're talking about some stuff. And many, many years ago there's this thing called the Threat Personas where we had like motivation and sort of resourcing on two axes. In the bottom, we had the script kitties. Bottom left, we had the script kitties. In the middle, we had the security researchers. And we tried to break the link between the security researchers and the script kiddies because they were just using the wares that came from the researchers. In the top right-hand corner were the nation states. And to your -- and the funny thing was the guy, he said to me, said, "I haven't heard the term script kitty in years." He said, "But I hear nation state actors every single day now."

Sherrod DeGrippo: It's an interesting world because they are operationalized. Whether you're talking nation state -- nation state sponsored or criminally motivated actors, financially motivated actors, they're so highly operationalized, they're so organized. One of my favorite things to tell developers because they always laugh, I can get a lot of jokes over on software developers that threat intel people are like, "Yes, Sherrod, we know." But I can make good jokes of the devs that aren't initiated like we are. But I always tell software developers, I'm like, "Have you guys ever heard of Jira?" And they're all like, "Yes, of course we know Jira." I'm like, "Yes, no, threat actors use Jira. They put in tickets. They do sizing. They're -- they're using software -- they're building software exactly the same way you are." And it's fun to watch their faces. And they go, "Wait, what?" I'm like, "Oh, yes. They're organized. They work their tickets every day when they come in."

Lee Holmes: And they come home and complain about office politics to their significant other and go back the next day and get back to hacking.

Sherrod DeGrippo: Yes. And one of the ways that we've seen that, not just from their behavior, but we've seen so many conversational chat leaks. If you're interested in looking at them, you can look at the Conti leaks. You know, they complain about how much money they're making. They complain about who's working what project. "Oh, I don't want to do, you know, the ransomware on that. I want to run the infrastructure on it instead." They complain. They say they don't like their boss. Yes, they have bosses. It's organized in many ways like a software startup, but instead of building, like a SaaS application, they're running ransomware operations.

Lee Holmes: Can imagine, like, "Oh, no, not another hospital. I was hoping for something [inaudible 00:43:01] time."

Sherrod DeGrippo: And I wonder, too, like do they care? Are they just, like, "Oh, it's an American thing, whatever. Shut them down. Get that money."

Lee Holmes: Yes.

Sherrod DeGrippo: I think occasionally they have a little bit of remorse, especially if they get caught. But for the most part, they're looking to attack and achieve their objectives because it is their job.

Michael Howard: I think something else we should mention about the book is the forward and the afterward.

Sherrod DeGrippo: Oh, yes.

Michael Howard: And so, the forward is written by Mark Russinovich. He was really excited to do it. I gave him the -- the table of contents, and he's like, "Yep, this is exactly what we need." You know, because he sees this stuff all -- all day every, you know, as well, being the -- the CTO for Azure. And then the afterwards. So, as I mentioned before, I was in the Microsoft Red Team at the time, and my manager was Craig -- Craig Nelson. And once he learned there was, well, I had to get the okay from him to write the book anyway, at the time, he said, you know, "Hey, I would love to write an afterward for this." Just to sort of to your -- to your point, Lee, before put a bow on it, sort of round out the book at the end. I'm like, "Sure, not a problem." Expecting an afterward to be, I don't know, one page, maybe two pages at the absolute most. Yes, it was nine pages. But it's a really good afterward. It really round -- if you were to sum up the afterword in two words, it would be, "So what?" And that's the angle he takes. So what? So, you know, what did you learn from this book? And so, what? Like, why should you apply this? And he talks about politics, like, the politics of security vulnerabilities and research and binding bugs and you know, exploiting them and, you know, getting into environments and so on. He goes through all of that stuff. The afterword is absolutely magnificent. Don't get me wrong. Mark's introduction is short and sweet and to the point. And then I think Craig's rounding at the end of the book really finishes off the book nicely with, "So what?" It's not cynical. Don't get me wrong. It's not cynical at all. It's a very nice, practical rounding. If you know Craig, you should be surprised it's not -- it's not cynical. But it's not. It's a very positive spin on the contents of the book and I love it.

Sherrod DeGrippo: I think Craig Nelson is great. Mark Russinovich is great. John Lambert, for inspiring so much of it, is great. And we should also do a quick shout out to all of the many, many reviewers who share their opinions in. I mean, once you started, Michael, you mostly were kind of spearheading that. Once we started letting people internally get a -- a look at the draft, oh, goodness. There was a lot of opinions.

Michael Howard: Actually, it was Lee who did that. Lee opened up the book --

Sherrod DeGrippo: Oh, Lee did it?

Michael Howard: -- internally. Yes, yes. He -- he -- we were really, really close to being finished and we had all essentially -- were we at PDFs at that point, like markup or was it still in [inaudible 00:45:44]?

Lee Holmes: [inaudible 00:45:44] still in like Word docs, but --

Michael Howard: It was? Okay.

Lee Holmes: Yes.

Michael Howard: So, yes, we opened it all up and we got lots of good comments on the content. A lot of it was really positive. Just, "Hey, thank you for pointing this -- this thing out." A couple of small corrections here and there, but yes, we have a lot of very, very good SMEs, you know, subject matter experts inside the company who provided their, you know, their -- their input. I will also point something else out. This is really important. In the acknowledgments, I'm an absolute stickler for never leaving anyone's name out. I'll tell you right now, when you hand a person a book who is like involved, like provided feedback, the first thing they do is go to the acknowledgments and look for their name. It's the first thing they do. And you don't want them to be disappointed, especially after they, you know, provided input for you. So, I'm a stickler for making sure that absolutely every single name is in there and spelled correctly. Because sometimes some of the names are a little hard to spell.

Sherrod DeGrippo: Thank you for doing that.

Lee Holmes: That's one of the things I think is so cool about the book is that, you know, words are cheap. You know, security folks are common for setting -- commonly known for setting just all kinds of like thou must, thou must, thou must. What makes this book different is that it's couched in reality. You know, this -- the Secure Future Initiative and the -- the principles that we discuss in the book are 100% the reality of what folks are dealing with every day at Microsoft. These are the security requirements that -- that every day teams are being measured on, the guidance we give on like what are the things to pay attention to for identity and for engineering systems? These are all derived directly from, you know, threat intel sourced changes and fixes that we needed to make, including, you know, previous operational best practices. And then getting the chance to like take even down to the fact of how do you run one of these security programs at scale that can be something that you as a company can execute on? You're not going to see that in other books. And then being able to leverage the -- the incredible security community across Microsoft to add their, like their unique perspectives from executives down to the engineers working on the specific features. We have just such a huge group of support that we were able to leverage throughout the book and through editing. And then you know, clearly there are just enormous amount of people who are operationalizing everything that we describe in the book today. It's just been a great example of -- of what a community can come together and do.

Michael Howard: Yes, I really wanted to call out a couple of names. Well, it's actually a Lee Holmes couple, so it's more than two. Some -- some people really went overboard to provide like incredible feedback across multiple chapters. Carolina Hattonpah [phonetic], I know I've got her name wrong. I always get her name wrong. I'm sorry Carolina, if you're listening, on the Microsoft Red Team. Christiano Bianchet [phonetic], also on the Microsoft Red Team. They looked at everything through a Microsoft Red Team perspective which was absolutely fantastic and terrifying at the same time. Mike Andrews who's on Azure Security, mainly in networking. You know Mike, he hasn't a few -- he always has a few opinions, does Mike which was fantastic. And also Raul Garcia on the Microsoft crypto board who really went through a lot of chapters to make sure that the crypto was -- was -- was correct. And finally, the -- the documents, all -- all the draft chapters were reviewed by Ava Ben and Richard Diver. They're our technical reviewers and they did a magnificent job, too. So, yes. And that's just -- just a couple of the names. Again, that's a Lee couple. But, yes, there was a lot of people who really went overboard to make sure this book was as good as it could possibly could be.

Sherrod DeGrippo: It was definitely a team effort and I -- I really appreciate everyone that participated and helped us because this -- this was a big effort and I think my hope is -- my hope is that you know, the world becomes more secure as we have access to these new AI tools and we're doing so much more and we're pushing out so much more. I hope that we find all the old bugs. Like, I was really inspired. I'll like real quick story and I'll pass it over to Shawn after this. I -- I grew up OpenBSD, that was my obsession. I loved OpenBSD and I built tons of infrastructure using OpenBSD. And I eagerly enjoyed watching Theo de Raadt and Darren Reed from FreeBSD fight on these -- on the mailing lists and just full disclosure, mailing list and fight, fight, fight. I loved it.

Michael Howard: They had a fight? Surely not.

Sherrod DeGrippo: Oh my God, it was incredible. I learned -- I learned how to flame from those two. I learned how to write a mean email from -- from Darren Reed and Theo de Raadt. But seeing AI find a 26-year-old vulnerability in OpenBSD, that was earth shattering for me, even at my advanced age going, wow, I was -- I was a believer, I still am a believer that OpenBSD is incredibly secure. AI can do stuff that we haven't been able to do. And I think, you know, this book really is the handbook that people need to use to secure their code.

Lee Holmes: Yes, I know there was, you know, the term that was often bandied about, right? It was like open source makes all bugs shallow. And it's only the combination of that plus effort, you know, that plus attention and effort. And the fact that something exists doesn't mean that it gets attention or effort. Just as you see so often with these huge, popular open-source projects held together by a couple of people, whether that be one or a dozen. Right? Now, with AI, now you can point it at things and, yes, you're going to get a lot of false positives out of it, but you're also going to get a lot of true positives. And, you know, this is the world we live in and this is also the world that we can use to our benefit because internal source is open source. Right? And you can make all your bugs shallow internally as well and -- and you know, really make some hay on improving things.

Shawn Hernan: I don't -- I don't think we've reached the end of bugs though.

Lee Holmes: Nope.

Shawn Hernan: I don't think like the -- the real question to me isn't the false positives, or the false -- or the true positives, the false negatives. What is the ragged edge? What is the jagged edge of AI? I think that's where the battleground is shifting. So, I don't think -- I don't think we're at the end of infosec by a long stretch. And I -- I think the battle will continue but on new turf.

Sherrod DeGrippo: Agree, and --

Michael Howard: It's -- it's interesting you bring that up though, Shawn. And this segues nicely with OpenBSD and Theo de Raadt. He and I had an email exchange with --

Sherrod DeGrippo: Michael, are you okay?

Michael Howard: -- with integer overflow issues. No, back in the day, like it was a long time ago. And it was interesting because -- it was interesting getting his perspective because it was relatively new at the time when he and I were talking about this. And to your point, Shawn, there was -- there's always going to be new vulnerability classes that no one ever thought about. You know, did those integer arithmetic problems exist back, you know, when they were finally discovered? Yes, they already existed, but no one had the bugs because no one knew what they were. And all of a sudden, someone woke up and said, "Well, hang on a minute. If I had these two numbers together, they overflow. And now next thing I've got memory corruption and I'm one step away from running exploit code." You know, the bugs didn't exist until they did. And it's the same today. Like, there's class of vulnerabilities that we don't even know about yet. But one day we will.

Shawn Hernan: One day we will.

Michael Howard: Yes. One day we will.

Shawn Hernan: There's no reason to believe that criminals and nation states are going to give up looking for ways to attack us.

Sherrod DeGrippo: And --

Shawn Hernan: Yes, that's going to continue.

Sherrod DeGrippo: It will continue. And the fact that we've -- that I brought up Theo, one of my acolytes in security, I'll bring out my -- my other acolyte in security. Yes, I get it. He's controversial. Bruce Schneier wrote my favorite essay on security of all time called "It's a Process: Not a Product, the Process of Security." He wrote it in the year 2000, so it's 26 years old today. It holds so true. I hope we'll link it in the show notes. But security is a process and we will continue to work this process making things more secure as more code comes out and more things are found. And we will always be doing that forever. And I hope that everyone can take that mindset of, look, this is a process and we're just going to keep working it.

Michael Howard: Absolutely.

Sherrod DeGrippo: Before we wrap up, I'll go through and ask everyone for their final thoughts. But for me, I was just thinking with -- with what Lee was saying about open source. If you have a open source maintainer in your life, if you have somebody with any kind of commit bit in your life, maybe buy them this book as a gift. This makes a great gift for the -- the important software developer who's on a lone journey, probably like that XKCD comic, creating some tiny little library that underpins the entire foundation of our way of life. And hopefully, this will make them feel heard and seen and help them keep us all safe. Lee, I'll start with you. Any final thoughts for people who might be checking out the book?

Lee Holmes: You know, I -- I think, you know, spend the time, enjoy it. You know, we really tried to write this as a book for defenders and from the defender's perspective. There is a lot to learn based on a tremendous amount of scar tissue. And you know, it really represents a lot of tremendously boiled down experience and knowledge from Microsoft. And even after writing it, you know, as we're going through the book's process, rereading it again, you know, throughout the various levels of reviews, I just got re-excited by it every time. And so, I think it's going to be a great resource for -- for many years.

Sherrod DeGrippo: Michael?

Michael Howard: Yes, if I had one -- one final thought, it would be the book is not meant to be an encyclopedia and it's not meant to be a story. In other words, you read from beginning to the end. Jump around. No, what I would do is I would read all the threatening self-perspectives of every chapter. So, it puts you into a nice frame of mind or terrifies you, I don't know which. But the stories are absolutely magnificent and they frame everything. And then find out the ones that really interest you. And I would definitely focus on the AI chapters. They're -- they're leading edge. They're bleeding edge. They're, you know, talking about frontier models. And if you don't know about AI enough from a security perspective, then do read that first chapter in the AI -- the series. There's four chapters on AI. Read that one first. But yes, don't -- it's not meant to be written from -- sorry, read from beginning to end in any specific order. Jump around to your heart's content. And sort of ground everything in what Sherrod writes at the start of every chapter because that will give you, if you think, "Wow, this is kind of, this -- this story is really interesting. This is all cloak and dagger and James Bond and Spy versus Spy. I'm now going to read this chat" -- then read that chapter. Right? That's the one that, you know, interests you the most. I'm not one for ordered learning. I'm always all over the place. But I end up -- end up absorbing everything eventually.

Sherrod DeGrippo: Shawn, what do you hope people take away?

Shawn Hernan: Well, I will say that it was 22 years ago yesterday that I joined Microsoft. Michael was my onboarding buddy. John Lambert was on my interview loop. I am reminded through this book and through my collaboration with Michael and Lee and Sherrod how much there is still to learn in this space. And I hope that the people who will pick up this book will feel a connection with why they found infosec interesting in the first place, because it's an endless playground of stuff to go learn. There's no other place where you have an intelligent adversary challenging you so hard. So, I hope -- I hope this will inspire some folks to keep fighting the good fight.

Sherrod DeGrippo: I want to thank the iconic, the legends Lee Holmes, Shawn Hernan, Michael Howard, my co-authors for the book "Threat Driven Software Development: Defending Online Services from Modern Threat Actors." You can get it available now wherever you get your books. Just go ahead and search that up and go -- go get yourself a copy. Thank you all so much. This experience has been incredible. I really just hope that we make the world a little more secure. Thanks for joining me on the Microsoft Threat Intelligence podcast.