Maslow’s Hierarchy of Security Controls

You've probably heard of Maslow's Hierarchy of Needs. It's a useful way to think about human needs and the priority in which we tend to fulfill them. Somebody dealing with a physiological crisis such as lack of food and water is unlikely to improve their situation much by focusing on self-actualization issues like finding opportunities for their artistic expression.

When thinking about an organization's security stance or security controls, I find that there is a very close parallel to Maslow's Hierarchy of Needs. I call it Maslow's Hierarchy of Security Controls. If an organization is struggling to contain known viruses exploiting patched vulnerabilities, they are unlikely to improve their situation much by trying to address zero-day attacks that operate in a "forensically clean" stealth mode.




When it comes to system defenses and security controls, there are many controls and mitigations you can employ:

  • Antivirus
  • AppLocker in "Deny" Mode (or another technology that does Application Blacklisting)
  • AppLocker in "Allow" Mode (or another technology that does Application Whitelisting)
  • Auditing (especially of implemented security controls)
  • Forensic capture and analysis of host-based artifacts (filesystem, network, registry, etc.)
  • Forensic capture and analysis of memory-only artifacts

Each control depends on the protection of those below it in the hierarchy of security controls. If you only add security controls near the top of the hierarchy, attacks can trivially avoid those controls by exploiting weaknesses lower in the hierarchy.

Here's a deeper look at these controls, and how they build on each other:



Impact Without Control


Antivirus / Antimalware

Can limit the execution of malware known to the AV industry.

Attacker can write and run any code, custom C++ applications, internet tools, etc.

Can be disabled by administrators. AV signatures can be evaded if the attacker is capable of recompiling or modifying an application.

Applocker in Deny Mode

Can limit the execution of malware known to your organization.

Attacker can write and run any code, custom C++ applications, etc., as long as they aren’t well known attack tools or exploits.

Can be disabled by administrators. Only blocks known evil / undesirable malware, can be bypassed with only minor application changes.

Applocker in Allow Mode

Can prevent the execution of unknown / unapproved applications.

Attacker can write arbitrary custom applicatons, as long as they are not detected by AV or Applocker Deny rules.

Can be disabled by administrators. Attacker can still leverage in-box tools like VBScript, Office macros, HTA applications, local web pages, PowerShell, etc.

Auditing of protections (AppLocker registry keys, AV settings, etc.)

By implementing and watching for registry / filesystem audit events generated when an attacker disables protections like AppLocker, attackers become more visible.

Attacker can disable most built-in controls, and then compromise a system without being impacted by that control.

Auditing is a reactive technology, not a preventative technology. An attack might still be successful, but proper audit monitoring can help you detect it.

Forensic capture / examination of host-based artifacts

Can help detect attacks based on in-box applications that modify the system in some way (such as putting a .VBS / .HTA file on disk).

Attacks that leverage in-box tools may not be detected.

Requires significant expertise and custom tooling to capture and forward all “interesting” forensic artifacts. Can be avoided by in-box components (such as Internet Explorer, VBScript “stagers”, PowerShell, and debuggers) that have the ability to invoke in-memory commands.

Memory forensics / application-specific logging

Can detect forensic artifacts that do not touch disk.

Memory-only attacks may go undetected.

Not all components that have the ability to invoke in-memory commands expose application-specific logging. Memory-only forensics require significant expertise and custom tooling.


So if you find yourself or an organization considering mitigations or security controls at a high level in Maslow's Hierarchy of Security Controls, be sure that you've covered your bases at the lower levels, too. Otherwise, your return on investment will be exceedingly low.

(Link to this in PPTX format: Maslow's Hierarchy of Security Controls)

4 Responses to “Maslow’s Hierarchy of Security Controls”

  1. ERROR_OUT_OF_MEMORY writes:

    This is a nice simple approach to security. I like it. Currently I’m slowly deploying AppLocker whitelisting. What are some tools that are used for the top three levels of the hierarchy?

  2. Who’s afraid of PowerShell security « Gerald's Brain Dump writes:

    […] […]

  3. Brakeing Down Security Podcast: 2019-037-Lee Holmes, Powershell logging, and why there's an 'execution bypass' writes:

    […] Maslow’s security Hierarchy:  […]

  4. Brakeing Down Security Podcast: 2019-038- Ethical dilemmas with offensive tools, powershell discussion with Lee Holmes - Part2 writes:

    […] Maslow’s security Hierarchy:  […]

Leave a Reply