00:00:22Confidential Computing
00:15:16Confidential Computing and Verifying Software Trust
00:23:37Benefits and Applications of Confidential Computing
SELLEST OSAST
Data provides the basis for how we make decisions. An enemy of security these days, from our point of view, is plain text. We need better than that. We need device-assisted support for proving where data comes from and how it's been handled. We need systems that keep data (and code) from being altered without cause, that give us the ability to trace the change history of data.
Confidential computing is a new compute paradigm that provides a hardware-based foundation for running code and the data it manipulates. It safeguards data and code (it's all data; it's all code) in its most vulnerable state: while it's being processed.
In this episode of Making Data Better Steve and George are joined by Anjuna's Mark Bauer to dive into this new model's high impact on security and low impact on cloud app development.
Mark dissects the mechanics behind this approach including how it strengthens the software supply chain through hardware-based attestation. He addresses its fit in modern cloud infrastructure including Kubernetes, data loss prevention (DLP), API scanning and more.
The conversation addresses the initial major use cases for confidential computing. High risk environments including defense, banking, and healthcare are obvious. Not so obvious is securing multi-party data sets in the cloud for machine learning and AI-based applications.
So take a listen to this episode of Making Data Better and learn how hardware-based security can harden the cloud.
Inglise
Ameerika Ühendriigid
NÄITA MÄRKUSI 🔗
TRANSKRIBEERI 🔗
WEBVTT
00:00:22.317 --> 00:00:30.888
Welcome to Making Data Better, a podcast about data quality and the impact it has on how we protect, manage and use the digital data critical to our lives.
00:00:30.888 --> 00:00:38.112
I'm George Peabody, partner at Lockstep, and thanks for joining us With me is Lockstep Founders, steve Wilson.
00:00:38.112 --> 00:00:38.612
Hey, steve.
00:00:39.401 --> 00:00:39.942
Good day George.
00:00:39.963 --> 00:00:40.625
How are you going?
00:00:40.625 --> 00:00:43.823
Good to see you, Good to see you, Happy New Year.
00:00:43.823 --> 00:00:48.014
Here's to a great 2024 for all of us.
00:00:48.014 --> 00:01:01.509
So, Steve, today we're going to talk about an important technology that has much to offer for those concerned with security but, at least as far as I'm concerned, is not well understood or even known.
00:01:01.509 --> 00:01:03.881
It's called confidential computing.
00:01:03.881 --> 00:01:22.197
And while we're talking about this on our podcasts about making data better, because data is the basis on which we make decisions and we need systems that keep data from being altered without cause, without it giving us the ability to trace the change history of data.
00:01:22.325 --> 00:01:29.582
And, as you and I both talk about all the time, the enemy of security these days is, from our point of view, is plain text.
00:01:29.582 --> 00:01:31.266
We need better than that.
00:01:31.266 --> 00:01:38.766
We need device assisted support for providing data that well, you know where it comes from and how it's been handled.
00:01:38.766 --> 00:01:43.362
So here's this new notion confidential computing.
00:01:43.362 --> 00:01:49.585
We went to this trade group called the Confidential Computing Consortium and here's the definition they put.
00:01:49.585 --> 00:01:50.349
They posted.
00:01:50.349 --> 00:02:00.394
It says confidential computing protects data in use by performing computation in a hardware based, attested, trusted execution environment.
00:02:00.394 --> 00:02:02.063
We're going to get to all those terms.
00:02:02.063 --> 00:02:17.810
These secure and isolated environments prevent unauthorized access or modification of applications and data while in use, thereby increasing the security assurance for organizations that manage sensitive and regulated data.
00:02:17.810 --> 00:02:20.162
So you can see sort of the domain here.
00:02:20.162 --> 00:02:25.502
I know, Steve, you're going to like it because and I like it too because it's converging software and hardware.
00:02:25.502 --> 00:02:30.062
We think the two need to go together when we're talking about security Absolutely.
00:02:30.122 --> 00:02:32.031
I love confidential computing, george.
00:02:32.031 --> 00:02:34.159
It's an idea that his time has finally come.
00:02:34.159 --> 00:02:39.135
We've had a go as an industry at hardware based security for a long time.
00:02:39.135 --> 00:02:56.616
People listeners would be familiar, which try not to get too technical, but most people would be familiar with the idea of encryption and the concept that we need encryption over data when it's in storage, at rest, and we need encryption over data when it's moving, when it's in motion.
00:02:56.616 --> 00:03:02.936
Now confidential computing is about yet another idea of using encryption over data when it's in use.
00:03:02.936 --> 00:03:05.643
There's a number of ways of doing this.
00:03:05.643 --> 00:03:09.932
There's homomorphic encryption, there's multi-party secure computation.
00:03:10.820 --> 00:03:18.746
I think confidential computing is the best go that we've had at this so far and I'm really looking forward to diving into some of those details.
00:03:18.746 --> 00:03:30.102
I'm just going to flag our test station, the idea that somebody's got your back about the quality of the data, the quality of the stories, the quality of the algorithms and the quality of the computing environment that we're talking about.
00:03:30.102 --> 00:03:31.645
It's a bit wild west at the moment.
00:03:31.645 --> 00:03:36.365
There's all sorts of secure chips and enclaves and secure elements and God knows what.
00:03:36.365 --> 00:03:39.663
How do you know that any of this hardware is actually in a proper state?
00:03:39.663 --> 00:03:41.551
How do we know that it's fit for purpose.
00:03:41.551 --> 00:03:49.502
That's what we're going to get into today, and how does this property and how does these characteristics become available to the enterprise?
00:03:51.007 --> 00:03:52.611
To take us deeper into this topic.
00:03:52.611 --> 00:04:14.316
I'm delighted to welcome Mark Bauer, who is VP of Product at Confidential Computing Company, and Junna Mark join me on episode three of Making Data Better, where I asked him to set his way back machine to the aughts and his role in helping Heartland payments increase the security of its system after a card breach.
00:04:14.316 --> 00:04:21.221
Mark, I'm delighted to have you come back to Making Data Better and to talk about what you're actually doing today.
00:04:22.004 --> 00:04:22.144
Yeah.
00:04:22.144 --> 00:04:25.673
So, george and Steve, good to meet you again, and thank you for having me back.
00:04:25.673 --> 00:04:27.827
By the way, I'm happy to have you here to everyone too.
00:04:27.827 --> 00:04:30.879
So, yes, I think Steve's absolutely right.
00:04:30.879 --> 00:04:53.154
Confidential Computing is a relatively new technology, that the concepts have been around for some time, but here at Anjuna we're essentially we have the vision of anybody be it enterprises, software companies, saas providers should have access to this technology because of the bar raising capabilities that it has in reducing risk.
00:04:53.154 --> 00:05:09.680
And if you think about all of the breaches that we've had over the many years, they often start in memory or in software that is vulnerable, and being able to reduce those vulnerabilities really has to come down to taking it down to the hardware itself, which is what confidential computing is about.
00:05:12.504 --> 00:05:12.824
Wow.
00:05:12.824 --> 00:05:22.096
So before we get into all of that, mark, tell us a little bit about your backstory.
00:05:22.096 --> 00:05:26.107
How did you come to this role and interest?
00:05:26.947 --> 00:05:37.023
Yeah, so it actually goes back to the story that we told in the previous episode, where we think about the Heartland breach and how that was resolved and how it came about.
00:05:37.023 --> 00:06:14.245
It was ultimately systems that were vulnerable, attackers getting in, getting access to things that they should have zero access to at the end of the day, and exploitation of vulnerabilities that resulted in hundreds of millions of credit cards being exposed, and the company Heartland reacted in a really positive way to turn that from being a potential disaster to a change that the industry had to embrace, which was really introducing hardware to protect data as it's acquired from the card readers themselves, which were always quite secure but weren't used in the way to protect card data, and then keeping that data secure all the way to the backend systems.
00:06:14.245 --> 00:06:19.651
And so that was in the days of what we thought of was end-to-end security that card data.
00:06:20.454 --> 00:06:38.492
When you think about the problems we're dealing with now, when organizations are embracing machine learning, massive amounts of data, video feeds, live audio coming in you need a better way to handle not just the data but the code itself, and so I'd been watching this technology come about over the last few years.
00:06:38.492 --> 00:07:14.088
I'd had it on my product roadmaps in the past, and I'd spent time at Amazon in the hardware security group as well, and so when I saw the opportunity to jump into a vendor that was spearheading the development of this technology at a very early stage in the market, I jumped across, because it is a shift in the way compute will take place and I think within five years and it could be even sooner than that it'll almost become the default way we compute, whether we like it or not, because of the demands on security and the risks that we're dealing with and the regulations and the privacy requirements that people ultimately expect.
00:07:14.088 --> 00:07:18.547
So I think there's a lot of change coming as a result and I want to be part of that.
00:07:19.769 --> 00:07:20.149
Cool.
00:07:20.149 --> 00:07:33.461
So this is actually kind of hurting my head because I'm trying to square how we do business today, how somebody that the folks who've been breached in the past they just store data.
00:07:33.461 --> 00:07:39.473
There's no such thing as data they don't like.
00:07:41.319 --> 00:07:43.468
Right this is a data opportunity.
00:07:45.720 --> 00:07:49.730
Right and, as we know, the downside is it's also an opportunity for fraudsters.
00:07:49.730 --> 00:07:53.732
From a bridge to liability, it's an opportunity for fraudsters to steal it.
00:07:53.732 --> 00:07:57.764
Where does confidential computing come in?
00:07:57.764 --> 00:08:08.408
I mean, we think data minimization is a great idea, but I take it that you're applying confidential computing principles to the storage of all that data.
00:08:09.877 --> 00:08:11.202
It's when you think about it.
00:08:11.202 --> 00:08:21.238
We've had and Steve alluded to this, we've had data at rest protection for many years and almost today you wouldn't go into a cloud or even into your own data center without data at rest protection.
00:08:21.238 --> 00:08:24.002
For the most part, it's something that, if it's there, it should be turned on.
00:08:24.002 --> 00:08:26.863
In fact, we've abstracted it to the hardware for a lot of bases.
00:08:26.863 --> 00:08:28.339
Same with data emotion.
00:08:28.339 --> 00:08:36.225
Data emotion is about the integrity of the data, it's about the confidentiality of the data and it's about making sure you know who you're talking to and either end.
00:08:36.225 --> 00:08:42.607
But all too often all of those environments are still processing data in memory during use.
00:08:42.607 --> 00:08:58.447
So you read data from a database into memory to process it, and now that data is in the clear and it's remarkably easy, if you have the right level of privilege which you can gain from malware and from vulnerability software to be able to get access to that memory.
00:08:59.035 --> 00:09:04.861
And there have been many attacks as a result of that that have compromised systems because you can pull down things like threads.
00:09:04.861 --> 00:09:07.923
You can pull down the personal data straight out of memory.
00:09:07.923 --> 00:09:12.943
You don't have to attack systems or worse, we see an encryption keys being stolen out of memory.
00:09:12.943 --> 00:09:22.903
You know, maybe it's memory dump that then gets moved to another system and that key then gets extracted by an attacker in a lower trust environment and it's used to decrypt data.
00:09:22.903 --> 00:09:38.827
That's in a production environment, and so the data in use problem is very, very real and it's been very difficult to solve until you take it to a hardware based approach to what is essentially confidential computing.
00:09:40.515 --> 00:09:41.259
It's simplest.
00:09:41.259 --> 00:09:56.486
It's essentially taking the memory, encrypting it during use, restricting the processing to processes that themselves can decrypt that content.
00:09:56.486 --> 00:10:16.048
At the very core it's encrypting the registers, the caches, everything else, and so that you're shrinking the attack surface to only the computational thing, the CPU core itself, which also has some security properties, so that you're eliminating unauthorized access to memory.
00:10:16.048 --> 00:10:27.847
And if you can do that, then data that is protected at rest or transported out of that environment can also be protected from that in the most key, essentially the CPU environment itself.
00:10:27.847 --> 00:10:32.024
And so that's fundamentally what it is about in the highest level.
00:10:32.794 --> 00:10:37.883
So you're taking advantage of the hardware that's built into the CPU.
00:10:37.883 --> 00:10:41.548
The trusted the T, the trusted environment.
00:10:42.590 --> 00:10:43.535
Yeah, very much so.
00:10:43.796 --> 00:10:56.729
In most modern processors now, or in some of the hyperscalers that have their own proprietary versions of this, there's instructions that have been added to the processors to more or less isolate the processing.
00:10:56.934 --> 00:11:22.148
So either creating a virtual machine instance that is isolated from the rest of the processor, instrumenting a process itself which cannot be seen by any of the other cores there's no other even to the rest of the operating system almost or creating an isolated instance that is locked down, and so you have techniques like memory encryption, isolation, and then things like process isolation.
00:11:22.148 --> 00:12:03.370
Plus on top of that, as Steve mentioned attestation, which I'll get to but in essence it's new capabilities in the processors that give you what were typically kind of things that you do using, say, hardware security modules, very bespoke pieces of kit that you would rack and stack for things like payments, encryption and key management, but to do that for more general purpose computation, and so that gives you the elasticity you need, the scale that you need, as opposed to running in a very confined hardware box that was over here on the left but did one thing well and secured it well, but now you can run any application in this kind of environment with the right enabling software and so on.
00:12:03.894 --> 00:12:11.442
And are you able to virtualize the T, then Essentially, yeah.
00:12:12.375 --> 00:12:26.054
So there are hardware capabilities and there's mechanisms called hardware roots of trust and there's hardware modules in the processors that handle the encryption, offload, the encryption of memory.
00:12:26.196 --> 00:12:28.028
So, it's not done on the regular processor.
00:12:28.028 --> 00:12:30.922
It's all offloaded so it runs at full speed if you will.
00:12:30.922 --> 00:12:58.855
But the kind of the notion of having hardware roots of trust gives you this ability to always come back and prove that the software that you're running is in this trusted environment, and which gives you a different way to start to prove that you're running in an environment that you can at least establish there was an acceptable level of security before you started to use it, which is something that you just don't get with regular processors at all.
00:12:58.855 --> 00:13:00.100
You make an assumption of trust.
00:13:01.807 --> 00:13:04.436
So what's different now, mark?
00:13:04.436 --> 00:13:10.799
We throw some jargon around like trusted platform modules and secure elements and hardware security modules.
00:13:10.799 --> 00:13:12.407
I think most people have got a sense of this.
00:13:12.407 --> 00:13:21.359
Hardware security module is like a shoebox size piece of kit that runs in a computer rack and it costs $50,000 and it's a great idea.
00:13:21.359 --> 00:13:23.966
But unless you're a bank you can't afford it.
00:13:23.966 --> 00:13:29.923
We've had commoditized versions of this before.
00:13:29.923 --> 00:13:36.788
The trusted platform module was supposed to be a chip on the motherboard of every PC and in fact most PCs have got them, but they're not sort of turned on.
00:13:36.788 --> 00:13:38.591
What's happened?
00:13:38.591 --> 00:13:49.616
Leading question to make CCC accessible, confidential computing accessible, where we've had all these dead ends before?
00:13:50.985 --> 00:13:56.498
Yeah, so confidential computing itself has actually been around for more than five years.
00:13:56.498 --> 00:14:12.053
In fact started in probably almost a decade ago with the very early processors that tended to be look more like the hardware security module small memory for prints, limited capabilities, very complex to use, just like HSMs, in fact.
00:14:12.053 --> 00:14:14.761
These days, though, that's changed.
00:14:14.761 --> 00:14:18.037
When you think about the demands of modern work loads.
00:14:18.037 --> 00:14:27.250
So you're running an AI workload that needs to process billions of points in a model, a core banking system that you want to run in these kinds of environments.
00:14:27.250 --> 00:14:32.210
Then you need the same computation capability that you get with regular instances that you have in the cloud.
00:14:32.210 --> 00:14:38.952
So I need 200 processors, I need 10,000 processors, so the technology is scalable to that level number one.
00:14:38.952 --> 00:14:41.905
There's also been a kind of a.
00:14:41.905 --> 00:14:44.611
You know availability is huge.
00:14:44.611 --> 00:14:51.839
Now Nearly every AWS instance has what's called AWS Nitro on-claim, which is their term for confidential computing.
00:14:51.899 --> 00:15:01.551
It's extensions to run isolated work loads, and so this is much more than what Amazon and others have had like HSM, cloud HSMs for a long time.
00:15:01.551 --> 00:15:02.994
It's going beyond that, isn't it?
00:15:03.816 --> 00:15:14.316
Yes, you know, the HSMs are great for storing keys, signing transactions, like PKI, so I've got a document that I need to sign with a digital certificate in a high integrity environment.
00:15:14.316 --> 00:15:15.307
It's great for that.
00:15:15.307 --> 00:15:23.129
It's not great if you want to run core banking in one of those things, because they're just not designed for it and you'd have to re-architect the app and everything about it.
00:15:23.129 --> 00:15:25.038
Proprietary operating systems it's a mess.
00:15:25.038 --> 00:15:34.865
These days you want to run Kubernetes applications and to run them in an isolated environment so that insiders have no access, so your admins have no access to them.
00:15:34.904 --> 00:15:37.133
Re-archiving the special edges in script language.
00:15:37.845 --> 00:15:41.553
Exactly exactly, which is that's what our role here is around.
00:15:41.553 --> 00:15:50.250
Junior is making this very, very simple so that not only you're taking advantage of this environment because it's there and you can, which is just a good thing.
00:15:50.250 --> 00:15:52.895
Generally you know better security overall.
00:15:52.895 --> 00:15:59.357
But it starts to get into that problem of how do I trust something before I use it?
00:15:59.357 --> 00:16:05.267
And if you think about that, when you go to a cloud today and you get an instance, it's like getting a server.
00:16:05.267 --> 00:16:09.557
You assume that the BIOS is high integrity and has no backdoors.
00:16:09.557 --> 00:16:11.591
You assume that the hypervisor you're using is good.
00:16:11.591 --> 00:16:20.932
You assume that the operating system is good and you look at the certifications that says this organization went through PCI, hipaa, soc2, etc.
00:16:20.932 --> 00:16:24.317
Which is an assessment done by human at some point in time.
00:16:25.019 --> 00:16:38.187
But it doesn't give you a way to actually measure as improved mathematically that this is a piece of hardware that meets this level of security and has this level of firmware and BIOS and microcode.
00:16:38.187 --> 00:16:45.456
So I know it hasn't been tampered with and confidential computing lets you do those things.
00:16:45.456 --> 00:16:48.202
So you can ask the hardware.
00:16:48.202 --> 00:16:52.316
Tell me what state you are in and prove that.
00:16:52.316 --> 00:17:01.928
Tell me what software you're running and is it the same software that I built in my secure environment over here in the data center, so I know that it hasn't been tampered with.
00:17:01.928 --> 00:17:10.895
So think of SolarWinds, that attack where there was manipulation of compilers and libraries being inserted into the supply chain.
00:17:10.895 --> 00:17:21.247
You could prevent that kind of situation by showing that this code has been tampered with before I run it, and I can prove that, and the hardware can tell me.
00:17:21.247 --> 00:17:25.786
It's not the piece of software that could be manipulated, it's the processor itself that can prove that.
00:17:25.786 --> 00:17:27.611
That's a game changer.
00:17:27.611 --> 00:17:33.231
When it comes to Real things like zero trust, we not just rely on a one way.
00:17:34.141 --> 00:17:37.808
When remind the audience, the solar winds was the so-called software supply chain.
00:17:37.808 --> 00:17:39.772
It was almost like a black swan event.
00:17:39.772 --> 00:17:41.603
It shouldn't have been.
00:17:41.603 --> 00:17:45.673
I mean, we should have known all along that software is incredibly complicated.
00:17:45.673 --> 00:17:52.057
It's got its own life story, it's got its own supply chain and what happened with solar winds was that elements of that supply chain.
00:17:52.057 --> 00:17:53.180
The attackers were very smart.
00:17:53.180 --> 00:17:59.113
They found the software module sub providers, the subcontractors that were most vulnerable, and they attack those.
00:17:59.113 --> 00:18:09.509
So then the software modules come back into the mainstream, everything's recompiled, everything runs and you've got that Vulnerability lurking in the supply chain that has been exploited.
00:18:09.509 --> 00:18:16.026
Um, I, that is really why George and I so interested in Confidential computing.
00:18:16.026 --> 00:18:19.160
Foundationally, because it helps us tell the story behind the data.
00:18:19.160 --> 00:18:28.413
It helps us you know, code is data and it helps us improve that confidence in the, in the backstory of the code and the data that we're all depending on.
00:18:29.842 --> 00:18:50.304
Yeah, exactly, it's all about my are you taking some Um fingerprint of the data, I'm sorry, fingerprint of this, of the, of the compiled code on the, on the Development system, and then using that as to compare to the running code that's inside of your, your, your, your system?
00:18:50.986 --> 00:18:51.910
It's a little more than that.
00:18:51.910 --> 00:18:56.781
So, when you think about all of the, all of the things that you can measure, so what?
00:18:56.781 --> 00:18:58.808
What constitutes something that you're going to run?
00:18:58.808 --> 00:19:13.285
Well, you've got things like the, the bootloader, the firmware, you've got the microcode version in the processor, then you've got the actual code itself for the application, which may be, you know, containerized application, multiple things, and then you've also got the initial memory state.
00:19:13.285 --> 00:19:15.851
You expect that to start from.
00:19:15.851 --> 00:19:20.028
All of those things Constitute essentially what you expect to run.
00:19:20.641 --> 00:19:36.009
So, when you've gone through your build process and you typically you'll have good security practices around the build process Um, you've got to make sure that what you're building is actually what you've run and you don't have an unexpected hypervisor that's actually leaking data out to a third party.
00:19:36.861 --> 00:19:49.720
Um, that you don't have an operating system with a back door that you didn't expect to be there, or you are using something that's not in the build process, that has a vulnerability that somehow correct in, or malware.
00:19:49.921 --> 00:19:51.204
It's being injected somewhere.
00:19:51.204 --> 00:19:55.756
So, essentially, you're taking secure hatches of all of those components.
00:19:55.756 --> 00:20:13.251
You know you can choose which ones you want to do, depending on your sophistication and risk tolerance, but it's all about making measurements of things Computing hatches and then asking the hardware we compute those hashes for me and it will give you those measurements back and you can then look at those measurements and combine them to what you build.
00:20:13.251 --> 00:20:41.099
And the the upside of this too is that the measurements on that software and the fact that the hardware has digitally signed this with the key that's essentially Embedded in at manufacture time into the secure processor, it can sign that, so this then becomes Evidence of what you're running and that evidence can also be then used as identity Like a machine identity to then do things like pull a secret into that application.
00:20:41.099 --> 00:20:54.907
And so the old way of having to give a cred to an app After you start it and then hope that it's in a secure environment and hope that that cred doesn't get stolen by an insider that can be eliminated, that kind of threat.
00:20:55.601 --> 00:20:56.826
And that means credential.
00:20:57.940 --> 00:20:59.306
Everything's got a credential in these days.
00:21:00.402 --> 00:21:01.907
Yeah, yeah, thank you.
00:21:02.859 --> 00:21:17.368
Yeah, so the power of attestation comes down to proving trust in something that you're running and then also using that information to bind the identity to other things, like a key management system, so you can then pull in secrets or pulling configurations.
00:21:17.368 --> 00:21:31.090
If you can do all of that automatically, then confidential computing becomes Very, very seamless and you can instrument it into your dev processes, as opposed to building encryption tools or having to turn things on at the application level.
00:21:31.090 --> 00:21:33.406
That is the way we were doing it today.
00:21:34.540 --> 00:21:36.419
Nice to trust, but it's better to verify.
00:21:37.772 --> 00:21:38.840
I Hold that.
00:21:38.840 --> 00:21:40.104
It's trust but verify.
00:21:40.104 --> 00:21:50.160
But the question is well, how do you really verify if you can't verify the thing that's verifying, which is software for the most part, and so abstract that to the hardware and you do have to still trust the hardware?
00:21:50.160 --> 00:21:53.717
Yes, but we trust AMD, we trust intel, we trust arm.
00:21:53.717 --> 00:22:00.279
You know, we trust the manufacturers and they have very, very strong processes over this and the trust mechanisms in that process.
00:22:02.229 --> 00:22:04.440
Mark, what's the process of deploying this?
00:22:04.440 --> 00:22:04.480
I?
00:22:04.480 --> 00:22:11.676
It sounds complex, complex and it sounds that I mean.
00:22:11.676 --> 00:22:19.971
My experience is that when encryption gets involved, there's overhead and and, and, and I'm just even from a processor.
00:22:19.971 --> 00:22:21.317
Overhead, you know, there's a performance hit.
00:22:21.317 --> 00:22:26.500
For those of us who think about CPU performance, yeah, how do you, how do you sell around that you?
00:22:26.500 --> 00:22:27.844
How do you sell around that?
00:22:28.906 --> 00:22:56.792
Well, the thing is you don't have to, because the modern processors if I look at, say, an AMD sev processor and Intel TDX these are the very you know current processors and TDX is also fairly new the, the benchmarks of these show that the performance impact of the full confidential computing capabilities is somewhere to the order of, you know, 5% on average, even under the serious load, which is a very acceptable number when you're getting this amount of value from encrypting data in use.
00:22:57.500 --> 00:23:35.672
So you know, and the question that you asked is exactly the right one, traditionally software based encryption mechanisms always added a fair chunk of the processor to dedicate to the processing of data and encrypting it, whereas this is offloaded into hardware accelerators, on the, on the processors, for the memory and then also for things like IO and disk encryption and so on, and so you can get some very high performance and you have the elasticity, and so you can scale horizontally and, you know, set your limits on Kubernetes, run them in a confidential pod and you're away and you don't have to worry so much about that performance and you don't have to worry so much.
00:23:37.720 --> 00:23:41.431
So, steve, I know you've got I suspect you have more more technical questions.
00:23:41.431 --> 00:23:44.128
I want to know how heck you get this into the marketplace.
00:23:44.128 --> 00:23:45.503
You know what.
00:23:45.503 --> 00:23:47.109
Who is buying this?
00:23:47.109 --> 00:23:50.568
Um, what are the objections you run into mark?
00:23:50.568 --> 00:23:53.848
How do you, how do you, knock those objections down?
00:23:54.700 --> 00:23:55.843
Yeah, good question.
00:23:55.843 --> 00:23:59.271
So number one is always I haven't heard of this technology before.
00:23:59.271 --> 00:24:07.819
This sounds too good to be true and it is a very powerful technology, and so this definitely education that's needed, which is why we're doing this podcast.
00:24:07.819 --> 00:24:13.592
Why is we spend a lot of time with customers in workshops and things like that, to education on on the technology?
00:24:13.592 --> 00:24:17.448
Um, so that that'd be the first one, I think, when you think about you know.
00:24:17.468 --> 00:24:19.873
Coming back to your last question about well, how do you get this seen?
00:24:19.873 --> 00:24:26.250
Um, traditionally, confidential computing was quite an onerous task for organizations.
00:24:26.250 --> 00:24:28.295
They had to build applications to it.
00:24:28.295 --> 00:24:31.740
Um, that's no longer the case, especially with what we're doing.
00:24:31.740 --> 00:24:41.323
It's a matter of essentially taking applications and processes and putting them into a confidential computing environment, and you can do that in in very short order.
00:24:41.323 --> 00:24:52.655
You know, if you think about the old way of protecting data was the best practice was typically encrypted, the application tier, so we'd use a toolkit and we'd have key management and we'd have to think about the data flows and so on.
00:24:52.655 --> 00:25:12.174
That was, you know, weeks to months of effort, typically per application in a typical enterprise Confidential computing, including the ability to not only protect data in use but enforce data at rest and in motion can be instrumented into a CI CD, and so then it becomes a question of well, how are you building software?
00:25:12.685 --> 00:25:13.549
We are CI CD.
00:25:14.726 --> 00:25:15.407
Sorry, good point.
00:25:15.407 --> 00:25:27.650
So it's into the development pipeline process so you can actually turn on confidential computing when you need to use it, as opposed to code it in, which is how you used to build it into.
00:25:27.650 --> 00:25:31.165
You know you used to build application security with SDKs, like you know.
00:25:31.165 --> 00:25:34.434
Rsa, be Safe is the classic one, and there's loads of vendors that do this sort of stuff.
00:25:34.434 --> 00:25:39.576
With confidential computing, it doesn't have to be built into the app.
00:25:39.576 --> 00:25:50.230
It can be instrumented by operations and turn it on so that the instance becomes confidential and the application then runs confidentially, at least the way we implement it.
00:25:50.230 --> 00:25:50.811
So it's easy.
00:25:53.549 --> 00:26:03.457
So I'm imagining that a confidential computing element like a T, a trusted execution environment, is essentially a hardened processor, a computing environment.
00:26:03.457 --> 00:26:14.518
I'm imagining that you're talking about taking enterprise software in its current state and, in a sense, recompiling it or running it in a virtual machine inside the TEE.
00:26:15.653 --> 00:26:16.744
Yeah, it's more like the latter.
00:26:16.744 --> 00:26:21.744
So the confidential computing environment is going to be regular processors.
00:26:21.744 --> 00:26:27.744
It's not like a special purpose processor, like TPM was a dedicated special process of the managed keys.
00:26:27.744 --> 00:26:36.352
So you can have, you know, you can get an Intel Xeon with TDX or SGX extensions, you can have AWS, nitro enclaves.
00:26:36.352 --> 00:26:40.057
These are all the kind of the brands, if you will, of confidential computing.
00:26:41.666 --> 00:26:53.744
In essence, the way we look at it is that you should be able to take your applications, run them in confidential computing without change, without re-architecting, not even a line of code change or even recompiling.
00:26:53.744 --> 00:27:02.930
It's taking the binary and running it virtualized so that you can run in a confidential computing environment, a run-time environment.
00:27:02.930 --> 00:27:08.113
Essentially an operating system gives you, gives the application, what it needs to run.
00:27:08.113 --> 00:27:12.760
So if there was the confidential computing environment was missing networking and storage.
00:27:12.760 --> 00:27:17.744
We filled in that gap, so it just appears like a regular application environment.
00:27:18.288 --> 00:27:20.704
And then think about, say, starting a web server, right?
00:27:20.704 --> 00:27:27.909
So one of the things a web server needs is the TLS key so it can decrypt traffic coming in from the browser Simple key.
00:27:27.909 --> 00:27:32.744
That's a very important key because if that's exposed all sorts of compromise can happen.
00:27:32.744 --> 00:27:40.744
So if you can securely inject that into the enclave as it starts, so that it just looks like a file that it would normally pick up.
00:27:40.744 --> 00:27:59.211
Then it can just run just as it would on a regular environment, and so confidential computing has to be about the simplicity of the application and then also simplicity for the processes around it managing configurations, keys, orchestrating, integrating into Kubernetes so that it's just seamless.
00:27:59.211 --> 00:28:01.442
So that is how this works.
00:28:01.442 --> 00:28:12.704
It is almost a kind of a virtualized way of looking at the world, and an application that was formerly insecure can now be run securely without changing it.
00:28:12.704 --> 00:28:20.577
That's how you get to do this in the development to operations process, as opposed to in the decoding process.
00:28:21.138 --> 00:28:21.398
Got it.
00:28:22.486 --> 00:28:40.957
So that strikes me that part of your value proposition is you're eliminating the need for, I guess, deep dive security audits of all the source code to employ every protection technique, that secure technique that you might.
00:28:40.957 --> 00:28:54.756
Now you can just take that code that you've been running with you knew you had some technical debt associated with it move it into your environment and you can, because of that connection back to the hardware, you can adjust it.
00:28:57.066 --> 00:29:01.394
You can certainly raise the bar on security for existing applications like that.
00:29:02.987 --> 00:29:05.744
You have to be mindful and realistic also about expectations.
00:29:06.306 --> 00:29:21.531
So, for example, if you have a database that you want to run in confidential computing, you absolutely can and should, so that the operations on the database are not visible to insiders and they can't memory dump and encryption of data at rest is protected inside the walled garden of the enclave of the secure execution environment.
00:29:21.531 --> 00:29:30.596
But if you have a SQL interface that is vulnerable and you can query it, you'll still have a vulnerable interface and so you have to be mindful of how you use it and the expectations around it.
00:29:30.596 --> 00:29:45.744
It's definitely a very powerful technology, but you might want to also think about the overall threat model to what you're instrumenting into the cloud or your data center and think about what mitigations you can reduce.
00:29:45.744 --> 00:30:11.217
But we've done analysis against the mitre attack matrix, which is basically the typical threats that people have to deal with in running applications, and there's at least 77 mitre attacks, as in vulnerabilities that are immediately eliminated by running it in hardware, which is a pretty big chunk of high risk that's reduced just out of the gate without doing anything.
00:30:13.788 --> 00:30:14.270
So what do you use?
00:30:14.270 --> 00:30:17.222
Cases that you're seeing the most accident in People that are coming to you?
00:30:17.222 --> 00:30:21.355
Yeah, great question Is it beyond regulated and sensitive data?
00:30:23.012 --> 00:30:26.971
Yeah, it's some really interesting stuff that we're seeing and it's probably like three categories.
00:30:26.971 --> 00:30:31.314
I'd say One is the regulated industries, the obvious suspects.
00:30:31.314 --> 00:30:33.066
You know the defense agencies, as you do.
00:30:33.066 --> 00:30:46.653
Others often started banking, healthcare as being the next obvious ones, and it's just unblocking things like cloud migration, where you know the irony of confidential computing is it's widely available in the cloud but it isolates you from the CSP.
00:30:46.653 --> 00:30:50.576
So if you don't trust the cloud, you can now control what you're putting into it.
00:30:50.576 --> 00:30:55.396
So it gives you hardware controls that you might have had in the data center that weren't there before.
00:30:55.396 --> 00:30:57.432
So now you can move things to the cloud.
00:30:57.432 --> 00:30:59.511
So banking, you know healthcare.
00:31:00.145 --> 00:31:14.531
But I think the two interesting categories we're seeing are especially machine learning and AI where, if you think about AI, you're often dealing with multiple entities of data, so people that don't often trust each other.
00:31:14.531 --> 00:31:32.453
So in a bank, you might have two lines of business that could, you know, merge data together, but the merger of that data could be very high risk from a breach risk perspective, like high net worth data above and beyond, you know, typically regulated, it's the crown jewels of most banks.
00:31:32.453 --> 00:31:41.933
Yet being able to analyze that with machine learning might give you something that's brand new, and you want to make sure that you have integrity over the execution of the model itself.
00:31:42.744 --> 00:31:45.744
So you want to make sure that you have integrity over the dilemma, exactly.
00:31:45.744 --> 00:31:58.590
And so now you can start to shrink the attack surface of execution of the AI model and create environments where you can have multiple parties come together into what is a trusted ecosystem that can't leak and you can control what comes out of that.
00:31:58.590 --> 00:32:01.049
So let's get the results out.
00:32:01.049 --> 00:32:09.338
So let's target this individual with these products much more granularly than I could with just anonymized data.
00:32:09.338 --> 00:32:18.172
Or, you know, minimize data AI and AI as a service inside organizations who just want to explore it and has a popularity and excitement, and so on.
00:32:18.172 --> 00:32:19.434
That's a really big one.
00:32:19.434 --> 00:32:31.307
And then the one that's really cropped up is third parties that for years have been dealing with security and they've got visibility into data that is very high value.
00:32:31.307 --> 00:32:36.461
So imagine all of those DLP vendors, you know, the ones that have the perimeters that used to inspect the data coming in and out.
00:32:37.455 --> 00:32:37.675
DLP.
00:32:37.675 --> 00:32:41.260
These are the data loss prevention yeah, data loss prevention.
00:32:41.555 --> 00:32:50.824
Or there's companies that do things like API scanning to see what the behavior looks like, with applications to detect risks based on the behavior of users and systems.
00:32:50.824 --> 00:32:54.023
Those have privilege over what's coming in and out.
00:32:54.023 --> 00:33:16.141
They also have the API tokens, so being able to secure that and lock that down closes a gap on what is actually security infrastructure itself, and that's helping those organizations move more of their customers to the cloud who have concerns over that level of access and visibility into the client on infrastructure that they don't own.
00:33:16.141 --> 00:33:30.781
So there's some really interesting scenarios that span everything from banks to healthcare to highly regulated industries and then brand new businesses forming on the back of this technology as well, like the multi-party computation.
00:33:30.781 --> 00:33:31.684
That's practical.
00:33:37.335 --> 00:33:39.342
Well, mark, I think we're gonna leave it there.
00:33:39.342 --> 00:33:44.542
This has been really super interesting, unless there's something else you'd like to address.
00:33:45.575 --> 00:34:00.880
No, well, I think I come back to the fact that you know, irrespective of whether you're thinking about cloud or computation in the data center, over the next few years the confidential computing is gonna be on people's radars and it's gonna end up on their roadmaps, whether they like it or not.
00:34:01.134 --> 00:34:08.925
You know the stakes are too high, especially as we get into higher levels of data that need to be processed by machine learning and AI.
00:34:08.925 --> 00:34:10.059
We're gonna hear about trusted AI.
00:34:10.059 --> 00:34:19.005
We're gonna hear more and more about trust I know that Steve's been talking about this for years and all of these things come together with trust.
00:34:19.005 --> 00:34:27.563
That has to come back to hardware at somewhere and then from there everything else can be trusted on top, and without that it's a house of cards.
00:34:27.563 --> 00:34:35.623
So this is absolutely in people's futures and I think what it'll mean is that security resolves to being about denial of service and the human error.
00:34:35.623 --> 00:34:46.101
If we can close down a lockdown computation in this way, which is a very profound, forward-looking statement, but I think in five years we'll look back and think you know what that might've been the right thing to do.
00:34:47.556 --> 00:34:51.561
And then I think we'll take the confidential off the front of this and just make it all computing.
00:34:52.436 --> 00:34:54.001
I think that is 100% correct.
00:34:55.014 --> 00:35:04.445
It's understandable that we triage at this time because things are expensive for this, and we triage sensitive and regulated data to be the first use cases for confidential computing.
00:35:04.445 --> 00:35:26.364
But you know, as computing gets commoditized, I mean I'm sitting here in a room with a, for all I know, a software-controlled LED light bulb with a couple of thousand lines of code, and there's millions of these things around the world and they're all points of attack and that idea of attestation and hardware roots of trust, even in light bulbs and vacuum cleaners and automobiles.
00:35:26.364 --> 00:35:38.744
This stuff needs to be spread far and wide and it's great to see this, the practicality of the deployment that you talk about, that the existing compute and the existing work flows can be picked up and moved into a secure environment.
00:35:38.744 --> 00:35:41.639
It's gotta be the way to go, yeah absolutely.
00:35:42.054 --> 00:36:00.347
I agree, so I may just stop right there, but I'm gonna say here myself that, while tremendously powerful, I'm also struck by the need for existing approaches.
00:36:00.347 --> 00:36:18.539
With Mark, you were talking about how do you protect an SQL interface and the database that where that data that's normally stored in plain text and you still have the techniques of good security hygiene that have to apply to those.
00:36:18.539 --> 00:36:29.523
Similarly, you were talking about AI data so much the data that LLM has been trained on it's bullshit.
00:36:31.795 --> 00:36:33.228
You have to think about integrity.
00:36:33.855 --> 00:36:43.514
So integrity, the regulatory discussions around bias that's built into the data sets, confidential computing, can't do anything about that.
00:36:43.514 --> 00:36:48.891
There's still a tremendous amount of work that needs to be done around the data itself, oh sure.
00:36:48.931 --> 00:36:49.855
Yeah, yeah, absolutely.
00:36:49.855 --> 00:36:55.054
I mean, you can make sure that it's coming from somewhere you trust, but you have to make sure that the data is also reasonable as well.
00:36:56.202 --> 00:37:00.030
And that's what's so powerful about what you're talking about.
00:37:00.030 --> 00:37:13.376
Yeah, exactly, To be able to prove that you have a trusted device is manipulating your bits and bytes, Exactly.
00:37:13.376 --> 00:37:15.119
Oh, Mark, thank you very much.
00:37:15.119 --> 00:37:18.724
We'll look forward to getting you back sometime.
00:37:18.724 --> 00:37:22.025
Hear about your progress and reach out to us.
00:37:22.025 --> 00:37:23.661
Let us know when something hot happens.
00:37:23.661 --> 00:37:24.719
We'd love to have you back.
00:37:24.875 --> 00:37:25.960
Absolutely anytime.
00:37:25.960 --> 00:37:27.438
All right, good to see you again, guys.
00:37:27.818 --> 00:37:28.681
Thanks, mark, so good.
00:37:28.681 --> 00:37:29.342
Thanks everyone, cheers.
00:37:29.342 --> 00:37:40.934
We'll see you next time.
00:00:22.317 --> 00:00:30.888
Welcome to Making Data Better, a podcast about data quality and the impact it has on how we protect, manage and use the digital data critical to our lives.
00:00:30.888 --> 00:00:38.112
I'm George Peabody, partner at Lockstep, and thanks for joining us With me is Lockstep Founders, steve Wilson.
00:00:38.112 --> 00:00:38.612
Hey, steve.
00:00:39.401 --> 00:00:39.942
Good day George.
00:00:39.963 --> 00:00:40.625
How are you going?
00:00:40.625 --> 00:00:43.823
Good to see you, Good to see you, Happy New Year.
00:00:43.823 --> 00:00:48.014
Here's to a great 2024 for all of us.
00:00:48.014 --> 00:01:01.509
So, Steve, today we're going to talk about an important technology that has much to offer for those concerned with security but, at least as far as I'm concerned, is not well understood or even known.
00:01:01.509 --> 00:01:03.881
It's called confidential computing.
00:01:03.881 --> 00:01:22.197
And while we're talking about this on our podcasts about making data better, because data is the basis on which we make decisions and we need systems that keep data from being altered without cause, without it giving us the ability to trace the change history of data.
00:01:22.325 --> 00:01:29.582
And, as you and I both talk about all the time, the enemy of security these days is, from our point of view, is plain text.
00:01:29.582 --> 00:01:31.266
We need better than that.
00:01:31.266 --> 00:01:38.766
We need device assisted support for providing data that well, you know where it comes from and how it's been handled.
00:01:38.766 --> 00:01:43.362
So here's this new notion confidential computing.
00:01:43.362 --> 00:01:49.585
We went to this trade group called the Confidential Computing Consortium and here's the definition they put.
00:01:49.585 --> 00:01:50.349
They posted.
00:01:50.349 --> 00:02:00.394
It says confidential computing protects data in use by performing computation in a hardware based, attested, trusted execution environment.
00:02:00.394 --> 00:02:02.063
We're going to get to all those terms.
00:02:02.063 --> 00:02:17.810
These secure and isolated environments prevent unauthorized access or modification of applications and data while in use, thereby increasing the security assurance for organizations that manage sensitive and regulated data.
00:02:17.810 --> 00:02:20.162
So you can see sort of the domain here.
00:02:20.162 --> 00:02:25.502
I know, Steve, you're going to like it because and I like it too because it's converging software and hardware.
00:02:25.502 --> 00:02:30.062
We think the two need to go together when we're talking about security Absolutely.
00:02:30.122 --> 00:02:32.031
I love confidential computing, george.
00:02:32.031 --> 00:02:34.159
It's an idea that his time has finally come.
00:02:34.159 --> 00:02:39.135
We've had a go as an industry at hardware based security for a long time.
00:02:39.135 --> 00:02:56.616
People listeners would be familiar, which try not to get too technical, but most people would be familiar with the idea of encryption and the concept that we need encryption over data when it's in storage, at rest, and we need encryption over data when it's moving, when it's in motion.
00:02:56.616 --> 00:03:02.936
Now confidential computing is about yet another idea of using encryption over data when it's in use.
00:03:02.936 --> 00:03:05.643
There's a number of ways of doing this.
00:03:05.643 --> 00:03:09.932
There's homomorphic encryption, there's multi-party secure computation.
00:03:10.820 --> 00:03:18.746
I think confidential computing is the best go that we've had at this so far and I'm really looking forward to diving into some of those details.
00:03:18.746 --> 00:03:30.102
I'm just going to flag our test station, the idea that somebody's got your back about the quality of the data, the quality of the stories, the quality of the algorithms and the quality of the computing environment that we're talking about.
00:03:30.102 --> 00:03:31.645
It's a bit wild west at the moment.
00:03:31.645 --> 00:03:36.365
There's all sorts of secure chips and enclaves and secure elements and God knows what.
00:03:36.365 --> 00:03:39.663
How do you know that any of this hardware is actually in a proper state?
00:03:39.663 --> 00:03:41.551
How do we know that it's fit for purpose.
00:03:41.551 --> 00:03:49.502
That's what we're going to get into today, and how does this property and how does these characteristics become available to the enterprise?
00:03:51.007 --> 00:03:52.611
To take us deeper into this topic.
00:03:52.611 --> 00:04:14.316
I'm delighted to welcome Mark Bauer, who is VP of Product at Confidential Computing Company, and Junna Mark join me on episode three of Making Data Better, where I asked him to set his way back machine to the aughts and his role in helping Heartland payments increase the security of its system after a card breach.
00:04:14.316 --> 00:04:21.221
Mark, I'm delighted to have you come back to Making Data Better and to talk about what you're actually doing today.
00:04:22.004 --> 00:04:22.144
Yeah.
00:04:22.144 --> 00:04:25.673
So, george and Steve, good to meet you again, and thank you for having me back.
00:04:25.673 --> 00:04:27.827
By the way, I'm happy to have you here to everyone too.
00:04:27.827 --> 00:04:30.879
So, yes, I think Steve's absolutely right.
00:04:30.879 --> 00:04:53.154
Confidential Computing is a relatively new technology, that the concepts have been around for some time, but here at Anjuna we're essentially we have the vision of anybody be it enterprises, software companies, saas providers should have access to this technology because of the bar raising capabilities that it has in reducing risk.
00:04:53.154 --> 00:05:09.680
And if you think about all of the breaches that we've had over the many years, they often start in memory or in software that is vulnerable, and being able to reduce those vulnerabilities really has to come down to taking it down to the hardware itself, which is what confidential computing is about.
00:05:12.504 --> 00:05:12.824
Wow.
00:05:12.824 --> 00:05:22.096
So before we get into all of that, mark, tell us a little bit about your backstory.
00:05:22.096 --> 00:05:26.107
How did you come to this role and interest?
00:05:26.947 --> 00:05:37.023
Yeah, so it actually goes back to the story that we told in the previous episode, where we think about the Heartland breach and how that was resolved and how it came about.
00:05:37.023 --> 00:06:14.245
It was ultimately systems that were vulnerable, attackers getting in, getting access to things that they should have zero access to at the end of the day, and exploitation of vulnerabilities that resulted in hundreds of millions of credit cards being exposed, and the company Heartland reacted in a really positive way to turn that from being a potential disaster to a change that the industry had to embrace, which was really introducing hardware to protect data as it's acquired from the card readers themselves, which were always quite secure but weren't used in the way to protect card data, and then keeping that data secure all the way to the backend systems.
00:06:14.245 --> 00:06:19.651
And so that was in the days of what we thought of was end-to-end security that card data.
00:06:20.454 --> 00:06:38.492
When you think about the problems we're dealing with now, when organizations are embracing machine learning, massive amounts of data, video feeds, live audio coming in you need a better way to handle not just the data but the code itself, and so I'd been watching this technology come about over the last few years.
00:06:38.492 --> 00:07:14.088
I'd had it on my product roadmaps in the past, and I'd spent time at Amazon in the hardware security group as well, and so when I saw the opportunity to jump into a vendor that was spearheading the development of this technology at a very early stage in the market, I jumped across, because it is a shift in the way compute will take place and I think within five years and it could be even sooner than that it'll almost become the default way we compute, whether we like it or not, because of the demands on security and the risks that we're dealing with and the regulations and the privacy requirements that people ultimately expect.
00:07:14.088 --> 00:07:18.547
So I think there's a lot of change coming as a result and I want to be part of that.
00:07:19.769 --> 00:07:20.149
Cool.
00:07:20.149 --> 00:07:33.461
So this is actually kind of hurting my head because I'm trying to square how we do business today, how somebody that the folks who've been breached in the past they just store data.
00:07:33.461 --> 00:07:39.473
There's no such thing as data they don't like.
00:07:41.319 --> 00:07:43.468
Right this is a data opportunity.
00:07:45.720 --> 00:07:49.730
Right and, as we know, the downside is it's also an opportunity for fraudsters.
00:07:49.730 --> 00:07:53.732
From a bridge to liability, it's an opportunity for fraudsters to steal it.
00:07:53.732 --> 00:07:57.764
Where does confidential computing come in?
00:07:57.764 --> 00:08:08.408
I mean, we think data minimization is a great idea, but I take it that you're applying confidential computing principles to the storage of all that data.
00:08:09.877 --> 00:08:11.202
It's when you think about it.
00:08:11.202 --> 00:08:21.238
We've had and Steve alluded to this, we've had data at rest protection for many years and almost today you wouldn't go into a cloud or even into your own data center without data at rest protection.
00:08:21.238 --> 00:08:24.002
For the most part, it's something that, if it's there, it should be turned on.
00:08:24.002 --> 00:08:26.863
In fact, we've abstracted it to the hardware for a lot of bases.
00:08:26.863 --> 00:08:28.339
Same with data emotion.
00:08:28.339 --> 00:08:36.225
Data emotion is about the integrity of the data, it's about the confidentiality of the data and it's about making sure you know who you're talking to and either end.
00:08:36.225 --> 00:08:42.607
But all too often all of those environments are still processing data in memory during use.
00:08:42.607 --> 00:08:58.447
So you read data from a database into memory to process it, and now that data is in the clear and it's remarkably easy, if you have the right level of privilege which you can gain from malware and from vulnerability software to be able to get access to that memory.
00:08:59.035 --> 00:09:04.861
And there have been many attacks as a result of that that have compromised systems because you can pull down things like threads.
00:09:04.861 --> 00:09:07.923
You can pull down the personal data straight out of memory.
00:09:07.923 --> 00:09:12.943
You don't have to attack systems or worse, we see an encryption keys being stolen out of memory.
00:09:12.943 --> 00:09:22.903
You know, maybe it's memory dump that then gets moved to another system and that key then gets extracted by an attacker in a lower trust environment and it's used to decrypt data.
00:09:22.903 --> 00:09:38.827
That's in a production environment, and so the data in use problem is very, very real and it's been very difficult to solve until you take it to a hardware based approach to what is essentially confidential computing.
00:09:40.515 --> 00:09:41.259
It's simplest.
00:09:41.259 --> 00:09:56.486
It's essentially taking the memory, encrypting it during use, restricting the processing to processes that themselves can decrypt that content.
00:09:56.486 --> 00:10:16.048
At the very core it's encrypting the registers, the caches, everything else, and so that you're shrinking the attack surface to only the computational thing, the CPU core itself, which also has some security properties, so that you're eliminating unauthorized access to memory.
00:10:16.048 --> 00:10:27.847
And if you can do that, then data that is protected at rest or transported out of that environment can also be protected from that in the most key, essentially the CPU environment itself.
00:10:27.847 --> 00:10:32.024
And so that's fundamentally what it is about in the highest level.
00:10:32.794 --> 00:10:37.883
So you're taking advantage of the hardware that's built into the CPU.
00:10:37.883 --> 00:10:41.548
The trusted the T, the trusted environment.
00:10:42.590 --> 00:10:43.535
Yeah, very much so.
00:10:43.796 --> 00:10:56.729
In most modern processors now, or in some of the hyperscalers that have their own proprietary versions of this, there's instructions that have been added to the processors to more or less isolate the processing.
00:10:56.934 --> 00:11:22.148
So either creating a virtual machine instance that is isolated from the rest of the processor, instrumenting a process itself which cannot be seen by any of the other cores there's no other even to the rest of the operating system almost or creating an isolated instance that is locked down, and so you have techniques like memory encryption, isolation, and then things like process isolation.
00:11:22.148 --> 00:12:03.370
Plus on top of that, as Steve mentioned attestation, which I'll get to but in essence it's new capabilities in the processors that give you what were typically kind of things that you do using, say, hardware security modules, very bespoke pieces of kit that you would rack and stack for things like payments, encryption and key management, but to do that for more general purpose computation, and so that gives you the elasticity you need, the scale that you need, as opposed to running in a very confined hardware box that was over here on the left but did one thing well and secured it well, but now you can run any application in this kind of environment with the right enabling software and so on.
00:12:03.894 --> 00:12:11.442
And are you able to virtualize the T, then Essentially, yeah.
00:12:12.375 --> 00:12:26.054
So there are hardware capabilities and there's mechanisms called hardware roots of trust and there's hardware modules in the processors that handle the encryption, offload, the encryption of memory.
00:12:26.196 --> 00:12:28.028
So, it's not done on the regular processor.
00:12:28.028 --> 00:12:30.922
It's all offloaded so it runs at full speed if you will.
00:12:30.922 --> 00:12:58.855
But the kind of the notion of having hardware roots of trust gives you this ability to always come back and prove that the software that you're running is in this trusted environment, and which gives you a different way to start to prove that you're running in an environment that you can at least establish there was an acceptable level of security before you started to use it, which is something that you just don't get with regular processors at all.
00:12:58.855 --> 00:13:00.100
You make an assumption of trust.
00:13:01.807 --> 00:13:04.436
So what's different now, mark?
00:13:04.436 --> 00:13:10.799
We throw some jargon around like trusted platform modules and secure elements and hardware security modules.
00:13:10.799 --> 00:13:12.407
I think most people have got a sense of this.
00:13:12.407 --> 00:13:21.359
Hardware security module is like a shoebox size piece of kit that runs in a computer rack and it costs $50,000 and it's a great idea.
00:13:21.359 --> 00:13:23.966
But unless you're a bank you can't afford it.
00:13:23.966 --> 00:13:29.923
We've had commoditized versions of this before.
00:13:29.923 --> 00:13:36.788
The trusted platform module was supposed to be a chip on the motherboard of every PC and in fact most PCs have got them, but they're not sort of turned on.
00:13:36.788 --> 00:13:38.591
What's happened?
00:13:38.591 --> 00:13:49.616
Leading question to make CCC accessible, confidential computing accessible, where we've had all these dead ends before?
00:13:50.985 --> 00:13:56.498
Yeah, so confidential computing itself has actually been around for more than five years.
00:13:56.498 --> 00:14:12.053
In fact started in probably almost a decade ago with the very early processors that tended to be look more like the hardware security module small memory for prints, limited capabilities, very complex to use, just like HSMs, in fact.
00:14:12.053 --> 00:14:14.761
These days, though, that's changed.
00:14:14.761 --> 00:14:18.037
When you think about the demands of modern work loads.
00:14:18.037 --> 00:14:27.250
So you're running an AI workload that needs to process billions of points in a model, a core banking system that you want to run in these kinds of environments.
00:14:27.250 --> 00:14:32.210
Then you need the same computation capability that you get with regular instances that you have in the cloud.
00:14:32.210 --> 00:14:38.952
So I need 200 processors, I need 10,000 processors, so the technology is scalable to that level number one.
00:14:38.952 --> 00:14:41.905
There's also been a kind of a.
00:14:41.905 --> 00:14:44.611
You know availability is huge.
00:14:44.611 --> 00:14:51.839
Now Nearly every AWS instance has what's called AWS Nitro on-claim, which is their term for confidential computing.
00:14:51.899 --> 00:15:01.551
It's extensions to run isolated work loads, and so this is much more than what Amazon and others have had like HSM, cloud HSMs for a long time.
00:15:01.551 --> 00:15:02.994
It's going beyond that, isn't it?
00:15:03.816 --> 00:15:14.316
Yes, you know, the HSMs are great for storing keys, signing transactions, like PKI, so I've got a document that I need to sign with a digital certificate in a high integrity environment.
00:15:14.316 --> 00:15:15.307
It's great for that.
00:15:15.307 --> 00:15:23.129
It's not great if you want to run core banking in one of those things, because they're just not designed for it and you'd have to re-architect the app and everything about it.
00:15:23.129 --> 00:15:25.038
Proprietary operating systems it's a mess.
00:15:25.038 --> 00:15:34.865
These days you want to run Kubernetes applications and to run them in an isolated environment so that insiders have no access, so your admins have no access to them.
00:15:34.904 --> 00:15:37.133
Re-archiving the special edges in script language.
00:15:37.845 --> 00:15:41.553
Exactly exactly, which is that's what our role here is around.
00:15:41.553 --> 00:15:50.250
Junior is making this very, very simple so that not only you're taking advantage of this environment because it's there and you can, which is just a good thing.
00:15:50.250 --> 00:15:52.895
Generally you know better security overall.
00:15:52.895 --> 00:15:59.357
But it starts to get into that problem of how do I trust something before I use it?
00:15:59.357 --> 00:16:05.267
And if you think about that, when you go to a cloud today and you get an instance, it's like getting a server.
00:16:05.267 --> 00:16:09.557
You assume that the BIOS is high integrity and has no backdoors.
00:16:09.557 --> 00:16:11.591
You assume that the hypervisor you're using is good.
00:16:11.591 --> 00:16:20.932
You assume that the operating system is good and you look at the certifications that says this organization went through PCI, hipaa, soc2, etc.
00:16:20.932 --> 00:16:24.317
Which is an assessment done by human at some point in time.
00:16:25.019 --> 00:16:38.187
But it doesn't give you a way to actually measure as improved mathematically that this is a piece of hardware that meets this level of security and has this level of firmware and BIOS and microcode.
00:16:38.187 --> 00:16:45.456
So I know it hasn't been tampered with and confidential computing lets you do those things.
00:16:45.456 --> 00:16:48.202
So you can ask the hardware.
00:16:48.202 --> 00:16:52.316
Tell me what state you are in and prove that.
00:16:52.316 --> 00:17:01.928
Tell me what software you're running and is it the same software that I built in my secure environment over here in the data center, so I know that it hasn't been tampered with.
00:17:01.928 --> 00:17:10.895
So think of SolarWinds, that attack where there was manipulation of compilers and libraries being inserted into the supply chain.
00:17:10.895 --> 00:17:21.247
You could prevent that kind of situation by showing that this code has been tampered with before I run it, and I can prove that, and the hardware can tell me.
00:17:21.247 --> 00:17:25.786
It's not the piece of software that could be manipulated, it's the processor itself that can prove that.
00:17:25.786 --> 00:17:27.611
That's a game changer.
00:17:27.611 --> 00:17:33.231
When it comes to Real things like zero trust, we not just rely on a one way.
00:17:34.141 --> 00:17:37.808
When remind the audience, the solar winds was the so-called software supply chain.
00:17:37.808 --> 00:17:39.772
It was almost like a black swan event.
00:17:39.772 --> 00:17:41.603
It shouldn't have been.
00:17:41.603 --> 00:17:45.673
I mean, we should have known all along that software is incredibly complicated.
00:17:45.673 --> 00:17:52.057
It's got its own life story, it's got its own supply chain and what happened with solar winds was that elements of that supply chain.
00:17:52.057 --> 00:17:53.180
The attackers were very smart.
00:17:53.180 --> 00:17:59.113
They found the software module sub providers, the subcontractors that were most vulnerable, and they attack those.
00:17:59.113 --> 00:18:09.509
So then the software modules come back into the mainstream, everything's recompiled, everything runs and you've got that Vulnerability lurking in the supply chain that has been exploited.
00:18:09.509 --> 00:18:16.026
Um, I, that is really why George and I so interested in Confidential computing.
00:18:16.026 --> 00:18:19.160
Foundationally, because it helps us tell the story behind the data.
00:18:19.160 --> 00:18:28.413
It helps us you know, code is data and it helps us improve that confidence in the, in the backstory of the code and the data that we're all depending on.
00:18:29.842 --> 00:18:50.304
Yeah, exactly, it's all about my are you taking some Um fingerprint of the data, I'm sorry, fingerprint of this, of the, of the compiled code on the, on the Development system, and then using that as to compare to the running code that's inside of your, your, your, your system?
00:18:50.986 --> 00:18:51.910
It's a little more than that.
00:18:51.910 --> 00:18:56.781
So, when you think about all of the, all of the things that you can measure, so what?
00:18:56.781 --> 00:18:58.808
What constitutes something that you're going to run?
00:18:58.808 --> 00:19:13.285
Well, you've got things like the, the bootloader, the firmware, you've got the microcode version in the processor, then you've got the actual code itself for the application, which may be, you know, containerized application, multiple things, and then you've also got the initial memory state.
00:19:13.285 --> 00:19:15.851
You expect that to start from.
00:19:15.851 --> 00:19:20.028
All of those things Constitute essentially what you expect to run.
00:19:20.641 --> 00:19:36.009
So, when you've gone through your build process and you typically you'll have good security practices around the build process Um, you've got to make sure that what you're building is actually what you've run and you don't have an unexpected hypervisor that's actually leaking data out to a third party.
00:19:36.861 --> 00:19:49.720
Um, that you don't have an operating system with a back door that you didn't expect to be there, or you are using something that's not in the build process, that has a vulnerability that somehow correct in, or malware.
00:19:49.921 --> 00:19:51.204
It's being injected somewhere.
00:19:51.204 --> 00:19:55.756
So, essentially, you're taking secure hatches of all of those components.
00:19:55.756 --> 00:20:13.251
You know you can choose which ones you want to do, depending on your sophistication and risk tolerance, but it's all about making measurements of things Computing hatches and then asking the hardware we compute those hashes for me and it will give you those measurements back and you can then look at those measurements and combine them to what you build.
00:20:13.251 --> 00:20:41.099
And the the upside of this too is that the measurements on that software and the fact that the hardware has digitally signed this with the key that's essentially Embedded in at manufacture time into the secure processor, it can sign that, so this then becomes Evidence of what you're running and that evidence can also be then used as identity Like a machine identity to then do things like pull a secret into that application.
00:20:41.099 --> 00:20:54.907
And so the old way of having to give a cred to an app After you start it and then hope that it's in a secure environment and hope that that cred doesn't get stolen by an insider that can be eliminated, that kind of threat.
00:20:55.601 --> 00:20:56.826
And that means credential.
00:20:57.940 --> 00:20:59.306
Everything's got a credential in these days.
00:21:00.402 --> 00:21:01.907
Yeah, yeah, thank you.
00:21:02.859 --> 00:21:17.368
Yeah, so the power of attestation comes down to proving trust in something that you're running and then also using that information to bind the identity to other things, like a key management system, so you can then pull in secrets or pulling configurations.
00:21:17.368 --> 00:21:31.090
If you can do all of that automatically, then confidential computing becomes Very, very seamless and you can instrument it into your dev processes, as opposed to building encryption tools or having to turn things on at the application level.
00:21:31.090 --> 00:21:33.406
That is the way we were doing it today.
00:21:34.540 --> 00:21:36.419
Nice to trust, but it's better to verify.
00:21:37.772 --> 00:21:38.840
I Hold that.
00:21:38.840 --> 00:21:40.104
It's trust but verify.
00:21:40.104 --> 00:21:50.160
But the question is well, how do you really verify if you can't verify the thing that's verifying, which is software for the most part, and so abstract that to the hardware and you do have to still trust the hardware?
00:21:50.160 --> 00:21:53.717
Yes, but we trust AMD, we trust intel, we trust arm.
00:21:53.717 --> 00:22:00.279
You know, we trust the manufacturers and they have very, very strong processes over this and the trust mechanisms in that process.
00:22:02.229 --> 00:22:04.440
Mark, what's the process of deploying this?
00:22:04.440 --> 00:22:04.480
I?
00:22:04.480 --> 00:22:11.676
It sounds complex, complex and it sounds that I mean.
00:22:11.676 --> 00:22:19.971
My experience is that when encryption gets involved, there's overhead and and, and, and I'm just even from a processor.
00:22:19.971 --> 00:22:21.317
Overhead, you know, there's a performance hit.
00:22:21.317 --> 00:22:26.500
For those of us who think about CPU performance, yeah, how do you, how do you sell around that you?
00:22:26.500 --> 00:22:27.844
How do you sell around that?
00:22:28.906 --> 00:22:56.792
Well, the thing is you don't have to, because the modern processors if I look at, say, an AMD sev processor and Intel TDX these are the very you know current processors and TDX is also fairly new the, the benchmarks of these show that the performance impact of the full confidential computing capabilities is somewhere to the order of, you know, 5% on average, even under the serious load, which is a very acceptable number when you're getting this amount of value from encrypting data in use.
00:22:57.500 --> 00:23:35.672
So you know, and the question that you asked is exactly the right one, traditionally software based encryption mechanisms always added a fair chunk of the processor to dedicate to the processing of data and encrypting it, whereas this is offloaded into hardware accelerators, on the, on the processors, for the memory and then also for things like IO and disk encryption and so on, and so you can get some very high performance and you have the elasticity, and so you can scale horizontally and, you know, set your limits on Kubernetes, run them in a confidential pod and you're away and you don't have to worry so much about that performance and you don't have to worry so much.
00:23:37.720 --> 00:23:41.431
So, steve, I know you've got I suspect you have more more technical questions.
00:23:41.431 --> 00:23:44.128
I want to know how heck you get this into the marketplace.
00:23:44.128 --> 00:23:45.503
You know what.
00:23:45.503 --> 00:23:47.109
Who is buying this?
00:23:47.109 --> 00:23:50.568
Um, what are the objections you run into mark?
00:23:50.568 --> 00:23:53.848
How do you, how do you, knock those objections down?
00:23:54.700 --> 00:23:55.843
Yeah, good question.
00:23:55.843 --> 00:23:59.271
So number one is always I haven't heard of this technology before.
00:23:59.271 --> 00:24:07.819
This sounds too good to be true and it is a very powerful technology, and so this definitely education that's needed, which is why we're doing this podcast.
00:24:07.819 --> 00:24:13.592
Why is we spend a lot of time with customers in workshops and things like that, to education on on the technology?
00:24:13.592 --> 00:24:17.448
Um, so that that'd be the first one, I think, when you think about you know.
00:24:17.468 --> 00:24:19.873
Coming back to your last question about well, how do you get this seen?
00:24:19.873 --> 00:24:26.250
Um, traditionally, confidential computing was quite an onerous task for organizations.
00:24:26.250 --> 00:24:28.295
They had to build applications to it.
00:24:28.295 --> 00:24:31.740
Um, that's no longer the case, especially with what we're doing.
00:24:31.740 --> 00:24:41.323
It's a matter of essentially taking applications and processes and putting them into a confidential computing environment, and you can do that in in very short order.
00:24:41.323 --> 00:24:52.655
You know, if you think about the old way of protecting data was the best practice was typically encrypted, the application tier, so we'd use a toolkit and we'd have key management and we'd have to think about the data flows and so on.
00:24:52.655 --> 00:25:12.174
That was, you know, weeks to months of effort, typically per application in a typical enterprise Confidential computing, including the ability to not only protect data in use but enforce data at rest and in motion can be instrumented into a CI CD, and so then it becomes a question of well, how are you building software?
00:25:12.685 --> 00:25:13.549
We are CI CD.
00:25:14.726 --> 00:25:15.407
Sorry, good point.
00:25:15.407 --> 00:25:27.650
So it's into the development pipeline process so you can actually turn on confidential computing when you need to use it, as opposed to code it in, which is how you used to build it into.
00:25:27.650 --> 00:25:31.165
You know you used to build application security with SDKs, like you know.
00:25:31.165 --> 00:25:34.434
Rsa, be Safe is the classic one, and there's loads of vendors that do this sort of stuff.
00:25:34.434 --> 00:25:39.576
With confidential computing, it doesn't have to be built into the app.
00:25:39.576 --> 00:25:50.230
It can be instrumented by operations and turn it on so that the instance becomes confidential and the application then runs confidentially, at least the way we implement it.
00:25:50.230 --> 00:25:50.811
So it's easy.
00:25:53.549 --> 00:26:03.457
So I'm imagining that a confidential computing element like a T, a trusted execution environment, is essentially a hardened processor, a computing environment.
00:26:03.457 --> 00:26:14.518
I'm imagining that you're talking about taking enterprise software in its current state and, in a sense, recompiling it or running it in a virtual machine inside the TEE.
00:26:15.653 --> 00:26:16.744
Yeah, it's more like the latter.
00:26:16.744 --> 00:26:21.744
So the confidential computing environment is going to be regular processors.
00:26:21.744 --> 00:26:27.744
It's not like a special purpose processor, like TPM was a dedicated special process of the managed keys.
00:26:27.744 --> 00:26:36.352
So you can have, you know, you can get an Intel Xeon with TDX or SGX extensions, you can have AWS, nitro enclaves.
00:26:36.352 --> 00:26:40.057
These are all the kind of the brands, if you will, of confidential computing.
00:26:41.666 --> 00:26:53.744
In essence, the way we look at it is that you should be able to take your applications, run them in confidential computing without change, without re-architecting, not even a line of code change or even recompiling.
00:26:53.744 --> 00:27:02.930
It's taking the binary and running it virtualized so that you can run in a confidential computing environment, a run-time environment.
00:27:02.930 --> 00:27:08.113
Essentially an operating system gives you, gives the application, what it needs to run.
00:27:08.113 --> 00:27:12.760
So if there was the confidential computing environment was missing networking and storage.
00:27:12.760 --> 00:27:17.744
We filled in that gap, so it just appears like a regular application environment.
00:27:18.288 --> 00:27:20.704
And then think about, say, starting a web server, right?
00:27:20.704 --> 00:27:27.909
So one of the things a web server needs is the TLS key so it can decrypt traffic coming in from the browser Simple key.
00:27:27.909 --> 00:27:32.744
That's a very important key because if that's exposed all sorts of compromise can happen.
00:27:32.744 --> 00:27:40.744
So if you can securely inject that into the enclave as it starts, so that it just looks like a file that it would normally pick up.
00:27:40.744 --> 00:27:59.211
Then it can just run just as it would on a regular environment, and so confidential computing has to be about the simplicity of the application and then also simplicity for the processes around it managing configurations, keys, orchestrating, integrating into Kubernetes so that it's just seamless.
00:27:59.211 --> 00:28:01.442
So that is how this works.
00:28:01.442 --> 00:28:12.704
It is almost a kind of a virtualized way of looking at the world, and an application that was formerly insecure can now be run securely without changing it.
00:28:12.704 --> 00:28:20.577
That's how you get to do this in the development to operations process, as opposed to in the decoding process.
00:28:21.138 --> 00:28:21.398
Got it.
00:28:22.486 --> 00:28:40.957
So that strikes me that part of your value proposition is you're eliminating the need for, I guess, deep dive security audits of all the source code to employ every protection technique, that secure technique that you might.
00:28:40.957 --> 00:28:54.756
Now you can just take that code that you've been running with you knew you had some technical debt associated with it move it into your environment and you can, because of that connection back to the hardware, you can adjust it.
00:28:57.066 --> 00:29:01.394
You can certainly raise the bar on security for existing applications like that.
00:29:02.987 --> 00:29:05.744
You have to be mindful and realistic also about expectations.
00:29:06.306 --> 00:29:21.531
So, for example, if you have a database that you want to run in confidential computing, you absolutely can and should, so that the operations on the database are not visible to insiders and they can't memory dump and encryption of data at rest is protected inside the walled garden of the enclave of the secure execution environment.
00:29:21.531 --> 00:29:30.596
But if you have a SQL interface that is vulnerable and you can query it, you'll still have a vulnerable interface and so you have to be mindful of how you use it and the expectations around it.
00:29:30.596 --> 00:29:45.744
It's definitely a very powerful technology, but you might want to also think about the overall threat model to what you're instrumenting into the cloud or your data center and think about what mitigations you can reduce.
00:29:45.744 --> 00:30:11.217
But we've done analysis against the mitre attack matrix, which is basically the typical threats that people have to deal with in running applications, and there's at least 77 mitre attacks, as in vulnerabilities that are immediately eliminated by running it in hardware, which is a pretty big chunk of high risk that's reduced just out of the gate without doing anything.
00:30:13.788 --> 00:30:14.270
So what do you use?
00:30:14.270 --> 00:30:17.222
Cases that you're seeing the most accident in People that are coming to you?
00:30:17.222 --> 00:30:21.355
Yeah, great question Is it beyond regulated and sensitive data?
00:30:23.012 --> 00:30:26.971
Yeah, it's some really interesting stuff that we're seeing and it's probably like three categories.
00:30:26.971 --> 00:30:31.314
I'd say One is the regulated industries, the obvious suspects.
00:30:31.314 --> 00:30:33.066
You know the defense agencies, as you do.
00:30:33.066 --> 00:30:46.653
Others often started banking, healthcare as being the next obvious ones, and it's just unblocking things like cloud migration, where you know the irony of confidential computing is it's widely available in the cloud but it isolates you from the CSP.
00:30:46.653 --> 00:30:50.576
So if you don't trust the cloud, you can now control what you're putting into it.
00:30:50.576 --> 00:30:55.396
So it gives you hardware controls that you might have had in the data center that weren't there before.
00:30:55.396 --> 00:30:57.432
So now you can move things to the cloud.
00:30:57.432 --> 00:30:59.511
So banking, you know healthcare.
00:31:00.145 --> 00:31:14.531
But I think the two interesting categories we're seeing are especially machine learning and AI where, if you think about AI, you're often dealing with multiple entities of data, so people that don't often trust each other.
00:31:14.531 --> 00:31:32.453
So in a bank, you might have two lines of business that could, you know, merge data together, but the merger of that data could be very high risk from a breach risk perspective, like high net worth data above and beyond, you know, typically regulated, it's the crown jewels of most banks.
00:31:32.453 --> 00:31:41.933
Yet being able to analyze that with machine learning might give you something that's brand new, and you want to make sure that you have integrity over the execution of the model itself.
00:31:42.744 --> 00:31:45.744
So you want to make sure that you have integrity over the dilemma, exactly.
00:31:45.744 --> 00:31:58.590
And so now you can start to shrink the attack surface of execution of the AI model and create environments where you can have multiple parties come together into what is a trusted ecosystem that can't leak and you can control what comes out of that.
00:31:58.590 --> 00:32:01.049
So let's get the results out.
00:32:01.049 --> 00:32:09.338
So let's target this individual with these products much more granularly than I could with just anonymized data.
00:32:09.338 --> 00:32:18.172
Or, you know, minimize data AI and AI as a service inside organizations who just want to explore it and has a popularity and excitement, and so on.
00:32:18.172 --> 00:32:19.434
That's a really big one.
00:32:19.434 --> 00:32:31.307
And then the one that's really cropped up is third parties that for years have been dealing with security and they've got visibility into data that is very high value.
00:32:31.307 --> 00:32:36.461
So imagine all of those DLP vendors, you know, the ones that have the perimeters that used to inspect the data coming in and out.
00:32:37.455 --> 00:32:37.675
DLP.
00:32:37.675 --> 00:32:41.260
These are the data loss prevention yeah, data loss prevention.
00:32:41.555 --> 00:32:50.824
Or there's companies that do things like API scanning to see what the behavior looks like, with applications to detect risks based on the behavior of users and systems.
00:32:50.824 --> 00:32:54.023
Those have privilege over what's coming in and out.
00:32:54.023 --> 00:33:16.141
They also have the API tokens, so being able to secure that and lock that down closes a gap on what is actually security infrastructure itself, and that's helping those organizations move more of their customers to the cloud who have concerns over that level of access and visibility into the client on infrastructure that they don't own.
00:33:16.141 --> 00:33:30.781
So there's some really interesting scenarios that span everything from banks to healthcare to highly regulated industries and then brand new businesses forming on the back of this technology as well, like the multi-party computation.
00:33:30.781 --> 00:33:31.684
That's practical.
00:33:37.335 --> 00:33:39.342
Well, mark, I think we're gonna leave it there.
00:33:39.342 --> 00:33:44.542
This has been really super interesting, unless there's something else you'd like to address.
00:33:45.575 --> 00:34:00.880
No, well, I think I come back to the fact that you know, irrespective of whether you're thinking about cloud or computation in the data center, over the next few years the confidential computing is gonna be on people's radars and it's gonna end up on their roadmaps, whether they like it or not.
00:34:01.134 --> 00:34:08.925
You know the stakes are too high, especially as we get into higher levels of data that need to be processed by machine learning and AI.
00:34:08.925 --> 00:34:10.059
We're gonna hear about trusted AI.
00:34:10.059 --> 00:34:19.005
We're gonna hear more and more about trust I know that Steve's been talking about this for years and all of these things come together with trust.
00:34:19.005 --> 00:34:27.563
That has to come back to hardware at somewhere and then from there everything else can be trusted on top, and without that it's a house of cards.
00:34:27.563 --> 00:34:35.623
So this is absolutely in people's futures and I think what it'll mean is that security resolves to being about denial of service and the human error.
00:34:35.623 --> 00:34:46.101
If we can close down a lockdown computation in this way, which is a very profound, forward-looking statement, but I think in five years we'll look back and think you know what that might've been the right thing to do.
00:34:47.556 --> 00:34:51.561
And then I think we'll take the confidential off the front of this and just make it all computing.
00:34:52.436 --> 00:34:54.001
I think that is 100% correct.
00:34:55.014 --> 00:35:04.445
It's understandable that we triage at this time because things are expensive for this, and we triage sensitive and regulated data to be the first use cases for confidential computing.
00:35:04.445 --> 00:35:26.364
But you know, as computing gets commoditized, I mean I'm sitting here in a room with a, for all I know, a software-controlled LED light bulb with a couple of thousand lines of code, and there's millions of these things around the world and they're all points of attack and that idea of attestation and hardware roots of trust, even in light bulbs and vacuum cleaners and automobiles.
00:35:26.364 --> 00:35:38.744
This stuff needs to be spread far and wide and it's great to see this, the practicality of the deployment that you talk about, that the existing compute and the existing work flows can be picked up and moved into a secure environment.
00:35:38.744 --> 00:35:41.639
It's gotta be the way to go, yeah absolutely.
00:35:42.054 --> 00:36:00.347
I agree, so I may just stop right there, but I'm gonna say here myself that, while tremendously powerful, I'm also struck by the need for existing approaches.
00:36:00.347 --> 00:36:18.539
With Mark, you were talking about how do you protect an SQL interface and the database that where that data that's normally stored in plain text and you still have the techniques of good security hygiene that have to apply to those.
00:36:18.539 --> 00:36:29.523
Similarly, you were talking about AI data so much the data that LLM has been trained on it's bullshit.
00:36:31.795 --> 00:36:33.228
You have to think about integrity.
00:36:33.855 --> 00:36:43.514
So integrity, the regulatory discussions around bias that's built into the data sets, confidential computing, can't do anything about that.
00:36:43.514 --> 00:36:48.891
There's still a tremendous amount of work that needs to be done around the data itself, oh sure.
00:36:48.931 --> 00:36:49.855
Yeah, yeah, absolutely.
00:36:49.855 --> 00:36:55.054
I mean, you can make sure that it's coming from somewhere you trust, but you have to make sure that the data is also reasonable as well.
00:36:56.202 --> 00:37:00.030
And that's what's so powerful about what you're talking about.
00:37:00.030 --> 00:37:13.376
Yeah, exactly, To be able to prove that you have a trusted device is manipulating your bits and bytes, Exactly.
00:37:13.376 --> 00:37:15.119
Oh, Mark, thank you very much.
00:37:15.119 --> 00:37:18.724
We'll look forward to getting you back sometime.
00:37:18.724 --> 00:37:22.025
Hear about your progress and reach out to us.
00:37:22.025 --> 00:37:23.661
Let us know when something hot happens.
00:37:23.661 --> 00:37:24.719
We'd love to have you back.
00:37:24.875 --> 00:37:25.960
Absolutely anytime.
00:37:25.960 --> 00:37:27.438
All right, good to see you again, guys.
00:37:27.818 --> 00:37:28.681
Thanks, mark, so good.
00:37:28.681 --> 00:37:29.342
Thanks everyone, cheers.
00:37:29.342 --> 00:37:40.934
We'll see you next time.
OTSI VARASEMAID OSASID
Otsi kanali Making Data Better viimaseid osasid.
Vastutamatussäte: Sellele lehele manustatud taskuhäälingusaade ja kunstiteosed pärinevad Lockstep Consulting Pty Ltd-lt, mis on selle omaniku omand ja ei ole seotud ettevõttega Listen Notes, Inc.
MUUDA
Aitäh, et aitad hoida podcastide andmebaasi ajakohasena.
