Microsoft Entra - Global Secure Access First Look

You. Hello and welcome to the let's Talk.

Azure Podcast with your hosts, Sam Foot and Alan Armstrong.

If you're new here, we're a pair of Azure and Microsoft three, six five focused It security professionals.

It's episode ten of season four. Sam and I had a recent discussion around the Global Secure Access, a feature that was announced with the rebrand of Azure ad to Microsoft Enterid. Here are a few things we covered. What is Microsoft entra internet access? What is Microsoft? Entra private access? How do these features help secure access to the Internet and to SaaS and internal applications? And how is it deployed and how is it licensed?

We have noticed that a large number of you aren't subscribed. If you do enjoy our podcast, please do consider subscribing. It would mean a lot to us for you to show your support to the show.

It's a really great episode. So without further delay, here's the episode.

Hey Alan, how are you doing?

Hey Sam. Not doing too bad. How are you?

Yeah, good, thank you. We've got a new one this week, haven't we?

Yeah. New features on Microsoft Enter ID.

And from the sounds of it they sound pretty big, to be totally honest with you, from what I've read so far.

Yeah. From the sort of light exposure to it that I've had. So I've done a little bit of playing with it but it is definitely very new and still sort of trying to catch up with everything that he can do. So bear with us.

Yeah, it definitely feels like a completely new concept to at least us anyway. Right. It's mainly focused around networking and that's not usually an area that we certainly have to sort of worry ourselves with too much. Right. We get involved in it.

Yeah, I was going to say we get involved and I'd say we have some good background in networking. I wouldn't say we're experts but yeah, we definitely get the concepts and everything.

Yeah. When you have sort of quite a disruptive technology coming in to sort of move away from more traditional concepts, it's definitely an exciting time and it's definitely something that we should all be aware of, I think.

Yeah, definitely. What we're going to talk about today is definitely not weird, but seems you wouldn't expect it to turn up where it did.

Yeah, definitely. Without a doubt. Right, so should we jump into it? Alan? Can you sort of give us just an overview of what Microsoft Entra Global Secure Access is?

Yeah. So Microsoft Entra Global Secure Access is the umbrella of a couple of products or features underneath it. So it's the sort of unified labeling for this sort of functionality. So underneath it is Microsoft enter Internet access and Microsoft enter private access. But generally the concept of all of it is around this solution being a security service edge. So being sort of the location for traffic and managing traffic, securing access to the Internet and to local internal resources. So it's kind of bringing in the zero trust identity first, verify all the time to various services that you may be running. So yeah, that's kind of sort of it in a quick nutshell, from what we've seen from it, it seems very interesting, especially private access and internet access.

Is this effectively these solutions sort of replacing traditional sort of VPN solutions that you would have from a device into either on Prem or your cloud resources?

Yeah, so it's bringing in some capability, like you said, it's kind of replacing traditional VPN solutions as well as potentially some proxies sort of scenarios as well. So it's kind of bringing them into the same sort of solution and it is very tied to zero trust. So it's proving who you are and then what access you have to certain sites or applications, et cetera. So it's definitely bringing that part into it now. So it's kind of the next piece of the puzzle of the zero trust principles.

Can I just work through the topology a little bit, sort of outside inwards maybe? Are we talking about users on devices that are then peered to where are they peered to? I assume it's Microsoft and their network.

Yeah, exactly. So yeah, it's going from end user devices to some of it being gateway in effect and then going to various applications, things like that, where you need.

To and then on the other side of that, as it moves through I'll call the big Blob in the middle Microsoft. Right. And then off the other side of that, it's either going to private access your resources on Prem or other private, I assume virtual networks, et cetera, I'm guessing, or it's going back out to the internet at that point to your SaaS applications, your other various internet connected systems that you communicate with.

Yeah, exactly. And there's some other bits in there where you can does have to go through that tunnel as well, so you can be quite granular with some of it.

Okay. And you mentioned sort of like web content filtering. I suppose that's really the entra internet access sort of part of it. So do you want to start off there and we'll talk about internet access?

