doBoard

do… Web Application Development and Security

Archive for June, 2008

How to Make Application Security Suck Less

Wednesday, June 4th, 2008

Application security sucks because it’s a wicked hard problem to mix the goals of security and application development within real-life projects.

If application development is about making an app do what it’s supposed to do, then application security is about making sure an app doesn’t do what it’s not supposed to do, despite real world conditions which may be hostile and chaotic.

“Hard core” security has become a massively complex black art with its own priesthood. As a result, the security community has generated an enormous volume of arcane information about security vulnerabilities and countermeasures.

Many conference presentations, books and articles about application security have tried to boil that down for the developer community, with excellent coverage of the top several types of security flaws. But security has a long tail, so that approach leaves vast territory uncovered.

That approach also doesn’t necessarily give developers the context and perspective necessary to judge the costs and benefits of security, and to make sound decisions about what really does or doesn’t need to be done. So I decided to address application security in a different way.

I gave a talk on this topic yesterday at the 2008 DC PHP Conference in Washington, DC. I’m posting a copy of the presentation slides and speaker notes for all of you here.

The goal of this talk is to help you wrap your brain around core concepts of application security, and thereby to make it easier to deal with correctly.

The talk begins with “What is Security, Really?”, poking fun at misconceptions and presenting the idea that security is keeping bad events to a minimum despite even skillful attempts to cause them.

Then it covers fundamental concepts and practices including: how to identify what needs protection; vulnerabilities and countermeasures with PHP examples; and how to avoid security excess by considering risk in a consistent way.

By the end, you should have a conceptual framework for application security that will at the same time simplify the problem space and provide more rigorous results.

So it’ll suck less.