BSidesDFW2025 Track 3

So

problem solving and proving that big ideas can come into life with a tiny budget, an amazing kid. So Everly is 10 years old and sold this idea to her dad. And she loves horses and makes

many of you.

Let's do the big unveil. This is the finished device.

So, we're a little mini nerds. We in our family, we're a little auditory sensitive, kind of runs in the family, and we need a little decompression time sometimes. So, this was sort of when we thought, hey, we should build a project for B-sides. We were here a couple years ago doing a soldering talk. We do projects. We try and invent some stuff. So, we're trying to think of something practical, and this was the practical idea. So you want to talk them through the picture and what you submitted initially.

I'm not the artist in the family. This is part of our talk submission. She's the artist behind the face and everything. One interesting thing, you'll see how the design changed a little bit. We initially planned to do a Raspberry Pi Zero. That ended up changing, and we'll talk about why a little bit. But the idea was we needed something to play the audio. We ended up using a

Mostly because, well, partly because of the cheapness, but also because of some technicalities about the amplifier and what we ended up going with. So, we started

It's cheap. That was a big piece. One of the struggles was how do we power this many LEDs and do we power them all up at the same time or do we control them independently? We looked at power budget and how to control it. But one of the great things about the Raspberry Pi Pico is that all of its 26 GPIO pins support independent control and pulse width modulation PWM. So you can control the brightness of an LED and for only $4 you get all that control. The real downside is that it has a very small power budget. So the combined amperage of all of those pins is 50 milliamps, which isn't a ton, but it's enough to drive some LEDs, especially if you're creative about when you

drive them and you protect them with resistors enough. I mean, the main thing is it was cheap. It's easy. We did look at one point at using like a servo motor controller to up the amperage a little bit. And then daddy couldn't. I mean, we were kind of running out of time and the I2C interface wasn't working and we're like this cheap piece of crap. So we threw it out. We went back to the original pie because it's flexible and it met the dollar's budget. The rest though.

We did 16 new LEDs that are different sizes and they are displayed on the front. We did 16 resistors, one resistor per LED. We did, yeah, I don't know how to say that. So the DuPont cables, and we'll show a picture in a minute. They're just the little internal cables that they have a tiny pin on one side, they have a little tiny female jack on the other, they just plug in. Real cheap cable for breadboarding. The strip headers, that's what you solder onto the side of the pie, right? So we've used strip headers a lot. The power jack, you want to show them the power jack? This thing. That is the power jack. Simple standard DC power jack. There's a proto board, which you'll see in some of

the pictures, just standard PC board and a buck converter for handling the voltage regulation. It's a variable voltage, so we can kind of dial it in. It left us a lot of flexibility, right? We could start building the project and then if we decided to change to something else, we could just dial in a different voltage. But how much did any of that cost us?

It was all part of my stock, right? So she just, like I did to my father, she has raided my parts collection and taken all my stuff. And now my soldering iron basically belongs to her. So, um. Because I have a better solder than him by far. Yes. Yes. Um, the, the picture is the buck converter. You'll see on the right side of that left image, the little, uh, let's see if my cursor works. This little silver thing. that is the potentiometer that controls the voltage. So you can dial the output voltage anywhere you want from, I think, 12 down to 3.5 or possibly 2 volts. We ended up going for 5 volts, but the Raspberry Pi Pico can take anywhere from

1.8 to 5.5. So we left ourselves a lot of wiggle room so we didn't blow stuff up. The plans changed a little along the way. Okay. This is my bit. This is my bit cause it didn't work out. She gets all the bits that actually worked out. So the original plan and part of why, so we were looking for how do we output the audio? Originally the plan was Raspberry Pi Pico, or sorry, Raspberry Pi Zero. Ran into a few issues with that, one of which was budget, but another was

Originally I was going to use a separate board that would, you can see here it costs, the DF player mini costs about $1.60 in bulk. Did not have one, but we can get them pretty easily. Buy a bunch on Amazon, have them sitting in the parts collection. This would play from an SD card. That was nice because we had SD cards laying around. Standard MP3 format. And I was going to use, this really nice parts express amplifier that I picked up at Micro Center years ago for practically free because it was opened. And so all this was my plan. It was $2 and we'll have the audio worked out. But what was the problem with that plan?

So somewhere along the way, we played some Taylor Swift on Bluetooth and she was like, this helps me relax. And I was like, oh dang, now I have just scope creeped myself into adding Bluetooth to this project. So when we say we went over budget a little, thanks Travis. That was really the reason why, because Taylor Swift has dragged us into a

except like a bulb in the middle and then this is the original speaker which came from a TV I think right? Yep. And then the amplifier with Bluetooth on the top. So we blew the budget with the Bluetooth amplifier a little bit right? We were a $10 budget now we're already at $13 just on the amplifier. But it adds Bluetooth, it gives us a simple stereo connection. It even came with wire whips so you could solder it directly to the speaker terminals. But when we talk about upcycle parts, these came from a company called Parts Express. And when she says they're from a TV, this is a company that does buyouts of big, like surplus electronics. So these speakers started life at a TV factory in Brazil.

They got bought out and we got them real cheap for this project. And that kind of buyout stuff is a great way to go get electronics parts for your projects. The passive radiator, we ended up not using

As usual, this took three times longer than we expected. The original plan was to put the passive radiator right in the middle. And what that would do is, with these speakers, not being giant, they don't go real low in the response range. And so the passive radiator just would sit there and passively vibrate at those lower frequencies and make the bass sound a little louder, even though we're not adding a subwoofer. So that was the plan, but it got cut for scope because we just didn't quite have time to do that. But you'll hear the sound in a minute. It actually, I think, turned out pretty well. Yeah, it worked out really well. So next up, we actually, yeah, go for it.

in the box.

We talked about that quite a bit because daddy didn't do it every time. But eventually we got the box there, just put together with blue tape and then we moved on to

I love pictures, but as you can tell from her concentrating face, it was maybe the wrong time. You want to describe the top left photo.

this stuff a few times to make sure and actually that proved to be pretty valuable because everly there's a little speaker at the bottom of that picture what did we learn about that time

not to slice my fingers off because yes once again daddy maybe didn't think through every aspect of the design but that's why you test fit everything as you go along so we use the quarter round to add stability in the corners and one thing that we kind of struggled with was everly wanted this as small as possible the original design is going to be do you remember how how wide in this The original, she wanted it three inches. We ended up going three and a half because just of the width of the speakers. And so when she's talking about this is the inside, these little tiny pieces of quarter rounds, you can kind of maybe see where they would not have fit over

the speaker. So the original plan was run quarter round through that. During the test fit, we realized, uh-oh, we didn't think that part through. So we cut tiny little pieces of quarter round instead. We adjusted the design. We problem solved.

Yeah. So it was designed to be accessible. We could get in and edit it along the way. Anything else you want to talk about with the painting or?

So we did a primer coat, a couple of finished coats. And then also, Everly, in that middle bottom picture, you're drilling. How do you prevent the plywood from drilling?

But that is a bit of a perfectionist, right? We tried to keep the wood from splintering. That is maybe one criticism of the approach was plywood splinters. Maybe not the kindest thing to work with. Had we used something like cardboard or medium-density fiberboard or something that's a little easier to drill, maybe a little more kid-friendly. But also, we were, hopefully this thing lasts a while, so that's why we went with the plywood. It's a little stronger long-term. So the layout and basic soldering. How about I handle the layout and then I'll talk, let you talk soldering. Yeah. So I'll go back to the inside for a second. Essentially you have the two separate systems. The diagram on the

right shows, you know, right side is really, the right side is the audio system, standard 12 volt power. It can actually go up to 18 volt, but we have, Everybody has 12 volt power supplies in their closet. We're no different. That's what we used. We had it free. That part was easy. The power supply for the microcontroller, that's where we used the buck converter to get it down to 5 volts. Then we put a resistor in. Actually, you can tell where I tried to cover up the resistor value because it changed.

Don't use AI because what did AI do to me?

So in technical terms, if you can see there, there's a little

There's a little proto board, a little circuit board that's kind of long and straight up and down sitting next to the Raspberry Pi. That's where we mounted the resistors. And in technical terms, what happened was if you go ask AI, what value of resistor should I use for a standard blue LED given an input voltage of 3.3 volts, which is what the Raspberry Pi pins run at, it will assume that the regular blue LED is about 3.2.

which means you need a very, very free flowing resistor. A 33 ohm resistor was right in the ballpark of what we needed. The problem was after we'd soldered all that, daddy was like, oh, let's use a multimeter and just test some stuff and make sure. Well, it turns out the LEDs we had were not 3.24 voltage at all. They were like 2.75. And so if you use a resistor with that little resistance, to risk one of just overpowering the LED and burning it out, but also the bigger problem we had, I mentioned the power budget on that Raspberry Pi Pico. We can only use 50 milliamps, and if you allow too much current through that LED, it was only going to be like three

or four LEDs could be lit, and then suddenly we'd be out of voltage, and we were going to possibly burn out the Raspberry Pi. So that was a big lesson to us. that you should not trust AI too much and you should go actually take the measurements, do the math. Because actual people brains are a lot better than artificial intelligence. Yeah. So in the box today, there are 100-ohm resistors, soldered nicely to a little circuit board. And in the trash at home, there is a totally separate board with a bunch of 33.

So we'll move on to the next slide. I think we've covered everything here. Oh, soldering.

Daddy's eyes aren't quite as good as they used to be and Eberle has a very steady hand. So her solder joints are quite good now. And then you want to describe the other picture with the LED?

They're just friction fit, especially once we put the paint on there. There's plenty of friction to hold them in. So they're not moving. And then shall we get to the vibe code? This is really her brainchild. She can vibe code quite well.

The first slide is just where we start. So this is, Evely came up with this prompt. Those are her words. We even, somewhere up here, I had this little Raspberry Pi Pico pinout card. So if you look at the diagram, you can see the pins we're connected to. So that's how she knew GP0, GP15. So she puts it in and spits out some code. And then we have another slide for the next part.

In technical terms, a couple of lessons we had here. First, Copilot's not that good of a coder. If you have access to Quad or ChatGPT, they're a little better than our experience here. Copilot's my favorite AI base. Yeah, Copilot's her favorite, so we use Copilot. But I think what you really see here more than anything is semantics about what is Python. really in both cases, Copilot was trying to use native Python functions that exist in normal Python that don't exist in MicroPython. And so what Python you're using, Copilot got a little confused. And that's really what it came down to. But it happened twice in the exact same way. And the errors look darn near the

