Simple Software Security: are there any real solutions for small teams?

I’m heading down to the SANS AppSec 2011 conference in San Francisco March 7 and 8. I’ll be on a panel discussing the disconnect between software developers and the security community, and what steps we can take to bridge the gaps. It should be an interesting discussion; I’m looking forward to sharing ideas with people who care about how we can all build better, more secure software.

I’m also looking forward to talking to smart people about the problems that small teams face in writing secure software. I want to know more about tools, ideas, practices that can be scaled down and used effectively by small, fast-moving development teams.

I’m concerned that too much of software security and Appsec is focused on the enterprise, the big firms with the resources and a mandate for security; and that there aren’t enough practical, affordable, simple solutions for small teams – where most of us work today, building and maintaining a lot of the world’s software. I want to know more about what’s out there that small teams can understand and use and rely on.

Are WAFs the answer?

Web Application Firewalls sound like the kind of solution that a small team needs. Don’t worry about fixing or changing security problems in the application: put in an appliance or another piece of software, set it up and let it block security attacks. But, of course, it’s not that simple. You need to find a good WAF solution, configure it, setup the correct set of rules and exceptions and then test these rules and exceptions thoroughly to make sure that the system still works with the firewall running; and continuously update the firewall rules as you update your software and as new problems are found. For some teams, especially teams that are not building out-of-the-box simple web apps, and Agile teams that are following Continuous Delivery with frequent deployments to production, or Continuous Deployment updating production several times a day, that’s a lot of work.

And WAFs add to operational cost and complexity, and there is a performance cost as well. And like a lot of the other appsec “solutions” available today, WAFs only protect you from some problems and leave others open.

Is ESAPI the answer?

OWASP’s ESAPI project promises a secure, enterprise API to handle the security functions for a web application. It’s Open Source, free under BSD license, it has an active community behind it to help with questions and make sure that it works and to keep it moving ahead, and it looks like good technology – exactly the kind of solution that small teams could use. It has code to take care of most of the ugly security problems, like data validation (straightforward in concept, but the devil is in the details) and encryption and secure session management.

But there’s a catch here too. ESAPI is good work, it is one of OWASP’s flagship projects, but it is still a work in progress. A bunch of smart and committed volunteers are working away on releasing 2.0 for Java; but it’s not ready for the wide world yet. Although there are some nice slides about ESAPI and some overviews available, the programmer-level documentation is incomplete and out of date. If you have a security specialist on staff who has the understanding, time and drive to work through the code, and who understands the problems well enough to know what to look for, you can get it to work. And big companies can pay for help from the consultants who wrote it to get it to work. Small application development teams don’t have the time or money to hire consultants to help make sure they understand the code and how to use it; and most of them don’t have the time or expertise to figure it out on their own.

For small teams to understand and trust ESAPI, it needs to come with clear and up to date documentation; simple and unequivocal guidelines and patterns on how to use it properly because you have to get it right the first time; and tools to help test to make sure that you used it properly. For people to want to use ESAPI, it needs simpler and cleaner packaging (something that the ESAPI team is planning) and tutorials with code samples for the common scenarios so that programmers can copy-and-paste to get started.

So ESAPI might be the answer someday, but not yet.

What else is there?

Other Appsec solutions are in the “first, you need to know how to write secure code, and then we can help you to check to see if you got it mostly right” space.

You start by getting the team training in software security awareness and secure development and security testing from The SANS Institute. Get the developers to use secure coding checklists
and cheat sheets from OWASP to write secure code and to help guide code reviews. Then you can use tools and guidance from Microsoft’s SDL to try to build your own threat models and keep them up to date.

Then you can check your code with static source code analysis tools. But most static analysis tools for security are expensive to license, take time to get setup and tuned, and you need your best people to make time to understand what the tool is trying to say and to work through the dups and false positives. And these tools are not enough on their own – they only find some of the problems.

Dynamic analysis, web application vulnerability scanners… same story.

Fuzzing? To fuzz online apps, you need to write smart protocol-aware fuzzers, which takes time and smarts. And you have to make time to setup and run the tests, and it’s a pain in the ass to work through the results and find real problems. It’s a good way to find fundamental weaknesses in data validation, but not a lot of small teams have the understanding or patience for this approach.

And if you do all this you still don’t know how secure you are (although you may know how secure you aren’t). So you need to pay for consulting help: get an expert code review, a threat model or secure architecture review, and you better schedule some pen testing too.

This is too much… and it’s not enough

It has to be simpler. It’s too hard to write secure software, too easy for even smart programmers to make bad mistakes – it’s like having a picnic in a minefield. The tools that we have today cost too much and find too little. Building secure software is expensive, inefficient, and there is no way to know when you have done enough.

There aren’t any easy answers, simple solutions. But I’m still going to look for them.