In response to "It's Only a Model" at A Techie's Musings
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 imput for that module’s task.
It amounts to an excellent way to avoid wasting resources and converge on desired results.
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!
*Data and Goliath* Published in Paperback
9 hours ago