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
I was part of a panel on the divide between software development and security, together with exploratory software testing guru 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.
2 comments:
I enjoyed your talk at the Summit. Nice blog and couldn't agree more with your conclusion.
Thanks,
Khash Kiani
XXE, XPATHi, LDAPi, and HHI/HRS are just as common/deadly as XSS or SQLi. It is increasingly rare to see CMDi or RFI/LFI, but as these decrease, file upload implementations (and subsequent vulnerabilities) appear to increase. Another category on the increase is ModelView injection because of the growth of MVC frameworks.
The largest problem with SQLi is that there is so much misinformation out there about how to defensively code around them. You'll see developers using LINQ, Hibernate/iBATIS, and stored procedures in ways that makes them insecure -- claiming the whole time that the ORM or use of stored procedures (or WAF) "makes them secure". Let me be clear that the adversaries are still ahead of our best-of-breed anti-SQLi solutions: many script kiddie tools for finding SQLi now include a check-box to "bypass ModSecurity".
The largest problem with XSS is that people are not implementing the correct defensive solutions even though they are well-known and available. XSS should be easy to be rid of... easy to monitor for... easy to test for... and it is -- I just don't see the right solutions making strides. I imagine this is more out of laziness than awareness in today's landscape. You can't, as a developer, write user-controllable data into the HTTP streams (which usually causes HHI/HRS and therefore also XSS) and you can't protect against XSS with data validation alone. I'm pretty sure we all know this at this point, right? So go find a solution that works because there's a lot of them.
I think we're going to see a lot more automated, random attacks on login forms (not just brute-force) -- which will turn into heavily targeted, asymmetrical attacks such as Anonymous vs. HBGary. All commercial and open-source web application security scanners/tools that find SQLi in an app also tend to miss the SQLi in the login form. The context of the login form usually isn't provided to the scanner (it's removed because it drops credentials). I would say that a majority of manual pen-testing and code review activities also miss vulnerabilities in these critical areas.
Additionally, what I worry about most is that application vulnerabilities will continue to monetize crime -- and potentially become itself a core money-making economy for criminals. Even if we solve all of the problems I describe in this blog post, it is likely that we will still face this issue.
Post a Comment