In a previous post, I mentioned that the Security Standards Council would be releasing a new version of the Self Assessment Questionnaire (SAQ) for merchants using virtual terminal environments for processing cardholder data. Well, say hello to the SSC’s new bundle of joy; called the SAQ C-VT, this version is applicable to “merchants who process cardholder data only via isolated virtual terminals on computers connected to the Internet”. This should come as a welcome addition to merchants who developed blank stares and involuntary tics as they tried to figure out which SAQ was applicable to their browser-based terminals. Full disclosure: I am guilty of getting into heated (and very boring to anyone else) discussions about the applicability of certain SAQs in various browser-based situations; this should simplify the discourse in the future, and leave time to discuss more important matters (such as why the 2010 Vikings should be traded to the Mexican Football League). I also think that the clarifications will have some positive implications for securing virtual terminal workstations. This is important, as two typical arguments that I have run into when doing an assessment involving virtual terminals go something like:
“The terminal just has a web-browser, and our payment gateway uses SSL. This workstation is out of scope and we don’t have to secure it. Antivirus is too expensive. Hold on while I install this kitten screensaver someone sent me through my AOL account on this terminal”.
“We don’t know how to deal with this PC, so we are cutting our company’s Christmas bonuses to pay for locking it down. We hired a team of InfoSec PhDs to harden the workstation and we have moved it into its own datacenter. To access it you have to go through a screening process that was rejected by the TSA for being too intrusive.”
To address the lines of thinking above, the SSC created the SAQ C-VT, which makes it pretty clear that virtual terminal workstations must be segmented and secured; the SAQ C-VT also provides streamlined requirements that are much more aligned with a virtual terminal’s function and typical configuration. For SAQ C-VT eligibility, a merchant must meet the following criteria:
Merchant’s only payment processing is via a virtual terminal accessed by an Internet-connected web browser;
Merchant accesses the virtual terminal via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment;
Merchant’s virtual terminal solution is provided and hosted by a PCI DSS validated third party service provider;
Merchant’s computer does not have software installed that causes cardholder data to be stored (for example, there is no software for batch processing or store-and-forward);
Merchant’s computer does not have any attached hardware devices that are used to capture or store cardholder data (for example, there are no card readers attached);
Merchant does not otherwise receive or transmit cardholder data electronically through any channels (for example, via an internal network or the Internet);
Merchant does not store cardholder data in electronic format (for example, cardholder data is not stored in sales and marketing tools such as CRM); and
If merchant does store cardholder data, such data is only in paper reports or copies of paper receipts and is not received electronically.
The full SAQ C (v 2.0) contains 80 requirements; the SAQ C-VT has a trimmed down 51. The changes are summarized below:
In SAQ C-VT, a personal firewall is required
The requirements to encrypt non-console access have been removed
There are no longer 3.x requirements for storing authentication data, as you wouldn’t be doing this in a VT situation
Encryption strength and security protocol configuration requirements are removed (4.1(c) and (d))
There are no longer requirements for encryption of wireless transmissions of cardholder data
Antivirus and patching requirements stay the same (as they should)
Remote access for vendors and two-factor authentication requirements are gone
Quarterly wireless scans/NAC for detection of rogue access points are gone, as well as the associated requirement for inclusion of wireless access point detection in the incident response plan
This is a BIG ONE: Internal and external quarterly scan requirements are gone. This in itself should make a very compelling argument to ditch the card swipe and start typing out those card numbers
Several requirements for ‘critical technologies’ are gone, including authentication for use of remote access, acceptable network locations for use of the technology, and automatic disconnection and activation of remote access technologies
Also, props to Branden Williams (truly a gentleman and a scholar) for being the first to make me aware of the release of the new 2.0 SAQs on his excellent blog.
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. Next up – what can I do?…
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Discover why security operations teams choose NetSPI.