same. So at first you... So you barely changed anything? Well, you get mad at Copilot. You're like, why are you repeating

So I will switch for a second. I'm going to take a couple of minutes unless anybody objects because I think we have plenty of time. I'll do a quick live demo just of how we programmed it. We're using Thonny here, which is a really simple development environment. And what are the buttons

While the big one was under construction, we built just a little protoboard. Basically the same thing, Raspberry Pi connected to LEDs, resistors. But this is on something we could test on. And also, if we blew it up, it's a lot easier to rebuild. So the code you just saw her vibe coding is this one called Twinkle.Pi that's up right now. And Everly, what's this duty?

So the original vibe code was 2000 out of a maximum 65,000 in terms of the pulse width. So it took up all that time available and divided it up into chunks. 65,000 chunks of time, it's only providing power 2000 of those. And when we click the go button, you'll see it starts to twinkle, but it's pretty big. And we thought, when we put it on the big one,

We just changed it to 9,000. One valuable lesson to me was the first time we wanted to change it, we went and Vibecoded the change, right? We just said, hey, Copilot, make it brighter. But then the next time it was just like, change one digit, it didn't really matter. So we just changed the digit instead of having Copilot rewrite the whole code. Right. So now we have a human in the loop, right? Because it's not just all Vibecoded. She's starting to learn some of the coding concepts. There is separately, and you'll see it on the main one in a minute, there's a fade code that we ended up liking a lot, which is similar. Let

me see if I can. The fade code is a little more gentle. Yeah, I like it better than the Twinkle code I said. The fade code is what we have on that, right? Yeah. So same concepts, still using pulse width modulation, PWM, to control the brightness, but it's now doing it gradually. Instead of just turning it on at a given brightness, it's ramping up. It's a logarithmic fade. And another thing is in the actual code we're using, it only goes up to 80% max power, and that's partly to stay within that power budget. So that PWM added a lot of flexibility to the design because we could really control how much power is going through the pie. Okay, I will switch this back. the slide show

and we can show. This was the finished piece of half with the wires. So this was the connector thing that is on the back of the box right here, which is what we plug into to give the energy, which connects to that white cord, which connects

flows in from this metal plate up to the power switch. And when we did it we had to change a couple things because occasionally we'd have one that we put the positive wire on the negative point and vice versa. Yeah. So LEDs are sensitive to polarity. And so daddy being fat fingered, you know, accidentally connected the wrong one to another.

Somebody stop for a snack break. Totally reasonable. I need some sugar to keep me awake. Thanks, kid. Anyway, the power distribution, it goes from the switch down to at the top left here is where that buck converter is. There's power terminals on the buck converter, so the power comes into that. And then from there, it gets straight off the terminals on the buck converter. Some of it runs to the amplifier. Some of it runs to the Raspberry Pi. So that is the design that is the construction. Um,

can I show how it works? Yeah. Okay. I can put the back to be perfect. It needs to be perfect. It's gotta be perfect. Okay. Anything else you want to tell them about the design? What was the hardest part?

And how

much did you pay for that primer?

Once again, most of this was just built with spare parts. Yeah, I don't know where we got that thing. That was like five-year-old primer with like a quarter can worth. It's really not much, but it was enough. Okay, back's on. You ready to do the honors? I'll let you flip the switch. Okay. Okay. Power is plugged in. Let me get the microphone over here. My tooth has a little...

Right now the volume's at five of at least 25. This thing gets very loud, if need be. But again, that wasn't the purpose, right? It's supposed to be all made. And then Daddy wants us to possibly do the tenor system transition with that one, right? Since we had the SD card with us. Okay. And you know what? I've already mentioned it, so I want to show. So...

a very unfortunate surprise. Yeah, briefly, if that's okay.

Exactly. So I was going to do this as a surprise. You can go ahead and click play.

So right as Daddy was doing the big reveal and, hey, I got Taylor Swift music and she didn't know about it and she's going to jam out in the garage and Daddy's going to do his weird little dance. A mouse was in the garage and somebody freaked out and ran off. And then he finds out it's a mouse and he stays out there for another half hour trying to get it out of the corner of the garage and whacking it with the broom. Okay. How about you play some Taylor Swift? Yeah.

We need to do the dance party. This thing's got plenty of volume. Okay. We should probably pause for some questions. Hit the switch. Okay. Any questions? So, one thing I don't understand. So, you have to change the other card. So, what is the

Bluetooth?

So, the Bluetooth, we ended up using SD cards just for convenience, but it does have Bluetooth, you just have to switch the input.

In this picture, you can see it's a small pair of wires from each LED, but one of the challenges, if we were to do it over again, we might think about making the strip headers a little different because trying to wire up 16 individual LEDs on a tiny strip header that's the size of the end of the... It's easy for me because I have small fingers. Yeah, but ham-fisted daddy was... That was a little bit of a challenge. For you, that was... Yeah, well that's when she peaced out to get some ice cream as daddy's like, you know, hanging out. You had me fix you an ice cream. Okay, maybe, maybe a little bit. Okay,

any more questions?

The full range speaker does the low frequencies and we ended up not doing the passive radiator. So that's where all the bass is coming from. It's not super bass heavy.

Thank you all for attending and we'll be around.

Thank you guys for attending.

I run into this all the time. I ask co-pilot to do something that's like, I can't do that. And so I change my wording, and I change my wording, and I change my wording. So are you signaling that?

You know, pay, salary. So I keep changing the wording, and the wording, and the wording. And do I eventually get to it because I've changed the word? Did I ask AI, how would you word this to circumvent it? Right? And so you can start to set up those signals as well. So then you're being alerted so that it's beyond what your user is asking. It's also going to the point of how often they're trying to do something. Are they getting feedback from the environment? That's something you'll probably have to build up a little bit more, starting small, building up from there, building up piece by piece. And go ahead.

So auto labeling is a time save. So I'm not gonna say auto labeling is going to match it perfectly. Like if I go into my sensitive information types in here, it's gonna tell me I have some crazy disease number in there that I definitely do not, right? Aragon doesn't care about that. But if your auto labeling is set up, regular expressions are a little bit easier, right? Because like a credit card number is very easy. I mean, if I open up a Word document, I go into this and I new word document. I can apply it. I have a general label set for everybody automatically. If I go into

mouse freezing. No, we'll just copy out one of these ones. If you paste it through here, even though I already downgraded this one, take the same information and I paste it through here. Your users typically know that it's sensitive information. The system doesn't always recognize that it's the right sensitive information. So auto labeling will save you in that sense that it will do it right. I just automatically apply that's confidential. If you have questions, reach out to 867-5309. So if you're going through and you know what sensitive information they're working on, a banking is perfect, right? They're working with routing numbers. They're working with credit card numbers. They're working with account numbers, things like that. Those are easy. It's when you start to come up with

code project names, project fellowship, right? Then all of a sudden, you're labeling based on that, and you're starting to do that. And now all of a sudden, fellowship or project was mentioned in another document. And so now your user has to downgrade it. But if you put your business justification, and you're going through your compliance portal, you should be able to view why they downgraded the label. downgrade it because I just put because there and now I can verify with them

That's right. And I used to see this all the time. I don't really see it anymore. But there's like, if you just draw like a line and two arrows, it's usually security and convenience on the opposite side, right? So something super secure is very inconvenient. Something super convenient is not very secure. So when you're looking at your end users and you're looking at different groups, right? Every group is going to access data differently and every group is also going to have different access. Starting with your high hitters that are accessing the most sense of information, yeah, you might piss them off because you're locking down data, but you're more secure because you're locking down the

data. Training your end users on how to safely handle that data is probably the largest part of it, right? Because no matter how much you lock it down, if they get mad and they start to try to find ways to circumvent it because this is too secure and I want convenience, they will find a way. It's like, this is my favorite. It's like every time I talk with a client, they're like, well, this is secure, but what if I take a phone and just take a photo of it? And I'm like, well, yeah. I can't stop the phone. I mean, unless you did like pull, send, give them the phone or do like a, boxes

where they have to drop the phone off, right? So there's always kind of risk to it. If you're so locked down that you don't even want them taking a photo with the phone, well then you probably are not as worried about general AI because you're probably not just allowing it inside the environment, right? You're probably at a completely different level of, you know, you're going through security, you can't have your phone with you, you can't access this data, it's completely locked down. I worked for the DOE for a little bit and the guy plugged a USB in and as fast as that happened, right? It's like, okay, so depending on how you want that data

security, right? Stage rollouts will help, but usually if you can find that data that they're accessing and you can find out what they're doing with the data, you can usually find a happier middle ground. It usually is happier for them than the security side, right, because it's going to still be less secure, but something that's at least pushing some policies and you have some granular control and you are limiting transfer to your bring your own device into an environment, things like that. I have a follow-up question. Yeah. Mm-hmm.

I think for the most part, people are figuring that out. So we have some people that are allowing everything and right now, well we find out what the users are doing. Then you have others that just goes to leadership and leadership decides. Like this is all we're doing, this is what we're doing. And then they implement that one. And then they start to block the other ones. Firewall, DNS, everything like that.

Thank you.

And that's a perfect talking point, because you said it has to filter through something. If your users are able to access data on their own bring your own device off my laptop that has absolutely no control, that's a completely different conversation. Because now it doesn't matter what protections you have filtering through something, because if you're just allowing them to access their OneDrive cloud stuff, a personal device that has no care about what kind of policy you have, then you're already set for, it's an entirely different topic, right? Now you need conditional access and you need to monitor this and you need to block this and it has to be compliant based on it. But people are still at that point too. People still are hybrid and bringing your own

device and allowing users to interact some way or another, right? So I think it's something that we're just gonna be constantly evolving. Go ahead.

See?

Exactly. Yep, exactly. Contain them as much as you can. Go ahead.

I think every organization is going to have to do it differently, because everyone has their own policies. Everyone has their own how users are interacting with data and where the data is uploaded. So I don't think it's something that can easily be replicated. Obviously, there's just the higher best practices. Understand your data so that you know what to protect. How do your users access the data? Do they need to be authenticated? Do they need this? Do they need this? And then you can start to build up the architecture. As you're working through it, you'll always find users have random data that you didn't know they had access to. Yep.

