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.

Security Risks and Continuous Development Drive Push for DevSecOps

How the need to speed application creation and subsequent iterations has catalyzed the adoption of the DevOps philosophy

By Dwight B. Davis, Writer, Symantec

curved steel bridge

The sharp rise in cyber security attacks and damaging breaches in recent years has driven a new mantra among both application developers and security professionals: “Build security in from the ground up.” Although it’s hard to argue with that commonsense objective, actually achieving it has proven to be far from straightforward.

Traditionally, of course, developers have focused on delivering reliable software that first and foremost provided the desired functionality. Security was largely an afterthought, if a thought at all – something that was to be layered on top of the application once it hit production. When, inevitably, applications were found to have code vulnerabilities, developers crafted and distributed patches to fix them.

Never ideal, the patch and update model has become untenable as security threats have escalated and software development cycles have accelerated. Much of this acceleration has been driven by public cloud computing, which has fostered the rise of a continuous integration/continuous delivery (CI/CD) development model.

At a more macro level, the need to speed application creation and subsequent iterations has also catalyzed the adoption of the DevOps philosophy. The fundamental basis for this movement is to better integrate developer and operations teams, thus ensuring that each side has a better understanding of the other’s needs and constraints.

By some estimations, DevOps and CI/CD can inherently aid in the creation of more secure software. Why? Because, thanks to the rapid application iterations, software flaws can be more quickly identified and more swiftly patched.

The problem with this supposed benefit is that it doesn’t alter developers’ build/patch mentality. Vulnerability fixes may indeed occur more quickly, but security still isn’t a core developer concern or responsibility.

Spanning the development & deployment cycle

To truly deliver on the “security from the ground up” objective, DevOps teams need to blend in a security component that spans the entire software development and deployment lifecycle. That need has resulted in the notion of a DevSecOps paradigm or culture. Here again, though, the concept is easier to grasp than to achieve.

The challenges associated with DevSecOps range from cultural to technical. Developers long disinterested in security issues need to change their mindsets and expand their skillsets. Development and security teams that have largely operated in their own isolated domains need to learn how to tightly collaborate. Developers who already have tools for code production and management now need tools for building secure apps. For their part development team managers need tools to give them visibility into the security of the code each developer is producing.

When it comes to implementing DevSecOps, there is no one-size-fits-all guidebook. Cloud native and more entrepreneurial firms may be able to mesh their developer, operations and security teams more quickly and easily than more mature organizations that must break down existing functional silos. Even though there will be a gradient in how tightly integrated the various teams become in different organizations, however, there is a fundamental need to move security beyond its own isolated domain.

“The goal is to decentralize and democratize security,” explains Hardeep Singh, cloud security architect at Symantec. “Having centralized security and decentralized development and operations is a recipe for disaster.”

Although developers must become more conversant and capable regarding security issues and approaches, the degree of their security expertise will vary considerably. Likewise, security pros typically aren’t going to become coding wizards. That said, each group needs to better understand the other’s worlds, and how the two must intersect.

Often, the security members within DevSecOps environments will set high level priorities and best practices, while the developers will be tasked with implementing them.

“You can’t expect app developers to know the best practices to secure IP data or to identify a SQL injection,” says Raj Patel, Symantec’s VP of Cloud Platform Engineering. “But you can train them on safe development practices and techniques.”

There may be some resistance among developers asked to take more responsibility for building secure code, just as some security experts may balk at bringing developers more fully into the security lifecycle process. Most often, though, these two groups are happy to share the burden of producing secure applications, since doing so not only reduces cyber security risks but also makes their own work lives easier.

DevSecOps can also drive a meeting-in-the-middle truce between the historical – and polar opposite – attitudes of developers and security pros. The bias of developers has been to say “Yes” to user requests, while that of security experts – prioritizing security over functionality and ease-of-use – has been to say “No.”

“In some ways, DevSecOps can be how security teams move to ‘Yes,’ because they’ve helped developers address security needs right from the start,” says Patel.