We spend a lot of time making sure our security tools are configured correctly. And for good reason. We've invested in endpoint protection, detection technologies, and a range of other security controls. We want to make sure they're deployed properly, that the right policies are enabled, and that we're following the guidance provided by the vendors who built them.
The problem is that we sometimes treat that work as evidence that we're protected. If the configuration checks pass, the agents are running, and the dashboard is showing green, there's a reasonable temptation to believe the defenses are doing their job.
But there's a pretty significant difference between having a security control configured correctly and knowing whether that control can actually stop an attacker.
A product might be configured exactly as its vendor recommends and still miss a particular attack procedure. You might have a detection capability available but not enabled. Or you might have everything configured correctly and discover that the detection logic simply doesn't recognize the way an adversary is executing a technique.
None of this necessarily means the vendor got something wrong or that the security team made a mistake. It means that security configurations are only one part of understanding how well you're defended.
The reality is attackers don't particularly care whether you've followed the recommended configuration guide.
Let's be clear: vendor best practices are important. Security teams should absolutely be using them. Frameworks such as CIS Benchmarks provide valuable guidance for establishing secure configurations, and there's no reason to ignore that work.
But there's a reason they're called baselines. They're designed to provide a good starting point across a broad range of environments. They aren't tailored to every organization's specific technologies, operational requirements, or the adversaries most likely to target them.
Think about an endpoint detection and response (EDR) platform. You can deploy it across your environment, enable the recommended prevention settings, configure behavioral monitoring, and confirm that everything is reporting correctly. From a configuration standpoint, you might be in excellent shape.
Now ask a slightly different question. What happens when an attacker uses a particular PowerShell command to execute malicious code? Or uses a legitimate administrative tool to move between systems? Or abuses credentials in a way that doesn't look particularly suspicious to the default detection logic?
Does your EDR stop it? Does it generate an alert? Does it even have the telemetry needed to recognize what's happening?
Those answers aren't necessarily in the configuration checklist.
The technology may be capable of detecting the activity, but whether it does depends on the specific procedure, the settings you've enabled, the detection logic you've deployed, and the information your tools can actually see.
That's where the difference starts to become clear. Configuration tells you how the product is set up. It doesn't tell you everything about how that product will perform against an adversary.
If you look at recent threat research, it's pretty clear that attackers have plenty of options when it comes to getting into an environment.
Verizon's 2026 Data Breach Investigations Report found that vulnerability exploitation accounted for 31% of breaches, surpassing stolen credentials as the leading initial access vector. Mandiant's M-Trends 2026 report found that exploits accounted for 32% of investigated intrusions with an identified initial vector, while voice phishing accounted for another 11%. Mandiant also reported that global median attacker dwell time increased from 11 to 14 days.
Those numbers don't mean the affected organizations necessarily had poorly configured security tools. What they show is that adversaries have different ways of getting access and different options for operating once they're inside.
Consider two attackers targeting the same company. One exploits a vulnerable internet-facing application. The other convinces an employee to hand over credentials, logs in using a legitimate account, and starts using administrative tools to explore the network.
Both might eventually attempt to steal credentials, move laterally, or access sensitive data. But they're going about it in very different ways, and the controls that can stop one approach may not be the same controls needed to stop the other.
That's the problem with relying too heavily on generic configuration assessments. They tell you whether certain protections are in place, but they don't necessarily tell you how those protections hold up against the specific methods attackers use.
And attackers are constantly finding different ways to accomplish the same objectives. They change tools, adjust commands, and take advantage of whatever the environment allows them to do.
So the question shouldn't stop at whether you've enabled the recommended protections. You need to understand which attack procedures your defenses can actually address.
This is where MITRE ATT&CK becomes particularly useful, but also where I think we need to be careful about what we mean by coverage.
ATT&CK gives us a common way to describe adversary tactics, techniques, and procedures. It's incredibly valuable for connecting threat intelligence to defensive operations and understanding the methods attackers use.
The problem comes when we start treating technique coverage as though it tells us everything about defensive effectiveness.
Take Command and Scripting Interpreter (T1059) as an example. It's a technique that includes several different ways an attacker might execute commands, including PowerShell, Windows Command Shell, and Unix shells.
Let's say your security platform has a detection mapped to T1059. Does that mean you're covered?
Well, covered against what, exactly?
An adversary can execute commands in many different ways. They might invoke PowerShell with specific arguments, run a script through a trusted utility, or use another interpreter altogether. Those implementations can produce different telemetry, and a detection designed to recognize one procedure may not recognize another.
So having a detection mapped to the technique doesn't mean you've accounted for every procedure associated with it.
This isn't a criticism of ATT&CK or coverage mapping. It's about understanding what the mapping actually represents.
There's a difference between knowing a product has a relevant capability, knowing that capability is enabled, knowing you have detection logic that addresses a particular procedure, and having evidence from testing that the detection works.
Those are all useful things to know, but they're not interchangeable.
If your coverage dashboard says you're covered against a technique, the next question should be how that conclusion was reached. What capability is providing the coverage? What specific activity can it detect or prevent? Has that capability been configured appropriately? And have you actually tested it?
The goal isn't to make the ATT&CK coverage chart as green as possible. It's to understand how your defenses will respond when someone tries to execute an attack.
There's another part of this conversation that gets overlooked.
When security teams find gaps, the natural reaction is often to start looking for something new. Another product, another detection platform, another capability to add to an already complicated environment.
Sometimes that's absolutely the right answer. There are real gaps that require new technologies or additional telemetry.
But sometimes the capability you need is already sitting in a product you're paying for.
Maybe a prevention feature hasn't been enabled. Maybe you've got the telemetry you need, but nobody has written the detection logic to use it. Or maybe a security policy is configured one way across most of the environment and differently somewhere else.
Here's a simple example:
Suppose you're assessing your defenses against a credential-access procedure and discover that your endpoint platform isn't detecting it. You look a little deeper and find that the product actually supports a relevant detection capability, but the policy isn't enabled on the systems you're concerned about.
You don't necessarily need another security tool. You need to understand the configuration, determine whether enabling that capability is appropriate, make the change, and test the result.
That sounds straightforward, but finding these opportunities isn't always easy when you're working across multiple security platforms, each with its own capabilities, settings, and terminology.
This is one of the reasons we should be looking at defenses as a system rather than evaluating each product independently. What can the environment collectively prevent or detect? Where are the gaps? And which of those gaps can be addressed by making better use of what you already have?
It's a much more productive conversation than simply asking whether every product has been configured according to its vendor's recommendations.
I don't think the answer is to throw away your configuration standards or stop measuring compliance. Those things are important, and there's plenty of value in getting the fundamentals right.
What needs to change is how we connect that work to the threats we're trying to defend against.
It starts with understanding the adversaries that are relevant to your organization. Which groups are targeting your industry? What procedures are they using? How are they getting into environments, moving around, and accomplishing their objectives?
That intelligence gives you a starting point for evaluating your defenses. Instead of trying to assess every possible technique equally, you can focus on the procedures that are most relevant to your environment.
From there, you need to understand what your security technologies can actually do.
That means looking beyond whether a product is deployed and examining its capabilities, configurations, and detection logic. You want to understand which adversary procedures your defenses can address, which capabilities are enabled, and where you might have weaknesses that need attention.
Once you've identified those gaps, the next step is to do something about them. That might mean changing a configuration, enabling a capability, creating a detection rule, or improving the telemetry available to your security tools. In some cases, it might mean investing in something new.
And then comes the part that's easy to overlook: testing whether the improvement actually worked.
You might have identified the right detection logic or enabled the right prevention setting, but until you test it against a representative procedure, you're still making an assumption about how it will perform.
Adversary emulation and detection validation can help establish whether the control works as expected. If it doesn't, you've learned something useful. You can investigate why, make another change, and test again.
This doesn't need to be a one-time project. As adversary procedures change and your environment evolves, you need to revisit those assessments. The aim is to make defensive improvement part of how security teams operate, rather than something they do once a year when it's time for an audit.
There's also a bigger question here for CISOs and security leadership.
Most security teams already have plenty of metrics. They know how many endpoints have agents installed, how many detection rules are active, how many alerts they've investigated, and how closely their environments align with established configuration standards.
Those numbers are useful, but they don't necessarily tell leadership how prepared the organization is to defend against an attack.
A CISO should be able to ask which adversary procedures are relevant to the organization, how well existing defenses address them, where the significant gaps are, and what the security team is doing to improve those defenses.
They should also be able to see whether the changes being made are producing results. If the team identified a detection gap last quarter, has it been addressed? Was the detection logic updated? Has the team tested the improvement? And what does that mean for the organization's overall defensive posture?
These are much more meaningful conversations than simply reporting that a certain percentage of security configurations meet a baseline.
I'm not suggesting that coverage scores or testing results can tell you exactly how much risk you've reduced. Security risk is more complicated than that, and we should be careful about presenting any single metric as a definitive measure of protection.
But they can provide evidence that the team is identifying weaknesses, taking action, and making measurable progress in strengthening defenses.
That gives security leaders a much clearer picture of how their investments are performing and where they should focus next.
Getting security configurations right is important. Nobody is arguing otherwise. Vendor recommendations, configuration standards, and compliance assessments all have a role in building and maintaining strong defenses.
But they aren't the whole picture.
You can follow every recommended configuration and still have gaps against the procedures an adversary uses. You can have a product capable of stopping a particular attack and never realize that the capability isn't enabled. And you can have a dashboard full of coverage mappings without knowing whether the underlying controls will actually work when tested.
This is really what Threat-Led Defense is about. Start with how relevant adversaries attack, understand what your existing defenses can do against those procedures, identify where improvements are needed, and validate that those improvements are effective.
At Tidal Cyber, we're focused on helping security teams make those connections. By bringing together adversary intelligence, defensive capabilities, configurations, and validation evidence, we help organizations get a clearer picture of their defenses and identify specific ways to strengthen them.
Because at the end of the day, having your security tools configured correctly is a good thing. But it's not the outcome you're ultimately trying to achieve.