We're going to discuss more closely, virtualization
risk and their remedies in the cloud.
In the shared responsibility model, the water line is that the provider is
responsible for physical security and the based infrastructure,
which means they need to pay attention to the hypervisor security. Now,
although hypervisors are now something that you can
actually consume and configure, in most cases,
this is on the side of the provider.
Here are the major issues,
security flaws that could be found in the hypervisor could be exposed by
such threats like Spectre and things like Meltdown.
You have inadequate granularity of controls that could be a
lack of governance related to administrative,
technical, and physical controls, and you have over subscription.
The threats that the security flaw can create is something known as
hyperjacking or VM hopping. This all happens because a tenant may be
capable of escaping from their host operating system. From the standpoint
of inadequate granularity of controls,
there may be a lack of attention from a governance
perspective to have administrative, physical, and technical controls operational.
The other element of there being oversubscription of services,
the actual threat could be that there are lack of controls at the provider's
location that would prevent the limits, and the reservations, and the shares
from being active that we talked about earlier.
Again,
it must be stated, most of this would most likely be on the
cloud service provider's side of the water line.
Let's look at the cloud service providers that dominate the market.
Amazon, their AWS service has Xen and Nitro for their hypervisor
currently, Google uses KVM, and Azure uses Windows Hyper‑V. Let's take
a look at what they say about their own product and the security that
they publicized to the public.
AWS's Nitro security states that they use what are called enclaves now. This
enclave technology is hypervisor technology that provides CPU and memory
isolation for their EC2 instances. They get this accomplished by means of a
Trusted Platform Module, or a TPM, currently at 2.0. This is a security
compatibility feature that makes it easier for customers to use applications
and operating systems, capabilities that depend on TPMs in their EC2
instances. And it also conforms to the TPM 2.0 specification, which makes it
easy to migrate existing on‑premise workloads that use TPM functionalities to
EC2. This, in turn, helps to provide a secure cryptographic offload using
AWS's Nitro System, and allows for EC2 instances to generate,
store, and use keys without having to access the same keys.
Additionally,
they have an internal governance system that they call lockdown
security model, which prohibits all administrative access,
including those of Amazon employees,
eliminating the possibility of human error and tampering.
On the Google side of the world, they use KVM, which is
Kernel‑based Virtual Machine.
This is an open‑source virtualization technology built into Linux.
KVM lets you turn Linux into a hypervisor that allows a host
machine to run multiple isolated virtual environments called
guest or virtual machines.
This is, in fact, their hypervisor.
The version of Linux that was released after 2007 is the one that could be
installed on an x86 architecture, and it supports virtualization capabilities.
Looking more closely at their description, one of the things that Google uses is
proactive vulnerability searching. These are multiple layers of security and
isolation built into Google's Kernel‑based Virtual Machine, and they're always
working to strengthen them.
Google's cloud security staff includes experts in the world of KVM
security, and they've uncovered multiple vulnerabilities in KVM in
Xen and VMware hypervisors over the years.
They reduce their attack surface by running in a non‑QEMU environment.
The reason why they don't use this is because there is a history
of security problems with QEMU, a long track record of security
bugs such as VENOM, and it's unclear what vulnerabilities may
still be lurking in the code.
All jobs that are running on the VMs will only run by means of cryptographic
key sharing, with jobs running on that host helping to make sure that all
communication between jobs are actually encrypted. Code providence means
that they run a custom binary and configuration verification system that was
developed and integrated into their own development process to track which
code is running.
Imagine a monitor that only allows code that has
been preapproved to be executed.
Their rapid and graceful vulnerability response defines a strict set of SLAs,
both internal and to their customer, for processing patch management in the
KVM environment in an event that a critical security vulnerability is
discovered. Their internal infrastructure helps to maximize security
protection, and then to meet all applicable compliance requirements externally
to notify customers of updates and any kind of contractual and legal
obligations they have to do this.
All of their releases are based upon stringent rollout
policies and processes for their KVM updates.
This is also driven by compliance requirements for Google cloud security
controls, and there's only a small team of Google employees that has access to
the KVM build system and release management control.
Azure capitalizes on host‑based isolation in a
process of hosting cross‑VM components.
They use Virtualization‑based security, known as VBS, for ensuring the
integrity of user and kernel mode components from a secure world so the
isolation continues down into the foundation of the hypervisor.
They have multiple levels of exploit mitigations. Mitigations include
Address Space Layout Randomization, so that if a virtual machine is
somehow being monitored in a side channel,
the data that is being committed to disk is actually not in
an order that could be easily figured out.
There's also controlled initiation of stack variables that
go all the way down to the level of the compilation of the
code or the compiler level.
They also have zero‑initialize,
which could potentially help to block injections into the OS level.
Here, the kernel APIs that automatically zero‑initialize kernel heap
allocations are made by Hyper‑V. There are various other risk
associated with consuming certain levels of the SPI model, including
having people from the inside of your organization initiating
unauthorized workloads.
The simplicity of starting a new workload is as
simple as pulling out a credit card.
East‑West movement of advanced persistent threats could be another issue.
Again, depending on the level of consumption that you're at, if you've used
cloud‑native architecture, it will be less likely that East‑West or lateral
movement of advanced persistent threats are likely. Improperly trained staff
anywhere along the SPI stack, applications that don't have security from
their initiation in the design process, also, lack of due care and due
diligence with the granularity of controls that are implemented, and just
overall Shadow IT, the same things that cause this unauthorized workloads.
Google actually mentioned in their report of 2021 for cloud threat
intelligence, that a large number of compromises, most of them are actually
used to perform cryptocurrency mining. The vulnerability that is made so that
the systems can actually be overtaken and instances can be installed is
usually by means of some type of third‑party software, something for us to
really watch for in the supply chain.
The main thing that we want to be thinking about is how do we
limit the blast radius? It's not that we won't be attacked,
but if an attack is successful, how well do we contain that attack?
Join me over in the next clip as we look at a major
element to success, Zero Trust.