Sentry’s Cody Florek on AppSec Programs That Create Partnerships Not Problems

You don't get to sit on the sidelines and be a wallflower here in this party, right? I think, because while it's fun when you're in the tabletop exercise space, it's not fun when the person who did see something that could have accelerated your investigation or reduced efforts in a certain way. They didn't feel empowered to speak up, so it's an opportunity to also help people feel empowered so that when they get in those scenarios and they have that opportunity, they take advantage of it. Welcome to the "Ahead of the Breach" podcast, where we are dedicated to empowering security experts and practitioners with the knowledge, insights, and actionable strategies to lead the future of cybersecurity. Here's your host, Kasey Kamaleri, CEO and founder of Sprocket Security. Now let's dive into today's episode. Cody, thanks for coming out of the podcast today. Thanks. That's great to be here. Yeah, I can't remember the year where we first met, but it was one of the first or maybe second Wild West hack fest. Funny thing is, we're both from Wisconsin and we just randomly met, and I think at that time you're at Rapid 7, is that correct? Yeah, I was at Rapid 7, and I don't remember if I was managing a team at that time or if I was a consultant yet still, but yeah, I wanted to get out. Way from rural Wisconsin and getting to rural South Dakota. It was great. We're on into that conversation. I remember that conversation for many, many years afterwards, and then we continue to bump in each other. Great to have you on the podcast here today. I remember I was always impressed with your career journey. Maybe you can just walk us through like, how did you get to where you are today as a director of InfoSecOps? Yeah. I was lucky in that a younger age, I knew I wanted to get into information security, so when I went to college, I was very focused and I kind of find something that's in InfoSec, found something in InfoSec, and then while I was doing that, looking for technical jobs as best as I could, the first technical job I ever had was a computer repair guy at a computer repair store. And then from there, I did some IT fieldwork for a few different places until finally I got my first security title in healthcare and I was a security administrator and I did I am. That's what I did. I made user accounts. The process was incredibly manual. We said, "Who do you want to be set up like?" And we just, you know, copy those permissions. Yeah, because you weren't versed in how any of it was built. You were just told, "Create the accounts and make sure you don't give them too much." And obviously that wasn't great. So I led me into a pretty long journey into the identity and access management space and the amount of complexity there to do it well was, it was a lot of fun to dive into that, but I started doing some vulnerability management there once we built a lot of automation in that space. Got into vulnerability management and enjoyed doing that. So I started doing some consulting for access management in the medical record system. So I was, I hopped out on a contract out east for six months and lived out in a Connecticut area for a while doing that for a lot of user access and building roles and identities there. And that's when I pivoted over to Rapid 7 after I spent some time out there. First, I was just doing vulnerability management, but then I started teaching some hacking classes for MetaSploit and eventually we took on this new product called AppSpider, which turned into their product inside AppSec today as people know it. So our team had to build services for that and that was a fun journey. We weren't trained real well and had to go out and figure out how to make this thing happen and we didn't succeed it and eventually it became a manager for Rapid 7 managing a team of consultants. And so we did a lot of implementation for folks and assessment for people. And once I completed that, I jumped over here to Century Insurance and I took a manager role over here, had a team of incident responders and a little bit of vulnerability management. Everything was kind of mushed together. And there was a few other teams around that space. So I did an access management and engineering and a few others and we started to grow that a little bit more and a little bit more year over year. And now we've got a pretty sizable group in our area and AppSec, vulnerability management, red team, engineering to say access management already, we might've got a lot there. Yeah. Yeah. There's a lot of things going on. No, an incident response. How could I forget? So, I mean, an incident response also houses the Thread Intelligence components. So we're busy for a lot of things and it's been fun because at Rapid 7, I got to jump in and just talk to clients and be the good guy all the time, right? And then drop in, drop out now, I get to really like get my hands at early and help build a program. Yeah. You own it. You have to see it through, right? You just can't say, here's the problem. Here's the solution. Good luck. You have to be like, I guess I have to implement the solution, you know, and, right. Not only do I have to, you know, so I'm director of information security operations, which means not only do I have to turn the thing on, but I also have to make sure that long term it works. So that's the operations component of when you're doing a project, you build and build and build and build and everybody knows about it. But then after a while, there's not so much shine and you go into operations mode and there's always going to be a volume of work that happens in operations mode. And people aren't going to know about that product or service as much anymore, but it's being maintained in the back. Is there a way that you measure that knowing that you implement something and then you have to maintain it and you have to build the operations around it? Yeah. Is there a way that you kind of try to measure that? Yeah. So here at Century, we do a lot of agile methodologies. And even though we are not developers in our group, we operate in the same way. So we measure our capacity to accomplish tasks or projects. I spent a lot of time with teams trying to figure out how much capacity do we have to achieve a certain goal? And it is not necessarily meant for you to be thoughtful of, okay, I'm going to hit this checkbox and this checkbox and this checkbox. And it means if I say I'm going to hit these milestones reasonably, am I going to be able to do that? And if you miss by a little bit, that's okay, but you're trying to get close to that target, right? And there's kind of two buckets. You have project work and then you have operational day to day work. And I measure the projects. I don't measure the day to day for some of the capacity project kind of thing. If you see your capacity, you're usually delivering X amount over a period of time. If you start to see that shrink, that means that it's obviously over here on the operational component. Yeah. Yeah. Now, I will measure some of the operational stuff for incident metrics or tickets coming into the IAM group to just get a general sense of volume of effort it takes to accomplish some of those things. So more from our staffing levels, accurate, do we have what we need from a resource perspective? Is there an opportunity for automation, you know, if we're continually getting bombarded with tons of operational things, you'll see the slippage happen on the project side. So from a agile methodology, projects is how we measure that from an operational side. It's more, what are the metrics closest to you that you are able to measure? Okay. The projects that you're looking at, size, and the effort, these like t-shirt size, point system, I know there's different ways to do it, but what's worked for you, Cody? I mean, we do points and different teams here at Century do different things. You know, I try to aim at rough guests every day as two points. You got a morning and you got an afternoon. Can you do that in the morning? Can you do it in the afternoon or is it take all day? So every week, you've got hand story points. So we measured by two weeks for our sprints, so every two weeks, you got 20 to work with. Well, you're probably going to do some email and you're probably going to have to talk to some folks. So you're starting to cut off time and do you happen to have any days off? Well, all right, so you get down to it and you might only end up with five story points available to you depending on how crazy your schedule is. So let's be realistic about what you're actually going to commit to over the next two weeks. And these are the things that, you know, directors and InfoSack, you know, well, directors in general have to do capacity planning, project planning, things like that. What else do you do in your day to day as a director? So it's a lot of coordination as an InfoSack area. I'm kind of the lab that I came from a customer service background when I was at Rapid 7 because everything you do is for the organization, right? So you're trying to provide a service and ensure that you have good customer satisfaction. So is your internal CSAT is it going up or is it going down with outside entities? Now, yes, you have specific requirements to maintain in terms of security, but making sure that you are locked step with different parts of the organization so that when they need something, you're delivering something useful. And when you need something from them, there can be some reciprocation there. So a lot of time is spent trying to make sure that we've got our eyes on the right projects, that we know what some of the upcoming work is going to be or where we need to inject ourselves at the right time. That's more at an organizational level from a internal to InfoSack area. It's do we have the right training to perform our work? Are we measuring things appropriately? So we're self-aware enough of when we're struggling? Or do we have blockers that we now need to think about and refactor? Is our design choices appropriate? So there's a lot of external analysis, internal analysis that goes on there. And then at times you're brought into to kind of talk about the risk of a certain thing. And what's our risk appetite and should we take action? Should we find a mitigation? So do we need more data? There's a variety of things happening in that space. Yeah. And I was going to ask you, how do you communicate that risk up, right? Many people have different styles of how they do it, different analytical ways of thinking about it. But what has worked for you when you need to kind of communicate that risk to upper management? Yeah. I think so. There's a variety of nuances there based on kind of the category that you're looking at. Are you talking about what risk is there in this new business process that maybe there's not the most clean way to secure? There's risk inherently in doing business of this type, or maybe not in this type, but in this way. And there's no good answer to go around it. Those are conversations that you're having with the business unit. And then you raise that up to your, your sometimes it's a meeting to kind of talk a little bit more. Other times, you know, you have to form an exception if it's flying in the face of policy directly. So you need to register that. Now there's other risk elements that you can measure. And that would be more from vulnerability management and abstract metrics. So how much risk do you have kind of baked in the things that you own and how are you driving that down month over month metrics are useful, but calling that out is in a specific way is useful. Otherwise, if it's a new hot button vulnerability right out the door, well, that's get people on the phone. So you go from operational tracking and movement on vulnerability management to incident response mode when you hit a certain severity level. And then all those metrics kind of go out the door and it's getting people on the phone and making sure that you're blocking and tackling and getting the right people online to mitigate, stop or whatever in those particular moments. So that's kind of when you go over to the the IR side of the house. So lots of silos on raising risk, right? Yeah. What I'm hearing Cody is you basically say the way you communicate that risk up changes based on the different aspect of security you're talking about. You're talking about incident response, you're talking about business operations or you're talking about blin edge vulnerabilities or emerging threats are coming out. Have you found it easier to communicate risk because you come from a technical background or another way of asking the question is do you leverage your technical background while communicating risk or do you shy away from that? I think it was a good place to start to help you understand what the real impact of that thing was. So when you study and you're kind of coming up in the info sex base, here's an exploit. Somebody could drive a truck through that. Right. Right. As I grew in terms of understanding from a career, so understanding how businesses operate, what the true value set is of having a info sec group. What service they're supposed to provide you're talking about. What's that mean in context of the environment in which it lives? So the technical background has helped me understand a lot of those things of what is the issue? What's the context in which it lives and what does that mean for the business overall? So that way you can translate that to somebody who will make a decision on, yeah, we're going to call all kinds of people in overnight or no, we're going to shut down something or any of those big scary red buttons sort of scenarios, being able to translate that technical into something reasonable and clearer required more than just technical. So technical is absolutely useful, but it's not all of it. So yeah, right. Now you have technical spreadsheet kung fu chops, right? Right. Let's talk about abstract for a second because back in the days, you know, info sec network security, what was the thing and you spend a lot of time and effort locking down networks. Now I believe, you know, we've shifted, everyone has tons of applications, people are developing their own applications, people are inheriting applications that they need to maintain. And the rate at which we're deploying code is just getting quicker and quicker, right? So therefore we are increasing our opportunities to great mistakes, great vulnerabilities and things like that. So a lot of people are trying to wrangle their abstract strategy. What's your approach, Cody? Well, every organization kind of approaches it a little bit differently and has every organization has a journey that they have to go on. So it's where you find yourself is a little bit of where you got to pick up and start working. Some organizations are very securities going to come from the app dev world because the organization maybe doesn't have a lot of folks who understand applications or anything of that nature. They understand infrastructure. So they do the traditional security stuff. So app dev folks to bootstrap it, but if you go the other way, which was been my pass because I came from a more traditional security background had some volume of programming understanding. But when I took on appsack at rapid seven, it took me a long time to figure out there's a little bit of a shift here in mentality. And once I clicked with that and put in a lot of effort to really understand that space, it was, we need to enable that group in a way that is useful. So it can't just be, here's your scan data. Enjoy. I don't understand what the scan data does or means or how you truly pick a part in application, but you're a developer. You'll figure it out. Here's your bonus, right? What my approach has been more fundamentally, you have to do a couple of blocking and tackling. You got a couple of pay to play type things that you got to do first. So how do you do your Sastened S scans appropriately and do it right for every application? So on board and rinse and repeat that onboarding process. That onboarding process, it should also include some risk analysis and understanding the app so that you know the, so here's the vulnerabilities that are out there. And what we've started doing is because you can't just go off of the OOS model. I mean, the OOS model is, is useful for telling you this. This is bad, but what does it mean in context? And that's probably the big nuance that I think a lot of folks struggle with. So where we went was we did dread modeling. So let's talk about where in the scan do we see trouble? Let's focus in on that trouble and then start dread modeling that out and saying, okay, based on the context in which we find this vulnerability, here's truly the things that we want app dev you to spend your time on when you've got a laundry list of crazy things to do already, we're going to jump in and we're going to add some more. Well, we're going to add things that are meaningful for you. So that's been our journey to get some things up and going in that space. And what I want to do is, so we've got a team here where we spend a lot of time focused in on AppSec and making sure that developers are working on the right things. But we do the triage of that first. What I'd love to do eventually is get tools closer to them. Once we clear out a lot of that riff rough and things that they need to early on sort of stuff. But once we get through a lot of that, then we're going to move a little bit closer to the developer at that point. But that's a journey to get there because yeah, it's up there. Yeah. Some people get hung up on just, you know, to this point, right? Sass and Dass over and over, right? And then they just keep getting these list of vulnerabilities because they're just doing CVE matches against library versions and they're at app, you know, and throwing it over the fence saying, fix it really, but there's no validation of, are they using library that way or they're truly vulnerable to this thing? You know, a lot of people get hung up there. Do you have any suggestions or ways to kind of get past that hump for our listeners? I kind of like, that's me. That's where I'm at right now. I mean, knowing that a library exists and it has a vulnerability in it is one thing, trying to understand the context of that in an app requires a partnership with the development team. It's hard for one single app, sex person to know all of the apps within an organization. You don't write it. You're not in all those code bases, but trying to understand where do you use it? And okay, let's talk a little bit more deeply. Are you actually calling the portion of that particular library that's vulnerable? Are you not? There's some automated tools out there that can tell you. There's also code review that people could do to understand that a little bit more. But knowing that I think is in having that conversation with people of what does it mean in the context of like, yes, this is bad. And based on some of our controls, maybe our WAF doesn't detect that type of thing. Okay. So escalate that. What's the impact of somebody actually exploiting it? Okay. Well, hi. Okay. Again, bring it up. We have that context of, hey, we've seen this vulnerability. We believe it to be exploitable, but we don't want to exploit it directly right now. So your red team doesn't want to run out of it immediately unless they get something spun off off to the side, which isn't always easy to do depending on what data you need. So doing some analysis and then bringing it back to the app dev team to partner with them to get how are you calling this is really useful. So that's why I always suggest don't just throw things over the fence because you're going to have to ask for intel back. And if all you do is over throw things over the fence, you're not going to make friends. Yeah. Don't throw your junk in my back here. Right. Now, you mentioned dread model, right? So that's where I imagine you have someone on your team that is doing exactly that kind of that triage, maybe do it using dread to help and then, you know, reaching those teams to have that communication to kind of actually help perform dread to figure out what the next step is. How are you approaching it, Cody? Yeah. So we have spent a lot of time looking through the findings saying, what's worth our eyes, looking at it and what's not. And then from there, doing some dread modeling and then we cut tickets to teams and say, Hey, here's your prioritized list. Take a look at it and we're going to have a conversation about that over a period of time. So we meet with all of our app dev teams on a cadence and that cadence helps us keep fresh with some of the things that they have upcoming and it also keeps us fresh with, you know, some of the tickets that they're working on. So yes, I am going to complete this ticket, but because of the library that we use, there's a different upgrade that we need to do because of a dependency. So therefore, it's going to take longer. Is that okay? Is there enough risk here that we need to accelerate that timeline or not? And those are the types of conversations that you're having with those teams because just like we've got a timeline and projects that we're trying to complete, they do too. So you're trying to talk about risk and, you know, do we need to bump this work to pull this in or can it fit nicely within our cadence? Got it. So we're past that, huh? You're starting to talk about maybe moving closer to the developer. Should I dare say shift left? Is that where you're taking the next phase of your app sec journey? Once teams no longer need that amount of filtering to get to them is when I'd like to really empower our developers to that point, once it becomes a value add as opposed to detriment. So right now we do that triage and there's enough complexities that I think it's, we're doing a lot of value add for teams. I think having those tools right in front of people, it's hard for an individual to prioritize something broader for their team or multiple teams, you know, depending on how the apps are developed. So as people write code in there is an opportunity to talk about a vulnerability there before they hit commit and then it gets scanned and assessed from a SaaS perspective. Is there an opportunity for, you know, some tooling to talk about it right then and there? It'll kill my app sec metrics and make it look like we're not doing anything, but it'll be worth it right because you just won't have things show up in the first place. So we're not there yet. I think some of the tooling is good to do some of that. Some of the tooling to do that is a little spotty and some of it is what tools do you develop in because certain things, the tooling to do that automated analysis works well with and some of it doesn't. So I think there's a lot of things that we can do to continue to analyze that space and test it out, see how it goes, are we seeing risk reduction or no risk being introduced at all. That would be great to see over time as opposed to adding things into people's sprints. So that's my like pipe dream of where I want us to go, but I think it's a journey for the app sec team and it's also a journey for your entire development group. So that's where we're hoping to go, but we're one step at a time as I say. Yeah, I mean, you can do a whole lot preventing the merge from happening or preventing the push, preventing the merge and then you're just creeping all the way to, you know, a pre-commit hook, right, prevent the commit from even happening, right? You can get crazy, but just starting with deploying that and getting that working. And so therefore you don't have any vulnerable code coming into or you're reducing, I should say, the vulnerable code coming into the repo is a great start. Yeah. Metrics be impacted, but like board the good. Right, so I mean, it's funny because if an organization never does absent and then they start, well, you got to scan all the things, even know like what's behind the curtain, right? So a lot of places have to start there and everyone says shift left. Well, be careful how fast you shift left, you know, like if shift left just means here's my discovery of your data, go fix it and run. I mean, putting your consultant hat back on, right, like I found your problem. Yeah, there's a reason why they call it like shifting left, right? Is because you don't start your, you know, application development group from the ground up saying, I'm going to put in this pre-commit hook at the developer's workstation to prevent security from happening. Now, someone out there is like, I'm building that way. I'm building that way, but like not really when you're building something as the business, you need to get the product out, the code out and deployed. So you usually don't have that model of rigor right from the beginning from an abstract perspective. Well, and it's been on how new your company is, you know, if a company has been developing for years and years and years, that takes time to absorb that mentality, that toolset, that change in methodology. It's a big ship to steer, right? But if you're a newer startup, I mean, there's so many more flexible options for you. If your teams are small, lots of flexibility there. So not everybody is built the same way in not everybody has the same advantages or disadvantages, but that's kind of why it's CWE versus CV, right? You got to help for yourself to some degree. I like that. But Cody, what threat do you fear the most? I mean, there's like typical answers of, you know, some threat actor out there, you know, I'm scared of ransomware. I think I am more thoughtful on how much coverage did we get in our implementation plans in our designs, the analogy that I often have is it's like a plinco game. And what you're trying to do is prevent that ball from plincoing all the way down, right? Like you want it to stop. So you got so many layers, it's defense and depth or pyramid of pain or whatever you want to call it. Did we do all the right things or is it going to be the star as a line? And then you've got that like it falls straight down. So that's probably the thing that I think about the most in terms of things that make me nervous of, are we sure we did it all. And a lot of the time you can walk away and say, yeah, I feel like we did. And we've got enough layers here to keep us safe and operating appropriately. But there's always something in the back of your mind going, well, what if you always have that person saying, well, what a, right? So you're trying to reason with that and come to terms with that all the time. Yeah, well, I was going to ask you like, I mean, how do you get to that point where you feel comfortable? Is it threat modeling? Is it Cody's hacker brain just going, what if, what if, what if the team have some exercises? Is it, are you using MITRE attack framework to kind of build yourself a heat map? What works for you? I mean, it's kind of dumb, but the answer is all of it, right? So I am not, I'm good at asking questions, but I'm by no means the smartest person in the room, right? Like, so I do think a lot about, well, where else does this impact us? So when I'm talking with folks about web app attacks, I'll talk to folks from a network perspective and they have lots of layers in place and okay, great. And they feel good. But then once you start really thinking about, well, how does web app work and how do some of those attacks where, well, some of that just, it's the Planko game, go straight down. None of those network things necessarily apply in the same way. You're talking about an entire different layer of the OSI map, right? So then you go, okay, well, that's good from that perspective and that helps. What do we do from another angle? So what's the other layer? So we talk to the abstract team and we start saying, okay, abstract. You've got your own controls at different layers. So build, deploy, and everything in between. So where all of those different checkboxes and checkmarks and then red team doing threat modeling, threat Intel doing, what are the bad guys who are chasing after you? What's there? Might our attack framework look like and then have your red team focus in on, does that might or attack framework match up? Our controls, if we overlay them, is it they focus here and we've got a big hole there or is it they focus here and we've got coverage. So doing a little bit of overlay there, I think, is also helpful to help prioritize a little bit of that. And then the other thing is just hygiene of vulnerability management and abstract. Are they continuing to do those operations appropriately access management is access management being handled appropriately in all ways? Is there MFA involved, you know, is our design and engineering efforts built in the right way to help that? And then do we have any detection to say, yeah, but what if that breaks? What if we pull the plug on that particular component, would anyone know until we get the alert? That's way down here. So that reminds me, right, you know, how do you get ahead of that? How do you approach proactive security within your team? It takes time to kind of instill that with everybody within your organization. It's curiosity in asking why, why did that happen, where did it come from? It's not enough to just block something, right, but like, why did that even come into play? And I think instilling that into people in your organization, not everybody's built the same way to think about that curiosity of why or what if. And so spending time with people, when you have an incident, doing incident reviews, when you have a tabletop exercise, talk about what went right, what didn't go right. tabletop exercises are incredibly useful, getting what are the firing ranges going? Those are super useful for people. Having your red team kind of blow something up every so often is also useful. And sitting down with your team and not directing them to ask why, but suggesting, where else could you go? What might that mean? I think it's really important and powerful discussion point to have with people. When you mention tabletop exercises a little bit ago and we're walking through, you know, what if this happens? What if that happens? What if a lot? And you uncover the craziest stuff once you get a really good dialogue happening. And you know, this one was on incident response and it's like, oh, you know, we're covered. We have our password, say, if offline, over here, you know, and we have a accessible here, it realizes that there needs your reaction to ransomware event would actually lock them out of a bunch of absolutely need to have credentials in order to work the whole incident. So it's like, man, like we will have never figured that out. If we just said, okay, check, you know, moving on. It's like, no, you pressed, you pressed and pressed and good stuff comes out. Yeah. And encouraging people to talk in those or say, hey, you haven't spoken. What do you think? There's a reason we brought you to the table. Come on in. Oh, man, it wasn't just a rule of D 20, right? Yeah. Right. You don't get to sit down the sidelines and be a wallflower here in this party, right? I think, because while it's fun when you're in the tabletop exercise space, it's not fun when the person who did see something that could have accelerated your investigation or, you know, reduced efforts in a certain way, they didn't feel empowered to speak up. So it's an opportunity to also help people feel empowered so that when they get in those scenarios and they have that opportunity, they take advantage of it. Absolutely. And Cody, how do you like prioritize all the different vulnerabilities, right? So out of the proactive approach, you identify vulnerabilities, vulnerability management and scanning is identifying things. You have appsack reporting different things, but like you get flooded with all these different vulnerabilities. How do you prioritize them across the whole company? So there's the basics of CVSS says this. Okay. That's the buzz in the news. Is there anything happening there? Is it exploitable? Is there any proven examples of somebody exploiting that? Those are some of the components of let's raise those to the top right away. I think context in which it lives also makes a lot of sense. So if this is a client side vulnerability versus a server side vulnerability, if that's a batch server that no one ever logs into, you probably don't need to hit the big red button to have somebody chase that down right to a second, right? But if it's something that, yeah, it's that batch server and every other server. Okay. Well, that changes it, right? So I think talking about context is really important. There's times at which given the context, we might say we're reasonably sure that this wouldn't be exploitable, but let's test it. Can we try to attack ourselves and figure that one out? If so, all right, well, now we need to activate teams a little bit faster. Otherwise, here is the list of things that you need to kind of cover this month. A lot of things will get covered through your typical patching cycles. We're going to measure to that and understand that and how that goes. But if there's anything that's big and glaring and missing, we need to talk about that because you still have a lot of risk in that environment and we need to drive that down a little bit. And I think the other thing is, is there's been a few vulnerabilities in the past where everyone made it a big deal and nobody did anything about it or there's, I think one was NSA advertised one, I don't know, a couple of years ago. And it turned out not to be all that impactful for a lot of people. So on some of those, we'll say, hey, there's a lot in the news on this particular vulnerability. Keep your teams on standby. We're doing a little bit of research right now because we don't want them to run off and try to create a bunch of downtime when it might be not necessary. So research is incredibly important, but at the end of the day, you're really just trying to say, here's a volume of risk. Here's your prioritized list. You're not going to fix every single thing, but here's the things that you should focus your time on. That's great advice. And, you know, also, Cicicab does a good job, I believe, of saying, you know, it's not always just the new hottest thing, right? It's what is being exploited because sometimes a vulnerability may be like, hey, it's vulnerable, but there's no public exploit, right? And then, like, literally a year or two or three years later, there's someone figured out how to exploit it, right? Now they're scanning the whole internet, and so that dated CVE is coming around and being exploited, right? And it's like, you've got to kind of take that just as another data point. It's multiple data points to come to this. Hygiene is important, right? So like, don't forget to kind of keep things up to date. I mean, it's one reason that you want to keep your libraries up to date. Yes, you run the risk of pulling something in that has an undiscovered vulnerability that's going to be tomorrow's hot one. We also run the risk of what you just said of, like, it's been out there for, what was the SSH one? How long had that vulnerability technically existed before it became big news, right? Yeah. So hygiene and keeping up to date is really important, but, you know, sometimes you do your best efforts to make these things come along, and once in a while you're going to have to just scramble. Yeah. So director, what are the top three metrics you care about, Cody? Top three metrics that I care about through your curve ball by making you only give me the top three. Right. I guess I'm going to maybe cheat a little bit here and talk a little bit more on measuring effectiveness for your different parts of your program. So I think measuring how you are performing in a particular area is really important from your operational day-to-day stuff. So you know, when I talked about ticketing before measuring what does it mean from a day-to-day perspective to operate, and if you start, you know, crossing a wave and going into the red there, expect things to suffer or the downstream impacts of that. I think measuring your ability to affect change for your area is important. So, you know, are you able to show that you're changing your program in a positive way that it's measurable that we've now done something, and it has reduced workload, it has accelerated, delivery, whatever. So I think that's another aspect. And then there's obviously the threat metrics that are important. So and you can break that up into a number of different things. It's your threat intel stuff, it's your sock intel that you're getting on a number of threats that they're seeing and by what type and where. It's your vulnerability management stuff of what are the things that are coming in and the most hot button items from a vulnerability perspective, what's scary out in the world, but then what's scary inside of, yes, I know the outside picture, but what does that mean in context for our systems, is there something that we should be focusing in on to drive that risk down? This is the same thing with abstract, except exchange out systems for applications. And what are the hot button items out there, and how do we translate that into what we're doing here? So it's impact to the organization and your security program. It's your day-to-day ops to keep that up and running. And then your threat metrics to determine, do I need to do something in one of those other two buckets? Well said, because you run so many different, I'd say, divisions of InfoSack that you can't overprescribed and be extremely narrow in your metrics, otherwise you're going to miss the holistic view. And I think you did an awesome job of just laying that out by saying it doesn't matter. Look, you put looking at the threat metrics as the third one, right? Because it doesn't matter if your ability to find and, you know, threat model and find vulnerabilities and handle that, it doesn't work and you're not performing and you can't show impact. And then, you know, secondly, if you can't fix any of that that you find or the ability to make change in the organization, you know, why are you looking at the threat metrics? I know. Right. I mean, the threat metrics are incredibly important to keep you motivated, right? Yeah. This is why we're showing up every day. And that's why we want to partner with people to build better solutions, right? But we have to be effectual. Like how are you actually going to affect your organization in a positive way? And it's kind of through your day-to-day, your pay-to-play kind of work. And then also, how do you build better? So yeah. Great advice. Cody, that's all the time that we have today. Thanks again for coming on the podcast. If someone wants to get in touch with the theater, kind of follow the work that you're doing and maybe ask you a few questions, how can they do so? LinkedIn is really the only social media that I interact with. So otherwise, I just view from afar. Sounds good. Thanks again, Cody, for coming on. Appreciate it. Thank you. Thank you for listening to another episode of The Ahead of the Breach Podcast. If you enjoyed today's episode, please leave us a review on Apple podcasts or Spotify. If you're interested in exploring how Sprocket is shaping the future of offensive security, be sure to check out our website at sprocketsecurity.com. Thank you again for joining us. See you on the next episode.