DevOpsSec, SecDevOps, DevSecOps: What’s in a Name?
By Jamie Tischart, CTO Cloud/SaaS, Intel Security
Cultural changes come in the form of integrating teams that historically have been disparate around a single vision. Technical changes come with automating as much of the development, deployment, and operational environment as possible to more rapidly deliver high-quality and highly secure code.
This is where I believe the DevOps debate becomes cloudy (sorry for the pun). As is normal in engineering endeavors, we often forget the purpose or the problem we are trying to solve and instead get mired in the details of the process or the tool. We tend to lose site that bringing DevOps together has the purpose of solving how to more rapidly deliver higher-quality, more secure products to our customers, so they can solve their problems and we stay ahead of our competitors.
I found it interesting that there is little information about whether DevOps or OpsDev is the terminology coined but that adding security into the mix has three different coined terms of DevSecOps, SecDevOps, and DevOpsSec. At first I didn’t give it much thought and I figured that over time it would converge into an industry standard and we would move on our merry way of trying to achieve that difficult goal of high-quality, highly secure continuous deployment of cloud services. Then I looked closer and thought that there might be something to these three different nomenclatures and that they highlight the different challenges that security has in integrating into the software development lifecycle.
Let’s talk about the general purpose of including security in DevOps practices. Security was often an assumed part of the development and testing process to which few people paid attention. Or, security was an afterthought that slowed down the development process and release cycle, executed by some other team requiring fixes to obscure vulnerabilities that would never be found or leveraged for harm.
That entire mindset, while flawed, worked reasonably well in the world of single-tenant application development where a 12-month release cycle was the norm and applications were deployed behind several layers of security appliances. This all changed when we started delivering multi-tenant cloud offerings where any vulnerability could put millions of customers and the reputation of our companies at risk. Yet, we still held onto some of these archaic practices. We were slow to integrate secure coding and testing practices into our everyday engineering execution. We continued to leave security activities until the end of cycles and we left many vulnerabilities unattended because it slowed the release. This was until, of course, someone exploited the vulnerability and then everyone dropped everything and all hell broke loose.
Integrating Security into DevOps
Integrating security into DevOps practices is the goal to alleviate these problems. It is the way to continuously evolve security through automated techniques and to achieve our goal of rapidly delivered high-quality, highly secure products. This brings me back to the different terms for integrating security into the DevOps movement and how each organization needs to determine how security is integrated.
Let’s first look at DevOpsSec. Consider the order and how that implies that security still comes at the end of the process. Maybe I am just being paranoid but this is a practice we need to curtail and instead imbed security into every aspect of the lifecycle. If we expound on that a bit and take it literally (and maybe we shouldn’t), the team will complete dev, deploy and operate, and then review security. If this is done in small increments and completed rapidly it is still a massive improvement to the end-game security testing we have seen in the past. However, it still may expose vulnerabilities within cloud production environments and require reversion or patching that could have been completed before hand.
Next let’s review SecDevOps. This would imply that the security activities occur before any development or operations. I am not sure that this is truly practical, although it is certainly a well-intentioned principle and has merits that should be incorporated into the DevOps practice. My interpretation of this is that new requirements/user stories/features – whatever your method – include security requirements in the development. If we take this to the next step, then these security requirements would have automated tests created and added to the automation suites so they can run continuously to ensure that security is inclusive throughout the cycle. Hmm, this sounds pretty good…
The last one is DevSecOps. Literally, you can expand this to completing development, then reviewing and automating for security, and then deploying and operating. This articulation hopes to catch the security concerns before they are deployed to the world but are not as incorporated into the overall process as SecDevOps. Certainly DevSecOps has the benefit of focusing on security before introducing a vulnerability to the the wild, but it is not security-focused in every activity.
Maybe I am taking it too literally, but maybe what we need is SecDevSecOpsSec. Here, security is a continuous activity in itself that needs to be incorporated into all stages of the product lifecycle. However, that is quite a mouthful…
The important thing is that when your organization is approaching DevOps, don’t forget the security aspect. Think about how you are going to integrate security into every aspect of your lifecycle. As for which term to utilize, I am going to standardize on SecDevOps. Integrating security at the start has the best of intentions and will lead to the most secure practices.
The post DevOpsSec, SecDevOps, DevSecOps: What’s in a Name? appeared first on Cloud Security Alliance Blog.
from Cloud Security Alliance Blog http://ift.tt/2gbgFjq