Effective PCI Tokenization Methods

Recently a colleague and a friend of mine wrote a great article about different ways to be PCI 2.0 compliant by tokenizing PAN data. If in case you missed it I want to draw your attention to it.

Essentially, if you are looking to be PCI-DSS 2.0 compliant there are few ways you can achieve that. The most painful would be obviously a rip-and-replace strategy and the easiest would be to do it in an incremental, less intrusive method.

First approach, the Monolithic big bang approach, is the legacy way of doing things. Once you figure out the areas of your system that are non-compliant (that is either storing PAN data –encrypted or not, or processing PAN in clear), you decide whether you need that component to be PCI compliant. As the PCI audit is very extensive, time consuming and very methodical, in which every process, application, storage, database, and system will be looked at and thereby it becomes very expensive. Once you figure out which components need to be PCI compliant you can do the rip and replace approach in which you will touch every system component that needs to be modified and rewrite the system to become compliant. This might involve touching every component and change your entire architecture. This essentially will be the most expensive, painful and the slowest before you can be compliant. While this can be the most effective for spot solutions, this could be an issue if you have to do this every time when the PCI-DSS needs change (which seems to be every year).

Second approach, API/SDK based tokenization is much more effective. In this case, you can retrofit applications, processes, systems, databases, etc. by making those components call an API (or SDK) which will convert the PAN data and return a token which can be used to replace the original PAN data. This requires you to do minimally invasive procedures. While this doesn’t require you to change your entire architecture/ system it still requires you to touch all those components that need to be compliant. Effectively this method is a lot faster and quicker to the market, while also giving you an opportunity to change quickly when the PCI-DSS needs change.

The third approach is called a gateway approach. In this you essentially monitor the traffic between components and tokenize/ de-tokenize the data in transit. This is also known as in-line tokenization. This method is effectively the cheapest, and the quickest to the market. But the biggest advantage is that your changes to your existing systems will be very minimal to nil. Essentially, you make the PAN data flow through the gateway which will take care of converting the PAN data to tokens before it hits your systems. Imagine the painful exercise when you have to make your Mainframe and legacy systems compliant by having them deal with tokenized data if you were to re-code those legacy systems. This method will essentially eliminate that.

You can read his entire article here.
Cost Effective PCI DSS Tokenization for Retail (Part I)
Cost Effective PCI DSS Tokenization for Retail (Part II)

Also, don’t forget to check out our tokenization buyer’s guide here.

 

Andy Thurai — Chief Architect & Group CTO, Application Security and Identity Products, Intel

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, Governance, Security, and Identity solutions for their major corporate customers. In his role, he is responsible for helping Intel/McAfee field sales, technical teams and customer executives. Prior to this role, he has held technology architecture leadership and executive positions with L-1 Identity Solutions, IBM (Datapower), BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 25+ years of IT experience.

He blogs regularly at www.thurai.net/securityblog on Security, SOA, Identity, Governance and Cloud topics. You can also find him on LinkedIn at http://www.linkedin.com/in/andythurai

 

Context Aware Data Privacy (part II)

If you missed my Part 1 of this article, you can read it here when you get a chance (link).

As a continuation to part 1, where I discussed the issues with Data Protection, we will explore how to solve some of those issues in this article.

People tend to forget that hackers are attacking your systems for one reason only –  DATA. You can spin that any way you want, but at the end of the day, they are not attacking your systems to see how you configured your workflow or how efficiently you processedyour orders. They could care less. They are looking for the golden nuggets of information that either they can either resell or use to gain some other kind of monetary advantage. Your files, databases, data in transit, storage data, archived data, etc. are all vulnerable and will be of value to the hacker.

Gone are the old days when someone was sitting in mom’s basement and hacking into US military systems to boast about their ability amongst a small group of friends. Remember Wargames,  the movie?  Modern day hackers are very sophisticated, well-funded, often in for-profit organizations, and are backed by either big organized cyber gangs or by other entities within their respective organizations.

So you need to protect your data at rest (regardless of how the old data is – as a matter of fact, the older the data, the chances are, they are less protected), data in motion (going from somewhere to somewhere – whether it is between processes, services, between enterprises, or into/from the cloud or to storage), data in process/usage. You need to protect your data with your life.

Let us closely examine the things I said in my last blog (Part 1 of this blog), the things that are a must for a cloud data privacy solution.

More importantly, let us examine the elegance of our data privacy gateways (code named: Intel ETB – Expressway Tokenization Broker) that can help you with this costly, scary, mind-numbing experience go easily and smoothly. Here are the following elements that are embedded in our solution that are going to make your problem go away sooner.

1.       Security of your sensitive message processing device

As they say, Caesar’s wife must be above suspicion (did you know Caesar divorced his wife in 62 BC). What is the point of having a security device that inspects your crucial traffic, if it can’t be trusted? You need to put in a solution/devices where a vendor  can make assertions regarding security and have the necessary certifications  to back up those claims. This means that a third party validation agency should have tested the solution and certified it to be ‘kosher enough’ for an enterprise, data center or cloud location. The certification must include FIPS 140-2 Level 3, CC EAL 4+, DoD PKI, STIG vulnerability tested, NIST SP 800-21, and support for HSM, etc. The validation must come from recognized authorities, not just from the vendor.

