Recently in PCI Compliance Category

Radiant being sued not over it's Aloha system which is PCI-validated but over the use of PC Anywhere.


Restaurants Sue Vendor for Unsecured Card Processor

creditcardSeven restaurants have sued the maker of a bank card-processing system for failing to secure the product from a Romanian hacker who breached their systems.

The restaurants, located in Louisiana and Mississippi, filed a class-action suitagainst Georgia-based Radiant Systems for producing a point-of-sale (POS) system that they say was not compliant with payment card industry security standards and resulted in an undetermined number of customers having their debit and credit card numbers stolen.

The suit alleges that the system stored all the data embedded on the bank card magnetic stripe after the transaction was completed -- a violation of industry security standards that made it a high-risk target for hackers.

Also named in the suit is Computer World, a Louisiana-based retailer, which sold and maintained Radiant'sAloha POS system.

According to plaintiffs, Computer World's technicians allegedly installed the remote-access program PCAnywhere on the systems to allow its technicians to fix technical problems from off-site. The only problem is, the company failed to secure the program. The suit alleges that the system was not up to date with software patches, and the PCAnywhere remote log-in and password that technicians used to access the POS systems was the same at every one of the 200 Louisiana locations where the system was installed. According to one of the plaintiffs who spoke with Threat Level, the default login was "administrator" and the password was "computer."


As a result, a hacker, believed to be based in Romania, accessed the systems of at least 19 businesses through the PCAnywhere software, and possibly others plaintiffs say. Once inside, the hacker installed malware to grab card data as it was swiped and send it to an e-mail address in Romania. The hack follows a wave of similar attacks that targeted point-of-sale systems at other national retailers and restaurant chains between 2005 and early 2009, including Dave & Busters restaurants, Hannaford Brothers, TJX, Wal-Mart and others.

The suit was filed in March in the U.S. District Court in Louisiana, but the court ruled only last week that the seven plaintiffs could proceed as a group with their case, opening the way for additional plaintiffs to join the litigation.

"We want other restaurants nationally to be aware of the hidden dangers posed by these technology companies and the unfair penalties imposed by the credit card companies," said plaintiffs attorney Shiel Gallagher in a press release. "These huge companies shouldn't have the power to destroy these restaurants."

The plaintiffs include Crawfish Town USA, Don's Seafood & Steak House, Jone's Creek Cafe, Mel's Diner, Picante's Mexican Restaurant, Sammy's Grill and a Best Western. Two other restaurants have also sued Radiant Systems and Computer World separately.

The restaurants are seeking millions in damages to recover their costs from the breach. These include fines levied against them from Visa and other credit card companies for failing to be PCI-compliant, the cost of forensic audits to uncover the source of the breach, chargebacks to cover fraudulent charges made on customer accounts and reimbursements to card providers who had to issue new customer cards.

According to the plaintiffs' court filing (.pdf), Radiant and Computer World were allegedly warned by Visa in April 2007 that the Aloha system, along with POS systems made by five other vendors, were non-compliant because they stored card data. Visa also sent out a bulletin in November 2006 warning that one of the most frequent vectors for hackers to penetrate POS systems was through poorly configured or unpatched remote-access software (.pdf) and default passwords. Nonetheless, the restaurants say, Radiant and Computer World sold them a product that was neither PCI-compliant nor secured against a known attack.

PCI compliance involves 12 requirements that include: installing and maintaining a firewall, changing default vendor passwords, encryption of transaction data while it's being processed and updated security patches and anti-virus definitions, among other things. Businesses that accept bank card payments from customers are contractually required by the payment card industry to have PCI-compliant architectures and to use only products that are PCI-compliant.

Charles Hoff, general counsel for the Georgia Restaurant Association and one of the plaintiffs' attorneys, says these kinds of security disputes are becoming more common but rarely garner public attention because vendors tend to settle rather than risk exposure through a court case. He said this suit was filed only after Radiant refused to take responsibility for the breaches.

"Radiant ... took a very arrogant attitude about it," he told Threat Level. "I've had other POS vendors who felt they should be accountable, and the end result was that they knew they needed to do the right thing. Radiant I don't think thought we were serious. Radiant's website gives customers the greatest assurance that when it comes to their resellers, they monitor and make sure they're scrutinized and compliant. It really would give you all the confidence in the world if it was actually done."

Radiant has declined to comment on the details of the suit.

"What we can say is that Radiant takes data security very seriously and that our products are among the most secure in the industry," Paul Langenbahn, president of Radiant's hospitality division, told the Atlanta Journal Constitution. "We believe the allegations against Radiant are without merit, and we intend to vigorously defend ourselves."

Keith Bond, owner of Mel's Diner in Broussard, Louisiana, told Threat Level that he purchased his Aloha system for $20,000 and installed it around late November 2007. Computer World, he says, convinced him that the system needed to be connected to the internet for faster transaction processing, as opposed to the dial-up modem connection he had been using for processing.

In April 2008, just a few months after installing the system, one of his employees called to tell him that the mouse cursor on one of three Aloha terminals he'd bought seemed to be moving on its own and that employees were unable to take control of it.

After contacting Computer World technicians, the restaurant was told to disconnect its system from the internet. A service tech appeared the next day to replace the hard drive, but didn't disclose the nature of the problem or indicate that an intruder had breached the system. Bond learned only later that a keystroke logger had been installed on all three of his Aloha terminals, and that the intruder had been siphoning card numbers for about three weeks.

He discovered this only after Visa and Mastercard contacted him in May to tell him his system had been breached. Bond, whose 24-hour diner processes about 60 to 70 card transactions a day, says 669 card numbers were stolen during the three-week period the hacker was in his system.

"If they had accessed the server, they would have got thousands of card numbers," Bond said.

The credit card companies forced him to hire a forensic team to investigate the breach, which cost him $19,000. Visa then fined his business $5,000 after the forensic investigators found that the Radiant Aloha system was non-compliant. MasterCard levied a $100,000 fine against his restaurant, but opted to waive the fine, due to the circumstances.

Then the chargebacks started arriving. Bond says the thieves racked up $30,000 on 19 card accounts. He had to pay $20,000 and managed to get the remainder dropped. In total, the breach has cost him about $50,000, and he says his fellow plaintiffs have borne similar costs.

Bond said Radiant and Computer World were unresponsive.

"Radiant just basically hung us out to dry," he says. "It's quite obvious to me that they're at fault.... When you buy a system for $20,000, you feel like you're getting a state-of-the-art sytem. Then three to four months after I bought the system, I'm hacked into."

Image courtesy California State Controller's Office

Recommended Commentary Link


Lessons Learned From PCI Compliance

Assessors reveal mistakes companies make with data security standard. -- To help companies get ready for a an evaluation, we asked QSAs to describe common problems they encounter when working with IT groups on PCI compliance. What follows are five best practices to help companies better prepare for an assessment and maintain compliance.

1. Know Where Data Lives

First off, you must know how credit card data flows through your system, where the data resides in the enterprise, and who has access to it. Assessors ask for this information at the outset of an assessment because it determines the scope of the project. They aren't there to review your entire security infrastructure, just the systems that collect, process, transport, and store credit card data. A surprising number of companies don't have a good grasp of this information. "It's common for a client to completely miss a particular data flow and have no idea that credit card data is being forked off to system X, Y, or Z," says a QSA at Neohapsis, who asked to remain anonymous.