Yeah, sure. Enter Internet access is securing access to your securing access to another way of securing access to three, six, five, your SaaS applications and potentially the internet apps out there as well. So what it's doing is some of it is a lot of it is sort of identity centric and it's using it's in effect delivering a cloud delivered secure web gateway. So it's allowing you to then filter the internet and protect users from malicious sites, things like that. So we have some of that with Microsoft Defender for endpoint. Of course, we have web content filtering there, but it's on a device level, so it's per device rather than per user. So this is where this is kind of bringing in that per user scenario where finance teams might be able to access different applications, different web categories. From a web content filtering perspective, you might have the security team that needs to access hacking tools and websites to do advanced threat hunting and things like that. So instead of it just being that device that has all that access, it's based on the user and when they sign in, so that's part of that it can run alongside another an SSE solution. So it can run alongside that. So you can sort of transition from that point, but because everything is going via or potentially going via Microsoft, then there is advanced logs about where the users are, not necessarily where they're going, but how they're accessing three, six, five, and things like that and what profile they used. So now the activity of accessing SAS applications is now enriched even more than it is today and it does bake into conditional access. So now when they want to access an application or I guess the Internet. And again, I've not fully looked at this yet. It may be a web category or something. There might be that we can enforce a different MFA prompt for it. And you can potentially also exclude it from MFA for some scenarios because you know it's going via. You've already detected who that user is on that device because they've signed in. And there are some new locations that you can use because it knows it's come from the Internet access gateway in effect. So you can now start using conditional access to be a bit more simpler or in effect like you'd do before, where you'd know, everyone has come from this IP address in a VPN solution. This is now saying, well they've been verified, so I now know that they're okay to go direct to Microsoft or they go through this tunnel because they also want to be extra secure. Or a SaaS application only supports an IP address filtering, not anything else.

If we sort of think about a traditional VPN solution, am I right in saying that most if you utilize SaaS applications in your business are you split tunneling those SaaS applications through? Your.

Recommended best practice for Microsoft as a SaaS application is to split tunnel because it's better for it to go straight direct because teams going over a VPN to the bridge would be in voice calls, things like that would be potentially terrible.

Yeah, and I suppose TLS is there to protect that, I assume, right? Your more traditional VPN is like a pipe to your private corporate world, right? More than it is these sort of SaaS applications going through. But what that then? Traditionally conditional access would be in place for a VPN just to open the pipe, right? Like challenge when connecting in some scenarios, yes.

Where supported and things like that.

Yeah, but what we're getting the ability to do is to have more fine grained conditional access per potential SaaS application and also having it effectively tunneled through Microsoft's Network all the way through from browser all the way to end application, right?

Yeah, exactly. And one thing that is interesting around it, which I think you'll find interesting is say you're worried about users collaborating with other tenants and they can be invited to other tenants, can't they? There's not necessarily a restriction for them to not go and talk to the other ones, potentially. I mean, we have got the tenant restrictions now in place. There are some of that, but there's no reason for that to happen with this. You can enforce that. They can't talk to another tenant unless it's in the if it's in the tenant settings in Enter ID.

Right, okay.

Because it picks that information up and says, well, no, you can't talk yeah, it is Office, but I know that you're not allowed to talk to that tenant as well.

The scenario I'm thinking of is enforcing MFA for an application that doesn't support MFA, potentially, you've got some legacy SaaS application that you connect to. Right? And maybe it's not SSI and maybe it's some really important system in your business that you can't live without, but it's terrible. Before I assume you could have done that by forcing that traffic through your VPN, right? And then effectively having that that way. But that does take a lot of skill and care to get right, doesn't it? And sometimes that doesn't always work correctly, does it? Just trying to isolate specific network traffic for some random website that you want to enforce some conditional access on. Right. Or.

I don't know yet, because some of it is private preview and the private preview is closed. Whether you can specify MFA to specific websites yet.

Okay, right.

But you can specify a profile for that user and what they're allowed to access on the internet, potentially all the web categories at least. And they would have to MF, you could tell them they have to MFA to be able to then so kind of like opening the tunnel for them.

And then because you would use content filtering to block them basically into that.

Profile, from what I've seen, very high level scenes. So it might be down to the granular level, I don't know yet.

Okay, right. Yeah. Because when I see things like continuous Access evaluation and conditional access, and from the infographics that I've seen, it's like dedicated tunnels, not just specific. It's not one big pipe that we're just getting access to. It feels more granular than that, from what I've seen.

Yeah. And one of the features that Microsoft are calling out on is that if tokens are stolen and then reused somewhere else as part of the conditional access, you're doing that check for what the compliant network they're coming from. So having that agent on in determining which way you go is able to tell azure ad is able basically check in or conditional access check in to see if you're still coming from a compliant endpoint or compliant network. So you can't just reuse that token.

