What Protects the Protection?
Engineers spend a lot of time thinking about failure because experience tells us that eventually something will fail. Disks die, processes crash, network connections disappear, and deployments don’t always go according to plan. That’s why we build redundancy, monitoring, failover, rollback procedures, and recovery into the systems we design.
Good engineering isn’t based on the assumption that everything will work perfectly. It’s about understanding what happens when it doesn’t, and I think Security controls deserve the same treatment.
We don’t always think about them that way. When an organization deploys a VPN, strengthens authentication, adds endpoint protection, or segments a network, there’s a natural tendency to consider the problem addressed. We’ve implemented the control, so that part of the environment is now protected.
Of course, the control itself is still technology. It has software, configurations, credentials, dependencies, privileges, and an attack surface of its own. Sometimes the characteristics that make a Security technology valuable to defenders, such as broad access or visibility into critical systems, are exactly what make it interesting to an attacker.
Several of this week’s cybersecurity stories illustrate the problem. We’ve seen attackers exploit enterprise VPN infrastructure intended to provide secure remote access, an authentication bypass affecting network management systems, and Microsoft patching a vulnerability that could bypass SmartScreen protections. Researchers are also warning about malware specifically designed to target industrial control environments, where the consequences of a failed Security boundary can extend well beyond traditional IT.
The individual vulnerabilities matter, and organizations running affected technologies obviously need to address them. From an engineering perspective, though, there’s another question worth asking: What happens if that control doesn’t work?
A compromised VPN shouldn’t automatically provide unrestricted access to the internal environment. Getting around authentication shouldn’t necessarily mean gaining administrative control. Malware that gets past a preventive control should still have opportunities to be detected and contained. The idea isn’t that another product magically catches whatever the first product missed. It’s that the environment has been designed so the failure of one control doesn’t remove every obstacle between an attacker and what they’re trying to reach.
That’s the real value of layered Security.
It’s sometimes represented as a stack of technologies, which can make the concept look like an exercise in accumulating controls. In practice, the number of products matters far less than whether the layers actually complement one another. Identity, least privilege, segmentation, endpoint protection, monitoring, and response capabilities can all play a role, but only when they’re designed as parts of the same system rather than independent boxes on an architecture diagram.
There’s an important engineering principle underneath all of this: avoid single points of failure.
We already apply that thinking to systems where availability matters. We identify dependencies, consider likely failure modes, reduce the blast radius when something breaks, and make sure we can recover. Applying the same mindset to Security means accepting that even a well-designed and well-maintained control can eventually be bypassed, compromised, misconfigured, or simply encounter something it wasn’t designed to stop.
That doesn’t make the control ineffective. It means we shouldn’t ask any one control to be perfect.
A mature layered architecture gives an attacker multiple problems to solve while giving defenders multiple opportunities to notice and interrupt what they’re doing. When one layer doesn’t behave the way we expected, the rest of the architecture still matters.
So rather than only asking whether a Security control is working today, there’s another question I’d add to the architecture review:
What protects the protection?
🔒 Security Tip of the Week:
Choose an important Security control in your environment and consider what would happen if it stopped providing protection tomorrow. You don’t need an elaborate tabletop exercise. Follow the likely attack path and identify the next independent control that would prevent, detect, or contain the activity.
If you can’t identify one, you may have found a single point of failure worth addressing.
📌 This Week’s Outlook in a Shareable Statement:
Layered Security works best when we stop thinking of it as a collection of products and start thinking of it as an engineering decision. Individual controls will occasionally fail. The architecture should be designed so that one failure doesn’t decide the outcome.
Chris Ogles
COO, Pinpoint Security
COO, Pinpoint Security
📰 Weekly News Roundup:
🚨 Security researchers uncovered active exploitation of a critical zero-day vulnerability in enterprise SSL VPN gateways, allowing unauthenticated attackers to achieve remote code execution and gain initial access to targeted corporate networks.
🔓 A global logistics company confirmed a significant cybersecurity incident after ransomware actors breached internal networks, leading to localized operational disruptions and the exfiltration of employee and shipping partner data.
⚠️ CISA added a high-severity authentication bypass flaw impacting widely deployed network management systems to its Known Exploited Vulnerabilities catalog, issuing strict remediation mandates for enterprise and government networks.
🛡️ Microsoft released emergency security updates to address a zero-day bypass vulnerability in Windows SmartScreen that allowed malicious executables to evade Mark-of-the-Web safety controls and launch undetected payloads.
🌐 Cyber intelligence firms issued joint warnings regarding a novel malware framework designed to target Industrial Control Systems (ICS) and SCADA infrastructure, capable of hijacking operational technology in the energy sector.
|
|