12 Steps To Application Security

There are several holdouts in the industry who wish to trump the term "Application Security" with the term "Software Security." My Christmas wish is that we standardize on the term "Application Security" - because I think it's a more realistic term to describe the state of the industry that helps organizations design, develop, deploy, assess, maintain, retire and build procedures around Applications in a way that protects them from external and internal threats.

1) We must admit that we have a problem and that the security posture of our enterprise Applications are becoming unmanageable.

Let me start by saying that most code is insecure. This is not necessarily getting better, but seems to be getting worse.

Those of us who are professional programmers were never taught to write secure code in school. Even Michael Howard, who is hiring the best and brightest out of the worlds top universities, clearly says that these star graduates have no idea now to write a secure application.

2) We must believe that a power greater than ourselves (Application Security Service Vendors) can help us restore sanity.

It would be effective to re-write all of the worlds applications in an environment that embraces best-of-breed Application Security methodologies. But the truth is that most CIO's have several thousand applications under their responsibility, that are largely insecure. It's already built. It's already in production. We low level programmers are tasked with writing more code, faster and faster, to keep the business moving, since they depend on our work more every day. We simply do not have the luxury of time or budget to rewrite all of those applications. So we are stuck with a state of having to secure applications after the fact. This is a reality check to those in the industry who conjecture that "Software Security" is a better term because "Application Security" implies protection of software after it is built.

3) We must make a decision to turn our will and our lives over to Application Security excellence.

I also feel that the term "Software Security" is a dangerous position that both polarizes the industry and blames the coder. Software Security implies Lines Of Code. Although at the end of the day, individual lines of code need to be written using best practices (input validation, output encoding, proper access control, etc,etc,etc) it's only a small part of the entire picture. Individual coders cannot solve the problem alone.

4) We must make a fearless inventory of the security posture of our current applications.

We cannot just run Fortify, Spi, Cenzic and Watchfire and be secure. We cannot prove that an application is secure by any predicate mathematical proof. So what do we do? We (at times) slap up a WAF to stop the bleeding. We bring in pen testers, conduct code reviews and run tools for the most critical apps.

5) We must admit to a higher power (our CIO), to ourselves and to other coders the exact nature of our wrongs.

We wage political warfare in our organizations to ensure that the "C" level, the project managers, the infrastructure teams, the architects and the low-level programmers are all on the same page about Application Security. Not to mention incident response. Legal issues. Risk analysis - which really has nothing to do with software - but measures a financial impact on a business.

6) We must be entirely ready to be re-trained to remove all these defects of how we develop applications.

We re-train software engineers as quickly as possible. We start growing a dedicated internal AppSec team to conduct these reviews in-house in a more cost effective way.

7) We must humbly ask our Vendor to help us remove our shortcomings.

There are so many activities around securing an application that does not involve lines of code - and does NOT involve software - that is seems myopic to me to use the term "Software Security".

8) We must make a list of all applications that are insecure, and become willing to make amends to them all.

No tool will answer the question of the state of our Application Security posture. It takes a village - and often several villages - to even achieve measurement of our current posture! Most CIO's have "no clue" where they are today in terms of Application Security exellence.

9) We make direct amends to our insecure Applications wherever possible by fixing the underlying code, except when it would harm the organization by spending to much to do so.

It is not cost effective to spend 100$ to re-code an application that protects 10$ worth of data. We need outside help to do proper risk analysis - and that measurement needs to be a combination of not just engineering but also non-technical business expertise which has little to do with Software.

10) We continue to take inventory of the security posture of our applications and when we are wrong we promptly admit and fix it.

Depending on a vendor alone will not set you free. The best of breed vendors encourage building AppSec teams internally - the best Vendors help accelerate your organization to achieving Application Security Independence. Continuing education is a great deal cheaper than re-education. Internal penTest expertise is a great deal cheaper than bringing in a service vendor. Using the right tools effectively is a great deal more cost effective than the shotgun approach of using whatever tool was sold to your CIO. The right Vendor will help you get there fast without disrupting the organization.

11) Through continued education and studying of industry best practices, we try to embrace that philosophy in all of our day to day engineering activities.

Once we have the knowledge, we must start building all applications with security in mind and practice from the first few days of each applications conceptual birth.

12) Having had an awakening as a result of these steps, we carry this message to other engineers, and practice these principles in all our affairs as we build new applications.

Software implies the programs that run a computer.

Application implies a solution to a problem - in the enterprise we are talking about delivering data securely.

And I think those of us who use the term "Application Security" do so because it is not the software that we are trying to fix - it's the solution to a business need that we are trying to make more robust.