By Mike Bursell, Executive Director, Confidential
Computing Consortium
Let's pretend that you're looking to buy a dog to protect you,
your house and your family and you've found the perfect breed: friendly with
the family, but known to be alert and defensive towards possible threats. Before you buy one, however, you check online
to find out whether it's really going to fit all of your requirements. And you find the same comment over and over
again: "there's one drawback with this breed: they'll protect you when you're
out on a walk, they'll protect you when you're asleep at night - but if a
threat arrives during the day when you're up and awake, they're completely
uninterested. No use whatsoever - will
just lie down and have their ears rubbed, before allowing any intruders access
to whatever they want."
Believe it or not, that's the situation with how most of us
currently do security in the Cloud (not to mention on premises, the Edge and
beyond): we only protect data in transit (on the network) or at rest (in
storage). When data is in use? Completely vulnerable to anyone who has
access to the system on which it's running.
That's because of the way that standard computing - including virtualization
with virtual machines or containers - works: the host computer requires access
to all RAM in order to allow your workloads to run. This means that anyone with administrative
access to that machine - a malicious actor in your CSP, an insider, a hacker
using an Advanced Persistent Threat (APT) - can look at and change your data,
however important and sensitive it is.
And whoever you are, whatever your business, you definitely have
sensitive data: data that you are employed to protect - and may become quickly
unemployed if you don't.
Until a few years ago, the only ways to protect data in use
were through air-gapping (not a great start for systems that want to access
networks) or HSMs (expensive and complex Hardware Security Modules). Over the past few years, however, silicon
providers have provided new, hardware-based functionality called Confidential
Computing that allows you to protect your data and applications even when
they're running, and even against the most privileged and powerful administrators
and applications on the system. All the
major CSPs now provide the capability to run your workloads using Confidential
Computing, and there are a growing number of vendors with products and services
that employ it. And, as you'd expect for
any security technology, there are open source projects from various
organizations out there that allow you to employ Confidential Computing on your
own.
Sensitive data - data that we need to protect from malicious
attacks or exfiltration - is all around us, and whether it's regulatory
pressures, our board or just concerns about our customers and business partners
that prompts us to protect it, that protection should be constant. Only turning on protection for certain states
of data makes no sense: data doesn't stop being sensitive or important when
it's in memory! In fact, the same goes
for many of our applications. Any time
that you have a proprietary AI model, a risk assessment tool or an application
that includes business or trade secrets in how it works, that application
becomes important to your organization.
Like the data it uses and acts upon, that application is sensitive, and
needs protection.
And the way that we deploy containers is a particularly good
example. For all the talk of DevOps (and
its more security aware friend, DevSecOps), the people operating your control
plane are often different to the people operating your containers and workloads
themselves. The control plane
administrators (the people actually managing your Kubernetes, Openshift or
Heroku deployment, for instance) may be internal or outsourced to your CSP, but
in either case, they are unlikely to be authorized to access (or even change!)
the workloads that are running. You may
also wish to protect your control plane from whoever is operating the host
systems themselves: whether those are the people you expect, or unauthorized
malicious actors. Where different groups
can't be fully trusting of each other, they each need their own guard dogs.
Confidential Computing allows for protection for applications
and data, isolating them in memory from unauthorized access by even the most
sophisticated and privileged actors. The
Confidential
Computing Consortium, part of the Linux Foundation, acts as the
industry body for promoting the adoption of Confidential Computing, including
facilitating collaboration on technical work, raise awareness, and hosting key
open-source projects to help organizations like yours find the right 'guard
dog' for your data. With Confidential Computing, you don't have to worry about
your guard dog taking a break when it matters most.
To learn more about Kubernetes and the cloud native ecosystem, join us
at KubeCon + CloudNativeCon North
America, in Salt Lake City, Utah, on November 12-15, 2024.
##
ABOUT THE AUTHOR
Mike Bursell, Executive Director, Confidential Computing
Consortium at Confidential Computing Consortium
Mike Bursell is the Executive Director of the Confidential
Computing Consortium, having been involved since its foundation in 2019. He is
one of the co-founders of the open source Enarx project and was CEO and
co-founder of the start-up Profian. He has previously served on the
Governing Boards of the CCC and the Bytecode Alliance and currently holds
advisory board roles with various start-ups. Previous companies include
Red Hat, Intel and Citrix, with roles in security, virtualisation and networking.
He regularly speaks at industry events in Europe, North America and APAC and
has a YouTube channel dedicated to cybersecurity education.
Professional interests include: Confidential Computing, Linux, trust, open
source software and community, security, distributed systems, blockchain.
Mike has an MA from the University of Cambridge and an MBA from the Open
University, and is author of ""Trust in Computer Systems and the
Cloud"", published by Wiley. He holds over 100 patents and
previously served on the Red Hat patent review committee.