Today’s subject is about security in the Cloud-city, Cloud security governance.

Before we jump into today’s subject let’s clarify some acronyms and terms that will be used several times in this, and future, article(s) about the cloud.

I have used the descriptions for SaaS, PaaS, and IaaS from Wikipedia, which are the most common forms of cloud services.

• SaaS – is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. SaaS is also known as “on-demand software” and Web-based/Web-hosted software.

• PaaS – is a category of cloud computing services that allows customers to provision, instantiate, run, and manage a modular bundle comprising a computing platform and one or more applications, without the complexity of building and maintaining the infrastructure typically associated with developing and launching the application(s); and to allow developers to create, develop, and package such software bundles.

• IaaS – is a cloud computing service model by means in which computing resources are hosted in a public, private, or hybrid cloud. It provides you with high-level APIs used to dereference various low-level details of underlying network infrastructure like backup, data partitioning, scaling, security, physical computing resources, etc. A hypervisor, such as Xen, Oracle VirtualBox, Oracle VM, KVM, VMware ESX/ESXi, or Hyper-V runs the virtual machines as guests. Pools of hypervisors within the cloud operational system can support large numbers of virtual machines as well as the ability to scale services up and down according to customers’ varying requirements.

Below figure is a sketch that I have made based on how Cloud Security Alliance illustrates the different cloud service models. The below model serves as a holistic and agnostic representation.

There are two more acronyms you need to keep track of in today, and future cloud, article(s):

• CSC – is the term for Cloud service customer and is the consumer of the cloud service.

• CSP – is the term for Cloud service provider and is the provider of the cloud service.

WHAT ARE CLOUD SERVICES

Cloud services are nothing new as such, mainframe systems have provided similar capabilities since the early days back in the 90s.

For example:

• Scalability
• Abstraction
• Pooling of resources
• Measured services
• Virtualization

After a while, the hypervisor technologies, i.e. virtualization, were introduced which made it possible to virtualize Windows and *nix boxes running in the on-prem data centers. Many companies had already even before the introduction of hypervisors started to provide hosted services to external organizations.

In my early days, I had the opportunity to work for one of the largest hosting providers in the Nordic region. The experience and knowledge gained from that time are something that I still carry with me today.

Cloud services increase abstraction. This is especially true to a high degree when it comes to SaaS. And when it comes to configured configuration capabilities, i.e. from a customer perspective, these capabilities vary between the services. And this is also something that needs to be contemplated from a cloud security governance perspective. In a SaaS service, the customer has low configuration capabilities in comparison to a service located in the on-prem data center. This also means that there is a higher shift in responsibility from a security perspective, between the CSP and CSC, in the different service models. And is something that needs to be contemplated, understood, and clearly stipulated as a part of the cloud security governance model, and in the contract and, agreements between the CSP and CSC. I will stop here, the Share responsibility model related to cloud services is a subject for another article.

IS THERE A DIFFERENCE?

Are there actually any differences between how IT services are operated, provided, provisioned, and managed back in the days compared to how things are today now when they are provided as “cloud services”?

The answer is “yes” and “no”. In some cases, there are very low discrepancies for how one cloud service is provided today compared to back in the old days, at Gandalf’s time. And in another scenario the discrepancies are high. The reason behind this is, in general, due to that one cloud service (SaaS, PaaS, IaaS) provided by one cloud service provider (CSP) may diverge (from an architectural, technology, management, security perspective etcetera) compared to a cloud service provided by another CSP. There is nothing wrong with it, this is just how it is.

In this article, we will look at cloud services from a security perspective related to governance. Cloud Security Governance.

Security, independent of if it is something in a cloud or an on-premises service in a data center, is not only about technology. Security is about Humans, Technologies, and Processes.

I will talk about security in the cloud from an agonistic perspective. Cloud security is agnostic. It is and shall be treated, from a holistic security perspective, as something that is vendor, product, and technology neutral.

My goal is not to point out particular suppliers of cloud services, certain organizations or saying X is better than Y because of W, Q, and Z. I will zoom out around the subject “cloud security” from a governance point of view and apply it vendor and product neutral. And security, as a discipline, is agnostic. It is neutral. Technology is something related to security, but it is not the only thing.

Security is not about a certain vendor, product, brand, appliance etcetera. And security in the cloud or in the on-prem data center shall be built on good and intelligent security principles.

“Cloud security is agonistic.”

Henrik Parkkinen

CLOUD SECURITY GOVERNANCE

One of the most obvious security differences between on-prem services and cloud services is security governance, e.g. how the services are governed and controlled through their lifecycle.

A service lifecycle implies the whole lifespan of a service. From the investment and procurement, through the operational cycle of the service when changes are made to the stage when a decommission is made of the service. During this life cycle an organization, i.e. the cloud service customer (CSC), needs to govern the service to ensure it provides and fulfills the security requirements of the organization. This is an exercise that is done together with the cloud service provider (CSP).

When digital services were and are installed, managed, and hosted in on-premises data centers the provisioning of the services is strongly dependent on internal processes, procedures, guidelines, teams, and methods. For example, before provisioning of a service in an on-prem data center is possible to be made hardware, connectivity, eventual middleware, software, licenses, protection functions etcetera needed to be in place. These processes and activities are controlled within the customer’s organization.

