Objective 4.01 Compare and contrast positive and negative security models

Positive Security Model

The two approaches to security most often mentioned in the context of application security— positive and negative—are diametrically opposed in all of their characteristic behaviors, but they are structured very similarly. Both positive and negative security approaches operate according to an established set of rules. Access Control Lists (ACLs) and signatures are two implementation examples of positive and negative security rules, respectively. Positive security moves away from “blocked,” end of the spectrum, following an “allow only what I know” methodology. Every rule added to a positive security model increases what is classified as known behavior, and thus allowed, and decreases what is blocked, or what is unknown. Therefore, a positive security model with nothing defined should block everything and relax (i.e., allow broader access) as the acceptable content contexts are defined. 

 

Negative Security Model

At the opposite end of the spectrum, negative security moves towards “blocked what I know is bad,” meaning it denies access based on what has previously identified as content to be blocked, running opposite to the known/allowed positive model. Every rule added to the negative security policy increases the blocking behavior, thereby decreasing what is both unknown and allowed as the policy is tightened. Therefore, a negative security policy with nothing defined would grant access to everything, and be tightened as exploits are discovered .

 

 

Pros and Cons

Although negative security does retain some aspect of known data, negative security knowledge comes from a list of very specific repositories of matching patterns. As data is passed through a negative security policy, it is evaluated against individual known “bad” patterns. If a known pattern is matched, the data is rejected; if the data flowing through the policy is unidentifiable, it is allowed to pass. Negative security policies do not take into account how the application works, they only notice what accesses the application and if that access violates any negative security patterns. Discussions on preferred security methods typically spawn very polarized debates. Tried and true security engineers might ardently argue the merits of the positive security model because it originates from the most “secure” place—“Only allow what I know and expect.” Many any business pundits would argue that the negative model is the best as it starts in the most “functional” place— “Block what I know is bad and let everything unknown through.” Both groups are correct and yet both opinions become irrelevant when projected onto applied security, because both positive and negative security are theoretical. Applied security falls somewhere in the middle of the spectrum, providing a practical balance. At some point, as

the negative approach is tightened, it will take on characteristics of a more positive model, inching towards a more complete security approach. Likewise, as a positive security model is loosened to accommodate new application behaviors, wit will take on some aspects of a more negative approach, such as implementing data pattern matching, to block the more predictable attacks. As a positive policy continues to relax, it will move

closer towards complete functionality. The point at which these two opposing concepts begin to overlap is where applied security starts to take shape.