The Payment Card Industry Data Security Standard (PCI DSS) is a set of compliance requirements against which merchants, payment gateways, issuers and other organizations who interact with payment card data are assessed. While there are certain requirement carve outs for service providers or merchants dependent upon the services in scope, the vast majority of the standard is the same for all organizations. While the uniformity in the application of the standard is meant to result in greater consistency in implementing more secure practices across the industry, the fact that all organizations are unique creates certain complications.
In consideration of the organizational differences that exist, we wanted to address the interaction between unified software development and operations (DevOps) and the PCI DSS. The use of a unified DevOps practice is not only becoming more common, but also a more effective means of performing business functions. Cloud environments support the rapid deployment of “cattle” instead of “cats.” Developers are now able to fully patch a system in development, install updated codebases upon the system, and deploy immutable systems into production with minimal delays. Within a series of steps built into the software development model, the DevOps team performs the tasks classically assigned to Network Administrator, Systems Administrator, and Application Developer roles.
How is an organization deploying updates twice, five times, or 16 times a day going to meet PCI DSS requirements?
As some of our clients use the DevOps model, our team has reviewed the PCI DSS from the standpoint of an organization that leverages a DevOps practice, and provided the following insights to meet not only the PCI DSS requirements but also the security-based guidelines represented by those requirements. When broken down by PCI DSS requirement, it becomes evident that organizations that choose a DevOps approach are not combating the standard.
In the area of identifying vulnerabilities, PCI DSS Requirement 6.1 states:
“Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.”
For protecting against vulnerabilities by installing patches, PCI DSS Requirement 6.2 states:
“Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.”
Performing threat analysis and response is a cornerstone of a secure environment. As environments grow, performing a manual review of patches for operating systems and dependencies will become an increasingly large task. To address this, we see and support the updating and patching of systems in development. Performing continuous development on patched systems is a best practice that will subsequently meet the need to apply patches to systems in production.
Initially, this may appear daunting. However, such a process addresses several items in the areas of development and security. Implementing updates and patches as a part of development will quickly make the downstream benefits apparent.
To maximize the security of change control processes, PCI DSS Requirement 6.4.2 states that change control processes must include:
“Separation of duties between development/test and production environments”
Going beyond just limiting access to the cardholder data environment (CDE), the separation of duties supports the use of role-based access controls. Where roles are joined due to a limited number of personnel, this is may not be an option. To meet this requirement in such cases, we suggest that organizations use a set of credentials for the production environment that is separate from those used in the development/test environments. Not only will this directly help address PCI DSS Requirement 6.4.2, but a review of access controls will demonstrate that a user performed a specific role while using an account intended for that dedicated purpose, which establishes accountability.
Security standards evolve more slowly than the technology the standards are meant to govern. Build security into the development and deployment processes instead of viewing security as an afterthought or overlay. Engage staff to understand how this can be done while mitigating or minimizing bottlenecks. While this is more easily said than done, by looking at the risks within the environment and the intent of requirements, organizations utilizing a DevOps model can implement controls and processes to support rapid deployment without sacrificing security.
Have security questions for our team of experts? Ask now, we would love to help.
