AppSec Blog

AppSec Blog

AppSec at RSA 2012 Conference

I attended the RSA conference last week in San Francisco for the first time, and enjoyed the city. Excellent restaurants like Slanted Door, Canteen, Barbacco and especially Commonwealth, the Wharf, Chinatown, the almost perfect weather.

I was surprised at the scale of the conference, the impressive number of IT security professionals who came from everywhere, and the even more impressive number of technology vendors represented. The exhibition floor was overwhelming: huge booths with their own bars and free drinks, lovely booth bunnies in racing suits and blue wigs, race cars, a robot, a real sumo wrestler, lots of games and contests, even a "beat the freak" - a chance to put on gloves and beat on a salesman. Most of the technology was targeted to the enterprise of course, SIEM systems and enterprise ID management systems, and highly scalable next generation and next next generation firewalls, and lots of endpoint security solutions. And vulnerability scanning technology of every kind.

I spent most of the week following the AppSec track, with a few interesting side trips. Monday was a full-day AppSec 101 seminar put on by different specialists, mostly vendors. The session on Secure Design was the same dull motherhood from Saltzer and Schroeder: defence in depth, least privilege, minimize the attack surface, compartmentalization, blah blah - it's no wonder that so few people pay attention to this, there's nothing clear or actionable except for maybe the simplest and most important principle: Don't Trust Data from Clients.

But there were a few cool takeways. I learned about FIRST.Org the Forum of Incident Response and Security Teams and their vulnerability scoring model for rating the risk of IT security vulnerabilities, which is useful. The session on security testing did a good job of covering dynamic and static analysis, fuzzing and manual testing, a pleasantly lucid explanation of how static analysis works, and when to use tools vs manual testing. One key point that kep coming up is that it's not finding the vulnerabilities that is the hard work. It's fixing them - deciding what to fix, making the case to fix them, dealing with the "blast radius" problem (many security fixes require changing different parts of the code) and making sure not to break the rest of the system.

Tuesday. I skipped the keynotes on Tuesday and most of the keynotes on other days - with a couple of exceptions the keynotes were a waste of an impressive venue and the audience's time — execs from security vendors playing with samurai swords and other silliness.

Jacob West from Fortify's session on emerging security problems on mobile platforms was quite interesting. A lot of the presentation focused on Android. Android's permissioning model is unclear enough that programmers can make simple mistakes that can easily be exploited, and its message-passing scheme (intents) is open to hijacking and other kinds of attacks. And of course there's SQL injection again, this time against local database storage on Android. Sigh.

A high-powered panel on Agile Software Security was a disappointment, turning into more of a bitch session about irresponsible development practices, which as I've said before isn't specific or intrinsic to Agile development. The arguments again are that there's not enough time to do scans and reviews in short sprints. This is patently wrong, I know it, because we do it - if a team is disciplined, they can fit the work into sprints incrementally as part of delivering a working system.

Because one of the panelists was from a WAF vendor the other panelists said cautiously positive things about WAFs especially as a solution for large legacy apps that are too expensive and risky to change or fix. But in other sessions, WAFs were not taken seriously as a real answer to security problems.

Wednesday's opening panel on implementing AppSec programs with senior managers from Adobe, Microsoft and JP Morgan Chase was excellent - real life advice from people who have actually done the work to put in successful software security programs. Especially cool that l I got to meet Jim Routh who is now heading up the software security program at JP Morgan Chase, and whose earlier work at DTCC helped me get our own software security program started 5 plus years ago.

Brad Arkin at Adobe, a frequent presenter at the conference, gave some good advice on preparing for and exploiting a crisis, including always having an unlimited budget scenario, because someday you might be asked for what you would do if money isn't a constraint and you had better not waste this chance.

A tragically under-attended session on software security programs at midsize companies which lacked star power but the panelists all knew their stuff and provided good advice on how to accomplish a lot with limited budgets and resources. All of them leverage outsourced on demand services such as White Hat and Veracode rather than trying to do everything in-house.

