![How Does Zero Trust Impact DevSecOps? [Interview with Larry Maccherone, Part 3] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F92ff52a0-e97b-4a6b-a340-d987d80c5734%2Faid_field_img__84338d611c71c6f2a4ed51aa124be83d.png%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_3EAuLccmwaq4KZ9GcZftJq5NbwLA){kind=small}
In my last conversation with Larry Maccherone, the DevSecOps Transformation Senior Director at entertainment giant, Comcast, we spoke about his vision for the future of DevSecOps in 2020 and beyond. In this third and final conversation, we’ll cover zero trust and the impact that it may have on DevSecOps.
Today, many applications run in hybrid and multicloud environments where the perimeter is identity-based, not IP based. In this zero-trust model, how can security and engineering teams work together to scale issuance and monitoring of machine identities (e.g. SSL/TLS certificates) within policy?
Larry: Identity is a bigger problem in a containerized, microservices, and serverless world. You can't count on an IP address being the same anymore. And that's a good thing from an engineering perspective because you should think of machines as cattle, not pets.
But of course, that makes scaling the issuance and monitoring of machine identities such as SSL/TLS certificates harder. Although the attack surface is always changing since there are no longer static IP addresses, there are regulatory and other compliance requirements that teams must grapple with. To enable this at scale it’s important for security and engineering teams to work together to standardize their approach for certificates. Teams should strive towards standing up a service for certificates so that this infrastructure can be leveraged across many teams. This gives security teams a central point of control to set guardrails and monitor issuance while making things a lot easier for developers. Having a common framework also reduces complexity and minimizes dependencies on individual issuers by abstracting those details away from individual applications. This is great for security because it speeds up remediation efforts with little to no impact on the individual application or team supporting it.
So rather than wait until the application gets into production, it’s good to have developers improve their process such that they're confident that the product that they're putting out there will use machine identities that are known to the security organization and compliant with policy. That prevents vulnerabilities from weak or misconfigured certificates and future headaches related to audits. You really have to embed this service in the CI/CD pipeline that builds the piece of cattle.
Are there any other models that would help with this?
Larry: Serverless. Serverless is really an even better model than containers. It's essentially really, really, really small containers with very little state preserved, and so that makes security a lot easier in one sense, but the DevSecOps tools market is being slow to catch up. There are more tools that deal well with containerization right now because it's been around a little longer than serverless.
Will DevSecOps last forever?
Larry: No, it's a marketing buzzword. I don't think of the spiral model and then XP and then RUP and then agile, and before Scrum there was a bunch of flavors of agile. I don't think of these as separate things, I really think of these as the world adapting to changes in technology.
The reason that a waterfall-ish approach was actually the right way to build software was that it was very expensive to pass backwards over certain boundaries in the process. For instance, once you shipped the product to the field, it required a human to go out to the factory to install an upgrade to the software. So you better make sure that it was in very good shape before it went out to the field, and that justified a three-month long testing period before you shipped a product out into the field.
So now it's essentially free to ship stuff to the field. Compiling used to take longer, testing used to take longer, all these things it used to take huge efforts that were very costly to redo. We've lowered the cost of those dramatically. The evolution of our process models is essentially just adapting to the evolution of the capability of our technology over time. And a little bit of the capability of our mindsets. Sometimes the only resistance is just a different way of thinking about things.
I don't think DevSecOps is a new thing; it's just one more thing on the progression. I see the phrase DevSecOps becoming buzzword bingo very quickly. I think DevOps will survive much longer. I think of DevSecOps as essentially; if you're doing DevOps right, you're doing DevSecOps. I don't have a different definition for those two things.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts