The twelve PCI DSS requirements are some of the most well-known compliance points for companies that interact with customer payment data during the course of normal business practices. Meeting compliance standards can often times be a time consuming and challenging task for organizations. Below, we detail four heavy-hitting wins that help set a PCI deployment for future success.
Defining (or Redefining) the Scope
The PCI scope encompasses any device or host on an enterprise network that comes into contact with cardholder data. Depending on the size of the organization’s network, the scoping of the PCI environment could be a relatively easy or difficult venture; it is understood that organizations with deeply-rooted network configurations, processes, and procedures will find it more difficult to reconfigure their networks for PCI compliance than organizations with more flexible processes and architecture. It is recommended that the network that contains cardholder data, the cardholder data environment (CDE), be as small as possible, and best practices also suggest that machines and devices in the PCI scope be completely segmented from the enterprise network as a whole. This segmentation reduces the overall cost and time spent on the PCI assessment, and significantly reduces the complexity of implementing other controls that are critical to the assessment. From a management standpoint, it also makes the implementation of processes and procedures more clear-cut and assists in risk mitigation; having a tight grip on sensitive information allows for more attentive, enforceable controls. You can address requirements 1.1.2.a, 1.1.2.b, 1.1.3, 2.4.a, and 2.4.b by properly defining and documenting the scope of the PCI network segment.
Applying Network Configuration Controls and Standards
Network configuration controls are critical, and should be applied to firewalls, routers, and other network devices responsible for routing and filtering information on the CDE. From a network architecture standpoint, firewalls should separate the CDE from all wired and wireless networks outside of scope, and should also be configured to employ a DMZ between the CDE and the enterprise network as a whole. For general configurations, firewalls should apply the concept of implicit denial, and refuse all connections that are not explicitly defined by business cases, requirements 1.2.1a, 1.2.1b, 1.2.1c, 1.2.3.a, 1.2.3.b, 1.3.1, 1.3.2, and 1.3.3, 1.3.5, and 1.3.7. Routers should be configured with these concepts in mind as well, and should additionally be hardened against unauthorized access and that their native configuration files are synchronized (requirements 1.2.2.a and 1.2.2.b). For all network devices, it is required that all vendor-supplied default accounts and passwords are changed (requirements 2.1a, 2.1b, and 2.1c). These measures are a solid step to hardening network devices, and can be easily integrated into processes involving the onboarding of new technologies.
Implementing Access Controls
Role-Based Access Controls (RBACs) most accurately describe the restrictions that must be placed on access to in the CDE. Specifically, RBACs limit access based on an individuals’ role within an organization, and can be combined with the concepts of implicit denial and least privilege to create a very flexible, secure identity management schema that is based on the needs of a particular organization. When RBACs are applied to the machines in the PCI scope network and documented properly, requirement 7, as a whole can be met.
Deploying Antivirus Measures
Antimalware measures are another essential need for securing the CDE. While most organizations already have an antimalware solution in place, the PCI DSS explicitly requires that all systems that are common targets of malware, like workstations and servers, have an antimalware solution deployed as a means of defense. The antimalware solution in question must have the ability to detect, remove, and actively protect against all known types of malware, and the solution must be properly configured to perform periodic scans, retrieve automatic updates, and provide a log of its activities while operating on the commonly targeted host or device. For systems that are not commonly targeted by malware, periodic measures should be taken to identify if any malware threats exist for those systems; if malware threats are found to exist for a system, it must be protected accordingly. Users should not be able to modify any of the configurations that are applied to antimalware solutions, and the solutions themselves should not be suspended or terminated unless there is a technically-based need for the solution to be terminated. Requirements 5.1.1, 5.1.2, 5.2.a, 5.2.b, 5.2.c, 5.2.d, 5.3.a, 5.3.b, and 5.3.c can be met if antimalware measures are implemented in a thorough and careful manner.
While meeting PCI DSS requirements can be a stressful and tedious initiative, it is critical for organizations to meet these standards in order to avoid costly compliance violation fines, damage to company reputation, and to mitigate the risk of data breaches. I hope that these four points will assist in your endeavor to strengthen your compliance posture.
[su_box title=”About Jason Smith” style=”noise” box_color=”#336588″]Jason Smith joined the ReliaQuest team in 2015 as a SOC Engineer. He graduated with an M.S. in Cybersecurity from University of Maryland University College. In his spare time Jason enjoys cooking, long walks through cyberspace, and the occasional hat change.[/su_box]
About the Author
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.
