Then they took down another BIG one

I have been sitting on this blog/thought for awhile but it became timely now with the Global Payments breach yesterday (Reported first by Brian Krebs on his security blog). Global Payments is a merchant acquirer, with contracts with retailers to handle the processing of card transactions (cc, debit cards, gift cards of all brands). Though the information is premature and not complete, it is estimated that they lost about 10 million+ accounts. Though Global specializes in mom-and-pop shop transactions, the company itself is very well established ($167 Billion worth of transactions last year alone). This breach happened in spite of having a decent security measures in place. What is worse is that the data stolen is full track 1 and track 2, which means using that stolen data one could easily reproduce counterfeit cards. (So, you better watch out for those unauthorized charges in your account – it is hard to dispute a transaction when someone swipes a card unless you catch it early – know it from personal experience).

You see the problem lies in the whole complex payment systems that were developed years ago for payment transactions. On those days security was not on everyone’s mind. Partly that is because most of these systems ran on private networks (and leased lines) and the hackers those days were not that savvy. It is sad, but true, that it is much cheaper for the companies to deal with the breaches than to make their systems more secure. You might recall a serious breach with Heartland Payment systems about a couple of years ago, where they lost about 130 million cards. Last year hackers stole payment card information for more than 100 million customers of Sony’s PlayStation Network. In between these, multiple smaller breaches that went un-noticed.

So if you are a security architect and are wondering how can I safe guard my company from such disasters; we here at Intel can help you. While we have many solutions that can help you, I am going to talk about a particular solution, our Tokenization Solution – Token Broker (TB).

A few years ago, PCI-DSS released a new directive that opened the door for a new concept called tokenization. The issue with dealing sensitive data is that you need to hide it somehow. It was done by encryption up until a few years ago. While encryption solution is very good for what it does, the surrounding issues became a major issue (key management, key rotation, encryption strength, etc). If the hacker catches the transaction in flight, or hack in to the systems and catch the transaction in memory/ process (where the data might be in clear) the issue becomes deadlier. In order to avoid that, PCI-DSS released a directive (and updated it late last year PCI DSS 2.0 Aug 2011) about tokenizing the PAN (Primary Account Number) information. At the heart of this directive is the fact that if you create a true random token (i.e., format preserving surrogate) there is no way that a hacker who intercepts the message can get the original information back. Hence there is no monetary value if someone captures the token in flight or from storage.

Essentially we have these hardened proxy Token Brokers that you can either slide in front or back of any application (we do support almost all standard protocols and data formats) that can sit in line of traffic and do these tokenization actions. This means essentially very little or no work is required on the applications/ API/ services side. By sliding our proxies in line of traffic you can ensure all the channels are secure and no one can sneak in without our knowledge.

An application needing original data can come back to our TB and ask us to provide them with the original data. This can be either a side call (as in a call to an API to reverse the data) or in line reverse translation, so the receiving application will receive the original data without a need for modification. Only the needed applications (or the proxies) know where to go to resolve the token. That application needs to be white listed with us (not just everyone can ask us to do the dirty job even if they know where to go). The connection can be made as a 2way mutually authenticated SSL to establish the identity of both sides and make sure the information travels end to end secure.

Tokens are stored in a Hardened database which is nearly impossible to breach and only the TB can connect to. All the communications from TB to DB is secure and the DB has a white list of only TBs that it can connect to.

In short by using Intel Token Broker (TB) solution you get,
• Storage and processing using surrogate data and not the original data.
• Format preserving tokenization allows to preserve parts of Pan information for internal purposes.
• Can handle any form of data. Can handle MS word, Excel, PDF or any other form of document.
• Our solution comes with all kinds of security certifications (CC EAL 4+, FIPS 140-2 Level, etc)
• Allows you to secure the perimeter, secure the edge, secure the API.
• Reduce PCI scope, Protect Card Holder data,
• Can work anywhere within enterprise, extended enterprise, including partner locations, virtual environments such as in the cloud.
• Can be in DMZ due to hardened appliance form factor.
• Reduces annual assessment costs.
• Helps with compliance issues.
• Hardware based random token generator.
• Full disk encryption, database storage encryption, Secure Boot/ BIOS, Tripwire, snooping block

A sample high level enterprise data flow with the original dataflow highlighted in dotted red to show how easy it is to slide a proxy in line to handle all transactions regardless of data format, protocol or security type.

If you are interested either in PAN tokenization or PII tokenization (such as SS#, DOB, etc) use the bottom link to check out our solution details and reach out to me if you need further details.
http://software.intel.com/en-us/articles/Expressway-Tokenization-Broker-Reduce-PCI-Scope/. Also, check out this whitepaper by Walter Conway, QSA, who is an expert on this subject.

Hope we can help our customers protect one enterprise at a time so these things won’t happen in the future.

Advertisements

About Andy Thurai
This blog is published by Andy Thurai, Program Director - API Economy, IoT, Connected cloud solutions with IBM. The views expressed here are my own and not of my employer. Please feel free to comment or engage in a stimulating conversation, but please keep it professional. I can be reached via the “Contact Me” page here. You can also find me on LinkedIn or on Twitter @AndyThurai

One Response to Then they took down another BIG one

  1. Pingback: Follow-up on Global Payments breach « SOA, Mobile, Cloud, Identity & Security Blog @AndyThurai

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: