RSA Conference 2023 | Ayal Yogev | Anjuna Security & Arvind Raghu | AWS

theCUBE.net

More from RSA Conference 2023

Ayal Yogev

CEO & Co-Founder

Anjuna Security

Arvind Raghu

WW Business Development & GTM Strategy Lead, EC2 Core, Confidential Computing

AWS

Info

Ayal Yogev | Anjuna Security & Arvind Raghu | AWS

Ayal Yogev

CEO & Co-Founder Anjuna Security

Arvind Raghu

WW Business Development & GTM Strategy Lead, EC2 Core, Confidential Computing AWS

search

(upbeat music)

>> Hi everybody. You're watching theCUBE's coverage of RSA 2023. We're here at Moscone West. This is day four. 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 is the CEO and co-founder of Anjuna Security and Avid 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.

>> Thank you for having me on.

>> Thanks for having us. >> What an event. We're back to 2019 levels, it feels like. I mean, maybe even more. I mean, there's more excitement, more startups, more people. It's good. It's good to be back, isn't it?

>> Yeah, it's great. RSA is always like a big reunion and it's fun to see everybody, people that I've worked with throughout the years. It's always a super fun event.

>> It's incredible. You go out at night and 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, "Oh yeah, I forgot." It's really like good old week. Ayal, why don't we start with Anjuna? Why did you start the company? What were the roots?

>> Yeah, thanks. 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. And 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. And when I ran 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 enabling security. And it essentially enables organizations to take their data and their workloads and run it in any environment with complete security and privacy. And the first thing we're seeing now this enables cloud transformation, organizations can take their most sensitive data, any workload and run it in the cloud.

>> Yeah, so I wrote a piece a while ago. If you just Google AWS' a secret weapon, it'll come right up. And it was really all about Nitro and it was certainly, Graviton was part of that, but the Apernet relationship Avid that started, it's really interesting the history of AWS and it's EC2 and other sort of semiconductor design prowess. But I learned a lot last year. Reinforced when we first met just about your perspectives on confidential computing. I'd say you guys were sort of with Nitro Enclaves really ahead of the game. Others have now sort of copied that, which is good. That's actually a good thing. But how would you summarize your perspectives on confidential computing?

>> 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. And everything we build is based on our conversations with customers. And 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's just no operator access from AWS to reach into your coder 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 innocuous data and sensitive data. If you're running 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. And that satisfies dimension two, where you're concerned about protecting coder data from yourself. That's our perspective, our definition, how we look at confidential computing. And everything that we have built has been based on working backwards from customer requirements here.

>> I've heard some, what I considered ridiculous arguments where somebody says, so I get it, you got to protect yourself, but then protect from, for instance, Amazon, they said, "Well, why don't you trust Amazon?" I'm like, "Okay, but if the Amazon's protecting it, it's 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. I'm like, "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, okay?

>> Thank you. But here's the thing, like you got to trust somebody in the process, right? That we are all trending towards zero trust, but it's an asymptotic curve. We'll get there at some point, but right now we are not there. You got to trust somebody in the chain.

>> Ayal, this idea of making security sort of an accelerant even to your business or an enabler, I think a lot of people might say that, nah, security's all about risk reduction, lowering my expected loss. How can security become an enabler? Give us your perspectives on that.

>> 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 workloads are already in the cloud. About 10 to 15% will probably never move to the cloud. But any of these sort of 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 no reason why you want to move something to the cloud, but it's being blocked. And basically, security and privacy is the number one and number two reasons why this moves are blocked, and it's concerns around data sovereignty, concerns about the privacy of the data. It could be PII data of customers, personal identified data of customers. So, if you have the right security solutions where you don't have these concerns anymore, then security becomes an enabler. Then you can take the 70 and 80% of workloads that you want to move to the cloud, but are being blocked and security becomes an enabler.

>> So, really the use case that we're going to talk about here is, is moving data from on-prem into the cloud that you want to put into the cloud,

>> Exactly. but you can't because it's not why, because it's not encrypted, you're not protecting data in motion. Is that right? Can you explain that?

>> Yeah, so the number one reason is, and it's what Arvid basically mentioned is the core sort of difference of the cloud versus on-prem is that the cloud is essentially somebody else managing the infrastructure for you, right? On-prem, it's your building, it's your servers, it's your people, you have control of the full stack, and even them 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 to worry about what happens if the government comes in with a subpoena and a gag order. Like, 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 the data anymore, that it just solves these concerns and enables those cloud migrations.