Will it redact? I don't know. I don't know how that one might work, right? If you start to, I mean, I think that's I know that's one of the OWASP top tens is when you start to adjust its priorities and then change its priorities and kind of manipulate that, it might have some interesting. I haven't had any success. I did this learn prompting thing, which was like an older version of some of the chat GPT where you could manipulate that. I think it's getting better. But then we'll probably come up with a new novel attack that can manipulate data in a separate fashion. where they don't necessarily go through let me create a puzzle for for the AI to understand and comprehend to accidentally output information so

what good question I'm sure I could do some testing okay yep

unless you're reacting it at the data, redacting it at the data level, right? When it first gets saved and you've already redacted it, right? That might be, but then you wouldn't ever be able to access the data unless you had some sort of, it would be, it's like a never ending cycle, right? So it's a good way to think about though. Perfect. Well, that was my whole presentation. So if you have any other questions, let me know. Thank you.

lunchtime.

I have about 30 slides to go. I'll raise the curiosity and not put you to sleep. But let's make it interactive. If you have any questions, you can stop me at any point in time, ask the question. We can have the day long. So again, a brief intro. I am Sandeep, I've been managing vulnerability management

and honestly it feels like

I'm going through this endless game of staying ahead of attackers, especially in the vulnerability management space. And today I will take you through the behind the scenes of what it takes for us to outpace the attackers, especially in the AI-driven landscape. Having said, let's kick off with an agenda. We'll talk about the problem space. I have some interesting quiz for you all. And we talk about what does this traditional patching cycle look like and how it is, there is a very much need for us to like think beyond traditional patching. That's when we introduce the solution space and talk about a closer, take a closer look at AI-powered vulnerability management. we look at triage and remediation workflows and see how we are changing the

direction towards more automation using AI. And then we talk about some of the case studies and projections using, when I apply this workflow, what kind of benefits I'm actually seeing, right? And wrap it up with, how can we be better prepared with everything that we see? So let me introduce a fictional character. This is AI generated.

This guy is like James, right? So he is one of the security engineers in the Fortune 500 companies. He walks into the office, takes his coffee, and he sees, you know, emails are just flooded, and his alerts are just going everywhere, like the page of duty, the phone is going off. Very soon he realizes that, hey, security vulnerability has been, which is used primarily in the file transfer software, weaponized overnight. Now he has more than like 100 different systems that he needs to patch.

That's a very tricky situation. That's exactly what happened with the move it breached a couple of years back. Now how can, this talk is primarily focused on how can James be set up for success and be motivated to come into work and he is constantly like outpacing the attackers.

One quiz, how many vulnerabilities you think appear every day, like discovered every day? Just take a random guess. 1,000, 500?

OK. That's far more worse than what it is. But 131

new vulnerabilities. This is actually a staggering number, right? If you really think about it, by the time I end this talk, five vulnerabilities discovered somewhere that are not necessarily weaponized and exploited, but they are discovered. They know there is a weakness in the system. Interesting stat before I ask this question. You can see this question though, right? But you all use assisted AI tools for your coding on a day-to-day basis, right? Raise hands. How many of you use it? Yeah, I see like good 50%. when you go to engineering side of it, there's 80% of engineers on a day-to-day basis use some sort of AI system, be it cursor, cloud code, GPT 4.5, all sorts of tools. They are like making engineers life way better. But guess

what? All these AI tools are trained on the code that was written by the human in the last decade, right? means is the code has a lot of vulnerabilities. Unless and until you have some secure guardrails on instructing AI, hey, this is how you should generate my code. These are my guardrails. These are enterprise-specific guardrails. These are code standards that you're establishing. AI is just spitting out information, whatever it learned. So now the question, what percent of AI code contains security vulnerabilities? I gave you enough context. You know, situation's bad, but don't say 80%, 90%, that's too bad. What do you think? 50. Any other guess? 70%. 70%.

You're pretty close. 45%, right, of the code that is generated by AI has some sort of vulnerabilities. Now, why is this a problem, right? Again, there might be a question you might have, like, what about humans, right? They write code. percentage of their core has some vulnerabilities, right? Maybe it's 45%, right? Situation's not like any different. But the problem is, we are talking about AI as a force multiplier. What does it mean? It is generating core at the next pace. You're talking about a startup that has gone from ideation to, I don't know, maybe launch in two months. How is it possible? It is able to generate the core at a faster pace. All you need to do is just

give a prompt and go through the PRD, design, implementation, everything happens in a week, right? Pace is a problem, right? Even though the percentage is the same, the pace is a problem. Now let's turn tables. As a security engineer, this is what matters to us, right? What is the average time to patch a critical vulnerability? Critical vulnerability is very relative term. A vulnerability that matters to your enterprise, to your company. How long will it take for a typical organization to patch, or a security organization to patch a critical vulnerability? 90 days. 90 days? 70 days.

Again. You definitely have seen the worse, right? Critical, there's of emphasis on it, right? There's all hands on the deck situation, there's a firefighting mode, but still, depending on the footprint of that vulnerability in the organization, it can take at least up to 48 hours. And this is the stat I'm getting from some of the research that I've seen. And 72% of the organizations kind of, you know, meet this. So this is more than 48 hours. The minimum is 48 hours, but it could be 70 days, 80 days, when you have that kind of posture for Now, let's look at what traditional vulnerability management lifecycle looks like, right? This is not a new problem. This is a decade-old problem, right? We have been talking about vulnerability management

for many, many years now, right? It starts with a scan where you need to have your scanners in various shapes and forms

infrastructure scanners, your cloud scanners, whatnot, right? You have all of that. And they look for weakness in the system, right? And they produce huge number of vulnerabilities that are out there, matching it to the public databases and whatnot, right? And they provide a CVSS core, all the good stuff for us to like assess and prioritize. And the next in the daughter is triage, right? What happens in the triage stage? at these thousands of vulnerabilities and what vulnerabilities matter to me the most, right? What should I fix? That's the triage process, right? This is very enterprise context driven because you cannot, this is not like a silver bullet that works for every organization. Hey, I have this triage process, let me hook it up. Hey, this vendor is telling me

they have this wonderfully built AI tool for this. No, it to have a lot of enterprise context yes there could be a workflow we'll talk about it in other future slides the last one is the patching which is the real painful process right this is where engineer security engineers have least amount of control that means you need to have an influence you need to talk to them in a language that they understand and come to some sort of a middle ground hey this is important because of these many reasons and that's a long journey right that's exactly

I'll be kind of walking through kind of establishing that workflow, how to simplify that. So what are the gaps, right? You have seen traditional vulnerability management scanners, they give vulnerabilities, weakness in the systems with some CVSS scores, right? The CVSS scores can range from anywhere from like lowest to the highest of 9.8. But a critical vulnerability with 9.8 score might not mean as much because that asset where that CVE is discovered is just deeply buried into your defenses right there's like you count like seven seven layers of defense that you have on top of that asset but whereas there is a CVE that is 7.5 which is considered kind of high sort of high medium is

out there on an asset which is publicly available, it is available for anybody to access. That is more important, right? So that's where the business context enrichment is very, very important. Manual scoring will not work. And when you look at this problem as more reactive space, right? Hey, I see the vulnerabilities. Let me go the traditional route, analyzing the vulnerabilities, yeah, it's fixed. reactive approach, right? Especially in this age of, and the pace of the vulnerabilities are growing, if you are taking a reactive approach, that's not good enough.

So we have seen how these vulnerabilities are actually like growing, like what is the, at what pace they're growing, and what is the reason behind that. So let's look at what is the biggest contributor and why organizations are dealing with a huge technical debt when it comes to vulnerabilities, right? End of life software, right? I'm pretty sure you must have heard about this, right? In every organization. What this really means is you are, you are using some software and it is deeply like rooted into your way of doing business. Now, suddenly if it is an open source, Most of the companies they use open source, they say, hey, we are stopping the support for this version. Even for the

enterprise versions, they stop support after a couple of years. So that means you need to constantly invest on upgrades of the software throughout the year. But there is a lot of, let me go to the next slide.

Depending on how that software is ingrained into your infrastructure, take anywhere from 12 months to 24 months, in some cases even longer. There could be shorter upgrade cycles as well for a simple software. But the complex one is anywhere from year to two years, depending on how deeply rooted that in your ecosystem. And there's talk about compatibility barriers. You have this legacy software that just runs on this particular OS. There's no way it can run on any other OS. The moment you touch this, it's gonna blow up. And you don't want to touch that. That's your core processing engine, business value generator that's been there for decades, right? So all of this kind of creates what? An operational inertia. And it gives us the

mentality, hey, if it's not broken, why should I even touch it? Give me a good reason, right? We talk about security breach, let's see when that happens, right? That could be a response from your leaderships.

The end result is like you have huge number of unpatched vulnerabilities that you're just sitting on and there is limited visibility because obviously from a noise tuning you might say, hey scanner just don't scan this guy, right? I know there are problems in this. I know you will give me like bunch of vulnerabilities from the system but I'm not gonna act on it. So it'll just create massive blind spots. And the result? they are the potential entry points for your attackers to get into their network and laterally move, leveraging those vulnerabilities.

This is where, right? This is the problem, right? Now, we'll move on to, like, discussing how we need to think beyond patching and establish a strategic discipline to address the problem that we have just discussed.

So, I'm pretty sure you guys, there are so many talks that talk about AI, not just this conference, you just go to any conference. If you count number of times people say AI, I think it will be very tiring. But that's where the future is, right? We need to leverage where we are going. We need to leverage AI to make it better and sustainable.

stages that we spoke about comprehensive scanning there are the scanning is the one that has matured a lot over the years right the the scanners are super sophisticated if you talk about take any cloud security tool the scanners are like super super sophisticated you take this orca prisma from palo alto they have like super sophisticated scanners very optimized that can run daily and give you what footprint what vulnerabilities you have all of that but when it comes to triage yes there are the same cloud security tools are able to provide based on the network exposure factor of your asset they will tell you whether that cve is critical or not but i would say it is not 100

there you still need to do some work we'll talk about that how that workflow will look like and the problem this the remediation that there's no solution yet, right? At least I haven't seen one that runs at scale and be able to run with any enterprise context. That's where AI will make a lot of difference. I'll talk about that. So what is this, like, you know, from a remediation standpoint, from a triad standpoint?

