To comply with PCI Requirement 6.4, you must follow change control processes and procedures for all changes to system components. This requirement aims to have appropriate separation in two places – keeping people separate and keeping systems separate. Compliant change control processes and procedures will include:

In an AWS environment, compliant with PIC Requirement 6.4 means having a framework and a policy to enforce separation between the development or testing environment and the production environment. By using the AWS Well-Architected Framework or the AWS Well-Architected Tool, you can maintain secure change control processes. IAM roles and access controls will also play an important role in logical separation. Be sure to follow security best practices in IAM when delegating access for developers. 

When you look at PCI Requirement 6.4, we’re looking at two important concepts and that is keeping things separate from one another. We’re keeping systems separate from one another and we’re keeping people separate from those systems, as well. So, let’s talk about separating systems, first. You want to keep development separated from production. When we come in to do a security audit for our clients, for example, we want to see that those are distinct environments, that there is no connectivity between them. As we look at your network diagram and the way your architecture is put together, we want to ensure that those environments cannot cross-pollinate and there won’t accidentally end up being any test data in production and vice versa. Having a framework and a policy that you follow to keep those environments separated is very important. You might look at the AWS Well-Architected Framework. You might also utilize the AWS Well-Architected Tool which is based on the framework, which gives you those best practices and the advice and guidance on keeping those systems separated from one another. 

Furthermore, we will look at your IAM roles to determine who are the people who develop? Who are the people who have access to production? There will be follow up questions for any individuals who have that access to production. What is their involvement with development and can there potentially be an opportunity for them to access both environments? Your team might not be large enough to have dedicated people who are only in development, who are only in QA, and who are only those responsible for pushing code to production. For smaller environments, one of the things that we look at in your IAM roles is maybe establishing separate accounts, so that you can keep that logical separation. Whenever someone is developing, they’re using one role as a developer, but then they have to log out and log back in with a role in order to push to production once the necessary approvals are made. These are what the requirements are in 6.4 in the PCI DSS. The point of it is to eliminate any accidental or mistaken access that could impact either the development, testing, or production environments.