Compliance is a journey, not a destination—an ongoing, multistep process. It is not boxes to check off—check it 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 organizations “cram” for their annual assessment in a short period of time. Be aware, however, that auditors and regulators are becoming increasingly savvy about this approach and can identify the key markers when presented with evidence. Instead, being continually compliant along the way will help improve an organization’s security posture and reduce its overall risk. With this approach, successive inquiries will go smoothly 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 organization that stores and/or processes credit card information. PCI DSS compliance, in itself, will not make an organization secure; instead, organizations should treat the guidelines as basic mileposts with which to design their cardholder data environment. This is critical to ensure the security of payment card transactions and cardholder data. Too often the approach taken by merchants and payment processors is to do the minimum requirements when, in fact, there is much more that can be done. Given this, merchants and service providers who are subject to PCI DSS know that achieving and maintaining compliance can be difficult, time-consuming and costly. However, there are some very basic concepts that will greatly reduce the complexity and time it takes to achieve compliance.
Too often the approach taken by merchants and payment processors is to do the minimum requirements when, in fact, there is much more that can be done.
Confusion surrounding the requirements is understandable. There are more than 200 line-item requirements, and many aspects of the standard are open to interpretation. It is critical to remain aware of the newest guidance and new mandates. For example, PCI DSS 3.2 introduced the need for multifactor authentication for any personnel needing administrative access to the cardholder data environment (CDE). The deadline for businesses to adopt PCI DSS 3.2 was 2 February 2018. Since achieving and maintaining PCI DSS compliance is an ongoing process, there is still time to 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 6 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 antivirus 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 identification 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 more than 220 subrequirements to meet, some of which are intentionally vague. According to Verizon’s 2017 Payment Security Report, there are more companies failing their interim PCI DSS assessment than ever before. The interim assessment is akin to the halfway point to the formal, annual validation assessment. These assessments evaluate controls, determine the compliance status of an organization 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.
Three Milepost Markers on the Road to PCI DSS Compliance: Use Validated Solutions
It is wise to be leery and check credentials when turning to professional services for compliance regulations and assessments. They must provide the technical expertise and regulatory experience to help the organization perform PCI DSS compliance audits and write PCI DSS Reports on Compliance (ROCs). It may sound obvious, but there is a surprising number of non-QSA companies that “do that PCI compliance thing.” The reality is, there is a dark side to compliance, including PCI QSA companies that give false ROCs. It is also highly recommended that organizations avoid producing their own hardware/software. It may seem like the economical choice, but there are ample customizable options and solutions to meet a diverse range of business needs. The PCI Security Standards Council maintains a database of current validated solutions. The “secret sauce” for a large number of merchants is to reduce the burden to the organization by simply purchasing off-the-shelf solutions that are already compliant. This helps simplify the overall process of compliance, especially if the organization has chosen solutions that provide end-to-end encryption to the acquirer. Additionally, it is important to identify points where manual entry might occur.
Define and Secure the Cardholder Data Environment (CDE)
This is the number-one problem when a QSA walks into an organization that is 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 the CDE. This includes networking devices, authentication servers and hypervisors. The best approach is to use multitier 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. When a card is displayed on most retailer websites, it is usually truncated. Adding a new card does not permit anyone to see that card after it is entered. Once the CDE is defined, that environment must permit administrative access only via a “jump-box” from a permitted workstation.
Once the card environment is isolated, the organization can start to approach security by asking, “How can data be extracted from this network?” It is advisable to 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, patching and update servers that live within that environment should be utilized. Examples of patch distribution servers are Windows Server Update Services from Microsoft and Corporate Software Inspector from Flexera. It is also necessary to scan the CDE regularly to ensure that patches are installed and no vulnerabilities exist.
Encryption must be used at all levels within the CDE: when the data are at rest, in flight and in memory. 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, primary account numbers (PAN), or tokenize them in some way that removes the card number from the environment altogether.
Know the Risk
Regular risk assessments should, by default, be included in the organization’s process for PCI compliance. At a minimum, a risk assessment should be performed every time a documented change is made within the CDE. This is standard with any change management process. Organizations are required to receive a PCI-ASV (Approved Scanning Vendor) scan at least once every quarter. Any issues found with each scan must be addressed and the steps taken for remediation documented.
Compliance efforts help build a strong security posture. Ideally, the security posture will become more efficient and effective over time through continuous improvement—just like every other business process. Following are some common mistakes organizations often make while on the road to PCI DSS compliance.
Purchasing Outdated Equipment
Often, to save money, organizations will go to the gray market (e.g., Ebay) to purchase older gear. The bad news for this approach is that this equipment often comes 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 the organization out of compliance with the PCI standard.
No Insight Into Data Trajectory
Often overlooked, but no less important, is understanding how the organization’s data are flowing through its network. The ability to identify and locate data with pinpoint accuracy is key to understanding what risk scenarios are applicable to the data. Additionally, it will be a requirement in isolating the CDE.
Avoiding Patches
Three common problems found when assessing environments for patching are:
- Stakeholders fear patches might break their application (or, the vendor told them not to patch).
- Application downtime is simply not desired/not possible.
- The network includes devices that have never been considered for patches (e.g., printers, network devices).
The bad news for all 3 of these scenarios is that the standard does not allow for these types of excuses. The environment must be patched regularly, and all devices that have firmware must be up to current revisions. If a payment application is overly sensitive to patches, a new payment application should be considered. This holds true especially if the vendor has told the organization not to patch. Downtime can be addressed by designing and utilizing services that are able to use load balancing during deployment. With a load-balanced environment, it is possible to perform rolling upgrades of that environment. Modern development and operations (DevOps) approaches have great power in addressing the problems of rolling upgrades. Finally, devices that have firmware must be patched. If the devices are no longer supported by the manufacturer, a replacement device should be acquired or the devices must be isolated from the CDE.
Bad or Incomplete Advice From Websites, Friends, Vendors
The PCI Security Standards Council maintains a section on its website that provides complete guidance on the standard itself. It is highly suggested that unless someone in the organization or the organization’s vendor is a QSA, the PCI guidance to implementation should be the first source consulted.
The article offers a basic jumpstart to the PCI compliance journey. As the organization travels ahead, it likely does not want to travel alone, nor does it want hastily concocted solutions to be a roadblock. A validated road map with well-integrated and validated solutions is the way to go.
Tyler Hardison, CISSP, PCI Qualified Security Assessor
Is the chief technology officer at Redhawk Network Security, where he plays a key role in leading new product strategies and initiatives and is responsible for developing technology solutions and service offerings for clients. He is highly regarded as a hands-on technologist with a strong focus on regulatory issues, program management and secure implementation. With his extensive knowledge of evolving cybersecurity threats, Hardison leads the development and execution of innovative, robust and secure information technology environments for organizations of all sizes. He has extensive experience and knowledge of security and IT, including regulatory issues and compliance, enterprise architecture, disaster recovery, process improvement, custom application development, and risk management. Hardison is a 20-year technology veteran, with 12 years of experience in the financial services industry, including serving as chief information officer at Stanford Federal Credit Union. He is at the forefront of regulatory changes, with in-depth knowledge of the tools necessary to stay ahead. He is a PCI Qualified Security Assessor and speaks regularly on how businesses can meet compliance.