Services
This is the first post in a short series about our proposed Hierarchy of Security Needs. It introduces the model, talks about the inspiration for the model and lays out the start of it - the base layer everyone probably needs for security. If nothing else, we aim to lay out our ideas about the most basic core components of doing security and we think that in itself is useful.
Abraham Maslow introduced the idea of a Hierarchy of Needs in the area of Psychology in a paper in 1943. The basic idea is that we need to satisfy basic human needs before we can satisfy higher order psychological and self fulfillment needs. Many people may associate it with the pyramid below (or similar).
I find this idea easy to grasp and intuitive. You have to take care of basics before you worry about the nice to haves. But ... in cybersecurity what are the basics and what are the nice to haves?
Although we prioritize different security tools constantly - spending money on one but not the other because of a perceived value - we don't necessarily have a consistent way to talk about the value or our priorities.
Now, I should also reference Josh Corman's blog post about H.D. Moore's Law and the whole idea around "you must be this tall to ride" which for me first captured the idea that if you aren't resistant to the tools we know hackers use, then you probably shouldn't be deploying a service online!
What our model is doing is basically blending and extending these ideas and trying to put some reasoning into how we prioritize security tools and initiatives.
To build a model for the security world, we started by creating some simple layers - or tiers in the hierarchy. To keep things as simple as possible, we stuck to a 4 tier model to start. I like 3 tier models even better, but I have a feeling people would find that forces harder decisions than they are ready to make.
Basic - Basic level security needs are the things we must do to survive online. Without doing them, we cannot be secure. An easy example is to use a complex password and MFA.
Basic needs are also established, understood, measurable and an implementation would have a good likelihood of successfully meeting the goals.
Intermediate - Intermediate level security needs are important and foundational for security but they may be just a bit more work to implement, issues, but they are usually more complicated to implement, require interactions or integrations and may be less universally accepted as core security requirements. Intermediate needs are widely adopted and well understood. An example of an Intermediate level security need might be adopting Single Sign On.
Advanced - Advanced security needs still address important issues, but they are usually more complicated to implement, require interactions or integrations and may be still in the early adoption phase of a security product lifecycle. An example of an advanced security item in the identity space might be Fido2 / WebAuthn and Yubikeys. These tools significantly ease authentication and protect from things like phishing, but most organizations we work with haven't adopted them. Partly because they are still getting basic passwords and SSO done.
Note that the Advanced name is not intended to necessarily mean "technically advanced". It means it would take an advanced organization to run them and we typically see them in higher maturity organizations.
Experimental - Experimental Security Needs also address important issues, but usually through a new method that isn't as proven or in a new area that people are recognizing requires security in a different way. Experimental security needs may address an issue that is important and keep you ahead of an attacker, but they still have a relatively high likelihood of failing. Experimental security is most commonly adopted by very mature organizations that have budget set aside to experiment.
An example of experimental level security needs might be Okta Verify and it's capabilities to provide seamless passwordless login based on device configuration, certificates and a set of user roles. In this case, the technology isn't really risky per se, it is just very new (as of 12/2022) and there is some complexity to the initial set up because an optimal deployment probably depends on an MDM (Mobile Device Management) solution as well.
A caveat: there is nothing we can do that will guarantee our security. There is no tool to implement, no compliance standard we can follow, not even an amalgamation of all of these things that can possibly address all aspects of the pyramid. The purpose of all of this is not to say one thing is better than another, but just to normalize how we talk about our priorities.
Let us try to define some more specific evaluation criteria for determining which tier a particular solution XYZ-TOOL should go into. In the following examples, the assessment of each item drives an item toward being lower in the hierarchy of security needs, though some drive all the way to Basic and others only drive to Intermediate.
Of course, these are highly unscientific judgments. I've only seen so many real world companies and breaches. I haven't tested all of the tools or solutions, and I'm not trying to advocate for or against any security tool or vendor. I am presenting a mental model with the hope that it may be useful. Speaking of security vendors ...
My experience is that security vendors both want to do the right thing and have an overdeveloped sense of how important and effective their own tools are. Unfortunately, the security tool landscape is so complex, it isn't easy to compare any tool to any other tool except in a narrow field!
So from a commercial security tool vendor perspective, there are a couple of obvious things to observe about incentives and messaging as we think about this model:
This section dives into the idea of the Basic level of security needs in the Hierarchy and introduces a number of items that fit into basic security needs. Remember, the Basic security needs level captures the things that pretty much everybody agrees we need to do. If the whole model is too complex to be useful, maybe this set of basic needs can help some people.
Doors That Lock - have doors that lock between random people in the outside world and any computers, files or other valuable or sensitive information. If possible, use stronger locks than residential grade locks. If larger, use keycards with biometrics that also track access controls.
Endpoint Detection and Response (EDR) - EDR is the current incarnation of antivirus or anti-malware. It is sometimes bundled to be XDR, MDR or other agent names. Common EDR that we see include CrowdStrike, SentinelOne and Microsoft Defender.
User Directory and Minimal Roles - We need a user directory (Azure AD, JumpCloud, Google Workspace, Okta, etc.) to have a way to track who our company users are. We generally want to use the same tool to capture the user's various groups and roles so that we can, in one place see, manage and audit different users' access to different systems.
No Open Storage Buckets - Many systems use cloud based storage (eg. AWS S3, Google Cloud File Storage, Azure File Storage) and unfortunately, it is surprisingly common to find sensitive data exposed in public storage buckets. This is common enough that we put this in a basic security category. If you're not doing this, nothing else can protect you.
Systems Patched - Patching is essential to keeping our systems secure. When a system isn't up to date, that means that there are available patches out in the world that we haven't applied. Industry reports such as the Microsoft Digital Defense Report note that attackers are using the patches to reverse engineer attacks that can be used to target systems. So there are actually increasing risk for systems that are unpatched.
Use of MFA for Ops, Admin, Financial - Since Multifactor Authentication (MFA) is harder to fake than a guessed or stolen password, we believe MFA is a cornerstone basic security control that must be applied for Google, Github, AWS, Azure, Quickbooks, Email and any other mission critical system.
Regulated Data Identified and Protected - If we don't realize we have regulated data, we may not protect it as well as we should. We need to develop sensibilities around which data is truly sensitive and an easy way to start is with regulated data like PHI, PII, and Credit Cards (PCI-DSS). All data like this should be encrypted in transit (eg. TLS) and at rest (eg. AES-256). We should also restrict access to only a small subset of users.
Financial Process Controls - A common attack these days is to find out a vendor that a company uses and change the payment information used. For example, Jemurai currently uses Harvest for tracking our timesheets. We pay by credit card. If someone were able to impersonate Harvest and tell us to re-enter our card or update the bank account we send wires to, they could get us to make our payments to Harvest go to themselves. To prevent this, we need checks and balances in the payment process to ensure that vendors are controlled.
PhishingPhishing is a type of social engineering attack in which attackers use fraudulent emails, text messages, or other forms of communication to trick individuals into providing sensitive information or performing actions that can compromise their security. / Social Engineering Resistance TrainingIn the context of cybersecurity, training refers to educating employees, contractors, and other stakeholders about security best practices and policies. This can include training on how to recognize and avoid common phishing and social engineering attacks, how to create strong passwords and use multi-factor authentication, how to handle sensitive data, and how to respond to security incidents. Effective training programs are ongoing and can help organizations reduce the risk of human error and improve overall security posture. - One of the most common ways that organizations get compromised with either credential theft or malware is by users that click on phishing emails and either supply their credentials or inadvertently allow malware to be installed on their device. Training users to avoid phishing emails or other social engineering scams is a core part of any security program.
The goal of this post was to introduce a Security Hierarchy of Needs. We walked through the inspiration for the model, talked about what the levels mean, and then we started to talk about what tools are in the Basic level. The goal is not necessarily to perfectly sort the tools. The goal is not to say one tool is better than another. The goal is to provide a mental model for having these conversations so that we can talk about the answer to:
Given that XYZ-Tool is an Advanced level security need, when is an appropriate time to adopt it?
Future posts will iterate on the model and talk about tools that fit in the higher levels. We'd love to hear your feedback about the model, tools or what you think we messed up!
