The Marriage of DevOps and SecOps
cloudsentry.evident.io
cloudsentry.evident.io
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)
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.
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.
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.
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.
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.
Security is hard. Conforming to security best practices is one thing. Being a security expert is in itself an entire career field.
I can't remember the year Dev married Ops so I doubt I'll remember the year Ops got a sister wife.
Most companies I know can't even find one person who can do dev + ops well. I've only met a few people. Usually there are ops people who can do a little dev and dev people who can do a little ops. I've seen a few companies where it is a productive marriage but most companies I know just throw Docker into the dev environment and call it devops.
Now imagine having all three be the same role?
> DevSecOps is propelling forward-thinking organizations by doing something simple — fostering collaboration of seemingly contradictory teams to align their disparate goals into a singular effort.
This is not how devops works! Dev ops merges the two teams so that everyone is responsible for both. It doesn't just have the two teams "work together"... the two teams have been "working together" since the web was invented. Devops, by most definitions I know, is where developers are responsible for thinking about and dealing with the operations issues rather than having another team.
As a side question, is it opsec or secops? I've always heard the former.
Secops, definitely. It helps to think of where the term comes from.
OpSec = Operational Security; outside the infosec circles you'd likely hear this term mostly in conjunction with "spy stuff".
SecOps = Security Operations. I.O.W. the practice and theory of maintaining and improving security of a system.
I'm not sure the goal is to have someone who is some kind of horizontal fullstack guru in all spheres, from management to hardcore security. Rather, people with those skills should work together, instead of staying in their silos, by automating the friction points between them all and making the process more "parallel"?
Obviously a front-end developer wouldn't be worrying about server configuration, but they can write the integration tests and deploy when they are done without involving another team assuming the test coverage is sufficient / code review is done / etc.
That's the utopia at least.
Each member of the team does not need to be a superhero, they just need to be jointly responsible.
You could partition by product instead Gmail | Search | Maps | etc.
You could do both partitions, which gives you Matrix Management [0]. In the software world this is more commonly known as introducing the role of a product manager in addition to a team manager.
it's my belief based on experience that all 3 - dev, ops, and security are pretty much a giant slow motion trainwreck everywhere except maybe the big 4. and maybe not even all 4.
this industry is doomed from a job function perspective. we keep making our own jobs more complicated and blurring the lines instead of gravitating toward more rigor. the accountants are doing it for us, and they do a shitty job because it's not their actual industry.
i'm in my last pure tech position. it's becoming too much to deal with relative to the money paid, because the expectations of a 24/7 internet are outpacing our ability to deliver with reasonable compensation and quality of life. i don't see it changing. i only see it getting worse, year by year.
also "just don't work that hard, and collect checks" is not really how i operate. good for you though.
There's also obvious moral hazard with this model. It's kinda like the fox guarding the hen house. Having the same department be code writer, operations and auditor seems like an awful Idea. If one has a tight dead line, they're going to cut corners. We've all seen it.
This model can only exist in a start-up because of man power constraints. Your first few hires are going to be amazing and may actually be capable of such a role. However, as time goes on, this person has built a castle that can't be touched. You're also going to find that as a company grows, the spread of aptitude and skill grows wider, making this model seem absolutely absurd. The simple chaotic environment that your """"secdevops"""" started in will not be the same two years from now. Newer employees are going to lack contextual knowledge due to the increased complexity and by the simple fact that they didn't build it.
In practice, most people are partly responsible for keeping the organization secure. This isn't news...
in other news, Yay! a new buzz word.
Traditionally, SecOps people are very IT oriented, and spend their time auditing existing infrastructure for vulnerabilities using automated tools, watching for hostile network traffic, etc. Very little programming or application security knowledge is required, but lots of networking and IT knowledge is required.
I assume that by SecOps, the OP is referring to Application Security Engineering. This field works much closer to the developers, has knowledge of how to build security into products, and usually has programming experience.
This might seem like a nitpick, but the difference between SecOps people and AppSec people is big enough that if you were to hire the one for the other's job, you'd have a very bad time.
I'm not sure what a more accurate name would be (AppSecOps? AppSecDevOps?), however calling it DevSecOps is too misleading.