Skip to content
401- Tore Out the MSSP and Built an AI SOC w/Brian Rowe

Brian Rowe

401- Tore Out the MSSP and Built an AI SOC w/Brian Rowe

THE IT LEADERSHIP PODCAST
EPISODE 401

401- Tore Out the MSSP and Built an AI SOC w/Brian Rowe

20
1 X
20
00:00 | 00:00

Brian Rowe

ON THIS EPISODE

Brian Rowe walked into Rehrig Pacific after a cyber incident with one job: build a security program. What he found was a century-old manufacturing company running IT like they were still small. You can't drive security on top of an immature shop. So the guy hired to be CISO ended up rebuilding all of IT too.

For four years, Brian was both the executive and the first-line incident responder. No days off. Because he was the only person who could read the telemetry. "Generative AI is a faster car, but if you're a bad driver or a bad navigator, a faster car just gets you in trouble a lot faster."

We get into tool maturity matching organizational readiness, why he fired his MSSP for an AI SOC platform, and the VMware death spiral. Plus the framework that stops executive whiplash: know if you're incremental or transformative before you ask for the plan.

The biggest takeaway? High appetite for results plus low appetite for change equals organizational conflict. Pick a lane.

Show Notes

Episode Show Notes

Navigate through key moments in this episode with timestamped highlights, from initial introductions to deep dives into real-world use cases and implementation strategies.

[[00:00:00]] Origin Story — Taking apart dad's computer at age 8

[[00:03:15]] Current Role — CIO/CISO at Rehrig Pacific manufacturing

[[00:05:42]] The Incident — How a cyber event led to hiring

[[00:08:30]] Dell Years — Avoiding IT because "good ideas go to die"

[[00:12:18]] Technology First Problem — Why IT people miss the point

[[00:16:45]] Manufacturing Context — Plastic containers and supply chain

[[00:20:22]] Security Stack Recipe — EDR, identity, email priorities

[[00:24:10]] Tool Maturity Curve — Simple tools that become handcuffs

[[00:27:35]] SentinelOne vs CrowdStrike — Platform consolidation reality

[[00:32:18]] MSSP Breakup — Why he fired them for AI SOC

[[00:36:45]] Traditional SIEM is Broken — Splunk licensing problems

[[00:40:12]] Four Years of Hell — Executive and incident responder

[[00:43:30]] AI Predictions — Augmenting humans, not replacing them

[[00:47:15]] Claude Cowork Paranoia — Browser security concerns

[[00:51:20]] The 80/20 Rule — People don't understand risk

[[00:55:45]] Decision Direction Problem — Why IT can't take more projects

[[00:59:30]] Throughput Metrics — Dollar per task, not tickets closed

[[01:02:15]] Infrastructure as Code — Shifting security controls left

[[01:05:40]] VMware Death Spiral — Milking the cow to death

[[01:08:25]] Incremental vs Transformative — Know which lane you're in

KEY TAKEAWAYS

Match security tools to your maturity, not your ambition
"Faster car, bad driver" - AI amplifies broken processes
Know if you're incremental or transformative before asking for plans
401- Tore Out the MSSP and Built an AI SOC w/Brian Rowe

TRANSCRIPT

Phil: All right, let's go. Talk to me. How'd you get started in this whole wildness? I think I should take a guess. Was it like an Apple IBM, or was it like Commodore 64, maybe Pentium 486, 586 or something like that?

Brian: Oh, no, I was. A little earlier than that. I remember my dad came home with. I think it was a Hitachi, maybe Noah Hyundai.

Phil: This is great.

Brian: Yeah, well. And it was obviously an x86 architecture, I want to say. I mean, this would have been, man, like, 89, 90. So my dad was. Is a retired nuclear engineer. And for whatever reason, I wasn't in school today. So it was like the weekend. He bought it, brings it home, sets it up, it's in my room. Because at that point, they're like. The idea of a home office wasn't as substantial. And so I was out of school, and I just decided I was going to disassemble it while he was at work. It kind of came back in, and dad was like, I'll make you a deal. If you put that back together and it works just the way it did, we won't speak of this.

Phil: Oh, so he's a cool dad.

Brian: Yeah. So I think that. I mean, that probably started it. I think my dad probably figures pretty heavily in that story because I also remember then a couple years later, I was maybe in the third grade. I mean, I wandered into his office and I saw dad. I'm bored. And he reaches over because he's in the middle of, like, trying to study for the hard exam, and reaches over and grabs a book in Objective C and hands it to me and says, here, go read this. And I started programming not long after.

Phil: So what age was that?

Brian: I want to say that was like the summer after third grade. So, like, eight, nine.

Phil: Were you a straight A student?

Brian: Yeah, I was one of those jerks. Like, school was just easy for me. Honestly. I also wasn't social. Like, I was a little bit classic nerd of, like, I'm going to bury myself in a book and not really worry about what other people are doing.

Phil: All right, why don't you just tell me, what do you do now? What should we. Now?

Brian: Yeah. So I run IT and cybersecurity for a large plastics manufacturing company. So my elevator version of that is that I really have all the responsibilities of the CIO and the CISO for my organization, inclusive of things like digital transformation. But I was actually hired to build a security program. That's really what started this journey at Rare Pacific. But it turns out you really need a very relatively mature IT shop to be able to drive security initiatives. And that was when you work for a hundred plus year old kind of privately held company, sometimes you walk in and you go, wow, we're still running this like we're a mom and pop, but we're way bigger than that and we really need to rethink our strategy around technology as a whole, inclusive of security, which has kind of been the story of the last almost eight years.

Phil: Man, it's great. All right, so here's the key piece to this, which is because we're the podcast, you've been heard and the, the general theme is that 93% of CTOs out there, CTIOS, at least in the, the mid market to Fortune 5000 space, are the departments of IT and right, they have a seat at the executive roundtable. And it's nice that they have a seat at the executive roundtable, but how much nicer is it to be heard? Right along that vein of thought, the fact that someone was hiring to grow or create a strong security posture tells me what we know also to be true, which is a lot of executives do have a lot of knowledge, which makes them dangerous and causes oftentimes more holes and problems. But how did that happen? How did someone actually go out and hire an IT person for security versus the IT guy having to convince executive management that we need security?

