I'm not a fan of the "DevSecOps" or "SecDevOps" terms. Security is just part of DevOps, the same way QA or product management are. It's not its own thing bolted on top of DevOps practices, it's an integral part of the product.
That said, I agree with the blog post. We are seeing more and more security teams reinvent themselves as they adopt DevOps practices, which really means security is learning to use the CI/CD pipeline and to build controls in IaaS and PaaS. We're moving away from security teams that panicked at the idea of not controlling layer 2 and 3, like they used to in the goold old datacenter, and seeing teams focus on web application security more and more.
It doesn't mean L2/3 are not important. There is still a lot of value to adding an IDS or a proxy to an infrastructure. But there is also tremendous value in testing controls continuously in the delivery pipeline, which means collaborating with devs and ops in the CI/CD pipeline. That's really what "secdevops" is about.
In the next few years, we'll see more and more security teams learn DevOps and that's a good thing. Let's just make sure we don't reinvent decades of infrastructure security in the process.
Many years in IT, little and big companies... I've seen 3 security models:
1) Absent. Everybody was so worried about other keywords, than nobody did remember about data security until it was a problem.
2) Invalid, unmaintained and written in the past by a third party. Everybody call this model components "the protocols", nobody knows about security, they know about "follow the protocol", or "this does not follow the protocol".
3) Conscious about threats, maintained and perfectly explained by the involved people.
The 3 models, did repeat before, and during the term "devops". And will repeat after. And will be immune to the existence/usage of the term "secops" in the media.
For the model 3), I've found 2 scenarios, 3a) management was conscious about security (even more than "technical people") or 3b) management didn't know almost anything about the sysadmin work, but they did know they didn't have problems.
One of the keys for the model 3) is management. They push the workers in one direction or another. If management does not understand the value or the dangers of data security, usually they have problems in more fields than security (technical debt, code, tooling, teams, projects, etc)
When people expects my response to an automation or integration or development question (devops), and I give them the response, with all the security aspects included, (not just a "technically valid" response) I use to gain value with the customer/team.
Now I think I was a secops (before the term was out there), when my boss just did want a 'devops' at the time.
This is really all caused by the rise of the Service as a unit of delivery. Web applications talk back to Services, which provide access to vast amounts of information. Same with mobile apps and APIs.
At one time the "security team" really meant the Network Security team. The people who controlled the firewalls. As web applications became more complex, the model was extended to Web Application Firewalls, that had a bit of knowledge of what web requests looked like, and what bad payloads looked like. But still trying to protect the application from the perimeter.
These days services are much more powerful, and connect to much more data. Form POSTs are now also Ajax calls, or JSON over websocket. They are also deployed in more ways: AWS, Heroku, Docker, Mesos/Marathon, Kubernetes, etc. Trying to completely control the network becomes more complex.
To effectively protect applications today, the security must be embedded within the application, where the defences have a full understanding of what's going on, and where the security always gets deployed as part of the app, no matter where it runs.
Similarly, it makes complete sense to me that the "Security Team" also needs to be embedded within the development team.
One team, responsible for the design, implementation, operation, and retirement of a system.
Sadly, this is what "DevOps" was supposed to be about when the discussions started back in 2010ish. Getting all of the people required across the entire business working together so that road blocks could be removed as close to the problem source as possible.
The fact that we even see DevOps teams tells you how horribly the point was missed. Instead of changing the way they do business, folks seem content to sprinkle in some automation and call it a day. I work in a company that put together a DevOps team despite trying to explain that to them. Now we have the same problems as before. They are just somewhat automated now.
I have given up on defining buzzwords like DevOps, Cloud, Mobile, Agile, Industry 4.0, Code of Conduct, etc.
If you want to change something in your organisation/project, just pick a few buzzwords. It gives your proposal a halo of modernism and progress. If you get rejected, try different buzzwords. You want to integrate developers and admins better? You can do that under the DevOps umbrella or the Agile umbrella or whatever.
Using a new buzzword gives people hope for change. Without hope they will not be on board. If they are not on board, change will fail. It works like a self-fulfilling prophecy. Only if people believe it, change can actually happen. If the actual changes fail, the buzzword is burned. Find a new one for another try.
This model explains very well why the buzzwords change quickly. The words don't matter. The definitions don't matter much. People will use and misuse them not matter what. You can misuse a buzzword to create change for good.
I hear the same thing said about having a "mobile team" or an "ios team" + "android team" (that people commonly think sprinkling a little "mobile" on the codebase makes everything fine, but no, mobile should be everybody's responsibility and you shouldn't have a mobile team).
What's the limit ? Should all specialized skills be uniformly distributed across the whole engineering org ? How is that conducive to the idea of "teams" at all ?
I think this organizational strategy works better with smaller orgs.
I couldn't agree more. At Mozilla, the Services Security team is part of the team that develops and builds services. We work with devs and ops every day. We write application and infrastructure code. We share successes and failures.
The traditional bystander/compliance security team approach shows its limits very quickly. Being embedded that deeply into the DevOps team is by far the most efficient way to secure services.
That said, I agree with the blog post. We are seeing more and more security teams reinvent themselves as they adopt DevOps practices, which really means security is learning to use the CI/CD pipeline and to build controls in IaaS and PaaS. We're moving away from security teams that panicked at the idea of not controlling layer 2 and 3, like they used to in the goold old datacenter, and seeing teams focus on web application security more and more.
It doesn't mean L2/3 are not important. There is still a lot of value to adding an IDS or a proxy to an infrastructure. But there is also tremendous value in testing controls continuously in the delivery pipeline, which means collaborating with devs and ops in the CI/CD pipeline. That's really what "secdevops" is about.
In the next few years, we'll see more and more security teams learn DevOps and that's a good thing. Let's just make sure we don't reinvent decades of infrastructure security in the process.
(shameless plug: I'm writing a book on devops security: https://securing-devops.com/book)