I sometimes have conversations with people who don’t know me well and think I’m nice (or even “too nice”). Depending on the nature of the conversation, I may correct them. I intend to be kind, which appears as niceness but is fundamentally different. People sometimes draw a false equivalence between the attributes of kindness and those of niceness. Someone can be kind but not particularly nice. As I’ve written elsewhere, it can be kind to give someone extremely blunt feedback, but it may not feel nice to the person receiving it. Similarly, something that is simple, or made up of simple components, is not necessarily easy. For example, the idea of climbing a mountain is simple to comprehend but potentially very challenging to execute.

What do I mean when I say Cloud Security is simple? The principles that drive Cloud Security are really straightforward. First, have a good governance structure. Ensure that your identity and access management practices are based on least privilege and maintain that stance. Ensure visibility everywhere in your environment. Put appropriate controls in place to segment your Cloud platform so that a compromise in one area is contained. Deploy technology using patterns and maintain your configurations through constant checking and automation. Detect unusual events quickly and provide actionable information to critical stakeholders promptly. Automate heavily. These are simple concepts, even for non-technologists.

However, the execution of Cloud Security at scale is anything but easy. Let’s take the area of entitlements, for example. Maintaining a consistent view of all of the entitlements held by every human and machine identity at scale is incredibly challenging. While the emerging product field of Cloud Identity and Entitlements Management (CIEM) intends to tackle this challenge, the solutions and market are immature. Microsoft’s recent acquisition of CloudKnox, now rebranded as part of the Entra product family, is a case in point. Entra is an interesting product providing information on Role-Based Access Control (RBAC) entitlements for Azure and other Cloud environments. Still, it does not yet give a view of Azure Active Directory entitlements. The combination of roles and entitlements between Azure AD and Azure RBAC is a critical view to have to identify potentially undesirable (toxic) combinations.

Without appropriately mature tooling, it is practically impossible for any Cloud Operations or Cloud Security Operations team to understand all entitlements held by any single identity or security principal. Given the number of breaches caused or facilitated by overprivileged credentials, this area desperately needs improved capability.

So Cloud Security is not easy, even if it is conceptually simple. An analogy struck me relating to DNA. The four bases that form DNA are relatively simple components. However, combined in an incredibly variable manner, they can create hugely complex organisms, ranging from a blue whale to a human to a fruit fly. Similarly, the variability of the underlying services in a Cloud environment and their combinations make securing Cloud solutions at scale incredibly challenging. Simple components build towards extremely complex “organic” ecosystems. As the line between IaaS and PaaS solutions becomes ever more blurred, the combinations increase in variability and complexity.

In a DNA-driven world, how the bases combine is governed by straightforward principles—Adenine pairs with Thymine, and Cytosine pairs with Guanine. During DNA replication, enzymes check to ensure that the correct bases have been added to the chain. If there are errors, they are removed at the source before the DNA is “written”.

In Cloud Security, we can keep our organisations focussed on the simple principles that will help us manage complexity at scale. From a practical perspective, we can ensure that we build environments using Infrastructure as Code (IaC) which is version controlled. We can wrap IaC templates with Policy as Code pre-deployment checks. We can validate from a post-deployment perspective that what we intended to build is actually running using posture management and workload protection tools. And we can continue to educate our broader organisations that what appears simple is not easy. The lure of the Cloud is powerful, and the concepts of it are simple. However, the reality of how to get there safely is highly complex and requires the appropriate preparation, training and tooling to avoid disaster.

Clearly, in this scenario, retail Public Cloud Providers (PCPs) are the younger member of the relationship – looking to move fast and break things, as it were.  Large, regulated Enterprises are the older partner, looking to put their feet up at the end of a complicated and trying day.  They can’t move as fast as the PCPs, because they have accumulated responsibilities in the form of regulatory and board oversight, and have less agility in their old bones than the more nimble PCPs.

When PCPs are dating/courting startups, or Small-Medium Enterprises (SMEs) in less regulated spaces, the pace of adoption and engagement in the relationship is often faster and less complicated.  This is because the younger organisations in the partnership may have similar interests, with fewer individual areas of specific concern.   The equation is one of best price and warranty for the service provided, and it often ends there.

Newer organisations tend to be more cloud-ready as well – they’ve grown up with modern application methods and technology and are carrying less technical debt.  Many large enterprises have applications that pre-date the foundation of today’s PCPs – and the management of these legacy applications can be critical to the day-to-day functioning of the enterprise.

Larger Enterprises also have a significant overhead in the form of regulations that they are accountable to meet, security and compliance controls to adhere to and boards that may be highly risk averse.

Does this “age-gap” means that the relationship is doomed?

Not necessarily; it just means that the younger partner needs to be more aware of the specific needs of their older paramour.   Some PCPs are clearly very aware of this.  For example, Microsoft Azure is focussing heavily on providing hybrid cloud services, including Active Directory integration and Azure stack for on-premises use to enable the lines between the enterprise and the PCP to be less of a challenge to adoption.

In their turn, the elder partner needs to be aware that contracts and master services agreements may need to be reassessed while still maintaining the appropriate risk management posture.  Workload selection also has to be carefully managed – the “wrong” workloads migrating to a cloud environment will clearly result in unhappy outcomes.

What else can PCPs do to help?  They can make information readily available to simplify the transition to a cloud environment by making compliance resources available, as AWS did recently with their Cloud Compliance center.

They can simplify and make more transparent their usage and pricing structures.  For the past few years, articles have been published (e.g. here, here and here) about businesses pulling workloads back from public cloud environments, in part because of “sticker shock”.   (There are other reasons, including availability issues that have been identified as driving the pullback).

In addition, PCPs can put together chains of services that legacy application managers can consume more readily.   For example, AWS Lightsail, Farscape, Beanstalk and Migration Services are a step in the right direction.  These still don’t remove the overwhelming variety and complexity of sub-services that PCPs offer, but compared to e.g. Google Cloud Platform, they provide a friendlier face to newcomers to public cloud environments.

Is this May-December relationship still worth pursuing?  Absolutely – because there can be significant value for both parties if approached correctly.  Large Enterprises can use public cloud environments as a catalyst for application modernisation, risk reduction and capital budget weight-loss (although OpEx clearly needs to be very carefully managed).  PSPs can benefit from the steady, predictable income that a well-funded, firmly established partner can provide (and can learn how to further develop offerings that are suitable to these organisations, growing the business).  As with any relationship, the key is to ensure that expectations are set appropriately at the outset, and then met or exceeded.