When we wrote our first PCI application security article Who's Guarding the Data Bank? in 2008, commercially available cardholder tokenization was in its infancy. Generally speaking, data tokenization usually refers to a process through which cardholder data (usually the Primary Account Number or PAN) is replaced with a substitute cyphertext value known as a token.
The token is typically generated via a strong, one-way publicly known mathematical hashing algorithm. If the one-way cryptographic algorithm is suitably strong and utilizes a known publicly validated mathematical algorithm, the resultant cyphertext is no longer considered to be cardholder data as defined by the PCI SSC. It does not require additional obscuring or encryption as the process cannot be reversed to reconstitute the original data (in this case the PAN) short of a brute force ‘dictionary’ based attack. If, however an attacker has access to both the truncated version of the PAN (for example 400000xxxxx67891) and the hashed PAN, then recreating the original PAN becomes easier. This is noted in section 2.3 of the PCI PA-DSS v3.1:
It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are generated by a payment application, additional controls must be in place to ensure that hashed and truncated versions cannot be correlated to reconstruct the original PAN.
Extra protections should be incorporated to ensure that applications further enhance the security surrounding tokenization of cardholder data as well as authentication credentials. For example, you should restrict application access to both the truncated and hashed versions of the PAN. The cryptographic strength of the token can also be further enhanced if needed by adding initialization vectors or values to the tokenization process (sometimes referred to as ‘salting’.)
In 2015, tokenization is ubiquitous and a useful method to use to reduce the scope of your PCI compliance efforts. The good news is that every major payment processor offers a tokenization solution for its merchant customers.
One of the challenges though is that there isn’t any industry-wide and accepted standard for tokenization. This leads to the situation where some vendors have their own proprietary method for tokenization. Notwithstanding, the benefits of tokenization outweigh the lack of standards.
It’s also important to note that while tokenization can take a lot of sensitive data out of scope, it does not replace the requirement to encrypt unprotected cardholder data in both storage and transmission. Some vendors are actually only storing the tokenized PAN along with the last four digits of the PAN following transaction authorization which helps to further reduce compliance scope for merchants.
Many payment applications are cloud based or use cloud services. Cloud computing introduces a new set of security concerns.
Early in the article, we noted that banks were robbed since that’s where the money is. Cloud providers are a target for attackers since they have petabytes of data.
Cloud systems and their interfaces can be exploited just like any other system, be it from cross-site scripting attacks (XSS) and cross-site request forgery (XSRF) or injection based attacks (SQL, XML, etc.).
While the cloud has its benefits, it’s only as secure as you make it. As recent as last week, over 1.5 million medical records were breached on Amazon Web Services. The names, addresses, and phone numbers, along with biological health information including existing illnesses and current medications, were posted in the clear to Amazon S3 storage servers. These could have just as easily been credit card numbers.
It’s also imperative to realize that just because a cloud vendor offers up a PCI certified environment; it does not mean everything you build on top of it will automatically be in compliance with the PCI DSS or PA-DSS requirements. It’s important to know that the vendor only is PCI certified to the demarcation point and to the extent of the services being provided. PCI compliance of shared hosted applications and environments is still the responsibility of the application implementer, i.e. - still your PCI headache.
Application security action items
Due to their external public-facing (Internet) nature, web applications are a primary target for attacks and resulting data breaches.
When it comes to ensuring application security, it’s a formidable task. But you can go a long way in just doing the basics. Some action items are:
- Take a holistic approach to application security - when creating an application security program, don’t initially focus on specific vulnerabilities. Rather take a strategic approach to application security. Ensure that good application security practices are in your firms DNA and built into all aspects of the software development life cycle (SDLC.)
- Don't DIY – In today’s agile development environments DIY might take too long. Look to bolster your application development security through additional secure code training (when dealing with application security, there are tremendous resources available in OWASP, NIST, W3c, etc.), the use of automated code and vulnerability assessment tools, and even outsourcing to remediate critical deficiencies.
- Address basic security flaws – focus on the core OWASP Top 10 vulnerabilities list to address the main web application vulnerabilities. Also keep in mind that the OWASP Top 10 includes general security vulnerabilities as well. Ensure your developers know how to code against things such as SQL injection, insecure cryptographic storage, cross-site scripting, cross-site request forgery, broken authentication and session management, insecure direct object references and more.
- Test earlier in the life cycle - a mistake some firms make is starting software security testing too late in the life cycle. Testing earlier can find mistakes earlier and minimizes post-development bug-chasing and regression testing.
- Incorporate application risk assessments-threat modeling – comprehensive application threat modeling is a new requirement for PA-DSS, and can provide invaluable insight into whether application coding and QA-test procedures address all possible vulnerabilities for even non PA-DSS applications.
- Create secure coding guidelines and functions - create secure coding guidelines and have a list of approved or banned functions
It’s undeniable that it is cheaper and more effective to eliminate security flaws earlier in the development life cycle than later. Implementing application security measures is not only a PCI compliance requirement; it’s also a best practice.
Review and revise your secure SDLC process to address the new PCI requirements which have significantly raised the bar for application security requirements. Traditional ‘layers of defense’ approach to Information Security coupled with robust, and threat resilient application architecture will help to reduce the instances and proliferations of overall data compromise.
Ben Rothke CISSP PCI QSA is a Senior eGRC Consultant with Nettitude, Inc. and the author of Computer Security: 20 Things Every Employee Should Know.
David Mundhenk, CISSP, PCIP, QSA (P2PE), PA-QSA (P2PE) is a Senior Consultant for the Application Validation team at Coalfire Labs.
This article is published as part of the IDG Contributor Network. Want to Join?