There are only a handful of days left for companies to become compliant with section 6.6 of the PCI DSS and there are even more scare-tactics being tossed into the marketplace. Compliance should not be feared, as we all know the penalty is what can be the most costly (see TJX). So what can you do to step up your compliance? Here are a few tips from around the web.

Security Ninja offers up these four tips:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

On Tray Ford’s blog, there is mention of a supplement that was released to help clarify 6.6. It is used as a tool to help understand the requirement, although “in no way replaces or supersedes Requirement 6.6 in the Data Security Standard.”

Finally, I took to YouTube to find some helpful information about PCI and I stumbled upon the videos below.

Eleven days remain for companies to make sure their web-facing applications and websites are PCI Compliant according to section 6.6. Authoring the PCI Compliance blog series I often look up interesting websites for insights and quotes, although for this part in the series I can pretty much look inward at our own solutions.

The general thought is that by June 30, most of the companies who need it will fail to comply with section 6.6. The sad reality is the quick fix mentality will lead to many of the compliance issues, as application firewalls only place a Band-Aid on the gaping wound that is poor code development. So will your website be compliant? [The Tech Herald]

E-xact recently launched Web Secure Pay, which is a fully compliant way of having your website visitors complete transactions without ever leaving card data behind. Customers and clients stay within the confines of your website then when it comes time for transaction is processing they are passed through our secure systems and brought back to your online environment seamlessly.

We’ve also produced step-by-step screencasts featuring everything from implementation to the code that drives our intuitive transaction processing manager.

Section 6.6 is about looking at the code AND the application itself. It’s no secret that our application runs smoothly with Ruby on Rails, which allows for a slick interface while remaining secure with its tight and compliant code. You can view more detailed screencasts involving implementation and processes on our Viddler profile and click here to find out more about WSP.

The PCI DSS section 6.6 compliance deadline is merely 12 days away, here are some more thoughts about this regulation.

Over on the ModSecurity Blog they closely examine this portion of 6.6:

“6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.”

As you can see, the goal of this section is to show that not only were vulnerabilities identified but that they were also fixed. So whether or not the vulnerabilities were identified by source code review or a scanner does not seem to be the main issue from PCI but rather was the vulnerability actually fixed??? It is the process of actually remediating the vulnerabilities that is taking entirely too long for organizations, if it happens at all. I mean, how many times does an Authorized Scanning Vendor (ASV) find the exact same vulns showing up in scan after scan? They are quickly showing the customer what/where the problems are but they just can’t fix them for a variety of reasons. [Read more... ModSecurity Blog]

VeraCode looks specifically at the semantics of the requirement:

Requirement 6.6 of the PCI-DSS becomes mandatory in June 2008 and requires all web-facing applications to either undergo a code review OR be protected by a web application firewall. There were questions on what “web-facing” means, and the Council admitted that it needed rewording. This could be interpreted as any application using HTTP as a transport mechanism, or it could mean only those applications that were Internet-facing. It sounded as if they meant the latter, but they did not say so outright which was confusing. Web services applications would also be within scope. [Read more... VeraCode]

On Search Security they drill home the high complexity of 6.6:

Section 6.6 is the most difficult and controversial part of the PCI DSS. It calls for either a review of all Web application code developed in-house, or the installation of an application layer firewall to protect all Web applications from known attacks. This puts most companies in a difficult position. [Read more... SearchSecurity]

And with a helpful twist, SearchQualitySoftware offers this advice:

…the simplest, least-expensive, and most reasonable way to satisfy PCI DSS Requirement 6.6 application code reviews is to perform automated scanning and manual testing of the application. Do them from the perspectives of both an untrusted outsider and a trusted user. [SearchQualitySoftware]

Section 6.6 is indeed unique as it brings to light the very real challenges that every connected company must face regarding web security. You can read more about section 6.6 on the PCI DSS website and in this supplement PDF.

PCI deadlines for compliance seem to be catching up with merchants all the time. Standards adapt, upgrade and tighten for greater security imposing compliance on businesses. The latest compliance deadline is June 30, 2008 and the PCI blog world is buzzing about what this all actually means (there’s even a countdown clock that you can put on your website).

PCI Blog - Compliance Demystified: “What does it mean? In order to understand this you have to take my Attack Vector based Risk Management (AVRM) approach towards the intent behind this requirement. One could easily reference that the intent behind this requirement is to prevent Internet-facing web-application compromises and you would be correct, but also missing the deeper meaning and back story.

Although card-present (typically IPOS) systems account for a greater number of credit cards stolen, about half of all account compromises are a result of web-application data breaches. Of this population, about 90%+ of the data compromises are a result of the top 5-10 web-application vulnerabilities. These include, but are not limited to, SQL injection, cross-site scripting, cross-site request forgery (CSRF) and other input/output validation issues. Knowing this you can now imagine that if we could mitigate the risk of these top attacks we could reduce the population of credit card data breaches by almost half!

This standard is focused on web-applications that process transactions, which is basically right up our alley. Finding the proper (and secure) web-application for your merchant needs can be difficult and you’ll certainly want to find one that meets PCI DSS 6.6 by the end of this month.

We are pleased that E-xact has been fully PCI compliant over the last several years and remains as such.

You can find more information on the official PCI DSS website and feel free to contact us to discover ways that E-xact can alleviate your security risks when using our payment management solutions.

E-xact’s experience at RailsConf this past weekend was truly positive, involving some excellent networking opportunities, answering questions, and learning from Rails greats during sessions and keynotes.

Our very own Emil Marceta gave a presentation on Sunday, which is now available online:

| View | Upload your own

If you are having troubles viewing the slideshow, please visit the Slideshare website.

Three days, one company speaker, four team members and 500 kms later, E-xact’s journey to RailsConf 2008 in Portland Oregon was a great success.

One of E-xact’s developers, Matthew Carriere, particularly enjoyed EngineYard’s presentation, “Reading about how you could be doing things is theory, having Ezra and the EngineYard crew tell you how you SHOULD be doing things was doctrine.” Matthew also noted, “Another highlight was the keynote by Joel Spolsky who gave an engaging talk about design and culture.”

Our theme of “Payments on Rails” featured our Realtime Payment Manager application and its journey over the years from .NET technology to its path onto Rails.

Our payment processing and transaction management has been going full steam ahead since its launch last year and we feel we truly prove Rails for enterprise. Being able to share this story with all those at RailsConf was a real treat and we enjoyed the questions and comments from all those who visited our booth.