Network Security
Security Controls
Build a structured library of preventive, detective, and corrective controls — and learn how to match each one to the specific risks it actually addresses rather than the risks it sounds like it addresses.
The Control That Was There But Did Not Work
A large retailer suffered a point-of-sale breach that lasted nine months and exposed 40 million card numbers. When investigators reviewed the security stack afterward, they found the company had antivirus software installed on every affected system. The antivirus had even detected the malware — and generated alerts. But those alerts went to a monitoring queue that no one checked regularly, and the software had been configured to log rather than quarantine. The control existed. It detected the threat. And it did absolutely nothing useful about it.
That incident illustrates the central challenge of security controls: having them is not the same as having them work. A firewall rule that allows everything, an IDS that generates a thousand daily alerts that nobody reads, a password policy that employees route around with sticky notes — these are the appearance of control without the substance of it.
Understanding security controls means understanding not just what they are but what they are designed to do, where they operate, and critically — what they cannot do. Every control has a scope, a failure mode, and a set of threats it was never meant to address.
The Three Functions: Prevent, Detect, Correct
Every security control fits into at least one of three functional categories. These categories describe what the control does when a threat materializes — not what it is made of or where it sits in the network. The same physical device can serve different functions depending on how it is configured and where it is placed.
Preventive Controls
Stop the threat before it causes harm. A firewall that drops malicious traffic, MFA that blocks a stolen password from granting access, encryption that makes stolen data unreadable — these controls act before damage occurs. Their value is invisible: you never see the attacks they stopped, only the ones they missed.
Detective Controls
Identify when something bad has happened or is happening. Log analysis, intrusion detection systems, and anomaly detection fall here. They do not stop the attack — they generate the signal that makes a response possible. Without detective controls, breaches persist for months because nobody knows to look.
Corrective Controls
Restore normal operations after an incident and limit ongoing damage. Backups that enable recovery after ransomware, incident response playbooks that guide the team through containment, patch management that closes the vulnerability an attacker used — all corrective. Their quality is measured in recovery time, not prevention rate.
Deterrent Controls
Discourage attacks by making them seem too costly or likely to fail. Legal notices, visible security cameras, warning banners on login portals, and published security certifications all signal that an attack on this target will face resistance. Deterrents work on motivated humans — they do not deter automated scanners that run regardless.
A mature security program has controls in all three primary categories working together. Prevention without detection means you never know when prevention fails. Detection without correction means you identify incidents you cannot recover from. And neither category substitutes for the other — a perfect detective control that identifies every attack is useless if there is no preventive control limiting what the attacker can actually reach.
Control Types: Administrative, Technical, Physical
Beyond function, controls are also classified by their nature — the form they take and the mechanism by which they act. This second dimension matters because different control types reinforce each other's weaknesses. A purely technical security program fails when human behavior routes around it. A purely administrative one fails when no technical enforcement exists.
The Three Control Types — and How They Interact
Administrative controls are policies, procedures, training, and governance. An acceptable use policy, a mandatory security awareness training program, a vendor risk assessment process, and an incident response plan are all administrative. They define what people are supposed to do. Their weakness: compliance depends on people following them, and people are inconsistent. An untested incident response plan is a document, not a control.
Technical controls are implemented in hardware or software and enforce their function automatically. Firewalls, encryption, access control lists, intrusion prevention systems, and multi-factor authentication are technical. They act regardless of whether a person remembers the policy. Their weakness: they require correct configuration, ongoing maintenance, and monitoring to function as intended — which brings humans back into the loop.
Physical controls govern access to physical spaces and hardware. Locked server rooms, badge readers, security cameras, cable locks, and tamper-evident seals are physical. They address the reality that network access sometimes requires physical proximity — a USB device plugged into a server bypasses every network-layer control in existence. Their weakness: physical security is often underfunded until after an incident involving it.
Why All Three Types Must Coexist
Consider a server room with sensitive hardware. A technical control might encrypt the drives and require authentication to access the OS. A physical control might require a keycard to enter the room. An administrative control defines who is authorized to hold a keycard and mandates that access lists be reviewed quarterly. Remove any one of these: an attacker with a stolen keycard but no credentials is stopped by the technical control. An attacker with stolen credentials but no keycard is stopped by the physical control. An employee who was terminated last month but still has keycard access — because nobody ran the quarterly review — is stopped by neither.
Mapping Controls to the Risk They Address
The most common security control mistake is not having too few — it is having controls that do not map to the actual risks the organization faces. A company spending heavily on sophisticated endpoint detection and response while running an unpatched public-facing web application has its defenses pointing the wrong direction. The threat landscape and attack surface analysis from the previous lessons exist precisely to inform this mapping.
Notice that no single control appears across every row. Ransomware recovery requires offline backups — a detective control designed for phishing will not help you restore encrypted files. MFA blocks credential theft but does nothing to limit damage once a legitimately authenticated user decides to exfiltrate data. Each risk demands its own control set, mapped explicitly, with the gaps documented and accepted or addressed.
Control Failures: Why Good Controls Stop Working
Controls degrade. Configurations drift from their hardened baseline as systems are updated, exceptions are added, and engineers work around inconvenient restrictions. A firewall rule added urgently during an incident to allow a vendor temporary access, noted in a ticket as "remove after Monday," that is still in place eighteen months later — is no longer functioning as designed. This pattern repeats in every organization at every scale.
Beyond drift, controls fail through several other predictable mechanisms. Alert fatigue kills detective controls: when an IDS generates five thousand alerts per day and analysts can review two hundred, the three thousand eight hundred unreviewed alerts might as well not exist. Security teams tune toward noise reduction — sometimes too aggressively, suppressing alerts that would have caught real attacks. Coverage gaps emerge when the threat landscape shifts faster than the control set: a control designed for on-premises infrastructure provides partial visibility at best into cloud-native workloads. Bypass techniques evolve — attackers study what controls exist and develop methods to operate beneath their detection thresholds.
TechPulse: Meera Audits the Control Stack
Meera inherited a SIEM that had been running for two years generating an average of 4,200 alerts per day. The previous IT manager had responded by creating suppression rules for the most frequent alert types — which now covered 94% of all alerts. The remaining 6% were reviewed when someone had time. She pulled the suppression rule list and found that one rule was silencing alerts for outbound connections to a known malware C2 IP range that had been added to the threat intelligence feed eight months ago. The rule had been created to suppress false positives from a legitimate CDN that shared an IP range with that C2 infrastructure — a reasonable decision at the time that became a dangerous one when the CDN migrated and the suppression was never revisited. Three workstations had been beaconing to that IP range for the past four months. The control had failed not because it was wrong — but because nobody had maintained it.
Compensating Controls: When the Ideal Is Not Possible
In an ideal world, every identified risk has a direct control that eliminates or reduces it to acceptable levels. In practice, some risks cannot be addressed with the ideal control — because the system is too legacy to support it, because the business requires a level of access that security would prefer to restrict, or because the cost of the ideal control exceeds the cost of the risk it covers.
A compensating control is an alternative measure that reduces risk to an acceptable level when the primary control cannot be implemented. The concept is formalized in compliance frameworks: PCI DSS explicitly allows compensating controls when a standard requirement cannot be met, provided the alternative demonstrably reduces the same risk the standard control was designed to address.
Primary Control
The ideal, direct response to a specific risk. MFA as the primary control for credential theft: it prevents a stolen password from granting access regardless of how the password was obtained or how strong it was.
When unavailable: a legacy VPN client that does not support modern MFA methods requires a compensating approach while migration is planned.
Compensating Control
An alternative that addresses the same risk through a different mechanism. If MFA cannot be added to the legacy VPN: restrict access to specific source IPs only, shorten session timeouts, enforce certificate-based authentication, and alert on any off-hours login from that system — together reducing the risk MFA would have addressed directly.
The requirement: document why the primary control cannot be implemented and demonstrate that the compensating controls reduce risk to an equivalent level.
Control Effectiveness vs Control Existence
Auditors check for the existence of controls. Attackers test their effectiveness. These are different things, and the gap between them is where most breaches live. A penetration test that bypasses every technical control in the environment is doing the organization a favor — it surfaces the gap before someone with bad intentions does. Regular testing, red team exercises, and purple team collaboration (where defenders and simulated attackers work together) are how organizations close the distance between "we have it" and "it works."
Building TechPulse's Control Framework
After completing her attack surface audit and threat modeling work, Meera built TechPulse's first structured control framework. She started from the risks identified in the previous two exercises — not from a compliance checklist — and mapped each risk to its current control coverage, identifying gaps and the priority order in which to address them.
The framework had three columns: the risk, the controls currently in place, and the control gap. Some gaps were acceptable — the risk was low enough that the cost of addressing it exceeded its expected impact. Others were not: the customer-facing portal had no WAF in front of it and no anomaly detection on its database queries, meaning a successful SQL injection attempt would be both easy and undetected. That gap went to the top of the engineering backlog the same afternoon.
The framework also tracked control ownership. Every control had a named owner responsible for its configuration, maintenance, and regular testing. Ownerless controls — the most common kind in organizations without this practice — tend to drift toward ineffectiveness because nobody is accountable for noticing when they stop working. Assigning ownership turned the framework from a document into an operational artifact.
The control question every security team should ask quarterly: For each control in the stack — when was it last tested, by whom, against what threat scenario, and what was the result? If any control cannot answer all four questions with recent data, it is operating on faith rather than evidence. Faith is not a security posture.
Quiz
1. TechPulse deploys a system that monitors outbound network traffic and triggers an alert when any single connection transfers more than 500MB to an external IP not on the approved list. An analyst reviews the alert and discovers a large data transfer in progress. Which control function does this system perform?
2. TechPulse's SIEM generates 4,000 alerts daily. The previous admin created suppression rules that reduced visible alerts to 250 per day. Meera discovers that one suppression rule is hiding outbound connections to a known malware command-and-control range. Which control failure mode does this represent?
3. TechPulse's legacy HR system cannot support MFA due to its authentication architecture and cannot be replaced for another 18 months. Meera restricts the system's access to VPN-connected devices only, enforces certificate-based authentication, limits login hours to business hours, and enables real-time alerting on any login attempt. What type of security control approach is she applying?