Healthcare executives are concerned with a broad array of regulatory and compliance-related issues. Many of those concerns are focused on patient health, government oversight and regulation, HITECH and meaningful use, financial cost controls, and even on credit card security. That last item might not be a complete surprise, but I suspect that, for many of you, it is way down on the priority list.
It’s an understandable approach given the magnitude of your other concerns, but it is a decision that may come to haunt you, particularly given the emphasis that card brands (VISA, MasterCard, American Express, Discover, and JCB) have put on credit card security and the focus that they have been bringing to the healthcare field. Retailers have been struggling with credit card security for years, but the card brands have started to cast a wider net, and healthcare has become a primary focus for PCI compliance.
I am sure that you are aware of the Payment Card Industry Data Security Standards (PCI DSS), a very broadly applicable security standard that concerns itself with all aspects and environments that deal with credit card information. What you might not be fully aware of (or may not fully understand the implications of) is the Payment Application Data Security Standard (PA-DSS.) This standard is managed by the same organization that manages the PCI DSS and, with some important due dates having recently passed us by, healthcare software companies are only just starting to “wake up” to the fact that they may have to worry about PA-DSS. In this pair of articles I attempt to do three things:
Provide a brief overview of PA-DSS and why it came into existence.
Help you understand why you should know and care about the PA-DSS.
Provide you some steps that you can take to make sure your vendors are addressing PA-DSS
What is the PA-DSS?
To provide a bit of context, it’s important to understand where the PA-DSS originated. PA-DSS was born from a previous program known as the PABP, or the Payment Application Best Practices program. The PABP program was a voluntary program created and administered by VISA that would allow application vendors to have a third-party assessor validate that their applications were built using security industry best practices. The PABP was a program that didn’t have a lot of teeth, wasn’t overly prescriptive, and wasn’t mandated by VISA, so only a handful of companies (mostly retail-focused) bothered to go through the process – almost entirely for marketing purposes.
In 2008, the PCI Security Standards Council (the organization created by the major credit card brands to administer the PCI DSS) was asked to take over the PABP program and align it fully with the PCI DSS. The outcome of that effort is the PA-DSS, which translates the requirements of the PCI DSS into a standard that application companies follow to ensure that they are providing an application that their clients can utilize in a PCI DSS-compliant manner. The PA-DSS is a very, very detailed standard whose requirements span documentation, technology, architecture, coding practices, process, lab testing, and a full SDLC investigation to provide a complete assessment of the security of the application.
These dual standards did create some confusion for organizations concerned with or subject to the PCI DSS. Anyone accepting a credit card needs to be PCI DSS-compliant, but they didn’t have to use PA-DSS validated applications (a standard administrated by the same council.) To make their own position clear, VISA stepped forward and stated that they required the use of PA-DSS validated applications for organizations processing VISA transactions. As VISA accounts for the largest volume of credit card transactions in the United States, their stance on PA-DSS certainly carries a lot of weight.
Now, you may be thinking, ‘why all of this concern over a standard that is so focused on payment applications’? The concern within the healthcare community comes from the definition of “payment application” – the PCI SSC has declared that, if an application fits certain criteria, it is considered a payment application, regardless of industry or the primary focus of the application. The criteria can be boiled down to:
Does the application transmit, store, or process cardholder data? (i.e., does it touch relevant credit card information?)
Is the application sold, licensed, or distributed to third parties? (i.e., it’s not an application that you developed internally or had custom developed for your organization)
An FAQ on the PA-DSS program and its requirements is located on the PCI SSC’s website but, if you consider just the two points above, this standard covers a lot of application solutions within the healthcare space. Basically, any software application that deals with credit card data, even if it’s the most ancillary aspect of that software’s functionality, is subject to the PA-DSS.
Why Should I Care?
So, why should you care? Well, first of all, because VISA has mandated that every merchant (i.e., any organization taking a credit card for payment) must use PA-DSS-validated applications after a particular date. That date was July 1st of 2010 (yes, we’re already past the mandated date.) VISA has indicated that acquirers (the organizations that process credit card transactions) “must take prompt action to move all merchants and agents to PA-DSS-validated applications” and, although they have not at this point documented consequences for non-compliance, typical consequences could include fines, higher interchange rates, or a straight refusal from VISA to process any of your transactions. Also, as VISA works through the acquirer, not with you directly, your acquirer might simply cut you off from processing any credit card transactions.
A second reason to care is that you may already be contractually obligated to address both PCI DSS and PA-DSS. Many payment processors already include provisions for your PCI DSS compliance in their contracts, but, given the pressure from VISA, PA-DSS requirements are starting to show up as well. That means that utilizing PA-DSS compliant applications for managing and accepting payment may be a requirement for taking any credit card, not just VISA-branded cards. Even if a processor doesn’t restrict card acceptance, it may impose a penalty in the form of a higher interchange rate to cover their own exposure to potential security ramifications or action by VISA.
The third reason (although not the least important) you should care is that this is an issue which may have a material impact on your organization, but is largely out of your direct control. You cannot have someone validate the software that you use in your facility (unless you are utilizing internally developed or fully customized applications) – the process needs to be initiated by the software vendor, the documentation updates need to be done by the vendor, the testing needs to be done on specific revisions of the applications, etc. You can’t fix this problem no matter how good you are at making your environment and facility secure. This is the responsibility of the application vendor, but it has the potential to have a significant impact on your organization’s ability to accept credit card payments.
I’ll elaborate a little further in the next section, but action needs to be taken to get your vendors moving in the right direction on PA-DSS. In the retail community, it took retailers screening vendors for PA-DSS and building PA-DSS into contracts for application companies to finally stop arguing and get moving on their PA-DSS requirements. Healthcare organizations are only starting to recognize that they need to keep their vendors’ feet to the fire on PA-DSS, and it’s only now becoming a big issue as a few of the more forward-thinking application companies targeting the healthcare space are starting to prepare for and go through PA-DSS validation.
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.
The move to a risk-based approach to PCI-DSS rather than a compliance-based approach would enable the transformation of PCI-DSS from a compliance standard to a security standard. On the other hand, the PCI-SSC avoids conflict with other industry security standards, guidance, and recommended best practices by NOT trying to be a security standard. That much is true up to now.
For example, in the case of annual key rotation requirements in section 3.6, there is little ambiguity in v1.2.1, where an annual key rotation is required. If an entity feels that quarterly or monthly encryption key rotations are appropriate, then they have met and exceeded that standard. If the cryptographic cycle is longer than one year, then that organization has not met the standard.
In most cases, the real risk of compromise to otherwise protected data lies not in the age of the encryption key, but rather in the balance of section 3.6 requirements that are NOT addressed by key rotation – specifically the key generation, storage, distribution, and revocation requirements. Generate weak encryption keys, implement weak cipher strength, get sloppy with storage and distribution and allow anyone to arbitrarily change keys at whim – and the frequency at which you rotate keys matters little, even if you change them daily.
But is a QSA empowered to make risk-based decisions regarding the suitability of a client’s key rotation interval? Version 2.0 suggests this: conceivably a QSA may reject the practice of annual key rotation on the grounds that risk factors suggest a more frequent key rotation schedule, perhaps quarterly. If the organization does not meet the schedule mandated by the QSA, then that organization may fail the audit until such time that it meets the “QSA requirement.” The target organization may in turn argue that it has met the standard of PCI-DSS by implementing (and demonstrating) annual key rotation. They will cite “contempt of QSA” as the reason for their failure to comply with PCI-DSS. Who will referee this dispute? What recourse does either the target organization or the QSA have available to them, and what actions might they take to address the conflict?
Similarly, a QSA may determine that an interval of less than one year is appropriate, and that the cryptographic cycle should be five years. How has this met the standard? By the arbitrary judgment of the same QSA who insisted on quarterly key rotations for that (other) organization? If the QSA can demonstrate the risk-based approach used to determine the cryptographic cycle, would this be acceptable? How can this be demonstrated with a high degree of confidence? That is, how do we know that the QSA did not fudge some “voodoo” numbers to support his or her “risk-based” analysis? How will this be communicated to the Acquirers and/or Card Brands?
The only vehicle currently available to communicate deviations from the standard is the Compensating Control worksheet. In its current form, one can well imagine what such a worksheet would look like. But one would be hard-pressed to imagine that such a Compensating Control would convey a strong and convincing argument supporting a lengthy cryptographic cycle well below the minimums established in the PCI-DSS.
Some of the team from NetSPI spent the week in sunny Orlando at the 2010 PCI North American Community Meeting. As most are aware, this year’s meeting was particularly significant as a new version of the Data Security Standard, 2.0, which has now been released and effective as of 1/2011. The new standard is so advanced that it went from 1.2.1 to 2.0, incorporating a 0.7.9′s worth of changes in a single revision(!).
The last few days’ sessions were a great opportunity to review the changes with the SSC and card brand representatives, catch up with others in the industry, and dispel rumors about the new DSS version (there will be no Requirement 13 mandating the use of ninjas to protect cardholder data, and Ouija boards cannot be used for wireless access point discovery). It should also be noted (if my wife is reading this), there was absolutely no beer consumed at Kook’s Sports Bar and all discussions were reasoned, civil discourses that ended promptly at 9:00 PM to allow for a full night’s sleep.
As far as the changes to the DSS, it should come as no surprise that there were not many surprises to be found. As was pointed out several times throughout the course of our sessions, the DSS is a mature framework with a rising adoption rate throughout the world; major changes could have serious financial and operational repercussions on merchants and service providers who have already incorporated the DSS into their environments. Keeping that in mind, the intent of v2.0 is to provide additional guidance and clarification based on the (apparently) thousands of communications that the SSC received in response to their request for feedback, and my first impression is that it succeeds in that respect. Below are some of the highlights I picked up on from the meeting and SSC-supplied docs, in no particular order:
Clarification that PAN is the primary element for applicability of the DSS to a merchant/service provider environment and is the definition of ‘cardholder data’
Sampling requirements will be more detailed, and will require more justification as to why the sampling methodology used for an assessment is considered sufficient
There are clarifications for issuers that have a business need to store sensitive authentication data (SAD), which should provide more specific guidelines for retention and protection of SAD
Additional requirements to secure PAN if hashing and truncation are used in the same environment, to reduce the possibility of malicious users reconstructing full account numbers
At this point, an automated or DLP-type solution is NOT required for data discovery and scoping of the cardholder data environment, though tools of this nature can/should be used where appropriate
“System components” now includes virtual systems in the definition
Requirement 6 has been overhauled to merge internal and web applications, and “industry best practices” no longer means just “OWASP”, and includes SANS, CIRT, CWE, etc.
News flash- two passwords are not considered “2-factor”. Glad we got that one clarified.
Requirement 11 allows for physical site inspection for rogue AP discovery if appropriate. I can’t see this working well in a large physical environment, but may work for mom-and-pop retailers who can see every wire on their router. I can’t wait for my first opportunity to write a comment for 11.1 that includes “Bob, the IT guy, climbs through air ducts and drop ceilings on a quarterly basis to identify potential rogue APs”
IDS/IPS must be included at the perimeter of the cardholder data environment and ‘key points’, as opposed to monitoring all traffic in an environment
There was some discussion around a new SAQ C that would be applicable to ‘virtual terminal’ environments. This is a work in progress, and I didn’t hear an official release date
There are many other tweaks not included above, but no real game-changers in my opinion. I know not everyone will be happy with all of the revisions, but the DSS is by its nature a compromise between global applicability for all types of environments and nuts-and-bolts implementation. There will still be requirements that have QSAs and clients scratching their heads, but my impressions are that many of the clarifications are long overdue and should make many of the requirements easier to interpret, test, and enforce. Ninjas will just have to wait for version 3; be sure to get your feedback in early.
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 .
Subscribe to PCI/PA-DSS Compliance Blog
