October 2009 Archives

Report from trust catalyst detailing the trends and obstacles to data encryptions, applications affected, and why it's important (average cost per breach in $6M)


Excerpt: he most significant increases in this year's research were "File encryption - server" moving up from fifth to second place and "Mobile device encryption" rising from eleventh to ninth. Email encryption at the client saw the most significant fall, from third place in 2008 to fifth in 2009. There was not a significant increase in encryption adoption for databases or backup tapes in 2009. We continue to caution organizations not encrypting these applications that they remain at serious risk of data breach -particularly with regard to patient and credit card data.

2009_Enc_and_Key_Mgmt_Industry_Benchmark_Report_201009.pdf
Pros and Cons of the Emerging Technologies Eyed to Improve Data Security
October 19, 2009 - Linda McGlasson, Managing Editor


Tokenization or end to end encryption - which solution will win the hearts of data protectors in the race to secure data?

A recent study conducted by PriceWaterhouseCoopers on behalf of the Payment Card Industry Security Standards Council shows that end to end encryption and tokenization are the top choices for companies seeking to employ new emerging technologies to protect payment card and other critical data. And both approaches have their public proponents, including Heartland Payment Systems (HPY) CEO Robert Carr, who's been encryption's most vocal supporter in the wake of his organization's historic breach.

But what are the pros and cons of each approach? We turned to a panel of information security experts for their analyses of tokenization vs. end to end encryption.

Defining the Solutions
A quick look at the essence of these two solutions:

Tokenization replaces sensitive card data information with unique id symbols that keep all the essential data, without compromising its security. This approach has become popular as a way to increase security of credit card and e-commerce transactions, while minimizing the cost and complexity of industry regulations and standards - especially the Payment Card Industry Data Security Standard (PCI).


End to end encryption, also defined by Visa as data field encryption, is continuous protection of the confidentiality and integrity of transmitted data by encrypting it at the origin, then decrypting at its destination. The encrypted data travels safely through vulnerable channels such as public networks to its recipient, where it can be decrypted. One example is a virtual private network (VPN) that uses end to end encryption.

The question for many organizations is not either/or, but rather which approach best fits into the organization's existing security architecture?

Pros and Cons
Size is a factor for organizations weighing tokenization and end to end encryption, says Dave Shackleford, former chief security strategist at EMC, and now principal at Blue Heron Group. "I would probably choose tokenization for smaller organizations, but larger ones will likely benefit more in the long run from looking to implement robust encryption practices and technologies," Shackleford says. Tokenization may not encompass all the data that needs to be protected by larger organizations, he adds.

read rest of article


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

In the first step of its move toward end-to-end encryption, Heartland Payment Systems (HPY) last week completed the first phase of its pilot project.

Heartland, the sixth biggest payments processor, earlier this year announced that it was hit with a data breach, wherein credit card numbers and debit card information were taken by hackers who broke into the payment processor's internal network. Since the breach was announced, the company has been working toward introducing advanced encryption standard (AES)-encrypted card transactions from merchants to Heartland's processing platform.

The merchant that took part in the pilot last Monday was a small carwash operation in Plano, TX, near Heartland's operation center. AES is the highest level of encryption and is currently on track to replace Data Encryption Standard (DES) and Triple DES as the desired standard for sensitive data. The pilot transactions included multiple credit cards, prepaid and signature debit card transactions that tested each of the major card brands, says Robert Carr, Heartland's chairman and chief executive officer.

Heartland's Solution

Heartland's new tamper-resistant security module terminal is meant to stop hackers from sniffing data beginning at the point of sale until it reaches the end point at the payment processor. Typically, cardholder data is unencrypted as leaves a merchant's terminal and isn't encrypted until it is either tokenized in a gateway or at rest in the processing platform's data warehouse.

The pilot tested four of five payment zones, the fifth being contingent upon the card brands or card issuer, when the data is sent from the processor to the authorization and settlement centers of the card brand or issuer.

Rest of article

Mobile barcodes are on the verge of becoming a global phenomenon, but what exactly are they, what do they do, and for whom? We became familiar with the original, linear barcodes (or 1D), from our supermarket shopping in the 1980's (although the technology was patented in the 1950's). They comprise a series of vertical black lines and white spaces of variable width, representing numbers, which are read (or decoded) by a barcode reader to extract the information they bear.

