Our first failure was in identifying the problem. Early warning professionals considered web application vulnerabilities similar to those of other applications, and that they could be identified with vulnerability scanning tools and then remediated with a patch (albeit a custom patch). They were at least partially correct in theory; the problem was in the practice. This failure led to the development of web application vulnerability scanning products as the basis of the web application security industry.

We finally realized that the root cause of the problem was related to application development. More specifically, the security of an application is in the hands of its developers. And what was our solution to this problem? Inject security people into the development process. We trained developers how to break their applications. We tested pre-alpha code that will be significantly changed another dozen times. And some people did threat modeling, which I still have not found to produce useful results.

Security comes down to control. For application security, this means who is in control of the functionality and data available within the application. This is why it is necessary that current and future application developers and computer security professionals learn the foundation of how to build secure applications from the start. To promote this effort, we are offering a discounted AppTrust Developer Training course at Virginia Tech this summer to ensure that the next generation doesn’t fall into the trap of doing it wrong and starts off doing it right.

To learn more visit the event site.

The AppTrust Assessment, Training, and Certification solutions break this mold with a strategy that enables your organization to implement applications that are secure as soon as they enter production.

You can read more about FYRM Associates’ new AppTrust offering at our Web site, http://apptrust.fyrmassociates.com, or contact FYRM Associates at http://scr.im/fyrmsales or (877) 752-7170 for more information.

We’re seeking volunteers to help out with development. We’d like to take this from a small research project to a community driven effort to expand the possibilities of what can be done with XSS.

Here are my thoughts: Have you ever worked directly for/with the government? Not a rhetorical question or being a smart a$$, but seriously. It’s a given that the US Federal government doesn’t spend enough money or resources on cybersecurity [see previous blogs]. I cannot imagine how difficult it would be to attempt to coordinate these “volunteer tests” with the Federal Agency, the government security teams that protect the site, the network and system folks responsible for the site, and then all the contractors involved in monitoring and supporting the site… that’s just a fraction of the folks on the government site. We’ve done contract work with the Federal Government and doing a simple scan of a small environment from a single source address took a tremendous amount of coordination and planning. It would be insanity to try to coordinate dozens of volunteers. And that is just one of a couple pre-planning obstacles I can see.

What about from a slightly tangent ethics view; is it volunteers or freebies? The Federal Government from what I’ve experienced has pushed procurement and purchasing folks through different types of ethics training to prevent inappropriate kickbacks to individuals and organizations. Could a big corporate entity like “Big Yellow” for example be allowed to volunteer a team of young staffers to “pen-test”? Wouldn’t it then be ironic if that same company down the line got a chance to bid on projects or even technologies to be implemented? You got to expect someone out there to try to take advantage of it.

The one point that Jack made mention that I’m not going to rehash too much but agree with is regarding incident response. Could you imagine being the contractor or GS-10 sitting in the SOC during “volunteer pen-test day”? If the government doesn’t have the tools to assess their own web sites, I wonder if they would have the technologies or resources in place to review the logs generated to figure out what is considered “normal” vs. “bad” traffic.

I’m not entirely sure if Jeremiah really thinks it’s a good idea or is throwing it out there for media fodder (I see SC Magazine already picked it up). It does bring up some interesting early debate but the more I think about it, it just doesn’t seem reasonable.

However one thought I did come up with and please pardon me if there is already an organization like this, is taking a page from the National Guard. It would still require some money, background checks, a tremendous amount of coordination and volunteering. How about a “Cybersecurity National Guard” unit, where people can volunteer X hours a month and have one of the core responsibilities testing government and military web sites. I’m deeply familiar with the military and intelligence community programs and teams that do this, but this “volunteer” group could be staffed with vulnerability researchers who have extra time or want to do something more valuable for ISC^2 CPEs ;)

We’ve decided on Sourceforge and you can download the code from the XAB project page located at:

• http://sourceforge.net/projects/xab

We’ve submitted talks to Black Hat and Defcon for the updates we’re working on, so hopefully we’ll have the chance to catch everyone up…solicit some more feedback…and grab a brew. Or two…

http://www.blackhat.com/html/bh-dc-09/bh-dc-09-speakers.html#Flick

