Hello, and welcome to my course.
Cloud Security Operations for CCSP.
My name is Lyron Andrews.
I'm a cloud security consultant,
small business owner specializing in cybersecurity training,
and a cybersecurity author.
This course has a value of 16% weight for the total of the CCSP exam.
As you join me in this course,
you'll find that it contains a significant amount of detail of
the system's components and administrative controls related to
physical and logical cloud security.
The course cadence is such that each module will contain necessary
knowledge and definitions that starts us off,
and then I will make use of the AWS Management Console to show the
configurable options of what has just been discussed.
Let's begin in the components section of the course.
First,
let's enumerate all of the major components that
provide physical and logical security.
Then, we'll review the configuration options of the major components.
And finally,
I will demonstrate use cases for implementation by actually
logging into the AWS Management Console.
Let's begin where you probably already have a good foundation of
the service provider's hypervisor security.
This is the basis for the majority of the major services,
including compute network and storage.
For a few minutes,
let's walk through the top three CSP's hypervisor type and security options.
As a brief review, there are two types of hypervisors that exist.
The type II predates the type I,
and this is the one that was an operating system.
hypervisor that allowed a traditional operating system to host
other operating systems, or what's called a hosted application
hypervisor that is actually a virtualization that is presented
inside of an application.
But the type I hypervisor is the modern day hypervisor of the cloud.
When you consider the rings of protection that provide a
theoretically more secure space toward the center, at ring 0
for a traditional operating system,
that is the area that should have the greatest
services related to confidentiality,
integrity, and availability, right there at ring 0 in the center.
But the type I hypervisor would have the hypervisor at the
theoretical ring ‑1. The security kernel of the launched operating
system would be above the hypervisor with very strong protection so
that the communication is only from the hypervisor to the guest
host serving up hardware,
but not the other way around. The type I hypervisor is also
known as bare metal or embedded because it can actually be
installed directly onto the hardware.
In some cases, it can show up as firmware. It can be as small as a few kilobytes
up to a few hundred megabytes, a huge difference in attack surface for a
traditional operating system that is gigabytes in size.
Let's for a moment consider the major cloud provider's
hypervisors that exist out there,
starting with Amazon Web Services' Nitro security.
The Nitro Enclaves is a further decoupling of hardware‑specific protections
that can be offloaded and broken down into dedicated hardware.
The Unified Extensible Firmware Interface for the Nitro Enclave actually
does a secure boot of a server to each of your instances.
It protects from tampering and provides proof of integrity for each EC2
boot instance using a specialized Trusted Platform Module that we'll
discuss in detail shortly after this clip.
That Trusted Platform Module also provides for secure
cryptographic capabilities that would include attestation and
confidentiality, or tamper resistance.
The Google Cloud specializes in KVM hypervisors.
This is a derivative of the Linux kernel, and they're known quite well
for finding and fixing vulnerabilities. Over the years, the Google team
has historically founded fixed nine major vulnerabilities in KVM, and
during that same period, the open source community didn't discover any
vulnerabilities in KVM.
They do not make use of the user space virtual
machine monitor and hardware emulation.
Instead,
they actually wrote their own user‑space virtual machine that has multiple
security advantages over QEMU, including the fact that QEMU has a long track
record of security bugs. In their environment, they also use a strong
cryptographic communication capability that protects also the attestation
and the confidentiality of the transmission of data down at the level of the
kernel that's running.
They have a robust code provenance team that is designated only for
managing that hypervisor and then a way of doing code provenance so
that releases are tightly controlled.
Azure uses a security policy mandate so that no information is
transferred between VMs by means of host‑based isolation.
They use the Hyper‑V security, and the Hyper‑V hypervisor
is the one that runs on their systems.
They rely on hardware and firmware mechanisms such as Cerberas chip to
protect and detect underlying platform security.
This helps to provide security from attacks,
including side channel, where if all the other mechanisms were bypassed,
they could provide address‑based layout randomization protection for
any of the data that's appearing on the machines.
They have a fully automated capability of reviewing the stacks on a
constant basis, and they make sure that all the code starts off
from it in a tested space that can help prevent the platform
integrity from being compromised.