Met Frank Kim from SANS for a beer. Came up with ideas to save the world. Drank more beer. Forgot what we talked about.

Thursday. An early morning Peer-to-Peer session on Software Security on A Budget, hosted by John Dickson from Denim Group. It was fun to share experiences with other managers on what we were doing, what was worth doing, what maybe wasn't worth doing but we're still doing it anyways. Everybody is doing some kind of application scanning (dynamic or static), although nobody believes that it is enough to ensure that the software is secure. Some of the things that were making a difference were training and frameworks. Developer training is important, but you get the most value in training the people (strong developers and testers) who really care about good software and who have the chops to take care of the technical problems. Invest in making sure that libraries and platform code are secure and that developers use it.

F-Secure's CTO on Cyber Terrorism. No real evidence of cyber terrorism yet, but social communities and blogs provide terrorists with a beautiful way to build their stories and recruit. The Internet can be a scary place.

Dan Cornell at Denim Group on vulnerability remediation costs. An interesting analysis based on a still small set of data from some remediation projects. No real surprises. Problems that are harder to find (like through manual pen testing) are often harder to fix than problems that are found by scanners, many of which are trivial. Others like SQL injection while still straightforward, take longer because you have to change the code carefully (to use prepared statements properly). The time to fix a security bug is only a small part of the total amount of work - most of the time goes to testing that the fix was done properly regression testing and rollout. I hope that they continue to build on this dataset, it would be helpful to learn what kinds of fixes are riskier to make, which ones cause the most regressions.

Friday started off with one of the most interesting sessions of the conference for me, a presentation "This is Getting Ridiculous" by Jeremiah Grossman about the insecure state of web apps. The scale of the challenge that we are facing in software security, especially web application security, is enormous. We need 10x or more people that deeply understand appsec to help fix the problems that we have today on the web. And of course we keep building more systems with new technology like HTML 5 and Node.js that we don't understand well enough yet, so we won't even know what the security problems will be for a couple of more years at least, meaning that we will have a whole lot more problems to deal with. He recommends that more companies (and government agencies) consider following Google and Facebook's bug bounty programs and try to hack themselves secure. If white hat hackers were motivated and allowed to hack any site, think about what they could find.

Scott Morrison talked about how moving to more open, simpler APIs, especially RESTful service APIs for mobile apps, creates a new class of security problems. APIs tend to be finer grained which means the attack surface is much bigger, and because they are finer-grained and closer to-the-metal they are self-documenting to attackers, easier to exploit. Like any interface, the key is to get the basics right and to scrub all input and output or you will get hosed.

The final presentation of the week for me was by Ivan Ristic on SSL and Browsers: the Pillars of Broken Security. SSL is the single most important basic security protocol on the web and it is not being used correctly, or not at all. Very few sites use SSL because it used to be expensive and they still think it is. More than 2/3 of the sites that do use it don't always use it consistently and properly, they mix HTTP and HTTPS traffic and don't protect private data and session information. Even if they do use it properly, most don't have it configured correctly. SSL Labs gives only 9 of the top web sites an A on using and configuring SSL correctly (that number seems insanely low, but that's what I wrote down...). The problem is only getting worse because if you spin up a popular web server stack today on Amazon EC2 for example, most of the stacks are not configured correctly by default. Qualsys has just released a free SSL best practices guide that explains how to configure and use SSL correctly. Hopefully thousands of people will download it and follow it and at least get this basic stuff done right. But that's probably wishful thinking.

The conference reinforced what I already knew. There are a lot of problems out there to be solved. App Security like so much else in information technology is mostly about getting the fundamentals right. Don't trust data from outside. Use SSL and use it properly. Find security bugs AND fix them. Build secure code and use it.

1 Comments

Posted March 09, 2012 at 8:10 AM | Permalink | Reply

Desperate Olive

Jim, thanks for this excellent summary as well as for the interesting links includint to the very actionable SSL guide.
Quick comment on Agile

Post a Comment






Captcha

* Indicates a required field.