For those of you in the Tampa area, I will be presenting the same tool at the OWASP Tampa meeting on February 18. You can check out the Tampa Chapter’s page here,

https://www.owasp.org/index.php/Tampa

I hope to see you at either or both presentations and SafeSurfing…

I’m going to start off this post with the moral of the story: Good intentions often have bad, unintended consequences. The following is the ‘Testing Procedures’ text of requirement 6.6 from the new PCI DSS v1.2 (source: https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html):

For public-facing web applications, ensure that either one of the following methods are in place as follows:

• Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows:

– At least annually
– After any changes
– By an organization that specializes in application security
– That all vulnerabilities are corrected
– That the application is re-evaluated after the corrections

• Verify that a web-application firewall is in place in front of public-facing web applications to detect and prevent web-based attacks.

Note that for ease of reading I’m going to shorten “PCI DSS v1.2 Requirement 6.6” to just “PCI 6.6” since nearly everyone already refers to it as such.

Without further clarification, this requirement now compels an organization that stores, processes, or transmits cardholder data (“CHD”) to apply PCI 6.6 to all of their “web applications” that are publicly accessible, regardless of whether the applications participate in the storage, processing, or transmission of CHD. We must assume also that this requirement will be applicable regardless of other security controls as well, such as network segmentation. Disregarding all other changes to the PCI DSS, this one requirement could significantly increase the level of effort and cost of PCI assessments.

Before I get into advice for dealing with the new requirement, let’s examine the two options in relation to the change. First option is to have an application security organization perform security testing on the applications, correct identified vulnerabilities, re-test and repeat if necessary. Furthermore, such testing must occur “at least annually”, which should not be a huge problem…and “after any changes”, which could very easily force an organization to simply stop making any changes to its web applications. Unintended consequences.

The second option seems rather simple, straightforward, and innocuous unless you have actual experience with web application firewalls (“WAFs”). At a high level, WAFs have two basic modes of defense: 1. Blacklisting attack strings, typically pushed down by the vendor like anti-virus signature updates, and 2. Custom rule checking, which requires training the WAF to understand more of the application it is protecting. Both modes can often lead to false positives; the second and more effective mode requires a lot of human interaction throughout the system’s lifecycle. Add to the mix the large price tag for commercial WAFs and the new requirement that requires protection for all public facing web applications, and what you likely end up with is an organization implementing an easily defeated blacklist of your standard attack strings (XSS, SQL injection, etc). Unintended consequences

I do not want to be accused of PCI hate speech. In fact, I would like to sincerely applaud their efforts in helping to drive application security education and strongly encouraging organizations to address the problems. My concern, though, is that the more stringent the requirements become, the more likely organizations will continue (or begin) to do only the bare minimum in order to “check the box” instead of fixing the root cause of the problem. This is similar to the problem of progressively raising taxes: the higher the tax rate climbs, the more people will invest to identify loopholes, legal or otherwise. Or, in Star Wars terms, “The more you tighten your grip, Tarkin, the more star systems will slip through your fingers.” –Princess Leia

With this information in mind, we now come to the issue of how to approach PCI 6.6. I’m going to suggest the most pragmatic approach that should work for most or all organizations, or at least those organizations that must endure PCI DSS assessments. In step-by-step format, naturally:

1. Classify applications – Separate all public facing web applications into a grid by user type (e.g. internal users only, external users only, mixed) and data sensitivity (e.g. CHD, public, internal/corporate, internal/sensitive).
2. Shorten list – If possible, move all web applications with internal users only to the internal network and provide external access via VPN. This should be an obvious move and something that should have been done well before PCI 6.6, but you might be surprised how often I see this situation.
3. Create assessment plan – First determine the budget for performing automated runtime vulnerability scans (the “cheap” option) against all remaining public facing web applications. Then the remaining budget—if any—can be reserved to add more effective assessment tasks to the most relevant applications, obviously starting with those that store, process, or transmit CHD.

As a general rule, I suggest using the results of a vulnerability scan/assessment against one application to identify and remediate potential weaknesses in other applications that either use the same codebase or were developed in similar fashion. This approach should lessen the number of findings in subsequent tests.

If all the advice in this post seemed familiar or common sense, then congratulations…you’ve been paying attention! The security industry has been evangelizing a risk-based approach for a long time now. Or at least some of us in the industry have been.