Loading...
Webinar
Hiring or Firing — The Next Step for AI-Augmented SOC Teams
Webinar
Hiring or Firing — The Next Step for AI-Augmented SOC Teams
Hiring or Firing — The Next Step for AI-Augmented SOC Teams
Hiring or Firing — The Next Step for AI-Augmented SOC Teams
Loading...
Along with the technical challenges of AI for security operations comes the human challenges of aligning and motivating a team. David shares a step-by-step approach for getting even AI sceptics on board.
AI can transform how your company approaches cybersecurity and get you promoted in the process, but you won't be able to do this on your own. You will need to have your peers and direct reports on board, including the ones who have not embraced the potential of AI the way you have.
We often focus, and much of this book has focused, on the technology side of AI in security operations (the tools, the AI models, connectors, dashboards, etc.) but even the best technology can't overcome the anxieties and subtle (or not so subtle) resistance of people who are threatened by change. This is critical when people are daily confronted with breathless headlines about AI taking away jobs.
I saw this firsthand on a recent project. The executive team declared a strategic initiative to rebuild the business around AI. Security leadership wanted to select an AI SecOps vendor in 60 days. The SOC team? Not on board, yet these were the people assigned to evaluate and figure out how to use the tools. The start of the project was greeted with folded arms and stony faces. The technical evaluation became an exercise in "gotcha" hunting for examples of where AI "was wrong." Not surprisingly, months later no tool has been selected, and no real progress has been made. Meanwhile, security alerts keep piling up.
Your project can be different. Here are steps you can take to keep the human side of AI for cybersecurity on track and moving forward, and how you can use the content of this book to help you along the way.
No surprises!
The fastest way to trigger resistance is to let people imagine what AI might do to their jobs. Meet that head on, and always before you start any technology evaluation. Explain early, often, and plainly why you are adding AI to your security operations (to reduce alert fatigue, accelerate investigations, and raise decision quality), what will not change (humans retain oversight and escalation authority), and what will change (routine triage and investigations will be increasingly automated). Be explicit that you are not swapping people for software, but you are shifting effort away from repetitive tasks and toward higher value analysis and response.
Give the team a sense of how the project will progress. For example: "We will start where we have the most noise or least coverage, measure the impact, and expand only when we're confident in quality." Set expectations that there will be transparency about how the AI reaches conclusions, how you'll measure results, and how feedback from analysts will shape the system.
Explain early, often, and plainly why you are adding AI to your security operations, what will not change, and what will change.
As you start the discussion, Alankrit's chapter "What Really Happens During an AI-Armed Attack" can help give context to the team. Sumedh's chapter "Five Things AI Does Well in Security" and Ambuj's chapter "Five AI Will Never Do in Security (That You Need to Do)" give a good picture of what capabilities AI will bring.
What will work look like in the future?
AI has the power to remove the most manual and time-consuming part of many roles but does not replace them completely. We can assume that traditional L1, L2, and L3 roles and the linear progression between them will go away, while new roles that elevate judgement, creativity, and coordination will be created. New roles like Context Engineering, AI Validation, AI-Enhanced Threat Hunting, AI Assisted Incident Response, and AI Detection Engineering all have a place in the AI enabled SOC. Define these or similar roles for your organization, then tie each one to a curriculum with training, shadowing, and certifications so that people can see how they will develop in their careers.
Steve Zaleski's chapter "Why You Don't Have to Be Afraid of AI Taking Your Job" and Joe Sullivan's chapter "The Architect, Not the Operator" both give a clear picture of some of the new roles in AI-enabled security operations.
Make success visible and fair
Before you evaluate a single product, define how you will measure "better." Choose metrics that matter to your analysts, stakeholders, and management, like time to resolution (TTR), mean time to acknowledge (MTTA), and the percentage of false positives the system can close without manual intervention. Give the organization an opportunity to provide input, but this is not a democratic process – you should make the final determination what you will show.
Sheetal and Karthik talk about the importance of defining a clear scorecard up front in "Lessons We Learned While Implementing AI in Our SOC (So You Don't Have To)." Metrics keep the debate honest and focus everyone on outcomes. Record and share the baseline of current operations, set 90-day targets post implementation, and commit to weekly updates. The objective here is to provide visibility, both to show improvement and to identify early if things are off track.
Participation encourages buy-in
Now it's time to start looking at vendors and technology. Drive the evaluation against the metrics you defined in step 3 and your set of technical requirements. Include front-line analysts and other team members in demos and hands-on testing. Ask them to run typical workflows with the candidate tools and evaluate the outcome. Where in the workflow does the tool remove effort from the workflow? How does the AI output compare with human output? Does the tool enable faster answers to support faster decisions?
The key here is to observe and manage the tone. If the human analyst and AI analyst disagree, who was right? And regardless of who was right that's a data point, not a conclusion. If you hear the tone trending towards "let's prove the AI wrong" remind the team that this is the software equivalent of a hardworking junior analyst who need supervision. Overall keep the evaluation tight – short sprints, quick fixes, and just enough hands on time to demonstrate capability.
Anton Chuvakin talks about the importance of this in his chapter "Simple to Ask: Is Your SOC AI Ready?". On the technical side, Nishant's "Criteria for Evaluating AI Security Operations Solutions" gives you a comprehensive framework for a technical evaluation.
Crawl → Walk → Run
First wins matter. Start your implementation where workload is high and consequences are relatively low. Phishing and DLP alerts, for example, are numerous, noisy, and as a result often ignored. Use these to demonstrate the capabilities of AI in production and get the team comfortable with the tools. Critical in this phase is that your AI tools offer transparency – what conclusions did they reach, and how and why did they reach that conclusion? Transparency builds confidence while helping people realize this is a logical process and learn how the tool operates. The goal of this step is to show that AI can remove toil from the system and let the team start move on to their new roles.
Ashish discusses the importance of starting out simple in his "A Maturity Model for Agentic AI in Security Operations." LN focuses specifically on DLP alerts in "The Cognitive Shift: Re-Architecting DLP for the Age of AI."
Oversight in action
AI security tools get better over time as they gain more context. While this is a technical necessity, from an organizational standpoint building context serves two important purposes. First, more context enables the AI to provide more precise responses to more complex security scenarios. As accuracy grows, the team gets more confidence in what the tool can do and in their opportunity to move on to their new, higher-level roles. You want the system to enable you to deliver against the promises of new roles and learning opportunities that you promised at the start of the project. Second, context in the form of feedback from analysts reinforces the ongoing oversight role of human judgement on the new tools. Let the team see that they are still in control, and as they give feedback to the system it learns and responds better the next time.
"You want the system to enable you to deliver against the promises of new roles and learning opportunities that you promised at the start of the project."
Context Engineer is often the first new role that emerges following deployment, and it does so at this step. Alankrit provides a full description in his chapter "Hottest New Job in Cybersecurity: Context Analyst."
You set the tone
A steady communications cadence reinforces focus and momentum. Keep communicating results at each step. Use the defined metrics to track and report progress. Host "show and tell" sessions to let different team members share how they are using the system. Let people give their feedback on working with the system. Celebrate people as they move into new roles made possible by AI.
Throughout, be honest about what is working and going as planned, and what is not. If people are concerned about their new roles, discuss it. If things are not going as planned, make the team part of figuring out what needs to be done differently. If you've followed this sequence of steps, by this point you are a team working together to improve, not the lone leader and worried employees you started out with. Build confidence with communications.
Getting to the corner office is a solitary activity only if you are self-employed. Follow these steps and you can build a team of people that share your vision of how AI can drive security and then translate that vision into practice. That's a team that is unstoppable.
Read the full ebook → Security for Winners: The Art of Using AI to Secure Your Company and Get Yourself Promoted
