Listen to this Post
The Problem With Calling an Organization “Secure”
Cybersecurity has spent years trying to answer a deceptively simple question: Is the organization secure?
Snehal Antani, co-founder and CEO of Horizon3.ai, believes the question itself may be wrong.
Speaking with Dark Reading’s Joan Goodchild at Black Hat USA, Antani argued that security teams need to abandon the idea that an organization can ever reach a permanent state of being “secure.” In a world where vulnerabilities emerge continuously, credentials are stolen, configurations drift, identities are compromised, and artificial intelligence is accelerating attacks, security is not a destination.
It is a process.
The more useful question is whether an organization is defensible. Can it detect an attack quickly? Can it contain the intrusion? Can it remediate the weakness? Can it prevent the same weakness from returning? And, perhaps most importantly, can it adapt faster than the attacker?
That shift sounds subtle, but it represents a major change in how executives should think about cybersecurity performance.
Security Is Not a Permanent State
Antani’s central argument is straightforward: calling something “secure” creates the illusion that security can be achieved once and then maintained automatically.
A security assessment performed on Monday can produce reassuring results. By Friday, a new vulnerability may have been disclosed, a privileged account may have been created, a firewall rule may have changed, or an employee’s credentials may have appeared in a criminal marketplace.
The security state has already changed.
This is why Antani prefers the concept of being defensible.
A defensible organization understands that attackers will eventually discover weaknesses. Its advantage comes from reducing the amount of time attackers have to exploit those weaknesses and increasing the organization’s ability to respond.
The difference is enormous.
Security becomes less about achieving perfection and more about building operational resilience.
The Industry Spent Years Chasing Vulnerabilities
For roughly two decades, cybersecurity programs have placed enormous attention on vulnerabilities and CVEs.
The approach made sense.
Organizations needed ways to catalog weaknesses, prioritize patches, and understand technical exposure. CVEs became an essential language for describing software vulnerabilities across the industry.
But attackers did not remain focused exclusively on vulnerabilities.
They evolved.
Threat actors increasingly began exploiting stolen credentials, identity weaknesses, exposed services, cloud misconfigurations, excessive privileges, poorly protected administrative interfaces, and weaknesses created by the interaction between multiple systems.
A vulnerability might exist on one server, but the real danger could come from the attack path connecting that server to an identity system and eventually to sensitive data.
That is why counting vulnerabilities alone can produce a misleading picture.
AI Is Making the Front Door Easier to Find
Artificial intelligence adds another layer of complexity.
AI can help attackers identify weaknesses in applications, automate reconnaissance, analyze exposed information, generate attack variations, and accelerate the discovery of potential targets.
But
The attacker still needs to move.
They may need to compromise an identity, escalate privileges, traverse the network, reach a valuable database, bypass security controls, or exfiltrate sensitive information.
That means organizations cannot build their entire defensive strategy around application security.
The real battlefield is the entire environment.
Visibility Must Extend Beyond Applications
Modern enterprise environments are interconnected ecosystems.
Applications communicate with APIs.
APIs interact with databases.
Users authenticate through identity providers.
Cloud workloads communicate with internal services.
Employees access sensitive resources from laptops and mobile devices.
Administrators possess privileged accounts that can potentially unlock entire environments.
A weakness in one component can therefore become an entry point into another.
This is why holistic visibility matters.
Security teams need to understand not only where vulnerabilities exist, but also what those vulnerabilities can reach.
That is the difference between vulnerability management and attack-path thinking.
The Metric That Matters: Mean Time to Remediation
One of
MTTR asks a practical question:
How long does it take the organization to fix a security problem after it becomes known?
A company with thousands of vulnerabilities may appear frightening on paper.
But suppose most critical weaknesses are remediated within hours or days, while less important findings are systematically managed.
Another organization might report fewer vulnerabilities but leave its most dangerous exposures unresolved for months.
Which organization is more defensible?
The raw vulnerability count does not answer that question.
MTTR provides much more operational context.
Detection Speed Matters Too
Remediation is only half the equation.
Organizations also need to understand mean time to detection, or MTTD.
An attacker who remains undetected for hours is dangerous.
An attacker who remains undetected for weeks can be catastrophic.
The faster a security team detects suspicious activity, the smaller the attacker’s opportunity to establish persistence, escalate privileges, move laterally, and access sensitive information.
This means detection should not simply be measured by whether an alert eventually appeared.
The clock matters.
The Forgotten Metric: Vulnerability Reoccurrence
Antani also highlights another metric that deserves much more attention: vulnerability reoccurrence rate.
This asks whether organizations are actually eliminating problems or merely fixing them temporarily.
Imagine a company discovers the same class of authentication weakness three times in different environments.
Each incident is technically remediated.
Yet the underlying engineering or configuration problem remains.
The organization is treating symptoms rather than causes.
A high reoccurrence rate can reveal weaknesses in development processes, configuration management, patch governance, architecture, or organizational accountability.
A mature security program should therefore ask not only, “Did we fix it?”
It should ask, “Why did it come back?”
Annual Pentesting Is Not Enough
Antani makes a provocative comparison when discussing penetration testing.
Organizations that conduct one or two penetration tests every year may believe they are receiving meaningful validation.
But the threat environment does not operate on an annual schedule.
New software is deployed every week.
Cloud infrastructure changes constantly.
Employees join and leave.
Permissions change.
Attack techniques evolve.
New vulnerabilities are disclosed.
External exposure changes.
Running a penetration test once or twice a year against that constantly moving environment can leave enormous gaps.
Antani suggests organizations consider dramatically increasing testing frequency, potentially reaching dozens of tests per month.
His analogy is memorable: performing a penetration test once a year is similar to brushing one tooth once a year and calling it dental hygiene.
The broader point is that security validation should become continuous rather than ceremonial.
Continuous Validation Changes the Security Mindset
Continuous security testing is not necessarily about launching aggressive attacks against production systems every day.
It is about repeatedly validating whether defensive assumptions remain true.
A security team might discover that an old vulnerability has returned.
Another test might reveal that a new cloud deployment accidentally exposed an administrative service.
A third could demonstrate that a compromised identity has an unexpectedly powerful attack path.
Each discovery creates an opportunity to strengthen the environment before a real attacker finds the same weakness.
That is where automated security validation can become valuable.
From Vulnerability Lists to Attack Paths
Traditional vulnerability management often produces enormous lists.
CVE number.
Severity.
Affected system.
Patch status.
Owner.
Deadline.
Those fields are useful, but they do not always explain business risk.
An attack-path model asks a different set of questions.
Can this weakness be exploited remotely?
Can it lead to credential theft?
Can the compromised system reach a privileged identity?
Can the attacker move toward sensitive data?
Can the attack ultimately achieve a business-impacting objective?
This context can dramatically improve prioritization.
A medium-severity vulnerability sitting on an isolated workstation may deserve less urgency than a seemingly similar weakness located on a server that provides a direct route to privileged infrastructure.
AI Changes the Economics of Attacks
Artificial intelligence does not necessarily create entirely new categories of attacks.
Its more immediate effect may be that it makes existing attacks faster, cheaper, and easier to scale.
Reconnaissance can become faster.
Code analysis can become faster.
Phishing content can become more convincing.
Attack experimentation can become more automated.
Security researchers and defenders face the same reality.
The defensive response cannot simply be to add more alerts.
If attackers can automate discovery while defenders still depend on periodic manual assessments, the asymmetry becomes increasingly uncomfortable.
The Human Problem Behind the Technical Problem
Security metrics are ultimately organizational metrics.
A vulnerability does not remain unpatched because a CVE database failed.
It remains unpatched because somebody, somewhere, has not completed a process.
Perhaps the system owner did not receive the notification.
Perhaps the patch breaks a business application.
Perhaps the security team lacks authority.
Perhaps the organization does not know who owns the asset.
Perhaps the vulnerability is technically complicated to remediate.
Metrics can expose these bottlenecks.
A rising MTTR may indicate insufficient resources.
A high MTTD may indicate inadequate visibility.
A high reoccurrence rate may reveal deeper engineering failures.
Cybersecurity metrics therefore should not merely measure security teams.
They should expose how the entire organization manages digital risk.
Deep Analysis
Measure the Entire Defensive Lifecycle
A mature security program should connect discovery, detection, remediation, validation, and prevention.
The objective is not to collect more numbers.
The objective is to understand whether the organization is getting harder to compromise and faster to recover.
Useful Linux Visibility Commands
Security teams can begin with basic defensive visibility on Linux systems.
For example, administrators can review recent authentication activity:
sudo journalctl --since "24 hours ago" | grep -Ei "authentication|failed|accepted|sudo"
This can help identify unusual authentication patterns that deserve investigation.
Administrators can also inspect listening services:
sudo ss -tulpn
The purpose is not simply to create another inventory.
The important question is whether every exposed service is expected, necessary, and appropriately protected.
Review Privileged Access
Privileged identities deserve special attention because compromising one powerful account can transform a relatively small intrusion into a major incident.
A basic Linux review can include:
getent group sudo
and:
sudo last
These commands can help administrators review privileged group membership and recent login activity.
In enterprise environments, the same principle should extend to cloud IAM, service accounts, API credentials, administrator roles, and machine identities.
Track Remediation Instead of Just Discovery
A vulnerability dashboard should ideally contain timestamps for every important stage.
For example:
Discovered: 2026-08-10 09:30
Triaged: 2026-08-10 11:15
Assigned: 2026-08-10 12:00
Remediated: 2026-08-11 08:20
Validated: 2026-08-11 10:00
From this data, security leaders can calculate meaningful operational metrics.
The objective is to determine where time is being lost.
Calculate Basic MTTR
A simple conceptual calculation looks like this:
MTTR = Total remediation time / Number of remediated findings
Security organizations should go further and separate remediation time by severity, asset type, business unit, and exposure.
A single global MTTR can hide important weaknesses.
A company might have an excellent average because thousands of low-risk issues are resolved quickly while a handful of critical internet-facing vulnerabilities remain open for months.
Measure Reoccurrence
A useful internal metric can be represented as:
Reoccurrence Rate =
Recurring vulnerabilities / Total remediated vulnerabilities × 100
The exact methodology can vary by organization.
The important principle is consistency.
If the same weakness repeatedly returns, the security team should investigate the root cause rather than repeatedly closing tickets.
Move Toward Continuous Validation
Continuous validation can also be incorporated into defensive workflows.
A simplified process might look like:
Discover
↓
Prioritize
↓
Remediate
↓
Validate
↓
Monitor
↓
Retest
↓
Measure
This creates a feedback loop.
Security stops being an annual event and becomes an operational discipline.
Don’t Turn Automation Into Recklessness
There is an important distinction between continuous validation and uncontrolled automated exploitation.
Testing should occur within authorized environments and carefully defined boundaries.
Organizations need safeguards around production systems, sensitive data, third-party infrastructure, and destructive actions.
Automation should make defensive testing more consistent, not make incidents easier to create.
Connect Technical Metrics to Business Outcomes
The board does not necessarily need a list of thousands of CVEs.
Executives need to understand exposure.
Questions such as these are more useful:
How quickly can we remediate critical internet-facing weaknesses?
How long could an attacker remain undetected?
How often do the same security failures return?
How many critical systems have exploitable attack paths?
How quickly can we contain a compromised privileged account?
Those metrics connect cybersecurity to operational resilience.
The Bigger Lesson From
Antani’s message goes beyond penetration testing.
It challenges an entire philosophy of cybersecurity.
For years, organizations have often measured security by what they have purchased, what vulnerabilities they have discovered, and how many security tools they operate.
But tools do not automatically create resilience.
A company can own an enormous security stack and still be slow to detect attacks.
It can employ hundreds of security professionals and still allow critical vulnerabilities to remain exposed.
It can perform penetration tests and still repeatedly recreate the same weaknesses.
The more meaningful measurement is what happens when reality arrives.
Can the organization detect?
Can it respond?
Can it recover?
Can it learn?
And can it prevent the same failure from happening again?
What Undercode Say:
Security Should Be Measured as a Moving System
The most important idea in
A company is never simply “secure.”
It is secure against certain threats at a certain moment under certain assumptions.
Those assumptions can disappear quickly.
The CVE Count Is Not the Whole Story
CVE numbers remain valuable, but they are not an adequate measurement of organizational resilience.
Two companies with the same number of vulnerabilities can have radically different levels of risk.
Attack paths, identity privileges, exposure, detection capabilities, and remediation speed determine the real difference.
MTTR Reveals Organizational Friction
A long remediation time may indicate more than technical difficulty.
It can reveal poor ownership.
It can expose fragmented infrastructure.
It can demonstrate weak communication between security and IT.
It can also reveal that the business has not given security teams enough authority to act.
That makes MTTR a management metric as much as a security metric.
MTTD Reveals Visibility
A security organization cannot respond to something it cannot see.
A low MTTD demonstrates that monitoring, detection engineering, identity visibility, and incident response processes are working together.
A high MTTD should trigger questions about blind spots.
Reoccurrence Reveals Root Causes
Repeated vulnerabilities are particularly interesting.
If the same weakness repeatedly appears, the organization may have a systemic problem.
Perhaps developers lack secure coding guidance.
Perhaps infrastructure templates contain insecure defaults.
Perhaps configuration changes are not validated.
Perhaps security findings are treated as individual tickets rather than organizational lessons.
Continuous Testing Makes Security More Honest
Periodic testing can create a false sense of confidence.
Continuous testing is uncomfortable because it constantly challenges assumptions.
That discomfort is valuable.
A defensive program should prefer discovering its weaknesses internally rather than allowing attackers to discover them first.
AI Makes This More Urgent
AI-assisted attackers can potentially operate at a scale that traditional manual processes struggle to match.
That means defenders need automation too.
But defensive automation should focus on prioritization, validation, monitoring, correlation, and remediation workflows.
The goal is not simply to generate more alerts.
The goal is to shorten the time between weakness discovery and meaningful defensive action.
Attack Paths Matter More Than Isolated Findings
A vulnerability becomes significantly more important when it provides a route toward a critical asset.
Security leaders should therefore prioritize weaknesses based on exploitability, exposure, identity relationships, privileges, and potential business impact.
That produces a much more realistic picture than a flat vulnerability spreadsheet.
Identity Is Now a Central Security Boundary
Modern attacks frequently involve identity.
A stolen password can be more useful than a complicated exploit.
A compromised service account can provide persistent access.
An overprivileged user can turn a small compromise into a major breach.
Security metrics therefore need to include identity exposure.
Security Teams Need Better Questions
Instead of asking:
How many vulnerabilities do we have?
Ask:
How many exploitable attack paths lead to critical assets?
Instead of asking:
Did we run our annual penetration test?
Ask:
How frequently are our assumptions being validated?
Instead of asking:
Are we secure?
Ask:
How quickly can we detect, contain, remediate, and recover?
Resilience Is the Real Competitive Advantage
Perfect prevention is unrealistic.
Resilience is achievable.
An organization that detects intrusions quickly, limits lateral movement, protects privileged identities, continuously validates controls, and learns from failures can survive attacks that might devastate a less prepared company.
That is what defensibility ultimately means.
The Boardroom Needs Better Security Metrics
Security metrics should eventually become business metrics.
Executives should know whether cyber risk is improving or deteriorating.
They should know how long dangerous exposures remain open.
They should understand whether the organization is becoming faster at detecting attacks.
And they should know whether previous failures are recurring.
That is far more useful than simply reporting that another security tool has been deployed.
The Future Is Continuous Security
The old model looked something like this:
Assess → Report → Patch → Wait
The emerging model looks more like:
Discover → Validate → Prioritize → Remediate
↑ ↓
└──── Monitor ← Retest ←──┘
The second model better reflects the reality of modern infrastructure.
Security Hygiene Must Become Routine
Antani’s toothbrush analogy works because it exposes the absurdity of annual security rituals.
Nobody would brush their teeth once a year and call themselves healthy.
Yet organizations sometimes perform a security assessment once a year and assume the resulting report represents their current security posture.
Digital environments change too quickly for that assumption.
Security validation needs to become routine.
AI Does Not Eliminate the Fundamentals
Despite all the attention surrounding AI, the fundamentals remain familiar.
Patch systems.
Protect credentials.
Control privileges.
Monitor identities.
Reduce unnecessary exposure.
Segment sensitive infrastructure.
Detect suspicious behavior.
Test defenses.
Remediate quickly.
Validate again.
AI simply increases the pressure to execute these fundamentals faster and more consistently.
The Most Dangerous Metric May Be Complacency
There is one metric that rarely appears on a dashboard: confidence without evidence.
An organization can have a green security dashboard while its environment is changing underneath it.
The antidote is continuous validation.
Assume that
Then test it.
Defensibility Is More Realistic Than Perfection
Antani’s argument ultimately offers a more realistic definition of cybersecurity success.
The goal is not to create an environment where nothing bad can ever happen.
The goal is to create an environment where attacks are difficult to execute, quickly detected, rapidly contained, thoroughly remediated, and unlikely to succeed in the same way twice.
That is a much harder goal.
But it is also a much more useful one.
✅ Security Is Not a Permanent State
The article accurately presents
✅ MTTR and MTTD Are Meaningful Security Metrics
Mean time to remediation and mean time to detection are established operational measures that can reveal how quickly organizations respond to security problems. Their value depends on consistent definitions and accurate measurement.
✅ Vulnerability Counts Alone Can Be Misleading
A raw vulnerability total does not automatically represent business risk. Exposure, exploitability, asset criticality, identity relationships, and attack paths can dramatically change the significance of an individual weakness.
✅ AI Is Increasing the Speed of Cyber Operations
AI can accelerate activities such as reconnaissance, code analysis, vulnerability research, social engineering, and automation. However, AI does not make every attack automatically successful, and organizations still require traditional security controls.
⚠️ Continuous Pentesting Requires Careful Implementation
Increasing testing frequency can improve visibility, but conducting dozens of penetration tests every month is not automatically appropriate for every organization. Testing scope, authorization, production safety, staffing, and automation quality must be considered.
Prediction
(+1) Continuous Security Validation Will Become Normal
As infrastructure becomes increasingly dynamic and AI accelerates offensive activity, more organizations will move away from annual penetration tests toward continuous or near-continuous security validation.
The most mature security programs will increasingly treat testing as an ongoing feedback mechanism rather than an annual compliance exercise.
(+1) Identity and Attack-Path Metrics Will Gain Importance
Security teams will increasingly measure how vulnerabilities interact with identities, privileges, cloud resources, and sensitive assets.
The question will gradually shift from “How many vulnerabilities exist?” to “Which weaknesses can actually lead an attacker to something important?”
(+1) MTTR Will Become a Board-Level Metric
As cyber incidents become more disruptive, executives will increasingly care about how quickly dangerous weaknesses can be eliminated.
A security organization that can demonstrate falling remediation times will have a stronger argument for its effectiveness than one that simply reports a large number of blocked threats.
(-1) Annual Security Assessments Will Become Less Convincing
Organizations that rely heavily on one or two assessments each year may increasingly struggle to demonstrate that their security posture reflects current reality.
An annual report can still provide value, but it cannot fully represent an environment that changes every day.
(+1) AI Will Push Defenders Toward Automation
The same acceleration that makes AI attractive to attackers will pressure defenders to automate more of their security lifecycle.
Discovery, prioritization, validation, detection, and remediation will increasingly operate as connected processes rather than isolated security functions.
(+1) “Are We Secure?” Will Become the Wrong Question
The strongest security leaders may eventually stop asking whether their organization is secure.
Instead, they will ask a much harder and more useful question:
If an attacker gets in tomorrow, how quickly can we detect them, stop them, recover, and make sure the same path no longer works?
That is the difference between simply possessing security controls and building genuine cyber resilience.
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: www.darkreading.com
Extra Source Hub (Possible Sources for article):
https://stackoverflow.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