Companies express an "extreme amount of frustration" over the amount of effort they have to put in to put the full picture together, says Ted Keniston, a QSA and managing consultant with the global compliances group at Trustwave. "We should be validating this information, not determining it."

Having a complete picture of credit card data isn't just a courtesy to your assessor; it also affects your ability to protect customer information, because you can't secure what you don't know about.

2. PCI Is A Moving Target

Let's say your assessor has just stamped you "compliant." You breathe a sigh of relief. The PCI assessment is annual, so you don't have to worry about it for another 12 months, right? Not so.

PCI compliance is only valid and only applies to the state of the network and systems at the time of the assessment. The moment you make changes to systems that fall under the 


Rest of article and pdf of entire article


inside-pci-compliance_884972.pdf

Visa has announced new global best practices for data field encryption, also known as end-to-end encryption - a much-discussed solution in the wake of the Heartland Payment Systems breach.

Announced by the global credit card company on Monday, these best practices are designed to further the payment industry's efforts to develop a common, open standard while providing guidance to encryption vendors and early adopters. Data field encryption protects card information from the swipe to the acquirer processor with no need for the merchant to process or transmit card data in the "clear."

Visa's Jennifer Fischer, senior business leader in the card company's risk area, says encryption is not being touted as a silver bullet for anyone, "But we see it as a way to supplement and help, in many cases, augment existing security measures."

Data field encryption can be another layer to enhance a merchant's security by eliminating any clear text data either in storage or in flight.

In addition to issuing these encryption best practices, Visa is chair of the ANSI X9F6 standards working group and is helping to develop a much-needed industry data field encryption standard. Fischer notes that Visa is also working with the Payment Card Industry Security Standards Council in reviewing its recent study by PriceWaterhouseCooper on emerging technologies use in the payments industry. Encryption was cited as one of the top four emerging technologies being looked at within the payment stream to protect data.


read rest of article
By David Taylor -- Most merchants and application vendors seriously underestimate both the scope and the force of the Payment Applications Data Security Standard (PA DSS). If so, it's only because they haven't read the standard or don't immediate grasp what's involved.

 Essentially, this standard could cause merchants in all industries and of all sizes to have to switch payment application vendors. Furthermore, since these applications are not generic "plug and play" software "modules," any changes will require changes to all custom code designed to integrate with ERP, sales audit, general ledger and other office management applications would also have to change. In short, PA DSS is a much "bigger deal" than the 1.2 release of the PCI DSS.

The Scope of PA DSS. Any application packaged for sale that collects (e.g., via a form that someone fills in or automated means), processes, or stores card data is included in the scope of PA DSS. That means that ALL merchants (even Level 4s) must only be running validated applications and this means that application vendors must pay to have their application tested in a "laboratory" by a PA DSS QSA (assessor), a list of which is conveniently maintained by the PCI Security Standards Council, who recently took over the task from Visa.

Assessment is price-competitive. Currently, there are fewer than 20 companies worldwide that have been approved to test and validate PA DSS compliance. More are joining the list all the time. Because the demand from merchants and, hence, application vendors, is just developing, we're hearing stories of a very price-sensitive market, with resulting "variability" in the quality of assessment, because low-ball-bidders have to make a profit on their assessments. As a result, we caution all merchants not to assume an equal level of data security between two application vendors just because they both appear on the PA DSS "white list." Merchants need to do their own validation of the data security controls and ask for copies of the PA DSS test reports.

The application vendor's dilemma. We've interviewed application vendors who tell us they are waiting until customers demand PA DSS compliance before having their software tested, and/or that their customers (the merchants) have no clue about PA DSS, so they don't want to get their current version validated, when a new version will be coming out in another 6 months, and they'd have to pay to have it tested also. The issue of "Why pay for security testing that customers don't even care about?" is likely to continue for another six months or so. As long as the focus of the SSC and the card brands is on the "minor tweaks" in PCI DSS 1.2, there will be less marketing bandwidth available to highlight the major changes which PA DSS will bring about in the market.

The demand lag and its market impact. This "cat and mouse" issue of paying to have a version validated prior to demand for PA DSS will get much more complex over the next two years. Most application vendors have, thusfar, only had zero or one version tested, because it's expensive and demand is "immature" at best. We expect that getting tested and being on the PA DSS "white list" will become part of nearly all relevant RFPs within a year. If this doesn't happen, then it's highly unlikely that the merchant community (all levels) will be running all PA DSS compliant applications by the October 2009 and July 2010 deadlines. Faced with potentially massive non-compliance, the logical response would be to postpone the deadlines. It's happened before.  

What are the compensating controls for PA DSS? Read rest of article

Tokenization and your store

New approach shapes how retailers secure private information and consumer confidence against data breaches

With stores located in various states and, in some cases, overseas, chain stores face a unique data security challenge. The plethora of recent State Breach Notification Laws and European privacy laws, as well as industry mandates such as the Payment Card Industry's Data Security Standard, put a lot of pressure on chain store CSOs to come up with foolproof ways to protect consumer information against a data breach.

Source Article

Many retailers have already adopted localized encryption and follow data security best practices but, for some companies, this may not be the most efficient way to protect credit-card numbers and various forms of personally identifiable information (PII), including customer loyalty data, and employee social security and commercial drivers' license numbers, etc.

With traditional localized encryption, the encrypted data is stored in applications and databases in place of the original unencrypted data, which means it is located in many places throughout the enterprise. Every system that contains encrypted data is a point of risk and remains "in scope" for PCI DSS compliance and audits. What's more, encrypted data takes more space than unencrypted data, requiring costly programming modifications to applications and databases, along with increased data storage costs.

To solve these challenges, a new data security model -- format preserving tokenization -- is beginning to gain traction with retailers. Tokenization reduces the number of points where sensitive data is stored within an enterprise by replacing encrypted data with data surrogates (tokens) and storing the encrypted information in a central data vault. This makes data security easier to manage and provides an extra layer of security, but it also takes systems "out of scope" for PCI DSS compliance.

Tokenization explained

With traditional encryption, when a database or application needs to store sensitive data, those values are encrypted and the cipher text is returned to the original location. With tokenization, a token -- or surrogate value -- is returned and stored in place of the original data. The token is a reference to the actual cipher text, which can be stored locally ("in-place tokenization") or, as in the newly-emerging model in a central data vault. As long as the token is format-preserving, it can be safely used by any application, database or backup medium throughout the organization. This minimizes the risk of exposing the actual sensitive data and allows business and analytical applications to work without modification.

Format-preserving tokens can either match the expected data type or expose a subset of the original value to simultaneously protect the information and enable applications and job functions to continue unmodified. For example, the token could expose the last four digits of the social security number or credit card number to enable call center operations.

Tokens use the same amount of storage space as the original clear text data instead of the larger amount of storage required by encrypted data. And since tokens are not mathematically derived from the original data, they are arguably safer than exposing cipher text. They can be passed around the network between applications, databases and business processes safely while leaving the encrypted data they represent securely stored in a central data vault. Authorized applications that need access to encrypted data can only retrieve it using a token issued from a token server, providing an extra layer of protection for sensitive information and preserving storage space at data collection points.

Encryption, tokenization, or both: What's right for your enterprise?