2.       Support for multiple protocols

When you are looking to protect your data, it is imperative that you choose a solution that not only can handle the HTTP/ HTTPS/ SOAP, JSON, AJAX and REST protocols. In addition, you need to consider whether the solution supports all standard protocols known to the enterprise/cloud, with “Legacy” protocols such as JMS, MQ, EMS, FTP, TCP/IP (and secure versions of all of the above) and JDBC. More importantly, you also need to determine whether the solution can speak industry standard protocols natively such as SWIFT, ACORD, FIX, HL-7, MLLP, etc. You also need to look at whether or not the solution has the capability of supporting  other custom protocols that you might have. The solution you are looking at should give you the flexibility of inspecting your ingress and egress traffic regardless of how your traffic flows.

3.       Able to read into anything

This is an interesting concept. I was listening to one of our competitor’s webcasts… there was complete silence when what appeared to be a dreaded question, was asked of the person speaking on behalf of that company: “How do you help me protect  a specific format of data that I use in transactions with a partner?”Without hesitation, the presenter answered the question by  suggesting their solution lacked support for it. While I’m not trying to be unnecessarily abrasive, the point is that you should have the capability to be able to look into any format of data that is flowing into, or out of, your system when the necessity arises. This means that you should be able to inspect not only XML, SOAP, JSON, and other modern format messages. A solution should be able to retrofit your existing legacy systems to provide the same level of support. Message formats such as COBOL (oh yes, we will be doing a Y10K on this all-right), ASCII, Binary, EBCDIC, and other unstructured data streams that are of equal importance. Sprinkle in the industry format messages such as SWIFT, NACHA, HIPAA, HL7, EDI, ACORD, EDIFACT, FIX, FpML to make the scenario interesting. But don’t forget our good old messages that can be sent in conventional ways such as MS Word, MS Excel, PDF, PostScript and good old HTML, etc. You need a solution that can look into any of these data types and help you protect the data in those messages seamlessly.

4.       Have an option to sense not only the sensitive nature of the message, but who is requesting it and on what context and from where

This is where we started our discussion. Essentially, you should be able to not only identify data that is sensitive,  but take necessary actions based on the context. Intention, or heuristics, are a lot more important than just sensing something that is going out, or in. So this essentially means you should be able to sense who is accessing what, when, from where, and more importantly from what device. Once you identify that, you should be able to able to determine how you may want to protect that data. For example, if a person is accessing specific data from a laptop from within the corporate network, you can let the data go with the transport security, assuming he has enough rights to access that data. But if the same person is trying to access the same data using a mobile device, you can tokenize the data and send only the token to the mobile device. (This allows you to solve the problem where location is unknown as well. ) All conditions being the same, the tokenization will occur based on a policy that senses that the request came from a mobile device.

5.       Have an option to dynamically tokenize, encrypt, format preserve the encryption based on the need

This will allow you to be flexible to encrypt certain messages/ fields, tokenize certain messages/ fields or employ FPE on certain messages. While you are at it, don’t forget to read my blog on why Intel’s implementation of the FPE variation is one of strongest in the industry here.

6.       Support the strongest possible algorithms to encrypt, storage, and use the most random possible random number for tokenization

Not only should you verify the solution has strong encryption algorithm options available out of the box (such as AES-256, SHA 256, etc.), but you should also ensure that the solutions delivers cutting edge security options when they become available – including support for the latest security updates.

7.       Protect the encryption keys with your life. There is no point in encrypting the data, yet giving away the “Keys to the Kingdom” easily

Now this is the most important point of all. If there is one thing you take away from this article let this be it: When you are looking at solutions, make sure that not only that a solution is strong on all of the above points, but most importantly, ensure that you  protect the proverbial keys with your life. This means the key storage should be encrypted, and  should be capable of having: an SOD (separation of duties), key encrypting keys, strong key management options, key rotation, re-key options when the keys need to be rotated/expired or lost, key protection, key lifetime management, key expiration notifications, etc. In addition, you also need to explore if there is an option to integrate with your existing key manager in house such as RSA DPM (the last thing you need is to disrupt the existing infrastructure by introducing a newer technology).

8.       Encrypt the message while preserving the format so it won’t break the backend systems

This is really important if you want to do the tokenization or encryption on the fly without the backend or connected client applications knowing about it. When you encrypt the data and  preserve its format, it will not only look and feel the same as the original data, but the receiving party won’t be able to tell the difference.

If you are wondering Intel comes into the picture in this area, we address of all of the discussion points mentioned in #1 to #8, with our Intel Cloud data privacy solution (a.k.a. Intel ETB – Expressway Token Broker) and a lot more. Every single standard that is mentioned in here  is supported, and we are working on adding the newer, better standards as they come along.

