PCI Compliance – Common Issues and Troubleshooting

Regulated by the Payment Card Industry, PCI Compliance is a set of standards designed to help protect merchants against credit card fraud. The overall goal of PCI compliance is to limit fraud at all levels of the credit card transaction world. That said, achieving PCI compliance for your website can be tricky.

For a primer on PCI compliance, please see this page of our website:

Any business that accepts credit or debit card payments is required by their merchant processor to pass a series of PCI compliance tests. Until the merchant has met compliance, they may face monthly financial penalties assessed by the merchant processor; The PCI compliance seal on the merchant’s website will appear broken or indicate they are not in compliance; And in some cases, they may have their merchant account revoked by the processor until such a time as compliance can be verified.

This article assumes the following:

  • You are the owner or manager of a website that needs to pass PCI compliance
  • You have access to the website hosting environment
  • You are authorized to access your company’s merchant account
  • You are authorized to access your merchant processor’s Approved Scanning Vendor (ASV) interface, where all of the PCI tests and results are compiled

In this article, we’ll go over the general workflow of achieving PCI compliance, including the Self-Assessment Questionnaire (SAQ) and setting up for your first PCI scan through an Approved Scanning Vendor (ASV); We’ll touch on possible issues, like challenging false-positives assessed by your ASV, and Risk Mitigation and Migration plans; And we’ll address specific steps Canvas Host takes to ultimately guide you to reaching PCI compliance.

1. Workflow

At the time you signed up for your merchant account, you should have received instructions to access the online portal for the ASV that partnered with your merchant processor.

The first step is to log into that portal and take a look around. Most interfaces will provide an overview of your merchant account, and report on your account’s current PCI Compliance, which typically is presented in two categories. You will need to go through both sets of steps as part of the overall compliance process. They are:

1a. The Self Assessment Questionnaire (SAQ)

You are required to complete the SAQ each year and answer hundreds of questions pertaining to how you physically conduct business, process and store credit card information about your customers, and what steps you take to ensure the security of your entire business.

If this is the first time you have logged into your account, the SAQ will be displayed as “incomplete” or “not passing compliance”. Clicking on the “start” or “begin report” button should start the online form. You should prepare for upwards of one hour, perhaps two hours, if this is your first time. On subsequent reports, you will find it faster to go over and refine previous reports, noting aspects of your operations that have changed, as well as being able to skip over details that have not changed.

Once you have gone through the SAQ, there may be follow-up questions provided by the interface that ask you to clarify or rectify incomplete or unacceptable answers. Once you have met all of the requirements of the SAQ, the interface will indicate that you have passed the SAQ. It is important to be as accurate as possible on all answers, to both ensure your company is operating safely, as well as to mitigate any liability that might arise from having provided untruthful information.

1b. PCI Compliance Scan

This is the hardest part. Every quarter (three months). you are required to permit the ASV vendor to scan your website and hosting service and to analyze them both for vulnerabilities, and generate a report that will either come back as “pass” or “fail”. After each scan, the results will be tallied into a printable/downloadable report, typically in PDF format, for review by you and potentially, your website host as well.

If this is your first time logging in, you will need to set up the ASV interface to scan your website, noting the domain name, and possibly the IP address associated with your hosting account. Once set up, the scan will be scheduled to start, and you will be notified of the scan’s findings.

If this is not your first time logging in, or you have recently changed website hosting providers and the old reports are still noted in the ASV interface, please be sure to check the configuration of the ASV, to ensure they will be scanning the correct IP address and/or website host! In the past, we have had customers notify us of failed scans; Upon reviewing the reports, we determined the failure was due to the ASV scanning the old hosting provider and not Canvas Host.

2. Reviewing the PCI scan

Scans of your website and hosting environment can take several hours to complete. The scans target two components of your online business:

2a. Your website and application code

During the scan, the ASV may test random URLs of your website, specifically looking for website forms, such as account logins, or fields requesting credit card information or other personal information (noted by the field name in the actual HTML code).

The scan will also attempt to determine the application you are running, such as WordPress/WooCommerce, Magento, or ZenCart (some of the many popular cart applications); Their versions (which is important, as code releases and minor revision patches are regularly issued to correct code vulnerabilities); And whether your application contains known bugs, such as cross-site scripting vulnerabilities, Javascript- or CSS- based bugs, or other technologies that may all present a risk to the website being hackable.

2b. Your website’s hosting environment

The ASV will also attempt to scan details of your website hosting provider — in this case, Canvas Host and the server we use to host your website — to determine if the server itself meets certain security criteria, or if it contains known vulnerabilities or similar “problems” that need to be fixed, in order to pass compliance.

Examples of things tested for include:

  • The version of operating system and related technologies, such as CentOS and WHM
  • Encryption and security technologies, such as SSH, SSL, and SFTP versions
  • Server-level login interfaces and if they force https:// or permit http://
  • Insecure technologies that should not be permitted, such as FTP
  • Open ports that may be subject to hack