>> And is the hard part the data in motion or is it the full sort of spectrum?

>> So, it's fine. 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 the 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 is sort of the core of why that access to infrastructure gives you access to data. Even if you encrypt everything, the data sits in the clear and memory, and the keys, 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, improve privacy on top of your environment.

>> So the architecture isolates pretty much everything, right? Maybe explain how traditional virtualization architectures were established and then what's different

and things like that... >> 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. And we moved it away from the host and 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. And 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. And that provides isolation between different tenants, and it 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, right? Because how we do it does not matter. What matters more is what we do for our customers. And what we are doing here is providing that end-to-end protection that Ayal talked about, right? There are three things you do with data. You store data, you move data, you process data. The protection for storing data and moving data that's existed for a while. What we are 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, 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. And then everything else is a combination of both isolation and encryption.

>> And the only entities that can get access to that are the ones that are trusted, right? That should have access to that. Is that correct?

>> 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 then beyond that, you may have users, even admin level users who have access to your instances. If you want to fence them out, that's why you provide

that in translation. >> Yeah, but in that scenario you're not trusted, right? You're blocked, right?

>> We are blocking ourselves out of there like the way I'd like to describe it and my personal opinion here, but your data is radioactive to me. We don't want to get anywhere near it, right? And that's how we treat it.

>> Yeah, yeah, it's like when somebody tells me, well, I have this confidential information, don't tell me. I don't want it. (Arvid laughs)

>> Yeah, I was telling somebody yesterday, it said, somebody walked up to me, asked me, "Hey Arvid, how confidential is confidential computing?" I said, "I can't talk about it." (All laughs)

>> So, let's go through a customer use case, if you can. So let's say, you guys talked about banks before. So I'm a bank. You said, let's say 10% of my data's in the cloud. I want to put another, I don't have a 30, 40% into the cloud. How do I do that? First of all, who's watching? How do you guys work together? What are the integrations? Let's go through the sort of use case.

>> Yeah, maybe I can talk about a specific use case. We actually worked on 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, and 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. And the other issue is the cost per transactions started going up in a massive way. And what they decided to do is they wanted to use AWS and essentially put, almost call it a caching mechanism in front of the mainframe to take care of this transactions 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, they got it ready to put on top of AWS, but then security and privacy got in the way. And the reason it got in the way is because the sketching mechanism is processing PII data and basically both internal regulations as there's external regulations. There's a regulation out 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. And when we come in with Anjuna, so obviously AWS provides Nitro Enclaves too, to help solve this problem. The issue that 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. So no need to change the code, no need to recompile. And that's exactly what we've done with this bank. We enable them to take that cashing mechanism and put it in AWS with no changes. Which in terms of what they achieved, one is the cost per transaction went down significantly, and then the latency went down from over two seconds to about 40 milliseconds.

>> Why was the mainframe a bottleneck in that scenario? Can you explain that?

>> 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 have about 50 million users that were using the digital experience. It just became everything had to go through that one bottleneck to the mainframe. And just the mainframe just wasn't... essentially the two options they had was other scaling the mainframe, which would've been about $100 million project. Obviously they didn't want to do or.

>> Gas, basically the mainframe. And now was data coming in from different locations or was it?

>> Yeah, it's the core banking application. Everything eventually gets to the mainframe.

>> Right, okay. Okay, so they would've had to buy another whatever Z20 or something

>> Exactly. 100 million, it would've cost.

>> That was the numbers they shared with us, which is obviously not something they wanted to do. And then the cloud is the perfect solution for these types of use cases if you have the right security.

>> That's interesting because I have talked to, over the years, a lot of banking customers and mainframe customers, they would buy a new mainframe site unseen because they could make a business case on it. But if you can use the cloud as a caching layer and the business case is way more attractive.

>> Yes. >> Yes, exactly.

>> For this use case anyway. >> Exactly.

>> And you said latency went down to, you said two milliseconds?

>> 40 milliseconds from about two seconds.

>> So, 40 milliseconds from two seconds, and the cost per transaction, can you repeat that one?

>> Yeah, the cost per transaction, basically when the mainframe became a bottleneck, the cost per transaction went up significantly. And that just went down with the sketching mechanism.

>> Okay, so you also mentioned that prior to Anjuna, you would have to make changes to the application in order to take advantage of confidential computing.

