All around stellar event, everyone I talked to had a good time, and was able to take something of value home with them. ~150 people attended on behalf of many different organizations, large and small, from banking, telecom, ecommerce, software development, healthcare, etc. The format favored enterprise speakers rather than experts, which made it less about the newest attacks/threats and more about how enterprises went about solving problem X. This was great because I don’t think we have to push as hard anymore to promote general webappec awareness. In my opinion the early adopters are here and we should be supporting them in being mentors and evangelists. We need to continue facilitating knowledge exchange.
Judging from the feedback my keynote was well received (whew). I was a little nervous because the material was largely new and also because I touched on some, well, sensitive and deeply held beliefs about ways in which we approach web application security. I’ll post the slides and speech text as soon as I can. I also want to thank the SANS team, especially Carol Calhoun, for allowing myself and WASC to participate. The sponsors (Breach, Cenzic, Core, HP, WhiteHat) were very generous who paid for a lot of the food, drinks, and evening entertainment. Also thank you to the attendees who really made it all possible.
Before I forget them, there we a several interesting I noted down:
1) There was a lot of talk about how to effectively communicate with upper management on web application security issues. If the security guy manically informs the CIO, “OMG, we got 30 XSS and 10 SQLi issues!”, chances are they’re not going to know what you are talking about or understand well enough to make an informed business decision. However if you are able to put vulnerability reports into a meaningful business context you stand a better chance of influencing action in the right direction. For instance we have 5 high severity issues, that if exploited could lead to X dollars lost or X number of users impacted. I don’t think anyone REALLY had good answers here on specifics, but its clear something better is needed.
2) The verbiage some people used to ask for advice on how to get programmer to develop more secure code was a little concerning. They used terms such as “how do we strong arm them?”, “we need to beat them on the head”, and “can we force them in some way?”. Ed Pagget from First American keyed on this negativity right away. Basically he said nobody, including developers, likes to be manipulated, or otherwise forced to do something and this is exactly the wrong approach. I agreed as this approach could easily backfire. Security people must work to establish productive working relationships with the business and its developers or nothing will change. If we believe developers (people) generally want to do the right thing if only empowered to do so, then let’s do that in the best way possible.
3) Several people said of the white and black box scanner tools (AppScan, WebInspect, Hailstorm) that when they integrated them in development, they disabled all but the most accurate of rules. Apparently developers have a high tolerance for false negatives and low tolerance for false positives -- perhaps in contrast to security folks. I guess this makes sense when you have to get some form of reliable security testing in the SDLC that’s managed by developers. But I’m left wondering how much security has actually been gained as a result? How much harder does it make it for the bad guy to find the next vuln?
4) Several enterprises described their investment in security “champions” inside development groups as opposed to trying to tackle the entire group as a whole. For web security matters the developers can go to someone in the immediate vicinity to consult with and ask questions. This is actually quite clever as that person acts as a mentor for the rest. You are effectively training the trainer.
5) I thought I’d have to do more “selling” on the VA+WAF subject, but overall people seemed highly receptive to the notion. I even had a short discussion with Gary McGraw and figured I’d have to spar a bit at least with him. Instead he basically said it’s a security solution that has a specific time and place, just like everything else. Indeed. When exactly that is, is the question we’re all trying to figure out and get comfortable with. Still as Sharon Besser from Imperva picked up on, our time-to-fix metric are less than desirable. We can and need to do better.
6) Several people were asked for their thoughts on the Microsoft SDL and OWASP ESAPI. Consensus on the SDL, great for enterprise/desktop software, not so good for web application development. Agile development sprint cycles are too fast for security to be built in the way its described. ESAPI, good ideas and lots of potential, difficult to fork into existing projects. Also, to be effective alternative APIs must be ripped out to prevent developers from rolling back to less secure code their more used to working with.