Security Verification and Offensive-Defensive Practice
“Healthy” from an O&M perspective vs “effective” from an offensive and defensive perspective: what is the gap in between?
In daily security operations, we are accustomed to focusing on the "running status" of devices.
In the daily inspection reports, the firewall CPU utilisation is normal, WAF service ports are connected, the number of online EDR agents meets the standard, and the License is still within its validity period. On the IT operations monitoring screen, all indicators are green. From the perspective of IT operations, this defence system is "healthy".
However, in practical exercises, we often encounter an extremely embarrassing situation: the attacker successfully obtained permissions and even completed lateral movement, but when we checked the device logs afterwards, we found that the devices were clearly online but did not block or even record any of the attack behaviours.
This is the "functional integrity failure" of security components.
It is different from device downtime; it is a silent failure. The device process is running, but the detection and defence logic has been disconnected. This kind of failure cannot be discovered by traditional SNMP monitoring, heartbeat detection, or traditional inspections.
Why do green-light devices fail? Three real technical reasons
Leaving aside personnel awareness issues, looking solely from an engineering and technical perspective, the core reasons leading to "device online but defence ineffective" usually fall into three categories. These problems are highly likely to occur in complex enterprise IT environments and are extremely difficult to troubleshoot.
Blind spots in traffic analysis: Encrypted traffic and non-standard ports
This is the most common reason for the failure of boundary defence devices (Firewall/WAF/IPS).
HTTPS/TLS encryption shielding: Although many WAF devices are online, because SSL certificates were not imported in time, or to avoid performance loss, an "encrypted traffic bypass" policy was configured, the WAF cannot decrypt the Payload in HTTPS traffic. When attackers use WebShell for C2 communication, as long as it is wrapped with HTTPS, it is just a string of unreadable code that cannot be detected by the WAF. The device is good, but it has lost the ability to detect encrypted attack traffic.
Non-standard port bypass: Some businesses open Web services on non-standard ports (such as ports other than 8080 and 8443) for temporary debugging. If the WAF's business processing policy is configured based on ports (for example, only traffic on ports 80 and 443 is configured for detection, and others bypass), then the WAF cannot see attacks targeting these non-standard ports at all.
Degradation of endpoint capability: Kernel compatibility and loss of Hook mechanism
EDR relies on the underlying Hook of the operating system or kernel drivers to capture process behaviour.
Uncoupling caused by kernel upgrades:
Enterprise Linux servers often undergo kernel version upgrades. If the EDR Agent version is not adapted to the new Linux kernel in time, the Agent process may still start and the heartbeat may report normally to the console, but the underlying monitoring driver actually failed to load. At this point, the EDR becomes an empty shell process that only occupies memory but does no work, unable to detect behaviour or block the execution of malicious files.
Degradation caused by resource limits: Some EDR policies are configured with "performance priority" mode. When the server CPU load is too high during business peak hours, in order not to affect the business, the EDR will automatically downgrade to "monitor only" or even "bypass" mode, giving up active blocking. Attackers often choose to launch attacks during high business concurrency periods, just to bypass defences.
Breakage of the data pipeline: Log format changes and parsing failures
SIEM and SOC platforms rely on logs for correlation analysis.
Log parsing failure: Upstream security devices underwent a firmware upgrade, fine-tuning the output format of Syslog (such as changes in field order). If the downstream SIEM's parsing rules are not updated synchronously, it will lead to failure in extracting key fields (such as source IP, destination port, behaviour characteristics). Logs flow continuously into the SIEM, and storage is normal, but to the analysis engine, they are all invalid data that cannot match rules. The attack happened, and the log recorded it, but the alarm rules could not be triggered.
Shifting from "Status Monitoring" to "Functional Validation"
The above problems reveal a core contradiction: "Online" from an operational perspective is not equal to "Effective" from an attack and defence perspective.
To solve this problem, relying on piling up more manpower to check configurations is unrealistic. A "validation" mechanism must be introduced in daily operations.
The core logic of validation is not to check whether the configuration is correct, but to test whether the function works.
Validate traffic analysis capability: Periodically send HTTPS traffic containing specific attack features through the Cyber Security Validation Platform to test whether the WAF can successfully decrypt and block it. If the WAF allows it through, it indicates a vulnerability in the certificate configuration or decryption policy.
Validate endpoint blocking capability: Automatically execute harmless simulated ransomware behaviour (such as batch renaming of decoy files) on the server to observe whether the EDR triggers a blocking alarm. If the EDR does not respond, it indicates that the Agent function may have been compromised.
Validate log parsing capability: Send standardised test attacks to trigger security products or audit functions to generate logs, and check whether SIEM can generate corresponding high-level work orders. If not, it indicates that log parsing or correlation rules need maintenance.
When building cyber security, what we lack least are assumptions—assuming that policies haven't changed, assuming compatibility is not a problem, and assuming logs can be parsed normally.
But the iron law of engineering tells us that in a complex system with high entropy growth, any component that has not undergone continuous validation will eventually fail.
The purpose of Cyber Security Validation is to eliminate these "assumptions". Shift default trust in security products and related platforms to continuous validation based on data. This is not only being responsible for the security level, but also a necessary backup for operational work.
