How to approach security in a Multi Cloud Environment

This is the sixth blog article in a series about security in global public clouds like Amazon Web Services (AWS) or Microsoft Azure. I will elaborate on security problems in multi cloud environments and how we can tackle them head on.

Blog Series about Security in Public Clouds

This blog is part of a blog series about security in public clouds. if you are interested in the topic more deeply have a look at the introductory blog where all related articles are listed and linked.

What is a Multi Cloud Environment?

{Shamelessly copying from Wikipedia} –> „Multi cloud is the use of multiple cloud computing and storage services in a single heterogeneous architecture.“ This is also known as a polynimbus cloud strategy and refers to the distribution such as cloud assets, software, applications across several cloud-hosting environments. With a typical multi cloud architecture utilizing two or more public clouds as well as multiple private clouds, a multi cloud environment aims to eliminate the reliance on any single cloud provider. It differs from hybrid cloud in that it refers to multiple cloud services rather than multiple deployment modes (public, private, legacy).

In general, hybrid cloud refers to a cloud computing environment that uses a mix of an on-premises, private cloud and a third-party, public cloud, with orchestration between them. The usual case of hybrid cloud is when a specific task, like compute intensive machine learning workloads, is done on cloud instead of putting massive load on the compute of a local datacenter. It must be noted that multi cloud does not exclude hybrid cloud. Hybrid cloud could very well be encompassed in a multi cloud environment.

Why Multi Cloud?

Well, in the early years it was just sheer amount of uncertainty. Nobody was quite sure what lies ahead in the world of clouds. As time went on, the initial school of thought for using multi cloud was to avoid vendor lock-in. That thought process has now evolved to much more broader goals, like redundancy, price competitiveness, capacity and features provided by cloud vendors in different regions. It can also permit and drive agile decision-making process depending on the business goals. The most important factor driving enterprise customers in parallel with above mentioned reasons is data sovereignty i.e. data is subject to laws and governance structures within a nation and/or region it is collected. Data sovereignty is directly associated to data security which is the subject of our blog here.

 

 

Security challenges in Multi Cloud Environments (MCE)

Obvious starting point for security, is to look at our architecture, and the established thought process from there on is to divide or decompose it into perimeters or zones with a notion of boundaries (think firewalls). Within these perimeters is a notion of trust. This conventional thought process worked with certain degree of success within legacy infrastructures, but they are simply no longer valid in today’s fast evolving cloud and multi cloud environments.

«Same old, same old» cannot work in clouds

Cloud environments are by definition elastic, and looking at the current state and to the near horizons, elastic and serverless. The same old security practices cannot dynamically scale and adapt instantaneously. Even more, the traditional perimeter-based approach just cannot keep up with the whirlwind pace at which new features and services are added and adopted inside the cloud environments. Why you ask? Because the traditional definition of perimeters becomes blurred (Cloudy with some chance of Fog, pun intended).

 

 

In the traditional perimeter-based approach we have constructs like IPs and ports, which in cloud are continuously changing and are by definition irresolute, much more so in multi cloud environments. Even if one takes on the traditional perimeter-based approach, the sheer number and continuous changes in size of perimeters and their respective entry exit points, is so huge, that to maintain and update them is essentially impractical. Think in operational terms like upscale, downscale, upsert, purge etc.. And if implemented will surely have holes in as the environment grows.

So, what do we do about it?

Begin with what are we supposed to secure. The now stale joke that „cloud is just someone else’s computer“ hides behind it a very important lesson. Just because the cloud vendor is providing a service, where as a customer we do not have access to the underlying hardware and networks, it does not mean that we are not responsible and accountable for the security of applications and data flowing in, out and within our infrastructure.

Instead of focusing on perimeter-based security, our number one priority must be securing the data, applications, and the workloads. Oversimplifying the previous statement, we need to verify the identity of elements which are accessing the data, apps and workloads (from here on DAWs) and not the cloud environment itself. In other words, it’s an inside-out approach as compared to perimeter paradigm. By using this approach, we position the security as near as possible to our DAWs. And now since we do not have the perimeters we secure each and every element with TNO: Trust No One approach, also known as Zero trust policy.

