Building Security In - Case Study from the Physical World

One of the main issues in software security is that the security requirements for an application are typically driven by random concerns that have little to do with providing security. These include: developer convenience (ajax rawks!), lowest common denominator (hey the mainframe can only support a 6 character password, let's use that throughout), and compliance driven security (check box Olympics). Sadly, these are the most widely adopted drivers in software security. We can hope to evolve to something is more driven by architectural risk analysis, specifically building security in instead of building vulnerabilities in.

Here is a case in the point from the physical world.

iCasualties reports that IEDs have killed 1,457 Americans in Iraq. This represents 40 percent of the total 3,609 total Americans killed in Iraq.

The main culprit was identified as the hillbilly armor and Humvees that were never designed to withstand IEDs. As the threat environment evolves, so must the countermeasures.

The Pentagon is working to replace every Humvee in Iraq with a MRAP (Mine Resistant AMbush Protected Vehicles). The main innovator is a company called Force Protection which builds MRAPs that have a v shape hulls that are designed to withstand IED blasts. The Cougar has been deployed for about a year and has taken 1,000 IED hits without a loss of life.

Of course, the threat is likely to try to identify new vectors, but the point is that a minimum posture should include not building known vulnerabilities into the system.

There are several lessons here for software security.

For software people - stop building hillbilly armor - aka Web Services (SOAP, Rest whatever), Web app developers, and so on "we have SSL and a network firewall, looks good to me." Instead identify vulnerabilities and build real countermeasures to address them. The real vulnerabilities are probably not listed in the security policy or in the compliance spreadsheet.

For "its perfect or its broken" security people - a security mechanisms need not address all known threat to be valuable. Jets, tanks, and a whole host of other things can probably take out a MRAP. The point is to find a cost effective way to make incremental improvements. Pragmatically moving forward as a design partner in the development process is the way forward.

For everyone who complains security is too hard or no one asks for it - you don't have to start with an uber be all end all team to get going. Force Protection started by hand building MRAPs with a team of twelve people. The point is the design work is hard and the deployment work is also hard, but you don't have to conflate the two. Start small, focus on teh security engineering in a way that you hit your security goals but can also scale, get stuff working, and get it deployed to users/environment. This creates demand from users, you think a Marine would rather ride in a MRAP or a Humvee? The demand from users is what will help you scale.

Comments

[Iang]

From a military perspective, this is obvious. The Humvee isn't an APV -- armoured personnel vehicle -- like the old M113s, which were *designed* to cope with such things. Therefore it is not a fighting vehicle, it's a transport vehicle. Better known as a taxi, coz it's not a truck.

Putting the Humvee in harm's way got the expected result: harm. While I admire the hillbilly armour as a good response to the circumstances, the basic flaw here is in the requirements. No amount of Mad Maxian reworks will solve this problem.

Still, seems like the US army has more basic problems that knowing the difference between a taxi and a tank. Just like our field :)