​Cloud-Native Security Starts with the Cloud

Oracle author: Maywun Wong, Director, Product Marketing

Contributed by: Frank Dickson, IDC, Program Vice President, Security & Trust

“Cloud-native security!” is the battle cry of the day. We all want it. But what is it? Everyone seems to define it differently. My suggestion is that any discussion of cloud-native security starts with the cloud.

We move to the cloud for flexibility, choice, and ease of deployment, right? Public cloud vendors look to deliver on the promise of those benefits with an elastic IT environment where resources scale up or down on demand. These resources are highly virtualized implementations of the same technology enterprise organizations run in their on-premises datacenters, the key difference being many tenants versus one.

As we look to implement (cloud) security in this IT unique architecture, we want protections that are native to that environment, cloud native if you will. That is when the conversation can get complex quickly, turning into a discussion that may include loosely coupled containers, CI/CD delivery platforms, serverless security, and microservices. Surely, these capabilities allow developers to make changes frequently without affecting other components of a hosted application. The foundation is flexible, scalable, and oriented toward a new type of infrastructure. However, it does not sound easy. As a result, when it comes to a responsibilities conversation regarding the security of the cloud, as opposed to in the cloud, those measures of security and integrity should be provided by the cloud provider to deliver on the promise of flexibility, choice, and ease of deployment and not the application owner's responsibility.

My suggestion in our quest for "cloud native security" is to flip responsibility. Cloud native security should be security measures that are native to the cloud--an integral part of the cloud offering. Thus, cloud native security is something that the cloud provider offers to application developers seeking to realize the benefits of flexibility, choice, and ease of deployment, regardless of where the ownership lies in the shared responsibility model. Let me elaborate on some examples based on an IDC lab validation study of OCI.

Hardware Security

Cloud, by default, means using someone else’s IT infrastructure; the hardware integrity of the infrastructure is the foundation upon which all future measures are built. If it's always the same organization using the basic compute elements, then any redeployment typically doesn't require a deep scrub right down to the firmware elements. Cloud native security requires refreshing all the way down to the firmware as, in a public cloud environment, there are no assurances that the boot code, the platform software, and any middleware are safe and secure for company B to use after company A reduces its current application-level demand.

If you were going to build your dream home, would you want to pour a brand-new foundation, or raze a house that was built in the 1930s and build on a foundation of unknown integrity? Remember, this is your dream home. The compute elements of a cloud-native architecture must be securely re-deployable. Cloud native security necessitates the ability to document and demonstrate the capability to wipe the firmware removing any traces of a previous use.

A second element of a cloud-native security involves a firewalling of the compute instances after the initial deployment. Given the sophistication of today's external attacks, it's possible that a software infection begun at the application level of a hosted service can travel all the way down to the bottom of its executable stack, and then begin an east-west attack on other discoverable cloud instances as it traverses the network fabric. It's rare that an initial breach occurs within a part of the environment that contains the ultimate paydirt in the form of sensitive data, credentials, and customer PI. IDC believes cloud providers that have isolated their network layers offer another important construct of a cloud-native infrastructure design.

Software Security

Again, organizations moving to the cloud seek flexibility, choice, and ease of deployment, but they are often less skilled in the security exposures, the deployment requirements, and the maintenance activities. Helping customers with their portion of the shared responsibility model is another opportunity for cloud vendors to deliver cloud native security.

Compartments, for example, allow tenants to develop fine-grained, logical asset management boundaries and access policies — a basic capability that one really begins to appreciate when it's missing. It does for the cloud what virtualization does for servers, and just about no one gets these boundaries right the first time until there's more operational experience to review. IDC believes compartments are an elegant means for simplifying adjustments to a cloud-native solution deployment.

Compartments can be created in security zones with additional immutable security policies. A security zone is associated with a compartment of the same name, but you cannot add or move a standard compartment to a security zone compartment unless all policies are met.

Another helpful design characteristic is the Identity and Access Management (IAM) Group. Groups allow users to access resources within compartments via policies that are written for the group and not the user. It’s another element of cloud management flexibility that reduces the combinations of user permissions required to protect a tenant's data. Using groups and compartments, tenants can marry their physical organizational structure to available cloud resources adding, changing, and deleting instances and people along the way. IDC knows that authorizations and access policies can quickly become a quagmire when every tenant participant insists that he or she is a snowflake (i.e., unique).

Cloud-Native Security is Scrub-able, Adjustable, and Governed by Explicit Policies

Finally, cloud-native security discussions also tend to include things like artificial intelligence and machine learning, big data analytics, multi-vector threat detection, and threat intelligence, etc. Some public cloud providers can be more specific with such insights, tips, and recommendations because they have visibility into the customer’s tenant(s).

IDC believes a cloud-native architectural design is fundamentally different from the technology and practices organizations have long implemented within their on-premises environments.