Brian: That's an age old problem, right? This is an organization that went through a relatively significant event that impacted their ability to communicate and service customers with the help of their cyber liability provider. They brought in a third party auditor and an assessment team kind of after the fact, both to help clean up and address challenges, but also to figure out how do we not make this happen again. And so I think it would be very fair to say that the IT staff at that point were doing the best they could with the resources that they had. And then the situation brought a lot of visibility to the problem set that they weren't getting previously. And so the number one recommendation kind of coming away from that incident was you need to hire an actual security leader who understands how to identify and manage or mitigate risk. And so they went on a journey and were remarkably willing to go through the level of change required. Now. I will say I spent most of my career through nearly a decade at Dell and then subsequently working at a software company doing my best to stay out of it. Frankly, like when you work for a Fortune 50, Fortune 25 company sometimes, I mean, my perspective was that it is where good ideas went to die. So I tried very hard. I mean, even while I was at Dell, the fact is I wanted nothing to do with security except that my best friend was network security architect at Dell and he just for years kept going, hey, you need to come talk to my boss. You need to come talk to my boss. And I was like, I'm good. That's too close to it. And so I spent my life in every department at Dell except for it. I mean, technically I also didn't work in procurement, but my last stint there I had been in mobile product design, working on smartphones and tablets. Dell decided that they were going to exit or at least dramatically modify how they were operating in that business. And so I went great. I'm now my go to market EA job for the VP of mobile product doesn't exist anymore. Maybe I'll go talk to the CISO and see what this thing is about. And that kind of got me started on a security journey that I wasn't expecting that I frankly really loved. That just made sense to the way my brain worked. And so very rapidly moved from having no formal experience all the way to effectively being Dell's data security architect for corporate, which was a lot of fun, but it kind of prepped me for okay, how does the rest of the world work? And how can you operate in a very technology oriented role without just being the shop of no. Or the place where the good ideas go to die.

Phil: Right. So the theme of it being the department of no. Yeah. Where good ideas go to die. So it's something we've been a battling for a long time. A lot of people say no, always say yes, just say yes. But why? Why do you need that? And to me, what it sounds like you're saying is the reason why I didn't want to go there is it just sounds boring. There's nothing creative, there's nothing new and fresh. I'm just turning wrenches and making sure the systems stay on and the blinky lights keep going. So you can't be that anymore. And they have to have some level of business ingenuity and creativity to help grow the business or secure the business. Is there something there to be said that's the piece of advice or change for it? People that are the guy that just held the passwords to the firewall for the last 20 years. If your Internet goes down and you're calling carriers yourself, that's not strategic. IT we help teams centralize monitoring proactive tickets and escalation across every location without Capex Less noise, more uptime, make it boring again. Just go to you've been heard.com and answer the seven questions to simplify, streamline, and save.

Brian: Yeah, I think there are two things that I would say. One, I find it challenging for any segment of the organization. The secret to the success that I experienced working for a massive company, one was just leading with curiosity, like being willing to take on new problems, not being afraid. But. But I was always coming at it from within the business. I worked in sales, I worked in sales operations. I went to work in finance, I worked in product development. Like as a technologist at core. I mean, I. I have a lot of computer science training. I spent a lot of time doing IT style work and, or writing code. And so I had the background and the technology understanding, but really what I was finding was that every problem ultimately was about people efficiency and business operations. And it wasn't technology first. And so one of the things that I often ran into there is that when I would interact with people who were like, paid IT people, they tended to believe that the problem was technology first, not people first, not business first. But it was the technology. And it's like, well, that thing doesn't have a purpose in life unless it drives business operations or if you're in the outside world. Right? Like outside of just a pure business, if it doesn't actually solve a problem for a person and it's a real problem that people understand, then it doesn't really matter how good the technology is. And so I think that was the thing that, like, I got my education as a technologist through the lens of all the business problems that we were interrupting.

Phil: Can we just break that down for a second? Like, how would someone think like that, that it was a technology first thing? Like, what does that really even mean is, like, we have a sales problem. Well, we're gonna fix that with technology or are we gonna talk with the salespeople and find out? And obviously the answer is to talk with salespeople or to talk with the sales manager to find out what the actual challenge and problems are first. Like, it could just be we have bad salespeople, but it's certainly not the CRM.

Brian: Yeah. And honestly, I will say a lot of business people think this too. There's an aptitude of saying, well, if I had this tool in my toolbox, then I would close more deals. And it's like, well, okay, but hold on. That just like when we talk about AI, it is fundamentally augmenting a human process. And so the first place that we have to be invested. Is understanding the process and evaluating. Is the process good? Is it right? Is it achieving its aims? Or is the process actually in the way? Because I was speaking with some of our executive team a couple of weeks ago and the reality is that Generative AI is a faster car, but if you're a bad driver or a bad navigator, a faster car just gets you in trouble a lot faster. And, and I think technology can be that way. It's like if we don't step back and think critically about the process and understand are we actually achieving our aims within the process and is what's our value goal and how does that kind of value stream function through the process, then it's impossible to understand how to augment it, because that's really what we're doing. Whether we're automating pieces, in some cases, maybe automating whole value streams, but I don't see as much of that, at least not in my organization. Then we're just making people move faster in a way that is ultimately destructive. But if we've done the work to establish the right process, you even think like from a sales perspective, do I even understand, as a technologist, do I understand how our industry trends are driving changes in buying perception? And like a good example of this when I first started in my current industry and we sell plastic containers and we also sell material handling and kind of technology solutions like a full stack service provider. But when you think about a lot of the customers that we've done business with for years and years and years, Covid accelerated the retirement of a lot of the kind of like there was a dramatic shift in the purchase. We had built a lot of really strong customer relationships with people. And so like when a bid came up, it was like, oh, we have to call Rarig for that because that's who we do business with, right? And so like, as long as we continue to produce a good quality product, their expectations and demands of us weren't really changing much. But as you start to get younger and younger buyers that are in that process now, our salespeople are trying to sell to people who are generationally more like them. The Amazon effect really does come into play of like, hey, I want that to be easy. I don't want to have to call you every time I want an update. Like, their perceptions are changing, their needs are changing and they're becoming more digital first. I think Covid accelerated a lot of that both because there was a lot more turnover in some of these traditional arenas where Maybe people are like, you know what? I really want to go live my life. And so they're retiring. There was a heavier press towards digital solutions because people couldn't be in the physical place. And so for industries like the ones that we serve, which are typically technology laggards, that's how, again, good old boys and laggards both just have a negative connotation in my head. That's part of why I hesitate.

