The combining of development and operations provides some enhanced capabilities for the security team as well. In this video, you’ll learn about DevOps and how security is integrating into this new structure of application development and deployment.
<< Previous Video: Development Life-Cycle Models Next: Version Control and Change Management >>
Traditionally, there have always been two sides to IT. There are the developers who work on creating the applications that we use, and then there is the operations side of IT that deploys and maintains these applications. But what if you were able to combine those two sides of the house together, to create one cohesive unit? That’s the idea behind DevOps, or Development and Operations.
If you can combine together development, quality assurance, and operations into one single entity, you’re able then to create and deploy applications much faster than you’ve been able to in the past. The ideas that you’re getting rid of, the barriers that used to be in place between the development team and the operations team, and you’re effectively having everyone part of one single team. With DevOps, the emphasis is on automating a lot of this process and making it something that can be monitored over time. That way, you’re able to integrate, test, release, and manage the application. And in some cases, the entire process is hands off.
This means that the overall process of development and deployment should be much shorter, which also means there should be more deployments occurring over time. Now that more organizations want to move to more of a DevOps model, the need for security becomes even more important, especially since there is so much more application development work taking place. The security team can be integrated directly into this application development process and create a series of automated tests that can occur along the way as the application is being created.
The integration of these automatic tests doesn’t require any additional manpower. So you should be able to set processes in place that are able to run a number of security tests very early on in the development process. Some of the tests that you can do would be functional tests– make sure that everything is able to log in properly, log out properly, and make sure that the platform that everything is running on remains secure. You can also test against known vulnerabilities and shortcomings. So you can check the platform, make sure there is no weak ciphers, or misconfigurations that may impact the security of the application.
It’s also easy to automate penetration tests so you can constantly test that the application and the operating system are secure against any type of attack. And of course, you can perform automated tests on the security of the application itself. You can try different types of input and see how the application reacts to these unexpected values. During the development process, code is constantly generated. And usually, there is a central repository where everyone’s code is finally collapsed together to be able to form the final application.
With all of this constant development process, there’s so many different opportunities to introduce security problems into the code. So ideally, there should be a basic set of security checks that can occur during the development process, a bare minimum of security so that if anything happened to be introduced into the code, you can catch it very early on in the development process. Once the code is finalized and moved into a testing phase, you can begin a much larger scale security analysis of the code. That way, you’re able to tell if it needs to go back to the developers or if you’re ready to deploy it into production.
Imagine if you had an application, and every week there would be a few minor changes to the code, and you would process and upgrade to the application every week. What if at the end of a year, you’ve been asked to also recreate this application on another server? The problem is you would have no way to go back over the entire year and easily rebuild what the application is supposed to look like. That’s why many applications are deployed as immutable systems. These are systems that cannot change. Once you have deployed this application into production, the application is not going to be modified at all.
If somebody realizes that a patch needs to be made or an update to the application is due, then the entire platform has to be updated. That way, the entire iteration from beginning to end can be tested, and then finally deployed. And if you need to revert back to a previous version, you simply grab that previous immutable system and deploy the entire system at once. This means there won’t be minor updates over time that might introduce a security issue. With a single immutable system, you can perform an overall security check and then know that you’re going to deploy a secure application.
In a pure cloud computing environment, you don’t have any hardware that you have to deal with. Everything is software-based, and it’s in the cloud. It’s very common in this type of environment to rely heavily on automation to be able to deploy these new applications. For example, what if you needed to roll out a new application that needed a web server and a database server? You can roll those out easily in a cloud computing environment by automating the process of building these servers and loading the software onto these systems.
By automating this application rollout, you can deploy the application to where it needs to be used the most. One of the challenges we’ve always had though, is that there are a number of infrastructure devices behind the scenes that also have to be deployed with the application. You’ve got server hardware, and switches, and routers, and firewalls, and other infrastructure devices. But what if you were able to take those infrastructure devices and also create them virtually? And that’s what we have today with the infrastructure as code, or IAC.
Everything is virtualized. And when you deploy the application, you’re also deploying a series of virtual switches, virtual routers, and virtual firewalls. This allows the organization to think very differently on how they’re going to deploy the applications. Instead of worrying about the back end infrastructure, you worry about the need of the application, and simply deploy it to where it makes the most sense. This is also a great benefit for security because you know when the application is going to be deployed. You will also be able to deploy all of the necessary security tools as well.