Getting Real to Getting Better in Cybersecurity | Chris Curwood | EP 103

Host Vishal Masih sits down with Chris Curwood, Senior Solution Architect for Cyber Systems and a former U.S. Marine, to discuss how accountability, agility, and integrity shape the future of cybersecurity.

From the defense sector to the digital enterprise, Chris shares how mission-first leadership and adaptive thinking drive transformation.

Discover how to build rapid feedback loops and why the speed of consuming feedback matters more than deployment speed. And why “business as usual” has no place in the modern cyber landscape.

Key insights include:

Breaking free from outdated, process-heavy cultures

The evolution toward Zero Trust and cloud-native operations

The role of DevSecOps, SBOMs, and agile engineering in resilience

How AI, automation, and quantum computing will redefine defense

Lessons from the Marine Corps that build stronger teams and systems

A must-listen for cybersecurity leaders, architects, and innovators committed to building systems that are smarter, faster, and future-ready.

Connect with Chris Curwood

Email: ccurwood@sabresystems.com | christopher.curwood@gmail.com Company: SABRE Systems, LLC

#CyberSecurity #DigitalTransformation #ZeroTrust #DevSecOps #AI #QuantumComputing #CyberResilience #Leadership #PublicSectorInnovation #GetRealGetBetter

Responsible for ICAM, Zero Trust, or identity security in a federal agency, prime, or large regulated enterprise?

If you’re trying to move from strategy to execution, start with Zephon’s Zero Trust Readiness Assessment: zephon.tech/zt

Questions or guest ideas? Email defend@zephon.tech

Transcript

SPEAKER_00 0:00

Welcome to New Zealand from the Cyber Challenge. Uncle Challenges and White House and Public Sector Cybersecurity. Some of the most complex ideas. This is a space for honest conversations, fresh perspectives, and practical insights designed to empower and inspire. Get ready to rethink what's possible and join the community committed to making cybersecurity stronger, smarter, and more resilient. Here is your host, Michelle Mante.

SPEAKER_01 0:43

Hi everyone. Welcome to another episode of Musings from the Cyber Trends. My next guest today is a senior solution architect for Cyber Systems and is currently serving DoD contracts with digital transformation and modernization. He brings over 25 years of experience, including eight years as a United States Marine with three combat tours from 1996 to 2004. Since his exit, he has served various projects and products with subject matter expertise that has varied from joint task force contingency to forensic identification to big data thread platforms and adjects. On his own time, he enjoys spending time with family, being physically active, fishing, and interestingly retro arcade and pinball machines. With that, everybody, please meet my guest today, Chris Gerbert. Welcome to Musing from the CyberTech. Chris, and thank you for your service.

SPEAKER_03 2:06

Thank you. Yeah, appreciate you and thank you for inviting me to your podcast. I look forward to the conversation we're gonna have today.

SPEAKER_01 2:12

Absolutely. Chris, in our previous conversation, you had mentioned getting real to get better. Can you share the story behind it and how it applies to cyber security today?

SPEAKER_03 2:29

Absolutely, yes. That term was actually coined by the former chief of naval operations Mike Gilday back in 2021. And when I first started my current position, my job was to come in and lead with the digital transformation modernization efforts for our customers within Sabre at the DOD level and uh specifically within the Navy. But this term really struck me because it made a very concise message or a vision statement that totally aligned with what I had been doing my entire career. And it was also interesting because it stemmed from my operational experience as a United States Marine, where we actually hold accountability all the way at the lowest levels. And we expect all Marines to be accountable for their actions, to have a high level of integrity, and to be able to account for anything that they cannot solve on their own, to expedite to leadership for support, for help. Really, what it comes down to, it's always about the mission first and about us last. And as a result of that, we're very we're ultra focused on outcomes and expectations as they apply to the mission. So with regards to the get real, get better, I remember the first time I heard that term. It the reason why it stuck was because it we're looking at four words that really encapsulate the vision of where we're trying to go. And so the get real part is the part of accountability, the personal accountability that we're looking for when we're with our within our engineers. This isn't business as usual. This is looking for value added and value streams. And we're and as you're moving into digital transformation and modernization, we lean on the data. The data has got to be clean, it's got to be accounted for and tracking everything that's going on inside and outside of our environment from a security perspective. So when I think about that get real, to me, it really focuses on looking at ourselves and looking at what we need to be accountable for and trying to address barriers for opportunities to improve to either meet or exceed the mission demand. So the get real part is important from a perspective of finding out where your current state is and what where you really are. And the integrity part's a really big part of this because it's not about over-beloading what we're trying to do or over-promoting what we're trying to do. It's really about saying, okay, what's working and what isn't working? And then how are we going to get better? And one of the challenges that we face within the DOD that's very interesting is getting the feedback all the way from the end user at the edge, either the tactical edge. And there's lots of reasons why that's challenging. It could be for InfoSec or ComSec and just trying to keep things isolated. But in this new future that we're going to with Zero Trust and with cloud native operations, we really need to be able to be just be upfront about the information that we're collecting and be able to take action as quickly as possible to keep it from becoming more of a bigger issue. And that's part of the getting better part, right? Is like we're looking at where we are in a current state and we're chartering for that future state. And we're trying to say, how are we going to get there? And that's a very tough question to ask because much of the capabilities and the service-oriented architectures, and there's a lot of challenge with compliance and policy and even capability with how these things interact. A cloud service provider could have multiple regions of services that they're promoting within the different domain spaces that the DOD uses, but not all of them are available at all of these regions. So you could end up becoming locked into a solution that is only available in one region until you wait for another region. And this also affects your highly available disaster recovery type of continuous operations process as regard with regards to that. But to make it into a long story short, the get real get better is four words that really encompass everything that I've been doing for my career.

SPEAKER_01 6:26

That's some deep that's some food for some real deep thought. Like where do you see that we as a cybersecurity as a cybersecurity industry as a whole, where do you see we are lacking in the get real part?

SPEAKER_03 6:48

I think that I think that the most difficult part is to do that self-assessment, especially if it's going to potentially expose some negatives, which is actually what we're looking for. When I meet with system owners and mission owners and discuss future state, I'm not really interested in the blue sky scenarios, like what works really well. I do want to account for it and a ratio of what works well and what doesn't work well. But I think that my effort is best spent on what doesn't work well and how are we going to fix that, especially as when we're talking about mission-critical systems where we're relying on bits of information or we're relying on something that needs to be very resilient as it serves information to the workforce. Yeah. So I think that going back to that, I think that it's really the biggest challenge that I face is that culture shift. We're literally going from very process-oriented network security type of infrastructure, where you may you may hear terms like business as usual. That's actually a bad word to me because that means that you're never really changing, you're just following that same process, which means if you don't change, you don't improve. And I I really want to have a real-time focus, a dashboard of uh some type of continuous monitoring, um, where if something good happens, we can take credit for it and try to promote that in other use cases. But when something bad happens, we need to take action immediately.

