Credit card security rules to get update

SAN FRANCISCO--Proposed new security rules for credit card-accepting businesses will put more scrutiny on software, but let them off the hook on encryption.

The update to the Payment Card Industry (PCI) Data Security Standard, due this summer, responds to evolving attacks as well as to challenges some businesses have with the encryption of consumer data, Tom Maxwell, director of e-Business and Emerging Technologies at MasterCard International, said here Monday.

The proposed update includes a requirement to, by mid-2008, scan payment software for vulnerabilities, Maxwell said in a presentation at a security conference hosted by vulnerability management specialist Qualys. Currently, merchants are required to validate only that there are no security holes in their network. "There is an increase in application-level attacks," Maxwell said.

While security stands to benefit from a broader vulnerability scan, another proposed change to the security rules may hurt security of consumer data, critics said. The new version of PCI will offer merchants more alternatives to encryption as a way to secure consumer data.

"Today, the requirement is to make all information unreadable wherever it is stored," Maxwell said. But this encryption requirement is causing so much trouble for merchants that credit card companies are having trouble dealing with requests for alternative measures, he said.

In response, changes to PCI will let companies replace encryption with other types of security technology, such as additional firewalls and access controls, Maxwell said. "There will be more-acceptable compensating and mitigating controls," he said.

While PCI is good in principal, relaxing encryption requirements is not, said Paul Simmonds, a representative of the Jericho Forum, a group of companies that promotes open security technologies. "It basically means that if you hack the system, you get the data," he said. "I can't think of a good alternative for encryption."

The challenge with encryption is that older payment systems were not built to support the scrambling technology, said Qualys CEO Philippe Courtot. "Encryption is the ultimate measure of security, but the current applications have not been designed with encryption in mind," Courtot said

The PCI security standard was developed by MasterCard and Visa and went into effect last year. It aims to reduce the risk of an attack by mandating the proper use of firewalls, message encryption, computer access controls and antivirus software. It also requires frequent security audits and network monitoring, and forbids the use of default passwords. Retailers that don't comply may face penalties, including fines.

[marileev]

protection... priceless

The PCI security standard may be a start, but financial instituions, including credit card companies not only have encryption this piece fo compliance to deal with, but also other cybercrime trends like laptop theft.
http://www.iwantmyess.com/?p=58

[vikramsareen]

Encryption is half baked solution - What abt TRUST

Security is need and it is always the after thought for any applicaiton or system work flow.

But I would like bring out the incomplete statement that is made in by the CEO - "Encryption is the ultimate measure of security, but the current applications have not been designed with encryption in mind"

Encryption addresses to only part of the problem. It only makes the data Confidential but does not adress to complete relief from the PAIN -

1. Privacy - Encryption
2. Authentication - ?
3. Integrity - ?
4. Non repudiation - ?

Soluton where digital signatures is used can bring in the element of trust to addresss to non repudiation and integrity.

For authentication - there are many ways of doing it. physical >> h/w token or software >> user password chanllenge.

It is incomplete to say "Encryption is the ultimate measure of security".

Vikram Sareen

[DryHeatDave]

Just for the record

The use of public/private keys DOES address non-repudiation.

[Jackson Cracker]

good in PRINCIPLE

not "good in PRINCIPAL"

[bbroeman30]

Don't remove encryption...

I write e-commerce software, and you can't remove encryption... Additional firewalls are good, as is more physical security, but you should still encrypt your data. It's fast, it's really easy, and it provides a lot of security...

I keep only minimal info in the session / cookie, have a lot of code in place to prevent session hijaks or session fixation, and I use 256 bit AES for names, addresses, credit card numbers, dates, etc. and only the absolutely necessary permissions for the different users for the databse... security isn't that hard...

[QDSP]

Active PCI Discussion Group - pciFile.ORG

FYI - A good place for merchants/IT folks to pose their questions regarding Payment Card Industry Data Security Standard is pciFile.ORG.

This site primarly services Visa-certified PCI auditors (QDSPs)but welcomes posts from service providers/merchants.

The moderator is the guy who wrote and delivers the certification class for Visa. His co-moderator is the guy that does the PCI class at SANS Institute.

There has already been a bunch of discussions about the new version of PCI-DSS (aka Version 1.1)

www.pcifile.ORG

[marileev]

great link thx

Thanks for the http://www.pcifile.ORG link.

[Wenlock]

The truth in PCI

I work with MasterCard and the major Banks to help merchants comply with the PCI Data Security Standard. I think some of the comments may have been mis understood and were not clearly conveyed.

"relaxing encryption requirements" is not what is meant in the statement by Tom Maxwell of MasterCard when he said ""There will be more-acceptable compensating and mitigating controls" SecurityMetrics constantly provides fortune 500 companies with compliance suggestions, alternative solutions or mitigating controls. I am on the front lines and I see no relaxation on the standards, I see the card associations applying the standards in the best places to prevent compromise while enabling merchants to increase their revenue.

[Dr. PCI]

No one's "off the hook"

