Confidential computing and its significance in security and privacy for sensitive data takes center stage in this interview between Dave Vellante, Ayal Yogev, and Arvind Raghu. As part of the coverage of RSA 2023, the interview highlights how confidential computing enables organizations to take their data and workloads to run in any environment with complete security and privacy, and how AWS has been providing confidential computing with Nitro Enclaves.
Dave Vellante: Hi everybody, you’re watching theCUBE’s coverage of RSA 2023. We’re here at Moscone West. This is day 4. The week has flown by — I don’t know, 40, maybe even close to 50,000 people this week in San Francisco. We’re really excited to have Ayal Yogev, who’s the CEO and co-founder of Anjuna Security and Arvind Raghu, who’s the Worldwide Business Development and go-to Market Strategy Lead for EC2 Core Confidential Computing at AWS. Cube alums, good to see you again — thanks so much for coming back on.
Arvind: Thank you for having me.
Ayal: Thanks for having us.
Dave: What an event, huh? We’re back to 2019 levels it feels like — maybe even more. There’s more excitement, more startups, more people. It’s good to be back, isn’t it?
Ayal: Yeah, it’s great. RSA is always like a big reunion and it’s fun to see everybody, people I’ve worked with throughout the years. It’s always a super fun event.
Dave: It’s incredible. You go out at night, you see people you haven’t seen in a while — I just saw another friend of mine that I used to work with at IDC, you know, “Oh yeah, I forgot!” It’s really a good old week. Ayal, why don’t we start with Anjuna? Why did you start the company? What were the roots?
Ayal: Yeah, thanks for asking. So my background has always been in security. I’ve been doing that for over 20 years, and what I love about security is that the best security solutions are enablers, right? They enable you to do something that you couldn’t do without the confidence and trust that security provides. Just one example is the firewall. The firewall is what enabled organizations to connect their internal networks to the internet for the first time. They wouldn’t have done it without a firewall. When I went into confidential computing, which is what we based the company on, it was very clear to me that this was going to be the next big enabler in security. It essentially enables organizations to take their data and their workloads and run it in any environment with complete security and privacy. The first thing we’re seeing now is this enables cloud transformation. Organizations can take their most sensitive data, any workload, and run it in the cloud.
Dave: I wrote a piece a while ago — if you just Google “AWS: A Secret Weapon,” it’ll come right up. It was really all about Nitro, and certainly, Graviton was part of that, but the Annapurna relationship that started — it’s really interesting, the history of AWS and its EC2 and other semiconductor design prowess. But I learned a lot last year that reinforced when we first met just about your perspectives on confidential computing. I’d say you guys were, with Nitro Enclaves, really ahead of the game. Others have now copied that, which is good. That’s actually a good thing. But how would you summarize your perspectives on confidential computing?
Arvind: Sure. Let’s first define what confidential computing is so our listeners know what we’re talking about. Depending on who you talk to, the definition changes a lot. But I think there’s one thing everybody agrees on — confidential computing is about protecting data in use from any access. Everything we build is based on our conversations with customers. Based on our conversations there, there are two distinct security and privacy dimensions that we have identified that pertain to confidential computing. Dimension one is where we are protecting customer code and data from operators on the cloud provider side. In this case, that’s AWS. So if you are running on EC2 today, there is no operator access from AWS to reach into your code or data that’s running on the instance. That, by default, is satisfying one dimension of confidential computing already. So if you’re running a Nitro-based instance, from our perspective, we are already providing confidential computing by default. Now, if you are looking to further isolate that code and data, if you’re running sensitive data (not all data is created equal — there’s [unintelligible] data and sensitive data) and you want to protect it even from yourselves, that’s really when a solution like Nitro Enclaves comes into play because it’s providing additional isolation on top of what you’re getting on a Nitro-based instance. That satisfies dimension two where you’re concerned about protecting code and data from yourself. That’s our perspective, our definition, how we look at confidential computing. Everything that we have built has been based on working backwards from customer requirements.
Dave: I’ve heard what I consider ridiculous arguments where somebody says, “So I get it. You protect from yourself but then protect from, for instance, Amazon.” They say, “Well don’t you trust Amazon?” But if Amazon’s protecting it is impossible for them to get to it, why wouldn’t I take that if it’s coming for free? So I heard that as a criticism of confidential computing one time. That’s the dumbest thing I’ve ever heard. Thank you for doing it, and yes, I trust you, but even better, I trust you more now.
Arvind: Thank you. But here’s the thing, we’ve got to trust somebody in the process. We are all trending toward zero trust, but it’s an asymptotic curve. We’ll get there at some point, but right now we’re not there. You’ve gotta trust somebody in the chain.
Dave: Ayal, this idea of making security an accelerant to your business or an enabler — I think a lot of people would say, “Nah, security is all about risk reduction and lowering my expected loss.” How can security become an enabler? Give us your perspectives on that.
Ayal: Yeah, so specifically, when it comes to confidential computing, when we talk to large organizations, like banks for example, roughly what we’re seeing is that 10% to 15% of the workers are already in the cloud. About 10% or 15% will probably never move to the cloud, but any of these 70% to 80% of workloads that they want to move to the cloud, there’s a lot of benefits to moving to the cloud; there’s scalability, there’s access to services that exist in the cloud. There’s a lot of reason why you want to move something to the cloud, but it’s being blocked. And basically security and privacy are the number-one and number-two reasons why the moves are blocked, and it’s concerns around data sovereignty, concerns about the privacy of the data, it could be PII data of customers. So if you have the right security solutions where you don’t have these concerns anymore, then security becomes in an enabler. Then you can take the 70% and 80% of workloads that you want to move to the cloud that are being blocked, and security becomes an enabler.
Dave: So really the use case that we’re going to talk about here is moving data from on-prem into the cloud that you want to put into the cloud but you can’t because why? Because it’s not encrypted? You’re not protecting data in motion, is that right? Can you explain that?
Ayal: Yeah, so the the number-one reason, what Arvin basically mentioned, is the core difference of the cloud versus on-prem is that the cloud is essentially somebody else managing the infrastructure for you. On on-prem, it’s your building, it’s your server, it’s your people. You have control of the full stack. And even then, sometimes you don’t want your admins to have access to your data. So it’s, to some extent, true on-prem. But in the cloud, it’s even worse because it’s a third party that’s managing it, and for banks that worry about what happens if the government comes in with a subpoena and a gag order, can they get access to my data? What happens if the cloud provider gets access to my data and you have third parties running on the same servers? So there’s a lot of security and privacy questions that people have, and that’s exactly where, if you have the right solution where access to the infrastructure doesn’t mean access to data anymore, that it just solves the concerns and enables those cloud migrations.
Dave: Is the hard part the data in motion or is it the full spectrum?
Ayal: So it’s funny — the hard part has actually always been the data in use. So data in motion is now pretty much solved. You can encrypt it using HTTPS. Data at rest is solved. You can encrypt data when it’s in a database or a file system. But the one piece that was always unprotected was data in use. What happens when the application needs to process the data and it decrypts it, loads it into memory, and at that point it’s completely accessible. And to some extent, that was the core of why access to infrastructure gives you access to data. Even if you encrypt everything, the data sits in the clear and memory. And the encryption keys have to sit somewhere on the infrastructure. So if you have access to the infrastructure, you have access to the keys and therefore to everything. Once you close that gap, then finally, you have full security and privacy on top of your environment.
Dave: So the architecture isolates pretty much everything, right? Maybe explain how traditional virtualization architectures were established and what’s different.
Arvind: That’s a well-informed question, by the way, and with the Nitro system, what we’ve done as you pointed out already, traditional virtualization versus what we did with the Nitro system is we abstracted away a lot of the virtualization functions, if you will, from the host with the Nitro system we moved it away from the host. Functions like networking and storage and device models, management, security, all of that were pulled away from the actual EC2 host itself and sits on separate PCIE cards on a Nitro system. And that is isolated from the actual host, which is running the virtual machines, which are your instances. The only thing that’s running on the host, is in addition to all of that, is just the Nitro hypervisor, which is a very light hypervisor, which takes care of ring fencing these virtual machines. That provides isolation between different tenants and also provides additional isolation that we talked about with something like Nitro Enclaves. So that’s the isolation model we built. But let’s not get hung up on isolation because how we do it does not matter. What matters more is what we do for our customers. And what we’re doing here is providing that end-to-end protection that I talked about. There are three things that you do with data. You store data, you move data, and you process data. The protection for storing data and moving data has existed for a while. What we’re now doing is extending the protection for data in use. Once it comes into the memory and once it gets unpacked and plain text is revealed, how are you protecting it and who are you protecting it from? That’s really what matters. But sure, yes, the Nitro system itself provides that isolation — that’s a very strong isolation model we built. Everything else is a combination of both isolation and encryption.
Dave: And the only entities that can get access to that are the ones that are trusted, that should have access to that, is that correct?
Arvind: That is correct, and just to add a little bit more to that, with your Nitro instance itself, even if you trust us, we don’t have access to your instances, so that’s already taken care of. And beyond that, you may have users — even admin-level users — who have acess to your instances. If you want to fence them out, that’s where you provide —
Dave: In that scenario, you’re not trusted, you’re blocked, right?
Arvind: We are blocking ourselves out of there. The way I’d like to describe it — my personal opinion here — is your data is radioactive to me. We don’t want to get anywhere near it, right? And that’s how we treat it.
Dave: It’s like when someone tells me, “I have this confidential information.” Don’t tell me! I don’t want it.
Arvind: Yeah, I was telling somebody yesterday, somebody walked up to me and asked me, “Hey Arvind, how confidential is confidential computing?” I said, “I can’t talk about it.” [Laughter.]
Dave: So let’s go through a customer use case. You just talked about banks before, so I’m a bank. You said 10% of my data is in the cloud. I want to put another 30% to 40% into the cloud. How do I do that — who’s watching? How do you guys work together? What are the integrations? Let’s go through the use case.
Ayal: Yeah, maybe I can talk about a specific use case. We actually worked with a large bank. It’s a top 20 bank, and the use case was super interesting. Basically they had their core banking application running in a mainframe. Essentially the mainframe became a bottleneck because more and more users started using the digital experience, and it caused them two issues. One was the latency started going up and beyond the SLA of what they promised their customers because the mainframe was a bottleneck. The other issue was the cost per transaction started going up in a massive way. What they decided to do is use AWS and essentially put a caching mechanism in front of the mainframe to take care of these transcartions and then sync it back to the mainframe once a day just to sync it back to the core banking application. So they’ve built all that, got it ready to put on top of AWS, but then security and privacy got in the way. And the reason it was done that way is because the sketching mechanism is processing PII data. Basically there was a regulation out by the bank from the bank of England PRA that talks about protecting data in use in the cloud that basically blocked them from putting it in the cloud. Obviously, AWS provides Nitro Enclaves to help solve this problem. The issues many customers run into is that if you want to use Nitro Enclaves, you have to refactor the application. You have to rebuild it for the Nitro system, and that’s where Anjuna comes in. We essentially build a software stack to make it super simple to take any workload, any piece of data, and run it in confidential computing environments without any changes. No need to change the code, no need to recompile. And that’s what we’ve done with this bank. We enabled them to take that caching mechanism and put it in AWS with no changes. In terms of what they achieved, one is the cost per transaction went down significantly, and then the latency went down from over 2 seconds to about 40 milliseconds.
Dave: Why was the mainframe a bottleneck in that scenario? Can you explain that?
Ayal: Yeah, because everything has to eventually get to the mainframe. All the data has to be stored there. And then as the number of transactions went up, they had about 50 million users that were using the the digital experience. Everything had to go through that one bottleneck to the mainframe. The option they had was, other than scaling the mainframe, which would have been about a 100 million dollar project… obviously, they didn’t want to do that.
Dave: So the mainframe ran out of gas. So was data coming in from different locations, or was it…?
Ayal: Yes, it’s the core banking application. Everything eventually gets to the mainframe.
Dave: Okay, so they would’ve had to buy another Z20 or something. 100 million, it would’ve cost?
Ayal: That was the number they shared with us, which is obviously not something they wanted to do. The cloud is the perfect solution for these types of use cases if you have the right security.
Dave: That’s interesting because I’ve talked over the years to a lot of banking customers and mainframe customers. They would buy a new mainframe, sight unseen, because they can make a business case on it. But if you can use the cloud as a caching layer, the business case is way more attractive — for this use case anyway. And you said latency went down to 2 milliseconds?
Ayal: 40 milliseconds from about 2 seconds.
Dave: 40 milliseconds from 2 seconds. And the cost per transaction, can you repeat that one?
Ayal: Yeah, basically when the mainframe became a bottleneck, the cost per transaction went up significantly. That went down with this caching mechanism.
Dave: Okay, so you also mentioned that, prior to Anjuna, you would have to make changes to the application in order ot take advantage of confidential computing. Did I understand that correctly?
Arvind: Maybe I’ll add a little bit of color to that. It’s not necessarily a blocker. It’s the considerations that you have to take into account when using a technology like Nitro Enclaves. Are you building the application from the ground up or trying to repurpose what you have? If you’re trying to repurpose what you have, that’s really where you’re thinking, “How do I lift and shift this without making any changes, without refactoring this?” Versus if you’re building from the ground up, you know the rules you have to work with. But regardless of which situation you’re in, if you don’t want to use a building block and build everything all by yourself, Anjuna can actually speed it up for you by reducing your time to market because they have a solution that can help move it faster than you yourself building it. So yes, there’s refactoring involved, but that’s involved when you already have code you want to repurpose.
Dave: Is there an analog with a Graviton, for instance, in order to take advantage of Graviton? You really want to optimize and think about how to take advantage of it. Is it similar or is it different in that? I can run workloads — it’s just that I can’t necessarily have them optimized for confidential computing existing workloads? Or do I actually have to make changes to the code to take advantage?
Arvind: Well if you’re using existing code, you do have to make changes. But Graviton may not be the best example to compare here because oftentimes, what we find is customers migrating to Graviton are either moving all the way from on-prem into the cloud and directly onto Graviton — or from, say, X86 instances into Graviton. So the considerations that are in play over there are a little bit different from the considerations we have here.
Dave: So the bottom line is there’s things that have to be done for existing apps. You obviously don’t have to do them for Greenfield apps. How do you do that? What’s the magic inside the covers?
Ayal: Today, if you want to use Nitro Enclaves, you have to recode the application. If you’re already in the process of recoding, maybe you want to do this, but in many cases, the engineers are not necessarily security experts. And you want to let them do what they do best, and then you can come after the fact and just run everything in Nitro Enclaves with no changes, which is the solution we provide. Not to mention if you have any legacy applications, things you already wrote and don’t want to change, or third-party applications, if you want to run a Nitro Enclaves, this is exactly where we come in and help. The way we do that is that we… maybe just go one step deeper into why you have to recode. With Nitro Enclaves, basically you have two pieces. There’s a piece running inside the enclave, which is the core of what the application does and that’s protected, and then you have all the communication that’s happening with the outside. And that’s something you don’t want to enable within the Nitro Enclave. So essentially, you almost have to break the application in two — a piece that’s doing what the core application does and a piece communicating with the outside. And then you have this connection between the two. That’s where you need to do it yourself if you refactor the application. Or, with us, what we do is take the entire application, run it inside the Nitro Enclave solution, and then we become the slayer that sees the application is trying to communicate with the outside; we’re going to take that and make sure it’s being handled properly as it moves to the outside. So again it’s just completely from the outside with no changes.
Dave: So it sounds like a perfect partnership. You guys love this because you get more data into the cloud faster with less friction. What kind of integrations do you have to do or have you done — or do you need to do in the future?
Ayal: That’s actually where I think additional benefits come into play because obviously, we’ve partnered very closely with AWS to be able to connect this to the Kubernetes service of AWS and to the key management service of AWS. And basically, we integrate with the different systems and solutions AWS provides to fit it into an enterprise environment. A lot of these large banks or large financial services organizations are using all these services and fitting into the ecosystem of the large companies — obviously very, very complex, which is one of the challenges we see when people try to build it themselves. It’s not just around recording the application, which is usually hard enough on its own; it’s integrating with all these other solutions that’s also a challenge. We’ve basically taken all that pain away just to make it super simple.
Dave: I’ve always been skeptical because Amazon has the mainframe migration program — I’ve always been skeptical about that because it’s hard to migrate Cobalt. But I love the fact of being able to extend the useful life of my existing mainframe and save 100 million dollars — that’s real business value to me.
Arvind: Yeah, we see this often with traditional banking institutions. They have APIs that have worked for a decade. Nobody wants to touch it. They know it’s working, they know it’s secure. Now they just want additional security enhancement. This is where I want to connect the dots with the earlier question you asked, “What is a security enabler? How do you look at this?” PII is not new to the cloud. It’s existed in the cloud, but there are a lot more regulatory compliance pressures, everything that these institutions are starting to have to consider as they move more workloads into the cloud. And that’s really where this big security becomes an enabler whereby deploying these solutions, by ensuring the isolation, by ensuring there’s no operator access, there’s no insider access and whatnot, these workloads are coming to life in the cloud. The data itself has been there, but what you do with it and how much more you can do with it is really the enabler.
Dave: I think it’s a really legitimate, defensible premise that you’re making security an enabler because you think about when you’re developing a new application and you’re all excited and focused on the functionality, working backwards from what the outcome is. You’re embedding certain aspects of security, but at the end of it all, there’s that last mile. You have to get through compliance, the audit, the security team — all that, and if you can remove that, that takes away friction, it’s an accelerant for time to market, and I think a big win for customers. So, guys, congratulations. I’ll give you a last word.
Ayal: I think where this is eventually going is once you have solutions like Nitro Enclaves, there’s really no reason not to use it for everything. I think average computing is just going to become computing, kind of like how HTTPS became security for everything. I think this is where the world is going and it’s the right direction. I think it’s going to make all of us more safe and secure.
Dave: Yeah, it’s a little inside baseball here, but super important. Guys, thanks so much for coming on theCUBE. Enjoy the rest of the show.
Try free for 30 days on AWS, Azure or Google Cloud, and experience the power of intrinsic cloud security.
Start Free