However, as barcodes were used in an ever greater variety of environments beyond straightforward stock control, they became longer and longer as people tried to pack more information onto them. A new generation of barcodes was devised in the 1990's, usually referred to as 2D or matrix codes. They are formed by patterns of black and white squares arranged on a (usually) square grid and can encode thousands of alphanumeric and other characters in virtually any language. Immediately the size and capacity problem was solved, opening the way for applications that had never been considered. 

Another radical and exciting advancement in barcode reader technology allowed the camera in a mobile phone to act as a reader. Mobile phones can now be enabled to read a variety of 2D mobile barcodes. These include QR codes, Data Matrix, Cool-Data-Matrix, Aztec, Upcode, Trillcode, Quickmark, shotcode, mCode and Beetagg.

The vast majority of symbologies are in the public domain, which means they can be used by anyone without restriction and without payment of a fee or royalty. This public approach gives rise to internationally recognised standards, global interoperability, and creates an economy of scale.  This is a great boon for advertisers and consumers (both of whom are the mobile operators' customers) because only one software client is required to read any code.  For the operators, this translates to greater choice and more competitively priced equipment.

Unfortunately, some barcode developers have chosen the proprietary route, which means they keep control of their own codes, the information that is permitted to be encoded and charge a fee or royalty for their use. These issues and the lack of interoperability usually means that proprietary barcodes tend to be used in controlled, closed environments, rather than in open, public systems around the world.

The most common use of mobile barcodes is to request information or a service or content from a Web site. It might be details of a promotion, or a discount voucher via SMS or MMS, or to activate a download such as a ringtone, music track or game, or click to call an IVR or human agent, or buy a travel or concert ticket. The advertiser pays the set-up costs as well as its operator partner on a per-click, download, view, redeemed coupon, ticket sale or call, depending on the campaign.

The key is that mobile barcodes are a pull technology, a permission-based way for a consumer to engage with an advertiser or medium. This is a very important attribute since there is a great deal of consumer angst and regulatory concern about intrusivemobile marketing: mobile barcodes are a world away from pushing unsolicited spam via SMS or MMS. Big brands are understandably wary of engaging in any advertising activity that compromises their reputation by alienating their customers and have stayed away from these kinds of push campaigns.

The pull of mobile barcodes overcome these issues and offer a direct, accountable way of connecting with consumers. However, if mobile barcodes are to succeed as an advertising medium, a high level of back-office integration is necessary, which reinforces the importance of open standards for processes and interfaces. Operators will need to demonstrate to the world's biggest brands that the barcode scanning transactions are accurate, reliable and defendable because they are going to charge that brand for every click.

The precedent is there: Google has built a multi-billion dollar, online business on this per click or interaction model with its Google AdWord/AdSense, which provides advertisers with reliable, accountable records of their users' transaction history and an accurate invoice, plus timely and granular revenue share payments to other parts of the ecosystem. In mobile, unlike online, there is the additional challenge that these mechanisms have to work across carriers, across countries and across currencies.

So the stage is set. With 2D barcode scanning, advertisers have a reliable, permission-based mobile channel open to them. Consumers love them as an easy way of using mobile technology to engage with services and media they are interested in, as has been demonstrated in spades in Japan, where mobile barcodes are part of everyday life. This is because Japan is unusual in having a very dominant operator, NTT DoCoMo, which decided to endorse QR codes and ensured that all new handsets had QR code client software embedded in them. The rest is history, but this approach is not applicable to markets in most other countries, which typically have four or five operators competing against each other.

The challenge now is to ensure that any brand advertiser can run the same ad campaign in Singapore, London and Seattle instead of having to produce and run different campaigns in each country and for every operator. The inability to do this has been another big inhibitor to mobile advertising. Mobile barcodes have the potential to overcome these issues and become the mainstream, global phenomenon that they could and should be. However to attain this goal, the various parties that make up the ecosystem and the various warring factions within the mobile barcode industry need to come together and work on common standards* that will be to everyone's advantage.

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]. 





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  |