AI Is About to Break Your Cybersecurity Operating Model

Episode transcript

Transcript provided for accessibility and search. Minor transcription errors may remain.

Introduction

SPEAKER_00 0:05

This is AI Security Multipliers. AI Cybersecurity Governance with Steve this week. AI is about to break your cybersecurity operating model. For decades, cybersecurity teams have built processes around people investigating alerts, reviewing vulnerabilities, managing incidents, and making security decisions. Now, artificial intelligence is beginning to do much of that work. Faster, at greater scale, and increasingly without waiting for a human to approve every step. But what happens when we introduce AI into security operations without changing the way those operations actually work? To explore why the future of cybersecurity may require more than another AI-powered security tool. Here's Steve.

AI Is Changing the Cybersecurity Operating Model

SPEAKER_01 1:02

Whenever a new technology arrives, we immediately start putting it into our existing products. And then we call it transformation. We've done it with cloud, automation, machine learning, and now artificial intelligence. Every security product suddenly has AI. Your endpoint platform has AI. Your SIM has AI. Your vulnerability management platform has AI. Your email security has AI. Your identity platform has AI, your cloud security platform has AI. Even the dashboard that tells you how many dashboards you have probably has AI. And I'm sure some of these capabilities are genuinely impressive. But I have a question. Have we actually changed the way cybersecurity operates? Or have we simply made the same processes slightly faster? Because those are two very different things. If AI summarizes an alert but a human still has to investigate it, copy information into a ticket, send it to another team, wait for approval and eventually close the incident, have we transformed security operations? Or have we just created a very efficient summary of an inefficient process? I think we're approaching a point where AI is going to force cybersecurity organizations to reconsider something much more fundamental than their technology, their operating model. I'm Steve, and this is AI Security Multipliers. Today we're talking about why AI might be about to break the way cybersecurity works, and why that might actually be a very good thing. Let's start with what I mean by an operating model. Because I can already hear somebody reaching for a management consulting presentation. Don't worry, there won't be a 47-box diagram, at least not today. An operating model is essentially how an organization gets work done. Who does what? Who makes decisions? How work moves between teams, which processes exist, what technology supports them, how performance is measured, and who's accountable when something goes wrong. Cybersecurity has developed operating models over decades. Security operations, identity management, vulnerability management, threat intelligence, incident response, governance, risk and compliance, security architecture, third-party risk, application security, and so on. Each has its own people, processes, technologies, responsibilities. And frequently, its own collection of spreadsheets. We've built structures around the capabilities humans had available. A security analyst can investigate a certain number of alerts. A vulnerability analyst can review a certain number of findings. An engineer can make a certain number of changes. A governance team can assess a certain number of risks, and the operating model reflects those limitations. But what happens when AI dramatically changes those limitations? What happens when the work that once took hours takes minutes or seconds? And what happens when some of that work no longer needs a human at all? That's not simply a technology change, that's an operating model change. Let's start with the Security Operations Center, the SOC. For years we've built security operations around alerts. Something happens. A tool generates an alert, an analyst investigates, they gather information, check logs, review endpoint activity, look at identity events, consult threat intelligence, decide whether it's malicious, document their findings, and either close the alert or escalate it. Now imagine AI can do much of that investigation. It can correlate events, retrieve relevant context, examine identity activity, analyze endpoint telemetry, summarize the timeline, identify suspicious behavior, recommend containment, and produce a report in seconds, not perfectly, and certainly not without controls, but well enough to dramatically reduce the amount of routine investigation required. What happens to the SOC? Do we simply give analysts more alerts? Do we reduce the number of analysts? Do we move people into higher value work? Do we change the escalation model? Do we redesign incident response? Those are operating model questions. And I suspect many organizations haven't really answered them. They're still measuring success by how quickly analysts close tickets. Perhaps we should start measuring something more useful, like whether we're actually reducing the time an attacker can operate inside the environment. Because closing a ticket isn't the same thing as reducing risk. Even if the dashboard is green. Now here's where things become uncomfortable. A lot of traditional SOC structures use tiers. Tier 1, Tier 2, Tier 3, an alert comes in. Tier 1 investigates. If it's complicated, it goes to tier 2. If it's really complicated, it goes to tier 3. And eventually someone who has been working in cybersecurity for 20 years gets involved and asks why nobody checked the DNS logs. AI could disrupt that structure significantly. Because

Rethinking SOC Structures, Vulnerabilities and Incident Response

SPEAKER_01 5:29