Check out information about our tokenization and cloud data privacy solutions here.

Intel Cloud Data Privacy/ Tokenization Solutions

Intel Cloud/ API resource center

I also encourage you to download the Intel Expressway Tokenization Broker Data Sheet:

 

Andy Thurai — Chief Architect & Group CTO, Application Security and Identity Products, Intel

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, Governance, Security, and Identity solutions for their major corporate customers. In his role, he is responsible for helping Intel/McAfee field sales, technical teams and customer executives. Prior to this role, he has held technology architecture leadership and executive positions with L-1 Identity Solutions, IBM (Datapower), BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 25+ years of IT experience.

He blogs regularly at www.thurai.net/securityblog on Security, SOA, Identity, Governance and Cloud topics. You can also find him on LinkedIn at http://www.linkedin.com/in/andythurai

 

Cost Effective PCI DSS Tokenization for Retail (Part II)

Welcome back, and thanks for continuing to read our blog series on reducing PCI Scope.  In our last blog we covered why reducing PCI Scope is so important.

Before we address common approaches to Tokenization, let’s recap what PCI DSS Tokenization is:

What is PCI DSS Tokenization?­­

PCI DSS Tokenization is a means for protecting credit card data by substituting a different, non-encrypted value for a credit card number.   Usually this takes the form of random number (with some of the first digits and ending digits preserved) that appears to back end systems to be a valid credit card number.

It is important that the random elements of the token (that is the digits that are not preserved) are not in any way derived from the actual credit card number.  [i] This randomized token is stored in a secure vault, which defines the mapping from the PAN to the token.

Common Approaches to Tokenization:

The first choice that merchants must make when embarking upon a path to scope reduction through tokenization is whether to build their own tokenization technology or to acquire it from a vendor (Intel/McAfee is of course such a vendor).

In the past merchants chose to build their own solutions as commercial PCI DSS Tokenization products are relatively new (with formal guidance from the PCI Counsel only appearing in late 2011).[ii]

In order to keep this blog post to a manageable length we will concentrate on the merchant data center rather than addressing both the point of sale locations and the data center in one post.   The same principles that apply to the data center are applicable to the retail locations as well. I invite those interested in a subsequent article on point of sale scope to contact me.

Figure 1 below shows reference architecture for retail data centers.   It does not represent any particular merchant’s data center, but rather represents a set of common components aligned in a typical architecture.     Virtually every retailer has an authorization path for data, a clearing path (that is usually a mainframe with batch processing of results in TLOG or similar formats), and provisions at the point of sale to process transactions in case the internet is not available at the time of the credit card charge.

---

 

Figure 2 represents the typical PCI DSS Scope associated with this architecture.   Please note that due to the offline requirement for processing credit cards (and therefore the need to store transactional data at the store server), typically most parts (if not all) of the retail locations are in PCI scope.

Figure 2:  Typical PCI DSS Scope at a Retailer’s Data Center

Three Approaches to PCI DSS Tokenization Architecture:

There are three common architectural approaches to PCI DSS Tokenization.

1)     Monolithic Approach

2)     API Tokenization (sometimes called Toolkit Tokenization)

3)     In-line Tokenization

The monolithic approach appeals to many as it promises to remove Points of Sale completely from PCI Scope and to bring the data center along for free.   This typically involves upgrading and standardizing equipment at the retail locations to allow encryption at the PIN Pad or Register.

Often the acquiring bank is able to decrypt the results ensuring that there is no obvious reason why actual cleartext PAN data may be needed within the enterprise.

This theory is very appealing as it implies it may be possible to remove the entire enterprise from PCI Scope and therefore drastically reduce compliance costs.

Peeling back the onion on Monolithic Scope Reduction:

There are several challenges associated with implementing monolithic scope reduction.   Some of them are listed below:

1)     Cost Versus Benefit

2)     Time to Value

3)     Fragility to Change

4)     Vendor and bank lock-in (what happens when it is time to renew the contract?)

Cost Versus Benefit:

As the value of monolithic scope reduction depends upon capturing the PAN data and protecting (encrypting or tokenizing) it at every retail device, all retail locations must be upgraded before real scope reduction is accomplished.

For a large retailer with thousands of locations this cost could easily mount to the tens of millions of dollars.     Often this does not compare favorably with the value achieved by reducing or eliminating PCI Scope.

Time to Value:

Most large retailers upgrade retail locations on a rolling basis (often on a 5 year or more schedule).   Deviating from this schedule is often very difficult.

Therefore, if each retail location must be upgraded (perhaps with new POS terminals and potentially with new software and registers) before significant business value is achieved, then expenditures begin on day one and benefits only begin to accrue at the end of a complete retail refresh cycle (usually measured in years).

Fragility to Change:

The monolithic scope reduction approach depends upon the assumption that the only places that PAN data enters the retailer are controlled directly by the retailer or the data protection vendor and that the only services that must consume the protected PAN data are in direct partnership with the data protection vendor (i.e. The Acquiring Bank has a partnership with the tokenization or encryption vendor such that it is able to derive cleartext PAN data from the protected PAN).

