Presenter:
Transcript:
Good morning, everybody. Welcome to HOU.SEC.CON. track 6. Our first speaker has over 25 years of technology leadership, including various roles in global consulting, director, and CISO, DeepWatch, Vista Equity, and Vista Equity Partnersin Salesforce, to name a few. Please help me welcome to the stage, Trey Ford. Thank you. I don't imagine y'all are here on accident, like in the back 40. Thanks for coming all the way out. This session will be hopefully exploring first principles and pressing into incentive alignment. I want to unpack what we're going to get into. If you've ever asked why it often feels likewe're the only ones pushing for controls, why engaging with the board or aligning with the ELP, why the whole ELT is so stressful, this talk is for you.
I want to unpack what that's going to look like through the course of this talk. The observations I started writing thistalk against came from my time in private equity. I had the privilege of working with – the private equity firm had 85 to 90 companies in it, which is to say, those CISOs didn't work for me – but I had the privilege of working with, and I saw somebrilliant work being done. done. I saw some work that was probably so brilliant, I couldn't wrap my head around why it was necessarily a good idea. I had the privilege of replacing about 50 of those CISOs over the course of two and a half years. So a lot of R &D. But they always want to know who they're reporting to.
And this comes up in your beer ISAC conversations. This comes up, of course, in the interview sequence. A lot of folks lead with that in the job posting. We're all concerned with how we're going to run our program, how we're going to staffour program, what type of investment we're looking at. But the incentives are not always aligned. And I want to unpack what that looks like. So my hypothesis is that there's a fundamental challenge that prevents us from engaging the business in a natural and healthy way. This isn't your brother's or your mom's how to talk about risk conversation. We have misaligned incentives. And I want to drill as far into that as I can, and offer perhaps a few frames that you can use to reflect and score yourself on how you've engaged with different departments, different teams, different processes, some of your operating flows.
So who am I? I would like to think of myself not as a thought leader, but a faithful thought partner. Again, workingwith this community of CISOs, I came to appreciate that I stood to learn more from them than I could possibly offer. I was able to reflect and share what I was learning, the challenges that we were exploring. With that said, we're starting to get that BaptistChurch feeling. I want you guys to pull as far forward as you can, or if you're willing, at least speak up when we step through some of these case studies and simulations. There is more brilliance, more perspective, more depth up there, over there than there is here where I'm standing. I went straight into industry.
I literally just did all my college stuff in night school, so doing that as an adult kind of sucks. I have a lot ofappreciation for all of our poor kids coming out of college that want to jump into cyber and can't get a job because they're notgoing to get a job. We all have experience. They are CISPs. They're not able to get in, so I have an appreciation for what they're working on. I've been around the game for a while. I've worked on the advisory side. I was employee 43 at PhishNet way back in the day. I joined White Hat Security back before Synopsis picked them up. Do you guys remember those really terrible Facebook games?
Mafia wars, words with friends? I had a real hard time over the holidays explaining to my friends that I was protecting the Facebook games that they hated so much. That was my life. That's what I did. From there, I went to go work at Black Hat. So I produced the Black Hat conference globally. I got to work with the research community. It's been a lot of funand, again, super humbling. Spent some time at Rapid7, out in the field with y'all. Went on to work at Salesforce, mostlysecurity. Do I need to grab the other mic? This thing cutting in and out a lot. I'll snag that.
So for me, Heroku was the most terrifying thing I could do as a CISO. It was effectively remote code execution as aservice. We were running everybody's code from Fortune 100 brands all the way down through ScriptKitties, proper professional hackers, folks that were relaying Premier League games. We were all over the map with what we did on theplatform. And we built this private spaces platform. And I'm going to talk a little bit about more of that journey. But I bring a lot of experience, or I can't hold down a job. I haven't decided which one's the most fair. Handful of definitions that I think weneed to build from. So first is, of course, first principles. Fancy word to put in a title. But I like, and you know, this is from the beginning.
We want to derive the foundational elements, a basic proposition or assumption that can't be deduced from anywhere else. We want to get to simple assertions. This is how formal logic builds. And I think we all walk in with a lot of assumptions. I want to try to press into those. Incentives, I think we're all generally comfortable with anything that motivates usto do something, or not do something. In economics, that's strictly a financial lens. Extrinsic incentives, by definition, are going to be strictly economic. So it's a material reward. This is where your OKRs, your KPIs, where all of your financial, how do we align with the CIO? How do we talk to the CRO? How are we removing friction and aligning executives? They're coin-operated. How do we work with them?
But I think the magic, and one of the biggest challenges we don't spend enough time and energy on, as security executives, is on the intrinsic incentives. That's the feelings of fulfillment, satisfaction, doing things for fun, or just because you wanted to. How do we activate those types of reward systems in our partners, in our dependencies? We're not the onespatching all the machines. We're not the ones controlling the code that gets deployed. We're trying to incentivize these behaviors. And so I want to press further into that. The language of the successful CISO has also changed. How many of you have heard of the CISO? How many of you have been through an interview process where you experienced that Kobayashi Maru, the unwinnable scenario, and they beat on you until they decide how technical they think you are?
Or they, I had one that wanted to do pair coding. I think the most interesting security question in that era was, can you define risk? I think that Spaff put it well. We can't really define security effectively. Defining risk is also a highly subjective topic. The newer conversation feels a lot more like the NBA. We're trying to talk more. We're trying to talk more about the language of business. The lingua franca is based in the P &L, looking at budgets, looking at performance and time to market. Sadly, Spaff's right. What it takes to get to market and what that defect cost center is going to look like over time. Governance, of course, we're going to talk a little bit more about this, of course, risk management, third-party partnerships, and everyone wants to know if you have incident command experience.
They're not hiring you because you've failed before, haven't failed before. Some people have that frame wrong. They're hiring you because you've been through it. It's not your first time. The conversation is very much increasingly business-centric. So a handful of frames that I want to apply to each of these simulations. First, this is something that a lot ofmy CISOs, when they started striking out, they struck out on this initial challenge. Anytime you're engaging with the ELT, anytime you're going to the board, you need to address these three questions, both for your peer executives. Well, I say peer as though the CFO is actually our peer. We're kind of a junior executive in most companies. When we're talking to the CIO or CTO, whoever we report through, we're preparing to bring something to the ELT.
They need this question answered, as does the rest of the room. When we go to the board, we need full alignment on what this is going to look like. So first, what do I need to know? When we're pushed, when we're pressured, when we're stressed, you pressure a CFO. They start quoting arcane bean counting theory tied to CPA tax law. Security people do the same thing. We don't quite go to RFCs, but we start talking about super technical CVSS stuff they don't care about. But we have to define, in language they understand, what do I need to know? Why do I care? We're going to press hard on why do I care. But there has to be something tied to what their daily drive is, what their challenges are, their financial reward systems, and then how to help win the hearts and minds of their organization to champion the things you care about.
And then what do you need from me? There's a big catch on what you need from me. How many of you folks have gone to a board, presented a problem, and were asked, 'Well, what do you need to solve it,' and didn't have your homeworkready to turn in at that point? You don't have to raise your hand. I think we've all done this in various levels. You've got to have a real clean, tight, definitive ask that the sponsor you're talking to is prepared to service. Non-economic incentives, I think, are where the real magic comes from and where I saw my most successful CISOs across my portfolio companies killing it. Pink, I think, wrote one of the more definitive pieces. I like threes. My name's Trey. I'm a simple creature.
I like threes. His drive drags on. He breaks into three major groups, autonomy, mastery, and purpose. Autonomy is this notion, of course, that you have the ability to choose what you're doing. This is particularly powerful when you're working on career coaching, talent development, resource building, understanding what folks want to do with their lives, where they're going. I found that getting folks to take on stretch projects was a lot easier when we sat down, reviewed their resume, talked about the job they wanted and the job after that, and started writing down what it was going to take to get there and thenaligning the projects that we had to take on as an organization to get them there. Those projects started getting prioritized in ways that I didn't understand.
It's actually kind of simple and embarrassing when you put it simply, but it's right there. Mastery, I think Spaff has it right. There's no rational way where correct is the top-minded thing, but you ask an engineer what they care about, software developers, what do you care most about? I want to write clean code, efficient, fast code, defect-free code. They care deeply about it. They care deeply about this. In internet software companies, these are the same folks that carry the pagers and get blown up whenthere's a production incident. They care deeply about making sure they got it right, their team got it right, and the testing wasdone. Autonomy, mastery, and purpose. This is kind of your warm, fuzzy, Care Bear stare aspect, but what you're doing matters on some level.
I'm not going to get into the deep leadership aspects of how to drive this for people, but everyone as part of yoursecurity program and all of your dependency partners partners, are going to need to press farther into why what you're asking for matters and how that's tied to the mission or purpose of the organization. All right, so the last piece that I think all of us should keep close is a simple triad, and these are the key outcomes. If we can't align on these three things, if we're not able to measure, and I don't think we have to be 100% on all of these, but I think the North Star to keep things simple is whether or not something is cooperative.
Do I understand why they want to do this, why they would tolerate doing this, how I support them in doing this? Cooperative. It's going to help them. It's going to help them progress their career. It's going to improve their pager duty load, those sorts of things, and of course, driving towards clear outcomes; I'm trying to measure. Continuous. How many of you alljust do once-a-year pen testing? You don't have to raise your hand. That's embarrassing. Don't do that. It's a problem, and we do audits. We do once-a-year audits. Now, they're supposed to have sample periods, and we're supposed to try to drive up resolution, but we do a lot of point-in-time contact across many critical aspects of our security programs. We'll drill on this a little bit, but think about how we could drive this more autonomously and think comprehensive.
Are you all familiar with the frame of MECE, mutually exclusive, collectively exhaustive? It's a great way to pressure test in thought partnership how to push someone to achieve the outcome and on which pieces we're going to be on a journey and wanting to ratchet things up without telling them how to do what you need them to do. So, critically guiding them to whatwe're going to define success criteria as and how we're going to take them on a journey to get there. All right. Enough lecturing. I'm tired of the sound of my voice. I'm going to cast a couple of stories and provide some frames, what I want to press into, what it takes to decompose some of these things, and these are things where I think we all get stuck.
We'll start off with customer annual onsite diligence, third-party risk management engagements. I'm going to lump together engineering capacity as opposed to failure. And then customer self-defense, I think those are very similar discussionary lines. And then we'll talk about board briefing and funding requests, along with a test particle of budget for anti-ransomware technology. All right. So customer onsite annual diligence, we're being recorded, so I'm not going to come right out and say I can't imagine customers would do their site visits as part of their third-party risk management programs for a boondoggle. They would never do that. But we've all had the customers come visit. Some of us may have been those customers that have flown to exotic destinations to sit down and discuss various aspects of that 500-line questionnaire we sent you.
You may have a couple of things that you really want to press on. There may have been follow-ups from last year's third-party review. But what are the key motives where organizations are coming out and spending time on site? Do they feel uncomfortable with the audit report? Do they have to have their own third-party standard that they're taking you across? Why can't they just accept? Why can't they just take your word or provide those questions in for your standardized third-party audit? I never could understand that, and I wanted to tease them about it, but when I was doing this at Salesforce, we had Fortune 100 companies that would come out and spend a week. Now I wrestled with this because my core security team was 18 people, and we locked up 10 of them for the week, preventing them from doing meaningful security work that profited tens or hundreds of thousands of other customers on the platform.
It made no sense to me. So I wanted to get into first principle analysis. I wanted to get into the first principleanalysis. What exactly do they want? Do any of y'all do this every day, third-party risk management? A couple of people I could pick on. Do you do on-site audits? No, no, God bless you guys. That's awesome. Thank you for not doing that. I'mlooking for force multipliers. I'm trying to understand how to capture this. What I ultimately was moving towards was kind of a 'romper room' approach, where if you wanted to do it on-site, you all came at the same time. Well, our questions are kind of sensitive. I don't want to share. I couldn't unpack what it would take to streamline this.
And so I tried to press into how they were incentivized, what they were driving towards. And it turns out that their OKRs and KPIs, what they had committed back to their leadership, was based upon the findings, the new findings, and thefindings that they closed out. And they took credit for things that we were able to help them close out, and then the fresh findings they would find. My challenge, my tension was that what they were pressing on and what sales and managementwere now excited about when this Fortune 100 company read out to my leadership team, here's our biggest, most concerning findings from this visit: They're not in line with my security program. They're not in line with my budget, not in line with my engineering plan.
And so what I wanted to do was press into that. And so what I wanted to do was try to understand what they took the most pride in, what they were finding in their travels, and ask really embarrassing questions. And so what we moved towards was something a little bit different. Their site visits started off with key controls. And what I wanted to do was takethem through the work we were doing. Make sure that they had signed off and agreed upon the plan that we were working against to address their concerns from last year. But I wanted them to specify the what, not the how. And I would bring engineering into these meetings. What was helpful about this was the engineers were hearing from, and we could design, we could accept, but what we ultimately were able to negotiate as a collaborative pattern was what success would look like and what would relieve that concern.
They wanted to get beyond ISO and audit reports, obviously. That's why they're coming on site. But it wasn't the most mutually beneficial way to do this. And so what we started doing was trying to build a trust portal that would allow them to see and track the types of patterns and operational cadence things. And I think a lot of technology is trying to go that way now, but it's still not there.
I still think the big piece was coming out for dinners. I don't know why we never got away from that. Does anyone have any experience with this? Anybody have other perspectives? Please.
And even if you're not, you're a service provider. And TruSight, some of those may have dealt with this. TruSight is this platform that all the banks put together to sort of solve this at scale. But it actually just became another audit, and the banks still said they were separate because they had their own way of doing things. So, it's also about, it's not considered anoffense. It's not enough just to send an assessment. If something goes wrong with a third party, did you do an on-site audit? There's a question that somehow makes a gap. So the auditors reviewing the banks are holding them to account for doing this, and they're demonstrating enough care and due diligence. And also, there's already budget allocated to it that can't just be reallocated to other things.
Yeah. Where does that T&E budget go? They don't want to just give it up. No. Anyone else have perspective on this? Totally fine. We can move on. All right. So engineering for security. This is the why do I care piece. In software development, so in standard SaaS applications, a lot of oil and gas folks. Anybody here work in software or SaaS? One, two, two and a half? All right. Strong oil and gas and OT here. We have this simple philosophy of a Crayola-level guy. We put caffeine into engineers, the engineers put out code, and we turn the code into money. That's how software works. It's a very simple construct. And so if we're measuring the velocity, we don't measure the coffee. We measure the velocity of the code and the deployments.
These are all going to be tightly correlated to features that customers have asked for, and that unlocks new revenue, unlocks new segments. That's where we play the game. That's what Spaff was talking about. What we've started fighting for was how to get foundational controls where we're going to automate fleet roles. Automate patch cycles to where wewere not disrupting flow. But these were things that were not driving to revenue. Great job patching, said no CEO ever. Andhow do we drive this to where the engineers care more about this? So what we did was we dragged our engineers into theaudit. Have any of y'all done that? A couple of you. Great. The other side of this is pulling them into some of our most interesting customers that were most interested in self-defense.
A lot of y'all, I assume, are moving to the cloud on some level. How do you defend yourself from a cloud provider? Do you know if anyone logs into your stuff from the cloud side? I mean, in theory, CloudTrail is going to let you know if AWS touches something, maybe on the Microsoft side. They've got a lot of math that says it's not possible. But I've also had tickets get serviced where they definitely did something for me and I have no idea when they touched things. How do you defend yourself from your providers? This isn't just third-party risk management. This is principally how do I monitor and hold toaccount and protect myself, or if I need, collapse my service where I know you can't get into my environment.
Difficult conversations, but that's not how engineers built this. And so, Spaff's right. Working with the user, the customer, to decompose what that looks like builds that empathy, but allows them to surprise and delight the customer, hopefully in, well, these are scary concepts, but in useful ways. What did the other party want? When we start looking back atcustomer self-defense or the capacity piece, the engineers want left alone. The head of engineering is most concerned with how fast they're shipping features. They've got alignment with customers. They've got product management. And their measure based upon product is revenue, delivery, engineering, velocity, and error budgets, if they're on the SLO type of universe. Where does security fit into that?
And so, some of us have a certain percentage that we've tried to negotiate, but what we did was turn around and sat down with them and did incident analysis where here's the pager load and here's the volume of root causes for why pager load and platform incidents were occurring. And they were all tied to foundational data. They were all tied to foundationalthings that dealt with patch hygiene, stability, regression testing, all the other defect types of testing. We empowered them todo the things that allowed them to stay with their families in the afternoons and evenings, kept them away from work on theweekends. They had to carry their laptop, but they didn't need it as often. We tried to align to what they cared most about.
And ultimately, they fought for more allocation for these security and availability utility-type concepts than I was ever going to be able to fight for. When the product manager is fighting with allocation and timelines for stuff, they tell you,no, no, no, I've got to fix this other thing. I got paged last weekend. Again, not happening this weekend. We're fixing it thisweek. That's a win. But they have to have a sense of ownership. That plays back to that autonomy concept. I don't know how to drive intrinsic capability aside from punishing and allowing them to feel the pain of the pager duty, feel the pain of missed timelines, to feel really bad scores for quality defects.
Do any of you all have perspective on what else is driving engineering and how to get them on board with some of these concepts? I feel like I should have packed more case studies when I fly through this. So on the other side of the audit,when we brought engineering in, engineers don't like auditors. They don't. Who, what, where, when, why, how? They cameback and absolutely tore the auditor apart. Show me chapter and verse exactly where in the audit code or the standard, what do you need? The engineering pulled in a product manager. Product manager was not happy about being in this room. And fortwo weeks, we sat with the auditors and decomposed every aspect of what they would need to do to make sure that the engineers never got to talk to the auditor again.
The best two weeks invested I ever had. What they focused on was what the core ideals, what the quantitative measures would be to make this auditor shut up and leave them alone. And they basically automated my team and the auditcycle out of a job for the next two weeks. When they came back this next year, they had built something they called TPSreports for the office space fans in the room. And so any time a protected branch or controlled body of code was going to gointo process, who, what, where, when, how, why is all tied into the development ticket. For us, it was JIRA. There was peer reviews, regression testing, sign-off on the design and the code pull request, and then sign-off on the deploy, like someone had reviewed and said, our test criteria is sufficient, but it improved their hygiene, driving down pager volume, but eliminatedall conversations that the auditor could ever ask because we spent two weeks and made him sign off on our design documents. And we automated that part of the audit all the way out of the way. This was harder with the customers onthe self-defense concept. What we settled on was the Cloud Security Alliance has this cake, a consensus questionnaire. How many of y'all have your own questionnaires that you send to your third parties, and you're stopping it? Why do you do that? What is your reasoning?
So, it's a weird country requirements?
I can be xenophobic, I can mock other countries. I'm totally fine with that. It's so confusing. I hope that makes sense. I can get behind that. You get the privilege of lowering the amount of defensive energy put into protecting anddefending your platform for the sake of filling out someone's questionnaire. I love that we pay this forward. It's a painfulprocess. What I found was by building out a consensus questionnaire and then building out a RACI underneath this, and Iworked with engineering and with customer support to do this. Security product managed the process. We facilitated the process. But what we found was with customer support, who was dealing most with these inbound questions, we worked with them on the security aspects of the questionnaires, they owned the process.
They kept it up to date. They were the ones able to speak to it. It unloaded my security team. It got more parties involved. But the customers were now able to automate and script against what exactly they were required to do, what they were responsible and accountable for, and which other pieces they were not touching because we had it. It was very clear in those audit points, it accelerated our audit points. A lot of y'all don't deal with PCI. That's one of the requirements is which parts of the responsibility are shared. But this became a non-security item for us. We rolled a hand off the majority of this workload by figuring out how to make their lives easier. And John, if you ever watch this video, I love you.
Thank you for bringing your engineering team in. That was awesome. All right. So this one's potentially the most contentious. So PINX number three, purpose. The board briefing and budgetary requests. So continual stats carry that still 80% of us in security leadership report in underneath IT. I spoke with one CIO earlier that has security underneath her, but most of us roll up underneath an IT, whether it's CIO, CTO, or engineering function. In the board management training, so what corporate directorships go through for certification and training, they worry about this notion of information asymmetry. This goes back to Spatial Challenger, STS-151L. That's the Challenger explosion. Remember the engineers knew that the O-rings were below, below a temperature, and the engineers were protesting, like, we can't launch in these colder temperatures.
And management made a management decision, and they blew up a shuttle. And that's the case study all business schools use for this. This information asymmetry thing is terrifying. What we're trying to do is find a great way for usto take what is important, what is material, what is timely, up to the board or the leadership team so everyone is aware of this.Is the CIO or CTO incentivized to prioritize the bad news, the bad weather we're sending them? Of course not. Of course not.How do we de-risk that? One other thing I'm gonna pick on, so budget requests.
Y'all, I guess you have OT, so I don't know that all of you have modern EDR, but y'all have EDR. Does EDR stop ransomware? Bueller? Anybody? Anybody? Okay, we're all aligned. I'm sorry this is being recorded. Thanks to our sponsors, sorry. It's a real problem, and so we have an incentive disalignment, and how do we defend what we're buying and how we're spending this money? It's a terrifying thing to turn us loose in front of the boardroom. The security people, you don't know what they're gonna say, and it makes sense that they're going on a proxy and censor some of this. We're loose cannons. I have found that the majority of the time, they're more concerned with the perception, and the best way to not be turned into a loose cannon and to terrify your CIO or whoever your executive sponsor is, and to terrify your CIO or whoever your executive sponsor is, into the ELT, or into the board of directors, is the power of a risk committee.
Y'all all have risk committees? Yeah, I hope. Please, don't raise your hand if you don't. I'm not gonna pick on you.Think about this for a hot second. Risk decisions need to be governance, yes. Otherwise, it's a Sisyphean task. You're pushing the rock up the hill by yourself. You're shrugging the whole thing. There's a reason why 'it's you against the world' is because it is you against the world. You go and talk to the CEO, you go and talk to the CEO, or the CIO, or the CTO, or someone else saying, 'Hey, I need budget for this.' It's their budget. And they're making a corporate risk decision by saying yay or nay, andthat's it. And where do you report out on that? You don't.
What we need to do, and what the NACD and all the other major corporate directorship platforms are focusing onis what is the governance process for making these decisions around risk? You know who's gonna hold patching to account faster than you will as security? General counsel. You know who's gonna talk about defect resolution faster than you will or engineering? Customer support. Who's gonna talk about misfired features or failures or platform outages? You, of course, are, but now we're making all kinds of noise. Sales, the CRO. Who's gonna talk about the efficacy of this year's cyber insurance renewal? I mean, you can talk to the CTO. I bet most of y'all received the questionnaire where you're gonna answer yes or no on really complicated security stuff.
No, the CFO's very interested, and so is General Counsel in what that process looks like and how to facilitate it.You bring leadership from across the organization and start light, maybe twice a year. Find time to get coffee and take them across at least your risk register so they have an idea of your nightmare scenarios and the near misses we most oftenexperience. And then once or twice a year, start with twice a year, please. I have a name for monthly if you can do it. Smallercompanies, this is impossible. Help them understand what we're looking at, what risks we're treating, what that decision-making process is, get their buy-in. Ask if we've got them scored right. Are these prioritized appropriately?
Now, take a big step back from all the machinations of the governance process and risk committees and imagine what the sponsor, the CTO or CIO is looking at when you're simply reading the weather of what came out of the risk committee. Here's the things we all agreed on. Here's the things we struggled with. Here's the stuff we couldn't decide on. You've got a handful of metrics. They're probably tied to cyber insurance metrics. You may have your own custom saucewhere you do a special risk calculation. But if you go to the board through the CTO, the CTO is like, look, this isn't on me. All these executives made a decision. There's minutes. This is corporate governance now. It's not their tail on the line. They're not worried about their perception.
You've also eliminated the red flag risk and removed liability from your corporate directors. The power of that risk committee, the governance engine, is pulling in that participation. And it's not just one voice. And it's not just putting the CTO on the spot. You're putting all of your, I don't know, gummy bears in the middle of the table saying, how are we going to carve these up? How many jelly beans do we push into each of these buckets to burn down risk? How much engineering capacity is required to do that? You go back to the board. Here's the decisions we made. Here's where I'm uncomfortable. But we operatewithin constraints. You know who can forgive management's objectives, EBITDA targets, or carve out budget for you to do things that were unplanned faster than anybody else?
The board. You know who's losing sleep because they have uncapped personal liability to the public and the investors? Everyone's got a boss, whether it's private equity back to the rest of their investors, their LPs, or it's public companies back to the general public. Everyone's got a boss. They're the ones losing sleep. I heard about this in the news. I don't know what this means. We all get disrupted explaining what's happened in the news. But what this does is aligns the coreideals of the company, what you know as professionals that spend your time and lose your sleep over how to facilitate a risk discussion, and you're just reading this out. You're no longer a loose cannon. They've got that. I'm going to pause. Does anyone have any experience? Any experience doing this, like you're doing this today? What's working? Or not?
You've got to speak up, brother. You want the mic?
In my organization, we've built up a risk committee. It's very new, but it's good because it stops this board freak out, board members freaking out, dumping on the CISO, CISO getting on us. Nothing was budgeted. No one understands the risk appetite. Stuff was identified for that two years prior. It's helping with the alignment, basically, is what I'm trying to say. Awesome. Anybody else have a story they want to share? Go, Joe. I mean, I can tell you, as a public company perspective, is if you don't already have a risk committee, you probably don't have a mature ERM process at all. Otherwise, you would have a risk committee, so the issue you have is that the board will typically lean on the CISO to create cybersecurity risk governance that does not exist in any other risk area.
All right, so you don't have a uniform risk process to plug in. So like having started a risk committee at a you know, like large commercial real estate, right? It's not heavily regulated, not a strong risk culture. You have to do it like an agile transformation where like when you do an agile transformation, you just say all the things, but you're really not doing anythingagile. You have to fake it till you make it, and it took like eight quarters because initially, like what happens is with the risk committee, you're just talking to them; they don't, no matter how much you break it down, the first principles, they don't know how to make decisions, yeah? And they're like, 'Well, what do you think we should do?' So eventually, then you know, they getsome backlash from the board, And so, what happens is at first they're like totally indifferent, then they get hypersensitive.
The ELT and then what happens is they learn they can risk accept things. And so then risk acceptance becomes like a weapon to not have to deal with things. Right? So it's like not the greatest outcome because as you get them more educated and you take them on this journey, then they're like, 'Oh, I just risk accept everything.' Do any of y'all have certification or formal signature process for risk acceptance where someone has to sign on the line? Yeah, several of you. Howhard was that?
Sell how do you drive a count of ability stir in the back, like the financial model line employees can sign up to this amount. It's kind of works its way up completely. Rational, see that a lot, yeah. I like that. Have any of y'all done the presentation on the board where you talk about, 'Here's the decisions, here's the acceptances that have been made? I'm uncomfortable with this and had a reaction from the board, it'slike a Baptist Church man, send it from the back, yeah. So, I think what we had with the budget overall and some of the on the risks that we had to take on were along with that purchase in general, that we didn't have that account to be backed this whole year so we had to accept it for that's how we could have addressed it and we did present it as such, like 'Hey, look, we're going to have to accept It's not something we're comfortable with, but it's just that we don't have the chance to accept it.
There will always be things that are below the line, and I think most people are okay knowing if we have an issue. I chose not to replace that tire if the tire blows out-I knew I did it, and they're willing to accept that. But at some point, they're accountable. Please, one issue that I'm seeing at my organization is that they're hand-picking the people who can address the board with what risks we do have, and those people have no idea what behind-the-scenes risks are being accepted in different departments-you know, underneath. Even things that the CISO has signed off on, they don't even know about it and there's no accountability there'd be dragons there, right? I would never tell someone they need to go and submit an anonymous report to the board for an ethical violation.
But at some point, we're talking about really difficult conversations, right? Sunshine is the best disinfectant. Trying to drive collaboration and ownership in this process, that autonomy thing, you get to choose your own adventure. The bottom line is you made a decision. Someone's got to know where that is. That has to be tracked. There has to be governance on that. And in theory, the audit and risk committee should be receiving that. Now, if the CISO is self-censoring or being censored on the way up, which is generally what I see, I don't think many CISOs want to die quietly on the vine dealingwith this stuff. So they're generally being forced or encouraged to give the sunshine. Trying to find a way to bring that stuffforward, do a special session, executive session, or read-in.
There's methodologies for this. But finding a way to bring that stuff forward, hard, difficult. Where's my controller? So I think it's clear what the other party wants in this case. The tension that we're generally carrying as the champions for security is that the technology counterparts that we often report through are disincentivised. To show that, and we have toremove that accountability from them directly. And that's what diffusing through the governance piece is. But now we're fighting for calendar time and interest that the other executives don't have. They're not sitting around looking for meetings, new meetings to sit in routinely. So we've got to be efficient. We've got to be fast. Frankly, the outcomes here are going to be negatively incentivised. But the upside is they get to make the choice.
And so we only have so many jelly beans that we can apply to the different aspects of our program. But we're not making that call. My argument to you is not to see yourself as the solo artist that could pick up any instrument in the band anddo it. Like, yeah, we can patch. Yeah, we can do configuration management. Yeah, we can. There's a lot of things we can do.But the bottom line is your group doesn't do that every day. But you're an orchestra conductor across the risk management committee cultivating tension between the different groups. So we can have a discussion, have an informed disagreement, and make hard decisions. And that's what the governance process is for. But we're building this muscle inside of the organization to drive.
The governance and hopefully align what the outcomes are best for the business. So we're not the onesrepresenting that. We're helping drive that process, facilitate that process. I think
the extrinsic and intrinsic incentives are pretty clear. This is probably my favorite slide from the group. It just kind of has the core of the questions. Already hammered that. That's what I had. Did you all have any questions or anything you'd like todiscuss? Back to your-you were talking about the audits that you were getting from different vendors or, I guess, customers that didn't align with your budget and your program. How did you-did that go to the board level or did that-I mean, did that-can you explain a little bit more how you handled that?
Because that could be like-I mean, I guess if they're a huge customer, then, well, then that changes things. Yes. When your top five clients are coming back to the ELT and giving back to your-your top customers have your top salespeople involved, you don't hire salespeople because they're smart. I like to pick on salespeople. You hire them because they're unbelievably influential. That's a different kind of smart. That's weaponized smart. It's why technology people are generally afraid of salespeople. They're influential. So now your most influential people that carry the most income for the entire business have the attention of leadership. And what they're most concerned about or think they're most concerned about –because in five days, they clearly covered every aspect of your program.
Now your leadership is more concerned about what biggest customer 1, 2, 3, 4, 5 is concerned about and why that's not the priority in the plan. And so we're having an intellectual disagreement. It's intellectually dishonest and there'ssample bias and recency bias that we've got to contest. And what we wound up doing was sitting down and so I – after I gotcompletely derailed, my entire leadership team during QBR is like, that's not what Acme Corp and Wiley Coyote told us. Why is that not the list? I had to do a special meeting with – the account executive, my CEO, my head of engineering, and then the audit team from Acme Corp. And we sat down and like, listen, here's my risk register and here's what you've put forward.
I've scored these in this way. I just wanted for the record so I can clarify because leadership doesn't agree with me. Would you rather me park this and this and this? So like, why didn't you talk to me about those? My brother in Christ,we've only had 40 hours together. Half of that was at lunches, boozy lunches and dinners. I'm terrible. But this is a real story. And this happened repeatedly. And so what happened the following year when Acme Corp and Wiley Coyote came on site was, show us your risk register. Yes. Head of engineering is right there. John, talk to him about this. Well, here's what we're doing and here's what we're worried about and here's why this is hard. How would you do this?
Engineering is the requirements from the customer for the things that I'm most excited about, and I don't even have to sell it. Now magic is starting to happen because I've completely aligned these on accident. I'm not smart enough totake credit for it. But it happens. It happened. And so anchoring this back to that risk register and then the risk committee,engineering won't show up in the risk committee saying, listen, our biggest customers care the most about this. We're moving too slow. That was a win. I stepped in it. I can't take credit for it. But I've seen it happen again and again across my portfolio coast. It works. There's also something very magical and dangerous right now. Getting those customers to write into their renewal contracts discounts for the products or services.
If you don't meet any of the commitments on what last year's audit report was. That's a really great tool. It appliesleverage back to the business. Really aligned folks, especially sales. Ever had a salesperson chasing somebody for patching velocity? It makes no sense, but it works. But if you have other interesting engineering projects in a time we're dealing withright now with economic retraction where zero basis budgets, you're losing budget manpower. You don't have the human capital to execute. What do you do? Well, now the business has to have hard conversations. Zach with Acme and Wiley Coyote is saying we had to make some cuts. We want to ask which trade-offs you want to make. But now sales is driving the conversation. Really difficult conversations because no one wants to give away budgetary savings. But it's funny how everyone else is now actively involved in the security program. Any other questions or thoughts? Ready to race to go getcoffee? Y'all, thanks for making the hike. It's been a pleasure. Thank you.