many Tier 1 activities are exactly the kinds of tasks AI is becoming good at. Gathering context, correlating events, identifying patterns, creating summaries, following investigation procedures. So perhaps we won't need the same volume of tier one work. But there's a problem. Where do future Tier III analysts come from? Because today many of them start at Tier 1, they learn by investigators, by making mistakes, by seeing patterns, by dealing with thousands of ordinary incidents before they encounter the extraordinary ones. If AI takes away much of that learning experience, how do we develop the next generation of security experts? We can't simply automate the bottom of the career ladder and assume experienced professionals will continue appearing at the top. That's not workforce planning, that's wishful thinking. So, the SOC of the future may need a different structure, fewer people doing repetitive triage, more people hunting threats, engineering detections, validating AI investigations, developing response automation, and deliberately learning through simulations and supervised investigations. AI may remove work, but organizations still need to develop expertise. Now let's look at vulnerability management, because this is another area where the operating model has been remarkably consistent for years. We scan, find vulnerabilities, generate reports, assign priorities, create tickets, send them to infrastructure teams, wait, remind them, escalate, wait again, produce another report, and eventually celebrate because the number of critical vulnerabilities went down until the next scan. Now imagine AI can understand considerably more context, not just the vulnerability score, but whether the asset is exposed, whether exploitation is occurring, what business process it supports, what compensating controls exist, whether the vulnerability is reachable, what dependencies might be affected by remediation, and potentially recommend or execute a fix, but that's a different capability. Instead of managing a queue of vulnerabilities, we may increasingly manage exposure reduction. And that distinction matters. A thousand vulnerabilities on isolated low-value systems may represent less risk than one exploitable vulnerability on a critical internet-facing application. We've known that for years, but our processes often remain built around counts. Counts of vulnerabilities, counts of tickets, counts of overdue findings. AI could help us move toward managing actual exposure, but only if we redesign the process. Otherwise we'll simply generate more accurate tickets, which I'm sure the infrastructure team will be absolutely delighted to receive. Then there's incident response. Imagine an attacker compromises an account. Within seconds, AI detects unusual authentication behavior. It correlates the activity with endpoint telemetry, identifies suspicious access, checks whether the account has privileged permissions, examines recent actions, and recommends containment, potentially before a human analyst has even opened the alert. That's exciting. But now imagine. The AI can also disable the account, revoke sessions, isolate devices, block connections, and initiate recovery actions. We've moved from AI assisting incident response to AI performing incident response. And that creates a completely different governance challenge. Who authorized those actions? What conditions must be met? What evidence is required? What happens if the AI is wrong? What if the account belongs to the person responsible for restoring a critical production system? What if the isolated server is running a business critical application? We can't simply give AI unrestricted authority because it's faster, but we also can't insist every low-risk decision waits for a human who may be asleep. The operating model needs to define different levels of autonomy. Some actions can be automatic, some require human approval, some should remain human decisions, and some should never be performed autonomously. The challenge isn't choosing between humans and AI, it's deciding where each belongs in the decision process. Here's a problem I think we'll encounter quite quickly. We build an incredibly capable AI AI security system. It investigates an incident in 12 seconds, produces a recommendation, and sends it to a human for approval. The human is in a meeting, so the recommendation waits forty five minutes. The AI then executes the approved action in two seconds. Wonderful. We've reduced the technical investigation time dramatically and left the operational delay almost untouched. Now sometimes that delay is justified. If the proposed action could shut down a critical business process, I absolutely want someone to consider the consequences. But if we're requiring human approval for every routine, reversible, low-risk action, we're not really using autonomy. We're using AI to create a faster queue for humans.

AI Autonomy, Security Architecture and Governance

SPEAKER_01 10:05

So organizations will need to rethink decision rights. What can AI decide? What can AI recommend? What can AI execute? What requires human authorization? And what level of confidence or evidence is necessary? These aren't questions a vendor can answer for you. They're business and governance decisions. Because the right answer depends on your organization's risk appetite and what you're willing to let a machine do. There's another implication. Security architecture itself. Today, many organizations have a collection of tools, each with its own data, its own policies, its own detection capabilities, its own console, its own automation, and increasingly its own AI assistant. One assistant investigates identity, another investigates endpoints, another investigates cloud, another investigates vulnerabilities, and another provides a beautiful summary explaining that the previous four assistants have identified a problem. This is not necessarily the future we should be aiming for. AI creates an opportunity to connect capabilities, identity, endpoint, cloud, network, applications, data, threat intelligence, business context. But that requires architecture, common identity, consistent telemetry, integration, clear data ownership, well-defined APIs, standardized controls, and orchestration. Without those foundations, AI simply becomes another layer sitting on top of fragmented security operations. And we've spent enough money building fragmented security operations already. Now let's talk about governance. Because this is where things get particularly interesting. Traditional security governance often assumes that humans are making decisions. Policies define expectations. Standards define requirements. Processes define approvals. Committees review exceptions. Audits assess compliance. And somewhere there's a spreadsheet documenting who approved what? AI challenges the speed of that model. If an AI system makes hundreds or thousands of operational decisions, you can't review each one manually. Governance has to become embedded into the technology. Policies need to become enforceable controls. Authorization needs to become dynamic. Risk thresholds need to be defined. Exceptions need to be monitored. Decisions need to be logged. And high-risk actions need appropriate oversight. In other words, governance becomes part of the execution environment, not simply something we document afterward. This doesn't mean abandon traditional governance. Boards still need accountability. Executives still own risk. Security leaders still need oversight, but the operating model has to connect those responsibilities to technical controls that operate continuously. A policy sitting in SharePoint won't stop an autonomous agent making a bad decision at three in the morning. Technical control might. Here's another uncomfortable thought. We may be measuring cybersecurity success using metrics that AI makes increasingly meaningless. Number of alerts investigated, number of tickets closed, average investigation time, number of vulnerabilities remediated, number of incidents handled. Those measures tell us something about activity, but not necessarily effectiveness. If AI can investigate 10,000 alerts, does that mean we're ten times more secure? Not necessarily. If AI can close vulnerability tickets faster, does that mean we've reduced the likelihood of compromise? Maybe. Maybe not. The better questions are about outcomes. How quickly do we detect meaningful threats? How quickly do we contain them? How much exploitable exposure exists? How often do our controls fail? How much business disruption results from incidents? How reliable are automated security decisions? How often does AI require human intervention? And perhaps most importantly, are we reducing risk? Because an efficient cybersecurity operation that doesn't reduce risk is simply

