Lifecycle Security - You missed GREAT talks

This was the first run for Lifecycle Security in Las Vegas, and attendance was honestly very poor. That's too bad, because we had some incredible talks (not tooting my horn, I mean the others ;).

Considering the traction and popularity that Defcon's seeing, it's a bad idea to have Lifecycle after BlackHat, and we communicated that feedback to the organizers. This conference is too important for people to miss it, so I'd be surprised to see it after BH next year.

So, I did the Application Security in the Real World talk here, and that and the other talks will be posted for download soon. I'll edit this post, and add the location when that happens.

HP Software Universe

Hey folks! I've been slacking big time, but we're going to get caught up today. Incoming blog spam!

As some know, I presented a couple of talks at HP Software Universe, at the incredible Palazzo Resort-Hotel-Casino. The conference was considered a huge success, even though attendance on the Application Security side of the house wasn't nearly as strong as we hoped for. Thankfully, this was noticed by the organizers, and they've promised much better coverage for the European Universe, assuming it happens.

A perfect end to a great conference - Stephen Marley headlined the HP party, after a great opening by Blake Lewis. We have the legendary Jerry Peña to thank for the awesome picture of Stephen (we're sworn to secrecy on the story leading to Jerry's legendary status, but maybe I'll let it slip if you buy me a beer ;), since none of mine are presentable.

Unfortunately, the video of the talks is only available to attendees, but everyone can see the slides. Links to both of my talks can be found below.

Video
Converted the links to Tiny because they're ridiculously long - Application Security in the Real World. And, the PCI University talk.

Slides
Application Security in the Real World and PCI University; You have questions, I have answers.

Enjoy!

Lifecycle Security

Greetings, readers. After a not-so-brief hiatus, I'm putting my blogging hat back on to tell you about a conference we've needed in the web application security community for a very long time.

Finally, we have a conference for webappsec, by webappsec professionals. Don't get me wrong, the OWASP and WASC projects are top notch, and I think their contributions to the community speak for themselves. That said, we needed a neutral conference that can bring together developers, users, and web security pros alike. Hopefully this will be the one.

My friend Dennis Hurst, a long time developer and webappsec pro, is one of the founders. The conference is being held directly after BlackHat, August 8-9, at Caesars, so you can just extend your stay if you've already booked a room for BH08.

Some great speakers have already signed on, and I'm sure it'll be a great show. Have a look at the Lifecycle Security website, and get registered for a couple days of pure webappsec.

PCI Compliance and Web applications: Another perspective

Ordinarily, I agree with Michael Cobb's advice and tips at searchsecurity.com. May 8, however, I read his PCI compliance and Web applications: Code review or firewalls? security tip, and disagree with him on a few different points. So much so, in fact, that I have to get it off my chest.

Let's begin with the assertion that "emerging threats" is the main reason to choose a Web Application Firewall (WAF) over some form of code review:

The main reason for an application firewall is that it will, if properly supported, actively protect against emerging threats, something a one-time code review will not.

Wrong. First, that's a BIG if. Second, everyone involved in securing, or breaking, web applications knows that virtually all emerging web application threats are simply new vectors of attack based upon the same old fundamental problems, 1) poor, or complete lack of input or boundary validation 2) poor, or complete lack of output encoding 3) application ids with too many privileges 4) terrible access control, and so on.

If you implement a secure development lifecycle, targeting the fundamentals of application security, not only do you shutdown today's threats, but emerging threats as well. Let's look at AJAX as an example. Attacks against AJAX are nothing new - they are the same, rehashed attacks we've seen for years, but appear amplified because more logic and functionality is pushed to the client. In other words, developers are making the same mistakes - the amplification comes from the fact that there's more opportunity to create those same mistakes.

A final note about the emerging threat position; WAFs are complex devices, and the organizations deploying them will do so in baby steps, and many will never implement the strictest control capabilities for fear of denying service to legitimate customers. Unfortunately, it's this complex functionality that would actually have the ability to stop a completely new attack vector. Hence, few organizations will benefit from some WAF's ability to stop true 0-day attacks.

Next, I'm curious to know where that pricing came from. If you didn't RTA, here's the relevant quote:

Pricing varies between brands but you could easily be looking at a purchase cost of around $5,000 for something that will handle around 900 MB of throughput, rising to around $8,000 for 2 gigabites per second (Gbps).

I conducted an RFP for my last employer in 2007, and have continued research on WAFs since then. The best I've been able to come up with recently are entry-level offerings from Breach, in the form of the ModSecurity appliance for $12,995, and Barracuda Networks' Web Site Firewall, which, at the low end, can handle a reported 1-5 servers, or 25mbps for $4999. Both vendors have high-end devices as well, starting around $24,995 for Breach WebDefend and $27,550 for Barracuda Networks' Web Application Controller (don't even bring up the $9,500 model - 100mbps is not high-end). Now, add in high-availability requirements, maintenance cost, and the cost to hire or train someone to manage them. Oh, and give me a break with the "let the current firewall guys do it." WAFs are not firewalls, and configuring a WAF and analyzing its output is nothing like managing a firewall.

Before moving on, I'll mention that Mr. Cobb does elude to the fact that WAFs require constant care and feeding, thank you. Imperva would have you believe otherwise, that after the initial period you can "set it and forget it" - yeah, right. Imperva's solution is really good, but nobody in their right mind is going to set and forget a device sitting in front of a web site doing millions in revenue per year.

Now, code reviews - Mr. Cobb mentions that enterprises should already be setting aside funding for reviews during the development process - something else I agree with. Especially, since security in the DLC is mandatory per PCI!!! From the PCI DSS v1.1:

Requirement 6: Develop and maintain secure systems and applications

Section 6.3 of the PCI DSS v1.1 takes it a step further:

Develop software applications based on industry best practices and incorporate information security throughout the software development life cycle.

So, what it boils down to is you must implement secure development best practices in the DLC, and in fact, a secure development lifecycle is a best practice. Furthermore, code reviews are a best practice when inserting security into the DLC. My talk at the upcoming HP Software Universe makes this point: By implementing a secure development lifecycle, thereby releasing secure web applications, you gain compliance implicitly, and in fact, operate within the true spirit of regulations and standards like the PCI DSS; that is, to create a safe and secure environment in which to conduct business.

There's been a lot of speculation, concern, and questions about how to comply with section 6.6. This might be best supported with yet another quote from Mr. Cobb's article:

Unfortunately, some earlier PCI guidelines gave the impression that internal code reviews would not be acceptable.

This is only true if that's how you interpreted it, and either didn't read or believe sources that cleared this up, such as Dennis Hurst's blog post of March 16, 2007. Of course now we have the Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified document mentioned in Mr. Cobb's article that not only vets what Dennis has been saying for over a year, but explicitly clarifies the options available to meet the requirement.

In conclusion, you must thoroughly research all of your options. We're not looking at a one size fits all situation here. Discuss section 6.6 compliance with your QSA, or another expert if you're not a L1 merchant, but keep in mind, there's more to section 6 than putting a band-aid on your insecure applications, ala a WAF. A WAF might prevent some of the attacks in the OWASP Top 10 from succeeding (What about access control, priv escalation, session handling, etc.?), but what if the WAF fails open, exposing your site, and its vulnerabilities, to the masses? A WAF can't lift a finger to help you develop secure applications, and an application behind one with SQLi and XSS defects is not a secure application. A WAF simply mitigates the threat and likelihood of an attack succeeding.

The PCI SSC has stated, as I do when asked, that ideally you should do both: deploy a WAF and do code reviews, either with web vulnerability scanners, or through source code analysis (manual or automated). In reality, however, this may not practical for small organizations, so there's going to be some risk analysis involved. Good luck! June 30 is close, and the clock is ticking...