 Thank you, Tomas, and thanks to everyone for joining. I have a few slides to walk through for the initial piece of it, and then we'll hop into a demo. So let me share my slides. Great. Can everyone see that okay, Tomas? Does that look okay? Looks okay. Thank you, Anusha. Wonderful. So excited as a member of the hyperledger community to be able to share with you today a little bit around how we are using hyperledger fabric as a cybersecurity startup in the Washington, DC area at a very high level. What we've come up with and a core part of our platform is hyperledger. What we've come up with is a way to do essentially fully automated internet allows you to do a multifactor authentication. With the idea of the multi-factor authentication, the idea of one-time use credentials, but for API-based traffic. We can actually ensure that every API call goes with a one-time use credential. Today, excited to show you how we are putting that into practice and protecting software supply chains. to chime in with any questions as we are going along. I think both Bonnie and Tomas are going to help me answer the questions as we go through. And let's get started. So just the agenda for today, we'll talk about, you know, very standard software supply chain and how supply chains are in use today. We'll talk about API secrets and sort of one of the dirty little secrets about API secrets. Talk about, you know, attacks against CI CD systems will go into cautious platform a little bit so that I can show you how we're using hyper ledger and how, you know, we think we've come up with some neat ways to productize it and then we'll do a demo against actually a live CI CD pipeline. Wonderful. So here is and this is probably very familiar to to many of you online right now. Here is a very standard type of CI CD pipeline so continuous integration continuous deployment pipeline that most organizations today that are developing software developing base products or SAS platforms have something like this in place in their own dev test staging kind of production infrastructure. Right. So what's happening here is you have some code here on the left hand side that some engineers are perhaps committing and they could be distributed all over the world in fact, and they're committing into a version control repository. So in this instance we're looking at GitHub but it could be GitLab it could be, you know, whatever you're using for version control. And then that triggers actually building the software, right and you can do that through something like Jenkins or, you know, whatever you're using for your, your build infrastructure. And likely, you know, if you have a somewhat mature CI CD pipeline, you're not just going to build and make sure it compiles, but you'll also scan and test it. And then once it passes, all of these automated tests all of these, you know, the security scanning vulnerability scanning so forth, you'll publish those artifacts and those artifacts get published into some sort of an artifact repository. In this instance today we'll take a look at a very common one called JFrog registry. It could also be using something like Nexus or you know something along those lines just where you're going to keep your artifacts which could be, you know, all forms of code right it could be binaries it could be Docker containers, it could be helm charts for example it could be even, you know, text files that you're using as part of configuration let's say right so something that you need to version and then leverage to then deploy into your staging production environments. If it's a cloud native application, you're likely deploying charts and containers using technologies like helm and Docker and Kubernetes. And you're deploying these artifacts into cloud environments like Google cloud or Amazon web services Microsoft Azure cloud. So very standard sort of pipeline right now. And what we'll talk about is, if we think about that pipeline, it has to by necessity be fully automated. And each juncture, what's happening is you're triggering API calls to be made. What's happening today with a lot of API based pipelines like this is they're using secrets right so either keys or tokens perhaps PKI certificates to do mutual TLS to secure those API junctures and make sure that you know API clients are actually authenticating. Hopefully they're doing that. And one of the challenges that these API secrets in the form that most use them today so tokens key certs are really, and here's the secret just system passwords, they're rather static. They're often shared, rarely rotated, often set to never expire, and as we're seeing with an increased number of attacks and things like that they're getting leaked sprawled sprayed across tons of environments and systems and we see a number of logos here that are oftentimes part of a CI CD pipeline or your software supply chain. And this is where you're having to do all of this manual secrets management, because they're static and because they're essentially bearer forms of authentication, and end up being weak proxies for machine identity right so when you talk about a key or even a token or PKI certificate. If I were to grab one of these and use them from outside of your pipeline outside of your trusted chain. I would in fact be able to use it right and that's fundamentally the issue with the bearer model of authentication right. So anywhere that we're using automated pipelines, we really need to kind of think about how can we secure particularly the communication that's happening in critical infrastructure like our software supply chains. So what that means is security needs to keep pace with automation. Right, we need strong notions, a strong definition of identity, and be able to do things like pin communication between only trusted entities, whether that's two Kubernetes pods in your cluster or whether that is, you know, a client that's trying to communicate into a piece of industrial IoT equipment sitting on a shop floor. The common thread here is that in this type of API based communication there isn't a human identity to verify the access, but you still need all of those same guarantees that we're often familiar with on the human identity side, like pinning communication like, you know, a credential rotation hygiene observability control. And so that's really where we're finding a Corsair to sort of be the missing link. Right. And, you know, increasingly we're seeing these targets against CI CD pipelines and automation I think, you know, even in the past few months there's been an explosion in terms of trying to steal these static secrets out of things like circle CI and, you know, octa and GitHub and so forth. So how do we combat this this is where we'll get into, you know, Corsair and the hyper ledger piece a little bit. As I mentioned Corsair is really focused on trying to bring all of the goodness around MFA to the world of and helping elevate machine identity in particular is sort of a first class citizen in the whole IM space. So, very quickly I'll go over this so that you can get a sense of what the flow is and then we'll double click into the hyper ledger piece and how we actually leverage it in the next couple of slides. So what we've built is an API security platform that relies heavily on hyper ledger as an out of band DLN. At the end of the day what hyper ledger is doing is collecting dynamic machine identities from all of these dispersed API clients where that client could be anything from a Kubernetes pod to a virtual machine a Docker container. It, as I mentioned, could even be, you know, IOT equipment sitting on a shop floor and you know we're actually doing some work right now in that realm with the US Air Force where they're looking to regulate access in a shop floor environment. And so, you know, how does this work. What we do is we hook in at the time of deployment, right, and then uniquely a couple a seated authenticator with an API client, right, and what that means is an authenticator really can take a number of factors let's say the API client is a, you know, for, for sake of an example here a Kubernetes pod. So our authenticator might be another container in that pod, right, or just a sidecar. So, you know, let's say these are all deployed uniquely seated with the authenticator, and then M3 will take for example is going to as each of these will start establishing its identity against the ledger network. What that means is that on a configurable interval, say on the order of hours for example, it'll send off a cryptographic heartbeat to the ledger. Each heartbeat build off of the previous right and then effectively forms a streaming chain identity on the ledger. At the same time, M3 and its authenticator is going to maintain the most recent portion of this identity, let's say the last few beats, so that when it's time to make an API call M3 can now, in addition to its static primary or say an API key, can also send as just an extra header on the API request, a MFA credential that's built off of this moving identity and these are one time use and traceable back to M3 and back to its identity on that on the ledger, right. And then in front of the API service where we want to actually enforce MFA, we drop our proxy, that proxy will pick off the extra header and simply check it against the ledger. And if there is a match with M3's identity, you let the call through, otherwise you block it. So very simple concept and you probably out there see analogies to you say a TOTP, right, like an RSA token or duo for example, where here hyper ledger really is acting as that out of band element in the whole MFA check and handshake. And what's neat about it and what actually takes this step beyond or few steps beyond TOTP is one the distributed nature of hyper ledger allows us to create a really nice redundant high availability story. So obviously these identities once written to the ledger are immutable and chained and you know we would say privacy preserving because these cryptographic identities really the essence here is the fact that they are chained together they themselves contain no PII right. It's only possible to produce this MFA credential locally on the client so even if a node in our ledger network for example was compromised it couldn't be used to do things like produce valid MFA credentials or you know really kind of affect the system in that way. And we kind of use hyper ledger as almost the state database so it gives us the ability through a web based console to then also monitor and control all of the API access and all of the identities that are managed here. So we can with the press of a button change the state to say M3's identity. So we are we don't allow API traffic through right so it turns almost into this dynamic sort of machine identity platform if you will. With that, you know maybe I'll pause for just a moment to see if there's any questions here around this. I'll go through the chat. Great, and it looks like Patrick you may have a question. No we can't hear you unfortunately we cannot. I'm just going to enable you to talk now Patrick can you try again. Can you hear me now. Yes. Okay, I think I was muted. Thank you for this. I'd love for you maybe now or later to step up a level and tell me why anybody cares about this. Right. So, and I would challenge you to do that without using any acronyms or technologies. What problem are you solving and what customers so in supply chains in IoT devices industrial settings. What exactly can somebody use this for. Yeah, without any technical speaker acronyms. Absolutely. That is a great question. So I would say at a very high level. Right. We are helping stop unauthorized access to systems and services. From other systems and services, right, regulating access so that you cannot get unauthorized into say, you know, and 3D printer that's sitting on a shop floor, or into a web based platform that's running in AWS gov cloud, using a static stolen credential. Right. So that's what's happening here these, these API credentials and I know API is an acronym but these, these credentials are essentially getting stolen in hordes and being used outside of trusted environments. But with something like an MFA solution in place, which really helped us kind of solve the human password problem, you no longer have to worry about if that system password gets stolen, you've got an extra factor on there. And that factor makes, you know, the stolen one worthless on its own. Does that help. It does. So I'm seeing this as a solution within your, and now that I'm reading the title of it, the software supply chain in your, in your, in your cybersecurity posture. My apology, I was thinking supply chains like what would this do to document my vaccine arriving with chain of custody type solution advice cybersecurity firewall. Yeah, technology management. Got it. Okay. Thank you so much. That's very helpful. Sure. Of course, thank you for the question. And I'll take one more from Shrekanth and then we'll we'll stop again in a little bit and take a few questions. How's that. Can you unmute Shrekanth? I did. Shrekanth, can you talk? Shrekanth had a question hand raised quite early on the intro. Okay, so maybe just remain there. Shrekanth, if you would like to talk just raise your hand again and I will unmute you then. Is that all right? Great. Okay. Awesome. So, so this is the idea, right, and we're getting some good questions around why hyperledger, why is mutual TLS not enough and things like that. So I will say, you know, mutual TLS is fantastic, right. And personally for myself and I know I didn't quite do an intro here but I've spent over 20 years coming out of the DoD and the intelligence world with the US government, right. And mutual TLS is fantastic. The challenge with mutual TLS is key management. Super hard to maintain hygiene around all of these key pairs that are floating around at scale. And what we have essentially done is create this nice abstraction over mutual TLS. And the way that we do it is we treat hyperledger kind of, as I said, the state database but also this identity manager, right. And what we can do, the neat thing about kind of what we're doing with hyperledger is we have taken fabric and we have fully orchestrated it on pure Kubernetes, right, which means that we can deploy it up and out to all sorts of basically anywhere that you can run a Kubernetes cluster in minutes. And in fact, we have active deployments on Google Cloud, Azure, AWS, even air-gapped environments with some of our sensitive customers. And the idea here is to make sure that we have deployed hyperledger in such a way that we are not platform dependent, right. And it's obviously easy to scale up and out. And it is a very helm driven deployment. I think we actually did a talk at KubeCon, maybe not last year but the year before on how to stay cloud agnostic with a platform like this, right. But the end, you know, ultimately under the hood, what we're doing is providing a nice abstraction and good hygiene around things like key management. So we're leveraging also within hyperledger for our own identity management, cert manager in there, right. So we're actually able to provide kind of a nice intermediate CA, allow you to specify your own roots of trust if that's what you want to do in more sensitive environments and essentially create an abstraction over mutual TLS. I will say that, you know, all communication into our ledger is actually MFA, right. It's using both Corsche as well as mutual TLS. And so this authenticator that we pushed to the API client is able to establish mutual TLS, but in a way that is extensible and easy to manage. So we can, you know, with the push of a button force an authenticator to rotate its underlying PKI. And I think that's one of the big advantages to using just PKI out of the box. And one of the neat reasons that we went with hyperledger is it's just a very flexible way to do this type of like, you know, difficult key management and machine identity. And our deployments are fully helm driven. So that's one of the things we've invested a fair amount of resources in on the infrastructure side. And eventually, you know, where we see taking our ledger because we've got both the SaaS offering as well as kind of an on-premise offering, but with our SaaS offering is really thinking about it as kind of multi-cloud, right. So to have some nodes out in AWS, perhaps some in Oracle Cloud, some in GCP, some in Azure. And then that, you know, as we are constructing our consensus policies even helps even further with the whole idea of high availability and high confidence in, you know, the decisions that we're making within the ledger. So this is a little bit around how we construct it. What I'll then look at is, you know, double click a little bit into how we do the streaming identity, right. So we're writing from an authenticator to the ledger on a configurable interval. And then we're building out these API credentials, these MFA credentials as a function of just the most recent few beats. So what's neat about it, and actually takes a step further than like a traditional TOTP is it's not based off of just one synchronization, it's based off of a handful, right. So what's nice there is then you take off like attack vectors from a cybersecurity perspective like point-in-time man in the middle. And then the authenticator keeps, you know, can keep then in its local just fixed persistent storage, just the handful of few beats that it needs to build out MFA credentials. And it's very easy to kind of rotate under the hood. And so I got a good question here actually from Abhijith around how do you solve clients which could be in a data center, right, versus talking to a cloud service. So what's neat is the authenticator is really all you need on the client side to be able to establish, manage and leverage the identity and all of the key rotation happens there. So there's a bootstrapping that happens with the authenticator to initially register it against the ledger. And then from that point onwards, as the, you know, these identity streams are built, very easy for the ledger to interject and say, okay, that's great. You want to write another beat, but first rotate your identity, rotate all of the underlying PKI. So it creates this nice kind of asynchronous out of band way to control even, you know, the age of any keys that are being used at the edge, for example. Like with something like this, and our usage of hyper ledger you can guarantee that you're not using PKI that's older than five minutes, right, if that's what you want to do. And, and yeah, that's right. The authenticator does need a very small amount of fixed persistent storage. Right. And, you know, in those instances, so you know I'll give you an example here of, we're doing some work right now with the Air Force manufacturing center, where we're actually placing our authenticators say in front of industrial IOT equipment. And for those of you that worked particularly say in the IOT or the manufacturing realm. You'll know that oftentimes these machines are immutable, right, you cannot add anything, let alone storage you couldn't add software on there. In other instances, we have a number of different form factors for these authenticators they could be, you know, binaries they could be code level SDKs they could even be hardware based authenticators which is what we're working, you know, that which is what we're doing for the Air Force manufacturing center. And, you know, APIs, as we all know, are are really everywhere. And so this whole idea of elevating machine identity we think it's just a really important step to take towards, you know, kind of securing a lot of these automated supply chains. So let's take a look now at moving towards the demo and how we actually secure some of these CICD and software supply chain systems. So for example, let's take a look at Artifactory, right, or whatever Artifactory repo that you may be using in your own environment. The question I would have for you is, how is it that you are connecting to the Artifactory repository from within your software supply chain. Chances are you're using something like service account tokens or some sort of tokens or perhaps, you know, a static key a static certificate somewhere along that way. So now, every juncture in your pipeline that needs to communicate with your Artifactory repository. Ideally, that's using its own unique credential and unique, you know, service account token if you will to connect. But each of those needs to be managed as a secret and needs to have a lifetime needs to have, you know, an expiry and a way to rotate it. Chances are you probably have overstretched DevOps teams and shortcuts are happening things like sharing the same credential between say Jenkins and your your scanning tools, right. Or let's say you have to allow in trusted third party vendors to publish artifacts directly increasingly we're moving towards these highly integrated ecosystems right of multiple vendors multiple collaborators. In that instance if they need to push to an Artifactory repo. How are you securing that access. And are you able to at a whim remote revoke that access. So those are the kinds of questions we've been asking ourselves and asking folks around us, particularly and you know in this instance we're talking about artifact publishing but but anywhere along this chain. What are all of the API junctures here, if you will. Right, so let's for us dive in and this is where I'll hop into the demo a little bit and hopefully show you, you know, using our own production CI CD and our dev CI CD pipelines. And how we're doing it today and how you know, using something like this hyper ledger solution with Corsa can really do something like actually pin access and flip on MFA. Right, so let me flip over here and bear with me as I set up this demo a little bit. Okay, great. So can everybody see this window that on the right hand side has Jenkins and on the left hand side has. Jay frog Artifactory instance up here. Great. Sure. I'm still logged in. Wonderful. Right. Log in here. And every time my screen goes black I'll just tell you what you're seeing and rather not seeing is my password manager so bear with me as I'm grabbing my passwords. Great. Okay. So now, um, what we'll do, and this is the first the first iteration of this demo. I'll actually be using this Jenkins job, publishing two types of things to this artifact in Artifactory instance that you see right here. The first is a Docker container. Right. So, as I said, we do a lot of work with the Air Force, and what ends up happening is, we want to start with like secure base images right and so I don't know if any of you are familiar with sort of how the Air Force is moving in this direction but they have this notion of like an iron bank repository of images right and so we pull sort of our red our UBI images straight from iron bank and so what you'll see me see me doing here is pushing that to the artifact repository is called a big bang base image. And then the next thing I'll do is actually push a couple of just zip files. These are meant to represent like backups like let's say you're using some sort of a system to to maintain backups and you want to have high fidelity around these backups right now when you think about an artifact repository I would imagine this is one spot where we really don't want anybody in the middle and mucking with things because then we lose confidence in what we are storing here and how we're using it. So, first instance, I'll run this job and this is without Korsche or hyper ledger in the mix this is just standard practice today we're going to use a service account token to push from Jenkins directly into into Artifactory. Right, so let me start filling some of this in. And this is in fact, this isn't a toy actually environment is actually our production environment I have a demo user set up here, and going to push a couple things so let's run this. And what we're using to authenticate as I mentioned is just this this bear service account token right that I had to generate in Artifactory. I marked it in this case that it's going to be used only for Jenkins. I'm pushing it in, and I'm sending it off. Right. And go here. And for the first time around we can actually watch the logs you'll see that I was able to log in using that service account token. I'm building this base image, tagging it and I'm pushing it here. And pushing a. So right we just push this one and pushing a couple of artifacts extra artifacts as well. Great. So, now let's check and see, right so we were here before let's check and see in this directory if we had anything at the time we didn't before running this job. If I refresh. Look at this. You'll see that when I expand this, I now have a big bang base image just as a, you know, sample image that we pushed just now. Right. Very standard practice today. And then also if I go here I go to backups, and I expand backups you'll see I also have a backup that we pushed just now. Right. So this is very normal operation in a CI CD pipeline. Now, here's the issue. You remember that as I was doing this, I had to put in this bearer token. Right. And if there we go. I had to put in this bearer token. Now, what if that bearer token got into the wrong hands. What if it was stolen in some way what if someone on the dev sec ops team or someone within the organization inadvertently, you know, wrote it in plain text to a config file shared it in some way or, you know, it was stolen somehow. If I have, I'm going to put my adversary hat on, if I have that bearer token, I can essentially even outside of this trusted pipeline do the exact same thing or worse. So I'm going to assume I have this stolen token. We have this 123 base image right here. I'm going to actually coming locally from my laptop, and this is running postman so a local HTTP client replicate that API call using exactly the same token that we used in the Jenkins job, and go ahead and delete. This time I'm actually hitting the unsecured endpoint, right. Go ahead and delete that Docker image. Right. So let me hit this. And it's as simple as that. So I get back a 204 no content, which essentially means that the delete was successful. So let's go back and look at our factory again. Okay. Going to come back over here. Refresh, and it's gone. What's worse is what if your adversary deleted and replaced it with their own version of an image named exactly the same thing that has malicious code in it. Right. That's the impact that you can have without securing these kind of critical junctures in your software supply chain. And so that's essentially what we are trying to trying to solve for. So now I'm going to run exactly the same demo again. But this time, imagine that we've got Corsa and hyper ledger in place. We're actually going to hit a Corsa enabled endpoint, and make sure that this Jenkins job right has actually been deployed with an authenticator and so can produce these MFA credentials and is as we speak extending its identity against, you know, Corsa's DLN that is running I think this instance is hitting Google cloud. Right. So we'll do exactly the same thing. But this time, Jenkins instead of directly talking to Artifactory is going to talk to its local authenticator and the authenticator acts as an egress proxy, where it will tack on the MFA credential to the request on its way up. Now, the proxy what it will do is it will strip off the extra header that's added and pass it on. So it still needs the primary bearer token that Artifactory is expecting. Right. So let's go ahead and grab that. Come over here. Pop this in and hit go on that. Right. And so now what you should see is this is still going to succeed. No difference here because we're hitting a Corsa enabled endpoint. This is a legitimate trusted pipeline. The only difference is invisibly these MFA credentials are getting added in. Right. And you'll see that here. I think we're actually far enough along. So let me refresh this. And we have a good base image. Once again. Right. So no change in functionality from the trusted pipeline. Now, if I do the same thing, and I try to hit and do the same thing, delete the image except this time I'm going to hit the Corsa protected endpoint sitting in front of Artifactory. This is what happens. Right. We get the 403 forbidden. And that's the behavior we're looking for. Right. Let the trusted systems and services operate and communicate just as they would. Cut everybody else out. And just to give you a sense, you know, we have the ability when this is kind of the administrative console. So I'll show you how this works in terms of a machine identity perspective. But we actually can track and watch all of the activity that's coming in. And very easily, if I try this again, I'm going to get the exact same forbidden every single time. But it will fail loudly. Right. So you can track things like failed requests have observability into it and so forth. And then, you know, the final piece I'll show you is you may have a trusted element in your pipeline. But what you, you know, maybe a security alert or event came in on this Jenkins publisher that we were looking at. So just, just as well as you don't want you want this to be seamless, you also still want control. Right. And so in this instance, that security event could trigger halting access to Artifactory from Jenkins until we investigate and see what's going on. So now this Jenkins publisher, we've halted access. Now, even though I'm coming from this trusted pipeline temporarily, I may not trust this juncture. I can go ahead and do exactly the same thing. We'll hit our Corsche protected endpoints. Right. Come back here. We still need the bearer token to pass along to Artifactory. But now if this gets into the wrong hands, we're not as concerned. Right. We've we've got time to fix it. It's not an immediate impact. We'll hit go on this. And you'll see that because access has been halted. This job also got a 403. It did not permit it to talk through. And you'll see that in the requests as well. Right. I think we timed out the last one fell off but you'll see that here through as well and you'll see it marked as as halted. Now what's interesting is if I go ahead and resume, instantly I'll be able to communicate again from that Jenkins agent. I'll also note here that this is status needs rotation. We had some really good questions around mutual TLS PKI management and so forth. What's interesting about our approach and usage of hyper ledger here is because of the way we're doing this identity in the ledger, I can rotate the underlying PKI supporting this identity at any time I want. And since I went through a sensitive operation like resume, I'm going to just go ahead and for good measure, rotate all of the underlying PKI. And so that's kind of the idea here and I think for this demo system, we actually have the rotation and the check in time for this identity at every minute it's going to update its identity on the ledger and send another cryptographic beat. And you'll see we can track that it just happened. Right. So that's, that's kind of the essence we're pretty excited about how we're using hyper ledger and, you know, it's been just such a force multiplier honestly for us. In terms of kind of getting all of the security guarantees that we are looking for in terms of machine identity, you know, identity credential access management. And, you know, I will say, you know, just to all of you that joined, particularly looking at the software supply chain side of it really would think about really elevating even software supply chain is kind of foundational and like critical infrastructure within your organizations. It really is increasingly a target point and sort of a, you know, today an easy target point for adversaries. So with that, would love to take some questions or, you know, if you would love to open it up for discussion. That's great. Thank you so much, Anusha. We do have a hand raised from Yusuf. So Yusuf, I'm allowing you to talk now. So please go ahead. Hello, this is Yusuf. Hi Yusuf. I'm calling you guys from Nigeria. I don't know if you've had any anyone from Nigeria calling you regarding hyper ledger or not. But I've been an avid fan of hyper ledger for the past six, seven years. And I'm just at a point where I'm about to start a development of an app and I want to use hyper ledger as a foundation for what I'm trying to do for identity management. I was thinking of hyper ledger in the, I don't know if this is a better version of that. I'm basically I'm trying to do. It's called a vantage level local service directory, which means I'm trying to manage multiple fields of user of less than a certain user in a local environment where the user, the user allows certain information to be available on the platform. And then the user controls certain information access information because of the, the, I mean, the hyper ledger, because we know identity management is very important, especially in places like Africa where security is very critical. You need to be able to use it. So I'm just talking on a very high level. I'm not very technical. So I don't know about actually need help for someone who understands how I can do this deployment. If you could actually help me to build my, my production for my test field for that. Thank you very much. Yeah. Yeah, I can take this one. Thank you for your question, Yusuf. And yes, we do have actually quite some people participating from Nigeria. And this is actually a question for us as a hyper ledger. And the first point I would recommend is to join our discord channel, which I will share just after this presentation. And besides that, we also have the active meetup community as well as Africa regional chapter. So there you can also find like minded individual in, you know, your geographical area as well. So the first step would be to join our discord and there's a special channel for Indy, which as you rightly pointed out is focused on digital identity. And you can take it from there. And if you have any other questions, you know, just feel free to reach out and I can write them down for you as well in detail. And I will add to that, Yusuf, you know, feel free to reach out to our team as well. We're obviously willing to support and it's great to see new initiatives on the hyper ledger side. I sent you a request on LinkedIn, by the way, I'll try and send you requested others also. I just want to make a very small statement. I'm trying to change the world. One step at a time. And I'm trying to create something that was going to tell the help the global South people connect. So it's not easy, but I believe we can do it. Thank you very much. Yeah. Thank you. Okay, Anusha, do you want to take the Q&A? We also have a couple of questions over there. Let me take a look. So I think Ramesh, you asked a question around what is the underlying framework. So, you know, we are essentially using fabric. And we've kind of been using hyper ledger fabric on Kubernetes. I would say at this point for about four years. And, you know, I didn't really talk through much of this, but I'll add to that. In terms of like real life production deployments, we have some real life production deployments across the DoD right now as well. So the US Department of Defense, as well as the, you know, some customers and partnerships like AT&T and Dell, some zero trust labs around the country. And what we're seeing, I know there was a recent paper that actually came out out of some folks on the hyper ledger side even around performance and things like that. And what we're seeing is hyper ledger as a platform is also very amenable to performance tuning and scaling and even under load of say thousands of, in this case, MFA checks per second. We're not really adding latency more than on the order of a handful of milliseconds. So sort of pleased with kind of the production scale at this point and doesn't even seem like we've tapped the limitations of it yet. And then Abhijit, you asked, this means something, a question around this means using the initial bearer token, the Corsair Authenticator grants new access token, I'm not getting the MFA here. Yeah. So that's a great question. So when you think about MFA, it's usually one of three things, right, something you know, something you are and something you have. And we would make a kin the initial bearer token sort of something you know, the issue is that if it's something you know chances are someone else can know it as well. The Corsair Authenticator in MFA speak for us is something that you have, and it's managing an identity and is pinned to the environment from which it's running. Right. And so that's really the difference there in terms of the MFA. Thank you for that question. Mick, MW, I'm seeing a question around heartbeats to hyper ledger are immutable, but did you mention the console could change the identity of a deployed machine. Yeah, so that's a great question. It can change the underlying PKI used to build the identity but it's it still ties back right so it's still a single identity but we're able to change all of the the secret information underlying it if that makes sense. So everything you know so for example, if we are using a PKI key pair to establish mutual TLS we can rotate that key pair. But then the identity on the ledger is consistent so it gives you that nice traceability. And then I see a question in the chat around Fablo. It's a good question, you know we have, we're now starting to look at other exciting projects within the hyper ledger community. So the gateway for example, we just I guess we've been at fabric for a little while now and so time to lift our heads and see what else is out there. Awesome. And I think I mentioned a little bit about the real life deployments, you know we do have active deployments on both kind of the commercial and the US government side across the board. And it really neat to see it across cloud platforms and things like that and you know if anybody does want to connect with some folks on our team and learn about how we've stayed really cloud agnostic happy to share there. Great. Okay. Do we have any other questions feel free to use the chat or raise your hand and I will unmute you. How can I learn more. Great. Yeah, so, you know, definitely reach out to us. You can definitely reach me on LinkedIn you can reach us at info at Corsa.com. You know I will put here here's an interesting QR code on our site we have actually an API. Excuse me. We have a security scorecard where you can go in it's completely anonymous, and we don't actually keep any of the information but just guided questions to see how you are doing with your own API security posture if that's something you're interested in doing. But yeah I would love to, would love to connect. And I see a question around is there a demo environment available. We do have POC environments and so if that's something that you're interested in definitely reach out to us and we can talk more. All right, that sounds good. So we do have time for one more question and then we're going to wrap it up we're almost to the top of the hour. So if anybody else would like to ask something please go ahead. Thanks, Mike. That's great. All right. Well, thank you everybody. I will just share my screen now just to wrap it up and invite also people to join our discord. But first of all, Anousha thank you so much for doing this webinar today you covered a lot of useful information and I'm also glad to hear that the people on the call enjoyed it as well. So those of you that are watching can if there are some questions that didn't get answered or they pop up later feel free to reach out to us, or, you know, the slides will be available on our webinar website so feel free to also reach out to Corsa as well. As I mentioned here is our hyperledger discord channel and I would like to warmly invite you to join. There's a QR code which you can scan, and you will be able to find the slides as well on our webinar library. There's a lot of real time engagement and you can learn more about either our project such as fabric that Anousha was talking about today, but also working groups original chapters and much more. There are upcoming webinars as well and you can follow those on our event website, and we also have workshops. And I would like to invite you to join on the using hyperledger firefly to launch an NFT collection public chains workshop with Kaleido on Thursday, March 23. That brings us at the end of our webinar. Thank you everybody for joining us and thank you again Anousha for all the great information shared today. And please join us for upcoming webinars as well join our discord and feel free to reach out whenever. Thank you everybody for watching and see you next time. Thanks everyone.