Joe noted that, while there have been no published significant actions for PCI DSS non-compliance, merchants are taking compliance requirements more seriously.

What are the drivers for this newfound concern and effort for PCI DSS? Joe pointed out four drivers:

1) The visibility of the TJX incident and their remediation activities and requirements

Indeed, the TJX incident not only relates well to pointing out the need for credit card safeguards, but the various reports about the incident, such as the Canadan investigation report I blogged about earlier this week points out that any business handling credit card data must be serious about getting safeguards into place.

2) All the other ongoing breaches that continue to be reported almost daily

Yes, as more and more security incidents and privacy breaches occur, more organizations are finally realizing that, it's probably not a question of IF but WHEN they will also experience a breach. To help prevent that day from arriving, business leaders must get effective safeguards into place.

3) The fines and penalties that these companies are receiving from the FTC and other regulatory agencies, along with the awards given through civil suits

I agree, nothing gets the attention of CEOs and CFOs more than knowing the growing trend of regulatory agencies to apply 20-year consent orders, along with millions of dollars in associated fines.

4) The preponderance of state and local bills being introduced that are based upon PCI DSS

Yes, currently there are some federal bills along with many different state-level bills constructed around PCI DSS. Minnesota already has such a law in place.

We also had a good discussion about the need to supplement technology with procedures and operational activities. An example of this is for application security. It is good to implement application firewalls, but they cannot protect against mistakes within the code or the insider threat that could result in intential backdoors, and other damaging features, being built into the code.

To supplement the application firewalls, application code reviews need to be done. Not only code reviews prior to production, but also when building security into the application and systems development life cycle (SDLC) from the very beginning of the planning phase all the way through to application retirement.

We discussed the importance of organizations knowing, and protecting as much as possible, against the insider threat.

Joe made a great point that there is also a great threat from malicious insiders who understand forensics and have authorized access to be able to do bad things and then remove all traces of their misdeeds.

We also agreed that the risks from third parties, such as vendors providing support, contractors, and other types of business partner relationships, are large and significant concerns. Organizations that are striving for PCI DSS compliance must basically ensure that these business partners are also in compliance.

Joe indicated that in the past three months he has noticed those who must comply with PCI DSS are coming around to grasping the importance. His observations included:

* Organizations that must be in PCI DSS compliance originally thought that compliance was a point in time event. However, they are now realizing compliance is an ongoing initiative.

* Compliance requires establishing a comprehensive information security program based upon good security practices. It is not a check-box activity.

* Compliance is not just about technology; you cannot buy a technology product that will put you into compliance. You cannot buy compliance.

* Validating your compliance activities is important. You must provide evidence for your compliance, through maintaining documentation, logs and active monitoring.

* Periodic compliance checks need to be performed on an ongoing basis. The first compliance audit will be the most extensive and painful. However, after it is out of the way, the subsequent audits will become easier to get through and more useful for determining your ongoing compliance and effectiveness.

It will be interesting to see what kind of news headlines about PCI DSS will hit the Internet streets on Monday!

BTW, for those of you wondering what the PCI DSS "levels" are, here is a very high-level list to give some background on the different defined levels from the PCI Compliance Guide:

* Level 1: Compliance necessary by September 30, 2007

"Retail and eCommerce Merchants with greater than 6 million Visa and MasterCard transactions annually. Merchants that have suffered a hack or an attack that resulted in an account data compromise. Merchants that Visa and MasterCard determines should meet the Level 1 merchant requirements to minimize risk to the Visa system, or merchants identified by any other payment card brand as Level 1."

* Level 2: Compliance necessary by December 31, 2007

"E-Commerce merchants with 150,000 to 6 million Visa or MasterCard transactions annually. All merchants meeting the Level 2 criteria of a competing payment brand."

* Level 3: Compliance is basically determined by each acquirer.

"Visa-Merchants with annual e-commerce transactions greater than 20,000 but less than one million total transactions. MasterCard-Merchants with annual e-commerce transactions greater than 20,000 but less than one million total transactions, and all merchants meeting the Level 3 criteria of a competing payment brand."

* Level 4: Compliance plan had to have been documented and submitted to the acquirer by July 30, 2007

"Visa-Merchants processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants regardless of acceptance channel processing up to 1,000,000 Visa transactions per year. Completion of PCI DSS Self Assessment Questionnaire annually, and quarterly network security scan with an approved ASV. Acquirer submits summary of PCI compliance plan to Visa by July 30, 2007. If a breach has been reported, or found, Visa reserves the right to move the Level 4 merchant to a Level 1. If so, the Level 4 merchant must abide by the Level 1 validation requirements. MasterCard-Any other merchant not covered in Level 1, Level 2 and Level 3 compliance qualifications. "