Phil: My very first impression, my first impression of your company when I look at it, is waste recycling. Your supply chain.

Brian: Right. But what does that actually mean?

Phil: The guys I call to come get rid of my crap, that's what I think. That's my first initial thought. And yours is probably like, well, no, it's the guys that you call to give you containers and stuff and forklifts to get rid of your stuff. I don't know. And then if you pick it up also at the same time, then great.

Brian: Yeah, well, and I think too, it's like. But it's like that exact element of you have to think about how many assumptions we have in the process. So when you work for an organization that makes a lot of trash cans or rollout carts that's heavily invested in environmental waste and recycling, you all of a sudden start to recognize how much complexity is in the process of getting your trash from your alley or your driveway and getting it where it belongs. And how do you do that cost effectively? Similarly, like, because one of the things that we do in supply chain is we service a lot of beverage distribution. We service poolers who do things like ag bins, meat trays, dairy crates, things like that. Where particularly for us, we're deep enough embedded in that supply chain that we're looking for opportunities to help our customers digitalize the process of getting their product to their end customer. But you don't think about what it takes for that bread to get on the shelf. Well, until Covid happens and it's not there. But realistically, there's a lot of process back there. And how does that package get to your front door from Amazon? Well, it's gone through X number of hands, and it's pass through Y number of containers. And like, how do they do that efficiently and do it at scale? And at the base of all of that is the container that's moving the product through the supply chain. How do you better enable that? And so I think that's the thing I often will tell people about an organization like ours, is that we don't move any of the things that you run into, but we're facilitating again the process improvement and efficiency. Whether that's asset visibility and tracking or it's deploying computer vision to improve accuracy or just making a good quality cart that won't break down for a decade.

Phil: Those are all geolocation stuff. I don't know if you guys know. Yeah, okay, so I'm curious because we do help people find or deploy or implement the right security vendors, MSSPs or products, whether it be no before, whether it be crowdstrike, whether it be all the vendors that of course help from like a neutral standpoint checkpoint, then you got firewalls and you got all this different stuff. When you go through from like if you were to go through and you had like a checklist and you're going down a list for like the necessary things that you would need to have in place in a mid market organization in your security stack, whether it be security awareness and training, siem, soc, endpoint detection response, email security, then just proactive security, incident response, that type of thing, compliance. Where do you go there? Do you have like a menu of services or do you have like a recipe of like. Well we need these things in place and I don't necessarily need to manage it all myself. What things do you manage internally in security and what things do you outsource in security? What's, what's the recipe?

Brian: Yeah, well an element of that is the recipe starts with have to know what it is that we're trying to make. And so that's a component of who is this organization like culturally, physically, what is our strategic aim? Because that has to inform like what we're after. Meaning if you're going to be a manufacturing shop and you don't see a lot of digitalization in your future that impacts how we think about the latent threats that are going to impact our people and impact our environment. If you're however a manufacturing company that aims to be a full stack technology provider who is already in the business or headed towards the business of selling SaaS solutions, again that has a different impact on where the organization is and where they're trying to be. So I think first of all it starts with really understanding culturally who is this organization, where are they today, what are they willing to accept? And then it's secondarily stepping back and looking at that threat model and going okay, what are the things that are most likely to have a direct immediate impact? And so in my book that almost always starts with the things that directly touch our people. So EDR other endpoint Capabilities, identity and email. Those are like priorities one, two and three in my. And really they're all kind of tied for one. But like you kind of put them in an order. It's. We're going to continue to face serious challenges related to identity compromise, endpoint compromise and email. So if I can start there. And that's exactly where we did start. Now, the organization had some things there that I think were heavily ineffective. Now that I step back and think about it, like, the strategy didn't stand firm. Stand firm? Yeah. I'm like, yep. No, it was. They were ineffective. And honestly, there was a why though?

Phil: Because that's important. So like we can just say something and like, we need to learn. Right. Meanwhile, you were coding on and taking apart a computer.

Brian: Oh man. It's a different window. What was wrong?

Phil: Like, what did you learn? What was completely like inappropriate or inefficient or what was the word that you just used?

Brian: Significantly ineffective, perhaps. But like, so one, I guess. And this is a thing that I would say too, and I often, even in my conversations with vendors, will look at a product set, look at a company and say, we're not ready for you yet, or we're past you in terms of the level of maturity that your tool set has. Like, there are times and like I was just having a conversation not about security necessarily, but about endpoint management, which I guess ultimately is a security topic. Seven, eight years ago, we bought a tool because it was simple and easy to deploy. And now it's actually hamstringing our ability to accomplish some of our core goals because the tool is too simple. But at the time I didn't have the staff, I didn't have the know how. And so we picked a very kind of a tool that did more of it for us but was far more limited. Now we've outgrown it. And so I think there's this maturity curve on the journey and I think this applies to technology vendors writ large but very uniquely within security. Where I want to say, like, originally those tools have been procured and then assumed that they were kind of fire and forget. I. E. We put in X tool for security and because for email security and because I'm about to talk bad about it, I'm not going to. I won't just lay it out though. I actually don't know that you can buy it anymore. But the EDR platform really wasn't actually doing edr. It was mostly just like frilly av. But when they bought it, it was probably fine and substantially better. Than what they had because they didn't have the staff to actually maintain an EDR platform and do something meaningful with it. So, great. We're going to go replace that with a much more mature tool set that has an understanding of the ATTCK chain and is going to be able to interrupt in memory issues that aren't just. It's not just frilly av. It is actually an EDR platform. So I think that was an element of where are we from a skills and capabilities perspective? Because if I put in a security tool that we're not ready to appropriately manage or I don't have the funds to pay somebody else to manage it, that can actually cause business to be disrupted in a way that's as bad or worse than having a less effective tool that might still have some security risk in it, but is more the speed that we're running at. And so I think that's a lot of the story is they were incredibly ineffective because the size of the organization, the complexity of the organization and the risk profile were well past where those tools could play. They were kind of in the shallow end of the pool, and we were kind of on that cusp of moving from the shallow end into the deep end, and the tools were kind of out of their depth at that point.

Phil: Do you have a favorite EDR tool?

Brian: I'm a Sentinel 1 shop today. I really.