SPEAKER_01 8:16

So this process shift that you mentioned that is not that is not occurring because of fear, because we are just too busy, or we have become too too comfortable.

SPEAKER_03 8:34

I think it's a lot of things, right? I think and you could say yes to all of those, right? Like comfort is something that people aspire for sometimes within their role. I'll tell you, I actually try to get comfortable being uncomfortable, meaning that I'm I have that perspective of if I didn't learn something new today, it's a waste of a day. I have the same perspective when I do sports or activities. I'll give you an example. If I go snow skiing, I don't go snow skiing anymore, but when I used to, my knees are too bad. But when I used to snow ski, I remember the first time that I became proficient at snow skiing. I was with my father and I told him, I said, Hey, I didn't crash all day. And he said, You didn't ski hard enough. That's absolutely a hundred percent correct. Yeah, it's just it's a position of challenge. So when I think about the get real, get better and that personal accountability, I'm thinking about, okay, you know what you do well, you know what you don't do well. Let's focus on using what you do well to for your normal everyday operational activities and starting to challenge yourself or your team on the things that you don't do well. And the first part about understanding that you don't do well is having that internal integrity to say, I'm not doing well. This is not ideal, this is not optimal for what I'm trying to do. The other part of that is that process driven. So you talked about change the change management side. We have a very diverse cultural workforce where you could have engineers that have been working within their role for 20, 30 years. These are really valuable folks, but they've been doing it that way for 30 years. Um, and imagine they're at their end of their career, they've got five years to retirement or something along those lines, and change is not something that they want to do right now. So you get a little bit of pushback there. You get pushback on the challenge of Comsec and InfoSec with the future of where we're going, where it's it's not open, but it is. Like the zero trust paradigm that's coming out, and it's a misnomer. And it to and what I mean by that is that I I think it's good that we should assume that the enemy is in our they're involved with our users, our devices, and our applications. But I think that once we get through into that operational environment where we've got our arms around our boundaries and we know what's going on inside and outside of it, it will open up the levels of collaboration and it will actually we can confidently interact without some of the concerns that we have with Comsec and InfoSec because the systems will be guarding us.

SPEAKER_01 11:04

Understood. So these people like you mentioned, like who have been working on this on the same role for the past like 20 30 years, they are really good at what they're doing. How do you convince them to shift the way they think? How do they how do you make them more open?

SPEAKER_03 11:27

Yeah, so that's a really good question. Traditionally, when we were working within a waterfall lifecycle type of a program or product, you would come and you wouldn't have the product at the ready because it's a long-term product, it's very difficult. So you might have some type of a simulator or some type of a flash macromedia that is giving you the future state or giving the customer the future state. But it's gonna take a year to a year and a half, maybe two years to get out, right? And in those situations, there's a lot of talking. There's a lot of people talking about what they want to do, and a lot of the pain goes up front into the design and the development because that's where the majority of the work is. But as a result, what ends up happening is you really can't change your, you really can't change that trajectory because you're in the middle of it with that waterfall life cycle. And so there's a lot more talking and guiding around on the evaluation process. Whereas when you're in an agile cycle, which is where we're going, where you need instantaneous feedback and you need to have a process that you're managing and monitoring for turnaround times and improvement, right? When you're working in an agile process, you need to make that change for priority as soon as available, which depends on the cadence of your team, right? So if I was in a waterfall life cycle program or a project, and we let's say we had 18 months to deliver, by the time we got into test and evaluation, much of the bugs that we're going to find have been year, maybe even a year separated from the actual development activity. So you're adding all this overhead into the actual overall life cycle when you're operating, especially with software development. Waterfall is not designed for everything, especially software development. But it's good for stuff like building buildings and things where you know the requirements, you know the materials, and you can get a good handle on the schedule. When you're talking about software and technology, that's not always the case. In fact, sometimes the customer doesn't know what they want, which is when they lean on us. And so when you go into that long term where you're giving a simulator or a flash file, and then you're delivering that a year and a half later, where it's probably needs to change already, and you didn't allow that for that change. Not only are you just talking to them, but you might not even be delivering the ideal solution at that time. Going back to the agile side, we don't talk when it comes to agile. We build and then we demonstrate what we're giving them as part of that build, which means that we're being accountable for what we're working on. And at that point, when we do that demo, that's actually really critical from my perspective for feedback. This is our customer, this is the first time they're seeing this. Is it valuable? Is it not valuable? What do you want next? And instead of trying to build something that is incredibly complex and big that would take two years to build, we work on a cloud or a minimal viable product that will leverage cloud native operations and that segmentation to build a core MVP of basic operations. And then we're going to iterate it, simple, do simple, small iterations with the cadence of the team. It's a combination of what the team can do, meeting our commitment, right? Missing a commitment in an agile cycle is not acceptable. It should hurt the entire team. It should not, it's not something you want to stand behind or be proud of. You did not meet your mission. Um, at that point, the only thing of value that you can gain from it is the retrospect of why didn't you meet your commitment? Because customers don't want that. They're not looking for you to come with without what you said you were going to deliver. And it's easier to deliver when you're in that small segment of delivery because you can get there sooner and faster, start seeing the problems, and you can deliver. There are times when you might not meet your commitment. But like I said, it's something that you don't accept. It's not something, it's not something you want to repeat, rinse and repeat on the regular. If from my perspective, I treat it similar to that that analogy I gave you earlier with the skiing. That's where you're going to get some really good criticism to go back and say, this is what we did wrong. I don't want to do that again.

SPEAKER_01 15:21

What I am hearing is that having being able to divide the work within smaller teams where you all work together as a much more coercive unit and work faster forces you to change your mindset.

SPEAKER_03 15:42