This portion of the scan is sometimes the trickiest, and for you can also be the most frustrating part, as it pertains to things completely outside of your control.

For Canvas Host, it can provide the greatest set of challenges, as every ASV operates a different set of criteria by which a server will be judged to be PCI compliant or not. The greatest quandary is in regards to suspected vulnerabilities or errors that actually do not exist, but which have turned up as a result of the ASV not being able to fully scan our servers, and whether the ASV will accept the answers and evidence we provide back to them in the course of trying to meet their criteria. This brings us to the next section.

3. Troubleshooting and resolving PCI scan failures

Whenever a PCI scan comes back with a “fail”, we ask you to open a ticket and provide us with a copy of the report to our Support system, at https://support.canvashost.com.

Our team will review the scan report and provide assistance in understanding the points of failure. For any points of failure due to code or website issues, our team will inform you that those are things you will need to fix. For any issues pertaining to the server in question, we will review the issue to determine if it is a new requirement that we need to act upon, or if it is something we’ve already fixed but which could not be determined because of limitations by the ASV.

3a. False positives

The most common situation we see in failure reports are deemed “false positives”, which are in fact not a threat but stem from the ASV not being able to dig deep enough into the server to figure that out for themselves. This is actually a good thing, because quite frankly, no outside service should ever have the right to scan or potentially hack into one of our servers. But, we recognize the irony of ASV’s intrusive nature in the grand scheme of PCI compliance, and so it is a game we woefully play.

Whenever an issue is deemed a false positive, Canvas Host will submit to the ASV, through the provided interface, necessary documentation about the purported issue, whether it is a back-patched version of SSH that the ASV feels is outdated but in fact is running the very latest version and therefore is secure; Or, if it is in regards to an outlandish request for the server’s primary IP address or even the website’s static IP that should not be referenced with the domain’s SSL — all of which generate a SSL mis-match. In any case, when it comes to a false positive, we want you to know we will do whatever we can to help bring to light that it is in fact not an issue and for which the ASV should grant an exception.

3b. Outdated TLS, and Risk Mitigation and Migration Plans

This part, honestly, makes us chuckle. While TLS 1.0, which is accepted as an older, yet secure and compliant technology, was due for an upgrade, the Payment Card Industry jumped the gun about two years ago, and began informing ASVs of a mandatory upgrade to TLS 1.2 for all website hosting providers. The problem is that at the time, most operating systems and their web browsers only worked with TLS 1.0.

This created a very problematic scenario. On the one hand, ASVs began failing all PCI merchants and blaming the web hosts for not supporting TLS 1.2. Those hosts that did upgrade to TLS 1.2 immediately found that certain Apple OS versions didn’t support it, nor did outdated versions of Microsoft Internet Explorer. So while the hosting environment was now PCI compliance, few visitors to the merchant’s website could access the website!

If you had to choose failing PCI compliance, or hosting a broken website, which would you pick? And so, several of our customers made the decision to cancel their merchant account, firing the ASV as well, and switch to PayPal for checkout purposes, which is handled over at PayPal.com and not the merchant’s website. In essence, the process negated not only the need for PCI compliance, but also the customer’s need for PCI hosting with us. It was a dark day for all.

At Canvas Host, we were faced with an inordinate task, of informing both our merchant customers, as well as fighting an impossible task upstream with various ASVs, many of whom disputed our findings, or who simply didn’t care. As soon as enough egg had landed on the Payment Card Industry’s face, a magic solution appeared: The Risk Mitigation and Migration Plan!

What is it? A templated, form letter that web hosts fill out, addressing concerns about TLS 1.0, how its use is being mitigated, how the host is monitoring for new vulnerabilities, how the host is ensuring that new threats are not being permitted into the environment, and when the host will migrate away from TLS 1.0? All of this can be summarized with the following statement: Through server and firewall technologies, and an actively researched hosting environment supported by a team that knows what it is doing and gives a damn. We don’t phrase it exactly that way, but hopefully you get the point.

There is indeed a deadline for when Risk Mitigation and Migration Plans will no longer be supported: June 30, 2018. Though it is recommended that hosts not wait this long, some large software companies have stated it will still be some time before their OS actively supports TLS 1.1 and 1.2, and lest we cut off our customer’s customers (who use those platforms) from accessing our network, we are going to wait a while before pushing through this upgrade.

Here is what a sample Risk Mitigation and Migration Plan looks like. When responding to certain ASV failures, the following document should suffice for the June 30, 2018 exception.

Risk Mitigation and Migration Plan
Prepared by Canvas Host