Phil: I was gonna ask you. I was just gonna ask you. Crowdstriker, sentinel 1.

Brian: Yeah. And why A hundred percent. I, I think the guys at CrowdStrike are doing a great job. So, like, what I'm about to say is, like, not really critical of the platform because I think it's really effective.

Phil: Do you know anything that Sentinel One can do the CrowdStrike can't do, and, and vice versa? CrowdStrike can do that Sentinel One can't do? Just curious. And I'm just kind of like, I'm being very, very nitty gritty about like, some of, of like how I pick these things apart from. Because I do want to kind of get down to like the top. I don't know. It's like, is it pretty easy? Like, when it comes to security, it's like, no, you either go CrowdStrike or Sentinel One. Or is there five options or is there only three options? Like, from a, from a CISO standpoint, is it like pretty cut and dry?

Brian: So here's the thing. I would say I don't think it's ever cut and dry because we're not talking about a static environment. It's to me, much like watching the weather patterns and especially because you have both the pace of innovation on the threat side, the pace of innovation on the protection side. But then you also have the acquisitiveness of the entire industry and these like we're building behemoths where it's like, I'm Palo Alto and I offer you everything. I'm Fortinet and I offer you everything. But on the surface that starts to sound good. And then at the nitty gritty level, really what starts to happen is you realize that like people who are really good at X are only mediocre at Y. And so even if you bought a great platform, building a consolidated platform across the spectrum of the technology arenas that a lot of these organizations are trying to deal in and operating all of them as an A or A plus player is really hard.

Phil: Okay, now we're at the heart of how we started this entire conversation. This is the heart of it. Okay. As a. And you, you are both the CIO ciso. I have Sergio, who was on the show a couple weeks ago. He's also the doctor, literally the doctor. He's literally a surgeon, like a real life surgeon, a CSO and a CTO and CIO at the same time as I do the visionary stuff or whatever. So at what point because what you just said, it's kind of like I call them the usual suspects. When you mentioned Fortinet, Mari, Palo Alto, whatever else, throw everyone else in the box there to the usual suspects. It's kind of like a feeling of like what you go with and like how you like the. The gui's and how it's going to whatever does this integrate? Do I like their access points or whatever it is therefore to manager, is it better to use a MSP or MSSP at that point to help you kind of that's really, really good and knowledgeable and can give you an extra bench of players to help manage all of these various different aspects with your guidance and visionary and ultimate review there.

Brian: I'm going to answer this question as a guy who has just parted ways with our MSSP and we've now like in source everything. So I think it depends a lot. There was an arena of time where between the staff that we had available the mind share that we had available for all of the transformation that needed to happen across the entire portfolio, where having a partner in the mix doing work on our behalf was beneficial.

Phil: Meaning when you have a big forklift at the beginning of an organization that hasn't really ever had Security in place and you need to make moves really, really quick because things are on fire and dangerous and you're going to get ransomware attacked and all kinds of holes and everything. That's where an MSSP really helps. You're saying in the meantime?

Brian: Yeah, it definitely helped me. And by that I mean, like, I, as an executive, I was also the first line incident responder for four years.

Phil: Okay.

Brian: And meeting like, if there was a security issue happening, I was usually the first one to stumble to it because I knew what the telemetry was telling us. And we brought in a partner because I couldn't keep doing that. Like, I did literally never had a day off. But the thing that's going to be interesting and like, I'll say a thing that may or may not sound controversial, but like, part of the reason that, like, I think the traditional SIM model and how it relates to how MSSPs deliver services is kind of broken. And. And by that I mean, like, I think about the biggest behemoth on the block from a SIM perspective, the very first SIM I deployed. Now, subsequently, I think I've probably deployed everything in a lab or in, in real life. That's probably a stretch. But like all the big players I've touched personally, and I would argue.

Phil: Can you list those, please? Just, just list off the big players that you've touched. Right now I just need to have them.

Brian: Well, I think so. Splunk is obviously the biggest. In my mind, they have the biggest name recognition in the space. That was the first one I did. But you think about whether it's Exabeam, slash, elasticsearch, which I got into elasticsearch before they had a security platform and really loved it as a data ingestion tool.

Phil: Is that the open source? They're open source.

Brian: They are an plus, meaning they've got an enterprise security module that sits on top that may or may not be open source, but it's a really strong kind of play. But then you've got qradar.

Phil: But what did the MSSP use?

Brian: It was Splunk. And part of it is like I stayed away from Splunk personally for two reasons. One, it's incredibly pricey and I think the licensing model forces you to make some bad decisions. Meaning from a security and threat hunting perspective, I don't want to have to be budget conscious about the amount of data that I'm sending. I'd rather be budget conscious about the amount of output that I'm generating. And that's a place where elasticsearch really kind of shown it wasn't an element of I could put as much data through it as I wanted to. Granted there was an underlying system cost to it, but really what I was getting out of it was that the output of the net value in terms of incidents, threat identification and ability to identify where we had issues. But I think the thing that I'm finding that's really challenged now is that one of the elements, and effectively we have now brought on Board an AI SoC platform that has completely supplanted what we're doing with our SIEM platform. And so like we're literally no longer feeding data to a Splunk instance or a traditional SIM at all.

Phil: Okay.

Brian: And so the framework of that is we're now putting all of our structured SIM like data, all of our log data is being down tiered into S3 with an MCP server sitting over the top of it so that I can query it just like I could query Splunk data across the long tail of compliance. But then we've got an automated platform that's augmenting my internal SoC, both doing the threat hunting and automating remediation in the playbooks where my staff is really comfortable that we've got high fidelity kind of telemetry.

Phil: Sounds pretty awesome.

Brian: Yeah. I mean, and I'll tell you, we're. We've been working with this organization for 18 months. We've been fully on their platform for all of like four weeks. We've been using it for a while and they were actually getting us better results in a trial in a POC that for some reason they let us keep running for a year. But we were getting better and faster threat identification from that than we were from our MSSP with Splunk with a SOAR platform with all of these tools, we were getting faster responses and more accurate like we were identifying things that the MSSP wasn't even finding. Just part of why we parted ways.

Phil: Okay. This is like a white paper thing. It sounds like unless you know an MSSP that's doing everything you just said,