This article appears to take some liberties with Mr. Maxwell's statements and clearly takes some out of context in an attempt to capitalize on the public?s fear of their personal data being stolen. As an example the following is written in the introductory paragraph: "...but let them off the hook on encryption." It should be noted that the card associations have not changed the requirement for encryption. All companies are still required to encrypt at least the Primary Account Number (PAN). The reality is, however, that sometimes conditions exist which preclude the implementation of encryption.

As the founder of a PCI QDSC, I can attest to the fact that it is a reality of the payments industry that not all companies can encrypt cardholder data. As an example, many issuing processors still use mainframe systems to process and store cardholder data. In these instances it is very difficult, and sometimes nearly impossible to implement encryption. Compensating controls are often necessary in these instances. The card associations are simply formalizing the requirements around the use of such controls to ensure that the protections that are used provide sufficient preventative measures.

By formalizing the definition of compensating controls, the card brands have actually made their use more difficult. They have stated that companies must have demonstrated technical or business constraints that prevent the use of encryption before compensating controls can be considered. There was no formal mention of compensating controls in former releases of the standard, though every assessor knows that they were a reality of the industry.

"The new version of PCI will offer merchants more alternatives to encryption as a way to secure consumer data." Again, this is not accurate. Previously assessors could recommend controls based upon their own experience and expertise. With the formalization of compensating controls companies will be forced to demonstrate that they cannot implement encryption technologies. In addition, very specific controls are identified as mitigating controls. Again, encryption is still required except in extenuating circumstances.

I am always amused when 'security experts' espouse their opinions without taking into consideration the challenges of the payments industry. In his response to the concept of compensating controls used for encryption Mr. Jericho stated: "It basically means that if you hack the system, you get the data...I can't think of a good alternative for encryption." I think most would agree with this statement. However,to reiterate, in some instances encryption of data may simply not be possible for all companies.

While the article states that the PCI was put into effect last year, this does not tell the entire story. Visa USA released the Cardholder Information Security Program (CISP) in 2000. Much of the current PCI was taken from the original CISP program. Visa USA has had a requirement for encryption since at least 2001. Again, it has been a fact of life that in some instances, compensating controls were required as some companies could not implement encryption.

[D.J. Vogel]

PCI DSS is about managing risk

To add to the discussion about PCI's movement, I think we should commend the Card Associations for self-regulating as a private industry. The Payment Card Industry Data Security Standard (PCI DSS) was a program developed to manage RISK, not solely SECURITY.

Encryption is always a sensitive topic for professionals passionate about security and business owners seeing price tags for enterprise-grade encryption solutions. Although technology is advancing and encryption solutions are more easily accessible, some organizations are unable to make either a business justification or technological changes to their legacy systems to be able to implement encryption. We, as security professionals, help business owners and decision makers understand WHY encryption is important and how to justify it.

The Card Associations are very responsive to the market. Security companies, such as 403 Labs and other Qualified Vendors/Assessors, work with the Card Associations to help give guidance on new attack patterns, technological advancements, and overall security trends.

Because PCI DSS is a Compliance Program to manage RISK, the highest risks will be addressed first (a calculation based on threat, fraud, and some statistical analyses to which we may not all be privy). As the Program continues to mature, additional SECURITY measures will be required when it becomes more feasible for the mass market to implement them.

As others have alluded to in their responses, encryption is also not the ONLY security measure that an organization should have in place. Security needs to come in the form of a Security Program -- encompassing technology (such as encryption), plus policies, procedures, and education to form a LAYERED model. After all... encryption will only be as secure as its key is protected.

For those of you who are able to encrypt and who continue to strive to be on the leading edge of securing your infrastructure, I commend you. For others, if you're reading this, it means you're already heading in the right direction -- just don't lose focus of your business and the goal.

[hadaso]

Merchants should not and need not store customer info at all!!!

Merchants should not and need not store customer info at all! They certainly should not store info that is sufficient to charge a customer's account!

What they should store is info derived from a combination of the credit card number, customer details needed to complete a transaction and details of the specific deal like the amount of money charged. This should be hashed in a way that the specific deal can be completed, but so that info needed to use the same credit card number to make another charge in a different time to a different merchant is not possible. That would boost the safety of online transactions thousands times more than any kind of "scan for vulnerability".

The real vulnerability is the outdated system that allows whoever has the info that the customer needs to hand over to charge the account to do the same (charge the account). This system should be upgraded to a system where the info handed over from the customer to the merchant is only good for making one specific charge of a specific amount at a specific time to a particular merchant.

[D.J. Vogel]

Sometimes there is a business reason for (some) data to be stored

This is a very admirable goal, to not store the cardholder data/PAN, for any merchant. Already certain data are NOT permissible to be stored after the authorization for merchants:

* Full magnetic stripe contents (aka, Track Data)
* 3 or 4 digit security code (CVV2/CVC2/CID)
* PIN Verification Value (PVV)

PCI DSS manages risk to help protect data and prevent fraud. These items present the most significant risk of fraud when stored. Fraud is much less likely to occur when only a PAN (i.e., credit card number) is compromised.

PCI DSS even agrees that any cardholder data should NOT be retained unless needed. In the current version (v1.0), Requirement 3 states:

"Keep cardholder information storage to a minimum... Limit your storage amount and retention time to that which is required for business, legal, and/or regulatory purposes..."