>> Right. >> Did I understand that correctly?

>> Yeah. >> Maybe I'll add a little bit of color to that.

>> Yeah, has that been a blocker?

>> Yeah. I mean please, yeah.

>> It's not necessarily a blocker. It's the considerations that you have to take into account when you're using a technology like Nitro Enclaves, right? Are you building your application from ground up or are you trying to repurpose what you have? If you're trying to repurpose what you have, that's really where you're thinking about, hey, how do I lift and shift this without making any changes, without refactoring this, right? Versus if you're building a ground up, then 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 that you want to repurpose.

>> Is there an analog with like a Graviton for instance, in order to take advantage of Graviton? You really want optimize, you think about how to take advantage of it. Is that similar sort of, or is it different in that? Like can I run? I can run workloads, right? It's just 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 of it?

>> Well, if you're using existing code, you do have to make changes.

>> Yeah, okay. But Graviton may not be the best example to compare here because oftentimes what we find is customers who are migrating to ARM 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 that we have here.

>> Okay, but so the bottom line is that there's things that have to be done for existing apps.

>> Yes. >> Yeah.

>> That you don't obviously don't have to do them for greenfield apps. How do you do that? What's the magic in the inside that covers that?

>> So, generally, and as Arvid said, today, if you want 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 sort of come after the factness run everything in Nitro Enclaves with no changes, which is the solution we provide. Not to mention if you have any legacy applications, things that you already wrote and you don't want to change, or third party applications. If you want to run in Nitro Enclaves, this is exactly what we can mean 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 sort of two pieces. There's a piece running inside the Enclave, which is sort of 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 obviously that's something that you don't want to enable that within the Nitro Enclave. So, essentially you have to almost like break the application to two. A piece that's doing the core of what the application does and a piece communicating with the outside. And then you have this connection between the two. And that's what you need to do yourself if you refactor the application. Or with us, what we do is we take the entire application, we run it inside the Nitro Enclave solution, and then we become the slayer that sees, oh, the application's trying to communicate with the outside, we're going to take that and make sure that it's being handled properly as it moves to the outside. So again, it's just completely from the outside with no changes.

>> So, it sounds like a perfect partnership. I mean, you guys love this 'cause you get more data into the cloud faster with less friction. What kind of integrations do you have to do, have you done, do you need to do in the future?

>> Yeah, so that's actually where I think additional benefits comes to 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 provide to fit it into an enterprise environment. Because a lot of these, again, these large banks or these large financial services, large organizations are using all these services and fitting into the ecosystem of a large company is obviously very, very complex. Which is one of the challenges that we see when people try to build it themselves. It's not just around recoding the application, which is usually hard enough on its own. It's integrating with all these other solutions that is also a challenge. And we've basically taken all that pain away just to make it super simple.

>> I've always been... I mean, I have to tell you, I've always been skeptical 'cause Amazon has the mainframe migration program. I haven't been very skeptical of that. It's hard to migrate coball, but I love... Maybe you have a different perspective of it, but I love the fact of being able to extend the useful life of my existing mainframe and save $100 million. That's real business value to me, so.

>> Yeah, we see this often with traditional banking institutions, right? They have APIs that have worked for a decade, nobody wants to go touch it. They know it's working, they know it's secure, now they just want additional security enhancement there, right? And this is where I want to connect the dot with the earlier question you asked Ayal, like, what is the 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 and more workloads into the cloud. And that's really where this big security becomes an enabler where by 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, that's really the enabler, that security.

>> I think it's a really legitimate, defensible premise that you're making security and enabler. Because you think about when you're developing a new application and you're all excited and you're focused on the functionality, you're working backwards from what the outcome is and honestly, you're not, I mean you're embedding certain aspects of security, but at the end of it all, there's that last mile. You got to get through compliance and audit and the security team, the Secop team, all that. And if you can remove that, that is takes away friction. It's an accelerant to time to market. And there's a, I think a big win for customers. So guys, congratulations. I'll give Ayal, last word.

>> Yeah, 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. This is a layer of security. I think confidential computing is just going to become computing like how https became security for everything. And I think this is where the world is going. I think this is the right direction the world is going to, and I think it's going to make all of us more safe and secure.

>> Yeah, it's inside, a little inside baseball here, but super important. Guys, thanks so much for coming on theCUBE,

it's great to see you again. >> Thank you Dave.

