Version control and change management procedures are important to both the operations team and the security team. In this video, you’ll learn about the security concerns associated with version control and how change management can be part of a safe infrastructure.
<< Previous Video: Secure DevOps Next: Provisioning and Deprovisioning >>
There are always going to be changes to an application. It’s guaranteed, because you’re going to have people that want new features added to the application, someone may identify a security problem, or you may need to integrate some bug fixes into the existing code.
During the application development process, there are an extensive number of changes made to the code, and you need some way to provide version control as you’re performing this application development process. There are also changes that occur when you are ready to move the application into a production environment. This formal change management process is one that becomes very important to maintain the up time and availability of all of your applications.
With version control, you can track the changes that are made to a particular file. So you can make change after change after change, and then you can go back and look at all of the different changes that have been made over time. We commonly see this used with software development.
But we also see it in the operating systems that we use today, and some of the cloud-based storage functions that we have available to us. This is very useful from a security perspective, because you can really compare how things have changed over time. And if certain files were modified, you could see exactly how and when those files were changed.
This version control can also introduce a number of security concerns. If you have a document that contained confidential information, and then you delete all of that information and provide the file to someone else, they may be able to use version control to revert back to the previous version and be able to see all of that confidential data.
If you’ve ever worked in an operations environment, then you know a lot about change management. Nothing changes with any of the infrastructure, unless there has been a formal process to evaluate what’s going to happen when you make that change. The formal change management process usually starts with a plan to make some type of change to the infrastructure. During that process of planning, you also have to determine what the risk will be for making this change to the infrastructure. And then, if the change doesn’t work, you need some way to revert back to the prior configuration.
Normally, you would perform a series of tests before implementing this change, document everything that you’ve done, and then get a final approval to begin the change management process. Normally, you would document this entire process, and then get a final approval and a schedule of when you can make the change. And then, finally, the change can be implemented in your production environment.
Every time a change is made, you have to evaluate what type of security component is going to be associated with this change. Even if you install a security patch, which, ideally, is going to make your system more secure, there may be another security component associated with that that would affect your application. The same thing applies if you’re going to update the application itself. There’s new versions and new code, and therefore new opportunities for security concerns.
And you have to consider that a change in one part of the application platform may affect the security in a different part, as well. So if you’re updating servers, you will still have to test the entire application flow, to make sure everything remains secure.