One typical question NetSPI receives from IT managers is “What does PA-DSS entail?” Hopefully, this will give you some answers.
PA-DSS
PA-DSS is a set of security practices and requirements developed by the PCI Security Standards Council to “…enhance payment account data security by driving education and awareness of the PCI Security Standards.[1]” The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data, and ensure their payment applications support compliance with the PCI DSS. Payment applications that are sold, distributed or licensed to third parties are subject to the PA-DSS requirements.[2]
By ensuring the compliance of your application with PA-DSS requirements, your company helps facilitate its customers’ PCI DSS compliance.
NetSPI’s Answer
NetSPI has developed a program guide to assist your company in getting payment applications validated. This guide prepares a company to get ready for the audit and allows them to better understand the requirements of the different pieces of the audit. These include the documentation requirements for the implementation guide, troubleshooting procedures, SDLC documentation including change control, vulnerability and software patching procedures and the training materials that are required. It also goes into the topic of the interviews that will occur as well as the testing of the application.
What the program guide does not do is tell the different people in the company what is expected of them before the audit, during audit and after the audit.
This validation process can be simple and easy or it can be long and tedious. Work with your auditor to get through the process, they have the experience to get you through the process.
Before the Audit
As a manager, there are processes that have to be planned for and started before the auditors come into your office to start the audit process. The application has to meet the PCI requirements, which include:
Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data
Protect stored cardholder data
Provide secure authentication features
Log payment application activity
Develop secure payment applications
Protect wireless transmissions
Test payment applications to address vulnerabilities
Facilitate secure network implementation
Cardholder data must never be stored on a server connected to the Internet
Facilitate secure remote software updates
Facilitate secure remote access to payment application
Encrypt sensitive traffic over public networks
Encrypt all non-console administrative access
Maintain instructional documentation and training programs for customers, resellers, and integrators
In addition to the application requirements, the documentation has to also be ready.The list of documentation includes:
Implementation guide – The most important document without which testing cannot start
Typical network deployment diagram and data flow diagram
Documentation of remote transmission of cardholder data, such as IPSec, TLS, SSL
New security vulnerabilities identification process/policy documentation
In many instances, use of specific language within policies is required. For example, the implementation guide requirements include required language, such as “Historical data (magnetic stripe data, card validation codes, PINs, or PIN blocks) MUST be removed for PCI compliance.” This wording is required by the PCI Council and if not included, can provide sufficient grounds for the rejection of the Report on Validation (ROV). NetSPI’s PA-DSS Program Guide has been developed expressly with intent of showing such working requirements.
As shown in the list above, documentation requirements are not limited to the implementation guide and need to be completed before a ROV can be filed. It’s not enough to have processes in place, such as the security coding standards; they need to be formally documented. Make sure to review the documentation requirements to make sure they are up to date.
The last but far from the least important part of the pre-audit process is to educate your employees on the PCI Council’s requirements for a payment application. They need to know that these requirements are not an optional part of the application and that they may be interviewed during the course of the audit. All team members should be familiar with established standards such as the SDLC documentation as well as be aware of the troubleshooting requirements as described in the process documentation.
Next Steps
The next blog entry will talk about what to expect during and after the audit.
Part 1 of this series discussed the limitations in the recommendations provided by Visa in their Tips and Tools for Small Merchant Businesses – 2010. This section will explore the limitations to keep in mind when working with Level 4 merchants and provide recommendations regarding their approach to complying with the PCI DSS.
Level 4 merchants have several “facts of life” that should be kept in mind when making recommendations for complying with the PCI DSS:
1. Level 4 merchants are in level 4 because they don’t have as many transactions. In general, this also means that they don’t have the extra capital to dedicate towards PCI compliance. Some of the standard spending at Level 1 – 3 merchants that Level 4 merchants will have a harder time with include:
a. Additional recurring costs, such as the charges from some vendors for tokenization
b. Costs for procuring additional hardware to become compliant
c. Costs for IT help to implement IT changes/hardware
d. Costs for QSAs (or other knowledgeable resource) to guide them through compliance
2. Level 4 merchants may not have the knowledge to interpret and/or apply the requirements in the same way levels 1 – 3 are able to. Level 4 merchants run leaner than larger merchants. This means they do not have people that specialize in various areas that can help them out. If they have an IT person on staff, they are likely a “generalist” with knowledge an inch deep and a mile wide. Others may only have an IT person that visits weekly or even less frequently.
3. Having less money and fewer resources, the amount of time a Level 4 merchant is able to dedicate to PCI compliance will be minimal.
The approach that Level 4 merchants should take towards compliance should begin with an effort to minimize their footprint. Previously that meant segmenting the network; however there are additional steps that should be taken beforehand:
1. Review the current business processes to determine if it is possible to accept cards in a different way in order to minimize the compliance footprint. Taking the approach of trying to have the smallest footprint, we’ll start at the lowest level.
a. Is it possible to outsource the credit card activity? Some business processes can be outsourced to a vendor fairly easily. When providing a service through a vendor, such as a cafeteria, it is important to ensure you are not in the position of providing security for them. Dropping in a separate network connection for which they have complete responsibility will remove any question as to who is responsible for the security of their network. If this is possible, you may be able to fill out the SAQ A!
b. Will a stand-alone credit card terminal that operates off of a Centrex line meet the throughput needs? Often times a business owner or manager may upgrade to a network-based terminal or an integrated solution for efficiency gains but, when compared to complying with the PCI DSS, the gains may not be worth the cost. To remove any grey lines that might bring other systems into scope, you should ensure the analog line does not go through existing telephone or network equipment.
c. Does the system tokenize the full cardholder account number? A Level 4 merchant typically has to rely on what the vendor is saying about their software, as there is no field in the software validation list that identifies if the application stores card numbers or not. This can be problematic, and vendors that service Level 4 merchants are all over the board regarding how well they understand PCI. Sadly, there are some vendors that are still not aware of their responsibilities for protecting cardholder data. I was recently discussing an application with one vendor that stored encrypted cardholder data at the customer site yet insisted that the customer could fill out a SAQ C.
2. After making the business decisions regarding how business processes will accept credit cards, the traditional segmentation can be pursued. As most QSAs know, this is an area that causes a lot of questions, even within the QSA community. For a Level 4 merchant, this will likely be an area that they, along with everyone else, will continue to struggle with until further clarifications come out. Vendors offering turnkey solutions could make this process easier by offering an entire environment customized for their solution (e.g. including a firewall).
While not all encompassing, these steps should help Level 4 merchants minimize their PCI footprint and also minimize overall compliance costs and complexity.
In September Visa released a document, Tips and Tools for Small Merchant Businesses – 2010. The title implies that this information will be useful for Level 4 merchants; however, I believe this guidance still falls way short. It is a high level summary of the requirements, but it doesn’t give any real actionable recommendations that decrease cost. For example:
Visa’s Recommendations:
Don’t store cardholder data that is not needed to run your business: While I do agree that the suggested approach of tokenization will help, it will likely increase the cost to the merchant for this extra service. As a solution it would move a merchant from a SAQ D to a SAQ C, but they may be able to move to a SAQ B or even a SAQ A with a different approach.
Ensure all printed copies containing cardholder account number… are physically secured: What does “physically secured” mean to a small business owner that has no security experience? I think many QSAs can relay stories of individuals that stored cardholder data on their desk and considered it physically secure because it was within their work environment.
Know who has access to your business computers, including any vendors… make sure they are protecting that information: Again, what does “protecting that information” mean to a small business owner that has no security experience? The entire information security community is trying to do this with limited success. In general the small business owner will ask their vendor if they are secure. This vendor, quite likely another small business with similar limitations, provides the answer that is expected: “Yes.”
Destroy any physical or electronic records containing full cardholder account numbers… responsibly. Once again, what does “destroy it responsibly” mean to a small business owner that has no security experience?
If you use a computer… make sure you have an anti-virus program installed and it is updated regularly: Many people don’t even know that there is typically an annual renewal for anti-virus and don’t know how to check if it’s being updated. This is an easy task for the computer literate, but it may be a challenge for many small businesses.
In short, recommendations 2 – 5 just restate a few of the requirements but provide very little real guidance. Recommendation 1 does provide some guidance, but ignores a couple of the key issues with smaller businesses: 1) generally, they don’t have the extra money to pay for another service and 2) they don’t have the vocabulary/knowledge to engage in the conversation about tokenization.
In part 2, I will explore the limitations to keep in mind when working with Level 4 merchants, and provide a few recommendations regarding their approach to complying with the PCI DSS.
In continuing with my series addressing common compliance hurdles relating to Payment Card Industry (PCI) requirements, I would like to turn to the topic of data retention. Surprisingly, I have found that many organizations struggle with data retention – not just managing and archiving credit card data but even defining appropriate data retention policies. There seems to be a lot of misinformation or at least misunderstanding out there so hopefully this will help clear things up a bit.
Requirement 3.1 of the PCI Data Security Standard (DSS) states that cardholder data storage must be minimized and a policy defining the appropriate retention length must be defined. There may be legal or regulatory requirements relating to data retention that must be adhered to. However, in most circumstances, documents containing full primary account numbers (PANs) need not be retained past 90 days, which is typically when chargebacks or disputes occur. If there is no business need to store cardholder data (for instance, so that a third party can supply access to transaction data and provide a mechanism for disputes and chargebacks), merchants should consider purging or redacting PANs stored both electronically and in hardcopy. Simply put: if you don’t need it, get rid of it. Also, keep in mind that masked or truncated PANs are not considered cardholder data and, as such, are not subject to the PCI DSS and can be stored indefinitely. Therefore, redacting all but the first six and last four digits of the PAN is a common method that organizations use to reduce or eliminate cardholder data while still maintaining the ability to reference a particular card or transaction, if necessary.
One common misconception deals with retaining financial records for audits. Many organizations end up keeping paid invoices that include complete credit card numbers for several years. However, this is not usually necessary. Financial auditors are interested in seeing records of revenue and expenses, not individual credit card numbers. In light of this fact, a simple change in business process can often significantly reduce burden associated with attaining and maintaining compliance.
When it comes to a remediation strategy, the first step in complying with Requirement 3.1 is to define an appropriate data retention policy that is based on business, legal, and regulatory requirements. This will, of course, vary from organization to organization. However, keep in mind that most business models do not require the retention of full PANs for very long after a transaction. Once an appropriate retention period has been determined, an official policy should be documented. Be sure to include any specific legal or business reasons for the selected retention period, as well as a formal method for disposing of both electronic and hardcopy cardholder data once that period has been reached. Finally, implement the policy and purge historical data that exceeds the newly defined maximum retention period. Remember that, in most cases, redacting PANs by blacking them out with a marker, cutting off the credit card section of a form and shredding it, or truncating data in a database is an effective way to reduce the cardholder data that is retained, reduce the risk of a credit card data breach, and meet the intent of PCI requirements.
We were asked by a customer about performing code review based on the PCI requirements. The questions they asked were:
Is there a checklist that exists that covers all of the PCI requirements?
Are there requirements such as not storing PAN un-encrypted?
What about not storing full track data or other restricted data?
Are there considerations outside of OWASP?
Can you recommend a simple resource for all PCI-related requirements?
At this point in time, there does not seem to be a single source of reference that answers all of these questions.
Since there is no definitive source, this document covers some of the PCI requirements in relation to code reviews. A code review includes reviewing all of the code for the OWASP Top 10 Web Application Security Risks for 2010. The OWASP Top 10 is inclusive of the PCI requirements and answers most if not all of the above questions.
The OWASP Top 10 Web Application Security Risks for 2010:
Injection flaws – such as SQL, OS and LDAP
Cross-Site Scripting (XSS)
Broken Authentication and Session Management
Insecure Direct Object References – exposing a file, directory or database key
Cross-Site Request Forgery (CSRF)
Security Misconfiguration
Insecure Cryptographic Storage
Failure to Restrict URL Access
Insufficient Transport Layer Protection
Unvalidated Redirects and Forwards
Risk number 7 specifically covers the question about storing PANs unencrypted. As for storing track data, this is partially covered by risk number 7. Track data is sensitive and needs to be encrypted while stored, but it can only be stored pre-authorization. Once the transaction has been authorized, the data must be securely deleted. This requirement is not covered by the OWASP Top 10.
Here is a complete list of the PCI requirements as they relate to the OWASP Top 10 (see the list above):
Requirement 1: Install and maintain a firewall configuration to protect cardholder data – this requirement is not typically covered in a code review
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters – this requirement is covered under risk number 6
Requirement 3: Protect stored cardholder data – this requirement is covered under risk number 7
Requirement 4: Encrypt transmission of cardholder data across open, public networks – this requirement is risk number 9
Requirement 5: Use and regularly update anti-virus software or programs – This requirement is not typically covered in a code review
Requirement 6: Develop and maintain secure systems and applications – this is fully encompassed in the OWASP Top 10 (both 2007 and 2010 versions)
Requirement 7: Restrict access to cardholder data by business need to know – this requirement is partially covered by risk number 4
Requirement 8: Assign a unique ID to each person with computer access – this requirement is not typically covered in a code review
Requirement 9: Restrict physical access to cardholder data access – this requirement is not typically covered in a code review
Requirement 10: Track and monitor all access to network resources and cardholder data – this requirement is not covered in the OWASP Top 10
Requirement 11: Regularly test security systems and processes access – this requirement is not typically covered in a code review
Requirement 12: Maintain a policy that addresses information security for employee’s and contractor’s access – this requirement is not typically covered in a code review
Start your code review checklist with the OWASP Code Review Guide and add to it for those requirements that are not covered by this guide. This includes securely deleting sensitive data (PANs, track data, keys, etc.) and application logging.
Another place to start or append to your checklist, if you develop .Net applications, would be Microsoft’s Index of Checklists .
