Types of Security Controls

A security control is any safeguard put in place to reduce risk, and the types of security controls in common use fall along two independent axes rather than one list. That includes technology such as a firewall or an encryption setting, processes such as an access review or a change approval, and rules such as a policy that requires background checks.

Controls are usually described along two independent axes, and mixing them up is the source of most of the confusion in this area. The first axis is type, meaning what kind of thing the control is: technical, administrative, or physical. The second axis is function, meaning what the control does about a threat: prevent it, detect it, correct it, and so on.

Every control has a position on both axes. Multi-factor authentication is technical by type and preventive by function. A quarterly access review is administrative by type and detective by function. A door lock is physical and preventive, and once you hold the two axes separately, the various published lists of "the types of security control" stop contradicting each other, because most of them are quietly listing one axis, the other axis, or a mixture.

These are three functions on the same axis, describing what a control does relative to an adverse event in time.

• Preventive controls act before: they try to stop the event from occurring at all. Multi-factor authentication, network segmentation, input validation, and least privilege are preventive.
• Detective controls act during or after: they identify that something has occurred or is occurring. Logging, monitoring, alerting, intrusion detection, and access reviews are detective.
• Corrective controls act after: they limit the damage and restore the state. Backups and restoration, host isolation, patching in response to a finding, and incident response procedures are corrective.

The relationship between them is the point. Prevention will fail at some rate, which is why detection exists. Detection produces knowledge but changes nothing, which is why correction exists. A program heavy on prevention and light on detection has no idea how often prevention failed, which is a genuinely common position and an uncomfortable one. You cannot fix what you never saw.

