Elementary Application Security Part 1: Look Both Ways Before Crossing The Street

Whenever you design a piece of software, a good rule of thumb is, "Simple is better." Sure, we can't always make our applications as simple as we'd like, but it is an ideal that designers have been chasing for a long time. In this spirit, I am writing a series of blog postings relating to application security based upon some very simple principles most of us remember from elementary school. It is the intent of this series that you, the developer, will be able to apply good, solid security principles in your software design.

Part 1: Look both ways before crossing the street.

How many times have we heard this sentence? It's pretty good advice, since we don't want to get hit by an oncoming car! You have to look and see what is heading in your direction, if you want to safely travel across a road. With that being said, how often do you "look both ways" before releasing software? Do you see what oncoming threats are out there that might "hit" your application? Is it important to even look at all?

Here's a good reason. Your application is far more likely to be a target for hackers than your Windows operating system. You heard correctly. Applications are responsible for more software exploits than your operating system. IBM released a study in January 2008 that shows in the year 2007, only 6% of all vulnerabilities focused on the actual Windows operating system. It also shows the rising trend of application-focused hacks, 94% of them, to be exact, in the year 2007.

So, how do you handle this?

One of the best actions you can take to minimize a hacking threat is the use of a threat model. Threat modeling is the action of reviewing your application and making visual model of potential threats. After that, those threats are eliminated or reduced.

There are many ways to threat-model your new or existing application. Three of those methods are described below.

Attacker-based Modeling - This involves looking at all of the types of hackers, what their motives might be, and how they might initiate an attack on your application. It might start with a simple statement, "Someone wants to take money away from my bank account" and work from there. If you think of it, in terms of securing a house, you're thinking about "Who wants to break in?"

While this method is a good exercise, it is by no means the most appropriate. That is because you might view some data as being irrelevant when, in actuality, might be the target. So, if you focus on a hacker attempting to secure someones bank account balance (and transfer money out), a target might actually be addresses. Or Phone Numbers. Or Social Security Numbers.

Asset-based Modeling - This is the opposite of an attacker-based model. Instead of focusing on the motivations of hackers, it looks at the would-be hacker's target. So, using the example of the bank account, it would focus on bank accounts, social security numbers, and any other data which might be viewed as valuable. Using the securing a house analogy, you're thinking about, "What might people want to take out of my house?"

This method also relies upon a the security team to recognize what data is valuable and what data is not. The drawback here is data can be misinterpreted as not needing to be secured. It also tends to focus on "real data" and doesn't lend itself easily to the prevention of denial of service attacks.

Software-based Modeling - This involves stepping through an application to determine where unauthorized people might attempt to break in to your application. This has also been called "design-centric" modeling. It is also the approach used in Microsoft's SDL (Security Development Lifecycle). You walk through how the application works (from Installation, to user launching, to application exits) in order to determine where hackers can compromise your application. In the securing a house analogy, you're thinking, "How might someone break into my house?"

This method is probably the most appropriate for threat-modeling. Rather than having to estimate valuable data or unknown hackers, it goes through an application piece by piece, area by area, to determine how *any* attacker might want to compromise your system.

There are articles and tools available to assist you in threat modeling.

• MSDN has an older article on using the STRIDE approach to uncovering design flaws.
• The Microsoft Security Development Lifecycle has its own web page. >.
• the Microsoft SDL page has a threat modeling tool (using Visio 2007) to assist in your diagrams.

Remember: Everyone needs to pitch-in to make a secure environment. By using these tips and tools, you are making sure YOU have looked both ways and have helped secure your application.