What is the shift? What is the mindset shift? What is the culture shift? Usually what happens in the vulnerability management is there's a lot of friction. You're talking to engineers, they have much bigger problem to solve. They are working for a business value generation. They are investing in whatever they are measured against. When you go talk to them, hey, this vulnerability is there. Can you please patch it? No, man. I have this stuff to do. we need to talk about next quarter, next quarter. That's just the constant game that we need to play. So there's always this friction, right? We need to create the space for a lot of innovation and less toil, right? And this kind of inducing the psychological shift on

let's move from reactive where people are challenged to go fix it to very shift left to be more proactive, kind of incorporate in their workflows.

So you might be thinking, okay, if AI is doing everything, is that trustworthy? Can I just like unleash AI and go fix everything? Is that a trustworthy thing to do? No. That's where we need to meet halfway or even beyond to generate some sort of trust and human is still in the loop to do the final checks and balances before it pushes through the ecosystem, right?

talk about AI power triage right now on a very high level you have you you have an AI engine that requires some sort of inputs right first to the scan data we spoke about scanners they're pretty good at generating the scan data vulnerabilities are there it gives you all that input now you provide whatever business metadata that you can which will talk about in the next stage. And a lot of, there's a lot of threat in teleporter, like about vulnerabilities, how they have been exploited, and you can pair it up with a lot of internal telemetry. All of that can be fed into AI, and it'll give you much, the contextualized, prioritized findings, right? How, we'll see that in a very detailed

slide here. So you have your, the signals right you you you provide your enterprise risk policies guidelines I'm pretty sure every organization should have hey I have these policies right for endpoint security these are the policies for infrastructure security these are the policies you have guidelines and you have all that established that becomes a critical input and you also provide the scan data that is that is given by your scanners integrate that with the threat intel which is basically available from key exploitable vulnerabilities from SESA and your EPS score exploit predictions score system and you have a lot of exploit DBs open source and more importantly when you're using this renewed cloud security tools they have a lot of

customer data right to see what are actually being remediated, where is the lot of chatter, right? So they'll be able to provide that kind of feed as well. Now you enrich the CMDB data on top of it, which is very critical. What is CMDB data? Just so that you all, maybe you all see it in a different forms and shapes. It's more like, what is this asset? What kind of data this asset has? What is the classification of the data? All of the good stuff, right? So mature organizations, especially like FinTech, they start with CMDB process as a first thing that they need to do, where right from the asset creation, it needs to have all the data before the asset

is actually put into production. So some of the mature organizations have a lot of good CMDB data. That needs to be passed into the Fusion engine. Now, what really happens, like how this Fusion engine is the data, it takes in all the data and now it will give you the prioritized, fully contextualized generating the rationales on why it thinks this vulnerability is important for you to fix, right?

That's very important. And what happens after that, right? You need to basically do some sort of automation. You hook the data into your ticketing system, establish the business owner who's basically on the hook to fix this vulnerability, you drive all that automation. So this is kind of, you know, you have inputs, you have processing engine, and you have outputs. This is kind of a mockup that kind of I developed as a POC at my company, which is kind of, you know, in the phase of rolled out in production. So this, gives a lot of interesting details. You have total vulnerabilities discovered from a triage process, like 2470, and how many are prioritized? 20, which is like what? 0.1% of the

vulnerabilities are prioritized as critical and high because of all the data that was fed into the fusion engine. resolution time is just like a made-up number i don't there's no way there's average resolution number 6.2 so but ai accuracy is something that it's very important right like when ai says this is a high this is critical how accurate is that data is that trustworthy we establish a feedback loop when the ticket is given to the engineer and he rates hey yes this package is there on system and yes this asset this vulnerability is discovered has critical data. So there is some feedback loop that is established using which we predict what is the AI accuracy rate here.

When it says it is high critical, is it indeed that we are not? And then you can see on the top, I don't know if you can read it or not, but you have this AI generated rationale, right? Like it talks about why this vulnerability is important. It tells you like, hey, critical asset handling PII exploit in the wild, the asset is exposed to internet with high EPS score. That's a good explanation that engineers can see and understand. It can be a lot more enterprise-rich context, but I did not show it here for obvious reasons. Now, let's move on to sort of unexplored territory. I'm pretty sure some of you have already seen the fully automated triage process.

So this remediation process, right? What can we do, especially using AI? Just to kind of take a step back, what are the various platforms where we see these vulnerabilities? Maybe we can crowdsource it. Where are you seeing these vulnerabilities? Can you say, like code, I can give you an example. your container images, that means packages that you use in your container images, they play a significant role. What others? You have your misconfigurations in the cloud, right? Where you misconfigure EC2 or a compute engine exposed to internet. You have your storage bucket just open to internet, which is supposed to be closed down. All of those are kind of what we are talking about, right? So that you have a mental picture of, okay, I understand this workflow,

but where is it fitting actually, right? So let's take a simple example of code and walk you through this workflow. The first one is, we have already seen it, there is a scanner that is giving you a bunch of vulnerabilities. And we have already discussed about the fusion engine, which is giving you the prioritized vulnerabilities. Now, I don't know how much you have on what MCP is, is a model context protocol. Now, model context protocol is kind of, you know, if you are following the developments in the generative AI space, maybe six months back, people used to have this whole rag, right, to enrich LLM with enterprise context. Now, Anthropic has introduced something called MCP, MCP's model context protocol.

Just to dumb it down, it's for you to feed or expose some of your enterprise capabilities to the LLM. Simple example, right? I want to get top vulnerabilities. Can you give me what are the top vulnerabilities that I need to focus on to LLM? How does it know? There's no way to know that, hey, this particular organization, ABC Corp, where should I go? I don't know. So MCP is a way to provide the context where MCP says, I have some tools available. It'll tell you if somebody asks vulnerabilities, get me top 10, I have some APIs exposed. You just route that information through me. But user is completely abstracted through that, right? So that's a quick kind of

context on what MCP is. So tying back to like how MCP plays a role here, you have your MCP that's like an API that is developed. That API is exposing these, which tells you like, hey, these are the prioritized vulnerabilities that I need to fix and all of that stuff, right? Now, in your workflow, you hook that process and then you move to your GitHub. That also exposes some MCPs saying that, hey, I have this vulnerability. Now, what is the repo that maps to this vulnerability? So it can provide the repository information and also exposes some sort of PR webhooks, right? So a few YPR webhooks kind of make sense here. The third is like a very important thing.

This is where the actual, you know, overall the brain behind the workflow is. Now the generative AI has two key inputs. It has prioritized vulnerabilities that it will fix, and it also has the repository information on where this fix needs to go. Now, AI can... information and also like talk to the cloud security NCPs they know they kind of provide how do I fix these vulnerabilities they provide that context as well it's not just a vulnerability how do I fix the vulnerability taking the context it'll just generate the code and which can be opened as a PR on the repo so the webhook functionality that was exposed from the github is leveraged by AI to open

a port request against the GitHub repo. Now, that's interesting. Now, what happens beyond that? This is where the fun starts. PR is open. That's not good enough for developers. There are a bunch of PRs that they can open, and they can just sit there for decades. I need to basically hook into the validation pipeline, automated testing. Mature organizations, they kind of enforce every repo should have some sort of unit test, integration test, whatnot, right? But legacy code, there's a bunch of legacy code. There is nothing like that, right? So this is where AI can play a role. It can use the existing test suites and run the PR and make sure everything is fine. It runs fine and it

can deploy that in a sandbox environment to make sure everything is good to go. But if the automated test suite is not available, cloud code it can just generate fantastic unit tests for you looking at the code so it does those things as well that means you are not so think of it this way prior to this you are having an open dialogue hey I have this 10 vulnerabilities to fix to your engineering team can you go fix it what is this vulnerability about oh this is this package that you're using you need to upgrade the package

response that you guys I don't know man like you know if I upgrade the package now I need to deal with the incompatibilities the bugs that I need to face the it's just unknown factor now now that is shifting into something like don't worry about it I did all that for you test run fine you didn't deserve great here is the result all you need to do is review the PR and make sure if there is anything else that you're concerned about make performance does, right? If that is not automated, maybe you can spend time on that. You don't have to spend time on anything else. That's where we are kind of meeting in the half, halfway or even beyond in some cases.

That's where the friction is reduced by multi-fold and it's an easy conversion for you to have on the prioritized vulnerabilities. And the last one, yes, with all this data, now service owner has

basically equipped to take these decisions like a much informed decision but still move at a faster pace so that he's focusing on what he's measured on, right, the business value that he's generating and whereas security engineers are fixing the vulnerabilities. It's a win-win proposition. I'll not spend a lot of time on this but this is very important. There's a change of flavor in how we deal with vulnerabilities, right, or misconfigurations on your cloud. How is that happening? Today what happens typically you have your servers, they need to be patched regularly. How are you patching them? You identify, hey, the server needs to be patched like from a minor version. If you're using a Rocky or Red Hat or anything, it needs

to be minor upgrade because it has these many vulnerabilities. That's what your platform engineering team gets as an input. Now, same saga right why should i upgrade it it might break my existing systems and stuff like that now this is where ai can go beyond and look at

what is the optimal time for me to do the upgrades it look at the telemetry and the system data historically like last one month it'll see all of that and you'll find out okay on a Sunday evening is the best thing to do because that's my low traffic zone. If something happens, the risk is minimal. All of that is just automated, right? You don't have to say anything. You just need to say, hey, this vulnerability needs to be fixed or this patch needs to be executed. It'll figure out using all the data that is there and come up with... All of this used to happen even before, but human is doing that, right? But when human is there,

there's a lot of data that human also needs to analyze. There's a lot of time spent first, but it could be subject to error. They might have missed some data, critical data points. Yeah, every Sunday at 10 p.m. I fix this. So the volume my system receives is very low, low risk. But guess what? The Sunday that you pick has a marketing campaign, right? So something like that. So that's a new data point. So AI will train on all of that. You can just train train on the data for the last six months to be sure so that it is picking the right schedules. And then it can generate your ITS integrative with ServiceNow, Jira, and it will route it for approvals, all the good stuff, right? And

at the end, you have your agent-based deployment. What that means is you have your Cloud Security MCP tools. They know exactly what needs to happen when the patch is going into a server or a cloud-native service or whatever it is, right?

Most of the systems today are easy to deploy into a sandbox. That's an investment that everybody needs to make where you need to have a sandbox environment where AI can use it as a playground to test some of these automation.

So if you're wondering, oh, this is just too much, man. I don't know where to start. You've explained a lot of things. I don't know where to start. If you are following the news, AI has released, if I'm saying this right, Aardwalk. This is like a cyber, this is for cyber defenders, right? If you look at this, this is a snippet I got from their announcement. It was launched a couple of days. Yeah. We have seen mostly like, you know, the code is already there in production. Vulnerabilities are there. I'm fixing it. I'm using AI remediation wonderful but how can I plug this whole thing kind of shift left and make it better with AI right so I don't know how much of how many of

you use cloud code or cursor or windsurf for your daily coding needs today enterprises right are

letting people explore that. This is where it kind of ties back to my original question, what percentage of code has some sort of vulnerabilities, right? How can you make that better so that you are not suffering with whatever damage control that you need to do by fixing the vulnerabilities, right? That's an important thing. These AI-assisted tools have something called rules that you can configure, right? Rules are like, you know, Cursor provides rules, Codo provides a lot of rules, Codo is like a GitHub webhook functionality that you can just hook right into the PR review and all of that. Those rules kind of provide the guardrails against how you need to think about secure coding that is very specific to your organization, right? At my company, we have

gone beyond and did something like this, right? I have this not-star...

When I say initiative, that's a GitHub project. Northstar in the sense, everything that is there, how it interacts with Kafka, how it interacts with secret management system. Everything is like a pattern and it is reviewed and approved by security engineers. Now, all I need to say is, hey, when you're doing anything like that, this is the model project that you need to look at and see if there is an adrift. That's it, simple. You don't have to train with 100 different rules saying that, hey, if somebody's opening of connection make sure it is closed if you are opening an external connection make sure it is approved basically it list is endless it is very very

difficult for you to get through that list right so that's why building some sort of guard rails into your AI assisted coding tools is very very important so that you are able to stop most of these vulnerabilities kind of getting through your ecosystem right

case studies on what this all means, right? Yes, we have spoken about a lot of this automation. Is it adding value really? Is it all, it's just theory, right? We have done this on some of our repositories.

There is this aggressive remediation. Just go hunt for vulnerabilities, just fix all of them, right? We are able to like fix 97% of those vulnerabilities that way, but I wouldn't recommend anything like this go you cannot take this approach that's where you need to look at conservative which is a big win too which is you know getting through these vulnerabilities like 40 percentage that's a good start you understand how the system is behaving what are the bottlenecks where it is choking take baby steps and then you can improve on top of it and again the north star goal is to get into the aggressive remediation so that you're reducing your footprints yeah

So if you're starting here, that's the problem. It must be crazy. It is crazy. It is crazy. We have seen it. There's a lot of regression. We had to do a lot of damage control. And we haven't done this on any critical repository. We have done this on a tier three application, which is mostly running behind the scenes. There's no business impact. That's where we run this. But. I mean, this sounds like the most secure system that nobody wants to. Yes. So this kind of projection, if you have one million CVEs, the graph is huge, right? Like you're coming from one million to 600K vulnerabilities just by using this automated workflows. It's like almost no

touch, right? When you're looking at conservative approaches. So how can we prepare? We, as we are contextualizing this whole thing with AI at a very fast pace, maintaining the human oversight is extremely important. That's where the real challenge is. We can get too comfortable with the workflow that is established and hey, everything is good, nothing is breaking, let me just snooze for a little bit. Hey, just take over and just ruin everything, right? There is a high possibility of that happening. So until you build that rigor, you need to have checks and balances and guardrails in place and make sure your workflows are fully tested and gain their trust on how and where human needs to be hooked in.

And constantly generate the velocity improvements. It's not just, hey, I'm deploying this fancy, completely automated remediation processes, but you need to verify, like you said, regression, how much time we are spending on regression, the overall time spent, we need to look at this from a macro perspective and come up with real-time dashboards on value generated. Like, how many are saved. It's not just security engineers. Like I said, this is a win-win proposition. You have your engineers talking about this, raving about it because they are doing stuff that matters to them. Now, what is the total time saved? Project it in your leadership dashboards. Let the value be realized. Do a reality check and make sure it is indeed

worth the investment. Remember this guy who was It's sad, AI gave me a different picture, right? Don't worry about it. This is not the same person. But this person, now he's just walking into the room. Yes, there's a zero-day vulnerability. I understand, but I got it under check. He just opens the vulnerability dashboard. He looks at the impact of the vulnerability, how many assets are there. He is just on a button click. He's opening a PR, let the test run through fine. he is just messaging these engineers, hey, these PRs are there. You have 24 hours to just review and click a button to accept it. I might be overstating it, but that is definitely possible in the near future. I think that's all I have. Thank

you so much. Any questions?

So the accuracy rate that was projected in the dashboard, it is coming from a feedback loop that is coming from engineers. We have provided some sort of feedback that users can provide whenever they're acknowledging a ticket to be resolved, or a PR to be resolved. Where they classify, okay, we provide some data like, hey, this asset seems to have PII information. he's exposed to internet, he has to explicitly acknowledge all of the checkboxes, so the feedback is kind of looped back into the system. That gives you good estimation on false positives, right? False negatives is a thing, right? Nobody's like, you know, AI has ignored some vulnerabilities, it has somehow thought, based on the data that is provided,

the vulnerability is not so critical, yeah, it is 9.8, 9.8, but it is not as critical let me just pull it behind the scenes right the false negative we are still working on it right that's why I'm not that's what that's why it is very important for security engineers to be still involved in the process look at the highest rated CVEs and provide that feedback manually to the AI system so the false positives yes the closed loop but the false negatives is where we still need to have some human oversight in the system

All right. Thank you so much for your time. And if you have any questions, you can chat with me offline as well. Thank you.

That's actually an excellent intro because in short, I think it's absolute bullshit that I need to go pay $150,000 for this knowledge and education. And I don't think y'all should have to, so I'm taking what I've learned that I find interesting and coming back and giving it to y'all. And how much did you pay for this conference? Zero. Yeah, so it's free. Huh? Just your sanity. That's different here. You're contributing. All right, yeah, so hi, I'm Jason.

Today we're gonna talk about process optimization, specifically business processes. I had a class that I took over the summer called, I don't remember, Operations Management. Yeah, there we go. I passed. That's all that matters, right? It was called Operation Management and they'd slap on four executives on the end because it's an executive MBA so they can charge us more money. But yeah, it's basically how you measure the flow of work through a team, through people, and how you go about optimizing those. Now for a disclaimer, all the material presented here is all of my own opinion. I will reference certain things from school. Anything that's copyright, I'm gonna talk about. I'm not a doctor, this is not medical advice, I'm not a lawyer,

this is not legal advice, I'm not a financial advisor, this is not financial advice. All that bullshit. Here we go. Who am I? We're gonna talk about that. The class I took, BA 6230, in case any of you find this super interesting and wanna go take the class, or maybe request What's that document they give you at the beginning? Not a transcript, that's at the end. What's the thing that tells you what they're gonna tell you about in the class? Syllabus. Syllabus, thank you. So you can go request a syllabus and go steal all the information open source style, the way Phil Wiley taught you to become a pentester. We're gonna talk about the goal, which is the main book, the text for this class. Fantastic

book, highly recommend. And then we're also gonna talk about the Phoenix Project, which is what, you read the goal? Goal and Phoenix Projects? Cool. So when I'm done here, we're just gonna tell you all the things I told you that I don't know. Both of these are fantastic books, highly recommend it. And then we're gonna delve into next steps, things that are beyond the class and those books. And this is the part where I want your feedback. Maybe not now, maybe now, if you have ideas now, I'll take them. Otherwise, come find me when the idea strikes you a week or two from now. I think there are a lot of really cool things here that we can take and apply to stuff that

we do specifically in IT and cybersecurity. So we'll talk about that. All right, who am I? Most of y'all know me. But for those of you that don't on the internet, hello, welcome, I'm Jason. I'm doing an Executive Masters of Business Association at the Southern Methodist University down the road. Assuming everything goes as planned, I will graduate in May of 26. courses I fail between now and then, but you know, whatever. Before that, oh no, for the day job, when I'm not at school, I do risk exception work for a large international financial forum, specifically in their information and cybersecurity program. Learning a lot of stuff there, it's my first foray formally into GRC, I've done

a lot of GRC stuff that's related to my other roles that we'll talk about here in a minute, but this has been absolutely fascinating. I was in attack service management for a large critical infrastructure manufacturer where they did not have any cybersecurity before I joined. They hired the first CISO, I was his first external hire, and we built it all from scratch, and now they've got a pretty kick-ass program. Before that, I did senior cybersecurity consultant at one of the big four consultants. These are the groups that you come pay a lot of money to interview your staff and tell you all the things your staff was trying to tell you all along. It's called

plausible deniability. It's a big deal in executive leadership.

Before that I was at a large investment bank. Yeah, doing cybersecurity stuff. I helped with their SAS program. I did their global social engineering program. So I got to fish people in Hong Kong and Tokyo and Poland and all sorts of places. It was a lot of fun. Learned a lot of really interesting things about slight cultural differences when you're fishing all over the place. But that was fun. Before that I did my bachelor's of science in computer engineering at the University of North Texas, also up the road. Hosted us back in what, 2023?

Yeah, I think we were there in 23. Good times. Yeah, so while I was there, my senior design project was with NASA. We did dynamic IPv6 addressing for spacecraft. That was a nightmare. Ask me about it. I'll tell you more about that later. Other than employment and education, I think community involvement is super important. Part of why I'm here talking, giving you all the information that I'm paying a ton of money for. I'm really hoping inflation comes through for me and like all those student loan payments afterwards are like nothing, but we'll see. I'm also the red team lead for the Southwest region of this collegiate cyber defense competition. I have a team of about 30 really badass red teamers and pen

testers that come and work for me every year and help me torment college students. It's a blast. I'm also a board member of the North Texas chapter of the Information Systems Security Association, co-host for DC 215. along with V here. Side note, come out to the after party. We're doing karaoke.

Location's got for B-Side CFW. I helped them find this spot. And I go speak at Dallas Hack Association on occasion. And a bunch of other stuff that I'm sure I'm forgetting. Like I forgot the third period on my ellipsis. Yeah, family karaoke, come out. 7 o'clock, be there. It's gonna be a blast. Oh, they open at 7. I'll be there at 7. We can be there, so. Come hang out. All right, so I'm gonna talk about the class that I took over the summer called Managing Operations, and I chopped it off for executives because this is for everybody. Let's be real. It's just executives are specifically tasked with this. We covered a lot of really interesting material, things I can point you to, public documentations, other

