The PCI Security Standards Council (SSC) has recently released the latest version of the 2.0 Report on Compliance (ROC) Reporting Instructions (formerly called the “scorecard”). This document had previously been for use by QSA auditors only; it is the secret sauce used to perform a Level 1 PCI audit. For those of you lucky enough to have gone through a L1 audit, the “scorecard” is the super secret document that the QSA kept stored on the triple encrypted drive in the TEMPEST-approved tamperproof tungsten-lined briefcase handcuffed to her wrist. QSA’s were not allowed to share the criteria on which the company was being audited (scored) on; the reporting instructions require the QSA to perform one or more of the following validation steps for every requirement:
Observation of system settings, configurations
Documentation review
Interview with personnel
Observation of process, action, state
Identify sample
Well, good news everyone! The document is now available to the general public. Hopefully, this will eliminate some of those awkward moments that seem to always come up during an audit:
QSA: “You need a documented policy that says you use network address translation. That’s not written down anywhere.”
Customer: “Can you show me where it says I need to do that in the DSS?”
QSA: “You won’t find it there, but I promise it says it somewhere. I’m not allowed to show you, just trust me, you need it”.
Customer: “Can you just let me peek over your shoulder?”
QSA: “If you saw it, I would have to have your memory wiped. Have you ever seen “Men in Black“”?
Customer: “I’m calling Security”.
It’s pretty hard to follow the rules when you’re not allowed to know what they are. With this document’s public release a company can actually evaluate their controls and compliance program against the same standards that a QSA will use; no more guessing how to meet a requirement, no more conversations where the auditor gives a seemingly arbitrary failing finding, with a “because I said so” for the explanation. This should also allow for organizations to get a much better picture of the intent and expected implementation of a requirement by understanding how the controls will be assessed. Well done, SSC.
From the “never been asked that question before” files, I recently had a client who wanted to know about wireless keyboards and whether they are in-scope for PCI. There are no PCI requirements that address keyboards or other wireless peripherals (though you could make a case that some keyboards transmit unencrypted cardholder data over ‘open, public networks’). Just to double check, I reread the Security Standards Council’s Wireless Special Interest Group publication on wireless best practices and PCI; the guidelines are geared towards 802.11 WLANs and specifically exclude Bluetooth.
Wireless keyboards are ubiquitous; there is a reasonable chance your organization is using them as the interface to a POS application or virtual terminal. The input could include customer name, expiration, PAN, and CVV. As we typically wouldn’t pay much attention to the peripherals that we type this data on, the question got me thinking about how much we take technology (and its security through obscurity) for granted. I did some exhaustive research on the subject (at least 5 minutes searching Google) and easily found some real world examples of wireless keyboard sniffing techniques; though not currently a prevalent attack, it is quite feasible to intercept the output from a wireless keyboard without leaving fingerprints behind. Unlike traditional keystroke loggers and screen scrapers, which can often be detected by antimalware applications, wireless attacks are transparent and do not require physical or logical access to target machines.
One of the more advanced tools out there is on Remote Exploit’s site, called KeyKeriki. This is a combination of hardware/software that targets the wireless signals from 27MHz keyboards (there’s a 2.7 GHz version on the way, too) and can capture or output the keystrokes. The hardware looks simple to build and includes an SDCard for logging; additionally, the software can do decryption of some weak XOR-based encryption on the fly (it takes about 40 keystrokes to get enough data to decipher the stream in real-time). I don’t want to go too far down the rabbit hole here as you can’t defend against every attack vector (PCI doesn’t address TEMPEST or Van Eck phreaking either), but there are some simple steps that can be taken to reduce the risk of compromise:
Include standards for input devices in your list of approved hardware; pick keyboards that use strong cryptography to transmit data.
It looks like many of the exploits are written to take advantage of certain vendor’s keyboards (I’m looking at you, Logitech and Microsoft…). Do some research when purchasing wireless keyboards to see if their communications security has already been compromised.
If you do have a need for wireless input devices, consider using Bluetooth, which offers some protection through the use of a PIN and a custom SAFER+ block cipher implementation. Check the footnote for a good publication on Bluetooth and security from NIST.
Drink plenty of coffee and/or adult beverages of your choice before typing credit card numbers. The resultant twitching/lack of coordination will make it more difficult for a malicious user to extract useful information from your typing. Bonus: it’s fun.
Consider using wired keyboards for virtual terminals and POS workstations. Remember those things?
If you are a payment application vendor, are you worried about the changes that have happened with the new release of the Payment Application Data Security Standard (PA-DSS)? For the most part, the requirements have not changed but there are a couple of items that may require some changes in the application, the documentation, or even the processes around the application.
Storing sensitive authentication data
In PA-DSS version 1.2, it was not acceptable to store authentication data (i.e. track 1 data, CVV, etc.). The revision for PA-DSS version 2.0 now allows for sensitive authentication data (track1, track 2, CVV) to be stored but only if there is sufficient business justification and the data is stored securely. This is only for card issuers and companies that support issuing processing. It has never been permissible for merchants to store this information even if encrypted.
During the testing portion of the audit, the auditor will be testing for sensitive authentication data using forensic methods. The auditor will also verify that the application is intended for card issuers and/or companies that support issuing services.
Auditing
One of the changes to PA-DSS is that the application needs to support centralized auditing. This means the audit data must be able to be moved to a centralized log server (i.e. syslog-ng, Windows Event Logs).
During the testing portion of the audit, the auditor is going to have to see that the lab has a centralized log sever configured and that the application logs are moving to this server. The PA-DSS Implementation Guide also has to provide instructions and procedures for incorporating the logs into a centralized logging environment.
One less requirement
As a final note, there is one less requirement. Requires 10 and 11 have been merged, instead of having two separate requirements, one for the merchant and one for the payment application vendor, there is now only one requirement covering remote access to the payment application.
Conclusion
The PA-DSS version 2.0 requirements, in most cases, are clearer. It makes it easier for payment application vendors to understand the requirements and to pass the audit.
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.
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.
Subscribe to PCI/PA-DSS Compliance Blog