There are two distinct scenarios where implementing a token strategy can be beneficial: to reduce the number of places sensitive encrypted data resides or to reduce the scope of a PCI DSS audit. The hub and spoke model is the same for both and contains these three components:

* Centralized encryption key manager to manage the lifecycle of keys.
* Token server to encrypt data and generate tokens.
* Central data vault to hold the encrypted values, or cipher text.

These three components comprise the hub. The spokes are the endpoints where sensitive data originates such as point-of-sale terminals or the servers in stores, various departments at headquarters, a call center or Web site.

In the traditional model, data is encrypted at the stores (spokes) and stored there; or encrypted at headquarters and distributed back out to the stores. Under the tokenization model, encrypted data is stored in a central data vault and tokens replace the corresponding cipher text in applications available to the stores, thereby reducing the instances where cipher text resides throughout the enterprise. This reduces risk because the only place encrypted data resides is in the central data vault until it is needed by authorized applications and employees.

In the second scenario, the model is the same but the focus is on using only tokens in spoke applications thereby reducing scope for a PCI DSS audit. In this case, employees only need a "format-preserving" token where the token provides enough insight for them to perform their jobs. For instance, the token will contain the last four digits of a credit card. In the traditional encryption model, cipher text resides on machines throughout the organization. All of these machines are "in scope" for a PCI DSS audit. In the centralized tokenization model, many of the spokes can use tokens in place of cipher text, which takes those systems out of scope for the audit.

Format preserving tokenization is ideal for some chain store enterprises, while a hybrid approach is better for others. Localized encryption is the default when stores are not always connected to a central data vault. In instances where stores are electronically connected to the data vault, tokenization is often the solution of choice. For many chain store companies, using a combination of localized encryption and tokenization is a practical approach for improving data security.

Format preserving tokenization protects payment-card information and employee information as well as all types of customer PII and loyalty data collected by many chain store marketers. Not only does the technology provide an extra layer of security in an extended enterprise, but it reduces storage space requirements and the scope of PCI DSS audits.

Gary Palgon is VP product management for data protection software vendor nuBridges, and is a frequent contributor to industry publications and a speaker at conferences on eBusiness security issues and solutions. He can be reached at [email protected]. 


The conventional wisdom is that when large vendors enter a niche market, those vendors "legitimize" that market. But the announcement that First Data and RSA Security are getting into the credit card tokenization business raises many issues beyond them simply "making" the tokenization market. Here is my first take on the implications of this announcement:

