Recently, and by recently I mean in the last three months and I am just now getting around to posting my thoughts on it, a colleague challenged whether the so-called “Postive Security Model” that I so often reference in my security architectures is really a model at all. His comments are below:
“What is the “Model” part. If it’s a principle, then isn’t the name “Positive Security”? If there is a model, then what are the components of the model? If there really is a model, then I should be able to see some set of the principles embodied in the model.”
In my opinion, the Positive Security Model is one of the fundamental models that should be included in a high-level security architecture. I recognize that it may not be practical in all situations and isn’t foolproof, but I think it is an important default control design approach. I would really like to see more developers start with this approach, and fallback on other methods when it isn’t practical to define all the allowable inputs. In network security we typically use the example of a firewall. You don’t want to start with an Any-Any-Allow rule and only block known bad traffic, you want to start with an Any-Any-Deny rule and only allow explicitly needed business traffic. I think the same model should be applied to application input validation. Only allow specified characters, lengths, types, etc. rather than just checking for bad ones.
What I like about including the Positive Security Model as a basic principle, is that it hopefully gets people into the right state of mind to approach security. Starting by defining only what should be allowed and working from there, rather than starting with defining what shouldn’t be allowed. It may just be an academic difference, but just referring to whitelists and blacklists seems too specific, and brings its own baggage. When I hear whitelist, I immediately think of Web URL Filtering for example. I think whitelisting is just one mechanism that can be derived from a positive security model. Other principles such as Least Privilege I think can also be derived from the concept of a positive security model.
I see this as one fundamental model or principle (still undecided here) that needs to be included in the highest level security architecture. It provides a good basis for approaching security design without limiting the process to well known countermeasures and controls, rather than focusing on expected business logic and interactions.
I tend to think of “positive-security” as a design principle, but almost always actually speak of it as a “positive-security model”, since it is usually applied in the context of a functional system.
In other words, security is a sub-feature of a system designed to accomplish some goal. The design of that security feature (it’s model) utilizes the principle of “positive-security”, therefore the security feature is based on a “positive-security model”.
But let’s not get bogged down in semantics
I agree wholeheartedly about your comments on the benefits of using a positive security model. It’s not a panacea, but really makes you re-frame your thinking about risk in a productive way.
If you’re trying to minimize your attack surface, trying to block every potential failure is a futile exercise. The search space is just too large. But by employing a positive description of what is expected (think of this as helpful in the same way that a unit-test is helpful), you can, in one fell swoop, excise the entire search space of things that are potentially bad (along with things that are known to be bad) because they simply have no place as parameters for that module’s task.
Sounds like a whole lot less work to me.
Of course, you may still need to take a scalpel to your “design-valid” inputs, because the code we actually write often contains logical failures as well, but that’s why unit tests along with positive-security models work so well!
-Chris