(bright music)
- Up next, we take an exclusive look
at Microsoft's work with Intel
to protect your most sensitive information in the cloud.
We'll unpack the latest silicon-level Zero Trust protections
and how they help mitigate against privileged access attacks
with hardware enforced protection
of your most sensitive data
with Intel Software Guard Extensions,
plus additional defense in depth silicon-level protections
against data exfiltration for memory.
And beyond security, we'll also demonstrate
confidential computing scenarios that are now possible,
such as machine learning analytics
on multi-party data and more.
And joining us to walk through all of this
is data center security expert,
Mike Ferron-Jones from Intel.
Welcome to Microsoft Mechanics.
- Thanks, Jeremy, it's a pleasure to be on the show.
- And it's really great to have you on
explaining another key part
of the Zero Trust defense in depth story in Azure,
which really spans from the silicon
all the way up to the cloud.
- Right, and Silicon plays an integral part
in a Zero Trust defense in depth strategy.
At Intel, we've spent almost two decades
creating hardware-based security innovations,
and these include the protection of data held in memory
as well as protections for data actively in use
during the compute operations
in places like the Azure cloud.
- And that's really the point,
because like our CTO Mark Russinovich often says,
it's your data.
And as part of Zero Trust,
even your cloud service provider
shouldn't be inside your own trust boundary.
So for Azure's part,
we're already providing a secure environment
where we protect your data
while it's in rest in data centers,
and also encrypt it while it's in transit.
And with Azure confidential computing,
we take it a step further
by protecting your highly sensitive data while it's in use.
And you can hold the encryption keys as well.
And this is really good news,
especially if you're from a highly regulated industry
or maybe you have privacy and compliance concerns
over exactly where your data is stored
and how it's accessed by apps, processes,
and even human operators.
And these are all areas by the way
that we've covered on Mechanics at the service level.
And we have a whole series
dedicated to the topic of Zero Trust
at aka.ms/ZeroTrustMechanics,
but as we'll explore today,
silicon-level defenses take things to the next level.
So why don't we get into this
by looking really at potential attack vectors,
and why don't we start with memory attacks?
- Right, so a security mindset
means that we've got to be prepared for the worst.
And so the scenario I'm going to start with today
may seem a bit far-fetched,
but the very fact that we defend against it
shows how seriously we take a defense in depth approach.
Now, something a lot of people don't know is that DRAM,
even when it's powered down,
can retain its data for up to several minutes
under certain environmental or temperature conditions.
So imagine that a rogue admin in the data center
was able to spray liquid nitrogen
on the memory to freeze the DRAM,
remove the DIMMs and install them into another device
that dumps and stores the memories contents.
Then it can be analyzed for sensitive, valuable information
such as encryption keys or account credentials.
This is known as a cold boot attack.
- And this seems pretty far-fetched,
especially given all of the protections that we have
for accessing Microsoft's data centers,
all the perimeter securities, etc.
So it kinda seems a bit more
like a mission impossible style attack.
How would we stop something like this?
- Right, I mean, a lot of things would have to go wrong
in order for this type of attack to succeed,
but here's where Silicon level protection
can help prevent this attack.
The latest generation of Intel Xeon Scalable Processors
are equipped with a technology
called Intel Total Memory Encryption,
which helps protect the data stored in memory
with a unique hardware protected encryption key.
The Xeon memory controller encrypts the data
as it's written to the DIMM,
so that even if the data is dumped,
none of it is readable.
- And while this seems like a pretty unlikely attack,
you know, it really brings home how important it is
to protect data while it's in memory.
I personally had no idea
that when you take the DIMMs off the board
and they're powered down,
they still hold some memory that you can actually exfiltrate
and get into another device.
But is there something, you know,
maybe doesn't require as extreme of a situation
as physical infiltration into the data center
where memory protection might come into play?
- Sure, so let's take an example
of a cross tenant data exfiltration attack.
So let's say a sophisticated attacker
poses as an Azure customer,
and they set up an instance
with a malicious virtual machine.
Their plan is to spoof legitimate memory reads
from neighboring VMs
and bring the data into their malicious VM.
So to succeed,
they have to first get past the Azure Hypervisor,
which works with the CPU's virtualization technology
to create page tables that assign separate memory regions
for each VM on the DIMMs.
The attacker's VM includes an exploit
that tricks the hypervisor to copy the page frame numbers
from the software page table,
such that the malicious VM can read or copy data
from the memory regions of neighboring VMs.
- And to be clear, you know,
an attacker would need to discover a zero-day vulnerability
in the hypervisor itself.
So it's really no small feat.
- No, it's no small feat indeed,
but with a Zero Trust mindset,
we shouldn't underestimate
the sophistication of the attacker
or overestimate the invulnerability of software.
So to layer on another level of protection,
that's where our Xeon processor
with the Total Memory Encryption Multi-Key capability
or Intel TME-MK comes into play.
As the hypervisor and CPU assign memory regions to each VM,
TME-MK assigns each VM its own encryption key
that's protected by the CPU's hardware.
So now if we play back the attack,
even though the attacker's VM
uses the zero-day hypervisor exploit
to access the memory of neighboring VMs,
it can only read or copy cyphertext from memory.
The stolen data is unreadable.
- And this will help protect
against certain forms of lateral attacks
like the one you just described.
And I know that some Azure customers
will opt to pay more for server infrastructure
that's dedicated to their organization,
so by design it isn't shared with other organizations.
So using things like TME and TME-MK
could be a less expensive way
to get additional levels of isolation and protection.
That said, though, I'd like to dig in a bit deeper,
you know, into the area of partnership with Intel,
you know, in terms of the protection of data
while it's in use.
- Right, so you're talking
about confidential computing, of course.
Now this is an area of joint innovation
where we focus on protecting data
while it's actively in use in the processor and memory.
And Intel and Microsoft were founding members
of the confidential computing consortium,
which was created to move this area of computing forward
through investments in technology
and in building the ecosystem.
To help protect sensitive data while it's in use,
Intel developed Intel Software Guard Extensions, or SGX,
that create protected areas of the CPU and memory,
what we call an enclave,
designed to allow only verified,
trusted code to process confidential data.
- Of course, Microsoft also built
the Azure confidential computing DC series virtual machines,
which leverage these silicon level innovations.
So what types of attack then
does Intel SGX help to mitigate?
- So one of the most difficult types of attack
to protect against is a privileged escalation attack.
Now these are most commonly software-based attacks
where low-privilege code exploits vulnerabilities
in high-privilege software
to gain deeper access to data,
to applications or the network.
- And equally a rogue system admin inside the organization,
or a bad external actor with stolen admin creds
could also have access
to do reconnaissance inside the network.
So how would something like Intel SGX stop here?
- So as we've touched on,
Intel SGX can help mitigate these types of threats.
It's designed such that any software
running outside the enclave
can't see the data and code inside.
Even if it has escalated its privileges,
it's just not trusted.
Now that includes any other applications,
operating system, the hypervisor,
even the VM and cloud administrators.
In fact, Intel SGX has the smallest trust boundary
of any confidential computing technology
in the data center today.
- And that really helps mitigate against things
like the rogue insider reconnaissance effort
and only trusted and protected code or algorithms
would be able to see and process the data.
But would this work then
if maybe the app was hijacked or overwritten?
- Mm-hmm, and this is where attestation comes in.
Intel SGX aware applications
have a cryptographically signed and authenticated manifest.
If an attacker attempts to modify the code,
the profile of the modified code won't match the manifest
provided by the original author of the software.
It'll fail attestation,
which means it can't load
and it can't access the confidential data.
- And you also mentioned the term SGX aware,
and to that point, you know, there's been a ton of work
to make sure that apps and workloads
can take advantage of Intel SGX.
So Microsoft has contributed to an open enclave SDK
for developers to easily build apps
that can take advantage of the hardware enclave
during specific operations.
And we've also taken one of our most popular apps,
SQL server, and also other derivations of SQL,
and made those SGX aware as well,
with something called Always Encrypted with secure enclaves,
which leverages Intel SGX to run the SQL query processor
inside of the enclave.
And in the Azure marketplace,
we've also published over a dozen different solutions
provided by ISVs.
That said, though, why don't we look
beyond the different attack mitigations?
Why don't we switch gears to something that might light up
as part of using confidential computing scenarios?
- All right, well, that's the really exciting part.
This opens up new ways for different organizations
to work together on shared datasets
in multi-tenant public cloud services
without compromising security or privacy.
I'll show you an example here
where two banks want to combine their individual datasets
to perform a fraud analysis on a larger pool dataset.
Now by combining their data,
they can increase the precision
of the fraud detection machine learning model,
so that both banks benefit
without exposing their transaction data to the other bank
or to the cloud operators.
Now here you can see, I have three windows open.
On the left side,
I'm logged into two different bank environments.
The one on the right is from a virtual machine in Azure.
Again, each bank environment has its own private dataset
that it owns and controls.
Now I'll start with a baseline.
I'm going to kick off
the fraud analytics inference detection
on top of bank one's dataset.
And I get a precision of around 92.7%,
and each bank will get a similar result
on their individual dataset.
Now, the challenge is that this is regulated data
and that each bank would want to protect it
from access by the cloud provider,
as well as the other banks.
- How much better does it get then
when bank one and bank two combine their datasets?
- And that's what we're trying to solve for
with the right security guardrails in place, of course.
Now I'll combine the datasets from both banks
and perform the same fraud analytics from before,
using the VM running in Azure.
Now, once it completes,
you'll see that the precision increases to 98.2%
versus the 92.7% that we got
just using bank one's data alone.
And this sounds promising,
but I perform this computation
using data from two unencrypted data files.
- And right now the data sharing model
between the banks and the operator isn't ideal.
So how can we add more protection to that?
- Yes, so since the data files weren't encrypted,
each bank's data could be visible to the other bank.
It could also be visible to an intruder in their shared VM
that hosts the fraud detection model or the VM's memory.
And from a confidentiality and regulatory perspective,
this just isn't going to cut it.
In this cloud operator window,
I'll first look at the processes run in the Azure VM.
And then I identify the process I just ran,
which is 17,838.
I can dump its memory contents,
and we can see that the data that we want to protect
is in the clear and vulnerable to anyone with access
to what ran in memory,
whether that's a rogue insider,
or an attacker who manages to breach the infrastructure.
- So how can we make this even more secure?
- Well, let's run that same computation
using Intel SGX enclave.
So in this case,
I'll use encrypted data files containing the same data
that we just used from bank one and bank two.
Now I'll launch the app using Intel SGX
and an open-source library OS called Gramine
that allows an unmodified app to run in an SGX enclave.
In doing this, only the SGX enclave has access
to the encryption keys needed to process the data
from the encrypted CSV files.
Now, first I'll run the analytics one more time.
And as you'd expect,
we get the same precision as before, 98.2%.
But this time the memory is protected.
If I go back to the view from the operator window,
and I look at the process list again,
and for that last run, it was 17957.
Now I'll dump the memory from this process
and you'll see that there's not any visible sensitive data
in the memory dump at all.
Only the protected processes inside the enclave
can see the data and process it.
- And importantly, in this case,
both banks actually have the advantage
of higher precision analytics.
The data was protected all the time end-to-end,
including while it was running in memory.
- Right, and this is a big advantage for both banks,
because it's really hard to do fraud detection on your own,
especially when the potential violators
are hopping from bank to bank to bank.
And this is just the tip of the iceberg.
There are so many more confidential computing scenarios
across a range of industries.
You know, these often involve multi-party computing
on shared or regulated data.
Now this could be everything from disease diagnostics
in healthcare involving multiple hospitals,
high security information sharing
within or across governments,
or to secure payment processing,
including credit card or bank transactions,
just to name a few.
- And Intel SGX, along with Azure confidential computing,
makes it a lot easier to create confidential clouds
inside the public cloud to host your most sensitive data.
So for anyone who's watching,
looking to build solutions on Intel SGX,
or learn more about memory encryption technologies,
what do you recommend?
- Right, so to learn more
and keep up-to-date with Intel innovations in this space,
you can go to intel.com/security
and to learn more information about Intel SGX,
go to Intel.com/SGX.
- Thanks, Mike, and also be sure to check out aka.ms/AzureCC
for more information on Azure confidential computing.
Of course, keep watching Microsoft Mechanics
for all latest tech updates.
Subscribe to our channel if you haven't already,
and as always, thank you for watching.
(bright music)