Deciphering DevSecOps

Security needs to be an integral part of the DevOps roadmap. Enterprise Strategy Group’s Doug Cahill shows the way

By Beth Stackpole, Writer, Symantec

Security has moved to the forefront of the IT agenda as organizations push forward with digital transformation initiatives. At the same time, DevOps, a methodology that applies agile and lean principles to software development, is also a top priority. The problem is the two enterprise strategies are often not aligned.

We recently spoke with Doug Cahill, senior analyst and group director at Enterprise Strategy Group, to get his take on the importance of the DevSecOps approach as well as how to retool organizations to adopt the emerging principle.

Q: Cyber security is often not an integral part of the DevOps roadmap. What are the dangers of such a siloed approach and what is the impact on the business?

A: Application development is now often being driven out of line of business, outside of the purview of centralized IT and cyber security teams. That’s because there’s a need to get new applications into production, or update applications already in production, as quickly as possible.

The risk of not having security integrated in a decentralized IT and application development approach is that there are too often no security controls applied. That means that too often new “code-as-infrastructure” is getting deployed into production for which security wasn't contemplated at all.

Another problem is the use of default settings. Some basic examples are server workloads that are provisioned in the public cloud without going through a jump host or single proxy, which means they can be subject to being port scanned. Another common mistake is the lack of appropriate authentication controls; use of multifactor authentication (MFA) is something that a security practitioner would champion, but without security involvement in the DevOps process, it may not be thought about.

The risk to the business is as more application infrastructure becomes public cloud resident, we’re finding more of that is business-critical and sensitive. That exposes the organization to a variety of cyber security threats, both internal and external.

Q: Explain the schism between DevOps and cyber security teams that leads to siloed operations and failure to embrace more integrated DevSecOps practices.

A: It is really based in competing objectives. The AppDev and DevOps teams are chartered with moving quickly, getting new applications to production and updating those applications iteratively based on feedback from the market. Security, on the other hand, is chartered with making sure those applications behave in their intended state, meaning they are not compromised. Therefore, security professionals generally take a more deliberate, methodical approach to their job.

Security practitioners sometimes see DevOps akin to running with scissors—bad things happen when you move fast, from their perspective. DevOps, on the other hand, thinks security is just going to slow them down. In reality, there is a way to secure infrastructure at the speed of DevOps, so it’s a misunderstanding based on competing objectives. The gap can be closed, but the first thing is to understand that there is a gap.

Q: There’s a lot of talk about “shifting security left,” but also “shifting security right.” Can you explain what is meant by both and how it addresses integrated DevSecOps best practices.

A: The shift security left, shift security right metaphors are akin to the notion of having security bolted in versus bolted on. Traditionally, security has been bolted on; it hasn’t always necessarily been part of the design center. The world of continuous integration and continuous delivery (CI/CD) is really an opportunity to bake security into all environments and stages from development to test to production environments. We can think of shift left as pre-deployment and shift right as runtime. The notes to shift right is a reminder that we still have to apply runtime controls to those production servers and applications to protect them from intrusions. This includes things like appropriate access controls in terms of updating host-based firewalls, anti-malware controls, and anti-exploit controls.

Q: Why should a company integrate security processes and controls with DevOps?

A: There are a number of really compelling benefits to integrating security into the CI/CD pipelines, something sometime referred to as DevSecOps. One is the ability to secure at scale. Just as groups autoscale based on the capacity requirements of the application, security will be automatically integrated with the way you orchestrate and provision the new server.

Integrating security controls helps organizations meet and maintain compliance with regulations such as PCI and DSS as environments are provisioned and managed through the DevOps processes. It’s really about security and compliance at scale, but there is also a level of efficiency. If you can automate applying the right security controls based on the role of the server workload, it’s a highly efficient approach. There are so many corollaries in terms of project work—we know if we have to go back and do things later, it’s much less efficient than doing it right the first time.

Q: What is your set of recommended best practices for putting DevSecOps into action?

A: The best practices for DevSecOps are composed of people, processes, and technologies. If we take a page out of the shared responsibility security model that cloud service providers talk about, CSPs are responsible for physical security, network security, all the way up to the hypervisor. The customers are responsible for everything north of the hypervisor like the workload, operating system, applications, data, identity and access management. We should have a similar approach for the relationship between the DevOps team and the security team—both teams need to work collaboratively to secure public cloud infrastructure.

The second is to look at this as a risk management approach. In larger organizations, you'll have multiple teams developing a wide variety of applications, but not all those applications have an equal level of risk to the business. If an organization is just starting down the DevSecOps path, they should start with one or two applications where they have the most risk for their business.

The next suggestion is to leverage the agile software development processes used to do CI/CD to write cyber security-related user stories. The cyber security team should partner with the product owner who is typically responsible for defining user stories and tasks that will be implemented over the course of the next sprint. The cyber security representative should really become part of the SCRUM team. They should be attending daily stand ups and explaining the value and importance of implementing these different user stories.

Q: Is there any sort of special ingredients that make for a DevSecOps-friendly culture?

A: I think it’s that security needs to be owned by everybody, and making security a requirement needs to come from leadership. You also need a dose of pragmatism—if an organization has a readiness gap and you’re playing catch-up, it’s taking a risk-based approach to identify where you have the most exposure and start there.