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?