Yeah, because we see that a lot. I don't know what the exact term is, but effectively scraping tokens from local and session storage in browsers, right, is a real challenge dodgy browser extensions, et cetera, that have access to those contexts. Right. So effectively, if there's a token in somebody's browser, then you don't need their password at that point, right. You don't even need their login details at that point, do you? You just need their token. Basically what you're saying is that you can effectively tie the access to that application through your peering into this system. And even if I did manage to grab the access token from your browser, it's effectively useless because I'm not transiting over that network. Right?

Yeah. And another feature, which I'm not sure how it works, but they're talking about that you can send the traffic from your desktop clients, which is kind of what we've been talking about, but also from a remote network. So you can almost create the connection from a router or a VPN endpoint for a branch, for example, and bring that to go through the Internet, access the brokers and everything. So you can capture other things going that way. I'm not quite sure how that works, but that sounds interesting as well.

So they're also saying it's not just at the device level, it's also at the network level as well, potentially giving you that access. Yeah. Okay. Yeah. So I suppose we've kind of talked about it, really, but what's the major sort of benefit for organizations for having specifically Internet access? Because that's usually something that is that usually something that organizations are as concerned about, or are we thinking more B, two B SaaS applications here when we're talking about Internet access, I mean, when.

We talk about Internet access in an organization, yes, they have an Internet pipe, they have a firewall, they have a proxy on site. When you move to hybrid working, then that isn't there. And don't get me wrong, there are Cloud Proxies, Zscaler and various other ones out there and they can take your Internet, not necessarily your Internet traffic, but proxy your web traffic to protect it. And that but Microsoft are bringing in another tool that is in the Microsoft family, in effect, and bringing that zero trust in because all users already signed in with Azure ad and it's all there. So then it's just bringing this next piece of the puzzle in. So yeah, you would potentially have VPNs, things like that. But I think it's come to that point of you've got all these different solutions looking after different parts of your network or different parts of your access to services. So that whole sort of do you have separate siloed solutions that then can't talk to each other potentially from a security perspective? Or do you have one where it's integrated into that Microsoft product suite where it wouldn't surprise me if this data starts going into Microsoft three six five Defender and becoming enriching all that data in there.

Yeah. Because I suppose I probably don't have the knowledge in the sort of advanced networking space to what other zero trust networking solutions are out there. Right. Because this is the only lens that I've already got of it. But I can see exactly what you're saying because there's a big disconnect there between your access to a network and also the other zero trust principles that we've got that we've had for a long time with Endpoints in sort of cloud identities. Right?

Yeah. Well, Microsoft brought in that continuous evaluation into conditional access. So it's checking always where you are, what network you change to and what your state, your compliance or position is. And when that changes, then that might change what your access is with this. Your access to something is the same thing when your position changed. So maybe also your device has now been partially compromised and Defender for Endpoint is now working its magic to resolve itself. But you're still working in the background. This is now going to go, hang on, something's happening here. Your device risk level has now gone to medium or high. That's now changed. Conditional access sees that and goes, hang on, no, I'm not letting you access anything because conditional access says even from this network, we're going to stop it. And then that prevents you fail the conditional access, et cetera. And then I'm assuming this product would then stop the access at that point, not necessarily reliant fully on Defender for Endpoint to block that user.

Yeah, there's sort of multiple things at play. And I assume this doesn't require Defender for Endpoint to operate. Is this completely separate tech?

Yeah. And that's probably fair to say as well. Yeah. You don't have to have Defender for Endpoint for it. In effect. You got to install an agent, get an agent deployed, and then that acts as your local sort of managing your network traffic, in effect, or your connections and where they go.

So however you provision and support applications, in theory, it can be rolled out standalone, right? Sounds like.

Yeah, exactly. It might be that you're not on the journey, maybe you're not at again, we're jumping around a little bit, but at the moment we don't know what licensing it needs because it's public preview.

Yeah.

So we don't know if it's going to be part of P One or P Two, or how much of it is P One, P two, or if there is going to be another skew yet.

Yeah, well, it's also organizations priorities, right. Their roadmap in what they might still be licensed with their current EDR solution for they might have another three years to run on it. Right. Yeah. Or they might be really happy with the product that they've got. So it seems like this Security Services Edge solution is a completely different solution and product than what else is there in the suite. Right.