closed case studies that I can tell you about. One of the big things we talked about was Toyota's production system. Everybody talks about this when they're talking about lean systems. The idea is you condense down the system to its most critical components and you tweak it and adjust it. Some of the three key terms and things you need to be aware of with Toyota's production system and how they call that is leveling. That is specifically when you take your average output for the year, your average across the weeks and the months. produce these things specifically in manufacturing. The idea is you know you're going to have ups and downs with your demand, but if you can build out your system so it's producing consistently and constantly, you're

not going to invest in a bunch of extra machinery and inventory and equipment and materials that don't get used certain times of the year. So the idea is you build up that surplus during low demand periods and then you filter it out that way. That's the idea of leveling. Sometimes it works for you, sometimes it doesn't. It's very much a business decision. It depends on what the value of that inventory is that's going through your system. For example, automobiles, right? Kind of expensive to make just one of those, right? So if you have an excess of those for a period of time, that can be a problem. And the problem with that is your capital

dollars are tied up in that inventory until you can sell it. So that's where the just-in-time portion comes in where is you build the thing just in time when it's needed and you build other components as it's just in time for them to be needed to assemble the final product. The entire purpose of this, I know we get into a lot of issues with this, with supply chain, right? We had this during the COVID thing where the whole chip shortage, right? Because everything was just in time manufacturing. And so when there was a sudden splurge in demand, manufacturing couldn't ramp up to keep up with the demand at that point. that bit us in the

butt during that, but the entire purpose there is that less of the company's capital budgeting dollars are tied up during that manufacturing process. So you can think about this as, we'll get into this a little bit later, but we talked about bottlenecks in your assembly process. And so the idea is in every assembly process, or every workflow at all, there is a key component or a key step where that process can only do so much work and things back up behind it and you can't route it to other things because of the way the process is and things get stuck there. The idea being that with just in time manufacturing, those things get there to that bottleneck just as they're needed because the more

backup, the more inventory you have stacked up waiting to be processed by that last critical step, those are dollars that are not being optimally used. that you need to take into consideration. The other one here is Jisuken. I'm gonna mispronounce that, but it's self-learning. That's a big thing with Toyota's process. It's basically hands-on learning. On the job training is what we typically call it, but it's, you can only teach so much in an academic classroom setting. At a certain point, especially with manufacturing, and also here with IT and cybersecurity, you have to get hands on keyboard. You've gotta get a person in front of the thing, doing a thing, so they can learn how that process works. very much how my brain works, right? I can

read all the documentation in the world and it sounds great. But until I get my hands on keyboard and I'm actually doing the process, that's when I find out where the documentation is good enough or not. All right. One of the really cool things that they called out, and I'm very glad they called this out, was specifically these lean processes in the energy sector. So I drew a lot of parallels here to what we do in cybersecurity. The principles we just talked about are absolutely fantastic. But there's certain points in time where optimization gets outweighed by safety. And so one of the concepts was in a nuclear power plant, you don't skimp on your cooling systems.

You don't skimp on your monitoring systems. You don't optimize those things. Because if you optimize too far, you're not going to have adequate monitoring. adequate cooling and at that point you get a meltdown and that's a problem and that's not a problem just for your shareholders that's a problem for everybody and so this same concept is in cybersecurity where there are certain things where cybersecurity should always be there to support the business to enable risk based decisions but there are going to be certain things out there where it doesn't matter this has to be done And that's part of our roles as risk practitioners is evaluating those and knowing where that applies. Where are the things

that we can get by with? And that's what I'm learning right now in my current role is risk exceptions. What are the things that we can adjust and accept the risk for? And what are the things that absolutely have to be done? And that's a huge balance that strikes in it. It's very dependent on the industry sector you're in, the space specific business here in and the risk tolerance of your executives. That's a big part of why I'm doing the MBA is because I'm really good at communicating technical risk to technical people. I've been doing that for about a decade. But what I'm really trying to do is build the skills where I can communicate technical risk in financial terms so that business people can make business decisions. That's

really why IT is there is to support the business to make money. That's why the business is there. Cybersecurity is there to evaluate that risk to do it safely. It really comes down to business decisions on what gets done and what doesn't. So that's where I am. One of the biggest things we learned here in this class was a lot of optimization can be counterintuitive. One of the biggest things we looked at, especially when you look at putting down the numbers of your process flow is sometimes you don't want things running at 100% capacity.

in the book that we talk about in a minute here, but there are times where automation can come back and bite you in the butt because you've automated the wrong things in the wrong order, if that makes sense. I'm a huge fan of optimization. We should optimize whatever we can. At the same time, you have to be judicious with it so you optimize the right things in the right order. And we'll get into that a little bit as we go into the text that we're gonna talk about. And I actually have, We do have a live demo for this as much as we can. So I've got some spreadsheets and stuff that you'll be able

to take a look at. So let's get into the book called The Goal by, I cannot pronounce his name, but the last name is Goldratt. Fantastic book, highly recommend it. It's a really easy read. A lot of this stuff sounds super complex and it can be, but this is written in a very narrative form where it's very much a story. manager who's struggling with process flows and optimizations and they're losing a ton of money and so it goes to the process of how he evaluates those things being new to his role seeing everything with fresh eyes and getting some coaching and mentorship from outside sources which I recommend absolutely so yes

math stuff behind us, don't let it scare you, please go check out the book. It's fantastic. The story follows, I believe his name is Alex, as he runs this plant, but there's some main points that we want to take a look at here.

The key thing is, what is the purpose of a business, right? And I think I said it earlier, but who can tell me what the purpose of a business is? To make money, right? There's a lot of great nonprofits out there that do a lot of great work. to make money, but the purpose of a business, generally speaking, is to make money. I can give you, on one hand, a list of companies that are fantastic that don't exist to make money, but they're actually doing really good social stuff as well. But generally speaking, yes, business exists to make money. And so when you're running that manufacturing plant, in this example behind this book, how do you measure that plant's

contribution to the business making money?

the Socrates method in case you can't tell. I like to ask questions so you do the presentation for me. How does a single plant contribute to a multi-facility business making money? Stockholders? Stockholders supply the initial capital to build the plant. But the way a plant contributes to the profit for a facility is... What the way? Creating inventory. I can create... There exists a scenario where a plant can create more inventory than the marketing team can sell. There also exists a scenario where the plant can make more inventory than society can consume. And that was part of the 2008 collapse where all the big three auto manufacturers made far more automobiles than were being sold. That was a whole... cook the books

situation where they were spreading out their finite costs so you could average the cost of property rental across all these things, make your cost of goods sold look better, make your profit look better, but there were realistically some acceptable reasons they chose to do that, but we can talk about that later. So yes, cranking out inventory is why the business builds the factory, but they make the inventory so it can be sold. So you wanna be careful with how much inventory you do produce. Yeah?

Yeah, so theoretically every company that does any kind of manufacturing should be doing that. Everyone that I am aware of does that. But yes, that's ultimately what they're trying to do is to make sure they're not overproducing. there are risks involved with that with under-producing, right? And that gets into a lot of, believe it or not, this is actually marketing where they're evaluating market demand and how much they think they can produce. And then you get into some supply curves with, you know, if we produce this much, how much can we sell them for? Where's the optimal profit line? But yes, that's on the same line. Ultimately where this story gets is they find out

that they had been pushing things too hard, too fast facility where they were overproducing in some areas and underproducing in other areas. And that gets into identifying your bottlenecks that we talked about a little later. Yeah, there it is. And this happens in the book. There's a story where this plant manager takes his son out on a scouting backpacking trip. And they realize that no matter how efficient the troop of boys is, if you have each of the boys go as fast as they can on the hiking trip, but they're still limited by setting up camp to when the slowest boy arrives. And so what they found out was in that situation, while they were getting to camp, it was looking like they were

gonna get there at 2 a.m. So they took the slowest boy and they said, all right, we're gonna put him in front, we're gonna make him the limiter. Because it doesn't matter how fast everyone else is, we can't do anything until we're all there. And then they took it a step further and they did an analysis of, well this one scout is our bottleneck, how do we optimize it? his backpack and they realize he's got a cast iron frying pan in there. He's also got half of the food and two of the tents. And so they found that because this one scouts the bottleneck, they can take some of that work, work in this case being hauling pounds per foot, and spread it across the team. At

that point, the frying pan has to make it there, right? We can't split it up at all. It's not useful to us in pieces once we get there. of what's the most effective distribution of work across the resources you have and then he goes back to the plant on Monday and he applies this and they find out there's this one heat treatment machine that's the bottleneck and through a bunch of things where like that's the only one in town and things like that they optimize the rest of the workflow around that one point and the idea is you find your bottleneck bottleneck and then you constrain all the rest of the work to that one

bottleneck the idea being should never be waiting for work. That machine should never be non-operable. In this situation, they had a three shift set up at the plant so they could run it around the clock. And they found situations where sometimes the machine wasn't running because the union said those guys had to go take lunch and they couldn't do the setup. So he did the work that you had to do with talking with the people and getting them to be flexible on their lunches and get those rules changed so that they could do that.

parts we get into is continuous improvement because once he optimized that heat treatment machine and it was operational 24-7, they ran into a situation where they found a new bottleneck because these new NSX 10s, they call them, I believe it had something to do with paint curing, became the new bottleneck. And so what they were able to find is despite having sold the previous machine that did the same job, they were able to go piece together a second X10 machine for the paint gearing and help increase the throughput of that particular bottleneck. But ultimately, what they come down to is plant efficiency is measured in throughput of what the products are coming through. Like you

were saying, inventory constrained to how quickly can we sell those things. In the story for the book, they were able to sell everything they could produce. It was a situation where they were underproducing. They were producing less than what could be sold. So this worked out well for them in that situation. to the point where they were so effective they started selling materials and inventory out of country. Once they're to optimize this. But fantastic book, highly recommend. I really love the narrative, the way they tell the story and walk you through it. I listen to it as an audiobook while driving around doing trips. Fantastic, highly recommend. I will say that ever since I read this book over the summer, I've been

sitting here thinking how do we apply all these principles and how do we apply them to cybersecurity?