Brian: I don't know that there are yet. I've talked to some who agree that their work has to change because like I think that's an element of like you, you might still run into MSSPs who are taking this aggressive AI focused approach and still able to deliver on behalf of organizations where the staff and the expertise doesn't exist to be able to bring it in and do it on their own. But it's like their model doesn't necessarily yet drive them to do it in that way. Meaning there's a lot of guys doing it the old way where you've still got a big 800 pound gorilla of a sim platform and you've got a team that's staffed and you've got real people doing threat hunting and they may be doing a little bit of augmentation, but they're not thinking wholesale about transforming the space. And I think sim as a concept will be transformed dramatically in the coming. Call it 24 months because.

Phil: Okay, so sweet. So that's a great transition to what your 18 month prediction would be of what everyone will be talking about 18 months from now that they are not talking about today. It doesn't have to be security.

Brian: The way that I would answer that question is going to play itself out I think equally well across technology realms. I mean one, I think it's realistic to expect that we're going, I hope we're having a very focused conversation about how AI is really an effective augmentation of all of our human capital that like what we're really trying to do. And this is like an element of thinking about the future of work that is like, hey, my job isn't to do the task. My job is now to shepherd the system that does the task and to deal with the exceptions that are easier for a human brain to kind of wrap wraparound. And I feel like there's a lot

Phil: of eliminating $10 an hour jobs.

Brian: I think changing the nature of 10

Phil: college worker like yourself should not be doing $10 an hour tasks.

Brian: Fair, right? So yes, all of the things that like I could have an assistant doing or that I could have an intern doing today, I think the answer is those things become heavily automated or heavily augmented or we finally recognize how many of them just aren't valuable and we stop doing them. But I want to be cautious because like to me what that means is that the nature of the actual $10 job changes. It's not that it goes away, is we have to think and honestly security has suffered from this right where we've landed in a place and I see security leaders all the time kind of making conversation about it in which we're trying to hire an entry level role with like 85 years of experience in security, but it's an entry level role and it's like, well, okay, but what you're saying is that you're looking for people who have the problem solving capabilities but none of the background necessarily in the specific tool set. And so we tend to identify those people based on the history of their resume, not necessarily based on the quality of interviewing or like, it's a really hard thing to evaluate. I think the same thing with AI. It's like I'm going to go in and say that that $10 an hour job really at its end, what we're finding is that there are pieces there where it's still really hard to focus an AI or an automation platform on every potential corner case. So there are going to be cases where it is cheaper, faster, better for me to continue to pay human eyes to get on it. But now what I need is I need that 10 an hour job to be somebody who knows that 80% of the work is being done by a platform. The last 20% is their responsibility. And how do we help feed them enough of those things to keep them busy, but without making it a $200 an hour job. And because again, you've got to grow people into these spaces. We have to take from where people are, whether they're already in your organization or not. They have to learn a new way of thinking, a new way of problem solving. And we have to facilitate that. And if we don't, what we're going to do is we're going to see a lot of expertise just walk out of our organization because they don't, not only do they not feel value, but they don't feel like they can keep up.

Phil: That just stressed me out. That whole thing, that whole thing just stressed me out. I'm just thinking of my own team and I'm just thinking of our own. Like, but I mean, we have a really, really, really good, kind of like, I would say I have a very, very good integrator in AI. We're trying to figure out how do we use basically in a safe way, Claude Cowork? Because that to me is like, it's a. I don't. I, I promise. I actually kind of want to ask you, the security guy, like, are you paranoid that someone might be using Claude Cowork? And how do you stop that? I. It literally took, I mean, because the initial kind of like is like, just took control of like my drive and took control of this and this and this and it did all this stuff. And I didn't really think about the consequences until next week because I got all this work done or it was like, it was kind of like, just take care of my. Can you please just go online, search, pull all these, like, I don't know, EPS files for these logos that we need to put into a marketing document and you can Just pull all that, because normally that would be like a $10 an hour job of like some marketing slick maker PDF maker guy. Right? And. Or some dude is going to use cloud cowork and it's just going to take control of his browser and just go pull that stuff on the side while he goes off and does his other piece.

Brian: Yeah, it's that question that has us always looking at whether or not we should be adopting an enterprise browser or some other capability, whether it's an island or putting Seraphic in the middle of our things like looking for deeper level controls around how we manage that attack surface. And we haven't made any of those leaps yet, in part because we're just about to actually standardize to a single browser. Like, we've been pretty heavy on kind of choose your own adventure when it comes to some of these elements. But the way the threat landscapes are evolving, and that's both related to AI and how easy it is. But even things like identity landscape problems where people used to say, oh, well, you've got MFA on you're good. It's like, well, guess what? Attackers figured out how to screen scrape and like, and effectively circumvent even mfa. And so now you've got places where, when you've got really dedicated folks trying to get into your organization through the identity landscape, the browser becomes the number one. That pane of glass that you're putting your credentials in becomes one of the most key problems in front of us. And so how do we improve that? Well, we can't really do it as long as we're in choose your own adventure land. So, like, yes. I mean, the short answer is absolutely worried. We're doing what we can to bring visibility to it. The problem, I feel like, as a security leader is that I need all of our nearly 2,000 employees to be conscious of the decisions that they're making. Meaning there's things that we try to like, hey, I'm going to try to keep viruses out of your inbox because I'm worried that you won't operate like a security professional and you'll click on a thing without thinking about where it came from and were you expecting it and is that real? Because if I could get everybody to think that way, then I actually probably wouldn't need as many tools. I'd go, great, you're never going to do that.

Phil: Or people don't give a crap, you know, but I don't give a. What you need to do is make everybody love you. You just need to make everyone It'd be easier to make everyone love you and want to be your friend than it would be to do that. That's really probably more effective.

Brian: I think it could. I mean, maybe. But I guess I would say this. I don't think it's that people don't give a crap. I think it's that they just simplify things they don't understand and they don't have a way to like really get in touch with the problems that are sitting there.

Phil: And do you ever drive down the street with your seatbelt off?

Brian: Well, no, that's dumb and it's against the law.

Phil: You know, do other people. Because they just think, well, I'm just going a half mile away to McDonald's because I'm freaking starving or I need a cup of coffee or whatever it is, or I need like, do you ever think that maybe they're just like, and I've got this other thing in my hand and I got anything. Do you think the people just like don't put their seatbelt on and drive down the street?