It's completely standalone and it's probably worth sort of mentioning that large organizations probably do have the skills, the technology to do this today with Cisco, Zetcare, et cetera. But there may be some smaller organizations that don't have the staff to support it or don't have the hardware to support it because that hardware is expensive. And don't get me wrong, you can get cloud services as well. But it's then having the skills to then manage that plus integrations with Azure Ad or Enter ID and things like that. This kind of feels like it's a few tick boxes and it's set up in a deployment of an agent. And it's almost from what I've seen, it doesn't seem too difficult. You don't have to be a full networking god kind of thing.

Yeah, I suppose it's still that single management plane, isn't it, of Azure Portal, right? It must still be. Is it?

Well, it's moving into Entrant.

It's a web user friendly portal, right, where it's configured and it's centralized management of those deploying those agents. Right? All those agents are cloud first configured. There's no on premise. It's all device based, isn't it? There's nothing on Prem that you need to you don't have like an agent on a server that sits on any network because this is zero trust. Right.

This is device not for the Internet access part. No.

Okay. Or should we talk about private access? Because that's probably equally, if not more so exciting.

Yes. So private access is, as it sounds, giving private access to your corporate network and in effect using the same technology, but in effect tunneling via Mugsoft to then come into your network. And I guess that kind of sounds a little scary when you think about it like that. It's just going via Microsoft to then come into your network. Well, how is it getting in? So if anyone's used it, it's using the technology and the capability of the App proxies. You've been able to do this for websites for years now. So as a quick sort of overview of Azure Ad app proxy or Microsoft Enter ID app proxy, you deploy an agent on your network. In effect it's like a reverse proxy. And then in Microsoft Enter ID, you then create an application which references on premise application URL, and then it gives it a public facing one and then you can add conditional access to it. You can do Kerver or single sign on for it if supported. And then in effect you can bring an inter application to the cloud for then users to consume. So this could be used for external people that are guest access, then accessing that application. Maybe they can't do single sign on, but they can get the portal to then sign in with their local credentials. So it just allows you to then bring all your applications accessible from anywhere securely. Because in effect you've got Azure ID, Microsoft Enter ID as your front door and that's having millions of transactions against it and potential attacks. So that is protecting just your application. So it's using that technology to then tunnel to your internal application. I say applications but actually this is sort of legacy. I say legacy. It's like on premise Services. Like RDP, SSH SMB. Now beforehand you'd have to have a VPN and pay for a VPN to do that. And you'd have to then do your policies to allow that access. In effect with this you're able to specify those remote applications and I think then they turn up in conditional access as applications and then you can put MFA on them, which beforehand you'd never be able to do. Like you said Sam, it would only be on the VPN gateway, the VPN connection. Now you're able to do a bit of control about what applications users can access and also what type of MFA they have to do. Maybe they have to do like a 502 key for the finance or the HR systems when they're accessing remotely. But I say remotely. But I believe that because you've got that agent on your client, when you're on the network it will do the same thing. It will add MFA to those services. So you can in know, bring the MFA, checking who they are, et cetera on the network before accessing your local resources. Which I think is very powerful.

Wow. Yeah. Because traditionally when you are inside the castle walls, so to speak, it's usually just free rein at that point, isn't it? Right.

Yeah. Unless you've got depending on what the services are from application perspective, yes. Maybe for secure resources you might have previous access workstations, things like that in place where they're segregated a little bit, but you still be able to just RDP them. You won't be able to do MFA without then adding a plugin. Because I think like duo do a plugin just for RDP to do MFA.

So what you're telling me is that with this app proxy has basically expanded to not just websites but other protocols. Now is that essentially what's happened here? Right, but what you're also telling me is that I get full conditional access granular control for any protocol. So I'll give you an example. I could say if I want to access a share somewhere, an SMB share somewhere, I could force a certain type of stronger MFA like I'm going to do a fido two challenge. Instead of as an example there's a more restrictive set of MFA. What is it? Challenges. Sorry mine went blank there. I can do those types of things with all the other power of conditional access as well. But for all this on prem and.

Different protocol goodness, that is what I'm seeing as yes. So the way I see that working, and again, I haven't had a chance to test it, is that when you request So to set it up, in effect, you specify IP ranges or IP addresses in your policy or fully qualified domain names. And then based on that, when your network when you're trying to access those, this agent then realize sees that, and then it checks the policy. See if you need to MFA or you need to apply conditional access then it goes off. Does that check brings up the prompts, get you to fulfill what is required, closes down and then it creates that connection and then opens the connection up for X time until you disconnect from the network I guess or reconnect. I don't know what that looks like yet.

