It’s a long road between development and production. In this video, you’ll learn about the deployment process and how to secure every step along the way.
<< Previous Video: Peripheral Security Next: Embedded Systems >>
Here’s a common challenge in many organizations. You’ve got a development team that has been working for months programming a brand new application. Now you’re ready to deploy the application. What is the process that you should follow to be able to deploy this application safely and reliably?
Even if you don’t have your own development team, you still have the challenges of deploying new versions of software. A good example is after Patch Tuesday. Microsoft releases a whole new set of security patches for Microsoft Windows. Well, then how do you roll out these particular updates? Do you test and deploy all of them Wednesday? Do you wait until Thursday? Is this something you do over the weekend?
This is the common process that you have to manage. You have all of this non-production software that somehow has to get implemented into your production environment, and it has to be done safely and with as little downtime as possible.
It’s common for your development and testing process to take place in a sandbox. A sandbox is usually implemented as a virtualized system that has no type of connectivity to the outside world or your production systems. Inside of the sandbox you’re able to change code, implement new systems, and see what the results might be without affecting any of your production environment.
Sandboxes are commonly used during the development process, so there can be incremental changes made to the base code and people can see how things are changing as they continue down the development process. Once you get outside of the sandbox, you may have a secure environment available for development purposes. There may be code writing that takes place on these platforms, and the developers can then take that code, move it off to a sandbox for additional testing.
The testing environment may be one that looks very similar to the final production environment. This allows developers to put code into the system, put all of the pieces together, and see if they operate in exactly the same environment that the production systems would run in. This is usually the environment that quality assurance uses to test the system and make sure there’s no bugs. And if everything works in this testing environment, we can stage all of that code and prepare it for production.
The staging environment is one step away from production. This is where everything works and feels exactly as it’s in a production environment. You would usually be working with a copy of the same data that you would use in production. And this allows you to run performance tests and make sure that everything inside of this is running with the same usability that’s expected.
Once we’ve run this application in the staging environment, we’re ready for production. We can make the application live and roll out all of these updates to the user community.
When you’re deploying this new application, how can you confirm that it’s secure? There should be a set of baselines that define exactly how this application should perform. You should know exactly what firewall settings are required for this application to operate, the patch levels of the operating system that must be installed to have this application maintain its security, and all of the different operating system file versions that are required for this application to be secure. There may be constant updates to this baseline as well, as the operating system patches change and as the application is updated.
Once you’ve created the secure baseline for this application, you can then test against that baseline periodically and make sure that all of the components used with this application are maintaining this minimal secure baseline.