Yeah, it's a forced mindset where it's you're almost at an entrepreneurial level with the service that you're building. And not only that, but remember we talked about the defects when you find the defects, right? So just imagine in that agile environment, where let's imagine we're delivering every three weeks, but you could be two weeks depending on your maturity. Or delivering every three weeks, we are not going to change that delivery because that would impact our schedule and our scope. So that means that we are committed to that scope. But what ends up happening is a developer will get to what they consider done from their perspective. Now we don't know done is different from every perspective across the pipeline. Um, but at that point, yeah, absolutely. So at that point, the thing is again, remember what we talked about earlier about finding the defect. When you find that defect, the developer was just in that code base. They know exactly, as soon as you report that defect at an agile level, they don't have to go looking for the defect because it was done a year ago. They were just in that code base, they know exactly where that defect is, they can go and make that change on the fly. We can validate that change and confirm that we're going to meet our commitment to our end user based on what the product owner thinks is acceptable. Now, what ends up happening is you eventually end up having a manifest, a small manifest of improvements. It could be enhancements or resolutions to defects. But you have a small manifest of deliveries to your customer. That's not the end of that feedback. Remember, the product owner is responsible for trying to meet or exceed the customer's expectations. So that product owner is the is the hub spoke, so to speak, for the feedback of not just the customer, but any feedback that could be valued because they're responsible for the return of the investment on those three-week turnarounds. So when you go to deliver that demo, we were at the state we were at before we delivered, which should stay and remain. We don't want to regress any of our software or systems. And now we're delivering new features. So we go into that demo, we deliver those new features, and at that point in time, we're expecting the customer to give us very good information for what's next. And at that time, that's also when the product owner is looking at the backlog of things that we know we need to fix to try to organize those in a manner that the development team can deliver the most return of investment. They're not going to take the uh the quick wins and just keep hitting those quick wins and not looking at some of those long-term strategies. There's going to be a little piece of everything inside of that three-week window, including opportunities to improve upon your dev apps, devsec ops pipeline itself. So, you know, the opportunity to actually work on infrastructure, you could have engineers that are working on that. The cybersecurity element. The other side of this is that being in cybersecurity and working on software development, as I have from the time that I was a Marine early on. And we're talking about, like you said, 1996, 2004. Back then, the cybersecurity was the Wild West. This was before DISA Gold Sticks, before common vulnerability, you know, CVU and all that stuff. We it was very Wild West and very rogue, very manual. There was an automation. Um get into our systems. And you know, moving from that to now and being in that environment, initially, when we just started to bring up cybersecurity as a priority, it was not managed well, meaning that we had a turnaround time for some of these CVEs and they were impacting our ability to deliver new functionality or enhancements. Does that make sense? Yes, it does. Because it became the top priority. So ultimately, what ended up happening was we ended up building systems and softwares that could deliver baseline features, but they were ultimately just designed to be secure. And unfortunately, those don't deliver information systems that can win because we don't have room for those enhancements. When you start stacking other types of things on top of that, the challenge of policy and guidance from the top down, because we're constantly trying to improve upon the cybersecurity posture. And then we go into leaner operations where we're actually we don't have the funding for the resources to get this work done. You can you can kind of see that you can kind of see the writing on the wall how a software system can go from delivering enhancements to basically going into a sustainment mode.

SPEAKER_01 20:04

So yeah, have you ever come across scenarios where the customer is not real? But I mean it's like they don't feel like they don't seem to be that much engaged or they're not giving you uh good feedback. Have you seen that?

SPEAKER_03 20:28

Yeah, I've seen a little bit of everything as far as like negligence and how they operate. And just yeah, ultimately, in my opinion, the feedback needs to come from the end user all the way up into the system. And if it's not meeting the needs of the end user, in my honest and humble opinion, if something isn't valuable anymore and you're not able to build value into it, you need to retire it.

unknown 20:57

Yeah.

SPEAKER_03 20:58

But I I have dealt with that. I think those are not good systems. Sorry, I didn't even step on you. I don't think those are well-operated systems because uh you're not supporting the end user, you're not supporting the value that the system brings. And sometimes you can see that with uh with the level of arrogance with certain systems or software systems that they feel they have a corner on the market or there's no competition. That's where I see some of that happening in a competitive environment where you have a market, the competition pushes the quality towards the end user.

SPEAKER_01 21:33

Have you have had to say engage the the uh the end user early on in the whole product uh design? So, like you start with a customer and they send you requirements that uh you you feel that you are not having that that that The uh the one-on-one conversation with the end user. How do you tackle that?

SPEAKER_03 22:10

Yeah, that's a really good question. I actually when it comes to requirements, I've shifted my mindset away from the standard government requirements where software shall do this, shall do that. There's a lack of detail that's in that if you're familiar with user stories, but I tend to I believe that capturing a good user story is much more beneficial in that you lay out the role, right? So you could say as a data analyst or as a cybersecurity analyst, right? You're laying out the role, which aligns with zero trust and role-based access controls, right? So you lay out the role and then you lay out either the problem statement or the enhancement feature. As a cyber analyst, I need to be able to quickly get a common list of CVEs for my system or something along those lines, right? That's the action. So you have the role, then the action, and then you have the benefit. This is important because some people just use the action. As a cyber analyst, I need to have this, but they don't put the why. And the why is actually important because that actually defines the priority, right? So that next benefit is why. So as a cyber analyst, I need to be able to quickly gain access to a common list of vulnerabilities for my system because I need to be make sure that we're compliant within a seven-day window or something like that. And it needs to have as low overhead as possible or whatever kind of value metrics you could put into that. And by the way, that benefit also creates your validation criteria, right? Because then at that point, you can start mapping your test for quality control, quality engineering at the end of it. This really all comes down to like how can we move quickly in a safely and secure manner, right? And so that's really where I focus. And speed is of the issue, is of the uh is of is a matter of importance for me. And really the thing that gets lost in the community I see because we're we're trying to crawl before we walk, and I'm very future forward thinking. One of the things that we lose focus on is really this isn't about how fast you can deploy to prod, although that is important. Really, what matters is how fast can you consume feedback, prioritize that feedback and turn it around so that they don't have to deal with those barriers.

SPEAKER_01 24:21

That's a different mindset. I haven't I have not heard that. So what I have heard, yes, go live as soon as as possible, make sure it meets the requirements, make sure it goes through the whole test cycle. But building a design that is able to absorb feedback and then modify or deliver the those those changes. ASAP is not something that I have come across much.

SPEAKER_03 24:56

Yeah, so I'll give you an example. So imagine that as you have a zero-day attack and it's hit your system, right? In a current in a current environment that wasn't invoking a zero trust or a containerized uh cloud native type of operational environment, or didn't have the type of management overhead to account for all the activities going on inside and outside, it would be very difficult to determine what the impact of that zero day is all the way across your systems of systems. Because you don't have good accountability of what where it is and what's happening there, right? And not only that, because you don't have good accountability of where it is and what's happening, that also means you don't have a good plan for how you're going to remediate it. So, what I mean by that is, and I'm using zero day as an example because I can't think of a better example of something that will shut your system down than a zero day, right? Because as soon as it hits, you're impacted. So that's the tip of the spear, right? How we would handle that and getting into that, how are you going to discover that? And how are you going to not only show how you're accounted for, but the impact that it has on your systems and your remediation, your turnaround? And that's a lot, that's a lot to handle. But if you end up going, if you're in that cloud native operation that that's data-centric monitored environment where you have software bills of materials that are tracking all of your software libraries, library dependencies. You have secure artifacts that are pushing out to show your application are secure through your devsec ops pipeline, which again it will lean towards that DOD CIO effort of the software fast track program. Um, now so I'm always thinking about zero trust and about modern technology. Zero trust is three baselines users, devices, and applications. So when I think of applications, that's really where that devse ops pipeline comes in. But going back to my root question, the feedback, that feedback has to get back into that development cycle and it has to be managed by that team and that product owner to determine what the what's most important. And a zero day, like I said, zero day is all hands on deck, right? But the sooner that you can discover that impact and that remediation plan, the faster you can recover.

SPEAKER_01 27:12

When you mentioned zero day, I just think of I think it was two years ago, December 23, when we had when we had the log 4J vulnerability come out.

SPEAKER_03 27:25

And we had zero day into the spotlight, didn't it?

SPEAKER_01 27:30

Yeah, yeah, yeah. And then the patch that they came out, it had its own vulnerabilities, and they came up with another patch which had some similar issues, then like you have to uh almost almost apply three patches in a span of I think two weeks. I think what you mentioned that not having a view of what you have in place. Like at that time what I saw, like everybody was just like running to patch. But the fact that you had to have JNDI turned on for that like vulnerability to be exploitable was not even considered. We just kept throwing the patch without seeing if the C if the actual zero day has an impact on us or not.

SPEAKER_03 28:24

Yeah, and I don't have the I don't have the stats, but I'll tell you that watching zero days that occur and they're always occurring, watching them happen around us, what I've noticed, and this is just from my own recollection, what I've noticed is that the systems that aren't cloud native, the systems that are like server client-based or on-prem type architecture, they're the ones that are most deeply impacted by these zero days. And it for known reasons, right? You have the segmentation where you can segment within your cloud native operations where you can shut down those services and take care of them. Yeah, yeah, and spin them back up. And so typically what I see is when a zero day happens, not that it won't hit a cloud infrastructure, it just ends up being easier to remediate. And I watch those other systems, and I'll just put this into perspective, it all kind of ties together into technical debt and single points of failure, right? So uh when I think of capabilities, one of the first questions I ask is, is this our own capability? Is this the only way that we're doing business here, right? And the reason why I say that is because if it's the only way we're doing business, that means we don't have contingency for that zero day. And if we're and if we're operating in a manner that server client or on-prem and we only have that one tool and a zero day hits, the impact could be catastrophic for some of those mission critical systems because now all of a sudden they're offline and not serving where they need to be. So I I tend to take a look at that and the supply chain, but it's a risk, right? Like in the commercial industry, that might be a risk that we would be willing to take to have some single points of failure. On the government side, I would say that it's part of the tech debt strategy to have more than one capability, but also gives you some flexibility and freedom. And the more that market grows, like there are certain services within our fields where that might be the only available or applicable service for known reasons, policy guidelines. They've got to have the provisional access or authorization. So it's one of those things where we can look at that supply chain management, that software supply chain management, and we can say, okay, if this gets hit with a zero day, we have contingency through this because we have this over here and we can shift our users over. There it won't be smooth, right? There's a change management side of it, but that's where agility comes in, and that's also where we expect the individuals at the edge to be capable of change fast. Remember, in that antiquated technology business as usual, there is no change, and not only that, they don't want to welcome it because change is hard, right? But in that accountable perspective, we accept it for the same reason that I'm not going to do a day of skiing without crashing. I am I'm a Marine, I'm rugged, I want to accept this criticism, and I want to grow and change, and it's value added every time. The other part of this is as you get into agile teams, you'll find that you won't get bored because you can do cross-training and job training and eventually become a full stack developer, right? You could let's imagine you start on front end, that's a it's an easier code base to because through CSS and all that stuff, you start on front end, you end up going to back end and computational processing. Um, and if before you know it, you can do it all, and now you're training and leading others to the same experience that you have. It's a natural progression, and you can guide that into your career path trajectories. I lead a couple people within Saber. We use that as for incentive on our annual performance review. It's just a constant process. And we also do coaching and mentoring and communities of practice. But really, what I want is I want the next up-and-coming engineers to understand that they're a full-time student and that we're gonna we're gonna make mistakes and have problems. That's where the learning occurs, right? Yes, and we don't want to do it over and over again, right? So if a mistake happens, the next thing I ask is how can we keep this from happening again in an automated fashion if we need to. Now, when you're trying to decide between automation and manual, I use a really simple mathematical equation. And I got this because I used to be a QA manager and I had to do this. For me to automate something would mean that I need to be able to evaluate the cost of that. So I'll give you an example. When I used to automate my tests, I knew that the framework that I was using to automate would take five times longer than if I was to manually generate a test using a Word document or a spreadsheet, where I'm just entering the steps in and you follow them, right?

SPEAKER_02 32:44

Yeah.

SPEAKER_03 32:44

By the way, when I create those manual tests, it's almost a 100% loss because it's gonna have to be constantly maintained by people and it's gonna be they're gonna run through it, it's gonna be very human-driven, which also means that it can't be run, it can't be run at night or on the weekends, it's only during working hours when that person's in the office. All these different things come into effect is like how can we simplify that? And so for me, if I was gonna run a test more than five times, remember it's gonna take five times longer. So if I was gonna run that test more than five times, I need to automate it right off the bat.

SPEAKER_01 33:18

Yeah, we have this mindset within our companies that like do it right the first time. So we have to always think of what we are doing from the long-term point of view. Uh I have told my team the days of us doing low-value manual work are over. You know, like with AI, so focus on the high value critical thinking part and automate as much as you can.

SPEAKER_03 33:49

Absolutely. And I'll tell you, it's we're in a really uh interesting and fun space with technology right now, with generative AI and pre-trained models. And so I actually believe that it's we're moving so fast and we're doing it in an organized fashion, where especially with generative AI, because you can use it to decouple and to organize things in a manner that's easier to digest. But we're really where I'm going with this is that I really do believe we it used to be that if we wanted to adjust or update software, um, we would recognize that we have a problem and we would start building out requirements, right? And that's a task all on its own. That could take months, right? I actually believe that at some point in the near future, I hope, anyways, that at some point in the near future the reporter of the problem will be able to fix the problem because it would take less time than it would to write the requirements and go through that process. And I also believe that we can qualify code changes through something like a DevSecOps pipeline as long as we're maintaining that pipeline to be the gate. And what I mean by that is that the pipeline just can't be sitting there on its own. People are gonna have to engineer it, they need to make sure that we're following all the current CVE structure and that we're handling any cybersecurity events that come in, and also that we're improving upon the process. So we're streamlining. Remember, we talked about feedback in the very beginning of the meeting. We can always improve on these numbers, right? We have charts, and so you know, let's imagine that it takes a week to get feedback. How can we tune that up and make it faster? Because there is a value there, right? And so as we're looking at these pipelines and the these entry points, we're constantly trying to improve upon that process because the value added is a force multiplier to anybody that uses that, right? On the same token, we could be using different devs ops pipelines across different organizations to challenge each other. So imagine that I have a devsecops pipeline at my cloud service hosting provider, right? But I may want to move to another cloud service hosting provider. So I take my code and I say, I want you to run this through your pipeline, and it runs through the pipeline and it stops it because it finds a vulnerability, right? Yeah, that should be an indicator to me to go back and review my pipeline, and why didn't it stop on my pipeline? So we could be challenging each other's pipelines by just changing code bases and pushing it through and saying, Why is that happening here but not over there? Yeah, AW type testing.

SPEAKER_01 36:16

So uh what I got from you is that like you you see a future in which we could potentially have one uh AI agent receiving feedback, the other fixing the code, and the other one reviewing it, another building. So we could we could potentially automate the whole process, of course. With the human inside, the whole process just to make sure that AI doesn't go crazy.

SPEAKER_03 36:55

Yeah, and then the other side of it too is and I've been this is something that's very difficult. We have physic physical access, as you know, from a cybersecurity perspective, is key, right? So when I'm doing coding, if I'm doing it locally on my laptop, that means that wherever my laptop is, even if I have it encrypted and all that stuff, I can put MFA on it. There's still potential that somebody could get access to that, right? Whereas if you were operating in a cloud space within a zero trust model, you're keeping all that data somewhere else where it's being secured. And by the way, if I am a bad guy, because we're assuming that everybody is a bad guy, this is pointing to the user side of that zero trust paradigm. If I am a bad guy and the system is tracing, as soon as it identifies that I'm doing something wrong, some type of a threat act, it's going to cut my permissions. And now I'm automatically not allowed into that code base, not allowed, I don't have any permissions to do anything. And actually, what really would happen at that point in time is that your ISSM or ISSO would be opening a body of evidence to come and have a quick conversation and ask why were you doing what we were doing? And maybe it's a false positive. That would be great. If it's a false positive, just restore my permissions and I'm back in and running. But if I'm an actual threat actor, get me out of there and have it at this at a point of readiness for that next person. So there's a lot of things that come into play here with this when I think about it from a changeover perspective. When you think of zero trust, you have to have that capability to take anybody, even the head architect, off of that program or product. And that produces a real big challenge. And they so they say, What's the impact of that? Well, if you're working waterfall in a non-agile manner, and you didn't have a proactive readiness around your documentation capture, your code completeness, and all that other stuff, then you would have a really big problem to solve. But if you had an agile team where that role has a daily delivery, it could be that the wiki documents, the code base, whatever. If that information is clearly tracked and documented for you new users, so that when you onboard, they know exactly where they go. You have it simplified to a point between your segmentation of your cloud native operations to where it's you're not talking about a complex process. You're talking about managing an API or something along those lines. The challenge becomes much easier, and that bar of entry for that person to come in and replace is low. Generative AI is going to make it even better because it's going to be able to allow us to lean in that direction for some of the heavy lifting, like the documentation. We know that's what takes time, right? So now we can start to lean on it. Unit testing, things like that. And so as we start to move in this future, we're starting to reduce some of the pains of that those time-consuming tasks that we used to have to manage, and we're lowering that bar of entry for those roles, and we're creating a natural landing spot or a landing path where anybody that fits the criteria for that role could come in and hit the ground running on day one.

SPEAKER_01 40:02

I feel like you mentioned dev uhps quite a few times. So you think the whole software bill of materials concept will that be like will that turn into a crutch for us to hide under compliance and not actually do a good job?

SPEAKER_03 40:29

I think there could be potential there. I'd have to really walk through that, but I actually think that the software bill materials is a critical part of the software fast track and of that gated process. And I really I think of it more as like a ledger. A ledger of what's actually happening, what's going on. And remember, like when we get that zero day, we need to be able to really quickly determine the impact, which means that's what those S-bombs are going to do. On the other side of it, those software bills of material are critical for compliance. Um, they're gonna need to be rolled into EMAS packages on the DOD side, as well as the artifacts from the build process. And that's actually how we end up putting our arms around that application section of zero trust is through that DevTech pipeline and through that accountable measure. So I just think that when I'm looking at these aspects and I'm looking at software building, do I think it's a crutch? I think it's I think it's a ledger of account management and inventory management on our software development practices. And I also think it's really healthy because I think that there's a lot of lazy development that happens once they create an actual application where they don't actually update the software dependencies and libraries. Even I have to do that on the small things that I do for static web pages and things like that, or if I'm doing Lambda scripts and Python updates, it's just a common thing, and it's not easy all the time, but generative AI is definitely making it easier. So it's one, it's as we start to move forward, we need to very carefully analyze some of these tools that can help us and make sure that we're not making any missteps with those tools and really start to understand how we can move fast. We use the term running with scissors, and it's really funny because running with scissors is a dangerous thing, but some of my clients are flying with weapon systems, which is much more dangerous than running with that into perspective. These people, these warriors that are supporting us and defending us are so important to me. And part of that is also because I was a Marine and I know that they make a difference. It's interesting because I interact with a lot of my colleagues that didn't serve, and they have they have a lot of respect for those that serve, and they ask themselves, they said, I don't know if I make a difference. And it's me that has to tell them, yes, you do. The work you do is incredibly valuable, and we appreciate it. That I'm not a warfighter anymore, but I can tell you that as a Marine, knowing that the enemy would had us in their sights in advance so that we can prepare for that situation is an advantage, and I appreciate the systems that allow that to happen.

SPEAKER_01 43:13

Cybersecurity right now is like a multi-billion dollar dollar industry and growing. We every week we have a new product. But the fact that instead of such a huge product sprawl, we are still getting breezed almost daily. Like the ask from the customer base. Like they're not demanding that the same kind of performance. I think the mindset has been that hey, like if if it is not uh it is not a matter of if but when, and we just go with it. Like, how do you tackle that?

SPEAKER_03 44:24