And then we also layer on not just those conditional access policies but also the continuous access evaluation, risky users X, Y and Z and all of that goodness on top of it. Right?

Yeah exactly. And that is just talking about it on being on the network and then when being remote it's the same experience.

Yeah.

And you know maybe an MFA prompt might look not look bad but be disruptive. But when you've got Windows Hello set up that does your MFA prompt for you because it trusts you've signed in with a face recognition fingerprint or your pin. So you've been trusted that point and then the TPM's now got your trusted MFA prompt in effect. So when that is configured I think it will be seamless. It might only be that if you're out and about maybe that's when it will do an additional prompt like it needs to do a phishing resistant prompt. Maybe it might be something like that. But again this is how I'm viewing it because I've not had a chance to sort of test it. I've got a device running some of it like the internet stuff but I've not got round to the private access yet.

And because it's app proxy I assume that also means multi cloud because anywhere that you can deploy app proxy it.

Can be quote any cloud I guess any partner wherever you may need access to as long as it knows the IP range, things like that. And yeah the great thing is there's no public attack surface there apart from it's Microsoft because the app proxies are outbound looking at a queue to then reverse proxy so that you're not connecting. You don't have a public IP address that's exposed to the internet on four four, three et cetera and manage that risk of vulnerabilities and things like that being exposed.

It's Microsoft's front door at this point, it's not self hosted VPN. I mean on the client side as that responsibility has shifted quite considerably into Microsoft's court at that point. Right?

Yeah. And if there's vulnerabilities at Microsoft that's going to be office three six five and everything potentially exposed. They have to have the agent sign in as a user, do the MFA as required to even get to that point hand have the right profile to be able to specify what they're allowed to access as well. So it's not even like it's like a not like a VPN because you can lock down VPNs and give different profiles. But generally it's just like an internet pipeline in effect, isn't it? And then you come out somewhere and if you get the right profile, I guess you can then access what you need. I think you specify the IPS and what's allowed to access at that point and then it's as granular as the applications, I believe. But the sort of per app access at the moment is only TCP apps at the moment UDP is in development.

When you talk about apps, are you talking about actual installed applications that are run on the devices as well? Can we tunnel individual apps?

I think they're talking about well, I don't know it's the answer, but I think it's probably talking about the services like SMB, things like that. You couldn't do UDP RDP yet kind of thing. Or if you've got a service that is UDP, they can't support it yet because it hasn't created that two way connection to prove that it's got that connection there.

Yeah, obviously still really new, right? What state? Is it public? Is any of it public preview?

You mentioned a private so most of it's public preview. There are some private preview features at the moment, which is I'll just reel them out. It's like dedicated public Internet traffic forward profile protecting user access to the public Internet while leveraging Microsoft Cloud Delivery Identity Aware SWG solution. So that's the cloud proxy web content filtering to regulate access to websites based on their content categories through secure web gateway. So the web content filtering is not public preview yet. And then the other one in there is the Apply Universal conditional access policies to all internet destinations, even if not federated with Microsoft Venture ID. So that kind of implies that either you're going to have a policy that says all internet, you have to meet this criteria to go out to the internet itself, excluding all the Microsoft ones that you need for like Defender for Endpoint and Office Three Six Five. We're not going to say Office Three six five, but enter ID, the core stuff or they're going to do it on a site by site basis maybe, I don't know. It's quite interesting. But all the private access stuff as far as I'm aware is public preview.

Nice. Yeah, sounds really good. And I suppose you don't know timelines or anything like that. It seems like quite a big new release, doesn't it?

Yeah, I need to get into the private preview read, see what else is there. But it is new. It's like three or four weeks. Three or four weeks old now. But.

Yeah.

I don't know how long it's going to be in public preview and how much more is going to change or whether those private preview features going to come out in ga or they're going to wait for it to get this first lot out and then public preview that bit.

Yeah.

I don't know what stance it wouldn't surprise me whether this would come ga at Ignite kind of feels like the colleague, you think it's November, so it's quite a few months there. And it's been in private before the whole thing.

Right, okay.

So I've just not had access to it, but it's been there for quite some time. And I expect a lot of this technology they've already got it's just that they're exposing it to a user based because this is like, in effect, this is bringing zero trust network access.

Yeah. And App proxy was there before. Right. So it's more the front end side of things.

It's more the agent bit.

Yeah, the agent, yeah.

And the Internet access bit is the new bit. Entrapro access really is just enhancing app proxy to do any URL and tunneling to them.