Therefore, no PAN data can make its way into the system in a way that the data protection vendor cannot control and no cleartext PAN data will ever be needed within the merchant’s data centers or retail locations.

Sadly, this is often not the case.  Vectors of PAN data into the enterprise can often be sanitized using custom software development (at additional cost and project risk), but the data egress path is often much more difficult to solve.

Imagine that all of the input PAN data is tokenized at the point of sale or other entry into the system (including CRM input, FAX/OCR input, Web Site input, etc.).    Now, the back end IT systems need to call out to a fraud detection service to ensure they should complete the transaction.

Commonly these fraud detection services do not accept encrypted or tokenized PAN data, but rather depend upon actual PAN data.   Now the enterprise openly needs PAN data in the data center to satisfy this new requirement.   PCI Scope is back in the data center.   Depending upon where in the architecture PAN data is actually needed, the entire data center may re-enter PCI scope.

Perhaps the bigger risk to change is in the case of a merger or acquisition.   Resolving one or more monolithic tokenization strategies with heterogeneous data centers and retail locations makes this problem nearly intractable.

Vendor and Bank Lock-In:

For monolithic scope reduction to function properly there needs to be close cooperation among at least the following entities:

1)     The Point of Sale Terminal vendor

2)     The tokenization or encryption software vendor

3)     The merchant

4)     The Acquiring Bank(s)

5)     The vendor(s) utilized for credit card authorization.

If any partnership among any of these critical participants breaks down, the entire system may fall apart.    What if the tokenization software vendor falls out with the point of sale vendor and the combined solution is no longer supported?    What if the merchant wishes to change Acquirer?

This fragility to change has the potential to put a merchant at a large disadvantage during negotiations with any of these partners for new equipment or contract extensions.

Tokenizing at the Data Center:

One of the more common solutions to the difficulties associated with monolithic tokenization is to tokenize at the data center.    This does leave the retail locations within scope, but can bring immediate value to the merchant rather than marginal value over a very large time frame associated with the Monolithic approach.   Often it is much less expensive up front (as there is no retail hardware and software refresh mandated).

There are two common approaches to tokenizing in the data center:

1)     API Tokenization

2)     In-lineTokenization

API Tokenization Explained:

API tokenization modifies existing systems to explicitly request token data from a tokenization vault when PAN data first enters the system.  This is typically implemented with a custom SDK or over SOAP based web services.  The system would reverse the process before outbound interface to payment gateway or to a payment processor.

Often a proxy server can be used on the front end of the web site to ensure that PAN data is tokenized before entry into Web Servers and that PAN data does not exist in at least some of the e-commerce server infrastructure.

For comparison purposes the architecture is unchanged from the previous example (including the fraud detection web service which requires PAN data).

Figure 3 shows typical PCI Scope for this retail architecture with API tokenization.   The e-commerce engine, the authorization engine and the clearing engine have been modified in order to explicitly request tokens and PANs as necessary.   Since all of them must have access to PANs (both for input and output for the clearing engine and authorization engine and for connection to the fraud detection web service in the case of the e-commerce engine) they are all within PCI Scope.

The scope reduction is small (the Web Servers and perhaps the E-Commerce engine may be removed from scope if there is no need for actual PAN data inside its bounds) as compared with the cost of the tokenization solution and the cost of modifying existing systems to explicitly request PANS and tokens. The downside of API tokenization is that each application that wishes to tokenize or de-tokenize data must be modified, typically with an SDK, which can mean additional development costs for the merchant.

In-Line Tokenization:

An alternative is to take a similar approach to tokenization at the data center with one subtle (yet very powerful) change.    What if instead of modifying existing systems to implement tokenization and detokenization, we simply add in-line proxies to the data flows that accomplish this same effect?

All back end systems still believe they are operating on PAN data, but actually work on tokens.   Data on the way into the data center is tokenized by the secure, high speed proxy and data on the way out of the data center (where PAN data is actually required) is detokenized by the same high speed proxy.

All of the back end data center systems fall from scope immediately.

Please see Figure 4 for an illustration of how In-Line tokenization reduces PCI DSS Scope.

Please note, this same proxy that tokenizes and detokenizes the data often decrypts the PAN data.  The proxy therefore can participate in PCI Scope reduction strategies at the retailer that involve encryption (symmetric or asymmetric) or other forms of tokenization at the point of sale.

This approach has many advantages over Monolithic tokenization:

1)     Much faster time to value.   In-line tokenization can be implemented in months rather than years and immediately begin reducing PCI Scope.

2)     Much less expensive:  No need to upgrade anything at the point of sale.

3)     Much more resilient to change:    There are no dependencies upon hardware or software at the point of sale or on specific financial partners (acquiring banks or payment gateways for example).

In-line tokenization is also superior to API tokenization:

1)     Much more scope reduction in the data center.

2)     Existing systems do not need to be modified as they do not change with In-line Tokenization.

