Cloud security – Fix Governance not just technology

I’m often asked – by clients, by colleagues, by anyone with an interest in cloud security –  to describe the most important security considerations regarding the adoption and operation of cloud services. I think I’m expected to answer identity and access management, security monitoring, or perhaps encryption and key management – something technology related. That’s not my answer. My answer often surprises people because they still tend to view cloud security as a technology issue and thus expect a technical answer. However, my view is that first we must get the governance right.

Governance?

Those organizations that I’ve seen struggle with cloud adoption have typically had one feature in common, namely inappropriate governance and ownership structures and approaches. Their cloud adoptions lacked central points of command and control and so fell victim to cloud sprawl, shadow IT, and duplication of capabilities as business units and individual employees decided to do their own thing. Attempting to regain control of data and services once they have been allowed to grow “organically” throughout global enterprises is a painful exercise; one which I’d strongly recommend organizations attempt to avoid by getting the right structures in place from the outset.

Now, it’s important to recognize that when I talk about “central points of command and control” I do not necessarily mean centralized micromanagement. I do, however, mean centralized ownership of cloud strategy and cloud risk by those with sufficient executive clout to be able to enforce their views. The strategy of those owners could well be to delegate responsibilities and accountabilities throughout the organization, typically with a few guard-rails attached, but it does at least allow for a consistent approach to be adopted towards cloud usage, for example, through the creation and mandate of a minimal set of cloud principles. Example cloud principles could include:

• Public cloud first
• SaaS for commodity services
• PaaS over IaaS
• Cloud native tooling over third-party tooling
• Single provider per workload
• Foundation services over per project services (e.g., use a standard identity solution)
• Automate where possible
• Transform over lift-n-shift.

Now, you may disagree with some of the above principles and that’s fine as they are only examples and every organization is different! Principles simply provide a framework to guide projects in their delivery.

Security management

The last bullet above can have interesting implications for security management in the cloud.  Organizations are used to having centralized IT Security teams, perhaps doing everything from policy setting and security assurance through to operation of security tooling. Such centralized security teams will likely have embedded a whole series of security checkpoints for projects to follow during their lifecycle in terms of sign-offs: project visions, high-level architectures, low-level architectures, processes and procedures all to be topped and tailed by a penetration test prior to go-live. This is fine in an on-premises world doing traditional, fairly static, IT in a waterfall model. This model is emphatically not fine in a more dynamic world looking to move towards DevSecOps. You simply cannot do a full pre-go-live penetration test of an application that is updated multiple times per day (you can and should be doing a rolling set of on-going penetration tests however). What does this mean in practice? Well, there is a lot of guidance out there in terms of the need to embed security controls into the CI/CD pipeline and “shifting left” as part of moving towards DevSecOps. This guidance does not necessarily extend as far as detailing how organizations still maintain control and consistency. My advice here is to move away from the centralized model described earlier and consider embedding security resources (or training up security champions) within the project teams.  These embedded resources are closer to the business requirements (as they act as just another part of the development teams/scrums/squads, etc.) and are able to react more quickly for requests for security input. They are also on hand to raise concerns prior to the development teams wasting their time on designs that would violate the risk tolerance of the organization. A central security function remains in this model but is now more of a “trust, but verify,” standards-setting and escalation function. This model is much more suitable for more fast-paced environments but must be adopted with care and in conjunction with the embedding of adequate technical security guard-rails within the wider CI/CD approach such as pre-approved templates, security controls embedded within the IDE, and automated security testing (SAST, DAST, composition, optionally fuzzing) within the pipeline.

The above describes two models for security management – a centralized model for traditional IT and a delegated and embedded model for more digital, cloud-native workloads, illustrated below.

In the real world?

That’s fine in principle. But organizations are rarely so easily categorized as “traditional” or “cloud-native.” Large enterprises in particular will be operating multi-modal IT, i.e. elements of traditional IT, elements of cutting-edge digital, and elements of pretty much everything in between. So, how should organizations structure their information security management? A hybrid approach is often the right answer, with a centralized function remaining available for those parts of the business that need it alongside a pool of flexible security resources that can be deployed to project teams where required. A key target for those flexible security resources is knowledge transfer – they should look to identify and train security champions within the development teams that they are working within in. As cloud adoptions ramp up, it is often not feasible to hire sufficient security resources to form a pool of resources able to support the project portfolio hence this need to identity and train up a network of security champions.

Would this model work for everyone? Of course not. Life is never so simple! The purpose of this blog post however is to suggest how large enterprises can look to avoid the missteps I’ve seen elsewhere:

• the lifting-n-shifting of on-premises security tooling and processes to the cloud hobbling digital transformation
• the failure to control shadow IT leading to compliance concerns as organization and customer data finds itself in various inappropriate places
• the failure to adopt consistent cloud architectures (e.g., landing zones) leading to overly large attack surfaces and duplication of functionality

Consideration of governance and security management structures as early in the cloud adoption process as possible helps organizations to avoid these missteps, and to prepare themselves to take full advantage of the transformational possibilities offered by adopting DevSecOps approaches.

Feel free to let us know if you’ve found other models that work better!

To find out more about cloud security, visit the Cloud Security page.