But App proxy would have had that agent on the other side, wouldn't it, originally? Like that type of technology?

Well, no, because all you do is you just go to URL and then it would redirect you to Azure ad and then go via that way. This is from a network level saying DNS or IP address any port you need to go to Microsoft, it's in effect changing the DNS to say you need to go to this DNS name, et cetera, to then be reverse proxied into your organization. As I would see how it works. I've not dived into it to that level.

We touched on it briefly before. What are we thinking about pricing? Do we know anything yet? Obviously it's preview, so we don't get anything like that. Do you know anything about that?

I've not seen anything around licensing. The only thing I've seen was when I was setting some of it up, it said you need a minimum of Azure ad or Microsoft entra p one. I mean, if it was in P one, I think that would isn't that.

Just to get you conditional access?

Yeah, well, that's the question. How much do you it's interesting because I don't know if you need that just to get conditional access. Plus something else. We don't know yet if there's going to be another skew because it feels.

Like there's got to be a data consumption part of it. Right, so they're proxying your traffic. Yeah.

But even with Web proxies today, you pay per user for it.

Do you pay for VPN gateway in Azure? Do you pay you don't pay for.

Ingress, you pay for egress. But if you're ingressing, you're going into Azure, aren't you?

But your egress is your downloads, right to your browser.

Yeah.

I'm thinking you're watching Netflix through yeah. Right.

Yes.

Right. Watching Netflix and my organization's decided to absolutely put everything through this. Right. Are you going to pay for your, I don't know, eight gigabyte film that you watched? I assume you are.

It's interesting. The thing is the question will be is what do you tunnel and what don't you? Because it might be that your company allows it. They don't want it to be tunneled. It might be their applications they want to be able to trust. And your plain internet doesn't go over the tunnel. I don't think that's the idea. I think it's the tunnel.

And really the organization is they're going to want risk reduction and assurance against the applications that store sensitive data about their organizations. Right. Like you say, you take a stance on certain applications, but I suppose it depends what type of company you are because if you were a big social media agency, as an example, you want token protection and you want X, Y and Z. You want all of these zero trust networking things, even when you're interfacing with your Instagrams and your YouTubes and all of that sort of stuff. Right. So I think it really depends on what type of organization you are.

Yeah, definitely. And again, I've not dived into it. And again, we don't know what Microsoft are going to if there's going to be a new skew for it or it's not, or maybe private access might become something that is allowed because it's just going through like they do now with app proxy just slightly more, potentially more data. But yeah, exactly. Could have been the same day. You might have been uploading a big file to it still.

Well, we won't know until they actually deploy it, but now that was great. Anything else you want to talk about, Alan? I know it's really new and caveat is that we haven't played with it. Do get in contact with us if you have played with it because really good to see other people's opinions on what the benefits and value adds are.

Yeah. And what you might be using it for as well. If it's replacing things or you don't have anything and it's actually going to fix a hole in your security plan. I guess the only thing, I kind of mentioned it a couple of times about how we deploy it. There's some policy that you deploy in Microsoft Venturer's portal, but then there's just an agent you download and install. So you can just deploy that via Intune or other software deployments. And then when a user signs in, it signs that in and then does the checks, et cetera. And then yeah, it's ready to go.

Cool, cool. Great. Thanks for that, Alan. That was really good. What's for next week?

That's your one, isn't it?

It is my one, actually. That's a very good point. We are talking about Chaos Studio next week.

That sounds interesting.

We love a bit of Chaos over here, don't we, alan that's for sure. You might well controlled chaos. So Microsoft have got a product called Azure. Chaos Studio. Effectively allows you to it's not even very well simulate outages and disruptions into resources in Azure so you can set up sort of test plans to see the effects of certain parts of your application maybe go offline, start functioning incorrectly, et cetera. So let's think. You've got, like, a logic app that might interact with, say, a key vault. What happens if you can't access that key vault? What happens to your logic app? What happens in those scenarios? So Chaos Studio wraps a load of benefits and features in and around that, and, yeah, I'll take you through that and sort of what the value adds are and why you should be using it.

That definitely sounds interesting. Okay, so did you enjoy this episode? If so, please do consider leaving us a review on Apple or Spotify. This really helps us reach more people like you. If you have any specific feedback or suggestions did I get something wrong? Do I need to update anything? We have a link in the show notes to get in contact with us.

Yeah, and if you've made it this far, thanks very much for listening, and we'll catch you on the next one.

Yeah, thanks.

All bye.