Yeah, that's it's interesting because in in the area that I work, it's uh not uncommon for the uh the people signing the checks to not be the end user, which means that they're the ones that are evaluating some of the performance and operational perspectives, but they're not really the operators. That's actually one of the values that I really enjoy about get real, get better, is that it's not that's not an acceptable model. We need to know precisely what is going wrong at the edge at the end user level, and to be really upfront, an after actual report, which is what happens after a combat scenario, after a combat scenario, in my opinion, is too late. I think that I don't think I think it's uh I find the value in it to some extent where you could probably go into more details afterwards and really take a good retrospective of the overall mission. Um, but I think that having a dashboard and some type of continuously monitored process where you can take action immediately puts us in a better position to win. And I I just believe that there are certain details that are focused around that former traditional type of life cycle mindset, where you know that waterfall life lifecycle mindset where we were going to collect it all at the end, that's not winnable anymore. That's not going to compete. On the other side of that, with the cybersecurity tools, you mentioned that there's constantly new tools coming, there's not they're constantly changing. Yeah, they I think that's actually a good problem to have as long as you can you can you can get around the noise, right? And so I'll give you an example of how I did this when I worked commercially, which is a little bit more challenging because there's more, right? There's more side there's because you're not kind of a compliance. So I would leverage, especially for a startup company where I'm not really enterprise, I'm a smaller company. I would I would lean on the gardener charts within the different markets, and I would stay away from that leader quadrant because that's going to be expensive. That's enterprise level, right? I would actually be looking towards the challengers because those are the ones that are going to be giving you good value. They're pushing to get into that leader quadrant, um, but you don't have to pay top dollar. And you could potentially, depending on your client base, you could potentially be a good customer for this person, and they be maybe willing to squeeze some efficiencies for you to lock you in as a customer. So there's all kinds of different ways that we can do negotiate that. But I would say the best problem to have is to have a a really convoluted market to where you can evaluate all these tools and a really and what I mean by evaluate, we have tools, we have tools like an assessment of alternatives, and that's like a one-time shot. You go and you look at three tools and then you score them. I'm talking about continuously watching. I'm talking about because just like I said, if you have that single point of failure and you're using it, yeah, you need to know what kind of contingency is out there. How easy is it for gonna be for you to change? And then the impact to the end users as well. Change management is hard. It's if somebody's used to using Windows and then you push them into a Linux machine, it's they're not gonna hit the ground running. Yeah, so it's just the way it is. But like I said, we need people at the edge to be ready to change quick, right? Not ones that are gonna push back and go, I can't change, I don't want to change because it's hard and I'm retiring. No, we want somebody that's ready to change, and I want to be really specific too. I used age as an example, but I'm not I'm I want to be very focused. I've met my share of elderly engineers that are amazing and they embrace and they learn to study, right? Um, but I'm just being up front, there are biases there with people, and I could be one of those when I get there too, where I'm like, hey, I just want to write it out. I'm I got a good paycheck coming. I really don't want to make it to the point where I can't sleep at night and I'm overchallenging myself. I'm very focused on the warfighter and on the person that I used to be with regards to my current work. But I am listening to the customer and pouring that feedback in, organizing that feedback, prioritizing that feedback, understanding all the capabilities that are around us and the service capabilities, it's a lot. It's a lot of work, which is why we have to do it. We have to do it. We have to reduce that tech debt, create more contingency with the capabilities that we have around us, and be ready for anything that could happen. As a Marine, when I was operating on the edge in that in those Wild West scenarios, one of the one of the metrics that I'm most proud about was that we were out there for 10 months and we were supporting over 10,000 nodes. It was the first time, this was back in 2003. This is the first time we really started using digital assets on on in a battle in a battlefront. We didn't really do that during the Gulf War. And actually, it was really interesting. We saw that the dependency on those systems back then, this is I don't know about now, but back then the dependency was so heavy that things like signal channel radio and things like that, they just didn't want to use it. They didn't find it reasonable, didn't want to use it. And so we're seeing this advancement in how comms are done, but really staying on top of those systems and that information and getting really back to that center point. We only went down, like our systems only shut down with the hubs folk that I was supporting. Our systems only went down during that entire 10 months for I want to say 30 minutes. It was a scramble drill, not fine, it was not fun. We never want to go down. The first thing that goes in my head when a system goes down is how many people that were relying on that system are in danger right now. And I know it's real because we're Marines. So, you know, it though that level of accountability importance towards the uptime and towards the actual perform and operation of those systems needs to be the highest priority with security. We need to get the bad guys out of our networks, and we need to be moving fast. And so all of the things that we've been talking about this morning, this afternoon, hit on that. It's very complex, but that's actually the joy of my job is trying to put my arms around all of this and get value out of it. It's a team game, though. We work together quite a bit, you and I, on some of these uh projects and proposals, and I value your expertise. There's many times where you've come in and corrected me, and I need to be adaptable to that because I don't have all of the answers, and I appreciate that that level of effort and that that accountability that we have as a team at a team as a team level. So I think really it comes down to that. That's a really another really important aspect of development that I wanted to hit on too is that in during that waterfall lifecycle development, it wasn't uncommon for developers to be in their office stovepiped and alone and just trying to deliver. But I really found the benefit of working on a table with engineers in real time to be I can't go, I wouldn't be able to go back into an office like that. I just think it would be such a detractor if you were in an engineering effort. And again, just like we're talking right now and working, I enjoy those types of environments when you and I are getting together and we can bounce off of each other because it because again, I'm I'm not perfect and I'm trying to learn, and you're helping to make my day the day that I want it to be, which is challenging.

SPEAKER_01 51:58

I really appreciate that answer, Chris. And like speaking with you, you know, like I see the value, the mindset that you bring from like being from uh from having served. You know, like uh I have not been uh in that space. Uh my focus as coming from the commercial side has been just to mainly been focused on making sure that we serve our uh our customer right, but that it goes a lot beyond that because you have the whole war fighter mindset, which is what we need right now. Like I I have been also asking my team here just to get into the message here that we are at war right now, be it Russia, China, North Korea, or Iran, or even people just who wants to like uh who want to make uh uh make big money. But coming from the background of having served, I think it's uh it's such a big help for for the whole cybersecurity for the whole cybersecurity industry. I appreciate that. Thank you.

SPEAKER_03 53:18

Yeah, I'll tell you, and it I think it's important that you know this too, because you're supporting this community, that the value of that. And I'll tell I'll share a story with you. I recently met with a colleague of mine, and I was working with him, and we were talking about some of the same kind of topics, and he mentioned to me, he said, I never served. He said, I was too he said I was too afraid to put myself into that kind of a risk, right? He said, but he said my grandfather was on I think it was the USS Lexington, one of the boats that was in Pearl Harbor. His grandfather was there. He ended up having he was off of the boat when they got bombed because he, I think he had a medical procedure or something along those lines. Um, but he said he watched his grandfather suffer Survivor's Guild, and uh and he said he finds great, he has a picture of his grandfather above his uh his uh his workstation and he finds inspiration. And I was so delighted to hear that because I and I wanted to know I told him, I said, you should have nothing to be ashamed of for not serving. I consider your service now to be valuable, and I'm sure your grandfather would be very proud. And the reason why I say that is because this individual has that level of accountability to where they're applying value added towards their products, and I believe that our customers are better off for it. So it's really important to when we work with colleagues, especially with the in the environment that I serve, that we share that with our colleagues, how important their work is, so that it can bring that motivation daily and have that same mindset, that get real, get better mindset. Business as usual is a bad term for me. I just don't like it. I never liked it. I remember the first time I heard it, that sounds like mediocre at best. And I I I tend to I have that marine mindset in that I'm constantly challenging myself so much that the competition just doesn't want any part of it, they're just gonna get dominated. And I know not everybody has that mindset, but if I can bleed that off to others, or if I can share that with others and give them that extra oomph that they need to know the quality of the work they're doing, the value that it provides, I'm happy to do that.