Posted from StorefrontBackTalk

  • Pressure On The PCI SSC To Embrace Tokenization
    The PCI Security Standards Council already commissioned Price-Waterhouse Coopers to do a study of tokenization, end-to-end encryption and other "beyond PCI" issues. The results will likely be discussed at the PCI SSC Community Meetings. That's great. Merchants, service providers and even QSAs want specific guidance about tokenization. This announcement and the weight of the players in the market should virtually guarantee that tokenization will be specifically addressed in the next release of PCI DSS, in addition to QSA training and other guidance from the SSC.

  • Pressure On Payment Processors And Gateways
    I have said before that the number of companies offering tokenization will increase several-fold within a year. We've already seen about a dozen players enter the market in the last six months. I'm expecting 30 to 40 more announced packages over the next six months, as payment processors, gateways, encryption vendors and application vendors all vie to see who can remove credit card data from the merchant environment the fastest.

  • Tokenization Standards And Portability Will Be Hot Topics In 2010
    The more options in the market, the more the demand for "token switching" will increase. Merchants who have entrusted their card data to Service Provider X will increasingly seek shorter duration contracts and have more specific demands about how they migrate their data from one tokenization provider to another.


    Because there are not currently any standards for either the form of a credit card token, how it is generated or how one token type can be converted to another (they can't, BTW), as more merchants realize this, they will raise concerns about being "locked in" to a particular tokenization approach. Smaller vendors will develop "token migration" or conversion tools, etc.

  • Multi-Channel Options And Other Complexity Issues Will Emerge


    Read rest of story at StorefrontBackTalk


  • August 2009 release of best practice doc, PCI_skimming_prevention_form.pdf, directed at skimming attacks. Illustrates how exposed terminals in POS are targeted by criminals. Wires, connections, ceilings, boxes, cameras and staff problems. It's a good document though worth noting that we find it ironic that the council would provide best practice guidelines for download as a Microsoft doc file. Historically and functionally that is one of the most dangerous files to download and have a user open. Guidelines also include self-assessment forms which are useful.

    Chapter 1: Overview

    The primary mission of the Payment Card Industry Security Standards Council (PCI SSC) is to ensure the security of payment data and the security of the payment infrastructure that processes that data. PCI SSC is committed to build trust in the payment process and payment infrastructure for the benefit of all constituents. As the threats and vulnerabilities of fraud evolve, payment constituents can and should expect the emergence of further security standards and requirements for terminal types, terminal infrastructure, payment devices, and payment process.

    This document was created to assist and educate merchants regarding security best practices associated with skimming attacks. Though currently not mandated by PCI SSC, guidelines and best practices documents are produced to help educate and create awareness of challenges faced by the payment industry. The guidelines are the result of industry and law enforcement understanding of the current and evolving threat landscape associated with skimming. In addition we have incorporated known best practices, currently conducted by many merchants, to mitigate skimming attacks taking place in their respective point-of-sale environments. .

    This document contains a non-exhaustive list of security guidelines that can help merchants to:

    · Be aware of the risks relating to skimming.

    · Be aware of the vulnerabilities inherent the use of point-of-sale terminals and terminal infrastructure.

    · Be aware of the vulnerabilities associated with staff that has access to consumer payment devices.

    · Prevent or deter criminal attacks against point-of-sale terminals and terminal infrastructure.

    · Identify any compromised terminals as soon as possible and notify the appropriate agencies to respond and minimize the impact of a successful attack.

    Additional security can--and must--be provided by merchants to enhance the security provided y the current PCI SSC standards and payment terminal vendors. Merchants have an obligation to ensure their respective payment systems and infrastructure are secure. 

    Merchants are the firstline of defense for POS fraud and are involved in the execution of the vast majority of controls suggested or required by PCI SSC. Merchants can achieve appropriate security and trust levelsat the point of sale by considering all the factors that can influence overall security in their terminal environment and taking the necessary countermeasures detailed in this document to ensure an appropriate level of security.
    There's an ongoing debate about the ability of cloud computing services to meet enterprise regulatory compliance requirements, including the Payment Card Industry Data Security Standard (PCI DSS) standard that is essential for e-commerce.

    Dcument purpose  - This document provides guidance and installation suggestions for testing and/or deploying 802.11 Wireless Local Area Networks (WLAN) for organizations that require Payment Card Industry's Data Security Standard (PCI DSS) v1.2 compliance. The goal is to help organizations understand how PCI DSS applies to wireless environments, how to limit the PCI DSS scope as it pertains to wireless, and practical methods and concepts for deployment of secure wireless in payment card transaction environments.


    PCI_DSS_Wireless_Guidelines.pdf
    Article covering wireless transaction and protocols in context of PCI compliance. Amazing that 11% use WPA2. Gist of article is that many companies have WEP hardware and need a "blanket" to wrap it is in order to secure PCI compliance. 

    July 9, 2009 - TLC-Chamonix, LLC (TLC) unveils its WirelessWall POS Architecture for wireless Point of Sale Terminals. It helps retailers achieve PCI DSS compliance by combining AES encryption, firewall, AAA and end-to-end security in a standards compliant software solution. Now, WEP or even Open wireless POS terminals and Access Points can have WPA2-Enterprise level security without changing any terminals, firmware or replacing network gear. WirelessWall saves time, saves money, and helps makes you achieve PCI DSS 1.2 network compliance.

    The award winning WirelessWall secures wireless and wired infrastructures to provide a transparent instant upgrade to standards compliant, certified (FIPS 140-2) strong security with access controls, allowing business applications and operations to continue undisturbed. It offers peace of mind with better protection, auditability, compliance, and loss prevention, while avoiding the cost of new equipment, new leases and downtime.

    Industry Initiative
    Faced with the prospect of billions of dollars in losses and lawsuit settlements, the retail industry is finally taking serious measures at self-regulation to protect merchants and consumers from wireless security breaches. Consider:

    • 2009 TJX, the parent company of TJ Maxx, Marshalls and other retailers, paid a $9.8M settlement to 41 states after a $40.9M settlement to Visa for wireless POS breaches. It absorbed over $135 million loss from its 2007 incidents alone.
    • 2008 breaches identified by the Identity Theft Resource Center-breaches totaled 449 with over 22 million records exposed. (That's more than all breaches in 2007 and the individual record count is climbing and will exceed 2007 as well)
    • 2007 breaches totaled 448 paper and electronic breaches with 127 million records exposed. 
    • 2006 breaches totaled 315 affecting nearly 20 million individuals. 
    • 2005 breaches totaled 158 affecting more than 64.8 million people. 

    The Payment Card Industry (PCI) is a consortium of worldwide credit card companies (Visa, MasterCard, American Express, Discover and JCB International). To confront and mitigate these mounting losses, and faced with imminent regulation by state and federal agencies plus penalties for violating existing privacy laws, they formed a Security Standards Counsel which implemented a Data Security Standard (PCI DSS) to preemptively control the problem.

    PCI DSS - A New World Order
    The new edition of the standard mandates improved wireless security practices and drops the broken Wired Equivalency Protocol (WEP) as an approved method, in favor of protocols using strong encryption such as AES. See: PCI DSS 1.2

    PCI DSS is not merely a set of recommendations -- non-compliance is not an option. It is a contractual obligation which demands all retail merchants big and small to comply as a condition of being allowed to continue processing credit cards and consumer information via electronic Point of Sale (POS) terminals or other wireless methods. 

    According to mandate, retailers may not implement new wireless payment systems that use WEP after March 31, 2009. For those that already have wireless payment systems in place, they must stop using WEP for security as of June 30, 2010. 

    Impact Assessment
    Naturally, this has enormous significance to operations and the bottom line of retailers. Perhaps just as great is the cost to POS terminal vendors, who have a large inventory of WEP-only wireless terminals that are often leased to merchants. They stand to lose considerable sums replacing or retrofitting equipment at costs which cannot easily be passed on to merchants, especially in a bad recession. 

    In these difficult times, vendors and merchants alike need a lower cost, easy to deploy solution that scales from small business to large enterprises with least impact.

    WEP Dominates
    The mandate bans the use of WEP, but it still dominates and others like WPA2 are poorly adopted. An Airtight 2009 Financial Districts Survey of 3,632 access points in major cities found half were Open or used WEP security. It concluded:

    • Everybody who knows security knows WEP is broken, but it still dominates.
    • Some used WPA, which had a crack demonstrated in Tokyo in 2008.
    • Others hide SSIDs which doesn't protect traffic captured by wireless sniffers.
    • 39% were "enterprise" APs (corporate HQs, offices, etc.)
    • Only 11% used WPA2 

    Even worse than this news is that of the tiny few organizations using WPA2, almost all have implemented pre-shared keys (WPA2-PSK) which has well known dictionary cracks, like CoWPAtty that can crack it in seconds - in many ways, making it worse than WEP.

    Why Fix Something that Isn't Broken?
    The abysmal failure of WPA2 to gain widespread adoption has not prompted the industry to question why (almost) no one is using it. Serious debate and changes in the telecommunications industry to adopt better technology and new standards will be needed before WEP is entirely eliminated.

    WEP is still pervasive in large part because wireless equipment manufacturers and industry groups failed to take decisive action to totally replace it and continue to manufacture equipment that supports it. WPA2 is still a security configuration option (and alphabetically WEP is first in most lists). Many users are simply unaware of the difference.

    There is also the reluctance to switch from existing protocols until there is an incident that demands it. This translates to the maxim: Why fix something that isn't broken? Unfortunately, this common sense rule can be very costly when applied to security. WEP is broken, but most users don't know it. The feeling is that if WEP weren't "good enough", why would the protocol still be supported by network equipment?

    Consumer awareness is one aspect. Even among the technically knowledgeable, there is little appreciation of the distinction between WPA, WPA2-PSK and the only truly strong protocols: WPA2-Enterprise. All others suffer risk of Man-In-The-Middle attacks, brute-force guessing, or key exchange compromises. The dictionary vulnerability risk of WPA2-PSK can be more vulnerable than WEP.

    WPA2-Enterprise is the best solution, but many businesses just don't have back-end RADIUS authentication and LDAP identity management servers or IT with the level of knowledge required to use them, so they accept the risk

    The WirelessWall Architecture

    WirelessWall is a government certified (FIPS 140-2) wireless security suite used by the military and DoE. Renowned for its investment protection value, WirelessWall adds WPA2-Enterprise grade protection to the current network as a software-only solution instead of replacing legacy wireless hardware and firmware. The DoD 8100-2 directive is mandate for federal and state governments to provide standards based end-to-end strong security. WirelessWall satisfies this directive and was assessed by the Joint Interoperability Testing Center (JITC) for use by Coalition Forces. This high level of protection is now being used to benefit the private sector and retail to eliminate hacking or sniffing end-to-end. 

    Even if terminals and WiFi gear only support WEP or no security at all, WirelessWall adds a blanket of strong encryption without any reconfiguration. Because it bundles WiFi AES encryption with RADIUS, LDAP and Firewall Policies all in one package.

    This solution allows you to meet the compliance requirements listed below.

    Table 1 - PCI DSS 1.2 Compliance
    PCI DSS Mandate Requirements
    Install and maintain a firewall configuration to protect cardholder data 1.1, 1.2, 1.3, 1.4, 1.5
    Do not use vendor-supplied defaults for system passwords and other security parameters 2.1, 2.2, 2.3
    Encrypt transmission of cardholder data across open, public networks 4.1, 4.2
    Develop and maintain secure systems and applications 6.1, 6.2, 6.3, 6.5

    Additionally, it is simpler to deploy and administer, and more cost effective than having those in a separate back-end (although it will support external services if needed). WirelessWall supports all wireless gear: all 802.11 protocols, WiMax 802.16e, Mesh and 4G. Using WirelessWall gives you everything for a fraction of the cost and none of the inconvenience of alternatives.



    Contact: TLC-Chamonix, LLC
    120 Village Square Suite 
    11 Orinda , CA 94563, USA
    Phone : 877-479-4500
    E-Mail:[email protected] 
    http://wirelesswall.com/
    http://wirelesswall.com/markets/pos/POS-mandate-brochure.pdf
    Nice article on tokenization which also highlights lack of formal standards for tokenization at this time. 

    Credit Card Tokenization: Put All Your Data Eggs in One Basket--and Watch That Basket

    I was on a call recently with Gartner, Inc., analyst John Pescatore to learn about credit card tokenization. Pescatore, who specializes in Payment Card Industry Data Security Standard (PCI DSS), encryption related to PCI DSS, and overall security of Internet systems for Gartner, explained that tokenization can reduce a company's odds of a data breach as well as reduce the cost and complexity of PCI DSS compliance and auditing. A couple of other Penton Media editors, including System iNEWS technical editor Mel Beckman, were also on the call, and I present our questions and Pescatore's answers here for your edification. [Editor's note: nuBridges Inc., a software company that recently released a tokenization product, arranged our discussion with Pescatore but did not attend the call or have any control over what was discussed.]

    Pescatore: The basic issue we've seen from enterprises is that the PCI mandate says that certain types of data have to be masked or encrypted. However, encryption does carry costs and complexity, plus the real issue is that what businesses really need to do is minimize the number of places where they store the credit card data--because in order to encrypt card data, you need encryption keys. If you're storing this data in more places than you need, the odds get higher that your keys will get compromised. So in the past couple of years, we've seen a lot of movement away from blind encrypting.

    Here's an example: A lot of pretty big companies don't have credit card payment as a big part of their business, but they have the PCI security requirement even for the small amount of payment processing they do. And they thought encrypting and other PCI security requirements were too complicated, so they outsourced the payment processing so they'd never store the card data, just a token. These companies could get full access to the transaction data, but the outsourced payment processor sends it to them without the card data. This idea of tokenization and masking started with these outsourcers. nuBridges is one of the first to work tokenization into a key management product. Now enterprises who either can't or don't want to outsource payment processing can do it themselves with tokenization. However, outsourced payment processors do have to get certified as PCI compliant.

    rest of article

    http://www.gokiosk.net/kiosk/tokenization-in-depth.pdf


    Wal-Mart this month became the latest major retailer to experiment with self-service kiosks, selling space in 77 stores for units that buy back used video games and issue credits directly to various payment cards.

    The initial trial is entirely isolated, with the kiosk vendor having access only to its own network and not to Wal-Mart's. But the $375 billion chain is officially considering having the machines offer in-store credits in the form of gift cards, which would mean allowing the kiosks two-way access to POS and potentially CRM data. That would force some serious strategic debate about how far outside vendor kiosks can--and should--be allowed to play inside a retailer's databases.

    The initial version of the kiosks collect payment card information as well as drivers license data. Even setting aside the potential future POS/CRM access, the payment and highly-sensitive driver's license data will force some of that debate right away. How secure are the kiosks? Who is ultimately responsible in the event of a security breach, both from a legal and PCI perspective?

    Beyond lawyers and assessors, consumers and the dollars they control will likely blame the retailer for any problems that started with a kiosk in or right next to its store. Wal-Mart officials are stressing that the Wal-Mart logo will not be used on any of the trial kiosks, although the Wal-Mart blue and yellow brand colors will absolutely be used. "This is not Wal-Mart's machine," said Melissa O'Brien, a spokeswoman for Wal-Mart's entertainment division. "We are leasing space to them in our store vestibules just like with do with other companies." And that nuanced distinction will be explained to every Wal-Mart customer how?

    The insistence that no brand be used displayed will be a nice point for the lawyers, but it won't do much for public perception. PCI Safe Harbor and legal indemnification won't help much if consumers feel betrayed.

    Another troubling issue is data ownership. If Wal-Mart gets consumers to come to their stores and asks them to interact with a kiosk in the store, can the kiosk vendor use that information to help other retailers? As a pragmatic matter, how can they not do so?

    The kiosks will know precisely who is returning what products and for how much money. Wouldn't consumers goods manufacturers--such as the ones that made that game as well as the ones that make rival offerings--kill for such data? Or to even be able to send a message to those people? And what about other retailers trying to steal some marketshare?

    Alan Rudy, CEO of E-Play, the Ohio-based kiosk operator that is working with Wal-Mart on this trial, insisted the units securely handle credit and debit card data. He said E-Play retains ownership of all information gathered by the kiosks and has no plans to share or sell it, but he wouldn't rule out anything for the future.

    Rest of the story


    While sensational data breaches experienced by big-box retailers and processors fill the headlines, 85 percent of reported data compromises involve small merchants - defined as Level 4 by the Payment Card Industry (PCI) Data Security Standard (DSS). More than 6 million small merchants are doing business in North America; fewer than 5 percent have attested to compliance with the PCI DSS.

    By Joan E. Herbig
    ControlScan

    These are potentially costly statistics for acquirers, who ultimately shoulder the monetary burden should their merchants experience breaches.

    Beyond their abundance, Level 4 merchants carry unique challenges. Acquirers can reduce their overall risk and dramatically improve compliance rates among these merchants by overcoming four often-overlooked pitfalls when designing their PCI compliance programs.

    Challenge 1: Little awareness of security

    Small merchants are focused on making ends meet. They have little awareness of - or time to focus on - security best practices. The few who have heard of PCI compliance typically don't know the standard applies to them. They assume PCI compliance is only for the "big guys" or e-commerce merchants.

    Those who realize PCI compliance does apply to them often approach it as a perfunctory process. The benefits of better security often aren't clear to them, and they don't realize breaches could be catastrophic for their businesses.

    Acquirers are required to develop a plan to address and educate small merchants about the PCI DSS. The PCI Security Standards Council (SSC) provides basic air cover, but acquirers that take a proactive, targeted approach to engage Level 4 merchants with a variety of educational materials and tactics will become valuable partners to their merchants and gain a competitive advantage.

    Education should be a significant component of any acquirer's comprehensive merchant outreach strategy to drive PCI compliance. Examples of helpful educational tools for small merchants include:

    • FAQs tailored to Level 4 merchants
    • PCI DSS basics
    • Tools to help merchants determine their PCI Self-Assessment Validation category and whether they require quarterly scans
    • Overview of the risks merchants face if they are not PCI compliant
    Additionally, acquirers should advise small merchants against storing credit card data without a compelling business reason for doing so, and direct them to use Payment Application DSS-compliant applications. That way, small merchants will experience a simpler path to PCI compliance and reduce their risk of data compromise.

    Challenge 2: Lack of technical expertise

    Most small merchants have few or no technical staffers to manage the PCI compliance process. All of them are required to complete Self Assessment Questionnaires (SAQs) annually and maintain compliance throughout the year. Many have problems answering basic questions in the SAQ because the language is often aimed at technical users.

    Questions like the following frequently arise:

    • What validation type am I?
    • What is a payment application?
    • What is encrypted data?
    • What is a firewall?
    How do I know if I'm storing prohibited card data?
    Level 4 merchants typically have no idea how credit card data flows through their businesses, and most don't have security awareness programs to educate employees on best practices for ensuring the security of cardholder information. Thus, they are highly reliant on outside parties, including their acquirers or POS equipment vendors, and often receive conflicting advice.

    Acquirers can help reduce confusion by providing small merchants with guidelines to answer SAQ questions that are specific to each merchant's environment. This makes it easier to complete the SAQ and improves the quality of responses. Acquirers may also want to consider providing security awareness training, in everyday language, to provide fundamental information small merchants need to guard against data compromises.

    Going forward, acquirers may want to establish processes for obtaining sufficient information about their merchants' environments that will enable them to answer certain questions, such as what payment application a given merchant uses. This data could be pre-entered in an online SAQ to make the process easier and less frustrating for the merchant.

    Challenge 3: Diverse merchant environments

    Small merchants often need multiple touch points to become knowledgeable and engaged in the PCI compliance process. Retailers lacking computer or e-mail access present acquirers with challenges regarding how to fully track and convey compliance rates for their small merchant portfolios.

    Acquirers must be prepared to provide paper versions of the SAQ to merchants without online access. Moreover, acquirers should develop a content management and reporting strategy for these one-off measures. This will ensure they maintain a holistic view of compliance for their merchant portfolios.

    Acquirer portfolios frequently consist of large concentrations of non-English speaking merchants, which compounds the difficulty of the entire compliance process. While the PCI SSC provides the SAQ in English and six other languages, acquirers still face the issue of providing training and technical support to help merchants answer the questions effectively. Acquirers will need to formulate plans to provide the SAQ and support for completing the SAQ in multiple languages.

    Challenge 4: Web site vulnerabilities

    Small merchants with externally facing Internet Protocols (IPs) must complete quarterly vulnerability scans (SAQ Validation types 4 and 5) to comply with the PCI DSS. Small merchants face unique challenges in complying with this requirement.

    Before scanning even begins, small merchants typically ask basic questions, including:

    • What is an externally facing IP?
    • What do I need to scan?
    • How do I find my firewall password?
    • Do I need to scan my POS system that is connected to the Internet?

    Most vulnerabilities found in small merchant scanning results require assistance from outside vendors to remediate. For example, dangerous structured query language injection and cross-site scripting vulnerabilities require a programmer to remediate; however, most merchants don't have a programmer in-house and are often not sure whom to commission.

    The merchant's host also plays a role in remediating vulnerabilities, and while there are many cooperative hosts, some are not willing to make the changes required to bring the merchant into compliance.

    Changes to consider

    Developing and implementing a successful Level 4 compliance program is not easy, but acquirers that take the time to develop a plan that anticipates the unique challenges their small merchants face upfront will increase the likelihood of realizing much higher compliance rates and less merchant frustration.

    Acquirers that don't have the time and resources to dedicate to comprehensive PCI compliance should consider partnering with a company that specializes in PCI compliance for small merchants.

    Different deployment options exist, ranging from full outsourcing to a hybrid model, where an acquirer's support team is trained to handle some aspects of support. This helps ensure the acquirer is equipped with knowledge to answer basic technical questions that often stall merchants early in the PCI compliance process.

    Security is becoming increasingly multilayered and complex, so even those with expertise have difficulty configuring security tools correctly. Acquirers managing a PCI compliance program should be prepared to "get in the trenches" to effectively support their merchants.

    Whether managed in-house or externally though a third-party, a well-executed PCI program helps acquirers reduce risk and provides an opportunity for them to take a leadership position and establish stronger relationships with their merchants.

    Joan Herbig is Chief Executive Officer of ControlScan. She has more than 20 years' experience in the high-tech world and serves on the Electronic Transactions Association's Risk and Fraud committee. Contact her at [email protected] or 800-825-3301.

    Excerpt: Critical to the selection was choosing a vendor that best met PCI DSS (Payment Card Industry Data Security Standard) requirements. For this, ePlay turned to WatchGuard to provide the instrumental role in PCI DSS requirement 1 - Install and maintain a firewall configuration to protect cardholder data.

    Editors Note:  Regulations too often become a bullet point and lose there practical effect on a project. PCI compliance is that way with self-service terminals.  Many kiosks that handle credit card data do not have firewalls installed on them either for wired or wireless access. Here is example of firewall selection.


    SAN FRANCISCOApril 22 /PRNewswire/ -- RSA -- WatchGuard(R) Technologies, a global leader in extensible network security and connectivity solutions, today announced that ePlay, an innovator in the DVD rental business, has selected WatchGuard solutions to provide PCI DSS compliant firewall security, and to protect thousands of remote DVD and video game disc rental kiosks as well as ePlay's back-end data center.

    "After evaluating Cisco, and other network security vendors, ePlay standardized on WatchGuard for their high security, performance, reliability and unbeatable total cost of ownership," said David Stellmack, Senior Systems Engineer at ePlay. "This is a mission-critical network comprised of remote kiosks and a data center transacting a large volume of payment card transactions. With WatchGuard in place, we can drive down costs, reduce time to market, and increase our provisioning process by twofold."

    PCI DSS Compliant Protection

    Critical to ePlay selection was choosing a vendor that best met PCI DSS (Payment Card Industry Data Security Standard) requirements. For this, ePlay turned to WatchGuard to provide the instrumental role in PCI DSS requirement 1 - Install and maintain a firewall configuration to protect cardholder data.

    To do this, each ePlay kiosk is armed with a WatchGuard Firebox Edge appliance to provide firewall, intrusion detection/prevention services, and highly secure VPN network connectivity. For remote kiosks, such as those located outdoors, ePlay utilizes the WatchGuard 3G Extend family of wireless connectivity solutions. With it, triple-DES encrypted VPN tunnels carry payment card and other sensitive data via 3G cellular networks. This gives ePlay maximum flexibility for kiosk deployments, usage models and most importantly, strong cardholder data security.

    With hundreds of remote firewall appliances to manage, and thousands more to come in the next few years, ePlay relies on WatchGuard System Manager, which provides ePlay with a PCI DSS friendly, free software solution to manage and upgrade remote WatchGuard appliances.

    At the data center, a pair of WatchGuard X Peak 8500 e-series, running in high availability mode, terminates remote kiosk VPN tunnels. As required by the PCI DSS, this network of cardholder data is completely walled off and separated from ePlay's corporate network and online reservation architecture, which are protected by other WatchGuard firewall appliances.

    Stellmack concludes, "I've looked at other kiosk vendors and shudder at their approach to security; I don't think they're deploying anything even close to enterprise-level security for credit card transactions. We would rather be over-secure, and WatchGuard helps provide that."

    About e-Play, LLC

    e-Play is a revolutionary way of marketing, delivering and purchasing DVDs and Video Games: a high-tech DVD rental platform combined with the ability to buy/sell/trade video games all in a single machine. e-Play provides the technical innovation for its units to hold thousands of discs, convert used discs into cash or credit at the retailer and perform a playability check on every disc dispensed. The machines include new releases and catalog titles and feature an interactive touch LCD screen playing trailers and interactive advertising. Founded in 2005 and headquartered inColumbus, Ohio, e-Play Makes it Easy to Find the Movies - and now, the Games - You Want.

    About WatchGuard Technologies, Inc.

    Since 1996, WatchGuard(R) Technologies, Inc. has been the advanced technology leader of network security solutions, providing mission-critical security to hundreds of thousands of businesses worldwide. The WatchGuard family of wired and wireless unified threat management appliances and WatchGuard SSL VPN remote access solutions provide extensible network security, unparalleled network visibility, management and control. WatchGuard products are backed by WatchGuard LiveSecurity(R) Service, an innovative support, maintenance, and education program. WatchGuard is headquartered in Seattle and has offices serving North AmericaEuropeAsia Pacific, andLatin America. To learn more, visit http://www.watchguard.com/.

    Worth noting Heartland Payment Systems and RBS Worldpay have been removed from Visa Inc.'s list of PCI compliant service providers and will have to undergo new PCI assessments and reapply for inclusion on the compliance list, according to a Visa announcement.

    Visa's action came after the two companies revealed they were victimized by hackers who managed to plant malicious software in the companies' internal processing systems and steal card data from the unencrypted data stream. Heartland had been listed as under review -- but still compliant -- prior to Friday's announcement, but now Visa has removed the Princeton, N.J.-based company from its lengthy list of service providers compliant with the Payment Card Industry Data Security Standard (PCI DSS). It was unclear whether RBS also had been under review.

    This was noted on the ETA Compliance Portal and it looks to be a very helpful resource. Here is some of the information.


    For list of validated applications click here

    The OCS DSS Quick Reference Guide is located here pci_ssc_quick_guide.pdf

    The ETA Compliance portal is located at http://www.electran.org/content/view/535/211/

    Acknowledging the need for controls that go beyond those offered by the Payment Card Industry (PCI) Data Security Standard, a senior Visa Inc. executive Thursday described two new initiatives to reduce payment card fraud being tested by the company.


    One of the pilots involves Fifth Third Bank, which is testing the use of magnetic stripe technology to create unique digital fingerprints for cards, said Ellen Richey, Visa's chief enterprise risk officer. Each stripe contains unique characteristics that can be captured and used to verify the digital identity of the card, Richey said during at a security event being hosted by Visa today. The goal is to stop the creation and use of counterfeit cards based on stolen payment card data.

    Another initiative, being piloted by retailer OfficeMax Inc., involves the use of a challenge-response technique at the point of sale. The project is aimed at testing the efficacy of asking consumers to respond to specific questions such as their ZIP code, the last four digits of their phone numbers, or the first three digits of their area codes, as part of the transaction approval process.

    Dan Roeber, vice president and manager of merchant PCI compliance at Fifth Third, said the bank had rolled out about 1,000 card readers to retailers who have not been informed about the pilot effort. The terminals are capable of reading the magnetic stripe information and creating a "DNA picture" of the card which is then matched during the authorization process, against baseline information for that card stored by the card issuer, he said during a panel discussion at the event Thursday.

    During the pilot process, baseline images or fingerprints for a card are created when it is first swiped through one of the new readers, Roeber said. But going forward, if the approach works, baseline images for each card could be created and stored during the card issuing process itself, Roeber said. "Even if somebody gets into a database and makes fraudulent cards, the DNS fingerprints are not going to match," Roeber said. "The thing I really like about this technology is that there are no key management issues," as is the case with the use of end to end encryption for protecting cardholder data.

    "We are very excited about this technology," he said.

    Fifth Third is one of several "acquiring banks," which are responsible for authorizing retailers to accept payment card transactions.

    William Van Orman, treasurer for OfficeMax, said the retailer had rolled out its challenge-response process to about 1,000 of its stores across Illinois, Indiana and Florida. The process, which has required changes to point-of-sale systems at these locations, involves asking customers ZIP codes or other personal information after swiping a card. The responses are then matched against responses to these questions that were previously selected by the consumer.

    For the pilot, the emphasis was on simply trying to understand what kind of changes needed to be made to the point-of-sale systems, and the kind of impact the new authorization process would have on merchants and consumers, Van Orman said. Customers were informed that the data was being requested for a pilot project and had the chance to opt out if they chose to, Orman said. After an initial six-month period, the pilot project has been extended by another four months at the request of Visa, he said. "Overall we think it's a successful project," he said.

    Richey said that while these projects were not quite ready for broad roll-out yet, they were indicative of the kind of approaches that could be used to make stolen data useless at the point of sale.

    Richey also highlighted Visa's efforts to give consumers more tools to fight fraud. One of them is a new service called the Transaction Alert system, and is currently available to Chase cardholders with Android-based smartphones, she said. The service provides real-time alerts of purchase activity on their mobile devices, which consumer can tailor using information such as whether they were online transactions, and locations where the transactions were made. The program will become available to all card issuers later this year, she said.

    The other program, which is still in development, is called Targeted Acceptance and would allow consumers to set personal limits on how, where and what amounts their cards can be used for. The service is already available to commercial customers and will be rolled out to consumers as well, Richey said.

    Richey said Visa was not opposed in the future to the idea of using chip and PIN technologies that are used widely in Europe. They require consumers to enter PIN numbers, instead of signing, when making credit card transactions. The approach is widely considered to be safer than purely signature-based transaction, but it would require considerable investments on the part of card issuers to make the change. Richey said today that Visa "fully" supports the technology and said it was not a matter of "if" but "when" and "how" the technology would be adopted in the U.S.

    Dave Weick, CIO at McDonalds Corp., discussed during a panel a new plan to minimize threats against payment card data. He described how the fast-food giant was exploring how to completely segregate all payment card data and transactions from the rest of its internal network. Weick said McDonalds had developed a way to accept payment card transactions without letting any of that data touch any of its own internal systems, including its point-of-sale devices.

    No one in the company's internal system would have access to any cardholder data, and even the portion of the network that deals with card transactions would be handled by an outside vendor, Weick said. "We are very early on in this," he said, adding that the plan was to first roll out the approach to company-owned restaurants before deploying it across all franchises.

    Heartland Payment Systems (HPY), one of the largest credit card processors in North America, is finally being called to the carpet for the apparent lapses in Payment Card Industry Data Security Standards (PCI DSS) that contributed to the largest data breach of 2008, perhaps even the largest breach ever considering the full extent of the exposure has yet to be determined.

    Called to the carpet sort of, anyway; the sanctions and guidance laid out by Visa (V) seem a little lackluster when weighed against the severity and duration of the breach.

    Given that Visa is now considered the most likely of several candidates for inclusion in the Dow Industrial Average, taking up slack from soon to be sidelined Citigroup (C) and Bank of America, (BAC) it is not surprising that they do not want to call too much attention to the situation:

    On January 20th of this year, Heartland Payment Systems (HPS) publicly disclosed a large-scale compromise involving account data from all card brands. In light of this event, Visa has taken the following actions to help protect the Visa system:

    CAMS Alerts - Between January 18th and February 4th Visa issued a series of Compromised Account Management System (CAMS) alerts (US-2009-046-IC) to financial institutions related to this compromise event. Providing this information can help financial institutions act quickly to minimize fraud on exposed card accounts.

    It is worth noting here that Visa and MasterCard (MC) reported anomalies to Heartland in late October, about two and a half months before the CAMS alert was issued.

    The rest of the story

    hrough October 29, 2008, Trustwave's forensics practice has investigated 443 cases of cardholder data compromise. The information contained within this article is the culmination of almost seven years of card compromise investigations.

    Key Developments in 2008: The Theft of Cardholder Data in Transit

    In 2008, the most notable development in payment card compromises is the theft of cardholder data at rest (stationary on a system component) to its theft in transit (moving through a system). Trustwave experts have noted that attackers, are stealing data in real-time by eavesdropping on a certain device and stealing the data as it passes to or through a particular system rather than stealing data that is stored on that system.

    One example of this is an attackers' use of unauthorized applications--referred to as malware--that steals cardholder data from a computer's Random Access Memory. What's perhaps most unsettling about the trend is that a merchant can use a payment application that complies with the Payment Application Data Security Standard (PA-DSS) or Visa's Payment Application Best Practices (PABP), but still fall victim to a compromise.


    Merchants and service providers must recognize that payment card security extends beyond just using PABP or PA-DSS validated payment applications and eliminating the storage of prohibited cardholder data. Any entity involved in the processing, storage or transmission of payment card data must ensure that they comply with the Payment Card Industry Data Security Standard (PCI DSS). In the cases of track data parsing from RAM that Trustwave has examined, the intruder gained the access necessary to execute the attack because the victim organization did not comply with the PCI DSS in full.

    General Payment Card Compromise Statistics

    The theft of cardholder data in transit is only beginning to impact Trustwave's compromise statistics. However, our experts expect the occurrence of these types of breaches to increase.

    Below are more general statistics that, for the most part, have remained constant over the past few years.

    Payment Card Acceptance Channel

    Whether the compromised merchant accepts payment cards over the Internet, in person or over the telephone or through the mail; we see the greatest variation between North America and EMEA (Europe, the Middle East and Africa) cases. In North America, the majority of compromises investigated by Trustwave were of brick-and-mortar merchants. In EMEA, the majority of compromises investigated were of e-commerce merchants. This fact is the reason many of the statistics from North America and EMEA differ as they do.

    Industry

    Businesses involved in the food service and retail segments make up the majority of compromises investigated by Trustwave, with approximately half of the compromises occurring at food service locations. In North America, the majority of compromises occurred at food service establishments. In the EMEA region, the majority of Trustwave investigations were of payment card breaches at merchants within the retail sector.

    Cases by Responsibility for Payment System Administration

    Many North American merchants investigated by Trustwave use outdated payment systems or do not configure them securely. Misconfigured payment applications will store or insecurely transmit cardholder data that can be stolen by an attacker. Many times a third party configured those payment applications and so negligence on the part of the third party more often contributes to the payment card compromises investigated in North America. Because the use of outmoded payment applications is not as prevalent in EMEA as in North America, neither are the problems caused by third-party installation, configuration or maintenance of such payment applications. Common PCI DSS Failures of Compromised Merchants

    For the most part, while the frequency of failure may be less, the PCI DSS requirements that compromised merchants fail to meet correspond in EMEA and North America. The PCI DSS requirements that compromised merchants failed to fulfill include:

    • Requirement 3: Protect stored cardholder data
    • Requirement 6: Develop and maintain secure systems and applications
    • Requirement 10: Track and monitor all access to network resources and cardholder data
    • Requirement 12: Maintain a policy that addresses information security for employees and contractors

    Cases by Technical Cause

    Trustwave finds that five technical causes contribute to the majority of payment card compromises across both North America and EMEA:

    • SQL Injection: Exploiting flaws in a Web application to force a back-end database to disclose information stored in the database (such as cardholder data)
    • Remote Access: Accessing remote control software used to operate a computer from remote locations
    • Backdoor/Trojan: Installing malware onto a system to gain access to a network
    • Perimeter Security Issue: Lack of or insecurely configured perimeter security
    • Weak Passwords: Guessing authentication credentials (username and password)

    The majority of compromises investigated by Trustwave in North America occurred due to insecure payment applications that store prohibited data; however, as previously noted, the theft of cardholder data in transit is on the rise.

    SQL injection is the number one cause of compromise cases investigated by Trustwave in EMEA. Again this can be attributed to the fact that more e-commerce merchants are compromised in EMEA. An e-commerce merchant must have a public-facing Web site in order conduct business and so leaves a section of their system open for attack.

    Conclusion and Merchant Action Items

    The key take-away from this analysis of card compromise cases should be that merchants must comply with the PCI DSS. Plenty of data security pundits continue to disparage the standard. However, the PCI DSS provides a comprehensive security standard that if followed, prevents the theft of cardholder data. To protect themselves and their customers, merchants must take a holistic approach to data security--an approach such as that prescribed and explained in the PCI DSS. [end] 


    Source Link

    Technology ROI -- By moving to a thin-client software architecture using the Microsoft Windows Server operating system, Domino's has been able to lower the investment cost for franchisees by several thousand dollars. In addition, by moving to the thin-client environment, Domino's has reduced the amount of information stored at each of its workstations to help achieve compliance with Payment Card Industry (PCI) data security standards.
    Heartland Payment Systems (HPY) on Tuesday disclosed that intruders hacked into the computers it uses to process 100 million payment card transactions per month for 175,000 merchants: http://www.usatoday.com/money/perfi/credit/2009-01-20-heartland-credit-card-security-breach_N.htm I took a moment to see if they were PCI Compliant and they were audited in March 2008 by Trustwave.

    They said the start of it all was a keylogger that got into their systems, as described in this snippet from http://www.informationweek.com/news/security/attacks/showArticle.jhtml?articleID=212901505&subSection=News

    ---------- 
    "the breach was the result of keylogging malware, which covertly captures anything typed on an infected computer, such as user names and passwords. ... 

    There were two elements to it, one of which was a keylogger that got through our firewall," he said. "Then subsequently it was able to propagate a sniffer onto some of the machines in our network. And those are what was actually grabbing the transactions as they floated over our network." 
    ---------- 

    You have to wonder if the keylogger software came in over a network, or if it was carried in by an employee on a USB token, in a laptop they infected while using it at home or while traveling, etc.We're not sure PCI DSS can effectively prevent problems like those, although it can recommend good security practices that reduce the possibility.


    PCI DSS mandates that machines that store/process/transmit cardholder information should not have direct Internet connectivity. There shouldn't really be a means for a sniffer to send results back to it's employer over the Internet, so in a way the exploit described does violate PCI DSS.

    Also, integrity, anti-virus and event monitoring controls should certainly pick up things like keyloggers and an IDS/IPS/firewall could be used to identify some rather odd connections from certain servers.


    Recent Entries

    Security Standards - Visa requiring encryption of debit card PINs on new pumps now, existing ones by July 2010
    January 7, 2009 (Computerworld) Lower gas prices aren't the only thing that's new at the pumps these days. Data encryption…
    Esprida to Simplify Security and Remote Management for Kiosks with Solidcore Partnership
    Allows Retailers to Sustain PCI Compliance While Maintaining Flexibility to Remotely Manage and Update Self-Service Systems CUPERTINO, Calif.--(BUSINESS WIRE)--Solidcore® Systems,…
    7 Deadly Myths and Solutions for PCI Compliance
    The first Payment Card Industry Data Security Standards (PCI DSS) Compliance in Hospitality Conference has reconfirmed what we found in…



    Related Ring Sites:
      GoKIS  |   ThinClient.org  |   keefner.com  |   Visi Kiosk site  |   KIOSK  |   Kis-kiosk.com  |
    Resource Sites:
      Elo TouchSystems  |   Acire Inc.  |   Nextep  |   TIO Networks  |   Olea  |   Self-Service Networks  |   Meridian Kiosks  |   Provisio  |   Kioware  |
      Selling Machine Partners  |   Source Technologies  |   Seepoint  |   5Point  |   Nanonation  |   Netkey  |   KioskCom  |   Summit Research  |   NCR  |