Three Common Illusions of Daily Safety Work: Insights from Several Data Sets

We work with a large number of frontline security teams, and a common sentiment we share is this: we are incredibly busy every day, but more often than not, the direction of our efforts may not align perfectly with the actual direction of real risks.

Today, we will not talk about vague theories. We want to share a few data points we have observed and summarized. These numbers might be somewhat different from what we think based on intuition and experience.

The First Number: 60%

Among the major domestic data breach incidents occurring last year that we analyzed, over 60% of the attacks had a dwell time of more than 100 days.

What does this mean?

What we usually worry about most are often those high-profile ransomware attacks, because they make a lot of noise and have direct impacts. Therefore, we invest a large amount of energy in real-time alerting and emergency response.

But this data tells us that the more dangerous enemies are those quiet attackers. After they enter, they do not seek to make big headlines; instead, they quietly carry out lateral movement, privilege escalation, and data packaging, a process that can last for months. By the time we discover it, the core data has long since been taken away.

Our existing defense framework, which primarily relies on real-time alerts, is often powerless against this type of slow-boiling-frog attack. This is because, during the long dwell time, every individual action taken by the attacker may not trigger any high-risk alerts.

Also, try putting yourself in their shoes: if you were the attacker, what would you do? The first goal of an attacker after a successful compromise is to establish a foothold in your environment, aiming to ensure none of your existing detection and prevention mechanisms alert or take effect—otherwise, how would they stay hidden? So, you should think about what you would do if your security products and detection mechanisms do not raise any alerts.

What should we do?

Since we cannot prevent when or how an attacker will break in, we must ensure we can detect them at the very first moment and make it impossible for them to take another step. Regularly use automated attack playbooks to simulate the attack techniques (TTPs) that attackers would use during the dwell time phase, and simulate all possible lateral movement paths after gaining single-point access.

Continuously validate every potential pathway from the corporate network to the core zone, and from Web servers to databases, to ensure these paths are discovered and blocked by us before they are exploited in real life. Of course, if the validation reveals a lack of technical measures, we must quickly plan to fill the gaps. For example: what if there are no OS-level audit logs? What if there are no network traffic audit logs?

The Second Number: 70%

In the cloud-based offensive and defensive drills we assisted customers in completing, nearly 70% of the points lost were not due to 0-day vulnerabilities, but rather due to basic and common misconfigurations.

What does this mean?

We spent a large amount of budget purchasing the most advanced CWPP and CNAPP, believing these high-end tools would protect our cloud assets.

But the data tells us that what defeats us is often not some advanced hacking technology, but rather some very basic mistakes. For example: a shared storage that was forgotten to be closed and left open to the public internet; an "any-any" security group rule set up for debugging convenience; an access key hard-coded in the code by a developer.

These problems cannot be solved simply by buying new tools. No matter how powerful a tool's capabilities are, they cannot stop a misconfiguration from directly leaving the front door wide open.

What should we do?

Turn configuration assessment into a dynamic, continuous, and practical validation process. Stop relying solely on static configuration scanning checklists. Use an automated platform to continuously simulate scenarios like "if an AK/SK key is leaked, what can an attacker do with it?" or "if this security group rule is open, which internal services can an attacker access?".

Use actual attack results to push for the immediate discovery, correction, and hardening of configuration errors, rather than waiting for the next monthly or quarterly inspection, or waiting to find out "so that was the case" during root-cause analysis after a security incident has occurred.

The Third Number: 40%

In the customer security incidents we reviewed, nearly 40% of the successful intrusions exploited vulnerabilities that had already been "fixed."

What does this mean?

We hold weekly vulnerability review meetings, urging operations and development teams to apply patches and clear the vulnerability list, thinking that everything is fine once that is done.

But the data tells us that applying patches does not fully equate to resolving risks. More often than not:

The patch was not correctly applied to all related assets.

The patch itself might have issues, or was incompatible with business operations and was quietly rolled back.

An attacker used a new bypass technique, rendering the patch ineffective.

We were satisfied that the vulnerability disappeared from the vulnerability scanning report, but we did not validate whether the attack techniques exploiting this vulnerability were actually rendered ineffective.

What should we do?

Add a mandatory validation step to the vulnerability remediation workflow. When the operations or development team reports that a vulnerability has been fixed, the work is not yet finished. The security team needs to immediately use the platform to rerun the attack playbook targeting that vulnerability. Only when the attack simulation shows "cannot be successfully exploited" can the vulnerability remediation ticket be truly closed.

These three numbers point to the same conclusion: the focus of our security work is shifting from assumption to proof.

We can no longer assume that no alerts mean we are secure; we can no longer assume that deploying tools means they are effective; we can no longer assume that applying patches means risks are resolved.

The core value of the Saixun Security Validation Platform is to help our customers complete this transition from "I think" to "I am certain." By using continuous, automated validation data, we guide our limited resources to be invested in reducing the most realistic and urgent risk impacts.