Earlier this week I attended the SANS Appsec Summit in San Francisco. I’ve taken SANS training before, and so have other people at my firm, but this was my first time at a SANS conference. It was well-organized and the quality of the speakers was high, especially for a smaller event like this.
There was a good mix of perspectives on software security problems: real-life examples of secure SDLCs and managing app sec programs; vulnerabilities and tools and methods; the problems and challenges that companies are facing putting in web app security; the very scary state of mobile app security. And there were a couple of cool and fun (if not immediately practical) presentations from smart guys at Google: one on their ballsy bug bounty programs, and another by Billy Rios on how botnets work, and what kind of application security programs botnets have. (I'm not sure what I can do with what I learned on this one, but it was definitely cool).
Around 2/3 of the crowd were app sec or other IT security people, the rest were developers or managers who wanted to learn more about how to build secure applications, based on a show-of-hands poll that I took on the first day.
I presented on How to Build Bridges between Development and App Sec
James Bach and Marisa Fagan who was representing the Rugged Software movement. James was entertaining and provocative as expected. He made the case that we will never be able to build secure software if we want to innovate. Marisa presented an update on what’s been happening with Rugged since it was announced at this same conference a year ago. While I appreciate the good intentions, I still don’t understand what difference Rugged is making, or will make soon.
Hilights and key take-aways for me:
You can’t get secure if you can’t convince software developers to take the bad guys seriously, and to take problems found in test and review seriously. “Developer looking at bug: that’s not a realistic case, nobody would actually do that”. This goes back to the Attacker’s Advantage: all it takes is one mistake, one soft spot that can be exploited for the bad guy to get in. “A lot of threat modeling is all about convincing developers that threats are real”. Even many testers don’t have an adversarial mindset. Find real problems and show that they are real and exploitable, especially in training.
Developers hate silly checklists and policies. Don’t expect a secure development program heavy on checklists and policies to succeed.
Logging, logging, logging. Good logging is an important line of defence for online systems. Logging inbound and outbound information with enough context to figure out what the hell is going on; logging all exceptions; making it easy for ops to monitor logs and to see what is important.
Big apps keep getting bigger, with lots of frameworks, external components, open source stuff. It’s not just your code you have to worry about. Big apps keep getting bigger and less secure. Small mobile apps are even scarier: there is no such thing as an expert on mobile app security today, because there is no such thing as mobile app security.
Robert Fly at Salesforce.com had a more upbeat story. Salesforce has found ways to make its appexchange program secure for its customers and partners. By limiting what partners can do in the system and how they do it through the salesforce development and run-time platform; by building a set of app sec tools and resources for its development community; by opening office hours to help developers inside and outside of the company with security issues; by enforcing regular code scans and reviews of every partner application. They’ve put a lot of work into their program, it seems to be paying off.
Last year everyone’s major vulnerabilities were XSS and SQL injection. This year the major vulnerabilities are XSS and SQL Injection. And next year, the major vulnerabilities will be… We don’t seem to be learning or getting better. Even with auto-escaping libraries and many of the world’s smartest programmers working there, Google is still getting caught on XSS vulnerabilities by bug bounty hunters.
Anonymous has shown that application-level DDOS attacks are real, and real hard to defend against.
The closing panel was on the future of software security tools. Tools are getting better, but not better enough, soon enough. IBM is working on much faster, incremental static analysis tools to provide quicker feedback to programmers so that they will use them more often; and end-to-end analysis that will look at code in the context of the bigger system to find real problems. Brian Chess at HP is working on integrating the results of dynamic run-time testing tools with static source code analysis tools to provide a more complete and accurate picture of vulnerabilities in the code. Ivan Ristic and Jim Manico talked about still-emerging secure, open source frameworks and template libraries and application sandboxes – technology that isn’t ready today, but that in 2-5 years will make it easier for developers to start building software secure by default.
So, there were no easy answers, at least not yet, but there are a lot of smart people taking these problems seriously, let's hope that better answers will come.