SPEAKER_01 55:36

And I'm sure just by uh speaking with you, I see that uh I see that trapping off on me. So I'm sure like people who work with you uh they see that and live that now let's uh let's pivot a bit. So retro arcade games and pinball machines. Uh tell us about that.

SPEAKER_03 56:08

Yeah, when I was a kid, so I grew up in the 80s and 90s when pinball machines and arcade machines were still pretty popular, and I grew up in the Pacific Northwest, which rains a lot, so they were more popular up here. But my my uh my father owned the Pizzeria at the time, and it had an arcade and nice, uh yeah, and then this was before Nintendo Entertainment Systems came out. We actually had some arcade games in our house. We had Defender and Donkey Kong, and actually it's really unfortunate. I don't know whatever happened to those games. They were out of our house long ago after we got a Nintendo. But I would love to have those games again. And I'm actually I built a machine arcade emulator many, many years ago when my kids were still younger. I'm in the process of investing in potentially buying a pinball machine. Um, because it's in the market, they're not inexpensive. Okay, and I I just love the uh it's like uh an oasis for me to to imagine a dark room with a bunch of arcade machines and the bleeps and the blips, and maybe even the smell of pizza and beer, something like that. But but I don't know, it just there's a nostalgia in me, and I really enjoy uh some of the nostalgia with my family. So we go to the arcades from time to time, or we'll go to a pinball bar or something like that. But yeah, I love uh I love arcade machines, I love video games. Um, not to the point that I really play them a lot, more more so just it's very interesting to me. And and now I actually get more joy watching my kids play. My kids are more into the console games. From time to time, they'll honor me and they'll go into an arcade, play some old stuff with me.

SPEAKER_01 57:50

Okay. Which is your your favorite arcade game?

SPEAKER_03 57:56

My favorite that's a good question. My favorite arcade game. There's so many, and they're all very different. I would probably say the arcade game that I spent the most time playing was probably Donkey Kong. I really like that game. Let me think. I like Joust. Joust is another good game. Uh and then some of the more uh modern games that were when I was a young teenager, like some of the Street Fighter games, I like some of those games as well. And then, yeah, and pinball, I'd say there's a lot of really new pinball machines that are coming out. There's a new Harry Potter machine that just came out on the last game. Yeah, but I like uh one of the games I like now that's probably my favorite game from pinball would probably be Cactus Canyon. That's a game that my wife and I have been playing a bit of.

SPEAKER_01 58:43

Okay. So have you ever uh have you ever taken part in any pinball competitions? Or it's more like a hobby.

SPEAKER_03 58:55

No, I'm a I'm more of a fan than an expert. I actually it's funny that you mentioned that. So I used to work for a company called Internet Identity in Tacoma, and they have a they had a little arcade bar that was open on Friday afternoons. So me and a couple of my colleagues would go and have lunch and play pinball there. And I was not the best, even of the three people that we were playing with. We had a friend there that was a master, like he knew how to nudge the ball without tilting it, and he he could just get on and knit and nudge it. Um, I'm still working on that. To me, now I'll literally watch the ball go completely out uh in out of bounds, and I'll be thinking to myself, why didn't I nudge it? But I'm not my reflexes aren't necessarily there yet. But uh yeah, I like I know the strategy. I know that I wa I actually like watching YouTube videos of professional pinball players because it's quite amazing. But I don't know if you've ever seen that. Yeah, no, no, I have not. Okay, it's really interesting because it's it's very humbling, actually. They can put the ball, they put the ball precisely where they need to at the time they need to, and they know how to control the balls. And so when you watch something like that, it can be very intimidating, but it's also very enjoying enjoyable to watch.

SPEAKER_01 1:00:12

Interesting. I will check it out. Yeah, very interesting. What modern games are you playing right now?

SPEAKER_03 1:00:21

I actually just bought a game for my son and I. It's modern, but it's it's a remake. It's uh Gears of they just did a Gears of War, it's not out yet, it comes out next week, but I pre-ordered it. Okay. Okay Gears of War for the PS5, and that was a game that I played when my oldest son is 27 now, but when he was uh when he was younger, like six or seven, we used to play that on the Xbox. So I'm looking forward to playing that with my youngest son, who's a senior in high school now. So he I told him we got it, it's coming. Another game that I really enjoy, and it's interesting. So I bought the Switch 2, um, and and I wanted to play that new Donkey Kong game, but I ended up getting stuck in Zelda Tears of the Kingdom. I like to play that game, but I've been lately I've been putting it down. So just so you know, I'm very much like I've been speaking during this meeting, I'm very prioritized. I'm studying right now, I'm starting to study some quantum computing foundational information.

SPEAKER_01 1:01:17

Okay, nice.

SPEAKER_03 1:01:18

I just know it's part of the future. I know from some of the writings on the wall. So I've I've almost always got some type of a certification that I'm trying to target, whether it's a foundational or just even associate level. I just I want to understand what the value spectrum is going to be for the new services that are coming around. Quantum is actually really interesting, and I'm enjoying it. I mean, I'm enjoying the actual learning aspect, but it's I'm not sure how much you know about data and digital information, but it's very similar to analog in that you can you've got more than ones and zeros, but it's very complex because you've got some physics and some calculus in there, and then you start talking about all kinds of different things that could go into the weeds really quick. But it's very interesting and it's it's a unique field. But I going back to my point, I when those things happen and when I have other priorities, I tend to drop off on the games a little bit.

SPEAKER_01 1:02:15

So I was putting it right, yeah.

SPEAKER_03 1:02:18

And I do that intentionally, it's part of the discipline from being a Marine, just knowing the value of what I'm doing and trying to apply my time. But again, I like video games from a relaxing perspective, and sometimes you need a break.

SPEAKER_01 1:02:32

Absolutely. Chris, how were you as a kid? And did you have siblings growing up?

SPEAKER_03 1:02:39

