Rethinking Security for Public Cloud

Symantec’s Raj Patel highlights how organizations should be retooling security postures to support a modern cloud environment

By Beth Stackpole, Writer, Symantec

Enterprises have come a long way with cyber security, embracing robust enterprise security platforms and elevating security roles and best practices. Yet with public cloud adoption on the rise and businesses shifting to agile development processes, new threats and vulnerabilities are testing traditional security paradigms and cultures, mounting pressure on organizations to seek alternative approaches.

Raj Patel, Symantec’s vice president, cloud platform engineering, recently shared his perspective on the shortcoming of a traditional security posture along with the kinds of changes and tools organizations need to embrace to mitigate risk in an increasingly cloud-dominant landscape.

Q: What are the key security challenges enterprises need to be aware of when migrating to the AWS public cloud and what are the dangers of continuing traditional security approaches?

A: There are a few reasons why it’s really important to rethink this model. First of all, the public cloud by its very definition is a shared security model with your cloud provider. That means organizations have to play a much more active role in managing security in the public cloud than they may have had in the past.

Infrastructure is provided by the cloud provider and as such, responsibility for security is being decentralized within an organization. The cloud provider provides a certain level of base security, but the application owner directly develops infrastructure on top of the public cloud, thus now has to be security-aware.

The public cloud environment is also a very fast-moving world, which is one of the key reasons why people migrate to it. It is infinitely scalable and much more agile. Yet those very same benefits also create a significant amount of risk. Security errors are going to propagate at the same speed if you are not careful and don't do things right. So from a security perspective, you have to apply that logic in your security posture.

Finally, the attack vectors in the cloud are the entire fabric of the cloud. Traditionally, people might worry about protecting their machines or applications. In the public cloud, the attack surface is the entire fabric of the cloud--everything from infrastructure services to platform services, and in many cases, software services. You may not know all the elements of the security posture of all those services … so your attack surface is much larger than you have in a traditional environment.

Q: Where does security fit in a software development lifecycle (SDLC) when deploying to a public cloud like AWS and how should organizations retool to address the demands of the new decentralized environment?

A: Most organizations going through a cloud transformation take a two-pronged approach. First, they are migrating their assets and infrastructure to the public cloud and second, they are evolving their software development practices to fit the cloud operating model. This is often called going cloud native and it’s not a binary thing—it’s a journey.

With that in mind, most cloud native transformations require a significant revision of the SDLC … and in most cases, firms adopt some form of a software release pipeline, often called a continuous integration, continuous deployment (CI/CD) pipeline. I believe that security needs to fit within the construct of the release management pipeline or CI/CD practice. Security becomes yet another error class to manage just like a bug. If you have much more frequent release cycles in the cloud, security testing and validation has to move at the same speed and be part of the same release pipeline. The software tools you choose to manage such pipelines should accommodate this modern approach.

Q: Explain the concept of DevSecOps and why it’s an important best practice for public cloud security?

A: DevOps is a cultural construct. It is not a function. It is a way of doing something—specifically, a way of building a cloud-native application. And a new term, DevSecOps, has emerged which contends that security should be part of the DevOps construct. In a sense, DevOps is a continuum from development all the way to operations, and the DevSecOps philosophy says that development, security, and operations are one continuum.

Q: DevOps and InfoSec teams are not typically aligned—what are your thoughts on how to meld the decentralized, distributed world of DevOps with the traditional command-and-control approach of security management?

A: It starts with a very strong, healthy respect for the discipline of security within the overall application development construct. Traditionally, InfoSec professionals didn't intersect with DevOps teams because security work happened as an independent activity or as an adjunct to the core application development process. Now, as we're talking about developing cloud-native applications, security is part of how you develop because you want to maximize agility and frankly, harness the pace of development changes going on.

One practice that works well is when security organizations embed a security professional or engineer within an application group or DevOps group. Oftentimes, the application owners complain that the security professionals are too far removed from the application development process so they don't understand it or they have to explain a lot, which slows things down. I'm proposing breaking that log jam by embedding a security person in the application group so that the security professional becomes the delegate of the security organization, bringing all their tools, knowledge, and capabilities.

At Symantec, we also created a cloud security practitioners working group as we started our cloud journey. Engineers involved in migrating to the public cloud as well as our security professionals work as one common operating group to come up with best practices and tools. That has been very powerful because it is not a top-down approach, it's not a bottoms-up approach--it is the best outcome of the collective thinking of these two groups.

Q: How does the DevSecOps paradigm address the need for continuous compliance management as a new business imperative?

A: It's not as much that DevSecOps invokes continuous compliance validation as much as the move to a cloud-native environment does. Changes to configurations and infrastructure are much more rapid and distributed in nature. Since changes are occurring almost on a daily basis, the best practice is to move to a continuous validation mode. The cloud allows you to change things or move things really rapidly and in a software-driven way. That means lots of good things, but it can also mean increasing risk a lot. This whole notion of DevSecOps to CI/CD to continuous validation comes from that basic argument.