The application development process can be a challenge to implement. In this video, you’ll learn how to securely create and deploy applications from the development process through production.
<< Previous Video: Virtualization Security Next: Provisioning and Deprovisoning >>
If you’re an organization that does your own development work, there’s always a challenge in getting the application from the development process and move it into the production environment. This sounds like something you could simply copy over into production and start using. But there’s many checks along the way to make sure that the process is going to go smoothly.
You also have challenges in rolling out updates to application or patching existing operating systems or applications. A good example is the Microsoft Patch Tuesday, where you need to test and deploy these new patches into your Windows operating system. But do you simply deploy them without testing? Or do you go through a testing process first? And what does that testing process look like? And how long does it take between the time that you receive the patch and the time that it’s deployed into production?
Each of these scenarios where you’re moving an application from a nonproduction environment to the production environment should be very closely monitored. So in this video, we’ll look at all of the different steps that many people follow between the time from beginning to end of the application development process.
There are many uses of the term sandboxing in information technology. But when we refer to sandboxing in this video, we’re referring to the application development process. A sandbox is an isolated testing environment that can be used by the developers to test different aspects of the application that they’re building. They can write some code, run it in the sandbox environment. And if something doesn’t work or goes wrong, the only people it will affect are people using that particular sandbox.
The developer can try a lot of different ideas and concepts with their code, try it in the sandbox, and see what the results might be. And they can do this without worrying that any other part of the production environment or anything outside of development will be affected by what they do in their sandbox. The sandbox can be used over and over again by the application developer to continually build onto the application that they are creating.
The application development process generally starts with a developer. This would be a programmer who writes the code in a secure environment and begins testing out different aspects of the code’s functionality. The developers will commonly use the sandbox to perform tests and will continue to add on to this code until they have an application that they can begin testing.
The testing environment is a bit more formal. The application developers have now created different aspects of the application and are bringing all of that code together to see how all of those different parts will react with each other. This will be the phase where the application developers can check to see if the features and functions of the application are working as expected.
Once the application developers feel that the application is working as expected, they can hand that application off to the QA team. This is the quality assurance team. And since they are outside the scope of the development team, they can really put the application through its paces to see if it’s working as expected.
This would also be the group that tests new features that have been added to the application and make sure that the new capabilities are working as well. This would also be a good time to make sure that any of the old errors that were previously fixed are still corrected in this version of software. Too often, we can deploy new software that accidentally re-enables old bugs. And it’s up to the QA team to prevent that from happening.
Once the QA team has performed their tests, and they feel that the software is ready to be released, there may still be an additional set of tests that need to be done before handing it over to the end users in the production environment. This would be the staging environment. And it’s a chance to test the application in a real-world environment that really does test all of the capabilities that the production environment will call for.
It’s at this staging phase where you might take a copy of production data and copy that over to be used as if it was in a production environment. This will perform a final test of the data. This will also give you a chance to see what the performance of the application might be once it’s put into a production environment. This is the last chance to check the features and usability of the application before handing it over to the users. So this would be a perfect time to put the application through a lot of tests and make sure that it’s ready to go into production.
Once all those previous tests are complete, it’s time to turn the application over to the users and put the application into production. For the end users, this might be one of the most challenging parts of the process because they now have to be trained on the new features and become comfortable with the changes in the application.
The team making this transition into production may also have a number of changes. They might have to implement new servers. There may be additional software that has to be installed. And this may have to restart or interrupt service for the existing production users.
Before deploying this application into production, it’s a good idea to get a security baseline of exactly what is required to secure this application and maintain the security of this application. We want to define all of the important security characteristics for this app. So we want to check the firewall settings that are required to have this application work and still be secure, want to check patch levels of the application and the operating system. And we want to make sure the operating system files are also up to date with the latest security patches.
If we deploy multiple versions of this application instance, then we want to be sure that this security baseline is followed for each one of those instances. And if we make any changes to this application, it could affect firewall settings, patch versions, and any other security aspects. So we want to make sure that we always keep these security baselines up to date.
It’s also a good idea to perform some integrity checks once this application has been deployed into production. This gives you a chance to check the existing production environment and make sure that it matches all of the requirements set on the original security baseline. If you find that the firewall settings, the patching of the operating system, or any of those other important security baselines is not matching in the production environment, then that should be an immediate concern and something that needs to be corrected as soon as possible.