3)     Much shorter time to value as it is much quicker to put an inline tokenization solution in place than to modify existing, business critical systems.

4)     Much less risk of breaking existing systems in the pursuit of saving money.

5)     Often In-line Tokenization solutions are much less expensive (even in terms of lower licensing costs) than comparable API tokenization solutions.

The same proxy that is used to tokenize and detokenize data can also transform data to other formats and other protocols.    This can be very important as during a merger, the proxy layer can make newly acquired stores appear to be the same as existing stores to the enterprise to the data center.   This same technology can make the data centers of the new owner appear to be the same as the old data centers from the newly acquired retailer.    This allows for very quick integration of newly acquired assets and for realizing economies of scale much more quickly after a merger.

In-line tokenization can also be used with existing bespoke tokenization solutions.   Instead of having the proxy make a tokenization/detokenization request to its internal service, the proxy broker can simply make a call out to an external service to perform these activities.

This approach of utilizing the proxy to call out to non-native tokenization can even be used with API tokenization products to give them the same advantages of native In-line tokenization (except perhaps the smaller price tag).

Conclusion:

There are two primary reasons most merchants evaluate PCI DSS tokenization options.

1)     To reduce the cost of PCI DSS compliance (as cost is directly related to scope)

2)     To decrease the risk of a data breach.

Given these constraints, we believe that the best option is often to begin at the data center where there is the most value gained with the least effort and then utilize this effort to inform the decision of how best to secure the points of sale.

I encourage you to read additional papers on the subject. At  cloudsecurity.intel.com , please consider downloading this popular paper describing how a service gateway can help reduce PCI DSS Scope.

Alternatively, you may enjoy watching Webinar: 3 Core PCI DSS Tokenization Models – Choosing the Right PCI DSS Strategy

Please reach out to me with any questions regarding that arise in your pursuit of a solution for reducing PCI Scope in your organization.

Next I will cover expanding the in-line tokenization concept to general in-line data protection for securing other forms of data including Personally Identifiable Information (PII) and Personal Health Information (PHI).

  Tom Burns serves in Intel’s Data Center Software group where he works with many of the world’s top retailers to help increase security and reduce PCI DSS Scope. Tom joined Intel in 2008 and holds a BSEE from Purdue University.

 

[i] Information Supplement: PCI DSS Tokenization Guidelines: PCI Counsel, August 2011 section 4.1

[ii] Information Supplement: PCI DSS Tokenization Guidelines: PCI Counsel, August 2011

Who is more sensitive – you or your data?

Sooner or later the following (not so hypothetical quandary) will undoubtedly arise: When moving your data to the cloud, you’ll be faced with an array of decisions that will need to be made. What considerations will you make for the protection of your data? In the not-so-distant past, you most likely invested a lot of time and resources into building “enterprise Ft. Knox” – a state-of-the-art, highly advanced and very expensive solution replete with several sophisticated gadgets, strategically positioned around the enterprise perimeter. You had a moment to breathe a sigh of relief, taking solace in knowing that no one could penetrate the fortress you built. You even went so far as to give yourself a pat on the shoulder, enjoying the moment.

Alas, the respite ended with a tap on the shoulder! The King, also known as the CIO, has informed you that the rules have changed! Apparently, when you were working hard building this impenetrable boundary around the edge fixing the exposure, he made a deal for the kingdom (in this case, your company), that expanded its territory. As a result, the short but life-changing edict is to move processing to a third-world country (in other words to the cloud). Gulp.

Medieval comparisons aside, the matter of fact is that your IT systems have been moved to the cloud – public, private, or hosted. With the stroke of a quill (or pen), the circumscribed limits of your perimeter have changed. Unfortunately, protecting your databases, processes, applications, app servers, web servers, systems, middleware, and back-end systems won’t work anymore, and as in most similar scenarios, you’ll have absolutely no control over them in a cloud environment. It’s highly likely that you won’t even know where things are even running most of the time.

The advantages of moving to the cloud cannot be denied, but the new paradigm-shift is not without headaches and real concerns that come with data privacy, security, auditing, compliance, residency (at certain times you can’t let the data leave certain countries for example), in addition to having to worry about being exposed to hackers on a 24×7 basis.

Now what? Well, there is an easy way to solve this problem. Instead of protecting all of the above, you can simply just protect your data instead. This is exactly where Intel cloud encryption/ data privacy gateways shine. We created these gateways a few years ago, keeping the ever-changing landscape in mind.

So how do we do it? Well, for starters, the Intel cloud encryption gateway is the ONLY solution that is available in multiple form factors – as an appliance, software and virtual. It can also be available as a hosted solution, through our partners if you should choose that option. Our appliances are not “virtual appliances” unlike competing vendors in the market. We provide a “true” appliance. This is imperative in the security field, especially when you need FIPS 140-2 Level 3 compliance in the government (or other highly secure environments like the healthcare) space. (As a side note, I recently read a competitors spec where that company claimed to “enable” you — so you could plug in and use FIPS 140-2 if needed. It’s not certain what they exactly meant or how to parse the finely nuanced language used in their advertisements. In contrast, we are completely straight-forward about our enterprise class capabilities. And, yes, we have that feature built in already.)

