Security Should Be Application-Specific

I'm looking for the perfect pants. They’re brown. They’re sturdy. They’re business casual. They have many huge pockets, artfully arranged so that I don’t look like a pack rat even after I stash my stuff in them. They don't cost a fortune. And of course, they fit me perfectly.

I have never met these pants. But if I did, I certainly wouldn’t give them to my cousins, who wish for black leather and pajama jeans respectively, or my friend from college, who is into purple cargo pants, or my brother, who is a good five inches taller than I am, even though every one of these people deserves the perfect pair of pants

Security, like perfection in pants, is in the eye of the beholder.

Different Strokes for Different Folks

What one stakeholder thinks is the very nature of security may be unimportant to another. For example, patients, doctors, hospitals, and health insurance companies are all stakeholders for medical practice management software, which will contain patients’ personal health information. To make sweeping generalizations, patients care most about confidentiality and integrity. Doctors and hospitals care most about integrity, availability, and authenticity, since that is what they need to treat patients successfully and defend themselves against mistakes and malpractice suits. Insurers care most about authenticity, since they only want to pay for services that were actually performed. These stakeholders would prioritize the same set of security goals differently, but a single product could satisfy them all.

In other cases, stakeholders have directly opposing security goals. Viewers want to use their existing, decades-old equipment to watch digital movies. Movie studios do not want attackers using general-purpose equipment to copy movies. Since the interfaces to older existing equipment are the same whether one is watching or copying, a single set of security goals can never satisfy both stakeholders.

One Law

In the end, application behavior, like pants in the time before spandex, is deterministic. Manufacturers can (but in my experience, rarely do) make pants that fit arbitrarily curvy people, and software developers can (but in my experience, rarely do) write software that securely enforces arbitrarily complex business rules. However, any given pair of pants will fit a limited range of people, and any piece of software will achieve a limited range of security objectives.

Since in practice, only one thing is going to happen given each input in each situation, the advantage of selecting a single set of security objectives in advance is this: Development or procurement can identify and focus on things that actually affect the security of this application according to you. Depending on what you hold constant, this means either better security for the same cost, or the same security for less effort.

What Goes Into a Security Objective?

Security objectives define:

• The attackers the system should protect against
• The prohibited actions these attackers should not be able to perform
• The response the system should exhibit instead of allowing the attack
• The initial configuration the system must be in, for protection and response to occur

A complete security objective has all four of these components.

Prohibited Actions

A prohibited action is a negative outcome that is meaningful to both the business and this application, and has a high impact (relative to the system’s purpose) on at least one stakeholder. When such an event appears in the security objectives, the system intends to prevent an attacker from reaching this outcome. For example, “steal wearer’s wallet” is a threat some pants try to defend against.

When security objectives do not include prohibited actions, security issues become a matter of opinion, and you get endless argument instead of consistent security.

Attacker Starting Privileges

Attackers are the threat agents who should not be able to perform the prohibited actions. There are many ways to characterize threat agents. For the purposes of selecting or constructing a system or service, the only attacker property that has a technical impact, and therefore the only property you need to put in the security objectives, is starting privileges. For example, if you are a secret agent, perhaps “report wearer’s location” is a prohibited action for your pants. You could include “extended physical access” as a corresponding attacker starting privilege. Hotel staff, dry cleaners, tailors, house cleaners, housemates, customs agents, and airline staff could all have this starting privilege.

When security objectives do not include starting privileges for attackers, there are many more possibilities for both the location and type of defenses the system could incorporate, and no clear criteria for choosing among them. Again, you risk endless argument instead of consistent security.

Intended System Response

If an attacker tries to perform a prohibited action, the system should respond in some way. Unless it is a honeypot, thwarting the attack is a good first step. Detecting an attack, and then logging it or alerting someone, is also a popular choice.

When security objectives do not include an intended system response, developers will (quite sensibly) do either whatever is easiest for them or what they think is best for security, and the system is unlikely to respond to attacks consistently. System administrators are likely to have a consistent response in mind, but will often find themselves unable to implement it because the underlying system does not expose the information or interfaces they need.

Initial System Configuration

The initial system configuration describes the state the system must be in for the protection in this objective to occur. This could include settings (zip-off pants — as seen below — to the rescue!), adherence to installation or configuration guidelines, internal application state, or the availability of outside resources. For example, alerting someone about an ongoing attack could require an external syslog server, and protecting my wallet from theft could require that I put it in the Kevlar-lined inner pocket.

Without an initial system configuration, a security objective would apply in unreasonable situations, and developers could spend significant extra time on interesting, but ultimately futile attempts to meet it anyway. For example, what if I left my wallet on the coffee table? I am sure I am not alone in mentally designing robotic pants with high-powered lasers and built-in facial recognition to defend my wallet against everyone but me. You could also end up arguing about what counts as a security issue, and the scope of this system.

Pulling It All Together

Security objectives should contain the same information and have the same meaning, no matter what their format. This text template shows how the four components of a security objective relate to each other:

When the initial configuration holds, the system shall not allow attackers to take the prohibited actions. If such an attack is attempted, the system shall have the following intended response instead.

Here is an example security objective for my perfect pants, in the table format I prefer:

Paraphrased slightly to read well in the text template, this security objective means:

When the wearer is wearing pants that fit and the wearer’s wallet is in the hidden interior pocket, the pants shall not allow an attacker with momentary access to the outside of the pants to steal the wearer’s wallet. If such an attack is attempted, the pants shall thwart the attack and alert the wearer.

This security objective should be enough to protect your wallet without risking tragic accidents or epic cost or schedule overruns. Good luck negotiating security objectives for your next project!

Next time: What is security architecture, and how would I use it to avoid indecent exposure charges when I reach for my wallet?

Read Brenda's previous installment in this series, "Beyond Security Requirements: Secure Requirements," here.

Zip-off pants image by Brenda Larcom