Hello and welcome to the let's Talk. Azure Podcast with your host, Sam Foote and Aaron Armstrong.
If you're new here, we're a pair of Azure and Microsoft 365 focused IT security professionals. It's episode 39 of season five. Alan and I had a discussion around defender for Cloud DevOps Security. We discussed best practices, key features and sort of practical insights from us using it and implementing effective DevOps security strategies. We've noticed that a large number of you aren't subscribed, so if you do enjoy our podcast, please do consider subscribing. It would mean a lot for you to show your support to the show. It's a really great episode. So without further delay, let's jump in. Hey, Alan, how are you doing this week?
Hey, Sam. Not doing too bad. Not doing too bad. How are you? Yeah, good, thank you. How are you? Looking for your trip next week? Yeah, yeah. Ready to go? No, no, not packed. I haven't rethought. Been keeping up with the stuff I need to do Ignite and trying to keep up with some of the stuff that's happening. What do you mean, Alan? It's not just a jolly off to America. You're actually going to do something. Is that right? Yeah, yeah, I always do something.
I feel like you're doing a lot more this time. That's what I was leading you into.
Well, I didn't. Am I doing more? Yeah, maybe. I got proctoring four of the labs around Defender for Cloud this time. I think last year they didn't have labs, did they? It's a good question. Maybe they did have a couple. There's definitely a lot more. There wasn't many security ones. This year there is. There's loads. So, yeah, I'm proctoring those. So I think last year I did proctoring for the pre day session and then was on the stands on Defender. Cloud stand twice. This time it's just the Wednesday and Thursday.
Okay. So you're just doing more of one thing, basically. Really? Yeah. So, yeah, it probably. Is it more time? Don't know, it's. It feels. It probably feels about the same because I'm doing two things in the day as last time it was only one. One session every day plus the. The pre day. Yeah. So I will have some more time to work in between things but also go to the event. So. Yeah. Should be fun.
Yeah. I feel like there's a lot more partners going this year. I see lots of like, hey, are you gonna be ignite LinkedIn sort of posts. You Know. Yeah, yeah. It's because it's merged, doesn't it, with the inspire in effect, so. Exactly. So we'll be. Will be interesting. Yeah. Not packed yet. Not even rethought about the travel. The travel's all configured. All configured, all booked and everything around. A terraform script and it. Yeah, got everything.
Yeah. Should probably. Should probably have some automation around it because it's pretty. Let's rinse a repeat to the airport anyway, get the coach, stay in the Moxie Hotel and then go the next day, whatever. So. Yeah, yeah, it's all booked and everything. She need to catch up with a colleague, Ben, who's joining us or joining me. Going over just to make sure when we're gonna. I think we're on this. We're on the same flight and everything. So we're work out what we're doing when we. We get over there and stuff.
Nice. Should be good. Should be good. Yeah. So, Sam, what is this week's episode? Yeah, we're going to talk about DevOps security, I think sort of more prevalent and important as ever. So, yeah, there's some really good tooling in and around Defender for Cloud's offering. So, yeah, I thought we'd cover that this week.
Yes, definitely. It's been maturing, hasn't it, in that space. So I guess, I guess probably what we need to start is from the. From the start and I guess, you know, what is DevOps security? Yeah.
Okay. So I suppose I'll start off with a DevOps 101. I suppose. Just started off really. I suppose. Yeah. So DevOps or developer operations is a process in which you. It's a software develop, it's typically a software development process, but it's actually, you know, bigger than that now. But, but essentially if you, if you imagine your development teams are building software and infrastructure solutions and I don't know, let's say, let's say you're a B2B SaaS app and you're building your application and you need to get that code to your web server somehow or, you know, some past solution for hosting it. So DevOps is a way to sort of create like a pipeline in effect to process that code. So, you know, developer writes the code and it gets committed into their source code repository. And then there are processes there to first, you know, verify this might be human or automated to verify the change has been made correctly, you know, sort of some element of qa and then you need to get that code out somehow. You know, maybe it'll go to your Staging environment first to give it a test before you go to production. And DevOps. The concept of DevOps is that sort of iterative process and also the automation that runs alongside it. So instead of taking that code and compiling it and then, I don't know, FTPing into your web server to copy the files up there, sort of DevOps and pipelines really starts to automate that process. So once it's been approved or somebody's committed or checked in the code so they submitted some new code, the idea is to create a pipeline that deploys that automatically for you. What that then means is your development teams and your infrastructure teams become more efficient because they're not sort of manually handling, you know, code or compiled code and having to log on to external systems and do those upgrades. You know, the idea there, you know, sorry, the idea there is to automate that and then there are going to still be tasks that maybe have to be done manually, but you're looking to automate that as much as you possibly can now with that sort of power. Does open up some security challenges, should I say, because there's more and more automation where you connect These sort of DevOps and source control repositories to your potential, your production environments. You need to think about how you're controlling that, not just from verifying who is doing what, but also making sure that code is as secure as it possibly can be. So DevOps security is really looking at that process end to end to understand where you can essentially layer on automation to make that process as secure as possible. So, you know, it's sort of a process and a control mechanism that sits on top of DevOps. Now, in smaller organizations, your developers are likely to also help with infrastructure. You know, in really small startups and even in, well, even in some bigger teams, developers do move into infrastructure as well. So what we want to do is we want any security checks that we can automate to be done as early as possible in the software development lifecycle. Yeah, if somebody makes a change to a piece of software that makes it less secure, you want to know about that before it hits any of your production systems, really. So there are a bunch of, there are a bunch of tools and processes and we'll talk about it in a bit more depth. That help you to understand the changes that you're making and the impact they may have further down the line.
Okay, yeah, so I think you kind of touched on. That's good to know about the overall DevOps side of things as well as sort of the security on Top. I was thinking you kind of touched on it, this kind of. Well, my view of DevOps kind of usage of it anyway is that you've got the applications, the code kind of thing, that side of things from a DevOps part, but then you've also got infrastructure deploying infrastructure in, you know. Yeah. You know, in the clouds or on prem. I suppose in theory.
Yeah, yeah. And let's, let's actually just touch on that actually, because that is a, that is a good distinction now is that DevOps primarily was a, like a development type activity. Right. But more and more now with sort of the rise of let's call it infrastructure as code, Terraform, bicep, ARM templates, whatever, open tofu, whatever your flavor is there, doesn't really matter. It's all the same concept really. But we now have this concept of infrastructure as code. So where you define your infrastructure in some sort of configuration file and you deploy that and your cloud provider provisions all of that infrastructure or makes changes to that infrastructure on your behalf automatically so you don't have to click through portals. You can define your infrastructure, make it repeatable, you can have visibility and check that infrastructure. So you know the impact of this and why does, why does it actually, I suppose DevOps security really matter is that you can have real lasting consequences from it. You know, if you had a bagged actor that deleted all of your infrastructure from your infrastructure as code files and was managed to get that through your change process, then you could in theory have your cloud environment destroyed, you know, instantly. Because your infrastructure as code provider is going to go, oh, you don't want these resources anymore, I'll clean those up for you. You know, good job, good job. And that's a pretty sort of dark and sort of scary example. But, but what I'm trying to get at is, is that there are real impacts to what you are deploying. And everybody, I think everybody knows this, but if we can have tooling in and around that, that helps us with that, that that can only be a good thing in, you know, in sort of my opinion.
Yeah, so I was thinking about this, this as you sort of. You're talking about, we want to know when some, there's a, maybe a security issue or a misconfiguration within the code, the infrastructure's code, etc. Before we push out to production, staging, etc. And I was thinking around, you know, we're talking about automation to save time, aren't we, at this point that we don't accidentally misconfigure it as we deploy it manually or upload it, things like that. So kind of push that problem then into I guess the code at that point. Really that's probably fair to say especially around infrastructure as code that then that needs to be checked because in effect we're just trusting that what we're building and this is like worst case scenarios as well kind of thing because developers will check code, but it's, I suppose it's showing that we need to do that check because you know, like you said, if it is not to say blindly uploaded and approved it, then the systems on the other end that's deploying is just going to do it. They're not going to question it, are they?
No, exactly. Because those automated systems are just doing as instructed. Right. So yeah, it's really putting those gates in place for verification and testing, you know, because if you would traditionally sort of click around the portal to deploy infrastructure, you know, have you followed every process correctly, have you checked every box, how can you sort of verify that you have configured, you know, against your specification? You know, it's, it's a lot less controlled than it is in infrastructure as code. Now I have to balance that argument in some respects because you don't just learn infrastructure as code overnight. It's something that you have to approach and learn and invest your time in. But there are a lot of, you know, upsides to that, you know. Yeah, sorry. And the only other part that I was just going to talk about is just how privileged. It's going to come out the wrong way, how privileged developers are in terms of that typically their administrative rights and the access that they have, you know, typically developers, development teams or sort of infrastructure analysts as well will have access to, you know, they could potentially have access to your source control, source control repositories. They can access test environments, potentially production environments using credentials. You know, they, because they build these build processes, they have the ability to modify them. So putting good governance around your sort of DevOps process is really important because these users are very, you know, have high levels of access typically into environments and they are very trusted because they build and develop intellectual property for the business.
Yeah, yeah, absolutely. I guess this comes back to the sort of DevOps side rather than the security bit in some form that especially, I mean we're talking about infrastructure code really. Well, I am anyway. But you can have, you know, read access only to that, that environment and still deploy stuff and not have the, oh well that's, that needs fixing. I'll just change it there and it's it's, you know, there's. Oh, what do they call it? Like Scope. Not they say Scope creep, but war. It's not even warping. I can't remember what it is, but there's a difference from what should have been deployed to what there is. And it's like, yeah, okay, I'll document that later kind of thing. And then it never gets done. Rebuilds, things like that, and then you don't miss it kind of thing. So yeah, yeah, yeah.
Friday afternoon, you know, apps down or infrastructure's not working correctly, you know, I'll open that firewall port temporarily just to get it working, you know, because X, Y and Z and it never gets closed or some other variant of that type of, you know, pressured environment. Right. So we do need a way to sort of, you know, keep as much control as we can. We reasonably can, I should say.
Yeah. Okay. So there's some tools out there to help with DevOps security. I'm assuming we're going to be talking about defender for cloud DevOps security. So you give us an overview of that.
Yeah. So Defender for Cloud is a. It's probably best to call it a suite of different solutions. Right. It's. It's sort of its own mini ecosystem, isn't it, of Defenders. But Defender for Cloud primarily is a, a cloud posture tool, but also a cloud workload tool as well. So it doesn't just look at, you know, how secure your actual environment is, but it can monitor your environment at the same time. And DevOps security is part of Defender for Cloud. So it sits within, well, the. Okay, so the configuration of it and the reporting that comes. Some of the reporting that comes out of it, I should say sits within Defender for Cloud. That is where you configure it and that's where it sort of lives. The big benefit of that is if you are utilizing Defender for Cloud and then other wider Microsoft security tooling, you have one singular sort of mini ecosystem. This is not. It is a separate tool, but it's within sight of your sort of Microsoft ecosystem. So you get sort of a unified view of your cloud environment. So you're not just thinking about Defender for Cloud might be looking at your storage accounts, your virtual machines, your databases, but what's running on them is also critically important. And what is configuring them, you know, as we talked about as infrastructure, as code is really important as well. So bringing all of that unified visibility into one place is really important. So it sort of sits all within side of that area. One area that is a real big focus for defender. Sorry, DevOps security is around looking at infrastructure as code templates and container images to sort of minimize misconfigurations before they reach production environments. So you know, if you've got a, I don't know, let's say, you know, all virtual machines shouldn't be open to the Internet. They should. They, you know, they should have to pass through access, should have to pass through a firewall. As an example, you could look at a misconfiguration in your infrastructure as code files and say, oh, why are you assigning a public IP address to that virtual machine? Why on its network security group are you allowing certain ports through those types of checks that you can do automatically? You know, there's, there's posture built in and we'll talk about some of those tools, but also you can define your own sort of policy in place of that as well. And also not just, I've just talked about infrastructure at the moment, but also the code itself. So things like one big area that is always a challenge for developers is the use of third party libraries inside their code. We have sort of, every now and again we have sort of relatively big incidents of this where you know, a reusable developer library of vulnerabilities found and then, you know, all of the applications that use that library also have to be patched. You know, they're not the, well, maybe the code. Because if you've got a version of what was the big one, log 4J as an example. So log 4J version. Sorry, I can't remember. It's a few years ago now. Version 1.7 random is, got a critical vulnerability in it. 1.8 has been patched. So you, you as a development team need to go through all of your applications that use log4.J and upgrade your package from 1.7 to 1.8. Now between 1.7 and 1.8 the package could have changed, you know, the functions that are available to you or the way that you call them could have changed or their behavior could have changed. And that can cause a real headache for development teams because they then have to, maybe not always, but sometimes they have to re engineer their applications to work with these new upgraded packages because of a security issue. So you need to know about that as soon and as quickly as you possibly can. And you also need a way to attest and verify that you've actually done that change as well. So you know, when, when one of these, you know, these vulnerabilities lands, you can make your fix and then you've, you've got a red light that goes to a green light once you've actually done the change and you've got, you know, confidence that the change that you've made has actually worked retroactively. And also, if that was to happen again or you regressed and somebody went, oh, it's not working properly, I'll go back to 1.7 in my example that, you know, the siren then fires again. So you've got that automated checking all the time, essentially.
Yeah, cool. Yeah, we've, I think we've had a little bit of a play with it in various integrations, things like that, to see how valuable it is with our infrastructure code, I guess. I think you kind of talked about this a little bit just now, but I guess, how does it work? How do you kind of set up?
Maybe, I guess, yeah, let's talk about how at a high level and then we'll go into actually setting up afterwards. So at a high level, what you do is you connect it to whatever source control. Well, no, not whatever source control system, because only certain ones are supported, but you connect it to your source control tool of choice. So today that is Azure, DevOps, GitHub or GitLab environments, essentially. So you say to DevOps security, this is where my code lives, basically. And you create what's called an environment for that. And then once you've done that connection, that's like a server side sort of API process, you then start to get findings that come out of that environment. As developers commit new code, sort of hooks are injected, hooks are injected, and statuses and alerts can be fired back. They can be fired back in two places in the Defender for cloud portal, where you can see alerts, configuration changes that you should make and that type of thing. But you can also do pull request annotations. And pull requests are a way for development teams to say, hey, I've got this new code. Alan, can, I'm going to raise a pull request. Can you check my code before we push it live? So that's like sort of a collaboration and a QA sort of process that people go through. But what's great is when you commit some code before. So let's say, Alan, you make a change to an application, you open a pull request, DevOps security can fire at that point and it can check all your code before I've even seen it. And then when I get there, I can see the results of that, essentially. So I can say, hey, you know, DevOps Security has been through here. DevOps Security is happy with Alan's changes. Now that doesn't mean to say that you can just skip all your QA process then and you know, you're off to the races. But it's another signal, isn't it? You know, it's another sort of process looking at what you're actually doing sort of day to day.
Yes, I think, actually think about that. It's kind of two ways of a benefit here. Like how I see it in that one is you're checking the security, the posture of the code or the IAC infrastructure as code. But you're also saving potentially some QA time because you might, it might be a requirement that you have to be able to pass that security review, in effect, the automated security review before someone from qa. QA is the code basically because at least then they know from a security perspective it's okay. There may be some recommendations from the security code, but there may be a requirement for you to have a certain, I guess a certain configuration, you know, to ma because you need to have it, you know, it configured in a certain way. And that's been accepted. I guess so, yeah. And I guess you've kind of talked about this actually is the integrations, you know, we've, you've effect push it into that pipeline. So they give you those annotations, things like that to give you, give it, give you that information before the code goes up to the location. It's going to depend on the pipeline.
Yeah, yeah, exactly. And once those integrations are in place, they are completely automatic, you know, you don't have to configure anything else or do anything else day to day.
Yeah, no, that sounds, it sounds kind of, sounds simplistic in some form to get that sort of, you know, the way you've explained it, you hook it, you create the connection from Defender Cloud to the, to the currently supported code source locations and then maybe do some configuration in your pipeline and then it affect your gonna say wreaking the benefits from it straight away.
Yeah, it's not, I wouldn't say it's that challenging to integrate, you know, it's, it's designed to slot in and yeah, just start working really, you know, because typically those code repositories are going to be cloud based now anyway, you know, because developers typically want, it depends what industry you're in. You might be in a regulatory, you know, a regulated industry where you can't do this, but a lot of people want that sort of intellectual property backed up, you know, in a, you know Azure DevOps or a GitHub, you know, equivalent essentially.
Yeah. Okay. Okay. So from a detection sort of perspective, using DevOps security, what the key things you should be aiming to detect within the current stuff. I guess you kind of talked about some of this again.
Yeah, let's just go through them and be sort of a bit more direct on the types of things that we're looking for. So one sort of big area is security recommendations for code vulnerabilities. I do need to sort of. There's two sides to this. Okay. There's the Azure DevOps sort of extension for this and that is essentially a collection of open source tools. Okay. So there's things like TerrAscan, eSlint, Checkov, Anti Malware Protection bandit. So there's, there's multiple different, usually open source, but there are some closed source ones there as well. And that is looking for actual code specific issues but typically it's what we call linting or verification. So it's not looking at the lines of code but more around how your code, what your code is using and sort of how it's structured more than anything. Okay, so I would call it like, I would call it lightweight sort of code scanning really. Okay. There are other tools out there that are more detailed than that. So things like DevOps, advanced secure GitHub, advanced security that actually can go down to the code level and what that can do is that can scan for specific, best way of being describe it specific vulnerabilities in the way that you write code. Okay. So think about the sort of lightweight extension more around your third parties, how it's structured, that type of thing. But advanced security can go down code by code and you can do queries on the code to look for things like SQL injection, cross site request forgery, those types of actual more detailed code specific changes. Now if you have that, you need to, I believe you need to be on GitHub Enterprise and that has to be integrated sort of separately. So if you want to run your linting, you want to check your IAC files, then you're all good on, you know, DevOps, DevOps security. Secret scanning is also really important. We've seen this sort of time and time again. It typically happens with public repositories, but you know, developers not using environment variables and leaving hard coded secrets in their applications. It happens time and time again. There are bots that scan for it. So there is also a system to search for expose secrets in your code. We talked about this a little bit in terms of open source vulnerabilities so these are your third party, third party sort of libraries that you integrate with. And then yeah, we've talked about infrastructure as code as well. But also there are security and posture recommendations around the DevOps environments themselves and misconfigurations there. Think things like creating publicly accessible git repositories where your code is held. You know, if you don't have a policy in place on Your, in your DevOps environment for that, you could get caught out by that by accidentally, you know, exposing that type of information. And also containers are also a big part of the visibility that you want to see. If you've containerized your applications, which are like of micro virtual machines that people use now, lightweight containers that they package their applications up into. You always base your container on some sort of public container. So if your application runs on Ubuntu, you'll use like the Ubuntu Slim image as your base and you'll build on top of that. But what if there's a vulnerability in that specific version that you've based off of also that is sort of a third party dependency that you, you need to manage as well. So there's a lot of different areas that you're looking at there and you can go deeper as well with more advanced sort of code level view as well.
Wow. Yeah, there's definitely a lot that it's checking. I think the, the secrets scanning is like you said, a quite a good one to have because it is one of the things that probably get missed time and time. Yeah, yeah, exactly. Yeah. Okay. So I guess the question everyone loves is, you know, how is this, how is it licensed?
Yeah, so it's actually licensed as part of the cspm, part of Defender for Cloud, which I think is interesting that they haven't kept it like separate, if that makes sense because it was, it was in preview for a long time, wasn't it? And it was effectively free at that point. So there is, there is an element of functionality and foundational cspm, but things like pull request annotations, container mapping and then other benefits that come as part of Defender CSPM are integrated or already enabled at that Defender CSPM tier. So a lot of the security recommendations, you can do it foundational CSPM as well.
That's interesting because I didn't know that. Yeah, well, when I, yeah, when I looked at the pricing this, when I didn't actually really realize it, that it was actually included in cspm. So I assume that a, an environment is classed as a resource in CSPM and that's how it's integrated. But there can be some challenges there about scoping that and how you scope that. Because, yeah, enabling CSPM can be a bit of a challenge, especially if you got a lot of resources.
Yeah, absolutely, yeah. I knew it had gone moved into from being a separate product with it or workload within Defender for cloud into Defender cspm, but I didn't know there was any capability that was in effect the foundational.
Yeah, there's quite a good table in the documentation, actually, which shows, in the documentation there's a support and prerequisites page and it shows you sort of where the cloud and region support is and where the features availability is across Foundational and Defender cspm and what other prerequisites you might need. Because some of the, some of the tooling requires GitHub advanced security for Azure DevOps. So you also need to think about that as well.
Yeah, okay, cool. So, yeah, you can start off some, some of it for free in air quotes or include generally in what you're doing and then you can enhance it as you get, as you, as you feel the need. So I think it's really good.
Yeah, yeah, exactly, yeah. And you do need to look at, if you want to use some of the, that functionality, you need to think about licensing on the GitHub side as well. If you want to bring advanced security in and I believe that is only GitHub Enterprise. Just give me two seconds, I'm just going to validate that. Yeah, it's just GitHub Enterprise now. I do believe you can license GitHub Enterprise on, on smaller teams now. I think you can buy it. You used to have to have a minimum of like 25 seats, something like that. So that's just another call out that this is intertwined with GitHub security, advanced security as well. Some of the features and functionality I've talked about. So it's, it's not probably 100% valid to say you can do. Let me just give you a list of stuff that you can actually do. Two seconds. I'm just going to get the right page open so I'm actually talking about it properly. Sorry, two seconds.
Yeah, sorry. So, yeah, in effect you're saying that you do get a lot of functionality with the integration and yeah, some of the more advanced stuff in Defender cspm, but if you want to do some other more advanced stuff, there's, there's the extra license.
So I think you're going to get, you're going to be able to connect your DevOps repositories in foundational with no prerequisite. You can look at security recommendations for those DevOps environments in terms of CSPM and I think you can also do infrastructure as code on that as well and also code vulnerabilities that that Microsoft Security DevOps extension, not the GitHub Advanced Security one, but the sort of open source version of the security DevOps extension that does say that you know that there is a tick in foundational CSPM for that. But you can't do things like pull request annotations so you can't have it live run. The data has to flow back over to the other side into Defender for Cloud. So it's not quite as slick basically to do that, but you can get some level of coverage there as part of that.
Yeah. Okay. Because like things like. Sorry, the things like discovered secrets are GitHub advanced security. So you can either an enterprise plan there to enable that type of functionality. Right, okay, yeah, that makes sense then. Okay, cool. Is there anything else, Sam, you can think that we've missed or anything like that? I think it's a great tool. It seems something almost seems like a no brainer in some form. Fairly starting.
Yeah. It is worth calling out that we've spoken about Azure, DevOps and GitHub quite a lot, I suppose, but GitLab is also supported. The only thing I would say is you do need GitLab Ultimate. I've never done this before, so I'm just. I'm reading from docs here. You need GitLab ultimate in order to enable. So there's no foundational CSPM functionality unless you've got GitHub a GitLab ultimate basically. And if I want, if I want one. Oh yeah, ultimate is $99 a month, so it's quite expensive.
It sounds expensive. So yeah, just ultimate, right? Yeah. Which version do you want? Do you want just premium for $29 a month or do you want Ultimate? By the way, your competitors have got Ultimate. Yeah. Cool. Okay. Well thanks for that, Sam. It was really. I think it's a really good sort of overview and dive into defend for Cloud's DevOps security side things. We do talk about DevOps occasionally, don't we? So yeah, it's good to see the security side of it.
Yeah. And sometimes, you know, if you're sort of a security professional, you might want to layer on this type of protection alongside your development team. So if they are using a supported piece of tooling and they've got the license or you know, you can procure whatever it is that you need. It's relatively easy to integrate and doesn't really affect their workflow. You can get visibility without causing too much disruption.
Cool. Okay, so next episode. So we will be missing next week, the week of Ignite, because. How dare you.
I'm away. Well, well, I think we've tried once to do it. Yeah. And I forgot parts of my stand and stuff. I think at one point I was just holding the mic in my hand because it. Bring it. You don't know t. You're already there, dear. Yeah. So we're gonna leave next week, but the week after, we're then gonna do an episode on Ignite and any other news that hasn't been announced at Ignite. We were going to try and do another episode on something. I was going to do another episode on something or try and do Ignite on its own. But then I expect all the announcements going to come out of that. So. Yeah, we'll do that. And then we're. And then I think we're pretty much into the end of the month anyway, aren't we, Sam, when we do that? So.
Yeah. And then. Yeah. Cool. So did you re. Did you enjoy. Did you really enjoy. Did you enjoy this episode? If so, please do consider leaving us a review on Apple, Spotify or YouTube. This really helps us to reach more people like yourselves. If you have any specific feedback or suggestions on our episodes, there's a link in our show notes to get in contact with us or you can leave a comment on our YouTube channel. Yeah.
And if you have made it this far, thanks ever so much for listening and we'll catch you on the next one. Yeah, thanks all.