>> Thank you. Thank you Dave.

>> All right, enjoy the rest of the show. All right, and keep it right there. This is Dave Vellante. John Furrier and I will be back right for this short break from RSA 2023. We're in Moscone West and we're live. Right back. (upbeat music)

Ayal Yogev | Anjuna Security & Arvind Raghu | AWS

search

(upbeat music)

>> Hi everybody. You're watching theCUBE's coverage of RSA 2023. We're here at Moscone West. This is day four. 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 is the CEO and co-founder of Anjuna Security and Avid 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.

>> Thank you for having me on.

>> Thanks for having us. >> What an event. We're back to 2019 levels, it feels like. I mean, maybe even more. I mean, there's more excitement, more startups, more people. It's good. It's good to be back, isn't it?

>> Yeah, it's great. RSA is always like a big reunion and it's fun to see everybody, people that I've worked with throughout the years. It's always a super fun event.

>> It's incredible. You go out at night and 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, "Oh yeah, I forgot." It's really like good old week. Ayal, why don't we start with Anjuna? Why did you start the company? What were the roots?

>> Yeah, thanks. 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. And 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. And when I ran 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 enabling security. And it essentially enables organizations to take their data and their workloads and run it in any environment with complete security and privacy. And the first thing we're seeing now this enables cloud transformation, organizations can take their most sensitive data, any workload and run it in the cloud.

>> Yeah, so I wrote a piece a while ago. If you just Google AWS' a secret weapon, it'll come right up. And it was really all about Nitro and it was certainly, Graviton was part of that, but the Apernet relationship Avid that started, it's really interesting the history of AWS and it's EC2 and other sort of semiconductor design prowess. But I learned a lot last year. Reinforced when we first met just about your perspectives on confidential computing. I'd say you guys were sort of with Nitro Enclaves really ahead of the game. Others have now sort of copied that, which is good. That's actually a good thing. But how would you summarize your perspectives on confidential computing?

>> 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. And everything we build is based on our conversations with customers. And 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's just no operator access from AWS to reach into your coder 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 innocuous data and sensitive data. If you're running 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. And that satisfies dimension two, where you're concerned about protecting coder data from yourself. That's our perspective, our definition, how we look at confidential computing. And everything that we have built has been based on working backwards from customer requirements here.

>> I've heard some, what I considered ridiculous arguments where somebody says, so I get it, you got to protect yourself, but then protect from, for instance, Amazon, they said, "Well, why don't you trust Amazon?" I'm like, "Okay, but if the Amazon's protecting it, it's 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. I'm like, "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, okay?

>> Thank you. But here's the thing, like you got to trust somebody in the process, right? That we are all trending towards zero trust, but it's an asymptotic curve. We'll get there at some point, but right now we are not there. You got to trust somebody in the chain.

>> Ayal, this idea of making security sort of an accelerant even to your business or an enabler, I think a lot of people might say that, nah, security's all about risk reduction, lowering my expected loss. How can security become an enabler? Give us your perspectives on that.

>> 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 workloads are already in the cloud. About 10 to 15% will probably never move to the cloud. But any of these sort of 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 no reason why you want to move something to the cloud, but it's being blocked. And basically, security and privacy is the number one and number two reasons why this moves are blocked, and it's concerns around data sovereignty, concerns about the privacy of the data. It could be PII data of customers, personal identified data of customers. So, if you have the right security solutions where you don't have these concerns anymore, then security becomes an enabler. Then you can take the 70 and 80% of workloads that you want to move to the cloud, but are being blocked and security becomes an enabler.

>> So, really the use case that we're going to talk about here is, is moving data from on-prem into the cloud that you want to put into the cloud,

>> Exactly. but you can't because it's not why, because it's not encrypted, you're not protecting data in motion. Is that right? Can you explain that?

>> Yeah, so the number one reason is, and it's what Arvid basically mentioned is the core sort of difference of the cloud versus on-prem is that the cloud is essentially somebody else managing the infrastructure for you, right? On-prem, it's your building, it's your servers, it's your people, you have control of the full stack, and even them 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 to worry about what happens if the government comes in with a subpoena and a gag order. Like, 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 the data anymore, that it just solves these concerns and enables those cloud migrations.

>> And is the hard part the data in motion or is it the full sort of spectrum?

