
The Marriage of DevOps and SecOps - kiyanwang
http://cloudsentry.evident.io/the-marriage-of-devops-secops/
======
jvehent
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.

(shameless plug: I'm writing a book on devops security: [https://securing-
devops.com/book](https://securing-devops.com/book))

~~~
secretmike
I've heard DevSecOps, SecDevOps, and DevOpsSec :)

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.

~~~
lmickh
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.

~~~
qznc
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.

------
somenomadicguy
Or we will remember 2016 as yet another year where our salaries remained
stagnant while expectations and responsibilities were increased by 100%?

~~~
tobltobs
This would imply that that security haven't been relevant for "DevOps" until
now.

~~~
somenomadicguy
I mean to imply more that every time we have a new paradigm shift in titles,
job responsibilities get increased. For example, it's not enough to be a
backend developer, now you must be a full stack developer, so that we can hire
fewer front-end devs. It's not enough to be a DevOps engineer, now you must be
a FullStackDevOpsEngineer. There's this concept that out there is some
superman engineer who can somehow be an expert in _everything_.

Security is hard. Conforming to security best practices is one thing. Being a
security expert is in itself an entire career field.

------
ryanmarsh
> In a few years, we’ll fondly look back on 2015 as the year that DevOps and
> SecOps “got married”

I can't remember the year Dev married Ops so I doubt I'll remember the year
Ops got a sister wife.

~~~
throwaway2016a
I was going to say something similar. So it's a three way marriage, dev + ops
+ opsec?

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.

~~~
RRRA
(edit: reply is on the first part, but i might need coffee :) )

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"?

~~~
secretmike
100% agree with this. The point is to have one _team_ working together, where
the team has all the required dev, ops, and security skills, or access to
tools that can augment the team's skills.

Each member of the team does not need to be a superhero, they just need to be
jointly responsible.

~~~
qznc
The question is how your partition your organisation. Classic is something
like Development | Testing | Production. DevOps wants to integrate the
different department, but you cannot build one huge team of 100 people.

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.

[0]
[https://en.wikipedia.org/wiki/Matrix_management](https://en.wikipedia.org/wiki/Matrix_management)

------
tmaly
sorry, I read the article and the word BuzzOps popped in my mind. I think most
companies are still trying to get their heads around clouds and micro
services.

~~~
AlexB138
Amen. I'm so tired of self proclaimed "Thought Leaders" coming up with
bombastic new buzzwords to sell to managers. In my eyes, the DevOps "movement"
has mostly been a complete failure. It went from being about cultural change
to half of the people thinking it's about Operations writing automation and
the other half thinking it means no Ops team at all, and developers doing
everything.

------
speedstick
Ever heard of a jack of all trades? It's true that jacks are super valuable
but a jack is not an ace. Following this model feels like your spreading your
brain power in to too many disciplines.

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.

------
gregshap
I'm blown away by the author's ability to fit so many buzzwords into so little
content.

------
bsamuels
I think that calling this a marriage between DevOps and SecOps is a serious
misnomer.

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.

------
robk
This seems like a pretty good development overall - more people looking at
application security across the org is a good thing imo especially if it can
provide another layer of defence for where the app developers missed something
or around new vulnerabilities just discovered. Even for things like Wordpress,
I like the additional hardening of a WAF and with tools like OSSEC (and
eventually more advanced tools like Immunio) on top of the usual app
hardening.