In addition, our appliance has a unique set of features that include: tokenization, encryption, Format Preserving Encryption (FPE), as well as others that will help ensure the authenticity, integrity, and validity of your data. That’s not all. What makes us unique is that our cloud encryption gateways are built to fit your current eco-system. This means that regardless of the protocol, identity system, logging system, monitoring system, or data/message type, we can encrypt/tokenize the data that is flowing in and out of your organization.

Let’s think about that for a second. You get these appliances, drop them in the line of traffic, do a few configurations, and you are done. Either you keep the sensitive data and send the tokens to the cloud, or alternatively, send the protected (encrypted) data to the cloud and keep the keys to yourself. This allows you to be compliant and mitigate your risk. There are no more long drawn-out IT engagements, nor nightmare filled sleepless nights trying to figure out what will happen when moving your sensitive data to the cloud.

This is really important where time to market (TTM) is the key. We can have you up and running and poised for being production-ready, in a matter of days (or even in a matter of hours as most cases call for). When making a decision, It’s also essential for your calculus to include ROI and TCO. When you buy a similar solution from someone else, make sure to ask yourself these questions: Will I have to spend hundreds of hours building this? How long will it take me to integrate this within my eco-system? We can get you connected with most existing enterprise systems such as logging, monitoring, auditing, middleware, identity systems, database, (web) services, and SIEM systems such as Arcsight/Nitro quickly. And you get the added advantage of having mobile enablement already built-in.

There’s one last note of chuckle I want to share. I saw a competitor’s blog suggesting that they are rated by Gartner, for tokenization and encryption gateways, and are rated “close enough”, to Intel & McAfee in this area. I just want to close this out by saying we are Intel-McAfee, and we thankfully don’t feel compelled to make similar associations with someone, just to bolster our viability or engender notions of greater stability. We genuinely care for our customers and know that we will be here for many years to come.

I encourage everyone to download a very topical paper on the subject regarding Intel Expressway Tokenization Broker:

 

Please contact me if you need more information. I’m more than happy to send you any additional information that you may need.

Andy Thurai — Chief Architect & Group CTO, Application Security and Identity Products, Intel

Andy Thurai is Chief Architect and Group CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Mobile, Big Data, Governance, Security, and Identity solutions for their major corporate customers. In his role, he is responsible for helping Intel/McAfee field sales, technical teams and customer executives. Prior to this role, he has held technology architecture leadership and executive positions with L-1 Identity Solutions, IBM (Datapower), BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 25+ years of IT experience.

He blogs regularly at www.thurai.net/securityblog on Security, SOA, Identity, Governance and Cloud topics. You can also find him on LinkedIn at http://www.linkedin.com/in/andythurai

Cost Effective PCI DSS Tokenization for Retail (Part I)

With PCI-DSS 2.0 compliance newly mandated and recent guidance on PCI DSS tokenization[i] this is an excellent time for merchants to review their compliance and PCI scope reduction strategies. One of the more common approaches to reducing PCI DSS Scope (and hence the cost of assessments and the associated costs of remediation) is to tokenize PAN data within the enterprise.

While this blog series focuses on tokenization within a retail environment, the approaches and results are equally applicable to any tier 1 or 2 merchant with a large investment in existing data centers.

Why Reduce PCI Scope?

Most, if not all, tier 1 and tier 2 merchants are already PCI compliant and view continuing compliance as a cost of doing business. Why would the merchant decide to change its IT infrastructure to reduce PCI scope?

To paraphrase the PCI DSS 2.0 Standard [ii], PCI DSS Scope may be defined as a set of all systems that store, transmit or otherwise have access to Personal Account Number (PAN) data. That is any system that accesses credit card data in any way (encrypted or not) is potentially within PCI Scope.

Since PCI Scope is the set of systems that must be evaluated by a Qualified Security Assessor (QSA) for compliance, the cost of an assessment is directly related to the size of the task (and therefore to the size of the PCI Scope).

The average assessment costs for Tier 1 merchants are $225,000 (with 10% exceeding $500,000 annually)[iii]. This only includes direct out of pocket fees to QSA organizations and does not include the time and resources that the merchant must apply to bring systems in line with the standard.

The largest and least predictable cost is in remediation of PCI inadequacies. As a result of the yearly assessment, the merchant often has a list of remediation activities and compensating controls that must be implemented in order to maintain compliance. Often these involve disrupting or upgrading existing systems or changing where in the network or on what physical servers systems may reside. The cost of this remediation often dwarfs the cost of the annual assessment and may be revisited every year.

As much of the standard is subjective and compliance is up to the discretion of the QSA, a determination of point in time compliance one year, is no guarantee of the same outcome in the following year (even with no or minimal changes to IT infrastructure).

So not only does a large PCI Scope mean a large assessment cost and potentially larger remediation costs, but additional risk to unplanned expenditures caused by IT disruption even for IT systems that change little between assessments.

In short, it is important to reduce scope as much as possible in order to reduce both ongoing costs and the risk of large, unplanned IT expenditures. One obvious strategy here is to reduce the risk as much as possible and ‘delete’ the data. Deleting the data may involve moving the problem to someone else, changing existing business processes to remove PANs, or relying on tokenization to shrink the PCI footprint.

Common Strategies for Reducing PCI DSS Scope

Common strategies for reducing PCI DSS Scope include the following:

1. Outsourcing all credit card processing and credit card handling to another vendor.
2. Eliminating all stored PAN data from the network.
3. PCI DSS Tokenization

The first option is by far the best at reducing scope. If handled properly there is very little or no PCI DSS Scope left for the merchant. This approach is not always practical for a variety of reasons including that existing IT systems could not accommodate the change and it is often preferable for the customer to enter into new transactions without re-entering credit card data. Moreover, large merchants often can’t change existing business processes that rely on PAN data, as it may involve re-training or re-deploying existing personnel or even changing the way business is conducted, if PANs are used for analytics or in other business functions such as CRM.

The second strategy often cannot be applied uniformly due to the saved credit card problem as described above and often data warehousing applications need a unique identifier to track purchases from an existing customer (perhaps to identify profitable and unprofitable transactions and customers). Since not every customer will be a member of a loyalty program, often PAN data is used to track customer activity.

The rest of this posting will concentrate on PCI DSS Tokenization

What is PCI DSS Tokenization?

PCI DSS Tokenization is a means for protecting credit card data by substituting a different, non-encrypted value for a credit card number. Usually this takes the form of random number (with some of the first digits and ending digits preserved) that appears to back end systems to be a valid credit card number.

It is important that the random elements of the token (that is the digits that are not preserved from the original PAN) are not in any way derived from the actual credit card number. [iv] The random number is stored in a secure vault, which defines the mapping from the PAN to the token.

If this is accomplished properly, the following results occur:

1) Any breach of documents with tokens rather than actual credit card data is useless to an attacker as the attacker does not have access to the token vault which stores the mappings.

2) There is no offline attack vector for deriving a decryption key and therefore compromising tokens.

3) Systems that only touch tokens and not actual PAN data may be removed from PCI Scope and are therefore not susceptible to the direct costs or remediation exercises for PCI compliance.

4) Systems that are thus removed from scope may now have past remediations and compensating controls removed in order to free up MIPS for business processes or in order to delay or eliminate the need for costly hardware and software upgrades.

5) Contrasted with encryption, tokenization does not incur a large key management problem at each system that encrypts and decrypts data – key management is centralized to the operation and maintenance of the vault alone.

Conclusion:

There are two primary reasons most merchants evaluate PCI DSS tokenization options.

1) To reduce the cost of PCI DSS compliance (as cost is directly related to scope)

2) To increase security and to drastically reduce the risk of a data breach.

Given these constraints, my colleagues and I are under the contention that the best option is often to begin at the data center where there is the most value gained with the least effort and then utilize this effort to inform the decision of how best to secure other parts of the enterprise.

In my next blog post, I’ll discuss three common architectural approaches towards data center tokenization.

While we continue to explore Tokenization, I encourage everyone to download a complimentary copy of PCI DSS Expert and QSA Walter Conway’s PCI DSS Tokenization Buyer’s guide available here

 

 

 

 

 

 

 

 

 

 

---

You are also welcome to peruse Intel’s solution for reducing PCI DSS scope by visiting the Intel Tokenization Broker landing page

 

 

Tom Burns serves in Intel’s Data Center Software group where he works with many of the world’s top retailers to help increase security and reduce PCI DSS Scope. Tom joined Intel in 2008 and holds a BSEE from Purdue University.

 

 

---

[i] Information Supplement: PCI DSS Tokenization Guidelines: PCI Counsel, August 2011

[ii] PCI DSS Requirements and Security Assessment Procedures, Version 2.0, Page 10 Section “Scope of Assessment for Compliance with PCI DSS Requirements”

[iii] PCI DSS Trends 2010: QSA Insights Report, Page 9 http://www.ponemon.org/local/upload/fckjail/generalcontent/18/file/PCI%20DSS%20Trends%20-%20QSA%20Insights%20010310.pdf

[iv] Information Supplement: PCI DSS Tokenization Guidelines: PCI Counsel, August 2011 section 4.1

Your personal data is now yours… maybe? by Andy Thurai

Recently the State of Alaska DHSS was fined a hefty sum of $1.7 million for non-compliance. This issue came to forefront when a USB drive containing PII (Personally Identifiable Information) data was lost (or stolen). This is not the first high profile incident in which stern action was taken by government agencies for someone losing or being careless with consumer data.

Recently, I blogged about how California declared zipcodes as PII and what you should do to protect the information you capture, regardless of whether it is credit card information, patient data, or electronic health records. http://soacloudsecurityblog.wordpress.com/2012/04/02/perfection-series-how-do-you-definemeasure-perfection/

It is not just about tokenizing your data, you have to make sure your logs, storage, and monitoring systems are clean too. If you fail to do that you can be found non-compliant, and when a compliance/ forensic analysis is done they look at all collateral repositories as well. I have previously blogged about being careful about leaving PII residue in your logs. http://soacloudsecurityblog.wordpress.com/2012/04/23/perfection-series-forgotten-data-in-your-logs-log-redaction-service/

Remember the classic case of employees going after Starbucks about their personal data being carelessly handled.  http://soacloudsecurityblog.wordpress.com/2012/04/09/you-too-seattle/

And we all know about FTC going after a data broker Spokeo for $800,000 to settle the FTC charges that it sold personal information gathered from social media and other websites to employers and job recruiters without taking steps to protect consumers required under the Fair Credit Reporting Act. http://www.networkworld.com/news/2012/061212-ftc-spokeo-260092.html?page=1

These are only a few examples of the revolution that is happening. For years we have had our data exposed, particularly personal information, and watched helplessly as our data was collected, sold, used, marketed to, abused and often stolen and circulated in the black market. Finally, the government and related agencies are stepping in to make a statement.

The core of all these issues stem from the fact that it is hard to fix the holes across your enterprise ecosystem. While you can continue to encrypt the data in as many places as you can, the human element still wins most of the time. And there is also the issue of encryption algorithm strengths or weak links in your process flow. That is why the newer model “tokenization” is becoming very popular. Especially since when you move your data applications and processes to the cloud, you lose a lot of control. Essentially when you lose control over the data trails, transport and storage i.e. – alerts, monitoring, logs, auditing, etc., compounded by the fact that you’re at the mercy of the cloud provider. This exponentially complicates your ability to figure out how vulnerable your data is, and thus could be very dangerous. Additionally, you need to know where all your data is flowing (or leaking). Especially if your data flows to an application instance, which is controlled by export control laws with stronger encryption exceptions as this could really mess things up. While you have to worry about using a stronger encryption to protect your data, you also have to worry about complying with export regulation laws.

Intel Tokenization solutions would be a perfect fit in such situations. Our PCI and PII tokenization allows you to strike a balance between both issues. You can keep your enterprise data encrypted and tokenize the sensitive data when it is sent over the wire to cloud locations, partners, etc. Given this fact, unless they are a whitelisted application, they won’t know where to go to get the original data. You can rest in peace knowing that while your sensitive data is sitting safe and secure, only your tokens are floating around everywhere.

If you are interested either in PAN tokenization or PII tokenization (such as SS#, DOB, etc) use the link below to check out our solution information and reach out to me if you need further details.http://cloudsecurity.intel.com/solutions/tokenization-broker-reduce-pci-scope

Also, check out this whitepaper by Walter Conway, QSA, who is an expert on this subject.

Andy Thurai — Chief Architect & CTO, Application Security and Identity Products, Intel Andy Thurai is Chief Architect and CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Governance, Security, and Identity solutions for their major corporate customers. In his role, he is responsible for helping Intel/McAfee field sales, technical teams and customer executives. Prior to this role, he has held technology architecture leadership and executive positions with L-1 Identity Solutions, IBM (Datapower), BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 20+ years of IT experience. He blogs regularly at www.thurai.net/securityblog on Security, SOA, Identity, Governance and Cloud topics. You can find him on LinkedIn at http://www.linkedin.com/in/andythurai.

Internal Tokenization Business Benefits

We’ve had a lot of interest in the tokenization broker lately. Read on as Product Manager Blake Dournaee shares some of the interesting use cases that are popping up in the field.  He also gives clarity to the definition of internal tokenization, which is becoming an important selling point in the market.

We are in the context of PCI DSS, and by tokenization, Blake talks about the tokenization of credit card numbers or PAN data with format-preserving tokens. The use cases we are seeing revolve around replacing PANs in documents, files or API calls with tokens, mainly for the purpose of reducing the scope of a PCI audit as well as reducing the chance of a breach.

His blog post can be found here.

You can also learn more about Intel Expressway Tokenization Broker by visiting our dedicated landing page, downloading a white paper, watching a webinar and exploring other areas of www.dynamicperimeter.com.

You can even access a trial of Expressway Tokenization Broker.

A Solution for Addressing Network Security & Dramatically Reducing PCI DSS Scope with Gateway Tokenization

Version 2.0 of the PCI Data Security Standard takes effect on January 1, 2011. Are you fully prepared for the upcoming changes? Can your company avoid non-compliance fines of up to $500k per incident?Join us  for an overview of planned changes to the PCI DSS Standard and pros and cons of available technology solutions. Find out how Security Gateways offer ideal solutions for handling internal tokenization when maintaining ownership and controlling PAN data are primary organizational concerns. Speakers will demonstrate how Security Gateways offer effective alternatives to outsourced solutions that can be impacted by token migration and card processor lock-in concerns.

Register here. for this 1 hour webinar on December 14th taking place at 1pm Eastern