Whether you have started thinking about transitioning to the cloud, are already on your way or have been ‘there’ for a while, how involved is your security team in the transformation? As a public speaker, I only submit presentations when I have research that I am passionate about, or when I believe I can present an inspirational topic. In 2019, Suhail (arranging HackCon) specifically requested a cloud-focused session and I went right to the drawing board. I came back with my session ‘10 lessons learned from 5 years in the cloud’. Unlike my previous presentations, this session focused a lot more on the transformational challenges for security teams when it comes to adopting the cloud and, strategies for succeeding with building your security team for the cloud.

I have since then held this session numerous times, and it always triggers deep discussions on the cultural aspects of cloud adoption within an organization. Specifically, these sessions trigger discussions around transformations that security must undergo to support and secure the new ways of working associated with cloud computing. Cloud security transformation has become something I am passionate about and where I seem to create most value for our customers. My 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’. The purpose of this article is to explain some of the steps and my approach to this.

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 most we see are mostly related to the customer’s responsibility. The cloud consumer tends to fail with their security responsibilities in cloud environments. That is likely due to the same reason our previous environment fail to defend against threats, and I 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 properly secure it.
There is a fixed mindset in the organizations cloud team that the cloud is highly secure and you don’t need to secure it.
There is a strong will by management and developers to move fast (which is positive too, I’ll address how to tackle this later on).

To deal with this, we need to educate both security and cloud teams on the risks in the cloud, and how this differs from the risks associated with an On-Premises and hybrid envoronment.

Forgetting what you know

The core elements of an organization’s environment have not changed as drastically the past 10 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 teams and they have to go through a transformation of adopting 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. However, through various workshops, training and hands-on labs, discussions and production environment development, it is possible to accomplish this transformation.

Moving away from department of ‘no’

I consider myself a cross-breed of security and cloud expert, meaning I’d be comfortable working in a pure cloud team but security is where my passion lies. With this experience, I have found that I am able to interface with developers and cloud teams more easily than a traditional security team and more effectively improve their security posture by working with them, instead of around them. It is my belief that understanding how a cloud team and developers operate and understanding what facilitates the cloud team’s speed.

My assignment is normally 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 not have them perceived as the ‘Department of no’ while also addressing immediate needs. We need the security team to be involved in the cloud initiatives from the beginning and be perceived as an enabler. If 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, our mindset will move away from ‘No’ to thinking How can we enable this. Security teams may have more uncertainty related to cloud environments, finding it hard to make fast decisions while understanding the operating environment and associated risks.

I find that working with the development teams and helping perform some of their tasks change 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

I 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 to 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 through 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 be to prevent anyone from creating a 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 is 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 own way of working

As a security team, we also have to rethink how we work. If our processes are manual, but the development teams have automated it, we are likely to introduce unnecessary risks.

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

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

Security teams needs to identify where automation is essential to carry out our function and not blame the organization for having an environment that is unmonitored for days. We need to speed up our time to deliver services and leverage automation. We must not only embrace the change but leverage the same benefits that other teams are seeking 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 improve efficacy of operations and then revisit if it still provides value. Moving to a hybrid setup also increases the demand on security resources when having to defend 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, you should either be a part of the core team or be an early adopter of it 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.

This article was written during a weekend trip to Gausta, I have been planning to write it for a while and wasn’t sure when to write it, but waking up here gave me the inspiration I needed and after hiking to the summit I was ready to finish the writing.