Security Outcomes and the Future Cybersecurity Workforce

SPEAKER_01 13:45

an efficient way of being insecure, which would look excellent on a dashboard. So what might the cybersecurity organization look like five years from now? I don't think it disappears. I don't think we replace every analyst with an AI agent, and I certainly don't think we can automate away accountability. But I do think the roles change. Security analysts spend less time gathering information, more time validating complex investigations. Threat hunters use AI to explore patterns across enormous data sets. Security engineers spend more time building and improving automated controls. Vulnerability teams focus on exposure and remediation strategy rather than managing ticket cues. Incident responders supervise increasingly automated response processes. Security architects design systems where humans and agents can operate safely together. Governance teams move toward continuous assurance, and cybersecurity leaders become increasingly responsible for managing an operating model that includes both human and digital capabilities. That's a very different organization. But here's the important point. We shouldn't simply remove people because AI can perform some of their tasks. We should redesign the work, determine where human judgment adds the most value, determine what can safely be automated, and build the skills needed to operate that environment. Otherwise, we risk creating a cybersecurity organization that's technically more automated, but operationally no more effective. And there's one more thing, something we've known about technology transformation for decades. Automating a bad process doesn't make it a good process. It just makes the bad process faster. If your incident response process requires 17 approvals, AI won't fix that. If your vulnerability management process produces thousands of tickets nobody owns, AI won't fix that. If your security tools don't share information, AI won't magically create a coherent architecture. If your teams have unclear responsibilities, AI won't solve accountability. And if your governance process consists primarily of writing policies nobody follows, adding AI won't suddenly make it effective. In fact, AI may make some of these problems considerably more obvious. Because once the technology becomes fast, the organizational bottlenecks become impossible to ignore. And perhaps that's one of the most useful things AI could do for cybersecurity. Not simply automate existing processes, but force us to question why those processes exist in the first place. So here's this episode's multiplier. Pick one cybersecurity process in your organization, just one. Incident triage. Vulnerability management? Threat hunting? Security exceptions. Whatever you like? Now ask five questions. First, what outcome are we actually trying to achieve? Not what activity are we performing? What risk are we reducing? Second, which parts of the process genuinely require human judgment? And which parts exist simply because humans historically had to perform them? Third, what could AI safely automate? Not everything it technically can do. What should it be allowed to do? Fourth, what controls would we need? Identity. Authorization. Monitoring. Evidence? Escalation. Human intervention. And finally, if we were designing this process today, knowing what AI can do, would we design it the same way? That's the important question. Because the goal isn't to insert AI into every step of your existing operating model. The goal is to build a better operating model. One that uses AI where it adds value, humans where judgment matters, and governance that keeps both accountable. That's the multiplier. AI is going

The Multiplier

SPEAKER_01 17:25

to change cybersecurity. Not simply because attackers will use it, and not simply because defenders will have more powerful tools, but because AI changes what security teams are capable of doing. It changes the speed of investigation, the scale of analysis, the possibilities for automation, the nature of decision making, and eventually, the way cybersecurity organizations need to operate. But none of that happens automatically. Buying AI doesn't transform your SOC. Adding AI to vulnerability management doesn't automatically reduce exposure. And giving every analyst an AI assistant doesn't necessarily improve security outcomes. Those things require deliberate changes to processes. Roles, decision rights, architecture, metrics, skills, and governance. So perhaps the next major cybersecurity transformation won't be about which AI security platform we buy. Perhaps it'll be about how we redesign cybersecurity itself. And frankly, it's probably overdue. I'm Steve. This is AI Security Multipliers. And remember, AI should multiply your capability, not your mistakes. I'll see you next time.