>> So, it's fine. 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 the 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 is sort of the core of why that access to infrastructure gives you access to data. Even if you encrypt everything, the data sits in the clear and memory, and the keys, 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, improve privacy on top of your environment.

>> So the architecture isolates pretty much everything, right? Maybe explain how traditional virtualization architectures were established and then what's different

and things like that... >> 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. And we moved it away from the host and 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. And 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. And that provides isolation between different tenants, and it 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, right? Because how we do it does not matter. What matters more is what we do for our customers. And what we are doing here is providing that end-to-end protection that Ayal talked about, right? There are three things you do with data. You store data, you move data, you process data. The protection for storing data and moving data that's existed for a while. What we are 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, 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. And then everything else is a combination of both isolation and encryption.

>> And the only entities that can get access to that are the ones that are trusted, right? That should have access to that. Is that correct?

>> 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 then beyond that, you may have users, even admin level users who have access to your instances. If you want to fence them out, that's why you provide

that in translation. >> Yeah, but in that scenario you're not trusted, right? You're blocked, right?

>> We are blocking ourselves out of there like the way I'd like to describe it and my personal opinion here, but your data is radioactive to me. We don't want to get anywhere near it, right? And that's how we treat it.

>> Yeah, yeah, it's like when somebody tells me, well, I have this confidential information, don't tell me. I don't want it. (Arvid laughs)

>> Yeah, I was telling somebody yesterday, it said, somebody walked up to me, asked me, "Hey Arvid, how confidential is confidential computing?" I said, "I can't talk about it." (All laughs)

>> So, let's go through a customer use case, if you can. So let's say, you guys talked about banks before. So I'm a bank. You said, let's say 10% of my data's in the cloud. I want to put another, I don't have a 30, 40% into the cloud. How do I do that? First of all, who's watching? How do you guys work together? What are the integrations? Let's go through the sort of use case.

>> Yeah, maybe I can talk about a specific use case. We actually worked on 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, and 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. And the other issue is the cost per transactions started going up in a massive way. And what they decided to do is they wanted to use AWS and essentially put, almost call it a caching mechanism in front of the mainframe to take care of this transactions 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, they got it ready to put on top of AWS, but then security and privacy got in the way. And the reason it got in the way is because the sketching mechanism is processing PII data and basically both internal regulations as there's external regulations. There's a regulation out 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. And when we come in with Anjuna, so obviously AWS provides Nitro Enclaves too, to help solve this problem. The issue that 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. So no need to change the code, no need to recompile. And that's exactly what we've done with this bank. We enable them to take that cashing mechanism and put it in AWS with no changes. Which in terms of what they achieved, one is the cost per transaction went down significantly, and then the latency went down from over two seconds to about 40 milliseconds.

>> Why was the mainframe a bottleneck in that scenario? Can you explain that?

>> 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 have about 50 million users that were using the digital experience. It just became everything had to go through that one bottleneck to the mainframe. And just the mainframe just wasn't... essentially the two options they had was other scaling the mainframe, which would've been about $100 million project. Obviously they didn't want to do or.

>> Gas, basically the mainframe. And now was data coming in from different locations or was it?

>> Yeah, it's the core banking application. Everything eventually gets to the mainframe.

>> Right, okay. Okay, so they would've had to buy another whatever Z20 or something

>> Exactly. 100 million, it would've cost.

>> That was the numbers they shared with us, which is obviously not something they wanted to do. And then the cloud is the perfect solution for these types of use cases if you have the right security.

>> That's interesting because I have talked to, over the years, a lot of banking customers and mainframe customers, they would buy a new mainframe site unseen because they could make a business case on it. But if you can use the cloud as a caching layer and the business case is way more attractive.

>> Yes. >> Yes, exactly.

>> For this use case anyway. >> Exactly.

>> And you said latency went down to, you said two milliseconds?

>> 40 milliseconds from about two seconds.

>> So, 40 milliseconds from two seconds, and the cost per transaction, can you repeat that one?

>> Yeah, the cost per transaction, basically when the mainframe became a bottleneck, the cost per transaction went up significantly. And that just went down with the sketching mechanism.

>> Okay, so you also mentioned that prior to Anjuna, you would have to make changes to the application in order to take advantage of confidential computing.

>> Right. >> Did I understand that correctly?

>> Yeah. >> Maybe I'll add a little bit of color to that.

>> Yeah, has that been a blocker?

>> Yeah. I mean please, yeah.

