Application Security is a Journey, Not a Destination

Submitted by Mike Rothman on Wed, 2009-03-11 13:45.
Today's Daily Incite

March 11, 2009 - Volume 4, #24

Application Security is Journey, Not a Destination

Good Morning:
Long time readers of my ramblings can remember the seemingly zillions of times I've mentioned the importance of application security. Not only are your applications the path of least resistance for the bad guys, we also suffer from a distinct lack of visibility in terms of what's actually happening within the application.

You are never finished with application securityLimited visibility is quite a problem, since a big part of my security philosophy revolves around REACT FASTER, which is basically understanding what's happening in your environment and knowing quickly when something is funky (like an attack or compromise). Well, it's hard to do that when we don't really have any instrumentation in the application to tell us.

So, for a change, we security folks are flying blind. Right, that doesn't end well.

The answer for application security is two-fold. There is a somewhat tactical path, which involves a penetration test to figure out what is obviously broken. This is the "fingers in the dam" approach because odds are there will be a number of problems that can't be fixed and every time you change the application, you introduce more issues. 

Another tactical measure is something like a web application firewall (WAF). Of course, the hyperbole of WAF vendor hyperbole would lead you to believe a WAF will block today's attacks and tomorrows and is really a strategic answer. Let's be clear - it's not. Not because a WAF isn't important, especially for common attacks like SQL*Injection, which can ruin your day. But there are always logic flaws in your applications and it seems the bad guys have a real knack for finding them.

So what's the strategic answer? You've got to build security into the application. FROM DAY ONE. That's right, as I referred to yesterday, this is mostly a process problem and a people issue. Technology is kind of besides the point. But how? I talk to very few folks that don't want to build secure software. They just don't know how, and they can't really quantify the impact of doing so.

But that is gradually changing. A few friends of mine (Brian Chess of Fortify, Gary McGraw and Sammy Migues of Cigital) have published a guide called the BSI-MM (Build Security In - Maturity Model) that's actually based upon (are you sitting?) the actual experiences of some large companies that have been doing this strategically for a while. Companies you may have heard of like Microsoft, Adobe, EMC and Google.

The concepts are presented within a "maturity model" for software security, which indicates the kinds of processes used to build code and make sure it's not a steaming pile of FAIL. There are twelve practices, each broken down into multiple steps. And this isn't going to happen overnight. In fact, the entire thing may not happen ever in its entirety. But the document gives you the perspective to understand how the process can work.

Like any other methodology, you have to figure out what parts are applicable for your organization, both technically and politically. Application security is a collaborative process and requires significant buy-in and sponsorship from an executive with enough mojo to push the agenda and enforce the impact of the process changes. Doing this right requires organization commitment, reorganization and incentives to encourage the right behavior. These are hard pills to swallow for many organizations, which is why software security is such a mess.

Personally, I have high hopes for this research. Most organizations remain skeptical and reticent about implementing a secure software process because they don't really understand the benefits, nor the long term impact of shipping secure code. By following these organizations over time and benchmarking their results, it can give evangelists and big thinkers some data to prove the value of building security in.

And we all know that the only thing that really shuts up a skeptic is data.

Have a great day.

Photo credits: “365/25” originally uploaded by teachingsagittarian 

Technorati: , , ,

The Pragmatic CSO

The Pragmatic CSO:
Available Now!

Read the Intro and Get
"5 Tips to be a Better CSO"

www.pragmaticcso.com



Submitted by Alan (not verified) on Wed, 2009-03-11 17:33.

It's a point I've been trying to get across for a long time. Automated analysis tools, WAFs, etc are all about symptoms. We need to get back to the beginning and look at requirements, architecture, teaching the developers how to do it better and so on. What seems to be difficult is convincing people who should know better that it's not about the tools.

The BSIMM looks interesting and useful. Now that we have to watch every penny, I think it contains many things that can be implemented without resorting to expensive tools.

Alan

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.