I've been a PCI Qualified Security Assessor (QSA) for PCI DSS requirements for some years, and I have detailed some of the more common mistakes I encounter whenever discussing PCI DSS with organisations, be they business owners, website developers, or service providers.
Believing attacks aren't a real threat and not complying with PCI DSS
To help explain this I'll use an unrelated industry. I spoke to fire station staff that had attended the site of an automated alert of a severe chemical warning incident in a sealed lab (which had no staff in it at the time). The Laboratory person responsible had been raised on the phone, and had to immediately return early from holiday to help enter the potentially dangerous lab and make the site safe. In the aftermath the lab staff member had complained, because they perceived the likelihood of a genuine incident as being low or unlikely. The fire station staff explained to the laboratory owners that although in the laboratories experience, accidents and mistakes were rare, the fire station visited multiple real incidents every day, where accidents have occurred and controls failed. From the fire service point of view, incidents are a genuine risk and likely. As to the impact, ask any fire, ambulance, or police staff about incidents and the conversation will become sober quickly.
In a similar fashion (but not as heroic as the services), a PCI QSA will visit companies to perform post compromise Report on Compliance as a regular occurrence. In conversation a PSI QSA will tell you that companies get compromised regularly, and that typically it's not publicised. However companies handling payments will often disbelieve any risk of compromise being likely, because they haven't been compromised. Yet.
When thinking of the likelihood, it's important to remember that your payment process presents a direct financial motivation to attackers. The people attacking your organisation or ecommerce website are not attempting to impress their friends, or accomplish a technical challenge, they are looking to make money. Your attackers are likely organised, experienced, and have a plan. They will have a good idea of risk versus reward, and will be part of a supply chain for the stolen card details. That is, the attackers that compromise your site are likely subject matter experts in this area and will likely not attempt to misuse the card details they obtain themselves. They will sell the card details to another criminal element who specialises in the area of misusing card details to get the most from stolen details before detection of their activities. In this way the attackers outsource the risk to other subject matter experts, and so effectively a supply chain exists for this attacking industry. The attackers will be constantly watching for new exploits for common ecommerce platforms because there is a financial interest to do so, and will be looking to reverse engineer any security releases released for software, such that not yet updated sites can be targeted. As an example of a PCI DSS control, this is where the patching window requirement comes from, to get your site patched before exploits are reverse engineered, released in the wild, and targeted against your site.
Fundamentally the credit card providers are trying to reduce or stop their losses due to fraud. This has resulted in the PCI DSS standard, which is a collection of requirements that will stop attacks that have already occurred to other businesses. Each time a requirement is ignored, or half-implemented, the risk is that an attacker will have an easier time compromising your site. Once compromised, you'll likely pay an initial fine, followed by having to hire an independent forensics investigation, and then finally having to have an independent PCI QSA produce a Report on Compliance by a specific deadline set by your acquiring bank. If compliance isn't reached by that deadline, more fines are likely to follow.
Believing "PCI DSS doesn't apply to us, as we don't store card details"
PCI DSS doesn't just apply to storing of card details, it also applies to transmitting and processing. As some examples:
- If your website receives credit card details directly from a form submission and then forwards these on, then your site is transmitting card details.
- If you receive payment calls over a VoIP line, your VoIP system is in scope because you are transmitting card data.
- If you take telephone payments and enter card details into a vendor’s payment portal via a workstation, you are transmitting card data, and the workstation and anything on that network will be in scope.
- Even if you outsource all payment via a redirect page on an ecommerce website, you still have a minimum of SAQ A based responsibilities. See below for a fuller discussion of this.
When asked, many organisations will confidently state PCI DSS does not apply to them when using a third party payment provider. The surprise comes with the financial impact of the fines and required forensics investigation.
Even when you've outsourced card processing, so that all aspects are handled by a third party such as Sage Pay or Worldpay or similar, then your website that performs the redirection is still in scope for a small number of controls as it can still affect the security of the card payment process. An attack against a website using a redirect or iframe to third party payment provider would be to inject a payment form into the payment provider selection screen, which had occurred at the last merchant I had to visit. Among the other controls that apply, another example would be that you still have a responsibility to verify that the provider you've outsourced to is PCI DSS compliant (or otherwise evidence that you are tracking their progress to compliance).
Completing the wrong Self-Assessment Questionnaire (SAQ)
In a large organisation the finance section might be given the SAQ to complete without sufficient technical knowledge of the company’s processes, and therefore the wrong SAQ is completed. As an example, SAQ A with 25 requirements is typically completed, instead of the one appropriate for the organisations circumstance.
The SAQs only correspond to specific circumstances, which are defined at the start of the SAQ, but by doing so only a subset of the PCI DSS requirements need to be met. As an example a town shop that only handles face to face payments might be eligible to complete SAQ B with roughly 34 requirements to meet. However if none of the circumstances for any SAQ are matched, then the catch-all is SAQ D with approximately 330 requirements.
After a compromise, and after the forensics examination report is completed, the organisation is given 90 days by the acquirer to become PCI DSS compliant. Becoming PCI DSS compliant to SAQ D within 90 days is normally not possible, due to the volume and depth of the requirements, even for well-resourced organisations. Changing business operations to meet the requirements of an easier SAQ is typically the best approach, but can be stressful for the organisation when done within the short timeframe of a post-compromise deadline.
If you're running an ecommerce site and unsure which SAQ your environment falls into (A, A-EP, or D), take a look at the following VISA guide which performs a walkthrough of the different methods and the resulting SAQ required:
If you're planning to deploy an ecommerce site, it's a good idea to agree with your web developers to use an SAQ A compatible implementation to provide yourselves with a minimal compliance burden. At a minimum, make sure you know which SAQ applies to the payment system you are about to implement, and you have looked at the requirements.
Not understanding that for ecommerce even the smallest SAQ has requirements for the website hosting.
As discussed in the first topic, even though you've outsourced card processing, so that when a client pays all aspects are handled by a third party such as Sage Pay or Worldpay or similar, it's still possible for an attacker to alter the payment options form and so lead to compromise of credentials.
For this reason:
- At a minimum, complete the requirements for SAQ A
- Ensure someone is tasked with responsibility for PCI DSS compliance, and that they have the time resource to obtain and maintain compliance. Ensure they have the backing of management in order to get situations addressed.
- Consider additional controls beyond the requirement, such as an alert when files and directories on your ecommerce site unexpectedly change (File Integrity Monitoring, or FIM).
Note that you will need to talk to your hosting provider as well, if you use a third party hosting provider. You need to agree in advance that they accept their PCI DSS responsibilities for your environment. It is too late to have this conversation when the site is compromised and the ecommerce expert hosting providers are denying any knowledge of PCI DSS and their legal representative has given them instructions in avoid communications in case the compromised organisation sues them.
Not understanding that a passing PCI DSS network vulnerability scan verifies part of your compliance only.
A passing vulnerability scan from a PCI Approved Scanning Vendor (ASV) means your site meets a small subset of PCI DSS controls; this alone does not mean you are PCI DSS compliant. It is just one requirement of the standard, and a passing scan of your site or your service provider means that you were compliant in that one requirement.
Some vendors provide a PCI DSS compliant badge or icon or similar as a result of these scans, however this does not mean the organisations showing this badge are fully PCI DSS complaint.
To give some personal opinion in this area: even if the specific SAQ doesn't require a quarterly vulnerability scan, it's a great idea to sign up to one of these automated scanning services because for a small amount of money you get at least four vulnerability scans a year and the opportunity to look at and investigate anything unexpected. A customer that's had a penetration test done is also a good sign; typically these are done in the process of launching a new site or when making major changes. To my knowledge I've never had to perform a post-compromise Report on Compliance for a customer that has had penetration testing of their environment.
Believing service providers claims to be PCI DSS compliant, without verifying.
Choose your service provider wisely. If you have ecommerce websites, even if you are SAQ A only, you need to have a PCI DSS compliant hosting provider. At a minimum:
- They should be able to provide their PCI DSS Attestation of Compliance (AOC). A good provider will be able to provide this specific document. A worrying sign is if instead other standards are sent over, such as ISO 27001, especially with a statement that this is enough. It isn't as this is a different standard not related to the credit card industry, and it is the PCI DSS AOC that you require, or you will need to track their process to PCI DSS compliance.
- One the AOC is provided, read that document – does it apply to the actual environment you are using? What does it say is the customers responsibility? Was it written immediately, as a result of the request – implying no actual PCI DSS work has been completed?
- View the proposed contract, does it acknowledge their PCI DSS responsibilities for your environment? If this seems like a paperwork exercise, ask yourself if your site is compromised, who will pay the fine, who will pay for the independent forensics investigation, and who will pay for the independent PCI QSA Report on Compliance? Your hosting provider is unlikely to be paying any of this and if they later deny all responsibility and you have no recorded agreement to support your claim to retrieve and damages from them.
Ideally if the service providers Attestation of Compliance has been co-signed by a PCI QSA this is a great sign, as it means an independent assessor has been involved. An exception might be if there are caveats recorded next to the signature, such as to say that the QSA assisted with verbal advice only, in which case read these statements carefully.
If they state they have ISO 27001, ISO 9001, and other standards, then these are indeed good signs (for security and quality management respectively), however they do not relate to PCI DSS, and there is no exemptions or reduction in requirements in PCI DSS for companies with these standards.
Be careful of service providers wording on websites as marketing departments can sometimes be tricky and there are some interesting claims on many service providers sites, such as attempting to use ISO 27001 as evidence of PCI DSS compliance, or of only mentioning PCI ASV scans as proof of compliance. Many will state they are PCI DSS compliant, but ask to see the Attestation of Compliance before you consider believing the claims. Note that just because the hosting company is well known in their niche, or the company hosts sites for famous brands, does not mean they are PCI DSS compliant.
As a real world example: on a recent post compromise audit the service provider produced a Attestation of Compliance that made no mention of the hosting environment, was under a different company name with no mention of the company in use, had been produced by a parent company before the company purchased the site hosting company, and stated only the customer had administrative access, when the hosting provider had already been seen to have an administrative account in support desk communications about other topics. This was not an unresolvable problem, but was only one problem of many on the audit.
Another example: A call centre had been outsourced to handle all payment calls. The service provider had completed the Attestation of Compliance to state that no card data was handled in their environment. When this was queried, an update AOC was produced overnight stating they did handle card data but were fully compliant. Due to suspicions, a visit to the site was arranged, and the operation was found to have no PCI DSS controls in place.
Not reading the warning signs.
If you have an existing ecommerce hosting provider, the following warning signs should be heeded (this is not an exhaustive list):
- The agreement with your hosting provider provides statements that protect the hosting provider from you only. No PCI DSS responsibilities are acknowledged by the hosting provider in any agreement.
- You see that default accounts are present in the administrative interfaces you share, or have visibility of.
- Security updates do not occur within a month of the vendor release. Only the web environment is updated and no party updates the underlying operating system. A general reluctance to apply security updates exists, which could be due to a poor understanding of how it will affect the site.
- Shared accounts are in use, such as logging in to administrative interfaces using the company name as the account name.
- Administrative accounts are present for staff that are known to have left.
- Short passwords are allowed, or passwords that are obviously weak such as dictionary words.
- They have no documented incident response plan.
- They have outsourced the underlying hosting, but see tracking the third parties PCI DSS compliance as an alien concept.
Note that this has been summarised from the minimum PCI DSS requirements, equivalent to SAQ A, and it is not a completing listing of all requirements that may be applicable to your site. These are provided on the PCI documentation site, at the URL below:
If in communications the hosting provider is aggressive or otherwise hostile to the idea of being audited, they are unlikely to have taken part in meaningful external quality assurance processes previously. Problems found are likely to be escalated as political confrontation, rather than technical fixes.
In comparison, the following are usually excellent signs:
- The sales person immediately recognises the term "Attestation of Compliance" and delivers the document to you that day. The document is dated within the past year and may even be counter signed by a QSA.
- Website administrative interfaces that you use can be configured to use two factor authentication, or can be restricted to address ranges belonging to your company. It is a great idea to use these security controls.
- A software update schedule is described to you.
- The service provider states they are willing to be externally audited if required.
The latter likely means they have been externally audited before, although it may be that other customers have audited to different standards.
In summary, your business is not likely to be in the business of PCI DSS compliance, but it you do take card payments, you need to be PCI DSS complaint. This is time consuming and may be difficult to understand at first, and can require expertise to work out how to become compliant, so set aside dedicated resource to ensure it's done well. Even if you reduce the scope and processes so you only have to comply with the minimum requirements of SAQ A, there is still some work to do.