The Aegenis Group is dedicated to helping companies navigate the choppy waters of data security, information risk, and privacy regulation. The Aegenis Group believes that the ability to understand not just the regulatory mandates themselves, but their total impact on the business environment can act as a compelling tool for business enablement. From understanding the ways in which your products and services can protect sensitive data to making the right compliance decisions for your business environment, The Aegenis Group can assist your company in facing the risks associated with an increasingly complex landscape of the business world.

Bookmark to:
          

Session Track: Business Trends & Impact
Scheduled Date: 2/7/2007
Scheduled Time: 9:10 AM - 10:20 AM
Session Title: Why Securing Payments Data Should be Your Top Security Priority

Other panelists will include:

• Chris Noell - President - TruComply
• Mark Rasch - SVP and Chief Security Counsel - Solutionary
• Hans Van Tilburg - Director, PCI Compliance - Visa International

Bookmark to:
          

Over the years the landscape of information security has changed from the need to implement perimeter protection to the concept of defense-in-depth and edge-security. Both of the latter concepts are a result of the changing landscape of fraud. In an effort to prevent fraud and reduce risk across the board, different industries have implemented their own set of compliance requirements.

On the surface the PCI DSS looks very detailed, especially when compared with other standards such as HIPAA, GLBA, and SOX. Underneath the clearly outlined requirements and audit procedures is a lengthy list of compensating controls, third-party systems, outsourcing, small data caveats, and that doesn’t even break the surface of the individual requirements and their intent. As PCI begins to gain critical mass and more companies begin to comply there is a need for clarity of vision and understanding for each part of the standard.

This article begins to demystify the Payment Card Industry Data Security Standard; explains the industry, its players, and how they relate; and explain the long list of nuances and differences in these definitions. Through detailed explanation the reader should have a much stronger understanding of the history, current landscape, risks, and best ways to mitigate those risks for your company or the companies you work with. This paper will not make you an expert on the payment card industry but it will give you a great start in beginning to understand the compliance process.

Bookmark to:
          

One interview addresses Dahn as a PCI expert and reports on the increating rate of compliance for merchants.

“For large organizations, they are facing a really complex system,” he says. Many aren’t aware, for example, of the standard’s allowance for so-called compensating controls, which permit merchants to satisfy certain rules using less costly measures. One merchant, for example, met a requirement for file-integrity monitoring, which could have triggered huge software costs, by using “an open-source product that did not require them to incur a per-license fee,” making it cheaper to install on the company’s multiple servers, Dahn says.

One interview covered large point-of-sale (POS) merchants that are seen as a large risk to the payment card industry. They are not being addressed with the change in Visa USA’s merchant levels.

With Visa USA this week introducing a revision of the volume bands by which it groups merchants for PCI compliance, the card association’s data-security rules now encompass all or most large brick-and-mortar retailers, forcing them to meet more stringent PCI validation requirements, including at the least self-assessments to certify compliance, says Michael Dahn, president of Volubis Inc., a San Francisco company that has contracted with Visa to help train PCI assessors and educate merchants on the standard. The change took effect July 18.

Bookmark to:
          

Research shows that today more than ever information security budgets are allotted towards compliance. The variety of compliance requirements is a collection of alphabet soup and yet the number of security breaches continues to grow. In 2005, there were more publicized data security breaches than any year prior, and companies still struggle to understand the industry requirements. Everyone is looking to their neighbor to interpret and understand what they need to do to comply without focusing on how to stay secure. This presentation provides an overview of national and global information security compliance requirements and demystifies those specific to the Payment Card Industry (PCI) Data Security Standard (DSS). It will explain in clear terms what the intent is of each requirement and how to understand things such as intent of controls, scoping & sampling, and compensating controls.

Bookmark to:
          

Within the PCI DSS encryption is required for the following items:

• Wireless (Requirements 2.1.1, 4.1.1)
• Non-console administrative access (Requirement 2.3)
• Data at rest (Requirement 3)
• Data in transit (Requirement 4.1)
• E-mail (Requirement 4.2)
• Passwords in transit or stored (Requirement 8.4)

This post outlines the requirements for each requirement but does not focus on compensating controls or implementation strategies.

Wireless: Companies have two options for securing their wireless networks. They can either implement WPA with proper authentication and encryption (think RADIUS authentication, individual certificates, and WPA2) or they can use WEP with another form of encryption (i.e. IPSec, VPN, or encrypted SSL). WEP is insecure and should not be trusted as a protection mechanisms. Tools such as wepcrack exist that can determine a WEP encryption key in under an hour.

