Compliance is a journey, not a destination.
While I am not the first to say this, I will reiterate that compliance is an ongoing, multi-step process. It’s not boxes to check off, “check it off and forget it,” but milepost markers along the way to ensure that compliance is consistent, such as ensuring that device inventories and configuration standards are kept up to date. Another term that is used for this check-box approach is “compliance cramming.”
This is when companies and organizations cram for their annual assessment in a short period of time. Be aware, however, that auditors and regulators are becoming increasingly savvy toward this approach and can identify the key markers when presented with evidence. Instead, being continually compliant along the way will help improve your company’s security posture and reduce your overall risk. When you take this approach, successive inquiries will be smooth and the stress of the audit process will be reduced significantly.
The Payment Card Industry Data Security Standard (PCI DSS) is a set of standards established to identify the key components of secure data environments for any company that stores and/or processes credit card information. PCI DSS compliance in itself will not make you secure, instead you should treat the guidelines as basic mileposts for which to design your cardholder data environment. This is critical to ensure the security of payment card transactions and cardholder data.
Too often the approach made by merchants and payment processors is to do the minimum requirements when in fact there is much more that you can do. Given this, if you are a merchant or service provider and are subject to PCI DSS, you know that achieving and maintaining compliance can be difficult, time-consuming, and costly. I am here to tell you that there are some very basic concepts that will greatly reduce the complexity and time it takes to achieve compliance.
Are you confused by the requirements? Understandably so. There are more than 200 line-item requirements, and many aspects of the standard are open to interpretation. Are you aware of the newest guidance and new mandates? For example, PCI DSS 3.2 introduced the need for multi-factor authentication for any personnel with need for administrative access to the Cardholder Data Environment. The deadline for businesses to adopt PCI DSS 3.2 was February 2, 2018. Since achieving and maintaining PCI DSS compliance is an ongoing process, you can still get on board.
PCI DSS: A refresher
PCI DSS is a set of industry standards designed to protect payment card data. Comprised of 12 broad requirements, the six key areas, control objectives, and requirements are:
Build and maintain a secure network
- Install and maintain a firewall configuration to protect cardholder data
- Do not use vendor-supplied defaults for system passwords and other security parameters
Protect cardholder data
- Protect stored cardholder data
- Encrypt transmissions of cardholder data across open, public networks
Maintain a vulnerability management program
- Use and regularly update anti-virus software
- Develop and maintain secure systems and applications
Implement strong access control measures
- Restrict access to cardholder data by business need-to-know
- Assign a unique ID to each person with computer access
- Restrict physical access to cardholder data
Regularly monitor and test networks
- Track and monitor all access to network resources and cardholder data
- Regularly test security systems and processes
Maintain an information security policy
- Maintain a policy that addresses information security for all personnel
This all sounds well and good. But there are 220+ sub requirements to meet and some requirements are intentionally vague. According to Verizon’s 2017 Payment Security Report, there are more companies failing their interim PCI DSS assessment than ever before. Think of the interim assessment as the half-way point to the formal, annual validation assessment. These assessments evaluate controls, determine the compliance status of an organizations, and provide recommendations prior to a formal validation assessment—and are carried out by a qualified security assessor (QSA), or internal security assessor (ISA). Verizon asserts that many of the security controls that are not in place could increase the likelihood of an organization suffering a data breach.
Here are three milepost markers on the road to PCI DSS compliance:
Use validated solutions.
Be leery and check credentials when turning to professional services for compliance regulations and assessments. You want to look for the technical expertise and regulatory experience to help you perform PCI DSS compliance audits and write PCI DSS Reports on Compliance (ROCs). It may sound obvious, but you would be surprised by the plethora of non-QSA companies who “do that PCI compliance thing.”
The reality is there’s a dark side to compliance, including PCI QSA companies who give “false” ROCs. Another recommendation: Do not “roll your own” hardware/software. It may seem like the economical choice, but there are other ample customizable options and solutions to meet your business needs. The PCI Council maintains a database of current validated solutions. The secret sauce for a large number of merchants is to simply purchase off-the-shelf solutions that are already compliant and reduce the burden to your organization. This will help simplify your overall process of compliance, especially if you’ve chosen solutions that provide end-to-end encryption to the acquirer. Additionally, identify points where manual entry might occur.
Define and secure your cardholder data environment (CDE)
This is the number one problem when a QSA walks into an organization seeking compliance for the first time. The rule of thumb is that any device that has direct access to a machine/database/server that is processing card data is now in scope for your CDE. This includes networking devices, authentication servers, hypervisors, etc. The best approach is to utilize multi-tier solutions that utilize a “gateway” to access card services. In this case, it could be a web application that accepts but has no ability to retrieve or otherwise extract the card data. Think about how your card is displayed in most retailer websites: it is usually truncated. Adding a new card does not permit you to see that card after it is entered. Once your CDE is now defined, that environment must only permit administrative access via a “jump-box” from a permitted workstation.
Once you have isolated your card environment, start to approach security as “how can data be extracted from this network?” Do not permit access to the internet, other than access to security updates and internet-based applications that are utilizing TLSv1.1 encryption or greater, and have a demonstrated business purpose (i.e. connection to an acquirer). Even then, utilize patching and update servers that live within that environment. Examples of patch distribution servers are Windows Server Update Services from Microsoft, Corporate Software Inspector from Flexera, etc. You must also scan your CDE regularly to ensure that patches are installed and no vulnerabilities exist.
Ensure that encryption is used at ALL levels within your CDE: at rest, in flight, and in memory. Remember that drive-level hardware encryption is not enough and the data should be decrypted only at the last possible step for actual processing. All PCI-validated applications already have this implemented. An even better approach is to truncate card numbers (PAN) or tokenize them in some way that removes the card number from the environment altogether.
Know your risks
I regularly discuss the importance of regular risk assessments. This should, by default, be included in your process for PCI compliance. At a minimum, a risk assessment should be performed every time a documented change is made within your CDE. This is standard with any change management process. You are required to receive a PCI-ASV (Approved Scanning Vendor) scan at least once a quarter. You must also address issues found with each scan and document the steps taken for remediation.
Your compliance efforts will help you build a strong security posture. You want your security posture to become more efficient and effective over time through continuous improvement—just like every other business process.
Here are some common mistakes companies often make, while on the road to PCI DSS compliance:
Purchasing outdated equipment
Often, in order to save money, companies will go to the grey market (ebay, etc.) to purchase older gear. The bad news to this approach is that this equipment will often times come without support contracts. Without contracted support, the majority of suppliers will not offer firmware updates to address hardware and firmware security issues. This will put you out of compliance with the PCI standard.
No insight into data trajectory
Often overlooked, but no less important, is understanding how your data is flowing through your network. The ability to identify and locate data with pinpoint accuracy is key to understanding what risks are applicable to that data. Additionally, it will be a requirement when you seek to isolate your cardholder data environment.
Avoiding patches
Three common problems we have found when assessing environments for patching are: patches might break my application (or, the vendor told me not to patch), application downtime is simply not desired/not possible, and devices that have never been considered for patches (printers, network devices). The bad news for all three of these scenarios is that the standard does not allow for these types of excuses. You must patch your environment regularly, and all devices that have firmware must be up to current revisions.
If your payment application is overly sensitive to patches, consider a new payment application. This holds true especially if the vendor has told you not to patch. Downtime can be addressed by designing and utilizing services that are able to utilize load balancing during deployment. With a load balanced environment, you can perform rolling upgrades of that environment. Modern DevOps approaches have great power in addressing the problems of rolling upgrades. Finally, patch those devices that have firmware. If the devices are no longer supported by the manufacturer, seek to acquire a replacement device or isolate them from your CDE.
Bad or incomplete advice from websites, friends, vendors
The PCI Council maintains a section on its website that provides complete guidance on the standard itself. It is highly suggested that unless you, your employee, or your vendor is a QSA, you should first seek out the PCI guidance to implementation.
What I have offered is a basic jump start to your PCI compliance journey. As you’re traveling ahead, you likely don’t want to travel alone, and you surely don’t want hastily concocted solutions to be a roadblock. We have found that a validated road map with well-integrated and validated solutions is the way to go.