Brian: Well, but I think that's the thing. I think the answer is yes. And I don't think it's because they intentionally don't care. I think it's because they don't fundamentally understand the risk.

Phil: Maybe, Maybe. Okay, so I guess that's my point is you've got the 8020 rule is true at the bare minimum, right? Yeah. If it's a matter of when and how bad the breach is going to be.

Brian: Well, and I agree. I just think I may be responding more to the fact that I don't think it's that people like when it comes to secure and granted, I'm speaking from a context in which I work for a family owned company that values family as a concept within the organization. And so like I would just argue most of the time when I interact with people it is not that they don't care. It is more often either that they were ignorant of the risk that they were accepting or they didn't understand the complexity of the thing they were dealing with. I mean, this is one of those challenges. You know, I was just sitting through an internal QBR last week and like one of the things that has been eye opening for the organization is we've started to do a better job of demonstrating because like somebody asked me, hey, how come you only take on X number of projects a year? You've got all of this staff sitting over there and we're funneling all these dollars into it. And I was like, okay, hold on, let me like open the kimono for a minute and show you the four million things we have to do operationally to keep the lights on every day. And then you'll know why. The lion's share of my staff is in an operational role taking decision direction.

Phil: Out of the five things that we've ever asked IT directors, what are the biggest struggles they have? One is training end users. Two is taking decision direction. Three is antiquated silos. But let's just leave it at those three, even if we just let it up those three, because I'm not spacing on the last two, which might be like convincing executive management. It might be something like that, speaking to executive management or whatever. And there's a debate over whether there really is a fifth one or is that, should that be merged with another one. So training end users, taking decision direction, antiquated silos. What you're talking about is basically like decision direction and the onslaught of projects that the average IT guy has it, if he was to actually complete them all, it would take 25, 35 years or something like that. And, and the challenge is, is how do you really kind of roadmap things in a way that is in alignment with selling more trash cans? Okay, like how that, that's really actual, like a really important project. So please answer that question where that person said, you have this big staff, you've got all these things, why can't I get my new wireless mouse with AI speakerphone?

Brian: So one, there is no easy answer. And I say that because at the end of the day you're dealing with the challenge that because people don't understand the complexity, they assume the thing they're asking for is simple. And the result of that is there's a lot of frustration when it's like, actually I need seven resources in nine months to do the thing that you're asking. Because I know you think it's simple, but in reality it's not. And so an element of like what we aim to do is, as we're looking through the portfolio, like, I've got three kind of strategic focuses at three things that we're focused on. One, we have internal projects running internal to it, whose sole purpose is to drive work out of the system. Whether that's just pure reduction of technical debt or improvement of process. Like we're making a big shift this year. It's like, hey, I need a self filtering system and I don't need to just clean it up one time. What I need to do is build a process around managing it. That is meaningful, that is like, I'm going to automatically deprecate objects that are, that haven't been accessed or haven't been touched or there's no activity on in a certain period of time. We're going to tear them out immediately because we know they're not there. I mean, they're ephemeral. Where before we were super concerned and now it's like, look, I really just need the system to clean itself and I'm not going to invest people time in doing that. We're, I mean, and we're thinking about that like, I need to get out of the business of my cloud services staff being there, clicking buttons like, no, they're just, they're writing code now and when we're, when we're redeploying environments, they're doing all of it. And I know infrastructure as code is not new, but like adopting it and ensuring that the entire top to bottoms architecture supports it. It's new for my organization, but most organizations are like kind of sort of there piecemeal, unless they're a startup and they were born in the cloud and that's how they did it from day one. And so like, we're downstepping away from investments with VMware so that we get to a platform that is like really going to be supportive of that. So, one, we're heavily focused on things where I can immediately say we're going to return bandwidth to IT staff so that our operational work just gets easier and easier, with the goal being that ultimately the balance of operational to transformational resources starts to shift towards transformation. And that's a place where, whether we're using AI or we're using other automation tools, it serves the need both of making you wait less time for your AI powered speakerphone mouse because there are fewer human hands in the process. So when you summarize the title of

Phil: that process, again, it's to get away from something, to create smoother operations, to do more.

Brian: Yeah, I would say we're up tiering the type of work that our operational resources have to do so that we rebalance and we have more resources focused on transformation than we do on operations.

Phil: Okay, all right. There's two things there. One, I'm sure everyone out there listening would love to know how you're doing that. But more importantly to the theme of the show and what we're trying to do, which is, like you said, it's very, very difficult to kind of like explain this to people is, hey, just have them listen to this. Podcast you've been heard, so that we're translating to the executive look, I was on this podcast the other day. Just listen to it, then go back to me, okay? Or at least listen to this blurb the last however many minutes of it. Please explain. And we should have this portion of the show that's like, explain EDR to the C suite. Go right and then now and explain your problem so that you have been heard, right? So that you're actually heard. Because their problems are EBITDA bottom line, flow through profit, stock investor pressure, whatever it is, stock buyback that we are initiating due to our 100% go with AI. So please explain what you just said in layman's terms to the board.

Brian: Honestly, it's relatively simple, right? It's all about throughput, right? At the end of the day, if we look across the organization and again, I work for a manufacturing company, so it's very easy for me to describe the fact that just like we think about in manufacturing operations, I need my dollar per pound number. My net throughput has to go up in order for us to improve the bottom line. Well, from an IT perspective, we're not talking dollar per pound, we're talking ticket per dollar or ticket per hour kinds of things or task per hour, right? So we're translating those metrics into things that I think makes sense from an understanding of.

Phil: Great. What are the. What are they? What are the KPIs?

Brian: Well, I mean, one, we actually do present a net dollar per operational task. So, like, it looks like a throughput dollar amount that's like you need X amount of output for the organization to operate. I have options. I can either take steps out of the process so that my cost per thing goes down, or I can speed up without increasing resources, meaning just move faster. In both cases, I get to spread my fixed overhead across a bigger array of things. And as a result, my throughput goes up. In theory, if we're doing it well, our customer satisfaction goes up, but we do it in a way that then I actually don't need as many resources on the line kind of doing the operational tasks.

Phil: Beautiful. You just answered that as a CTO and a cio. Now I want you to answer it as the ciso. How does that apply to security?

