Best Practices for Change Management in AWS
What to Include in Change Control Procedures
PCI Requirement 6.4.5 addresses change control procedures. The PCI DSS states that change control procedures must include the following:
- Documentation of impact
- Documented change approval by authorized parties
- Functionality testing to verify that the change does not adversely impact the security of the system
- Back-out procedures
During an assessment, an auditor will observe your AWS environment to see if you’ve implemented thorough and thoughtful change management procedures. Everything dealing with change management must be documented to prove compliance. By using the AWS Well-Architected Framework or the AWS Well-Architected Tool, you can maintain secure change control processes. The AWS Well-Architected Framework addresses change management under the reliability pillar by addressing how to monitor workload resources, how to design workloads to adapt to changes in demand, and how to implement changes.
Transcription
PCI Requirement 6.4.5 speaks to your change management practices that you have within your organization. When we walk through this with our clients, we’re looking at the method that you use to track the changes that you are implementing into production. You might have a ticketing system or some other method that you’ve put into place within your organization to keep track of your changes. That’s important for the audit because we will look at the sum total of the population of all of those changes and we will select samples in order to verify that your change management practices are being followed. One of the things that we would want to see in a ticket are these 6.4.5 requirements. Have you documented the impact to the system? Before a change can be approved, you have to have proper documentation as you’ve evaluated what the impact of this change is going to be. We will look into your method as to how approvals are gained for that. Who is responsible for approving the change? Are they appropriately qualified and in a position to be the one to approve those changes? We’re going to look at the impact to the security of the application.
When it comes to the PCI Data Security Standard, security is at the forefront. In your process for managing these changes, you have to have a step that speaks to security. When a change is being made, have we followed OWASP as an industry-standard best practice for this code that has been developed for this change? Are we running a code review tool such as a Veracode or maybe some open source code review tool in order to evaluate common coding vulnerabilities within the change that we’re making? That’s something we want to see evidence of. Finally, we will want to see backout procedures. Are there procedures established once a change is made? If something that was unexpected or had a negative impact to your environment, did you have the proper and necessary procedures to back that out to go back to your original state? Please evaluate your change management processes and look into how you can have that documentation ready as you want to strive to comply with PCI Requirement 6.4.5.