I I had a brother growing up. My brother was it was tough love. So my brother challenged me quite a bit because we had a very competitive nature. We were only three years apart from one another. Um but ultimately I at some point I gained my own independence and just kind of went on my own. My brother does well for himself, but him and I are a little bit different in that regard. And once I became a Marine, I took my own, I had my own North Stars, and he was just cheering me on from the sidelines. But yeah, I didn't have I did I only had one brother. I was still a latch key kid. I don't know if you know what that is.

SPEAKER_01 1:03:20

No, I don't.

SPEAKER_03 1:03:22

So when I grew up in the 80s, it wasn't uncommon for uh for parents that worked really hard to give their children a key that they would put around their neck to get into the house when they were done at school or whatever. Um but really what it means is that I was off on my own. I was doing my own thing off on my own. I had chores and things like that, and I did good in school, but I was off on my own, and that's actually one of the reasons why I joined the Marine Corps. So no regrets there.

SPEAKER_01 1:03:51

Okay, good. Uh is it safe to uh to uh to assume that you can make a good pizza?

SPEAKER_03 1:04:04

A good pizza, yeah. Yeah, that I I would actually definitely stand behind that. One of the one of the things that happened for me, so I have I'm not a developer, but I have a development background, meaning that I don't write code every day, but I can certainly read it, and I like to play around with it from time to time. Um I would say more of uh configurator than a developer. But what while when COVID first kicked off, my wife and I were having a conversation and uh she asked me if you could have a superpower, what would it be? And I started to think about it, and I thought we could actually have a superpower because we have a lot of time on our hands now. So I told her, I said, I wanted to have the ability to make good food anytime, anywhere.

SPEAKER_01 1:04:50

It's a good footpower, yeah.

SPEAKER_03 1:04:52

I'll be fired. Yeah, and actually I poured myself into it and to the point where it's one of my favorite hobbies now is cooking. And it's it's a it's very similar to engineering and development, right? You have to you have your you have this future state of where you're trying to go, you need to get organized with your ingredients. You're gonna have methods for applying a cooking element to these ingredients, and then you have this comp this way of combining them all together at the very end to make something beautiful that tastes good in your mouth. And I to me, there's nothing better than just pouring myself into a cooking station and then watching somebody eat it and knowing that it tastes good. Yeah, so I would totally if I were you, I would bet on me that I can make a good pizza. And if you're ever in the Seattle area, I would definitely invite you to my house so I can cook for you.

SPEAKER_01 1:05:48

Awesome. I would look forward to it. And if you're ever in the Dallas area, I can cook pretty good Texas chili and brisket.

SPEAKER_03 1:05:57

Oh, I'm definitely there then.

unknown 1:05:59

I could

SPEAKER_03 1:06:00

I love good Texas barbecue.

SPEAKER_01 1:06:02

Thank you. Uh I think the the whole world loves Texas barbecue. I will tell you something funny. Before I moved to Texas, I don't really eat barbecue because I was in the northeast and over there and barbecue is like is like usually sweet.

SPEAKER_03 1:06:19

Okay.

SPEAKER_01 1:06:19

Yeah, till I moved to Texas, I was like, but because I I didn't grow up eating sweet meat. So to me, like meat should not be sweet. It has to be spicy. So only when I came to Texas, I was like, okay, now this is good. I can use this.

SPEAKER_03 1:06:35

Spicy, smoky, juicy, and falls apart in your mouth.

SPEAKER_01 1:06:38

Yep, exactly. Yep. Brisket.

SPEAKER_03 1:06:42

Yeah, there's other different types of barbecue too. If you go to St. Louis and Kansas City, it's a little bit there. The south, like South Carolina, it's a little different there.

SPEAKER_01 1:06:51

Yep.

SPEAKER_03 1:06:52

Yeah, very cool.

SPEAKER_01 1:06:54

I really got into barbecue after I moved to uh to the south because like over here they do a better job. Like it's yeah, uh yeah, period.

SPEAKER_03 1:07:08

Yeah. We have some good Texas uh stuff, Texas barbecue stuff here, but I'm sure it probably can't relate to being in actual Texas.

SPEAKER_01 1:07:17

I think people are now moving out from Texas and using the same skills, but this is tough to find, that's all. Yeah, yeah.

SPEAKER_03 1:07:28

I think that's what happened up here. We got it. We had a guy that came up, he brought his own smokers from Texas. He had uh like a yeah, restaurant style, right? And he's been here for I want to say six years, and his business has really taken off. And in fact, they do uh he does uh smoked pork belly on Fridays, and and uh each layer of that pork belly just has a different flavor that it takes on and just has different tech. I it's amazing. But yeah, I love going there and ordering some food. Sometimes I'll go in there and they won't have anything left of what I want.

SPEAKER_01 1:08:02

So I hope you find some good barbecue and tell us how our our listeners can find you. How are they gonna do that?

SPEAKER_03 1:08:19

Yeah, so I work for Saber Systems L L C Sabresystems.com. Um you can reach me at c Kerwood, so C C U R W O O O D at Sabresystems.com if you want to reach me. And I'm happy to connect with anybody who's interested in digital transformation and modernization. And you can also probably reach you to get a hold of me as well, but I'd prefer if you contacted me directly so we don't bother you. But yeah, it's uh I work for Saber Systems, and uh I can also be contacted at christopher.kurwood at gmail.com for my personal email address, and I don't have a problem with that. But uh yeah, that's how you can get a hold of me.

SPEAKER_01 1:08:58

Thank you again, Chris. I'm sure our listeners will really love what we discuss and also learn from it. Getting real to get better is something that we all can can strive for, and we need it.

SPEAKER_03 1:09:17

Yeah, again, it's Admiral, it was uh Chief of Naval Operations Michael Gilday, who coined the term in 2021. I definitely think that it's a really good vision statement, North Star, for anybody who needs to adjust or change or adapt to improve. And I really appreciate the opportunity you gave to me to be on your podcast. I really enjoy talking with you. And uh, if you ever need to do this again, I'll be happy to join.

SPEAKER_01 1:09:41

Absolutely. I might nudge you again. Thank you, Chris.

SPEAKER_03 1:09:46

Thank you, sir.

unknown 1:09:48

Thank you.

SPEAKER_01 1:09:48

Have a good one. Go back. You too. Thank you.

SPEAKER_00 1:09:50

Music from the Cyber Trench Podcast requires more than a conversation. It takes action, research, and collective wisdom. If today's episode resonated with you, we'd love to hear your insights. Join the conversation and help us shape the future together. We'll be back with more stories, strategies, and real-world solutions that are making a difference for everybody. In the meantime, be sure to subscribe, rate, like reviews, and share us so much people benefit from us. Thanks for listening, and we'll see you on the next episode.