Non-Console Access: This means the elimination of TELNET, FTP, R-services, and any other protocol used for administrative access. Most companies struggle replacing TELNET with SSH, but they should also look to places where VNC is used for administrative access and FTP is used for batch administration. Any plain text protocol needs to be replaced or encapsulated with an encrypted alternative.

Data at Rest: This is the biggest requirement for data encryption throughout the PCI DSS. This mandates three things:

1. Industry accepted encryption algorithm with proper key length (i.e. AES at 128-bit)
2. Encryption key management
3. Encryption key rotation

For some organizations a hardware security module (HSM) or tamper resistant security module (TRSM) are used to perform all the key management and rotation steps. Other companies will opt to implement these requirements in their own software and they will need to work with a qualified assessor to determine if they are meeting each of the three key requirements.

Requirement 3 lists two alternatives to cardholder data encryption being Truncation and Hashing. If you choose either of these alternatives you do not need to encrypt the data, although some companies find it helpful to store both the encrypted and hashed or truncated account numbers within the same data store. (If you go the way of hashing it’s good security sense to ’salt’ your hash values.)

Data in Transmission: Contrary to the wording cardholder data does not need to be encrypted when transmitted over private networks — only when traversing public networks. So what is considered a public network? The Internet, DMZ, and Wireless networks. Companies need to verify the cardholder data traversing public networks is encrypted (i.e. Encrypted SSL for Internet traffic, IPSec for DMZ connections, and WPA2 for wireless networks.)

If data is transmitted over a private network (i.e. Frame-relay, private T1, MPLS, VPN, etc.) the cardholder data does not need to be encrypted.

E-Mail: Cardholder data should never be sent un-encrypted via e-mail. If the e-mail traverses a public network (as described above) it would need to be encrypted as per PCI DSS Requirement 4.1, which causes many companies to think they do not need to encrypt internal e-mails that contain credit card numbers. The problem is that e-mail is static most of the time, either in personal mail folders on workstations or on the e-mail server itself. If these locations contain un-encrypted credit card numbers they are considered data stores and must themselves be encrypted as per PCI DSS Requirement 3.

What is the solution? Deploy e-mail encryption software to all employees who will need to send and receive card card data, which will prevent un-encrypted data stores from being created.

Encrypt Passwords: This requirement applies to all network, system, and application passwords that are stored. Companies who use VNC and pcAnywhere must be cautious because these passwords are not stored encrypted. Native pcAnywhere passwords and VNC passwords are stored in an easy to unscramble format. Other than that, watch out for router passwords that are not store encrypted (think ’service password-encryption’) and application level passwords. Many companies implementing password encryption forget about application passwords that also need to be encrypted (or hashed).

Bookmark to:
          

In a recent American Banker article, Visa U.S.A. Chief Executive Officer John Philip Coghlan predicted that by the end of this year, more than 60% of the merchants accepting Visa bankcards will have adopted the Payment Card Industry (PCI) Data Security Standard.

I risk spoiling my brand neutrality, but if 60% of Visa’s merchants are PCI compliant by year’s end, I’ll get a Visa tattoo, embed a radio frequency identification device in the back of my right hand and become the first human payment product. “Talk to the hand” will become my preferred payment parlance. Fun as this seems, I feel secure that by year’s end I will remain ink and chip free: I doubt that 60% of merchants will even know what PCI stands for by that time.

I can empathize with the writer in that changing an industry can sometimes feel like parallel parking a large truck. It may be slow and take careful attention to detail but it can be done. Visa has stated at ETA and CEO John Coghlan have both given statistics that put compliance somewhere in the neighborhood of 60% by the end of the year.

Statistics are funny things in that they can be slanted in many ways. The magic percentage number may apply to merchants, service providers, or both for that matter. I would imagine that the merchant population is always increasing so the percentage would have to be based on the number of identified merchants and service providers in a certain year. According to InfoMerchant.net there were over 1.5 million terminals shipped in the US in 2005 (some to replace old terminals and some new.) The percentage compliant only shows a point in time but shows that the industry is slowly moving towards improving security.

The article explains that the “overlooked Level 4″ merchants are such a large risk to the industry because they are using integrated point-of-sale (IPOS) units.

Additionally, several IPOS systems can inappropriately store magnetic-stripe data, often due to merchant misuse or ignorance. Many IPOS systems connect to a processor via high-speed Internet connections, leaving them vulnerable to hackers.

