Transcript
Hello and welcome to the wake up podcast by Veeam, the global leader in data resilience. My name is Caroline Wong, and today I'm joined by Robert Wood. Robert, welcome. Thank you so much. I'm super excited to be here. Today we get to talk about some of your time being CISO of CMS. Robert, let's start out, what does CMS stand for? It is the Centers for Medicare and Medicaid Services. And one of the most common questions, of course, is why in the world is there only one M when there's two things that have an M? Government acronyms don't have to make sense, but that's what that is. What was it like to be the CISO there? It was a lot. So I went from a job where I was running a small security team for a tech startup to that job where we had hundreds of people covering the biggest health payer in the country. And it was a program that was just of a wildly different size and scope and scale. And there's congressional interactions and it was a lot, but it was an amazing experience all at the same time. Yeah, incredible. From my perspective, having only worked in the private sector, how the public sector operates when it comes to cybersecurity is really fascinating to me. And one of the things that I'd love to hear your perspective on is what about supply chain security in a role like that? How much of a dependency did you have on various third parties? Tons. So in the government, you and this varies agency to agency, but in CMS in particular and really across HHS, there's a lot of the operational work that gets done is done by contracting companies. So the government shuts down and you don't have access to your team. And so in a private sector organization, you might deal with the occasional services vendor, but most of your supply chain is made up of products and tools and stuff like that. In the government, it is other agencies and kind of research university partners that you're working with. It is products and tools. It is contractor organizations and that as you have a primary company, they will sometimes subcontract stuff out. There's sometimes multiple levels of subcontracting. They use their own tools. So it's an incredibly complex like web of stuff that goes into the supply chain in government and it is very much unlike how it is in the private sector. Yeah, you know, I think recently folks have been talking about not only third party security, but third and fourth and fifth party security. You know, when I think broadly about your typical private sector info sec team, you know, maybe 75% of the folks are on staff and 25% or contractor, something like that. I wonder if you can kind of give us like what's a rough ratio? What does an organization look like in terms of contractor makeup in the public sector for such an organization with really large remit? So for us, we had about 50 federal employees in the information security and privacy group, which was the group that I oversaw as the CISO. There was five divisions that kind of covered various core functions, security operations, privacy and policy, compliance, national security matters, and broadly risk management, vulnerability management, things like that. And inside of those divisions, you had government task leads, or they refer to them as GTLs. Those are effectively individual contributor, like non-managerial resources who are running these different contracts and programs or functions. They are kind of leading the contractor organizations. And so we had about 50 federal employees and over 400 contractor employees working with us. And so it was almost like an inverted ratio that you would experience in the private sector where most of your team is internal full-time employees, and maybe you have a managed service doing something for you or consulting companies or services companies doing something for you. And amidst all of that, you had sometimes the contractor organizations would be using their own tools. Sometimes they're using CMS purchase tools. It was kind of a hodgepodge there. But that kind of dynamic existed in the program offices, in the Medicare office, in the Medicaid office and CHIP and the hospital kind of coordination groups, and where you had a very similar dynamic of small federal team driving and setting strategy and all of that, but overseeing contractors who were doing the work. That is so interesting. Now, tell me what it means in terms of responsibility and accountability. Because of course, for decades, we've been outsourcing and partnering, and we've always kind of used matrices and dependencies to get our work done. But I'm curious to know your perspective on the responsibility and the accountability bit. There's the way it should work. There's these mechanisms that are set up in the procurement process. You have these success metrics. They refer to them as CPARs. I have no idea what the acronym stands for. But CPARs is basically like the scores you get as a contractor for how you're doing, how you're delivering. Are you good? Are you bad? Are you on track? Are you not? Are you behind? All of that stuff. You have another mechanism, the authority to operator, ATO. It's something that a lot of people are kind of notionally familiar with. It's kind of the stamp of approval that security and CIO offices provide to a system before it goes into production and starts serving live mission needs and live data, all of that stuff. Now, typically, accountability is driven through those two mechanisms. Those are, in my opinion, not super effective things because you can very much just skate right on through and you can kind of meet the bar, check the box, and do good enough for government work and just keep on moving. And it provides a mechanism for oversight, but it doesn't necessarily open the door for... It doesn't guarantee effective oversight and accountability of contractors who might not be delivering to the level that the government needs or, in some cases, with thinking about this complex supply chain, managing the tech debt that they're bringing to the table when they are serving you in some mission capacity. And that is problematic, as you might imagine. How does it feel to be the individual responsible for that and knowing that while there are controls and things in place, that they might not always work perfectly? Do you get anxious about that kind of thing? I definitely did. So when I first came into the role, I got recruited in by the former CIO, who I'm just very grateful for, for kind of believing in me, giving me a shot, all of that. When he brought me in, he had a few big overarching mandates. One was he needed somebody who was kind of a culture champion or a lightning rod, as he referred to it, because everyone hated security. They didn't want to talk to him. They wanted to go around him. They didn't like the opinions that they got. Everything was no. It was very kind of traditional. We don't like cybersecurity, so we're not going to engage with it. So he needed a cultural lightning rod, as he referred to it. He needed somebody who was technical because there was a lot of smoke being blown places that shouldn't. And in that case, you had this dynamic where the tail was wagging the dog. The contracting entities were really setting the strategy and kind of saying all these smart words and coming up with the shiny PowerPoints and whatnot and influencing, to an unhealthy degree, what was happening from a security standpoint. That's problematic. And you didn't have the depth of technical leadership in security to really call people out and stop the train before it gets too far down the tracks and course correct. And that's problematic. And then he wanted somebody to be able to think big with him and strategize and really try to drive towards this change that he was trying to instrument in the organization. And so coming in, it was unnerving. It was hard. I wrestled with all of this imposter syndrome, like, oh, I'm coming from a little tiny startup and going into this huge organization, and the country's depending on me. I would kind of tell myself stuff like that. And it was personally challenging, which was not actually true. I had a whole team behind me. I had an amazing deputy, an amazing leadership team under me. They were all incredible. But I would look at the situation like I was the youngest CISO CMS had ever had, I think that HHS had ever had. And I was the youngest person on my team, also ironically. And so I'd come into these situations and look around, and there's all of this experience and all of this knowledge and awareness and whatnot. And it wasn't until I started to get involved with things and realized that, like, yeah, I'm actually pretty darn capable myself. And I can flex and I can do all of this stuff. And then I started to kind of settle in and do my own thing. But initially coming in, that was quite off-putting, if you will, just given the scope of the problem. There's, I want to say, 130 million Americans on those programs, and that's not a small number. It is an enormous responsibility. It is an enormous mission to fulfill. And you have a lot of dependencies. Tell me about a time when things didn't quite go maybe the way that they should have. There was a lot of those cases. So I was there when the SolarWinds breach happened. I was there when Move-It happened. I was there when Log4J happened. A lot of things along those lines. And all of the major incidents that I oversaw in that role happened outside of the agency on agency data or on agency programs. And that was hugely problematic because you're trying to manage risk that you don't control in any way, shape, or form. You can influence it through policy or directions or through those accountability mechanisms, but you can't control it. You can't patch the system. You can't train the people. You can't implement the multi-factor authentication. You can't do those kind of mitigating things that are typically done should an organization experience some sort of issue or some sort of breach or tactical discrepancy that needs to be dealt with. And so working through those complicated situations where you're managing across this massive that very similar to the private sector third-party risk management dynamic where they are incentivized to put their best foot forward. They are not incentivized to show you all their dirty laundry and to tell you exactly how things actually are under the covers. And that's problematic when you're trying to get to the truth around what might have happened in a certain section, you know, a breach happened on Medicare or Medicaid data. We're trying to figure out what went down, how it happened, what the size or scope of the issue is, and they're not incentivized to really give us all the details. That's tough. It's fascinating. Paint me the picture of a war room during one of these incidents. What does it look like and what does it feel like when something starts to go sideways? There's actually a couple of different war rooms, if you will. There's not everything happening on one conference bridge or something like that. So in this setting, you've got the technical stuff that's happening, the SOC, the incident responders, the forensics folks, dealing with potentially the affected organizations, dealing with vendors, all of that, product vendors, et cetera. And they have a live conference bridge 24-7. You can dial into it if you want situational awareness. Managers are dropping in periodically to get updates, keep a timeline, all of that. And then you've got the And then you've got the political response. That is a, depending on the nature of the incident, if it escalates to the level of Congress needs to be notified, then you've got the whole political apparatus at the agency. So the appointees, the Office of Legislation Affairs, all of these folks are now involved because they want to be very intentional around the curated messaging that goes up to Congress because executive oversight is no big deal and in that setting, it's kind of like a Fortune 500 company reporting up to their board. They don't take it lightly, they don't just wing it. And so you've got the technical war room and then the political response war room. And those are happening in parallel. And the security team, the CISO's office, is stuck in the middle of that, taking the inputs from the technical war room as an input to the political war room and then vice versa. Things kind of pass back and forth and you're just this conduit. Well, thank goodness they hired the technical guy. Well, that does help. And I should say, my deputy, this gentleman, Frank D'Amizio, he is incredible. His background is former FBI digital forensics and incident response and such. And so the two of us had a very complimentary background and that, I think, was also just this killer dynamic for CMS during that time. It's like we were able to work super effectively together, especially in these contexts because we had a very yin and yang perspective on things and our strengths balanced each other out and all of that. And we could cover each other where I was stronger, where he maybe wasn't as strong and vice versa. Tell me about some of the kind of challenges that are inherent to this type of model. I don't know anything about what it's like to have to brief Congress on a thing. I don't know what it's like to have to address a political appointee on an incident. I'm so curious to know what that feels like. The first time you do it, it is nerve wracking. It's like the first time you get up and do public speaking or something, you're just shaking through the whole thing and trying to keep your nerves about you. But then you do it and you do it and you do it. And they're just regular people who happen to be in a position of influence and authority and power. And so you get a sense of the kind of questions that are interesting to them and relevant to them. And this is something that every security professional, as they're coming up through the ranks, they probably have to learn the hard way at some point. When they talk to somebody in leadership, they want to talk tech. They want to talk nuts and bolts. If you're talking about a ransomware incident, they start talking about fuzzy bear this and this not Petya or whatever. And somebody in senior leadership does not care at all about those level of detail. They care about how many people were impacted, how much downtime there was, what the cost of the breach is going to be in terms of person hours, what do you need as far as response support, things like that. And it is really important for technical people to be able to put a different hat on and think about what these other people need. Because when you're in the technical war room, you may not be talking about those things. You're asking questions and you're inferring and pulling all the pieces together. But all the people who are hands on keyboard are not talking like that. And so going in and having these conversations with the politicals is very much like speaking to a board. You're talking in impact, you're talking in risk, you're talking in strategic matters. And you're using a different language for a different party who cares about different things. And I mean, that's probably the best way I have to frame that. And you were telling us about your experience of kind of taking on the role and starting out in the role. You experienced a bit of imposter syndrome, a bit of the weight of these hundreds of Americans depending on you for their healthcare. And I wonder, were there moments during incidents where it kind of like struck you like, oh gosh, I'm worried that we might be letting these folks down? I think at that point I had been there long enough that it had settled in and I was grooving in my job and in my role. And it did add a layer of urgency around. So one thing that happened with the Move It incident, for example, just to kind of peek behind the curtain, if you will. We initially received certain numbers around how many people were impacted. It's X, whatever X was. And as the days went by, X turned to 2X, turned to 3X, turned to 10X. X kept on changing. The number of people kept on growing. That was a very suboptimal situation, as you might imagine. And so that of course puts pressure on everyone on my team to, we're going back to people in leadership with egg on our face, updating them that things have gotten even worse, the more we've gotten involved and all of that. But that pressure around the people who are depending on these programs, I think that really exists in the way you show up with the vendor in this case, the contractor in this case. Because you are very firm with them. It's not about feelings and it's not about playing nice and it's not about, you don't have to be a jerk, but you need facts and answers and you need to set the CPARs aside and set the ATOs aside. You need to really get in. And this is where I think having a technical background or being able to put that hat on is hugely beneficial. You can step into a situation and ask piercing questions. And when you get an answer, you ask the question that's behind the thing that they just gave you. And you keep on unraveling things until you get to what's really happening. I think that's where that pressure of the dependency of the programs comes into play because it is a fantastic motivating factor to step back and think about how many people are impacted because of whatever happened. And we're not just gonna let this, we're not just gonna check the box on this one. This isn't the lunch menu app that's getting certified and ATOed. This is real people's lives and real nation impact. And that's not cool. Absolutely. One thing that I think is not discussed really enough in our field when it comes to incident response is what's going on in the personal lives of everyone who's involved. So of course these things, the enemy gets a vote as they say. You don't get to choose when incidents happen. And everyone has lives. I have a wife, I have kids, I have horses, I have dogs, I have hermit crabs. I have all of these things. None of that stops when things hit the fan. They still need to go to school. They need to get fed. Groceries need to get bought. Dinners need to get cooked. Bedtimes need to happen. All the things need to keep on going. And that same condition exists for everyone who's working on these teams. And the amount of personal pressure that goes into maintaining your normal life amidst some of these incidents, which can stretch on days, weeks, long enough, can be really hard and really challenging for the individual. And for somebody in leadership who's managing their team, you can't just expect your team to just pedal to the metal, nose to the grindstone, whatever, for weeks on end. You have to start thinking about, like if they're pulling all-nighters and expected to be there during the day, you have to start thinking about how to give them some kind of relief and how to make sure that they're gonna be functional as a human and as a supportive team member with you, as well as how to get the job done. And so you have to start balancing those things. And that is like an extra mental burden that comes into this, that of course you need to deal with the incident and that needs to all just happen. But there's all of these other interpersonal dynamics that are very real because sometimes somebody might have a spouse or a partner that can take over with the kids or they may not have these responsibilities, but that's not always the case. And if somebody needs, somebody might get sick, somebody might, anything could happen. And you need to be able to manage through all of that. And it's not just a given that everyone's just gonna be able to drop everything and run it a hundred miles an hour for four weeks straight. Yeah. So. I really hear you taking on the weight of that as a leader as well. You have to. Right, the wellbeing of your team members and all the dependencies, frankly, that exists in their personal lives in addition to their professional lives. Yeah, I mean, and for yourself because you're being pressured to provide all these answers because your team is probably not the one who's doing the leadership reporting. They're providing you information and then you're relaying this. And so you're getting pressured from top down and then you're having to manage from your position to the rest of your team. And I mean, so you have to make sure that you don't run yourself ragged and show up and absolutely bungle things at the same time because that is a very real threat. With people who are expecting new kids, I oftentimes will lament with them that you can, there's a lot of health conditions that take a long time to manifest. It takes years or months to get fat, to give yourself lung cancer from smoking or whatever. It takes one or two days to get sleep deprived and then you are shot for as long as it takes to get caught up. And you pull a couple of all-nighters dealing with an incident and you are going to be not that effective. You can only drink so much coffee and get back some sort of level-headedness. And so you need to also be taking care of yourself as well as taking care of your team amidst all of that because if you don't, you're not gonna make as good decisions. You're not going to communicate clearly. You're not gonna be as level-headed. You're gonna be short-fused. None of those things serve you well when maybe in the technical stuff where you can just plow through its bits and bytes and ones and zeros, et cetera. But when you're doing the political dance with the board or with Congress or senior leadership, that is a whole different ballgame. Robert, I wanna shift gears a little bit. I'd love to hear about your expectations for the contractor organizations that you worked with and for your vendors. I think this is one of those things that is a little situationally dependent or maybe personality dependent. So being a technical security person and coming from a very technical background, I had high expectations for the individuals who were serving not only my group, but the agency as a whole. My expectation was that if you were gonna be handling anything inside of your environment, your boundary, if you will, then you should be really exhibiting security levels, security controls that were commensurate with what it is you were doing, the data that you were handling, $100 lock for $100 asset sort of thing. And in many cases, that just wasn't really the case. You had organizations that invested so much in delivery, and this is kind of the nature of government contracting, unfortunately, is contract comes in, almost all of the, because it's lower margin work than private sector, almost all the money goes back into hiring people, basically staffing these contracts and putting people in place to deliver on the work. There's not really a whole lot of money left over, profit left over. I mean, in some cases there are, but there's not a whole lot, and this is not the core emphasis of building an environment, a corporate IT, corporate security environment. to support some of the things that end up happening in those environments. And that, it's a paradoxical misalignment that is really troubling when you kind of play it out and bad things end up happening, especially when you've got these layers of prime contractors, subcontractors, or sub-subcontractors, and it gets complicated really quickly, and when there's no, nobody that can tell you what versions of Log4J are running in these tools, or are you using the vulnerable move-it versions, or whatever, and you're just left to guess or wait to see if something bad happens, and then react to it from there, that's not fun. That does not sound like fun. No, I can think of a few more things that would be fun. Does it feel frustrating, is it aggravating, to be in a position of responsibility, to have these partners, and to kind of not being able to get access to the information that you need to do what you gotta do, what does that feel like in the moment? Frustrating's a good word for it. It's frustrating, but at the same time, it's understandable, when you think about the dynamic that exists with money being allocated for delivery. Same kind of thing happens in consulting organizations, or like services companies. Unlike a product company, where they're building this setup internally, deploying this product internally in a cloud environment and whatnot, everything is hardened, and people are coming to you, data is coming to you, and you are providing assurance around what it is you're building. It's just a different, it's a different dynamic, and I think this is one of those complexities that emerges when you think about how dependent the government is on not only product companies, but services organizations, government contractors, and the layers of them that exist. And that's just, it's, I don't know that there's a great way to escape it. One of the things that we ended up doing is we, building on the executive order 14.028, I know you know exactly which one that is, of course. So this was the Joe Biden, that came out under the Biden administration, is the big Zero Trust executive order. Couple of things that were in that, that were less advertised or less popular, if you will, in terms of security marketing attention, were things like the SBOM mandate, that was requiring that organizations that were selling stuff into the government were able to provide some level of software supply chain transparency in the form of an SBOM, a software bill of materials. And at the time, there was really not any good tooling, or it was still in its infancy, in terms of collecting, aggregating that data, and then doing anything with it. And there was a lot of complaining and griping amongst the industry around, you know, what are people doing with these things? Why are we going to do all this work when you're not going to do anything with it? Which is a valid concern. However, having that information handy allows you to go in and query around incidents such as the big CVE, like Move It, for example. Zero day happens, are you using this vulnerable thing? And that's where these programs like asset management and the SBOM collection are tremendously valuable. And so one of the big initiatives that we had spun up was this security data lake. So we built this whole infrastructure around Snowflake and really tried to shift away from the telemetry focused data capture that was the normal, I mean, security, you talk security data, it's almost always logs, right? Like server logs, application logs, WAF logs, whatever, you know, it's telemetry, time series data, et cetera. And we were really trying to expand our aperture to collect other types of more business intelligence type of data that we could correlate alongside of logs in Snowflake as a means of bringing a technical layer to that accountability discussion. So we could collect data passively in times of no incident and when times of incident occurred, we could turn to the data and let the data speak for itself and then work with the contracting organizations accordingly as needed, depending on what the data told us. That is so cool. I think that we are both data nerds and I love that the Biden administration said, everyone needs an SBOM. I mean, yes, thank you, right? Like there are things in security that aren't the coolest, but sometimes they're just basic, fundamental, one-on-one hygiene things that we got to have. That is really cool. Yeah, well, and it's, and like I said, I know I'm kind of playing both sides of the coin here, but I can definitely see the contention amongst the security community when, because they have to jump through a lot of hoops as well. The SOC 2 reports and the vendor questionnaires and all of that stuff and throwing an SBOM in there as one more thing that is a check the box exercise or so it feels is pedantic and it's annoying and it slows the deals and it just adds friction to everything. And so I get it, but being in the business of the government is a different story. And so I have less sympathy for it in a government context than I do in a B2B private sector context. Yeah, sure. You've got mission critical activities. Robert, are there any other thoughts that you'd like to share with us with regards to expectations, accountability, responsibility? One of the things that I think is really key and that is undervalued in this accountability discussion is where, so compliance gets a bad name in security. It's kind of turned into a four letter word in many cases and compliance is an assurance tool. It's a communication medium of how you're doing against some standard as assessed by some independent third party. Compliance isn't everything. I'm certainly not asserting that. But I think if more companies, really organizations more broadly, more organizations looked at the spirit of compliance and what it is intended to be and to do and took it seriously and really invested in high quality assurance and evidence and storytelling and all of that, then we could move the needle when it comes to one organization demonstrating assurance to another organization that they're gonna, when they're gonna partner. The other thing is I think when these transactions occur, one organization, like let's say CMS in this case, procures services or products from another organization, there's assumptions that end up getting made around what they're going to do, what's going to be provided, how things are gonna work. And I think that's fine and dandy on some level. However, I think it's also important that the purchasing organization really take stock of the things that they control and adapt their operational cadence and some of the things that they're doing operationally to incorporate that vendor. So a good example of this is tabletop exercises that center on and incorporate, you don't have to invite the people from the supplier, but having the exercises focused on supplier related incidents, really important because that's something that you control and you can think through your incident response playbook and how you're gonna show up and coordinate, how you're gonna collect data, how all of that is gonna work when other organizations are involved. Instead of just making an assumption that our normal playbook is gonna work, you need to take accountability of the things that you're doing, your own activities, security activities, configuration checks and SSO adherence and the things that you are controlling as an enterprise and just factor your suppliers into it. And I think you will end up getting benefits, security benefit for your organization as a result of that work instead of just leaving it to the assumptions where things can fall through the cracks. And I think that's a really slippery slope that I see oftentimes in the private sector setup where purchasing organization goes to supplier, sends out questionnaire, supplier wants to put their best foot forward, sends their best efforts, articulation of their controls and their security posture and their answers and all of that stuff. And then there's just all of these assumptions that get made after the approvals happen around how security is really gonna work both on the day-to-day basis as well as in times of crisis. And the real gnarly stuff happens at the edges. It happens at the handoffs. It happens when one team connects to another team or one organization connects to another organization. And if you don't do that hard work of changing your operations and adapting to fold those other players in, then I think you're setting yourself up for a hard time when things get hard. Robert, we've talked about some of the challenges of not only managing the technicalities of an incident, but also the emotional challenges that accompany it. What advice do you have for security leadership in order to take really good care of themselves and their teams? I think a big part of that is having a good, healthy work-life balance. I know that's a little bit of a cliche term or idea, especially working in security where everyone is so involved and engaged and whatnot, but you need to be able to step away from the job at a certain point. Because if you don't, it's just going to eat you alive and spit you out afterwards. And especially in an incident, things are crazy. You're working extended hours. You're probably working weekends. You're probably missing dinners. You're probably missing sports games, whatever. You're missing things. You need to still be able to pause and be able to communicate with your team that you're going to pause and communicate to them that they should be able to pause when the time is right and recover and show up whenever they show back up for the next shift, refreshed and ready to engage. Now, there's always a little bit of fudge and flex in that because sometimes you need to just be present for an extended period of time. But you can't just be on the clock 24-7 during the whole thing. And they can't do that either. And if you start to set that expectation as a leader, your team is going to burn out really quick and having no team at all because they just dropped on you or threw their hands up and walked away or whatever, or just got frustrated. And maybe you make it through this incident, but they're done after that. That's not great. And so I think being able to set boundaries in advance of an incident, just generally speaking, you have these boundaries, you're going to be able to step away, you're going to be able to not respond at 11.30 at night when somebody sends you a Slack or a Teams message or whatever, that I think is a really, really good thing. Now, you don't want to take that to the extreme where you've got people who are going out at 4.30 on a Friday fishing during the middle of an incident. That is also not great. Everyone needs to be rowing in the same direction and rowing together, but there has to be a balance there. Otherwise, it's just going to grind you down. Yeah. I think that some leadership has trouble trusting their team to do that balance at their own discretion. How do you, as a leader, communicate that to your team in these different scenarios where there are going to be high-pressure times when you really need to be on, and I want you to be able to trust your team? And I want you to stay alive and survive through this. And at the same time, how do you manage that personally? And how do you encourage your teams to be thoughtful and intentional about it? So I hate tracking time and doing time sheets and all of that stuff. Not my thing. I've never liked doing it. I don't like asking people to do it. I don't want to micromanage people's time. And you're online at 8 o'clock, and you're offline at 5 o'clock. You better have a green bubble the whole time. That sort of thing. I have always opted to, both for myself, as well as for the people that I am managing or leading, to focus on outputs, as opposed to time spent in front of keyboard. And so really emphasizing that. And if we can trust each other and build up around your contribution to your outputs, your outcomes that you've been either assigned or that you've subscribed to, then we're good. Those output commitments are going to change in the middle of an incident when things are crazy. But that same dynamic of trust, you're going to do what it takes to get it done. And when you can, you're going to step away. And I trust you to do that, because the thing is going to get done. And you're going to communicate. We're going to be transparent. We're going to have a sense of urgency around the way we communicate with one another, especially in urgent times. It's not just going to be this lackadaisical, I'll get to it next week, or whatever. Those kind of communication patterns and that general sense of trust through output or outcomes, I have found to be tremendously helpful, as opposed to trying to drill down into the inputs, the time spent, and things like that. Because I've worked with people who claim they work 12 hours a day and get nothing done. And so there's not a direct correlation between time spent or hours spent, whatever, and the output or the quality of the output, quantity or quality. And so I'm a very output, outcome-oriented individual myself. I love that. And I know this to be the case about you. And I love it. I think it's fantastic. I think outputs and results all the way, right? Yeah. Robert, what advice do you have for security leaders who are trying to navigate the complex mix of roles and responsibilities between security team, buyer, seller, all these different relationships? What advice do you have for folks when they're trying to be proactive about clarity when it comes to roles and responsibilities? I think you have to really have an understanding of where you want to go. This, again, is cliche. But thinking about your core mission, the base-level mandate that you have to get done. We were there in CMS to support the mission of the organization, the secure operational mission of the organization, and to make sure that that could sustain and function. Security wasn't the most important thing, like data security and all of that stuff. If the programs could continue to function, obviously, there's setbacks to data security and integrity issues and all of that stuff. But that was not the absolute core mission. It was all about operations and mission enablement. And so I think you, as a security leader, you have to be really grounded in what your mission is, who your primary stakeholders are. And always come back to that. It's like first principles thinking, like test things against that. New initiative pops up. There's always going to be another thing. AI is now here. Blockchain is a thing. Quantum, I read an article on the plane here about quantum picking back up and really picking up steam. That's going to be a thing. Like there's always things. Go back to your core mission and stakeholders and make sure that you are satisfying those things first and that you are prioritizing your time, prioritizing your team's time, prioritizing your investments and your budget. And your general priorities and your backlog or your strategy accordingly to serve that core mission first and foremost. All the other stuff is secondary. And it's a supporting cast, if you will, or supporting efforts. But all too often, and I mentor a number of folks who are coming up in the security field, like transitioning into their first leadership role, that sort of thing. And it is so common for people to get swept up in the anxiety around we're not secure enough, a breach is imminent, we need to work so hard. And oh my god, there's a vulnerability over here. So my team is going to be the ones to patch it and to take on that work. And it creates these really unsustainable, unhealthy patterns and feedback loops in the organization that can really spiral over time and create a really toxic, negative situation when your intentions were nothing but positive. And so you have to be grounded and come back to that, I believe, anyways. And I have learned that the hard way, because I used to be exactly that person. And that's why I feel confident in telling these folks about this, because I have been burned by my own good intentions trying to just carry the world on my shoulders in some of the organizations I've worked in. And eventually, it will just bury you. And then you're no good to anyone. Mission first. I love it. And Robert, if you could go back and talk to your professional self, say, 15 years ago, what advice would you give that young man? There are so many directions I could take that. The, I think I would really focus. So around that time, I was very deep into red teaming and offensive security work. And I was in my head about all of that. And I was that person who exacerbated the technical risk and the technical impact of everything. And I would really be encouraging myself to be thinking about how the organizations that I was serving, I was consulting at that time, how they worked, what was important to them, what really mattered from an asset standpoint, from a strategy standpoint, what was important to the stakeholders I was working with, or to their bosses, or to their bosses' bosses, stuff like that. That kind of contextualization goes a long way. And if you practice it, so my wife is a, she's a former actress. And in addition to just being awesome, she has grilled me countless times that I've gone and done any kind of public speaking or even some of these congressional things that we spoke about earlier. And making sure that I am really just together with my thoughts and how I present and what I'm trying to communicate. And one of the things that I feel like I got from that feedback loop with her was a real intentionality around putting in reps, putting in practice, doing this translation from something really technical to something that made sense to this more executive stakeholder on the other side. Like one of the earliest examples I had of this was at Cigital. And I was running a red team. And I was, my whole team had something else going on. They were busy with something. And I was left after we had achieved our goal and done all, like caused all of this stuff to go haywire for this customer as a big bank. And I was left on the phone as a lowly associate with this executive stakeholder who is now a friend of mine. And we remain close to this day and I've learned a lot from him. But he grilled me in that moment. And all I could come up with was technical answers. And I kind of fumbled. I think I made it through fine. Like the engagement wrapped up fine and all was good, of course. But I was not prepared to translate things in that moment to this business context that he really needed it in. And so learning that skill early on and actually practicing it, not just conceptualizing it and realizing that it's important, but practicing it. Say it in front of a mirror. Record it. Record yourself saying it. So you can watch it back and look at how dumb you look. And then you can make it better. And then you can get better over time. That goes so far when somebody is trying to advocate for more budget, try to grow their team, try to prioritize this big new initiative that they want to do. Because security almost always is working through other teams. And so most of the job, you have to be able to negotiate and build coalitions and work with other people and collaborate to get things done effectively. And so if you lack those skills, you are forever fighting with one hand tied behind your back and you're not gonna be effective. And I wish I had learned that skill even earlier. I fortunately met my wife early in my career so she was able to set me on the right track. But I wish I had learned that skill even earlier so that I could just, I had more time to put it into practice. Robert, thank you. It's always so much fun to hang out. Thank you so much. This was awesome. This is Wake Up, a podcast by Veeam. Global leader in data resilience.