>> It's not necessarily a blocker. It's the considerations that you have to take into account when you're using a technology like Nitro Enclaves, right? Are you building your application from ground up or are you trying to repurpose what you have? If you're trying to repurpose what you have, that's really where you're thinking about, hey, how do I lift and shift this without making any changes, without refactoring this, right? Versus if you're building a ground up, then 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 that you want to repurpose.

>> Is there an analog with like a Graviton for instance, in order to take advantage of Graviton? You really want optimize, you think about how to take advantage of it. Is that similar sort of, or is it different in that? Like can I run? I can run workloads, right? It's just 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 of it?

>> Well, if you're using existing code, you do have to make changes.

>> Yeah, okay. But Graviton may not be the best example to compare here because oftentimes what we find is customers who are migrating to ARM 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 that we have here.

>> Okay, but so the bottom line is that there's things that have to be done for existing apps.

>> Yes. >> Yeah.

>> That you don't obviously don't have to do them for greenfield apps. How do you do that? What's the magic in the inside that covers that?

>> So, generally, and as Arvid said, today, if you want 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 sort of come after the factness run everything in Nitro Enclaves with no changes, which is the solution we provide. Not to mention if you have any legacy applications, things that you already wrote and you don't want to change, or third party applications. If you want to run in Nitro Enclaves, this is exactly what we can mean 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 sort of two pieces. There's a piece running inside the Enclave, which is sort of 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 obviously that's something that you don't want to enable that within the Nitro Enclave. So, essentially you have to almost like break the application to two. A piece that's doing the core of what the application does and a piece communicating with the outside. And then you have this connection between the two. And that's what you need to do yourself if you refactor the application. Or with us, what we do is we take the entire application, we run it inside the Nitro Enclave solution, and then we become the slayer that sees, oh, the application's trying to communicate with the outside, we're going to take that and make sure that it's being handled properly as it moves to the outside. So again, it's just completely from the outside with no changes.

>> So, it sounds like a perfect partnership. I mean, you guys love this 'cause you get more data into the cloud faster with less friction. What kind of integrations do you have to do, have you done, do you need to do in the future?

>> Yeah, so that's actually where I think additional benefits comes to 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 provide to fit it into an enterprise environment. Because a lot of these, again, these large banks or these large financial services, large organizations are using all these services and fitting into the ecosystem of a large company is obviously very, very complex. Which is one of the challenges that we see when people try to build it themselves. It's not just around recoding the application, which is usually hard enough on its own. It's integrating with all these other solutions that is also a challenge. And we've basically taken all that pain away just to make it super simple.

>> I've always been... I mean, I have to tell you, I've always been skeptical 'cause Amazon has the mainframe migration program. I haven't been very skeptical of that. It's hard to migrate coball, but I love... Maybe you have a different perspective of it, but I love the fact of being able to extend the useful life of my existing mainframe and save $100 million. That's real business value to me, so.

>> Yeah, we see this often with traditional banking institutions, right? They have APIs that have worked for a decade, nobody wants to go touch it. They know it's working, they know it's secure, now they just want additional security enhancement there, right? And this is where I want to connect the dot with the earlier question you asked Ayal, like, what is the 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 and more workloads into the cloud. And that's really where this big security becomes an enabler where by 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, that's really the enabler, that security.

>> I think it's a really legitimate, defensible premise that you're making security and enabler. Because you think about when you're developing a new application and you're all excited and you're focused on the functionality, you're working backwards from what the outcome is and honestly, you're not, I mean you're embedding certain aspects of security, but at the end of it all, there's that last mile. You got to get through compliance and audit and the security team, the Secop team, all that. And if you can remove that, that is takes away friction. It's an accelerant to time to market. And there's a, I think a big win for customers. So guys, congratulations. I'll give Ayal, last word.

>> Yeah, 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. This is a layer of security. I think confidential computing is just going to become computing like how https became security for everything. And I think this is where the world is going. I think this is the right direction the world is going to, and I think it's going to make all of us more safe and secure.

>> Yeah, it's inside, a little inside baseball here, but super important. Guys, thanks so much for coming on theCUBE,

it's great to see you again. >> Thank you Dave.

>> Thank you. Thank you Dave.

>> All right, enjoy the rest of the show. All right, and keep it right there. This is Dave Vellante. John Furrier and I will be back right for this short break from RSA 2023. We're in Moscone West and we're live. Right back. (upbeat music)