Brian: I think the thing that I would say is we talk a lot about decision quality and how decision quality impacts the, like, relative riskiness of activity. And it's like I think about things like we're driving out human hands in the process of provisioning services and managing Firewall rules and, you know, provisioning VMs. Well, part of that means I actually have better visibility to the types of things and the configurations that our engineering teams are putting in the wild. Which means that from a security perspective, I can actually better predict how the risk profile evolves over time. I can measure drift. I couldn't do it before because people were pushing buttons and now I can sit here and say, well, I've got declarative statements about how we're configuring services and what firewall ports are open at the host level that before I would have had to run discovery after it was in production to understand what was happening. So we're moving the security control and assessment phase earlier in the process. So that is the minute one of my systems engineers puts IAC code in a repo. We're now looking at it from a policy perspective and asking the question, does that mean our compliance requirements? And if it doesn't, and by the way, that's a check, it, it's not a deployment. And so just like we're selling, reporting,

Phil: you're selling, the sale is reporting. Okay.

Brian: It's more about stopping and changing it. Just like we won't let code go into production. Like if our software engineering teams are working on a product release and all of a sudden they pull in a third party library that's got known vulnerabilities, we stop the deployment. And so we're doing the same thing with IAC to say, like, hey, if you're not meeting minimum standards, I'm not going to allow you to execute that action. I'm going to stop it, I'm going to force you to fix it right there. And we're going to, if we can automate the fixing, we're going to do that.

Phil: That's like the Phoenix project. What do you do? How do you explain that?

Brian: Well, but part of it, right, is like it, it does change the expectations on their job. They should know ahead of time, empowers them.

Phil: Yeah, yeah. Does that move any further through the organization? Like not just technology, like does that move any further into sales, marketing, OPER and any other kind of visibility that security actually could provide that would be useful to the bottom line?

Brian: Well, and I think there's no shortage of those things. Like, I mean, I would look at just like we're spending a lot of time thinking through kind of similar patterns of thought with finance, right? Which is like, hey, if I want to prevent fraud, if I want to prevent some of the types of attacks, because obviously any attack that a Malicious actor can perpetrate that is directly monetizable, whether on our behalf or on the behalf of one of our customers, that's got an immediate payback. It's not a shot in the dark. So similarly, thinking about how do we implement systems and processes that automate more of the everyday tasks but then have the overlays of things like, hey, that's a weird pattern. Hey, that's not normal. Let me identify that for you as a pattern of a financial transaction or even a pattern of an email discussion about a financial transaction that is not normal and put friction into the process where it's not normal and allow the others to move through faster.

Phil: Okay, I understand that. Seeing a pattern that's not normal.

Brian: Yep.

Phil: Are you saying from like, people that are not really, like, shouldn't be communicating in, in this way with the company, or are you saying it's internal company people communicating in a way that they shouldn't be communicating openly about that?

Brian: Yeah. Well, think about it this way. Like, security folks talk a lot about user and entity behavior analytics with regard to understanding. Like, hey, that's the first time Johnny's tried to RDP to the server and he's doing it at 2:00am 2:00 clock in the morning.

Phil: Yes, yes, yes, I understand. All right.

Brian: Okay, so now you've got some level of like, normalcy that you're like, well, that's weird. And it may only be weird because you've never seen it before. And so like, you think about that where it's like, okay, can I put in systems related to financial transactions as it relates to vendors or customers, where I go, hey, I've been having regular email communication with this individual for years. They've worked for this organization. They've been responsible for processing transactions, for sending us invoices, for sending us remittance, all of these. Like, there's now a history of this behavior. Can I apply that same methodology? Even in ways that you say, hey, that person never emails me. I mean, and again, never emails me at 2am but now all of a sudden I'm getting 2am emails from even an individual that I've operated with before. But that's new behavior. Now I want to slow that down and say, I want a human to look at that versus, hey, this is normal pattern. We're not changing things. There's no change of ach information. There's no change of like, everything is running exactly the way it has been and we've got good kind of, I'll call it soft authentication, which is like the invoice number I sent you, the amount. You've got enough points of verification that what you're telling me is valid, then I don't necessarily need human eyes on it. But then when something's not matching that, then I'm going to go, okay, let me drop that out of an automating queue and let me put it back in the hands of somebody in AR AP to just go, hey, okay, this, this is a thing I need to look at. And then training those staff members to go, okay, if it hits me, that means something's weird. So I need to be. I'm not just processing the general ledger entry or processing the invoice or the payment. I'm actually. Now, my job is to ask what's weird about this and validate if it's real.

Phil: This is a such an amazing conversation. We haven't even gotten to like the last three bullet points. We haven't gotten into it. We kind of talked a little bit about AI and cloud transformation. Kind of like on the security end and security piece, the cloud transformation. I mean, we could have a whole nother podcast would invite you back to talk about the VMware Broadcom debacle and all that type of stuff. Where is that really going? How are they, how can they do that? I always wonder how a company can actually do that.

Brian: I mean, if people are willing to pay it, if it doesn't cost them enough business, then the consequences of the action aren't big enough and so they'll keep doing it. But I, I think that's the thing. It's like, I mean, a very simple example. The, the sheer.

Phil: What's your prediction there, though? Okay, so, so what's your prediction there on the VM Broadcom? Do they just basically like sync a company on purpose or just, I'm just curious, like, or is it so big that it's like we don't care about the other ones that are just going to leave because these behemoths that can't leave us. Is it one of those things where it's like, it's so sticky. It's like existing without Microsoft. It's like existing without Microsoft. Can it happen? Could everyone decide to just move to Google one day? They could. Are they going to? Probably not.

Brian: And I guess I would say, like, people said very similar things about BlackBerry. It was sticky. You're too embedded in the process. You've got too many big guys who aren't going to retire, Bez, et cetera. And obviously that hasn't proven to Be true. I do think there's an element of like, if I'm Broadcom and I go, well, traditional kind of VM infrastructure is now on a fixed course to its long term death. Right. That like service bus and like cloud native service styles, whether they're run from a private cloud or run on a public cloud or whatever. Like in the long run, the flexibility, the core tie to net cost and the lack of having to pay for overhead you're not using, that has to be the way the future operates. Especially when you look at the density, the power constraints, the water constraints, all associated with data centers and like managing.

Phil: So we're just going to milk it. We're just going to milk right fast.

Brian: And so, yeah, let's just get as many dollars out of it. Let me ride this train as fast and as hard as I can, knowing it's going to crash soon enough. Now, I think the hard part for them is they're probably accelerating it.

