Learn the System Before You Change It
David Brockmyer explains why cybersecurity transformation should begin with understanding the business, its people, and the decisions that shaped the current environment. He shares how leaders can distinguish true inefficiency from necessary friction, resolve ownership conflicts, build trust, and sequence change without disrupting what already works.
Effective transformation starts with learning why the current system exists, preserving what still serves the business, and creating clear accountability before introducing major change.
Episode Chapters & Full Transcript
Select any chapter or transcript timestamp to begin watching from that exact point in the episode.
Full Transcript
Welcome to Conversations with CISOs, Security Leaders and Technology Executives, where we sit down with the leaders shaping cybersecurity and enterprise technology. Today I'm joined by David Brockmyer to discuss cybersecurity transformation, learning the system before trying to change it. David, thank you for taking the time to join me today. To get us started, could you introduce yourself and tell us a little bit about your background and your current role?
Yes, I'm David Brockmeyer. I am a technology executive. I've been working in the technology field for about 31 years, I guess, starting out as a systems engineer, working my way up to CISO and now doing independent consulting. And really focused on cybersecurity for the last 15 years, where I think I really found my calling.
Excellent. So, what should a security leader learn about the business, its people, and its existing security program before developing a transformation strategy?
So before developing a transformation strategy, I think it's really important to understand the business risks and the business operations as they exist. Learn about the constraints and the decisions that have led them to the position they're in so that you can start with a good understanding of what you need to preserve, what you need to question, and what you need to adjust over time.
And how do you, when learning about the business, how do you distinguish between a process that is genuinely broken and one that only appears inefficient because you don't yet understand its purpose?
You have to understand how you got to the position you're in and whether the friction is in place because it's protecting something or because it is actually a true inefficiency. So again, I think it's important that you understand what led the business to the position it's in prior to making decisions about major adjustments. That's not to say that you shouldn't make adjustments quickly if you see that there's a challenge that needs to be resolved. But give yourself the breathing room to understand before you make big decisions.
So can you walk us through a cybersecurity transformation where the technical problem was not the hardest part and what ultimately made the change difficult?
Yes. So when I joined VSP in 2017 there was an ongoing identity governance and administration project that was developed based on some older technology. The technology wasn't that important, but the challenges were that there were just disagreements on ownership, accountability, and who operates what in what way. And then, in addition to that, there were underlying technical structural problems, things like in the directory systems that made it really difficult for that project to continue and succeed. I ultimately ended up pausing that project, reviewing the threats to its success with the other directors in the organization, with managers and with technologists, to learn what the structure was that was causing the program to not be successful, then I integrated that into the three-year roadmap that we've developed at VSP to modernize the cyber operations there, including identity governance and administration.
How did you work through those ownership disagreements and how would you recommend other cybersecurity executives work through ownership disagreements that may come up during their own cybersecurity transformations?
The best thing to do is first again understand how the structure got to where it is. There have been times when I learned that there's a structure that was unfamiliar to me, but it was just as functional as the structure that I had grown accustomed to. So I worked with the other directors at VSP to adjust my thinking to that structure, for example. There are places, though, where you have to say, How can we generate accountability and drive it through metrics and proven results to ensure that we're all doing the best we can with the system? Then we can have tougher discussions where we say this could be yours, this could be mine, but we need to agree that accountability means this. And it's important that we understand that so that we can support the business. And then there are times when I say, maybe you have to own it because this is a portion of your technical operations business. Or I say that I have to own it because it's part of the security operations business. And we need to be able to clearly delineate those things. At the end of those discussions, we should have clear accountability and clear direction on how to achieve that accountability through either technology or standardized processes. That's what I did with the Identity Access Management program at VSP.
So once you understand the system that you're trying to change, how do you determine what should be changed first and what should be left alone?
In order to be successful, you need to understand, I need to understand how I'm going to affect the best change for the business. The best change for the business may have different characteristics. So, for example, when I was at Intel and I was managing the data centers in California, we were trying to consolidate power in a space to complete the transition from a large data center to a small data center because we were constrained by power and cooling, but not space, because the rack densities were getting so much tighter. And working with the facilities team, with the engineers and the facilities team, we were at a disagreement in terms of how dense we could make the power supplies due to what was a historical concern about safety. I worked with them to understand what that safety constraint was. And whether it was a legitimate constraint based on current technology or whether it was more of a historical or cultural constraint. We ultimately decided to raise the density to the level that I had asked for. But in order to do that, I took full accountability for the safety of the project and the outcome of the project, which was normally something that I would give to the facilities team to complete with their standard processes.
So speaking of those cultural dependencies, cybersecurity outcomes rarely depend on the security team alone. How do you identify the different organizational dependencies and decision rights, incentives, and constraints that may affect a transformation?
That's the most critical and sometimes the hardest thing for me to find. So what I like to do is take a procedural approach to identifying those things. I start by working within the information that's been provided to me. Like at VSP, I was provided with a series of audits and a series of action items that had been recorded in ServiceNow that were owned by my team, but they didn't really have an understanding of how to get the right people involved. So I used those, which isn't really the happiest way to introduce yourself, but I did use those to start introducing myself to my peers at the director level and the leadership at the vice president and CIO level to help get an understanding of how they saw it happening in the past and then what would be our path forward over time in the future. That gave me the ability to start breaking down the problem into solvable chunks that we were able to put into our short-term, medium-term, and long-term roadmaps to get the program from the as-is state to the to-be state, trying to preserve the partnerships and the relationships as best I can while realizing that I was on a schedule that was required by the COO and the CEO to make this transformation happen.
So speaking of those relationships with business leaders and other security practitioners, how can cybersecurity leaders earn the trust of those security practitioners and business stakeholders before asking them to change the established processes?
The best way that I've found is to maintain transparency and try to maintain accountability and try to maintain clear lines of communication wherever you can. If you are transparent, if I'm transparent about what I do with my partners, then they understand what I'm trying to accomplish, not only what I'm trying to accomplish, but why I'm trying to accomplish it. If I maintain my own accountability and make and meet commitments. It's something that I learned at my very first days at Intel and it sticks with me to this day. You know, be transparent, tell people what you think and put your ideas on the table. Be accountable, make and meet commitments in a timely manner. And then help them by understanding what their constraints are and helping them either move their constraints or prioritize based on the security requirements as they relate to their business.
So as I'm sure you know, working in large organizations, cybersecurity transformations can easily become multi-year programs that struggle to demonstrate progress. How do you balance the long-term structural changes with the need for daily wins?
That's a great question. The need for daily wins is going to come through the transparency in my operation. So when I think about what I started with, let's say in the security operations center at VSP, we had a functioning security operations center that I knew needed some updates to catch it up with modern threats. So I started by making sure that I was able to deliver clear metrics to my management that helped them understand what our operational effort was going towards. And then with that, I was able to say, but this is what we should be doing, which enabled me to build a six-month plan to start making adjustments to the operation. And then the longer term plans were able to build on top of that. So we started with the technology that we had and the small team that we had. And we said, right now, if we're able to add somebody to add a junior analyst to help our two senior analysts then we'll be able to build it out a little bit more and start enabling those senior analysts to look at the long-term problem and help us look at a modern SOC, a SOAR implementation, a better relationship with our L1 and L2 partner. And we did that over the course of three years. So we started small, so we got our wins, we kept measuring them and delivering them because you've got to keep that visibility on the program. And then we said, okay, now this is what we need to do next, and this is what we need to do next. And we transformed our SOC of two people and a small MSSP to an appropriate SOC for the company of VSP, which was outsourced L1, L2, a modern SIEM, a modern SOAR architecture, and then a staff to support it. both from an operational and an analytical perspective.
So that SOC transformation is a great example of starting with the problem instead of starting with a tool. Have you encountered that in another area of cybersecurity?
Absolutely. And in fact, the description I gave you about the identity governance and administration challenges that we faced early in our transformation at VSP completely applies in almost the same way. In that case, we had bought a tool believing that it was going to help us solve our governance and administration. A lot of people who have experienced a governance and administration transformation recognize how challenging they are. And our problem was, or our biggest challenge was that we hadn't solved some of the underlying concerns. We hadn't solved all of the accountability, responsibility aspects of the business process, and we hadn't cleaned up the foundational layers of an identity and access management and identity governance administration program. So the first thing we needed to do was work together with our HR partners, with our IT partners. and with business partners who own different software-as-a-service platforms that they're administrating independently, to identify how we were going to govern this as a team. Because as you know in healthcare, it's critical that we have very clear procedures we follow so that we can maintain our adherence to our governance policies, which was HITRUST when we completed it, but it was ISO 27001 when we started it. With all that in mind, the team had purchased a tool that was not going to work, not because it was a bad tool, but because we didn't fix everything underneath it. And some of those structural changes were long-term changes. This is a 60-year-old company we were working with that had an Active Directory that had been around since the 90s. It had a lot of legacy decision-making built into it that needed to be corrected for automation to work. So we started our strategy with let's get our accountability and responsibilities aligned among the stakeholder teams. Let's understand what technical debt we need to resolve in order to be successful. And then let's build our three-year roadmap on adding platforms to the identity governance and administration capability. The timing was fortuitous because We were able to instead of using a legacy on-prem solution, we were able to use a cloud-based identity governance and administration platform that was growing at about the same rate that we were. So we were able to bring online our basic functionalities once our tech debt was resolved to the point where it needed to be of identities from our HR systems, our identities and our users from the directory services, started integrating into Azure and then start building out from there. The beauty of what we did, and it did, it took us the full three years, is we started with five administrators who were working tickets through their email system because again we had to have accountability, and that's where it had to come from. They were doing our access reviews which had to be done quarterly. We were always behind. We always found gaps or we didn't have an email or couldn't find a spreadsheet. Well, we found the spreadsheet. We had to work hard though to make sure we had everything aligned so that our partners in audit could easily see that we were doing things right. As we progressed, we were able to reduce the number of headcount required to physically enter users from five down to two, and then eventually one. And we reskilled those people so that they were able to help us accelerate that progression, move into program management, maybe do a little engineering, and help the overall program. So that was probably my favorite example of how we transitioned the manual process that was problematic in certain ways to an automated process that enabled us to be more effective at running the identity and access management and the governance aspects of the program. It's kind of similar to what we see happening right now in the AI transformations that are happening everywhere. And they're happening with individuals using their bots or their apps. And it's also happening even more quickly and a little more interestingly with AI agents that are being deployed throughout organizations.
Yeah, for sure. So that idea of understanding the objective, process, and accountability before introducing technology definitely becomes even more important with AI. As organizations begin incorporating AI into cybersecurity operations, where should leaders start?
So I think from a CISO perspective, we really should start with a framework that we can build that helps us understand accountability. Again, go back to start with accountability and responsibility. When we're building any kind of application tool, capability within the organization, we really need to know who the buck-stops-here person is for it. So, you know, if it's new capabilities in your MDR or your XDR, then the CISO has to vouch for, manage, and monitor that capability to make sure that it's operating appropriately. The same way, once we've started with that accountability, we know who's responsible, we've built a framework that can support the business and our business partners. Then we need to look to how do we implement it responsibly. So I look at AI agents as digital employees. I know that they need the same capabilities in terms of identity and access rights, limits to how much they can do, and guardrails that you build around them and into them through the deployment of the agent. And I also believe that we need to have a framework around them that says these are not guardrails, this is how we know that the agent's beginning to misbehave, and then as it slowly adjusts its behavior, we know when we need to take action and put a human in the loop, maybe quarantine the agent or stop it from performing the specific duty. An example that I use is in healthcare if you have an AI agent identifying claims that may be important for us to review for fraud, it may start out with taking just the claim ID and sending it to a human who's going to review it and do additional analysis. Eventually it starts adding fields because it's helpful and it says, okay, I'm going to add the email address of the person. And then it says, and then it goes further and says, I'm going to email that person when I email the claims administrator. That's when we know we've gone from green, normal operations, amber, it's starting to do things a little bit differently. And then red, we need to stop it and re-examine how it got to that conclusion. By building deterministic frameworks around the AI behavior, we'll be able to instantiate that and get it done in a repeatable manner so that we can scale our AI agents without risking exposure.
Alright, so as we wrap up, final question. How do security leaders know that a cybersecurity transformation is successful beyond just tools deployed or milestones completed?
I think you have to measure it in a few ways. The first one is security outcomes. If you've performed a transformation, you should be able to see a difference in the security outcomes in whatever aspect of your program it is. If it's the SOC, if it's vulnerability management, application security, identity and access management. You should be able to see what the path was from the as-was state to the is-now state. And then you should be able to say, okay, these are the documented improvements that I see. But I think more important than that, you should be able to say that I developed this program over three years to skate where the puck is. So then not only is it meeting new requirements and managing them better, but it's also aligned with the current state of the security market. So for example, when I started at VSP in 2017, I immediately had to make a decision about antivirus, right? Plain old antivirus. And we looked at that, we looked at the need to sign a contract, we looked at the market, and we said, if we sign this contract now, in about three years, we'll know who the leaders are in EDR, and we'll be able to land on the leading market there when it matters. Because until then, we're going to be experimenting with technology that hasn't really proven itself. I've done that successfully and I've also had challenges with it, where I implemented technology that was not ready for prime time. And it goes back to the IAM example where I needed to track contingent workforce. And there was a tool for that. And I said, I'll buy that tool and see how that goes. And about $50,000 later, I realized that I didn't have the underlying structure to make it successful. So the program is successful if it meets your objectives, your metric objectives, it skates to where the puck is, and it doesn't fumble on something like a tool that isn't ready for prime time.
All right. Well thank you very much. Thank you everybody for watching. If you enjoyed this conversation, be sure to like, subscribe, and leave a comment with your thoughts or suggestions for future guests and topics. And thank you again to David Brockmyer for joining us today.
Thank you, Sullivan.
Conversations With CISOs, Security Leaders & Technology Executives
Hear practical conversations with the executives responsible for protecting complex organizations. Each episode explores leadership, risk management, infrastructure, incident response, governance, and the decisions security leaders make every day.