Recently in Security Category
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
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.
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.
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@example.com.
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.
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.
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.
Read rest of story at StorefrontBackTalk
The opportunities offered by the advent of proximity mobile payments are clear; differentiated payment services, increased transaction volumes, faster transactions, increased customer convenience, operational efficiencies and the ability to increase customer loyalty through targeted gift and loyalty programs. With implementations already in place in Europe and Japan, strong consumer interest and the ability to leverage the contactless POS infrastructure already in place, NFC-enabled proximity mobile payments show much promise. But how will security be managed in an ecosystem with so many stakeholders, each managing their own unique aspect of the process? The news is good.
Both the financial and mobile industries have made much progress in defining how NFC-enabled mobile payments will take place and how financial information will be secured. Security is bolstered by the use of industry standards and by the technology supporting proximity mobile payments. Industry organizations have defined standards based approaches to ensuring that payment account information is delivered securely to the mobile phone and stored securely in the phone's secure element.
The NFC-enabled mobile phone leverages the existing ISO/IEC 14443 standard for communicating payment information from the phone to the merchant's POS terminal. Appropriate risk analysis of an operational model for proximity mobile payments can identify where there is potential for fraud or misuse, develop mitigation measures and assign responsibility. From the consumer's perspective, the proximity mobile phone payment looks just like a contactless credit or debit card transaction.
Mobile phones can also leverage two-factor authentication technology to secure the payment application and information. Requiring a passcode or a fingerprint to initiate or respond to the terminal's attempt to initiate or validate a transaction can provide the consumer with additional comfort and a sense of control over a transaction.
While implementations may vary, industry players are moving in a consistent direction. Industry organizations are working to increase ease of access, global interoperability and security of mobile payment technology to consumers. Pilot studies in the United States and implementations worldwide have tested both the technology and the mobile payments process. Proximity mobile payments technology is solid, and will serve this exciting new payment frontier well. Industry stakeholders can leverage the proven technology and a merchant infrastructure that is ready to go to take advantage of consumers' ever-growing love of mobile technology.