Sign up with your name and email address below to receive our newsletter!
Mar 12, 2018
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 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:
1. Build and maintain a secure network.
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.
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.
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.
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.
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.
Three common problems found when assessing environments for patching are:
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.
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.
Originally posted on Cybersecurity Nexus: View article.
January 14, 2020
CHIEF TECH...read more
November 8, 2019
October 24, 2019
CHIEF TECH...read more
October 29, 2019
October 22, 2019
August 23, 2019
CHIEF TECH...read more
August 21, 2019
CHIEF TECH...read more
August 15, 2019
CHIEF INFO...read more
August 20, 2019
July 16, 2019
CHIEF TECH...read more