7 Preventable Mistakes Even Top Security Teams Make

Many organizations make the same mistakes as they grow and mature their security operations (SecOps) program, team, and tools. It’s critical to understand these repeating antipatterns because they consistently result in ineffectiveness, inefficiencies, frustration, burnout, and increased organizational risk.

Top Seven SecOps Antipatterns to Avoid

The first step to avoiding and correcting antipatterns is to understand them.

1. Keeping Secrets From Family

SecOps organizations often don’t share insights (attack trends, prevalent and damaging attacks, etc.) with other parts of the organization.

Without this real-world data on attacks on the organization, other teams cannot effectively prioritize security investments and design security controls to block them. This causes SecOps to respond to avoidable incidents that could have been blocked by other teams.

SecOps must take the time to share what they are learning to help others help them.

2. Equating Collection With Detection

Many SecOps teams focus too much on collecting data and not enough on the security outcomes of that data. This results in an expensive data collection operation that never finds attacker activity hidden in that data.

This typically happens because of:

SecOps data efforts must focus on outcomes: enabling detections, investigations, recovery, and compliance obligations.

3. Believing the Network Is the Only Source of Truth

Many SecOps organizations have a false belief that only network data is required to detect and investigate attacks.

This is often because many security teams started as a security specialization on networking teams. While network-centric controls still protect against old-school network attacks on classic architectures, this is no longer good enough for today’s world because:

While networks are important, they are not the only (or most important source) of truth for SecOps today.

SecOps must build skills, tools, and processes to detect and investigate attacks using identity, application, endpoint, email, and other data sources.

4. "Not Invented Here" Bias

SecOps often has a strong bias to create custom detections and tools instead of evaluating and adopting established solutions.

While custom detections are sometimes required, building them for well-known scenarios is wasteful and distracting.

Organizations must "configure before customizing" by evaluating well-engineered, tested, and maintained tools before spending resources to create and maintain high quality custom solutions.

5. Shiny Object Syndrome

SecOps often prioritizes "cool" advanced scenarios and tools before critical basic capabilities.

While some actors perform advanced attacks against high-value targets using genuinely novel techniques, most attacks use well-established tools and techniques.

Before investing in sophisticated attack-technique detection, SecOps teams must master detecting and responding to common techniques such as phishing, password sprays, password reuse from known breaches, and pass the hash or ticket.

6. One Tool to Rule Them All

SecOps sometimes develops a belief that a single (often expensive) tool can solve all problems.

This can happen when budget-constrained SecOps teams build high expectations for a tool and make unrealistic promises to leaders to get approval. SecOps teams then must meet expectations that this tool can solve everything, even as it reaches its natural limits.

SecOps must focus on outcomes and how tools support those outcomes.

7. Toolapalooza!

SecOps organizations can also purchase too many tools without clarity on how to integrate them to work well together. This often happens during or after a major incident or crisis, when purchase approvals are easier.

SecOps tools that don’t work together create a "swivel chair" experience that wastes time and effort switching between tools, increases frustration, and causes analyst fatigue.

The analyst experience must be intuitive across tools to keep up with and get ahead of attackers.

Recognizing organizational antipatterns is the first step. In part two, we'll share how your organization can leverage best practices to optimize protection and overcome these antipatterns.

By John Schectman, Principal Program Manager, Microsoft; and Mark Simos, Lead Cybersecurity Architect, Microsoft

About the Authors:

Jon Shectman is a principal program manager at Microsoft, who leads detection and response strategy for the Customer Success Unit. Special areas of interest include early detection, SIEM+XDR operations, SOC modernization, reducing analyst fatigue with AL/ML, and retiring technical debt. His guiding principle is: As defenders, we must apply moral ingenuity against amoral ingenuity. 

Mark Simos is lead cybersecurity architect for Microsoft, where he develops cybersecurity reference architectures, best practices, reference strategies, prescriptive roadmaps, CISO workshops, and other guidance. Mark also chairs the Security Forum and co-chairs the Zero Trust Architecture (ZTA) working group at The Open Group. 

Mark is co-author of the Zero Trust Playbook and co-host of the Azure Security Podcast. Mark actively contributes to open standards and publications including the Zero Trust Reference Model, Zero Trust Commandments, Security Principles for Architecture, and NIST publications.