Several other functions appear in various frameworks alongside these three, most often deterrent (discourages the attempt, such as visible monitoring or warning banners), compensating (a substitute when the intended control isn't feasible), and directive (instructs behavior, such as a policy). They are legitimate categories and they are also where the published lists start to diverge.

There is no settled answer, and the disagreement is real rather than a matter of one source being wrong. Published lists give three, four, six, seven, or eight, and pages routinely answer "there are three types" while describing six of them in the body.

The reason is the two-axis structure described above:

• By type, there are three: technical, administrative, and physical. NIST SP 800-53 splits the middle one into managerial and operational, which produces four.
• By function, there are commonly six or seven: preventive, detective, corrective, deterrent, compensating, and directive, with some lists adding recovery as separate from corrective.

Three and six are therefore both correct answers to different questions, and a list of eight is usually a merged set containing items from both axes.

Stop asking how many there are and ask what the categorization is for. If you are mapping controls to a compliance framework, use whichever taxonomy the framework uses and stay inside it. If you are trying to find gaps in your own program, the function axis is more useful, because the useful question is "what do we have that detects this, and what do we have that corrects it." If you are assessing coverage across the organization, the type axis is more useful, because it surfaces the administrative and physical controls that a purely technical inventory misses.

Multi-factor authentication requires more than one kind of evidence to prove identity, drawn from different categories: something you know such as a password, something you have such as a device or a hardware key, and something you are such as a fingerprint.

What it reliably stops is the reuse of a stolen password on its own. Credential stuffing, password spraying, and the use of credentials from an unrelated breach are all substantially defeated by a second factor wherever that second factor is actually enforced, and that covers a large share of opportunistic attacks.

What it doesn't reliably stop is more important to understand, because this is where the assumption that multi-factor authentication solves identity risk breaks down:

• Real-time phishing proxies: the victim enters the code into a site that relays it to the real service immediately. One-time codes by text message or authenticator app do not survive this.
• Session and token theft: malware or a phishing kit steals the session cookie after authentication has already succeeded, so the second factor was completed and is irrelevant.
• Push fatigue: repeated approval prompts until somebody accepts one, often at an inconvenient hour.
• Help desk and recovery-flow abuse: convincing a support process to enrol a new device. This bypasses the factor rather than defeating it.
• Anything that does not use the authentication path: such as legacy protocols that were never enrolled, or a service account with a static key.

The distinction that matters is between phishing-resistant factors, meaning those bound cryptographically to the site such as FIDO2 and WebAuthn hardware keys and passkeys, and everything else. NIST SP 800-63B is the reference for what counts as which. Codes and push approvals are a large improvement over a password alone and they are defeated by techniques that are now commonplace. If a program is relying on multi-factor authentication as a primary control, which factor is in use is the question worth answering.

The principle of least privilege says that any user, account, or process should have only the access required to do its job, and no more. It is one of the oldest ideas in security and one of the least consistently implemented.

Its value is entirely about limiting consequences. Least privilege doesn't stop an account from being compromised, it determines what happens next. An attacker who takes over an account with narrow, well-scoped access has to work for every additional step. An attacker who takes over an over-permissioned account may already be finished.

It is hard to implement for reasons that are organizational rather than technical:

• Permissions accrete and rarely get removed: people change roles and keep the old access, so entitlements grow monotonically over a career.
• Nobody wants to be the reason something broke: removing access carries a visible risk of interrupting work and an invisible benefit, which is the wrong shape of incentive.
• Service and machine identities are worse than human ones: because they are frequently provisioned with broad rights during a rushed deployment and then never revisited.
• Determining what "required" means is genuine work: and it requires understanding what each role actually does.

The practices that make it achievable are joiner-mover-leaver processes that actually remove access on the move step, time-bounded elevation instead of standing administrative rights, and periodic review of the accounts that would cause the most damage rather than of everything at once.

Because patching is a continuous obligation with a discontinuous risk profile, and almost every organization has more things to patch than capacity to patch them, and falling behind is the default state, and the interesting question is which things you fall behind on.

The recurring causes:

• Volume: new vulnerabilities are published continuously across every product in the estate, and the arrival rate exceeds most teams' remediation rate.
• Change windows and availability requirements: patching requires downtime or restarts that business processes will not always allow, and in operational technology and healthcare environments may be genuinely unsafe.
• Dependency and compatibility risk: applications certified against a specific version block the underlying platform from being updated.
• Ownership gaps: security finds the vulnerability, an infrastructure or application team applies the fix, and the two report to different people with different priorities.
• Inventory gaps: you cannot patch what you do not know you have, and shadow systems and forgotten appliances are frequently the ones that get exploited.
• Prioritization by severity score alone: which produces a large undifferentiated pile of critical findings and no ordering within it.

That last cause is the one most within a team's control. A severity score describes the weakness in the abstract, not the risk in your environment. Prioritizing by whether the vulnerability is internet-reachable, whether it appears in CISA's Known Exploited Vulnerabilities catalog, and what the affected system holds produces a much shorter and much more defensible list than a CVSS severity threshold does. Scanners such as Rapid7 supply the inventory for that decision; the ordering is still yours to make.

You test them, because the alternative is inferring detection capability from an absence of alerts, and an absence of alerts is exactly what a broken detection stack produces.

The methods, roughly in order of cost:

• Log source health monitoring: alert on the absence of data. A collector that stopped reporting on Friday is the most common and least dramatic detection failure there is, and it is invisible unless something is watching for silence.
• Detection coverage mapping: map your detections to adversary techniques using MITRE ATT&CK, and look at what is not covered. This tells you what you never built, which is different from what is broken.
• Atomic testing: execute individual known techniques in a controlled way and confirm that the expected telemetry was produced, that the detection fired, and that the alert reached the queue. Each of those three is a separate failure point.
• Purple teaming: run an attack sequence with the offensive and defensive teams working together, and record what was seen, what was seen and dismissed, and what was missed entirely.
• Full adversary emulation or a red team exercise: which tests the whole chain including the people and the process, at correspondingly higher cost.

Two failure modes are worth naming because both look like success. The first is a detection that fires correctly into a queue nobody works, which is a coverage number that's technically true and operationally meaningless. The second is a detection that was tuned into uselessness after a noisy period and still appears in the coverage inventory, and testing the path end to end, from technique executed to human acted, is the only way either one surfaces. Proactive searching for activity that never alerted at all is a related discipline, covered in the threat hunting section.