The presentation triggers deep discussions on the cultural aspects of cloud adoption within an organization. Specifically, these sessions trigger debates around transformations that security must undergo to support and secure the new ways of working associated with cloud computing. We are passionate about cloud security transformation and seem to create the most value for our customers. Our goal is always to bring the security team closer to the cloud team, transform their way of working to be more efficient (leverage what the cloud has to offer), and help them avoid being perceived as the ‘Department of no’. This article aims to explain some of the steps and our approach.

Understanding cloud risks

Some security teams have the mindset that the cloud is insecure from having read old headlines, while, in fact, the cloud is built and operated in a highly secure manner. The compromises we often see are mostly related to the customer’s responsibility. The cloud consumer tends to fail with their security responsibilities in cloud environments, no surprise here. That is likely due to the same reason our previous environment fail to defend against threats. With the cloud, we also believe the likelihood of a compromise increases due to some of the elements below:

• There is a lack of technical understanding about services in the cloud and how to secure it properly.
• There is a fixed mindset in the organization’s cloud team that the cloud is highly secure, and they don’t need to secure it.
• There is a strong will by management and developers to move fast (which might be positive, I’ll address how to tackle this later on).

We need to educate security and cloud teams on the risks in the cloud and how this differs from the risks associated with an On-Premises and hybrid environment.

Forgetting what you know

The core elements of an organization’s environment have not changed as drastically in the past ten years as they will during a migration to the cloud. Identities used to be bound to your environment, your internal network used to be a security boundary, and the threat model is changing.

Sacha Faust and Andrew Johnson presented the illustration below in 2017, highlighting how the ‘cloud mindset’ differs from the past.

The main problem is that most of these terms are new to security resources, and they have to transform their mindset to this way of thinking, while also considering the existing risks of operating in an on-premises environment. Changing this mindset isn’t done in a week or month. However, it is possible to accomplish this transformation through various workshops, training, and hands-on labs, discussions, and production environment development.

Moving away from the department of ‘no’

We consider our consultants a cross-breed of security and cloud experts, meaning they’d be comfortable working in a pure cloud team, but their passion lies in security. With this experience, we have found that we can interface with developers and cloud teams more efficiently than a traditional security team to improve their security posture by working with them instead of around them. We believe that understanding how a cloud team and developers operate and embedding security facilitates the cloud team’s speed.

Our assignment usally is to bring the security team closer to the cloud team, transform their way of working (leverage what the cloud has to offer), and not have them perceived as the ‘Department of no’ while also addressing the immediate needs. The security team must be involved in the cloud initiatives from the beginning and become an enabler. When the cloud team has a work sprint to build a Proof of Concept of an application in the cloud, the security resource allocated to the project should not only set the security requirements but seek to adopt the practices and mindset of the development team. By embracing the change and being part of it, the mindset will move away from ‘No’ into thinking about how can we enable this. Security teams tend to have more uncertainty related to cloud environments, resulting in difficulty in making rapid decisions while learning to understand the operating environment and its associated risks.

Working with the development teams and helping perform some of their tasks changes how they perceive seasoned security professionals, builds trust, and also increases a security professional’s knowledge and confidence in working with the cloud.

Building guardrails and not gates

We like the analogy of building guardrails instead of gates. Cloud is a culture, and security has traditionally operated with gates to prevent errors. In a fast-paced environment that often comes when shifting to a cloud-based operating model, security has no choice but to remove the gates or become obsolete. A ‘gate’, like a security review, may be seen as a blocker, and requiring something manual for every deployment is hard to keep up with, while something that runs automated 'guardrails’ allows the teams to proceed without being dependent on manual processes.

Guardrails are designed by thinking, ‘What could possibly go wrong’ and implementing automated controls to prevent that. It’s the automated part of the approach that makes it work well in a fast-paced environment. A guardrail could prevent anyone from creating public storage except if explicitly declared or a policy ensuring no management ports are open to a wide internal range but constrained to the bastion. Guardrails are a great way to facilitate a discussion and identify common ground and understanding of cloud security best practices between security and development teams.

Rethinking our way of working

A security team also has to rethink how they work. If the processes are manual but the development teams have automated theirs, we will likely introduce unnecessary risks or delays.

To provide a real example of this:

The development team had fully automated the provisioning of a new ‘application environment’, which took 10 minutes to build through an automated pipeline. The security team, needing to monitor the environment, had a manual process to enable monitoring that took days for them to act upon and execute. During this timeframe, there were three options:

1. Allow the team to operate with an elevated risk due to a lack of monitoring
2. Have the team wait days for a new ‘application environment’ until the security team had set up monitoring
3. The security team automates the monitoring process and adds seconds or minutes to the deployment time.

Security teams need to identify situations like this, where automation is essential to carry out our function and avoid blaming the organization for having an unmonitored environment for days. We need to speed up our time to deliver services through leveraging automation. We must embrace the change and leverage the same benefits that other teams seek to improve our operations.

Security teams are often swamped with keeping the lights on, so how do we find time to prioritize automation and improvements? Sometimes you need to consider what you are doing today that adds the least value, and stop doing it, focus on automation to improve the efficacy of operations, and then revisit the work later to consider if it provides value. Moving to a hybrid setup also increases the demand for security resources when defending multiple and diverse environments.

The future of security teams

To summarize this article, I believe we as a security community need to be more involved with a cloud transition and not watch from the sideline. If you work with security and your organization is moving to the cloud, we believe you should either be a part of the core team or be an early adopter to learn the concepts in detail. We should embrace that things move faster and use that as an opportunity to rethink how we achieve our objectives.

Want to understand more about how to succeed with a cloud security transition? We are happy to discuss how we see the transformation and can help you succeed.