During my presentation on tokenization at the Boston Application Security Conference I mentioned repeatedly that the application that calls the tokenization process should not have the ability to de-tokenize. This is important because, increasingly, this system is going to be closer to the initial point of data capture. In the case of an e-Commerce site this means closer to the consumer, like a public-facing web application. A publicly accessible web application should not have the ability to directly access a full credit card number after a transaction has occurred. And when I say ‘ability’ I mean that the functionality or code to accomplish this cannot be implemented and no connection to a system that could provide access to a full card number should exist. It is not sufficient to simply limit this type of activity to a privileged user or process running on this system if you truly want to realize the full benefit of tokenization.
I also made the point during my presentation that the applications that your typical internal users have access to should not have the ability to de-tokenize, access decryption keys, or even access the encrypted data. Any of these applications that your internal consumers have access to should only have access to the token value. The intent of tokenizing is to reduce the storage and the use of sensitive data across the organization, therefore reducing the attack surface and liability of protecting that data. If you are limiting the access to the de-tokenizing process that is running on the same system that all of your users have access to then you are completely dependent on this access control configuration. That entire system remains in-scope for the storage of the original sensitive data because this capability exists.
The best way to summarize these points is to think about the tokenization process as “checking in” sensitive data. Remember the Roach Motel ads? In this case, sensitive data checks in – but doesn’t check out (to your standard user or system). For those exceptions to this rule, users that must have access to the sensitive data directly, they should be provided with access to systems and data in a method that is out-of-band and requires strong authentication, authorization, and auditing.
Posted via email from ken5m1th
No comments:
Post a Comment