Yeah. So that's in the book what they did is once they fully optimized the use of their bottlenecks where that heat treat machine was 24 seven and it was never not working. to get enough material through the plant where they were able to meet all their current orders and they actually started selling internationally. Because they were able to increase capacity to that point. Yeah. And actually in that scenario, that gets to the point where some of the counterintuitive stuff, they had gotten everything optimized so much to that point that there were resources sitting there not doing anything. And so they were able to sell internationally at what on paper looks like a loss. It looked

like it cost X dollars to produce Y product. But what they found out is because there were things that were not being used because they were subject to that heat treat plant, they were able to sell it at what looked like lower than cost because of what it changed. And I'm doing a really poor word salad of explaining that. But yes, the short answer is yes. They were able to increase production at that point. Keep in mind it's fiction, right? Like I said, the numbers they present all make sense. And now we're going to do a little bit of a demo. I'm basically giving you one of my homework problems I had over the summer.

This is a case study out of the Kellogg School of Management. This is a surgery center, specifically bariatric surgery. And they give a scenario where they have the surgery center. They believe they're operating at capacity. is if we want to increase profit what step in the process do we need more of do they need to hire another surgeon do they need another anesthesiologist do they need more nurses if so which one do they need to rent a bigger space and if they do is it recovery rooms or surgery rooms and it's one of those things where the process ends up being so complex that it's not immediate immediately obvious upon reading the case study and this this goes a little bit into things that

don't seem intuitively obvious. Because when I first read it, I thought, oh, clearly they need another surgery room to be performing more surgeries. So I'm going to go ahead and summarize this real quick. I know this is an eye chart, really hard to read. This is basically the flow. So after reading the case study, I basically took it in the Visio and worked it down. They do a situation here where some patients use

and pay up front. Some patients go through insurance and some of those insurance claims gets rejected. Some of them get accepted. If they get rejected, there's an additional workflow that has to happen. I believe that's shown here somewhere, but it's basically one of the doctors has to write them a letter saying that, you know, we had to do this and then they come back and okay, we do it. And then there's extra testing. And sometimes the insurance company says if these tests aren't performable, authorize it and things like that. It gets pretty crazy. this is actually just the first part of the flow chart. Uh, yeah, there's more. Uh, okay. So in here we're actually getting into surgery. Come on. Here we go. Yeah. So here we

go. We get into surgery. We'll talk about prep and there's some stuff that happens in parallel here, right? So the surgery nurses can start prepping the patient while the surgeons and anesthesiologists are scrubbing in. Uh, obviously you can only do one surgery and one surgery. Oh, right. And there's two types of surgery. There's a laparoscopy and Here's the open surgery, both of which have different recovery times and different operating times. And then they give us the stats of roughly how many of these come through the surgery center. And so we do all this math, and we figure out what exactly does that look like. I did not do these transitions. This must be a holdover

from the template I was using. That's fantastic. But here's what I did. Once I finally worked through the problem, I broke it down. I'm seeing so many spelling errors. I don't know why I didn't get docked for these. This particular chart is just for a cash paying patient. And I do not recall if I did this one. I think this is a little labriscopi. Yeah, because it's the shorter operating time. But I broke it down by what task is done for that particular procedure with that particular payment method. I made a list of who is required for each of those steps. And then I made a table because this was the easiest way I could get the math to work in an automated

way. in a coordinated fashion. Me being the person that I am, I do this once and then make the tweaks. I basically copied the tab and made the change for insurance accepts, insurance rejects, and then again for laparoscopy versus open surgery. I have posted this whole spreadsheet on my GitHub and there will be a link. It's supposed to be on this page, but we'll get that for you at some point. So you can go in there and play with it. I'm actually gonna show you the spreadsheet. So I've got a table basically of zeros and ones of how many of which resources are needed The order that I did that is because there is a single situation where we need, or two situations where we need two surgery

nurses, and that just makes the math easier on the Excel stuff. I also got a deal here where we count which room is occupied for each step and the amount of time. When's my last call? Batch. Oh, yeah, yeah, yeah. That's how many things we can do at once. There's a specific step where you put a bunch of patients through a, I don't know, seminar, webinar. They show them a video. And in this situation, we're going to put six patients through, I'm out.

We put six pages through the video webinar at the same time. How are we on time? We're doing OK. All right, from there, I absolutely love Excel's capability to change colors based on your numbers. So I use this shit everywhere. Basically, this part does the analysis. And I set it up so it's automated. Again, so I can copy it over the next steps. But this automatically identifies that the surgeons in this case are the bottleneck for this particular scenario.

And you can see that's where we're stuck. It goes so far as showing the utilization of 100% and identifying it at the bottom line and doing that. And if you remember when we started, the real question was how do we increase profits, right? So that's the question. So on each step, for each combination, I have an additional table here that generates what is the profit in this scenario. So let's go take a look at that spreadsheet, because I know you're just dying. and sell skills. Somebody's laughing, that's fantastic. Okay, so here's the first table we saw. You can see here there's all my list of my tasks. Here's who all's involved. This doesn't do anything formulaically, that's just there for my brain because that's easier to read

than this. And you can see here I have two, I can change that at any point and go to five and it'll update, but we're not gonna mess with that right now. And then we've got a list of rooms. Now, a little bit to the right. What's up?

That's what I was talking about earlier, about trying to duplicate. Come on. Where's my mouse? Please. Hey, there we go. OK, cool. All right. So thank you so much for letting me know. OK, so there's the starter table. This is the workflow for the cache labroscopy surgery. There is my column of who is involved with which step. Again, this does nothing with formulas. This is just for my brain so I can read it. And then here's the number of which resources are involved with which one. And you can see we go down as far as the receptionist who schedules the call and all the different steps. And then there's the room we're using, what type of room. And then

over here is the amount of time it takes. And then I've got batch stuff here too. Batch is one of the first things we learned in the process optimization. where we did a house manufacturing and selling exercise in the first class and it was basically the smaller your batch size in manufacturing, the faster things go. And this is kind of reflective, I think, in incident response where when you have single task focus, you're probably a little more effective than trying to run several incidents at the same time. Okay, so here are the fancy colors. And you can see it's indicating, based on the formulas that are in here, are our bottlenecks because we only have four surgeons we are limited to how many surgeries we

can do now you notice if I go in here and I change that to six surgeons it changes now the care nurse is our bottleneck because we can only intake so many patients and so that's the usefulness of the way this is built out is this will let you immediately simulate what will happen if we make certain changes and hopefully if I have this. Yeah. It's updating the profits as well. So we've got the cost of rent for the facilities, the consumables for each surgery, the rentals for the bed, salaries for surgeons, nurses, and the anesthesiologist, and the receptionist, in addition to how many of those we actually have access to.

Oh, 80 for the first two rows there for revenue and consumables is ours. That's the number of hours. No, that doesn't make sense. there. Like I said, I did this over the summer in July. Rundown min table units per week.

Oh, I think it's looking at that capacity right there. That's what it's done. So yeah, the homework that I actually submitted had I think six different tabs, all copies of this one for the scenarios. Was it cash? Was it insurance? Accepts immediately. Insurance rejects and then is convinced and accepts. And then each, wait, no, that's eight. And then each of the two types of surgeries, open surgery versus laparoscopy. And that was important because the recovery time in the recovery room and the final step was longer for the open surgery, but the surgery itself was shorter for the laparoscopy. So that's kind of what I've got built out here. I do these in tables because it

makes it easier to tweak it later. I can take this exact same spread apply to a completely new scenario that may have a dozen times more steps, maybe half of the many resources. I can just tweak the tables. That's one thing I really like about Excel is those formulas when you're doing the tables are a lot more stable than ranges and things like that. We're coming up on time, so we're gonna keep moving. Any obvious questions about, yeah? How do you account for career events? You have to pay a lot. Ah, fantastic question. That gets back to the leveling thing we talked about, meeting with the Toyota production system. You design these for the averages. Fortunately with bariatric surgery, usually this is a

completely optional surgery. There are situations where that's not the case, in which case you just shift things around and bump them around. But in this situation, we assume steady state. And because the surgery center was maxed out at max capacity, or at least they believed they were at max capacity, that was a good way to go here. But that is a fantastic question for surge stuff. Let's say in the cybersecurity world, right, you have an incident. Hopefully you have an incident response contractor on retainer and you can just pick up the phone and bam, you've got that immediate new capacity. That gets into bigger things about how to orchestrate an entire information security department. This is kind of geared more towards just how to optimize a specific process.

But that is a fantastic question and something that should always be taken into account. Also goes back to the previous point of more optimization out of a whole process and a whole system when you're not running at 100% capacity for any specific resource. That's the word I'm looking for. But fantastic question. Thank you. All right. Let's get back to the slides. Maybe. Hey, it worked. It worked. My what? Probably.

So this brings us to the other book that was not part of this class, but I highly recommend. So I remember I was talking about how after I read the book, The Goal, and went through this class, I was like, how do we apply this to IT? And I spent months just like contemplating this. It was eating a hole in my brain. And then I was chatting with some people about, hey, I wanna do this talk for B-Sides, and at the end I wanna propose to people like, how do we take these principles and apply them, principles and how do we apply them to IT and cybersecurity? Because I feel like there's enough parallel that we can make this work, but it's just barely different enough that I can't

quite grasp it. And Rainmaker, how many of y'all know Rainmaker? Great guy. He says, oh, you should read The Phoenix Project, because that's kind of what they talk about. So I went and got myself a copy. Actually, that's a lie. I had a copy for the last two years, and I am really bad at getting through my backlog of books. I blame school.

Did they? Oh, that's cool. Anyway, yeah, so he said I should read this. Went and got my copy out of my bookshelf, my shelf of trophies of books that I have not read yet. And went right through it. And it is literally the previous book, The Goal, in an IT scenario. Like, exactly the same thing, narrative story, through what challenges they were facing, which are very common challenges with people I talk to across IT. And one of the first, I think it's the second chapter actually, they said, one of the characters said to the other, like, oh, you went through business school. Have you read The Goal? And I'm like, okay. And they've read it like five or six times

throughout the book. It's fantastic. But it basically takes those principles and breaks it down. So we're talking about bottlenecks that he I didn't talk about the scout's name. The scout's name was Herbie. So the entire time in class, we would talk about, have you found your Herbie? Have you found your bottleneck so you can optimize around it? In this situation, the bottleneck is Brent. Brent is a genius IT practitioner. He knows everything about this company. I think it was called Unico or something. They make auto manufacturing, auto parts. And this guy knows everything. And no one... solve an outage without Brent's help because Brent knows everything. And ultimately, you get to the point where they define Brent as the bottleneck. And the question is, well, if we can't fix

anything without Brent's help, is Brent the solution or is Brent a liability? And it turns out, the more thinking and analysis they do, Brent turns out to be the liability. Now, it's not Brent's fault. He's not holding the company hostage. He's just doing his best. Sometimes they do. In the book, in this narrative, Brent is not malicious. It's more nobody's protecting Brent's time. Managers come from other departments and yell at him until he fixes their problem. And so what we run into is a situation where Brent could be working on the big project that the company's supposed to be pushing for, which in this case is the Phoenix Project. That's the name of their thing. But he keeps getting sidetracked because

other people are stealing his time. They put in processes to protect his time. It's basically no one gets to talk to Brent without going through the CIO and things like that. And Brent can only work on the things that are, you know, this list of things. They end up doing a Kanban board. Anyone not familiar with Kanban? Fantastic process. I use it a ton at home. It's basically you list out your tasks and you've got the to-do and everything starts on to-do. There's the in progress and there's done. Some people put a fourth column in the middle between in progress and done and it's like on hold or pending someone else's work, things like that. It's a really great way to visualize everything that's going on and what's next

in line. They end up in this book applying it to laptop and desktop rollouts and they find that because there's a defined process and everyone knows when the thing that they're dependent on in front of them is done, they're able to just take the next thing in queue and take it and go. trying to figure out what's going on. So that is fantastic. One of the big things to talk about is the type of IT works. There's business projects, and that is the things that we're doing to enable the business, new things specifically. So in the book, that is the Phoenix Projects. It's their big point of sale and web sales system. These books are set like back in the 80s or 90s, so it's very interesting to kind

of see that little bit of history back there. IT projects, right? So IT has their own projects they're doing to try and make things more efficient. In this case, they're talking about deploying a complete virtualization environment where they can get rid of all their, not get rid of their physical, but convert them to virtualized hardware and move things that way to make things easier to work on. And the idea there is that's gonna make them more effective as an organization. There's changes, and sometimes these are maintenance, patches, updates, things like that. Firefighting is the fourth type of work. And that is the most dangerous type of work. They often call it unwork because it's unplanned.

It'll pop up and it'll suck out your time. And you can't not do it, right? When the sales website is down, you can't not fix that. That becomes priority one. And the idea is, how can you optimize those IT projects in the previous step and those changes to get them in such a way that those firefighting bits happen less and less? applying your patches when you're supposed to, reduces your security footprint, things like that. But the book gets into a lot of detail of how to identify those, how to put the processes in place to identify those, and how to, really the big thing is shift the culture of not just IT, but the entire company to get in line with that, to kind of teach them that this

is why we're doing this, this is how we make things better, this is how we help you more. So we get into a lot of that.

Let's talk a little bit about cybersecurity. I thought this was a really interesting perspective. I'm still a little torn about what I think, but the idea being that security is important specifically when it benefits the business. They were in a situation in this book where the company was at risk of going under, and so there were certain things like audit findings that were not as, that got deprioritized.

really interesting. I'm not... I struggle with this, with whether or not I disagree or agree, and part of it is not being in the book. It's hard to get a feel for what the details were, because they are fairly generic, some of these things. But there's some things, going back to that power sector thing, some things need to be done, right? Especially in this day and age, there's not... Well, I say that. We've had... two Microsoft patch rollouts have had reports of crashes. So there needs to be some caution, but it's gotta be measured, right? But there are some situations where the cybersecurity takes minimal effort and does so much preventative that it's worth doing. But I'm still on the fence on where I

think about that. But yeah, moving on. Great book, highly recommend. Go read it, tell me what you think. We are running a little short on time, so I'm going to be brief here. I'm reserving some time to questions, so if you have some of this, I'd love to hear it. But essentially, how do we apply these principles in cybersecurity specifically? So the Phoenix Project talked specifically about operations IT. A lot of great material in there, a lot of great parallels in cybersecurity, but there are some nuanced differences between coding and developing a web sales platform

containing it versus incident response or vulnerability management or GRC, right? Those are very similar but slightly different. And they're different enough that I can't use Phoenix Project as a cookie cutter, if that makes sense. In the same way that I wasn't able to use the goal as a cookie cutter to IT, I'm not able to, I'm not able to, Jason is not. I'm sure someone is able to, I don't know how to do it yet. the Phoenix Project to cybersecurity specifically. And so, if you have thoughts on this, I wanna know. We talked about the types of IT operations work. I wanna bucket down what are the types of cybersecurity work. And that might be as simple as the NIST categories. I don't know yet. Oh, and

then I would really love to build an MBA class for my classmates and take some of their money the way they're taking mine. Specifically on technology risk.

and how these executives that are learning, these people that are learning to be executives, how can they take technology into account the same way they take financial risk into account? So if you have thoughts on that, I would love to hear them. I'm already building a list of topics that I want to see in a technology risk or a technology strategy class, and I intend to propose it to the faculty and say, hey, this is the thing you need to do it. I need to be the one to teach it because I want your money. But if you have ideas, I would love to steal your ideas. But these are some things I've already thought

of as shifting left, secure by design, sec devops, things like that.

Did I push the right button? Oh yeah, this is what we talked about. That's me. If you want to get a hold of me. Are these current? Yeah, these are current. Okay, cool. You can get me there. The GitHub.

There's one specifically with today's date and says process optimization. It's a spreadsheet, but it's super simple. Just Jason R. Kohler on GitHub. But yeah, I would love to take questions and slash or ideas or feedback or whatever, because this is very much a summary of what I've learned, what I've figured out, and I would love y'all's help and how do we do this better. Yeah, what do you got? Yeah.

I've heard to talk about is how in the same way we have loans in accounting and other ways of raising capital, tech debt also has compound interest. It's just not measurable in dollars as easily.

I'm trying to do in my current role of risk exceptions is based on the business unit that this application supports and how much money it makes, that's your opportunity cost if it goes down for cybersecurity reasons or business continuity reasons. Who knows? IT goes down at a time as well. AWS totally didn't do that two weeks ago. But yeah, yeah, basically, yeah, I would love to be, I would love to find a way all the work that I think it's going to take that we can quantify the risk in dollars.

Yeah. Discount over time. IT debt over time. I love that. I'm going to think about that. I'm going to think about that. Actually, take my email. Shoot me an email because after tonight's period I'm not going to remember. What'd you got? What'd you got? So one thing in one of my classes that covered was the cost of fix-up on the way is so much cheaper earlier than once it's introduction. Absolutely. That gets back to the shift-left thing I was just talking about. If you can get a SAST that has a plug-in to your developer's IDE where it tells them live as they're typing, hey, this doesn't look like a good idea. You want to try it this way. to remediate that vulnerability. Nothing, right?

It never existed in the first place. Whereas, you know, if it goes live and it goes into production and a bug bounty person finds it, that is going to cost you so much more. Was that a question or a distraction? Cool. Do they have much of that? Is this SMU? Do they have much of what? Well, much of this tech. SMU's MBA program and SMU's business. Tech landscape.

Their business school really doesn't. And that's part of why I'm trying to write it. I have not really made contact with their engineering side and their computer science side yet. I suspect they have that. But I would think in the, you know, as an MBA class, maybe even in the Ops class, they would have a whole. Yeah, so actually as we're talking about it, I'm thinking a little more. Let me provide a little more context. a marketing class. It was mandatory. Everyone in the program had to take it. And he started off that class with, I don't expect you to know how to go create a marketing campaign. I don't expect you, when you graduate, when you finish this class, to be able to

run a marketing department. What I want you to know is these are the metrics of how you measure a successful marketing campaign. These are the metrics of how you measure a successful marketing department. And these are things you look for and things you need to tweak and some of the root causes you may find. And that's kind of what I want to do with this technology cybersecurity risk is I don't expect these guys to go be CISOs when they finish the course. I don't expect them to be CIOs when they finish the course. But I want them to know how to evaluate CIOs and CISOs. They want to be able to talk to, they want to know, because it's all about, you don't have to, the MBA is all

about, you don't have to know all the stuff. You have to be able to talk about the stuff to be able to hire the

Yeah, absolutely. And that's kind of thing is like, despite all the finance and accounting I've taken, I will never be an accountant. That's not going to happen. And in the same way that, you know, I don't expect these guys to be technology people, but so many of them, as talking to my classmates, so many of them are dependent on IT and developers to build out the tools and solutions. Like I got one guy, he's building out a complete, oh, Fudge, what's it called? The whole auto sales industry inventory efficient everything, he's managing the developers that do that. He's pretty tech savvy himself but he does not know how to do that on his own. But he needs to know how

to manage those people. He needs to know how to take the business processes that he understands, work with the technology people to build the tools he needs and know that they're being competent. These are the type of people who can... They ask me this all the time. developer how do I know they're competent and I'm like well do you have 10 years I can teach you but you know I don't think that's an MBA doesn't prepare you to do that it's a key part of being a manager that's what's missing and that's what I'm trying to if I can convince them to do this course if not I might write it myself and just put it out there on the internet but

that's a thing that's a gap I see it's a thing I want to make but exactly is not how do you the things, but how do you manage the people that do those things? How do you know that they're being effective? All right, we're running short on time. I think we have time for one or two more questions. If not, I'll be around. If not, I'll be at karaoke. What you got? I was just going to say, do they go over all the ideas of, like, I guess I forgot the term for it. Basically, you have an in-house department versus staff. Oh, outsourcing? Yeah. So it's not in the core curriculum. They might cover it in one of the electives. It's not in any of the electives I've been

in yet. I will go look at that. That's a really good question about how do you make the decision of outsourcing versus building in-house.

Right. What's the cost of change? What's the tech debt incurred by that? Because that's the as I'm trying to communicate to people right now is, yes, this decision looks clean now, but there will be tech debt within a year, no matter which decision you make. That is a fantastic question. I'm gonna add that to my list of things that needs to be in that course. Thank you. All right, I think we're at time. Yeah, pretty close. All right, I'll be around. If not, you can know how to get ahold of me, hopefully. But yeah, that's what I got. Thanks so much for coming out. Y'all been great.

go to SMU to get your MBA and give them a ton of money.