PCI DSS standard 1.2 went into effect this month. As mentioned before, the changes are mostly cosmetic. However, with the new standards come more reasons for businesses to pay attention. The Tech Herald briefly talked with Mark Bower from Voltage about these changes and his company’s client base.
Mark Bower of Voltage talks about the new version of PCI DSS.(IMG:J.Anderson)
“The PCI regulations haven’t changed in terms of compliance adherence – any organization that processes and/or stores credit card data still must comply with the PCI DSS 1.2 standard – that hasn’t changed,” explains Bower.
“The new updates simply clarify areas that were previously a little ambiguous. For example, PCI DSS 1.2 refers specifically to the use of strong cryptography when encrypting PAN data, which would of course include AES Format-Preserving Encryption (FPE).”
FPE or Format Preserving Encryption is one of the offerings from Voltage. It’s a way to encrypt things like credit card numbers in a database without altering the database schema.
The Tech Herald asked Mark if the new version of PCI DSS, being mostly cosmetic in respect to the changes, allows companies a chance to relax on becoming compliant.
“The only area I see where the standard has relaxed is in the patching (within Requirement 6), but I interpret this as a clarification. In some legacy systems, patching the databases may have been compromised by using basic encryption tools or third party solutions that were invasive and required alterations to databases – for example, proprietary stored procedures and triggers,” he said.
“These types of solutions only operate with specific versions of databases and patch levels, thus applying a critical database patch – e.g. to prevent a new SQL injection attack or to remove a critical vulnerability — would have broken these older encryption systems, resulting in system downtime. Thus the 1.2 standard has relaxed the requirement to have an immediate patching requirement. This is however contrary to best practices (Gartner and other research firms) in managing database security.”
Yet, some companies are sweating bullets over the new changes. Why are some companies nervous about the changes?
“Many companies have started out using a method referred to as “compensating controls” for PCI compliance. This was often done to achieve compliance quickly, but at a great increase in ongoing compliance costs as the compensating controls required dedicated people and new processes and procedures that are often manually audited,” Mark said.
“Also, compensating controls reduce risk somewhat, but they don’t address the data privacy problem and can be circumvented. For example, instead of encrypting the database in a legacy system, they have human processes to approve access to card data. Meanwhile, the DBA can still read credit card numbers. Now, some of these compensating controls that were previously possible are increasingly difficult to use as the model for PCI compliance.”
So where is the shift? What are his clients using? Are they relaxing during the PCI standards changes?
“Now, I see a shift from compensating controls as the “quick fix at high cost” to using encryption technologies like Voltage SecureData, which can eliminate the high costs of compensating controls and allow encryption to be used in places that were previously impossible,” Mark explains.
“For example, we have clients who are encrypting legacy DEC Alpha systems with Oracle 8 data warehouses, old AIX platforms with Oracle and DB2 databases where the card data was also an index column and thus DB2 encryption could not be used. Format Preserving Encryption (FPE) and Voltage SecureData’s transparent key management and rollover policies make it really simple.”
Mark told The Tech Herald in his interview that he is confident his customers using Voltage SecureData are relaxing, using their savings on other things instead of compliance. “After all, encryption should be easy. Prior to the development of FPE, it was a long and expensive haul; hence the compensating control approach.”
Another topic in the interview was PCI section 6.6, which will change the way some businesses operate online. What does Mark think of the changes in this section?
“Requirement 6.6 is now mandatory. All public-facing Web applications are subject to either (a) reviews of applications via manual or automated vulnerability assessment tools or methods, or (b) installing an application-layer firewall in front of public-facing Web applications. This is important,” he told us.
“Now, if a company has used a “home brew” approach to securing data in the Web application, or used a complex toolkit, the PCI audit scope has now increased drastically – and, correspondingly the cost of compliance. We’ve actually addressed this head on. With the Voltage SecureData SOA model, the audit scope will be 1-2 lines of code in one or two places in the entire application – if that. That’s much simpler than typical legacy code which is often ten thousands of lines of code throughout the whole application suite since there will be areas in PCI scope like key management. This is a huge benefit for Voltage SecureData users versus in-house or traditional toolkit-based approaches.”
So what is your company using for PCI compliance? How have the changes affected your business model, if at all? Chime in below and leave a comment.
For all the details about changes in PCI DSS 1.2, check out a well thought out explanation here.
Add your comment (no registration required)
page: 1
AndrewBoldmanJun 5th, 2009 - 00:43:16
Hi, good post. I have been woondering about this issue,so thanks for posting. I’ll definitely be coming back to your site.
Report this comment
Advertising
AndrewBoldmanJun 5th, 2009 - 00:43:16
Hi, good post. I have been woondering about this issue,so thanks for posting. I’ll definitely be coming back to your site.
Report this comment