Due to this reason better visibility and less abstraction are taking place in the on-prem security governance process compared to if the service were provisioned in the cloud through an IaaS, PaaS, or SaaS. Having physical visibility, understanding and knowledge do not automatically equate to a higher degree of security though. Cloud services may be a more secure alternative in some cases. The core message here is, that services located in on-premises data centers, provide the organization with a better insight into how the service is controlled through the life cycle. Simple as that. Each phase in the security governance process can be controlled by the customer’s organization.

Having good insight will equate to a better understanding of the potential threats, vulnerabilities, and risks involved.

If you are interested in Risk Management, you can read more about the discipline in this article, What is Risk Management.

Insight, from a security perspective but not exclusive, is highly reduced when it comes to cloud services. A service installed on-prem though does not mean it is more secure.

But if we compare a security governance process related to on-prem service to cloud services there are some obvious things diverging. These things will, due to the nature that the stuff in a physical data center managed on-prem by organizational employees, require certain specific tasks.

For example, how the physical security is controlled in the data center, and the scalability of the physical locations, and facilities. It will also provide guarantees in form of portability and possibilities to access the physical location, data, and information if needed.

One of the most common vulnerabilities in on-prem services and cloud services is misconfigurations, i.e. technological parameters are wrongly or inadequately applied. If you read through a couple of threat and risk reports related to cloud security this will be one of the risks that rank very high on the agendas and have done so for years. And the reason for this risk is obvious. It has to do with that configurations, in many cases, are managed by Humans. And Humans make mistakes.

I will provide a real-life example for you that I have come across more than once related to this risk and when it comes to IaaS cloud services. And keep in mind that this example is not generically related to IaaS cloud services and has very little to do, or close to NOTHING, with the technology or service. The primary source generating the vulnerability related to this scenario resides on the other end. The person who (miss-)configure and deploy the stuff.

REAL-LIFE CASES

I have witnessed, more than once and twice, really nasty security incidents take place in organizations due to misconfigurations in cloud services. For example, resources located on the internal corporate network have been exposed, by misconfigured routing and network communication, due to simple mistakes. This has led to the bad guys have been given a highway into the organization’s network by fairly easy methods.

The pathway has provided the bad guys with initial access into those networks from where pivoting and lateral movement has started out. ”Lateral movement” is a form of the pathway where the bad guys start out to gain further advancement into the organization. This is done by, for example, enumerating the environment, gathering information, and mapping out critical and sensitive assets. There are loads of tactics, techniques, and procedures for accomplishing these tasks.

And this can lead up to something like <*BAAAAAAAAM*>. Say hello to nasty Mr. Ransomware. <*KABOOOOM*> Domain compromise of the organization’s Active Directory. Not so cool. Not cool at all. A really bad scenario that is a result of a misconfiguration. A Human mistake. Those simple “clicks” in the cloud service control plane together with less good security hygiene in the network made this possible.

So, what can be done to reduce these forms of mistakes? One of the most critical aspects is to use apply stringent security governance, change, and configuration management processes. The same processes were used when implementing, configuring, and managing things in our on-prem data centers. Of course, there need to be some adjustments here and there, when it comes to the Cloud security governance process, but the core principles are the same.

A portion of these is:

• Use a systematic process for implementation, configuration, and management.
• Track all the changes made to cloud services and ensure relevant testing is conducted prior to production implementation.
• Conduct risk assessments as a part of the security governance, change and configuration management process to reduce potential negative business impacts.
• Contemplate and establish a security governance process built around Humans, Processes, and Technologies.

The average time (2021 figures) an adversarial threat actor is kept unidentified in an organization is around 270 days. That is a lot of time. Think about how much intel they can gather during that time frame. All the shady stuff they can accomplish. It would be very creepy if a thief had access to your house for 270 days. Sneaking and lurking around in the shadows. Not so cool.

Increasing the likelihood to identify and detect these forms of patterns, anomalies, deviations, and other shady things can be accomplished with the help of intelligent identification and detection management capabilities. Intelligent identification and detection management capabilities are a composition of Humans, Processes, and Technologies. There need to be Humans dedicated to this form of activity. Processes in place dictate how certain procedures are conducted, from a preventative and protective perspective. And Technologies that make it possible to effectively identify, detect and respond.

RECOMMENDATIONS

Establish a systematic process for cloud security governance.

Ensure that your organization’s overall security hygiene is managed and continually improved over time.

Cloud security governance needs to cover Humans, Processes, and Technologies. Ensure that all of these elements are contemplated and included in your cloud security governance model and processes.

EPILOGUE

There is more to be said about the subject, Cloud security governance. This is one part of the fundamentals. Another part, which is strongly related to, the Cloud security governance process is contracts and agreements. The commercial contract that is agreed upon and related to the cloud service, provided by the CSP to the CSC, covers and stipulates responsibilities and accountabilities for each party. This will be something that I cover in a separate article.

I encourage and recommend you as a reader of this article, and if you find cloud security as something interesting, to also visit Cloud Security Alliance website (CSA). I do not get any form of commission from CSA for mentioning or recommending them as an organization. I do this due to I am a big supporter and fan of the job they do. Shout out to Cloud Security Alliance! Thank you, CSA, for the great work you put in! I am glad to be a part of such a strong and great community.

The Cloud Security Alliance (CSA) is the world’s leading organization dedicated to defining and raising awareness of best practices to help ensure a secure cloud computing environment.

Cloud Security Alliance (CSA)

Stay systematic. Intelligent processes. Contemplate risks. Security hygiene. Continually improve. Risks change. Threats change. Manage vulnerabilities. Strive for resilience. Cloud security.

Henrik Parkkinen