Your organization may feel as though its ready to be PCI DSS compliant, but do you really understand the complexities that come with this undertaking? The multitude of short and long-term intricacies that your business must adhere to is mind boggling. Are you truly ready to take the blue pill and fall down that rabbit hole for your company’s foreseeable future? Well, if you want to keep accepting credit cards at your point of sale (POS), you’re going to need to do more than just cram before your required PCI compliance scans. When 45% of businesses continue to take card payments even though they fail to comply with payment security regulations, you don’t want to become another data breach statistic. To fully grasp the density of requirements surrounding PCI compliance, follow us down the tunnel where we will detail the 4 levels of PCI compliance and the usefulness of PCI administrative access.
We have identified in our past blog series how important being PCI compliant is for businesses that accept credit card payments at the POS. Being PCI compliant allows companies to sidestep fines and remain a viable option for consumers who seek peace of mind in their POS transactions. As a quick refresher, the most recent version is PCI DSS 3.2. Version 3.2 was introduced in April 2016 and officially replaced version 3.1 on February 1, 2018 as the standard all companies must follow.
PCI compliance levels
Whether you’re a single brick-and-mortar retail location or you’re a large organization selling goods across multiple stores and ecommerce sites, your credit card merchant account requires attention to stay connected and integrated. With roughly 80% of organizations still not PCI Data Security Standard (PCI DSS) Compliant, it would behoove your company to stay ahead of the curve based on your compliance level which is ascertained by totaling your credit card transaction volume that your organization processes which are aggregated and quantified across multiple channels.
There are four levels of PCI compliance that your organization can potentially fall into with Level 4 being the lowest level and Level 1 being the highest level:
Below is a more advanced look for your organization to get a better understanding of the intricacies of each PCI compliance level:
Level 4 – The only difference between level 4 and level 3 companies is that your credit card processors will not verify whether you’re meeting the Data Security Standard (DSS) requirements if you are a level 4 organization. That means the responsibility, and the liability, falls squarely upon your shoulders.
Level 3 – You are still required to sign up for quarterly scanning and complete your SAQ. The difference is that now you need to have that information validated when it is submitted to the payment processors.
Level 2 Level 3 & 4 PLUS staff that performs the self-assessment must attend and pass a yearly training and accreditation for PCI SSC ISA if they want to keep using the option of self-assessment for PCI compliance validation. If your company meets the Level 2 requirements for American Express, your SAQ must be certified by the CEO, CFO, CIO, CISO, or other principal. Level 2 organizations can opt to have their assessment performed on site by a Qualified Security Assessor (QSA).
Level 1 Companies that meet Level 1 must have yearly on-site reviews by an internal auditor and a required network scan by an Approved Scanning Vendor (ASV).
PCI Compliance Scan
After meeting the initial security requirements of PCI compliance, all agencies and service providers must annually validate that they are still in compliance by passing a vulnerability scan performed by an approved scanning vendor based upon their number of card transactions or size of the agency. The Council sets the standards for PCI security but each payment card brand has its own program for compliance. Specific questions relating to compliance would be best to be directed to your acquiring financial institution.
Internal and external vulnerability scans are conducted in a similar manner. Both scans are automatically administered via a computer program and an Internet connection. An external vulnerability scan looks for holes in your network firewall(s), where malicious outsiders can break in and attack your network. An external vulnerability scan, on the other hand, checks to be sure all back doors are locked and impassable, while an internal scan searches the network to ensure that its infrastructure is properly secured and free of intrusions. A vulnerability scan is designed to be nonintrusive. At a high level, scanning tools run a series of if-then scenarios on your systems, also known as a scan, which typically takes 1-3 hours, depending on your environment. It simply scans and provides a logged summary of alerts for you to act on. Unlike penetration testing, a vulnerability scan doesn’t exploit vulnerabilities in your network.
If your system receives a failing grade on its compliance scan, it can be almost impossible to know for sure exactly what went wrong. 45% of all companies don’t currently comply with the PCI DSS rules, which will ultimately give way to a scan failure of their system when tested for vulnerabilities. If you failed your PCI scan due to having a flaw in your system, there are a myriad of different patches that are available for the most common vulnerabilities. If you failed your compliance scan, you can apply for an extension while you formulate a solution for to patch the vulnerability and your credit card processing partner will be able to assist you.
Self Assessment Questionnaire (SAQ)
The SAQ is a relatively short document (i.e. five or six pages long) and can take many hours to complete by a qualified individual from within your organization. Some tests vary in range from 30+ questions to more than 300 questions. If you’re not sure which assessment is right for your business, you can always double check based on the below chart that details the appropriateness of each SAQ and the requirements necessary to pass each assessment:
| Assessment | Appropriate For | Not Appropriate For | Vulnerability Scan Needed? | Requirements |
| SAQ A | Card-not-present merchants (e-Commerce or mail/telephone order) | Face-to-face channels | No | No electronic storage, processing, or transmission of any cardholder data on the merchants systems or premises. |
| SAQ A-EP | e-Commerce merchants | Anything other than e-commerce channels | No | No electronic storage, processing, or transmission of any cardholder data on the merchants systems or premises. |
| SAQ B | Brick and mortar or mail/telephone order merchants | e-Commerce channels | No | No electronic cardholder data transmission, processing, or storage. |
| SAQ B-IP | Brick and mortar or mail/telephone order merchants | e-Commerce channels or merchants using the Secure Card Reader (SCR) | No | PTS-approved payment terminals with an IP connection to the payment processor, and that have no electronic cardholder data storage. |
| SAQ C-VT | Brick and mortar or mail/telephone order merchants | e-Commerce channels | Yes – but Penetration Tests are not required | Virtual terminal on one computer dedicated solely to card processing. No electronic cardholder data storage. |
| SAQ C | Brick and mortar or mail/telephone order merchants | e-Commerce channels | Yes – but Penetration Tests are not required | Payment application connected to the Internet, but with no electronic cardholder data storage. |
| SAQ P2PE-HW | Brick and mortar or mail/telephone order merchants | e-Commerce channels | No | Must use approved point-to-point encryption (P2PE) devices, with no electronic card data storage. |
| SAQ D | Merchants and service providers only | Yes – Vulnerability & Penetration Tests are required | No outsourcing of credit card processing or use of a P2PE solution. |
*Any companies that meet PCI compliance Levels 2, 3 or 4 must complete the PCI DSS SAQ annually and undergo quarterly network security scans with an Authorized Scanning Vendor (ASV).
Approved Scanning Vendor (ASV)
A Payment Card Industry (PCI) ASV is a company that has been qualified and officially certified by the PCI Security Standards Council (SSC) to perform external vulnerability assessments as required by entities wishing to comply and gain certification via the Council. A full listing of PCI Compliant Approved Scanning Vendor (ASV) can be found here. Businesses on this list have all undertaken extensive testing from The Council that ensures their scanners (and employees running those scans) are cutting edge. The tests cover how potential ASVs handle scan requests from their customers, perform scans, and report scans.
To pass a PCI ASV verification, all items that have been identified as being Critical, High, or Medium (or with a CVSS score of 4.0 or higher) as well as automatic failures must either be remediated or disputed by the customer. All disputed items must be resolved, accepted as exceptions, accepted as false positives, or mitigated through the use of compensating controls. For more on this process, feel free to peruse and review the PCI DSS ASV Program Guide here.
PCI Administrative Access
With the rollout of PCI DSS 3.2 from the PCI Security Standards Council (dubbed The Council in mentions hereafter) in early 2016, there have been a slew of new obligations introduced to entities regarding remote and administrative access to the cardholder data environment (CDE). Under PCI DSS 3.2, any individuals with non-console administrative access to systems that handle credit card data must authenticate using multi-factor authentication (MFA). Organizations have until June 30th, 2018 to complete their migration with a documented confirmation from an Approved Scanning Vendor (ASV). If they have not yet completed the migration, the organization must have implemented a Risk Mitigation and Migration Plan and are working to complete their migration by the required date.
An SSL Certificate is a digital computer file that has 2 specific functions: Authentication/Verification and Data Encryption. SSL uses the Message Authentication (MAC) algorithm – a message authentication code (MAC) is a short piece of information used to authenticate a message and to provide integrity and authenticity assurances on the message. Integrity assurances detect accidental and intentional message changes, while authenticity assurances affirm the message’s origin.
Transport Layer Security (TLS) uses a keyed-hash message authentication code (HMAC) algorithm that is specifically constructed to calculate a MAC involving a cryptographic hash function in combination with a secret cryptographic key. Implementing TLS over SSL will give an organization sturdier authentication, privacy and integrity, interoperability, flexibility, as well as easier deployment and use. It is highly recommended that if your organization wishes to remain PCI compliant that it implements at least to TLS v1.2 to safeguard payment data as much as possible. Migrating to early TLS must be done in an organized fashion to ensure that Point of Interactions (POIs) and their termination points all have up-to-date patches and are using the necessary extensions.
Basically, PCI administrative access can be configured via a console or non-console configuration with the configuration requiring a specific level of authentication based on standards set by the Council. The specific mechanisms that your business chooses to implement to adhere to these standards will ultimately depend on how stringent your company wishes to set their administrative access protocols. It is in your best interest to formulate a methodology of authentication to stymie potential hackers without affecting the user experience of your credit card processing platform.
Console vs Non-Console
PCI DSS defines non-console access as logical administrative access to a system component that occurs over a network interface rather than via a direct, physical connection to the system component. Non-console administrative access includes access from within local/internal networks as well as access from external, or remote, networks. In laymans terms, non-console administrative access refers to the instance where your system is accessed over a network.
Multi-Factor Authentication
Past iterations of PCI DSS specified that businesses only had a two-factor requirement, but for only remote access. In a nut shell, MFA is essentially another way of branding two-factor authentication (2FA). Thus, console based administrative authentication still only utilized multi-step authentication which has been shown time and again as being far easier to bypass as a method of verification. Multi-factor authentication (MFA) prevents remote attackers from gaining access to your network or email system by guessing weak passwords. Once an attacker is in with a normal user account, they can gather network information and pivot to gain elevated privileges. MFA would mitigate this risk. PCI DSS 3.2 now enforces MFA for companies to authenticate their accounts.
A MFA solution must not provide any indication of success or failure of any individual factors before granting access. It refers to authentication mechanisms where the two authentication elements fall under different categories with respect to something you have, something you are, and something you know. Typically, we usually see a successful implementation having a username/password (something you know) and access token (something you have) to meet the minimum of two factors required.
For MFA to work, the organization must implement authentication mechanisms that are independent of one another, to ensure that access to one factor does not grant access to any other factor and negatively affect the integrity or confidentiality of any other factor. For example, if the organization is using SMS for Authentication, it must align its process with that of the Councils expectations, by ensuring the token is sent regardless of the passwords validity, and that any subsequent authentication denial would not indicate which of the factors, password or token, were invalid. If the solution prompts the user to provide the second factor only after receiving a valid first factor, then it is what the Council considers to be only multi-step authentication on par with using two successive passwords which is not acceptable to meet the PCI requirement for MFA.
Regardless of whether the user is in the CDE themselves where they are looking to gain administrative access to a system, the Council specifies that they must use MFA. Using MFA to increase your authentication strength based on deterring user access to your CDE to make changes from untrusted networks, reduces the risk of weakened security controls, compromises and data breaches. The fact remains: 69% of consumers would be less inclined to do business with your organization if you’ve experienced a breach. Building this strong defensive network security structure can provide you with a much greater level of assurance in the identity of the individual, as it is much less likely that an attacker will be able to compromise both authenticating factors.
Concluding Thoughts
Don’t wait until your cardholder data environment (CDE) is compromised and your user data is stolen before acting with PCI compliance. Be proactive and plan now to update your compliance quarterly in alignment with the Councils requirements and be sure that you’ve doubled down on your efforts to do so by putting it all in your budget for the foreseeable future.
Download Our PCI DSS Checklist
Assess where your organization currently stands with being PCI DSS compliant by completing this checklist. Upon filling out this brief form you will receive the checklist via email.
