10 ms·

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

by jvehent 10y ago

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)

txutxu 10y ago
(Some) people needs new keywords to feel ok. 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.
secretmike 10y ago
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.
- jvehent 10y ago
  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.
- lmickh 10y ago
  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.

by jvehent 10y ago

txutxu 10y ago

(Some) people needs new keywords to feel ok. 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.

secretmike 10y ago

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.

jvehent 10y ago
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.
lmickh 10y ago
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.