PCI DSS addresses both online and brick-and-mortar merchants (plus mail and telephone procurement). There will be situations where some merchants will need to store information (sometimes just temporarily). Here are a few examples:

* Subscriptions (where there is a regular reoccurring charge, such as monthly)
* Store and forward/batch processing
* Unshipped items for inventory that is not in stock
* Repeatable purchases

Unique transactions are great in theory; however, the infrastructure to support them is not present in a mass scale. Several service providers (think of gateways) are making strides to help their merchants achieve this goal by using a placeholder for the credit card number or allowing the merchants to store the cardholder data on the service providers systems to allow for repeat charges.

Again, the goal of the new release is not to say Merchants do not have to encrypt information. By definition, compensating controls:

* Need to be "above and beyond" the current requirements
* Meet the "intent and rigor" of the original requirement

This is NOT an effort to relax the standard, but to respond to a business need in the market place while still limiting risk to data.

[Dr-Security]

Credit card security rules to get DOWNGRADE

With identity theft and credit card fraud at an all-time high, it's truly puzzling to see any countermeasure or testing requirements being relaxed.

MasterCard also recently announced that some of the Internet scan requirements have been reduced. Now, only two of ten OWASP application vulnerabilities need to be checked for.

Data encryption and data obfuscation are not that hard. There are creative ways to solve most any challenge in this area. And they don't have to break the bank.

What you are seeing here is MasterCard and Visa giving in to the demands of their paying members. The Credit Card companies themselves are decreasing their own business risk while increasing the risk to consumers.

[D.J. Vogel]

Credit card security rules adapt to reduce even more risk

PCI DSS is composed of multiple components and testing procedures to manage risk and protect data (in the effort to reduce fraud). The Internet scan requirements are only a component of the PCI DSS requirements. It's important to recognize that OWASP (or similar) secure coding guidelines ARE REQUIRED (also listed as 5.1 in the Payment Application Best Practices):

"6.5 Develop web software and applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities..."

Testing procedures STILL INCLUDE penetration testing and/or application code reviews.

Positively, as commented, there are creative ways to solve MOST ANY [encryption] challenge, but unfortunately not ALL challenges, which is why we see program improvements -- these are efforts to address more situations and further reduce risk.

MasterCard and Visa (et al) don't "give in" to accept more risk, instead what we are seeing is a private program that's maturing and adapting to the market place. The Card Associations recognize that it would NOT be good for anyone to just reduce one factor/risk (such as business risk) if another factor increased (such as consumer risk). Consumer confidence in the system is what makes the system successful.

A larger adoption of the program results in less risk overall. Everyone's goal is the same here -- to manage and mitigate risk and fraud. No one in the payment process benefits from fraud.

[J.D. Oder II]

My 2 cents - Is this an editorial?

Some of statements made previously have indicated that merchants should not store data at all past the initial request. Well the simple fact is that depending on the type of merchant in question, data storage is a requirement. This is the case with the hospitality, auto rental (car hire), some mail-order, and some food service industries. There are data storage requirements, but the question really remains is it the best choice to store sensitive cardholder data at the merchant location? Many believe it is not.

In regards to the encryption question, encryption only works to a point. A question one should ask is who stores the encryption keys? Even in the most advanced PKI solutions appropriate key management is paramount. Just adding encryption does not solve issues.

To further illustrate this fact; if a POS company manages the keys, and they have an internal breach, go out of business, etc. and the keys are compromised, then all merchants using that POS system could become subject to loss. On the other hand do many (if not most) merchants have the know-how and the internal security controls and policies in place in order to manage such keys appropriately? Based on experience I would say the lion share do not. How encryption pans out in the card acceptance world, only time will tell.

There are alternatives to encryption however, that exist out in the world of financial transaction processing that already address these issues. Companies like Shift4 Corporation http://www.shift4.com/security.htm have implemented, and others are currently implementing solutions so that merchants do not have to worry about the storage of sensitive data.

It is solutions such as these that Mr. Maxwell is speaking. To simply make a blanket statement that alternative solutions to encryption will harm security and lessen PCI DSS?s prowess as a standard is, in my opinion, (and with all due respect to Joris Evers) somewhat irresponsible.

Each solution will be required to go through the same rigorous audit procedures by qualified assessors, and as I understand it, no blanket stamp of approval will be granted. They mitigating and compensating controls will simply be one cog in a larger security mechanism. Only part of the PCI DSS deals with transport and data storage. There are others that are just as important to the overall security of sensitive cardholder data.

The numbers have been tabulated and PCI DSS has made a difference. It is the industry?s goal that it will continue to do so. If the industry comes up with alternative solutions and they make things better, and more streamlined, then that is better for consumer confidence, and if consumer confidence is better we all win.

As a final thought, critics need to be identified as to what ?Oxen they are trying to gore.? If they are for instance selling PKI solutions and the newer mitigation solutions may interfere with marketing efforts, then that needs to be addressed in one?s articles. Report all the news and let the CNET readership make the decision for themselves. After all, they are a pretty savvy group. If not, the report should have the heading ?Editorial?