Phil: Right, okay, good.

Brian: Yeah. They're going to force organizations who would have been happy to just continue riding the train.

Phil: The COVID effect has become the Broadcom effect.

Brian: The Broadcom effect, that's fair. And so it'll be interesting to see because you want to look at that and go like one. If they were turning those dollars into an innovation pipeline that built more flexibility into the VM stack so that their existing customers had a reason to stay, had saw value in the 4 billion percent increase. Seeing that we bought a cash cow and I want to get as much cash out of it as I can. And if I end up killing the cow in the process, well, okay,

Phil: amazing. Yeah.

Brian: Oftentimes I'm sitting in my staff meeting and I have a bunch of great directors that work for me. But often we're sitting in there and we're having lively, healthy debates about either technology strategy or a business problem. Or like it's an animated set of discussions because we're trying to create some things, but in the middle of incident response, like right now, I mean, it's the difference between being at the command and General staff college, playing a war game and actually being on the battlefield as a general. Well, when I'm on the battlefield, like there's real circumstances. We're not talking theory now. Now there's plenty of room for debate in some of the things that we need to go do. But the fact is the patterns, the playbooks are well established. And so really then my role overseeing incident response becomes providing air cover where I can helping evaluate the business risk that my incident responders can't necessarily do communicating with executive staff so that they understand what's happening and what we're doing. Being the guy who's willing to go call the CISO at a customer and have a one on one conversation about something that may or may not impact them in the long run. But it to me, we're no longer creating a thing, we're running a ship. We have a lot of confidence that it's going to weather the storm, but that doesn't mean it's going to be fun. But we know what we're doing and so we're going to get to business. And so that's no longer an animated conversation necessarily.

Phil: Yeah, there's a big difference. Like we talk a lot about in my organization, like, look, there's a difference between practice and being on the field of play where the score counts. And if you don't keep score, how do you know who's winning? You're taking it a further level. You're saying like we're not even playing a game anymore. We don't even care about the score anymore. We just care about winning the war and then with as the least amount of casualties as possible.

Brian: Yeah.

Phil: And then I think that those are the conversations that I think C level executives that may not understand the language that we speak all day long should be proud to have and should be speaking as it says, it speaks more volumes about the organization. Let's end with this. If there was one thing that you wanted the not necessarily like your C level executives, but it does apply to them. But they may already know. But if there is one thing that you wanted executives to hear across the world, the C level executives that are come in with a, like I want my AI plan like on my desk tomorrow. Where are we at? Like the. Can't we just like migrate all this stuff to the cloud? Like what's the message to those people that you want them to hear loud and clear?

Brian: I think the simplest version of how I think I would frame this is this. There is no shame in having a focus on incremental innovation versus being a transformative leader. It doesn't matter which you are, but you need to know which you are. Because I can't serve the guy who is really up for the risk tolerance is incremental innovation. But the appetite for change or efficiency gain or splash is transformative. Those two things create more conflict in my organization and in the organizations that I've worked with historically than people who kind of know what lane they're in and are very comfortable in it and then planfully approach changing lanes.

Phil: Okay, break down that. What creates more conflict? Again, the type of guy that does this but is unaware of this. Yeah.

Brian: So like in the like tongue in cheek example of I want my AI plan on my desk tomorrow, it's like, I'm happy to do that for you. We can build a plan. But I need to know, are you asking for a dramatic rewiring of how your organization functions through the lens of AI, or are you simply trying to achieve an operational aim which is like, I need to tell the mentor AI

Phil: in yeah, I need to augment certain areas and I want to make sure that we're being efficient, that we're at least using the tools that people are aware of it. Do we have like an AI steering committee and roadmap that's concerned with making sure that we take the baby steps towards, you know, implementing this or. Yeah, or you going to just fire like a 200 heads tomorrow and say we implemented AI.

Brian: Right. And I think that plays itself out in a lot of non AI contexts in which it's like, hey, what I really need is you think about sales. You, you were talking about the CRM earlier, right? Like, what do you actually need as a sales leader? Well, I need to close more deals. Okay, well let's sit down and talk about what does that mean to you? And do you need to close 50% more deals or do you need to close 5% more deals? Because if you need to close 50% more deals, your level of crisis in understanding your business process is really high. And as a result, your appetite and your willingness to change and make critical investments is much higher. But if I come to you with a plan that's transformative and you're like, actually bro, I just needed to close like 5% more. It's like, okay, well I could have done that with like incremental continuous improvement style work. And that's the level of investment and that's the change appetite that you have.

Phil: Have.

Brian: But where those two things are in conflict, high appetite for results, low appetite for change or investment, we can't make that work.

Phil: So you're like a psychologist also. So the CTOs and CIOs need to make sure to tell people like, hey, look, like what, what's more appropriate? Do you want to make incremental changes? Are you willing to make these big massive changes? If we have to make these big massive changes, it means like a lot of sleepless nights. It means a lot of extra work. It means this, this, this and this. Are you prepared for for that, or do you want to just keep showing up every day to the good old boy network and we just kind of make it the good old boys and we're going to layer in some of the good new boys at the same time and keep drawing.

Brian: Yep. And neither path is bad, but if you don't know which path you're on, we're going to have some conflict.

Phil: Well, it's kind of like it just depends on, like, how you approach it, I guess, is how it could be bad or good in either scenario. So.

Brian: Yeah.

Phil: Brian Rowe, it has been an absolute pleasure. This has been outstanding. This has really, really been a lot of fun. I, I thank you so much. And you've been heard. Thank you.

Phil: All right, let's go. Talk to me. How'd you get started in this whole wildness? I think I should take a guess. Was it like an Apple IBM, or was it like Commodore 64, maybe Pentium 486, 586 or something like that?

Brian: Oh, no, I was. A little earlier than that. I remember my dad came home with. I think it was a Hitachi, maybe Noah Hyundai.

Phil: This is great.

You've Been Heard - IT Leadership Podcast logo

You’ve Been Heard

You’ve Been Heard is where IT leaders stop being sidelined and start being amplified. We’re the triple-threat platform: podcast, community and vendor-neutral advisory that elevates your voice, your value, and your influence because when IT leaders rise, so does everything else.

© 2025 You've Been Heard. All rights reserved.