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.
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.