By Bill Pirtle
MPCT Publishing Co.
Most merchant level salespeople (MLS) cringe when they think about Self-Assessment Questionnaires (SAQs). The Payment Card Industry (PCI) Data Security Standard (DSS) requires SAQs to be completed by all but the very largest merchants (Level 1), who have more stringent requirements.
When SAQs first appeared, many MLSs helped merchants complete them. Now that we understand the liability associated with helping merchants in this manner, we need to find other ways to get the job done.
Some larger ISOs have online SAQs merchants can be directed to, but most of those still require merchants to hire their own Approved Scanning Vendors (ASVs). I believe there are two very good reasons for MLSs and small ISOs to partner with a qualified information security company.
For this article, I posed questions submitted by GS Online MLS Forum members to Greg Rosenberg, Alliances Sales Engineer at Trustwave. Rosenberg is considered by many to be the guru of the SAQ. His answers, thankfully, were not too technical and are mostly explanations of policies and suggestions to help you help your merchants. GMARTIN began by asking, "IP terminals are connected to the Internet to process transactions. If you read the questions regarding scans, it says if you have a connection to the Internet, it must be separate from other computers.
I take this to mean you would need a separate router to hook up to the IP terminal. I doubt many are following this, and since the terminals are secured with SSL or the like, and don't store card data, this requirement seems very onerous.
"I may be misunderstanding this, but that's how I read it a year or so ago. At that time, there was no special wording regarding IP terminals, just any forward facing Internet connection, of which an IP terminal would be included. What is your understanding of this?"
Rosenberg responded as follows: "In most cases, IP terminals generally qualify merchants for SAQ C or D. When we discuss IP terminals, we tend to think of them as otherworldly devices. We need to remember two basic tenets here:
Next, CLEARENT asked, "What is the scope of a scan and what does it entail? What defines different needs?"
Rosenberg replied, "To understand an external vulnerability scan, a good analogy for the process of the scan is akin to how a burglar would 'case the joint' before a robbery. In this analogy, your network is equivalent to the house that a burglar is checking out in hopes of finding soft spots to exploit.
"A scan generally starts with a port scan. This is equivalent to checking for unlocked doors and windows. Except in the case of your public-facing Internet connection, there are more than 65,000 possible entrances to your network. You may have heard of some of the more common ports; for example web traffic uses port 80, and email uses port 25. Some ports stay open to pass-through traffic, but hopefully these are as few as possible.
"Once the open ports have been identified for your network, the scanners try to identify all of the devices sitting behind them, called system enumeration. It's similar to a burglar peering through your windows to see if you have an alarm system or watch dogs.
For system enumeration, the scanner will identify the types of operating systems running on the devices on the network (Windows, Mac, Linux, UNIX, etc.) and the services running on those same systems. The scan may find payment applications, web servers or domain controllers.
"Lastly, once all available systems and services are identified, the scan performs two basic checks:
"At no point will an external vulnerability scan attempt to manipulate or steal data from your environment. The moment that an individual tries to exploit a vulnerability scan, the process is either labeled a hack (you did not provide the permission) or a penetration test (you authorized the access)."
I then said many MLSs, myself included, wonder what the written policy of a merchant should look like to satisfy requirements.
"This is a complex question to answer and will vary from merchant to merchant," Rosenberg said. "Suffice to say that there are a few points to be aware of as far as policies and procedures:
CCGUY wanted to know, "Why is there no such thing as PCI Compliant Web Hosting?"
Rosenberg said, "In short, the PCI DSS is a holistic approach to protecting cardholder data. It applies to an organization and not just a cluster of servers. Most reputable web hosting providers have either self-assessed or had an independent auditor look at their business and its practices for review against the PCI DSS.
"Visa and MasterCard list web hosting providers who have had an on-site assessment by a QSA. When engaging a web hosting company, part of the due diligence should include whether the provider is PCI DSS compliant and how they can demonstrate their compliance.
Remember, in most cases, should a hacker breach a hosting provider and steal customer's credit card data, the merchant will likely be held accountable. Choose your partners wisely."
Having repeatedly heard differing answers on this topic, I asked, "If a merchant has a website with a separate gateway (like eProcessing Network), does the merchant need to scan his network? Does this change if the merchant uses a virtual terminal feature to key card numbers?"
"It depends," Rosenberg replied. "Do you transmit your cardholder data to the third party, or are you redirecting your customers to another website? Even if you don't touch cardholder data you still have risk, and scanning is recommended in many cases."
"Are there a certain number of mandatory scans for POS IP connected merchants?" FAITH asked. "If so, how many and how often? If not, are there a recommended number of scans? Lastly, what is the cost of an average scan?"
Rosenberg said, "The PCI DSS mandates that merchants pass at least one scan per quarter, at a minimum, if scans are applicable to their environments. However, monthly scans are recommended to stay on top of changes you are making and the effect on the scan results. For example, you would not want to scan once every quarter, fail that scan and then scramble to try to pass a scan that same day.
"The price will vary, but most small merchants should expect to pay a few hundred dollars per year for their scans in a retail setting. Many acquirers, processors and ISOs have PCI DSS validation programs that can bring that cost down significantly."
Next, CCGUY asked, "Why doesn't PCI DSS require that POS systems (computer systems) be on a closed system, closed network, no outside access to the net on any computer that is part of the POS system?"
Rosenberg replied, "Two concepts are really important when engaging in the PCI DSS compliance process for the first time: segmentation and 'least privilege.'
Segmentation means removing systems from the cardholder data environment with specific security controls like firewalls and point-to-point encryption (P2PE). Least privilege means individuals or systems only have access to that which they need to do their jobs and nothing else.
"Segmentation is not required by the PCI DSS, but it can significantly reduce the burden of compliance and the amount of exposed risk. Least privilege is generally required for all systems and personnel, but not often followed or interpreted properly.
"Most merchants with broadband connections generally need at least some access to the Internet or open networks for their POS systems to function properly. Unfortunately, all too many merchants do not stay vigilant with how many connections remain open over time. One should always be aware of the holes they have poked through their firewall and why they are keeping those holes open."
CCGUY asked another question that I'm sure many in the industry ask, "How do they expect a merchant who owns a restaurant with no IT [information technology] education, no IT department, no computer experience beyond sending email, etc., to answer the SAQ D?"
"If you are a merchant trying to fill out SAQ D on your own, and you don't have a technical background, please stop," Rosenberg said. "There are wizard-based approaches, like Trustwave's TrustKeeper, that can help translate the technical requirements into more meaningful text.
Even if you understand a good portion of the requirements, please look for a vendor that has this approach to help simplify the remaining 25 percent of the requirements.
"If you are a merchant that qualifies for SAQ D, then you are already at higher risk than about 75 percent of all other merchants. There are two paths that SAQ D merchants should take:
Jim Motley of Alpine Network Solutions in White Lake, Mich., asked me why in the world would a scanning company fail his client because the ASV could not detect his client's network through his security system.
To this, Rosenberg said, "An ASV should never request that a merchant remove security controls to facilitate an external vulnerability scan. The scan is trying to mimic what a hacker might see from the real world.
You will expose yourself to unnecessary risk when removing these important security controls. Immediately escalate this issue with your vendor should they make such a request."
I would like to thank Greg Rosenberg for taking the time to answer questions on the SAQ. I'd also like to thank Greg Leos, Vice President at Trustwave, for making Rosenberg available, and Trustwave management, for allowing his participation in this article.
If you have further questions regarding SAQs, Rosenberg can be reached at grosenberg@trustwave.com.
Please contact me on the MLS Forum or by email if you would like to suggest a topic for a future article.
Bill Pirtle is the President of MPCT Publishing Co. and author of Navigating Through the Risks of Credit Card Processing. He is also a merchant level salesperson for Clearent LLC, Electronic Payments Inc. and Electronic Merchant Systems Inc. Bill's website is www.creditcardprocessingbook.com, and his email address is billpirtle@yahoo.com. He welcomes all connections on Facebook and LinkedIn.
The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.
Prev Next