… Our industry is most exposed within the Level 4 merchant category. …

First, Level 4 merchants are not the only ones using IPOS systems; in fact most merchants use them. One web site documents the difference as such:

A point-of-sale (POS) system can refer to many things depending on whom you ask. To some, it is a simple cash register or a standalone card swipe terminal that is connected to a phone line or store controller. To others, it is a PC-based system that integrates a cash drawer and a card reader that runs sophisticated software applications. This report analyzes the PC-based POS system market.

Second, there is nothing super technical about an IPOS other than it uses specific software that ties the credit card reader into a PC. What most people do not realize about the Level 4 definition is that it is not based on acceptance channel. This means that unlike Level 2 and 3, which are based on “e-commerce transactions”, Level 4 is based on either e-commerce or brick-and-mortar transactions.

Does this mean there’s a loop-hole in the level definitions? Maybe. Most Level 4 merchants are small mom-n-pop shops but some are large retailers that do less than 6 million transactions per year (or 500,000 per month average) but do not have an e-commerce presence. This means there are many small merchants and some very large merchants in the Level 4 definition.

The statement that hackers look for IPOS systems is partially correct, but the article makes it sound as if they are primarily used at Level 4 merchants. The story should have explained that hackers are targeting retail stores more than e-commerce stores. This would more clearly explain that Level 2 and/or Level 3 should not be based on acceptance channel (i.e. e-commerce vs brick-and-mortar).

The article provides the following recommendations:

I urge Visa and MasterCard to focus their efforts on this cross section of merchants, and I encourage all acquirers to register all known third parties that represent this merchant group. And I hope everyone in the industry seriously addresses this demographic. The PCI requirements for Level 4 merchants are to pass a self-assessment questionnaire and to pass a quarterly network scan from a qualified independent vendor.

This is exactly what Visa and MasterCard have been doing. CISP, the precursor to PCI, was introduced in 2000 and has been slowly expanding, based on changing risk, from e-commerce systems to the back-end systems down to the POS itself. In December of 2004, Visa posted to its web site the Payment Application Best Practices (PABP), which it plans to make a required part of PCI by the end of this year. The PABP applies to all types of payment applications and their compliance with data security standards will directly impact all merchants regardless of level definition (in fact, most Level 4 merchants only store credit card data in their POS systems so a PABP validated POS may make them compliant right away.) But this too will take time, because even once the secure version of the application is available the merchant will have to implement it in their environment.

Visa and the acquirers are registering third-party service providers all the time and have been since 2000. One of the required items on the report on compliance (ROC) is that the assessor or auditor provide a list of any third party vendors and what access they have to cardholder data.

The acquirers are addressing compliance using a risk model. Level 1 merchants are a higher risk than Level 4 merchants. The retort to that is that many Level 4 merchants add up to much more than the few Level 1 merchants and thus are a higher risk. This is not true.

Yes, Level 4 merchants are compromised more often than Level 1 merchants. Yes, there are more Level 4 merchants, but individually they store fewer credit card numbers. What people do not know is that it takes a whole lot of Level 4 merchants being compromised to equal one Level 1 merchant or service provider hack that results in 10-20 million credit card numbers being compromised. Also, part of the risk equation is consumer confidence, which is affected much more by a Level 1 compromise than by several Level 4 compromises.

The article makes the following recommendations that are already in place.

• Require merchants with dial-up, stand-alone terminals and no other connectivity or card number storage capacity to verify accordingly with an attestation statement. Then exempt them from further compliance-related activity.
• Impose a due date for compliance on merchants processing more than 20,000 transactions yearly, regardless of processing method.
• Provide an Association certification for all acquirers engaged in enterprise-wide cardholder security programs. Advertise these acquirers’ compliance and significance.

Merchants with terminals that dial directly to the acquirer and do not store credit card data have only one compliance requirement to meet: securely storing the paper receipts that print the full credit card number. If their copy has a truncated card number then there is no other compliance requirements.

Due dates have already been set and passed. Every merchant should have been compliant by September 30, 2004. The due date was extended for some merchants, but currently all merchants and service providers need to be compliant.

Qualified information security companies are already working with the top acquirers and processors, and have been for some time, rolling out “enterprise-wide cardholder security programs”. They are working with their entire merchant base to get them compliant. Also, the acquirers have to send reports to the card associations on a regular basis to report the compliance status of their merchant population.

Bookmark to:
          

Bookmark to: