The Falcon's View

Not Really "Game-Changing"

This solution is not really very different from what we have today. It's a subtle variation on current tokenization solutions. The tokenization itself still happens the same way. The gateway component is still present. The cardholder data is still being stored somewhere. What's really different here is that, rather than requiring use of a redirect or an iframe or an API call to get cardholder data out of a merchant's environment, it is instead being intercepted mid-flight by Akamai, who in turn tokenizes it through the gateway and then passes the token on to the merchant.

There are a couple things happening here that are very noteworthy:
* De-SSL Interception: Akamai is intercepting the SSL-wrapped connection from the customer to the merchant, breaking (or, terminating) that connection a la an SSL proxy. That is to say, though you as an end-user might think that you have a secure SSL connection end-to-end to the merchant, this isn't actually the case. Of course, this also isn't new for Akamai, which has provided this service to customers for a while. One open question here is whether or not the connection from Akamai to the merchant is using SSL. Technically it's not required by PCI DSS since there isn't cardholder information. However, one would hope a new SSL connection is instantiated to protect the rest of the session.
* Transparent Tokenization: Rather than requiring merchants to embed code into their site, or to redirect to the gateway, the cardholder data is simply being transparently captured and tokenized in-flight. This is really a rather remarkable feat considering one must assume the tolerance for performance impact is very low. So, not only is the SSL connection being terminated early, but the card value is grabbed, tokenized, and then the connection is restarted to the merchant site using the tokenized value rather than the real card data.

Transferred Risk, Not Improved Security

One issue that arose in conversation on Twitter yesterday while discussing the solution was a bit of term confusion. This solution provides a mechanism for merchants to transfer the risk of managing cardholder data to someone else. Interestingly, it's not clear who they're transferring the risk to, or what sort of contractual coverage will be in place. One might think at first blush that Akamai is shouldering the new risk burden, but that's only partly true, and probably not as much so as you might think. Really, it seems that their gateway partner, CyberSource, ultimately bears the brunt of the transferred risk, since they're the ones who will be storing cardholder data.

What I think is important to note here is that, more than mere semantics, there is a fundamental difference between transferring (or reducing) risk and improving security. This service does not make merchant systems or applications any more secure. It merely reduces the exposure of cardholder data (and, really, just the credit card value - the merchant's payment system will remain in place, complete with customer data). The question I asked of Akamai CSO Andy Ellis yesterday was "does this make merchants any more secure?" The answer here is a definitive "no." Yes, merchants are reducing their own risk burden, but this solution does not make them any more secure.

At the same time, depending on how the contracts are written, there's still a possibility that the risk transference won't be complete. This is a topic for lawyers to hash out in painful detail, but it's something that nonetheless needs to be considered. If your contract, as a merchant, is with Akamai, then will you also have a contract with CyberSource? Be careful how you answer, because you're still technically covered by PCI DSS, and thus still need to make sure your 3rd party providers are also compliant!

Still Subject to PCI DSS Reqs. 9 & 12 (?)

One of the arguments made in favor of fully outsourcing payment card processing is that it eliminates all your responsibilities and exposure under PCI DSS. However, I'm finding that hard to believe given the documentation that the PCI Council makes available. Case in point, consider the following explanations for the different types of Self-Assessment Questionnaires:

Based on those definitions, it would seem that users of Akamai's EdgeTokenization solution - or any other outsourcing solution - would still be required to complete the SAQ A. The PCI Council seems to be very particular about who can complete the SAQ A, based on this:

However, given these two blocks of text, it seems fairly clear that, per SAQ A, merchants are still required to comply with certain parts of Requirements 9 (Restrict physical access to cardholder data) and 12 (Maintain a policy that addresses information security for employees and contractors). In fact, 12.8 is specifically focused on managing third-parties to whom card processing is outsourced. The introduction to PCI DSS itself seems fairly clear on this matter:

"For those entities that outsource storage, processing, or transmission of cardholder data to third-party service providers, the Report on Compliance (ROC) must document the role of each service provider, clearly identifying which requirements apply to the reviewed entity and which apply to the service provider. There are two options for third-party service providers to validate compliance: 1) They can undergo a PCI DSS assessment on their own and provide evidence to their customers to demonstrate their compliance, or 2) If they do not undergo their own PCI DSS assessment, they will need to have their services reviewed during the course of each of their customer's PCI DSS assessments. See the bullet beginning “For managed service provider (MSP) reviews” under Part 3 in the “Instructions and Content for Report on Compliance” section below for more information.

"Additionally, merchants and service providers must manage and monitor the PCI DSS compliance of all associated third parties with access to cardholder data. Refer to Requirement 12.8 in this document for details."

I'm not a QSA, nor do I work for the PCI Council, nor am I a merchant (any more), but this all seems fairly straightforward to me. Does outsourcing drastically reduce the compliance burden? Yes, absolutely. However, it does not eliminate it altogether, despite assertions some have made to the contrary.

Leaking Secrets?

Historically, we've not known much about how Akamai functions. They've been very good at keeping a low profile, all the while providing a considerable portion of Internet backbone. If you were to dig, I think you'd be surprised to see just how much traffic ends up going to Akamai instead of the site you think you're visiting. This latest product, however, pulls back the curtain a bit and gives insight into what is potentially a bit creepy. If you've been concerned about how much data Google has on us all, then consider how much data Akamai has access to (whether they're keeping it or not).

As noted, they're intercepting SSL communications, terminating it on their networks on behalf of their customers. It's unclear if that SSL connection is then restarted, or if the back-end calls are in the clear. As much as we've been told to use SSL everywhere, this raises a potential concern about it's effectiveness. In fact, one could go so far as to decry SSL as a scam perpetrated on the masses given how easily it's being broken down.

It's also somewhat ironic the furor over federal officials who want to break Internet encryption. From a NY Times article yesterday:
"Federal law enforcement and national security officials are preparing to seek sweeping new regulations for the Internet, arguing that their ability to wiretap criminal and terrorism suspects is “going dark” as people increasingly communicate online instead of by telephone."

Not to point out the obvious, but if I were these officials, I think I'd just buddy-up to companies like Akamai in order to gain surreptitious access to data. Imagine US-CERT's Einstein Program sitting on Akamai's backbone. Hmmm... and yet where's the concern over what Akamai does as part of their standard business practices? At least the federal government is subject to certain legal constructs (like the US Constitution).

What this raises for me is a potential red flag around privacy. It would be interesting to have insight into how data access is being used, particularly with respect to national security requests, broad Internet traffic monitoring, and the like. I don't say this to stir the pot, per say, but because it's interesting to me what gets people in a twist. As a society, we seem to worry about government intrusion while overlooking corporate intrusions like frequent buyer programs, Google analytics, Facebook privacy management, and so on.

More Enablement Culture

The last point that I think bears highlighting here is the continued expansion of the enablement culture. One of the key problems facing the IT and security industries today is that the decision-makers are generally far removed from the results (consequences+impacts) of their decisions and actions. Users click on links in spam that result in infections and in swoops IT to magically fix it. Sure, we send people to annual awareness training, and we give them cutesy trinkets, but in the end very little difference is made.

Solutions like EdgeTokenization seem to bring to mind a larger variation of this problem. To my original question to Andy Ellis, this solution does not make these merchants any more secure. Instead, it transfers the risk to another organization on the premise that this third party is much better prepared to manage that risk. Unfortunately, because it does not improve security around the system, it merely gives the illusion of improved security. Reduced risk is not, however, the same as better security. Here's why...

In the world of FAIR risk analysis, risk has two (2) main components: loss event frequency (LEF) and loss magnitude (LM). LEF is further broken down into threat event frequency (TEF - comprised of Contact Frequency and Probability of Action) and vulnerability (Vuln - comprised of Threat Capability and Resistance Strength). In the case of EdgeTokenization, risk is reduced in two key areas: TEF and LM. That is, the likelihood that a threat agent will attack seems to decrease (maybe) because the cardholder data is no longer present. At the same time, even if a threat agent does attack, the correlated Loss Magnitude should be significantly lower, with a most likely scenario being slight reduced primary costs, and much lower secondary costs. Which is to say that the financial risk borne by the merchant should be lower by virtue of not having as much "data of value" in their potentially-compromised environment.

What's important to note here, though, is that at no point does Resistance Strength improve/increase. EdgeTokenization does not improve the relative security of the payment card system (or, CRM system as the case may be). At the same time, switching to EdgeTokenization (rather than wholesale outsourcing the entire billing/payment platform) will almost certain de-emphasize the environment, likely reducing the security investment made in protecting it. Without the requirements of PCI DSS, what's the likelihood that these systems will be secured at all? Moreover, I have to wonder if implementing this solution would undermine the need for buying a PA-DSS certified product, since you're no longer dealing directly with cardholder data? You could then continue to use a really awful platform like Platypus since it's not required to meet full DSS compliance. This scenario is but one example of the enablement culture created that literally discourages applying much, if any, security consideration to what are actually rather important systems.

To summarize, and expand upon, this section, consider the following cases where the enablement culture is expanded:
* Merchants feel less pain: As already discussed, solutions like EdgeTokenization do not improve the security of their environments, but does reduce the risk. In effect, merchants will now feel less pain in the case of a compromise, even though the degree of compromise can be as severe as before. Card values may not be compromised, but customer information probably will, not to mention the impact of having servers compromised in general. However, the likelihood of fines and judgments is greatly reduced. The reduced likelihood of meaningful consequences in the face of bad things happening is no incentive for improvement.
* Broken system sustained: I'm particularly concerned that this solution furthers this broken payment card system in a way that is tangible and useful to the card brands, but without really doing much to save the world (so to speak). I hope that Akamai makes a ton of money off this proposition, but I also suspect that the card brands aren't necessarily paying for it even though they stand to benefit handsomely. Then again, maybe Akamai is being quietly funded for this project by the PCI Council...
* Continued promotion of credit and consumerization: This is more an economic and political issue, but the current state of the American economy is due in large part to the extreme binge of credit-based spending and consumerization that has devoured us whole. Anything that continues to make these problems worse rather than better is vexing, though in a philosophical and ethical manner.

The bottom line here is that I grow tired of security professionals and the security industry producing solutions that remove a clear connection between actions/decisions and the resulting consequences and impact. All responsible parties should feel pain when bad things happen as a result of their decisions/actions. Unfortunately, we live in a paternalistic period where big brother (not always the government, btw!) steps in to help shield us from negative impacts.

A poignant comment from Andy Ellis was to point out the parallels in my concerns with the Peltzman effect, which is described on Wikipedia thusly:
"The Peltzman effect is the hypothesized tendency of people to react to a safety regulation by increasing other risky behavior, offsetting some or all of the benefit of the regulation."

I think we are already seeing this effect in play, and it worries me that the more we abstract merchants from their security responsibilities, the more likely it is that they'll run poorly secured systems that can be compromised at the drop of a hat. Putting this into a broader national security context, this is not a good thing. I'm happy Akamai is helping get cardholder data out of the hands of merchants, but I maintain serious concerns about the particular method. Also, mark my words: a class breach of tokenization solutions will come some day. When that happens, how will we respond? How will we view this solution then?