This week is the premier conference for those that store, process, or transmit cardholder data (affectionately referred to as CHD, by me). Everyone from VISA / AMEX / DISCOVER / MasterCard to the POS devices themselves are here. The industry is a very tight group, and it has been an amazing experience to realize how much these companies work together to meet customer (consumer) demands / needs.
I have had the privilege to speak with dozens of companies and sit through several discussions on the payment industry and the PCI DSS requirements. This entry contains my notes and takeaways from the first day. These take aways include:
- PCI DSS program Updates (new version, changes!)
- Threats, Trends, and Analysis
- Safe harbor for Small Merchants
- PCICo
- Top Reasons for Compromises
- Top Actions to mitigate compromises
ETA, the Electronic Transaction Association, is the conference to learn about how the payment industry is growing, the latest technologies, and recent security efforts. The conference has an exhibitor hall of nearly a hundred companies that provide everything from the POS hardware to the biggest card companies in the world. This international event includes breakout sessions where the experts and leaders of their field can discuss how to handle real world situations. After attending some of the breakout sessions and hearing from over 30 product companies, I have compiled a breakdown of the best tidbits, morsels, and other bits of goodness. As more details come forward I will be sure to post them.
First off, some figures provided by the credit company themselves.
- VISA presented some figures on how many companies are meeting the PCI DSS validation / compliance requirements. At the time of the convention, around 74% of merchants have submitted or their ROC (report on compliance) is under review. This is roughly 232 organizations.
- In addition, approximately 1,592 merchants have submitted their SAQ (self assessment questionnaire) and their PCI DSS external scan results
PCI DSS Updates:
- PCI DSS will be updated from version 1.0 to version 1.1 in the summer of this year – “PCI DSS version 1.1 will provide changes in form, not substance” – VISA representative
- PCI DSS version 1.1 will contain greater specificity in the controls that should be in place
- Updates are occurring with feedback from a sampling of Acquirers, Issuers, QDSCs, and Service Providers
- An additional Merchant level will be included to provide a more absolute line. o Companies processing greater than 1 million cards will be required to have a SAQ and PCI DSS external scan
- June 30th 2008 requirement – WEB APP firewalls o PCI DSS will include a requirement for WEB APP firewalls to be in place by 2008. This will address many of the application layer threats and cause a simpler compliance effort for companies that meet PCI DSS mandates
- Top 2 major initiatives: o Continue message of “Not storing TRACK data” o Increase acceptance and adoption of PABP initiatives
Threats, Trends, and Analysis:
- TRACK data is commonly discovered in logs o This is from forensic data and it was determined that the companies were unaware of this activity by the application
- SQL attacks were a part of every credit card breach recorded in the past few years (not the root cause, but part of the attack)
- 84% of POS PC systems were the source of compromises o Attacks generally came from remote sites using test equipment
- Attacks came over several channels: o 30% over dial-up o 47% over Cable / DSL
- 60% of errors and violations were a direct result of 3rd parties
- 99% of Brick and Mortars that suffered a compromise were storing TRACK data
- 25% of compromises are due to laptop theft or paper receipt theft
Safe harbor for Small Merchants:
- Small merchants can and should meet PCI DSS requirements
- Small merchants represent largest source of compromises
- Reason: small companies cannot afford ($$) the cost of a breach
- Safe harbor: o Demonstrate validation – SAQ & Scans o Maintain validation – good documentation
PCICo:
- Similar to SETCo
- To be formed organization that will manage the PCI Documents
- Accredit QDSC organizations
- Eventually handle other duties
Top Reasons for Compromises:
- No Firewall
- Backdoor or Trojans
- Remote Access configuration errors
- Remote system exploits
- SQL Injection
- Non-compliant hosting provider
Top Actions to mitigate compromises:
- Install a stateful firewall ($1,000 for a model that can be managed remotely)
- AV and / or personal firewall
- Disable remote management on internet facing devices o & block incoming ports on your NEW firewall
- Patch, patch, patch
- This one is harder, but: o Practice good web site developments practices o Practice good DB development o Test, Test, Test o Web app firewall
- Require provider demonstrate PCI DSS compliance o They can and probably need to be certified o They may have already done it for one client (perhaps there is a plan that includes PCI DSS certification for a couple of bucks) o Request a SAS 70 type II with Control objective details (verify that the control objectives and procedures align completely with PCI DSS)
A lot of the details above were heard during presentations, anecdotal conversations, and through public literature available. A special thanks goes to all of the panelists for providing great information and especially to the card processors for their transparency in the success of the PCI DSS program. There is a tremendous amount of work that must happen in the credit processing industry in order to properly secure the data and maintain customer trust. I believe that from the efforts of these groups these necessary changes are still important. One disconcerting fact is that many of the ISOs, product companies, and general service providers do not know what PCI DSS is or what the requirements are. This is very troubling as we have reached nearly the year and a half mark.
Training, education, and continued efforts by everyone involved are necessary to truly insure that PCI DSS 100% compliance will be possible. Tomorrow is the final day and I hope to provide even more detailed information. I will put together some final thoughts on the red eye back from Vegas, and look forward to any feedback.
Any other attendees or anyone with questions on the conference, please add a comment below and I will try and address them directly.
James DeLuccia
The change can be interpreted in two ways. First, MasterCard received a large amount of complaints that the requirement was burdensome on the auditor and auditee. Second, MasterCard feels that the other 8 requirements are best practices and not objective enough to be part of an audit.My thoughts are that this reduction in audit requirements is not consistent with the industry’s commitment to preventing security breaches. Web application vulnerabilities constitute a tremendous amount of the serious threats to organizations, and without some form of prevention (regular quarterly audits / web assessments, or web application / intelligent firewalls / IPS) the company and the industry’s image are at risk, not to mention the client’s data.