1. Where are SSL/TLS 1.0 currently used in your environment? (Description(s) of where and how you are currently using SSL and/or early versions of TLS.

All SSL connections currently use TLS1.0 but also support TLS 1.1 and TLS 1.2. At present, certain operating systems, website browsers, and/or email applications are limited to supporting TLS 1.0. Until such a time as greater adoption of more recent TLS versions occurs, we will continue supporting TLS 1.0. We understand the deadline for this has been extended by the PCI industry to June 30, 2018.

2. How are you mitigating risks with SSL/TLS 1.0? (Description(s) of the level of risk with SSL/TLS 1.0 in your environment and the additional security controls you have put in place to mitigate these risks.)

We monitor traffic and server activity constantly. Any type of suspicious traffic or activity is handled immediately.

3. How are you monitoring for new vulnerabilities associated with SSL/TLS 1.0? (Description(s) of the processes you are employing to monitor for new vulnerabilities associated with SSL/TLS 1.0.)

We monitor and update software daily. We check back patches implemented inside of our software and validate that they are not vulnerable.

4. How are you ensuring that SSL/TLS 1.0 are not introduced into your cardholder data environment? (Meaning, how can you verify that new or upgraded systems connected to your cardholder data environment don’t contain SSL/TLS 1.0?) (Description(s) of changes you are making in your processes to make sure that SSL/TLS 1.0 are not introduced into new environments.)

Cardholder data and all customer data are the responsibility of each customer we host. At present, our environment does support SSL/TLS 1.0, 1.1, and 1.2. Some browsers and devices, as previously noted, do not currently support TLS versions 1.1 and 1.2.

To the best of our abilities, the environment supports the latest/most secure SSL/TLS versions.

5. When will your migration plan from SSL/TLS1.0 be completed? (completion must be no later than June 30, 2018.)

For best practice, we plan to migrate fully away from SSL/TLS 1.0 before the PCI deadline of June 30, 2018, just as soon as we are confident that adequate support for TLS 1.1 and 1.2 have been rolled out to our customers’ platforms, devices, and applications.

3d. Worst case scenario? Fire the ASV

Unfortunately, Canvas Host has given this recommendation to several customers over the past year, whose ASVs refused to listen to us, and refused to accept the very Risk Mitigation and Migration Plan set forth by the Payment Card Industry! In these situations, there literally was and is nothing you, the customer, nor us, the web host, can do. In certain situations, terminating your working relationship with the ASV is in fact called for.

Some merchant processors support more than one ASV. Some do not. Unfortunately, if it is a situation where you are forced to use a specific ASV “or else”, then it may come to a point where we recommend you go the “or else” route. At the end of the day, we have nothing to gain by wasting your time by trying to do the ballet with an ASV that keeps stepping on everyone’s toes. In these situations, the ASV is not acting in your best interest, nor the spirit of why they even exist.

If it comes down to this worst case scenario, please know that Canvas Host is willing to try anything to help you pass compliance, and it is for that reason that we are recommending you work with a new merchant processor. We have an established relationship with an IonPOS, an excellent Authorize.net reseller that offers extremely competitive rates, and which dovetails with TrusteWave, a respected ASV that provides a friendly interface, and whose support staff approach PCI standards in a fair, manageable way.

4. Reaching PCI Compliance

After everything has been checked out, we will make the determination for you to ask the ASV to re-scan your website. If all goes as it should, the report will turn up a pass, in bold, green letters! Additionally, you will be able to place a nice seal on your website that attests to the domain passing compliance, with a datestamp and other verifiable information that is intended to build trust with your customers.

Remember, the SAQ has to be done each year, and you will receive a reminder when it is up for renewal. Also, your ASV will re-scan your website in another three months, and while we can all hope they will give you a pass for the items cleared as false positives or given exceptions through the Risk Mitigation and Migration Plan, we have seen just as many situations in which the ASV suffers abrupt memory loss and requires everyone to go through the process all over again.

If you detect a bit of sarcasm here, it’s because we know how important it is for you to remain compliant, and yet have been through countless hoops for various ASVs, some of whom in our honest opinion simply should not be in business to begin with. Ultimately, we are here to serve you and ensure you reach compliance.

5. In summary….

In the history of our company’s operations, rarely has Canvas Host’s environment passed a PCI scan on the first try, unless it’s the same ASV that recently scanned another customer’s website. In fact, having just met compliance with one ASV, we have grown accustomed to another ASV immediately taking issue with our environment as well. To some degree, ASVs are in the business to find errors — which is fine — but some do it to such a degree, as to undermine the purpose of PCI compliance and instead create a space that devolves into finger pointing.

The challenges of PCI compliance that face you as a merchant, and Canvas Host as your hosting provider, can be overcome through a spirit of cooperation between all parties. If ever you feel overwhelmed by the process, please don’t be alarmed. We’ve been there before, and we understand the steps we must take to help you get there.

While Canvas Host cannot guarantee an “easy” path to PCI compliance, what we can guarantee is our willingness to help you as best we can.