Where to begin

The place to start implementing these practices should be a two-tracked. First comes data, since data touches literally everything, then apps, compute, networks, end users and their devices. Every app or workload when transmitting or receiving data must go through an identity verification. TNO means we will stop assuming trust based on point of origin in a perimeter and instead, we continuously assert the minimum level of trust necessary (think of least privilege) based on the verified identities of the elements.

Second come key assets, the definition of key assets can vary according to business and its goals; but still let’s go through some usual suspects with examples. Any, and all well framed cloud architectures talk about IaC (infrastructure as code), we won’t elaborate on that here, but it suffices to say IAC is the backbone of any cloud architecture and even more so in MCEs. Hence IaC is an obvious point to begin implementing security. Another key asset we can begin with is Identity Management Service, needless to say, it has to be secured. And a final example is backup services, local or in clouds, access to backups must be well secured, you would be surprised how many times it just isn’t.

The reasoning behind the choice of the above examples is that, these examples have one thing in common: if an attacker gets access to any of these services inside your infrastructure its „Game Over“. The above examples can help to not only identify the key assets, but also help to associate a threat to business continuity ranking for these assets in case of data breach or attack.

Distinguishing and securing access to applications by increasingly unpredictable IP addresses and port numbers is neither fruitful nor secure in the modern threat landscape. Unpredictable due to the nebulous nature of the cloud and elastic nature of the workloads. Instead, applications and services should be identified by their attributes and their immutable properties. Properties which can be used by security teams to configure and deploy potent and enduring security policies.

This effectively decouples security policy from the underlying infrastructure and the continuous change to it and ties it directly to our strategic assets.

Machine Learning: If you torture your data long enough, it will confess

This quote from famous economist R.H. Coase is valid for security in clouds too.

„If you torture data long enough, it will confess to anything you’d like.“ 

Machine learning is a subset of artificial intelligence that uses algorithms to learn from data. The more data patterns it analyses, the more it processes and self-adjusts based on those patterns, and the more valuable its insights become. There is a lot of bling attached to machine learning, and while machine learning is not the silver bullet to get them all, it shifts the focus from prevention to real time threat protection.

Cloud infrastructures, like any other system, produce quite lot of data, so much that thinking that any person or team could go through all that data is more than a whimsical thinking. Machine learning uses all this data to detect threat events. The more data processed, the more patterns it detects and learns, which it then uses to spot changes in the normal pattern flow. These changes could be threats and vulnerabilities.

Machine Learning brings two main advantages to the security landscape:

Event detection & Remediation, machine learning can process the data generated by the systems and find anomalies, they can either alert a human or respond by shutting a specific user or application out, among other options. This saves a lot of precious time while a potentially dangerous piece of code or bad actor could be doing damage.

As a driver for Automation, when security teams have machine learning technologies handle routine tasks and first level security analysis, they are free to focus on more critical or complex threats. This does not mean these technologies can replace human analysts, as attacks often originate from both human and machine efforts. Therefore, responses are required from both, humans and machines. Machine learning can trigger playbooks which generates event-based reports, can be analyzed by security teams and make them more agile. Also help them in compliance and audit initiatives.

On an ending note, let’s bring forth the business benefits of the above-mentioned security practices to multi cloud environments:

  • Reduce risk by identifying key assets and improving observability, in other words reduce of the probability of having blind spots from a security perspective.
  • Reduce area of attack, i.e. minimize the potential of breach.
  • Increase speed and agility with automation and Machine Learning.

Further resources:

Swisscom has published whitepapers on cloud security in which security issues are dealt with in detail. These can be obtained as follows:

If you want to learn more about Swisscom’s portfolio and services on public cloud get in touch with us using the following links:

Also, Swisscom provides a service called W.A.R. Well Architected Review, which covers security aspects too, you can read about it in this blog.

You can access the detailed information about W.A.R. here: www.swisscom.ch/wellarchitected