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 one of season four. Alan and I had a discussion around Defender for DevOps recently. Dev, SecOps and SEC DevOps are becoming increasingly important as teams shift to a continuous integration model for development and a shift left in responsibilities for code and infrastructure security. Here are a few things that we covered. What is DevOps? Why is Dev SEC Ops and SEC DevOps important? Which platforms are supported by the product? What insights, security insights can be shown from the product and how it integrates with your process. One quick ask is that if we've noticed that a large number of you aren't subscribed yet, if you do enjoy our podcast, please do consider subscribing. It would mean a lot for 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, Ellen, how are you doing?
Hey, Sam. Not doing too bad. How are you?
Yeah, good, thank you. Starting to get very warm here in the UK. So yeah, it's been very nice to finally have the start of our summer. Anything exciting been happening with you?
Not necessarily. This week it's been very busy. We've done a little bit of traveling this week, haven't we, around the country for various things. And next week I'm in London at invosec Europe, and I'm actually doing a talk on the Microsoft stand.
Nice.
Wednesday.
What are you doing a talk about?
It's mainly around Defender Cloud. The title of it is unified Cloud Security Posture Management. So I think that's at 1235 on the Wednesday. Nice.
Yeah. So if you're in London for infosec, definitely go in, listen to Alan's talk on the Microsoft stand. That sounds amazing.
Yeah, it'll be shorter than one of our podcast episodes.
Yeah, exactly. Well, they won't let you ramble on on stage, I suppose, will they? So, yeah.
You been up too much this week or anything exciting?
Not so much exciting, I think. Just preparing for this next season of the podcast, obviously getting things all set up. So, yeah, it's been exciting. We've had a couple of weeks break, so yeah, it's good to get back to it, definitely.
Okay, cool.
Yeah. So this week it's Defender for DevOps. Relatively new product, but I think it's worth definitely reviewing it. It's got some really good features, so yeah. Should we jump into it, Alan?
Yeah, definitely. So we should probably start off with some high level initial things around DevOps. So can you explain what a little more around? Well, explain what DevOps is and why it exists and what does it serve to help us developers and things like that.
Okay. Yeah. So it's definitely worth doing a little bit of a brief backstory on DevOps. So DevOps is sort of a software methodology principle around making the deployment of software as streamlined and as efficient as possible. Traditionally what you might do is you might say have a developer that builds an application, let's just use the example, working example of a web application. They might compile that application. And traditionally you might have logged into the server, maybe you would have like FTP the files to the server to overwrite your latest update. And a lot of those processes would have been done manually traditionally. And DevOps has really sought to automate a lot of that process. So developer writes code, checks in code to some sort of source control system. Nowadays that's usually git. And when that code is published into some sort of system, let's say GitHub or Azure DevOps as a couple of examples, there's lots of them out there. Then processes, you might have called them runners, pipelines, actions will then trigger to validate, to build that software, to validate it, and then ultimately to deploy it to your systems automatically. And what that really means is, traditionally the developer has not had to worry about the build of the code anymore, of the deployment of the code. That responsibility has shifted into a new set of skills. And that's where we've had traditional DevOps engineers who have helped to automate that build process. A lot of the time those builds are done in the cloud. Now, some organizations you can do DevOps internally as well, so you can run those systems internally as well. So yeah, you go from code to deployment in a lot more streamlined way, basically.
Cool. So it kind of sounds like if you were doing rinse and repeat actions that you may have to do multiple times, that you make sure that it's right every time. You're not having to accidentally misconfigure something.
Which yeah, and it might not be like the compiled binary. That's the problem, right? Or it could be you might upload a binary with debugging symbols still embedded in it, or a non optimized build. Or for instance with your application, you might have to send up a config file with it and maybe you've got a config file that's for development, one for staging and one for production. And us humans are inevitably humans and some mistakes can be made. So the idea is to automate a lot of those processes to try and take out some of that human interaction, makes it more efficient, makes it more accurate, and ultimately it allows us to ship applications in code more regularly. It's also worth pointing out, even though it's called DevOps, like developer operations, DevOps principles are also used in the building of infrastructure. We've had lots of episodes on infrastructure as code. So even though it's more developer and application focused, other types of disciplines are also using these processes to make their lives more efficient. So traditionally, if you're an infrastructure engineer, you might go into the Azure Portal and you might click click and you might deploy your resources and configure your resources. But now with the growth of infrastructure as code, what you can do is you can describe your resources into a file and you can let a tool like TerraForm Azure Developer, CLI, Bicep, Arm, there's many different flavors. You can use those tools to allow you to then deploy that infrastructure and to track the state of that infrastructure as well. Won't go into that because we've got lots of great episodes on infrastructure as code and how that works. So check back for those. But really, DevOps is the automation of that process. It doesn't matter if it's applications or infrastructure, you really want to automate as much of that as you possibly can now.
Okay, great. Okay, so I've heard of DevSecOps and SEC DevOps. What are they and what do they bring to DevOps?
Okay, so those two terms, dev SEC ops and SEC DevOps are kind of the same thing, but they are moving effectively shifting security responsibility to the left, right? So traditionally security would have been you would have to rely on developers to update their code. If they're using third party libraries to track which libraries they're using and which ones have got vulnerabilities, that's just a really basic example and sometimes that used to get missed and making sure that whose responsibility a lot of because there's security at the application and code level, right? It's not just infrastructure security and hardening at that. You can have the most secure infrastructure in the world, but if your application has a remote code execution vulnerability in it, it could be that your firewall isn't going to save you. I mean, firewalls are a lot more sophisticated nowadays to looking at those common types of application attacks. But really, security should start at that code level to start off with. So what we've seen is we've seen a shift to the left. So if you sort of break up dev SEC ops as three different stages, you develop something, you secure it, and then you pass it off to operations to run it. So traditionally it was just DevOps just straight from develop it's, just delivery. And then we had dev SecOps. And this is really what Defender for DevOps really is, because you've done your development, you then run a tool on it such as Defender for DevOps, which is your SEC, and then you pass it off to operations. So you're sort of validating your build, you write your code, you upload it, defender for DevOps checks it, and then should it pass, then effectively it gets handed off to operations, it gets put into production or deployed basically. But SEC DevOps shifts the dev and the SEC, if that makes sense. SEC comes first. And really that's sort of the Holy Grail, really. Actually, the Holy Grail is SEC dev SEC ops, really, because you really want to be doing that. Security awareness as developers are actually developing. Now the timeline of this is a bit mudied because there's different types of security tooling at different parts of the process. So you've got security tooling within side your integrated development environments, you've got security tooling inside of your DevOps software as well. So really to me it's a combination of all of those things. Obviously, operational security is still really important, right? But ultimately everybody in that chain needs to have some level of responsibility, don't they? And also we need to have visibility at all as many of those parts of the chain as possible. Because if we can catch something like a third party library that you're using that's got a critical vulnerability in it, I'm thinking log four J here, right? We'll call that one out. You want to catch that as early as you possibly can as you're developing because ultimately development of applications especially comes in waves. You might roll out a version of software and it might be three months until you hit that part of the code base again and you could just within that time, let's say there's a vulnerability. It's a very simple example, but it's a very real example. Your dependencies go out of date, you pick up some vulnerabilities. Now there's tooling that you can run on your machine to do that, to find out about those. But then what we could do is we could bake that into our DevOps pipelines to basically do that checking and have a second pair of eyes basically to do that as well. So in theory they are two separate methodologies and we're talking about shifting security as far to the left as we possibly can, but ultimately in that process you want security layered in at every level. Really. Yeah.
Okay, so I guess like you said, I guess sort of in the past, security has always taken a back step or been at the back, hasn't it? It's been build everything, get it working, things like that. And then maybe security is checked. And we've seen that in a lot of areas, it's not even just in development beforehand when we've built potentially you're building networks, things like that and this is bringing it into that process now and it's almost becoming, like you said, to the left, front and center doing checks as that process as it goes through that process.
Yeah. And we've seen, I think we all understand how much more sensitive data is being processed by these systems nowadays, right? So many systems are digitized and cloud migrated now and interfaced over multiple networks, right? So yeah, as sort of that we call it like an explosion of data and the sensitivity of it has increased. We now have to layer in more controls over the top of it. But what we've traditionally had is we've had maybe security tooling that has interfered potentially with put up barriers and roadblocks. Right? And I think what a lot of these tools are now trying to do is to give you insights and visibility, but maybe not block. You can configure how these tools run and we'll talk about that in a bit more depth. But what we do know is that the most secure organizations and applications think about security as far left as reasonably possible, right? As close to the source as well. Because if you're the developer, Alan, it's much more highly likely that you can spot a SQL injection attack inside of your code before the Ops team can. Right? Because the Ops team, the code to the Ops team is a black box. You know how that works. But if you had something that could help you look for threats inside of your code base, you could start to see that emerging before it even gets to an Ops scenario.
Yeah, okay, that makes sense. Okay, so you did mention Defender for DevOps in that, in that, in that question. So what features are supported for Defender for DevOps in this dev SEC ops.
SEC DevOps process just layering security everywhere. Okay, so the main three things that Defender for DevOps is trying to give you is the firstly, it's trying to give you visibility into your security posture within your DevOps. I'll call it environment. Right? We've talked about this internally about how secure should pre prod systems be staging systems, right? Do they actually store sensitive information? At what point do you start to think about this? Do you start to think about this between pre prod and production? And what it's effectively doing is it's scanning your code and looking at your dependency trees for vulnerabilities. So there's a bunch of open source tooling that Microsoft has brought in that allows you to effectively automatically scan your dependencies within your application. For instance, let's say you've got a Node JS app and you've got a bunch of NPM packages that you use. And one of those NPM packages has a critical vulnerability inside of it that's got like a published CVE. Potentially it's going to automatically scan your dependencies for you and then tell you about recommendations about when it sees those items. Now, developers have been able to run security checks locally. So like for Node JS, their package manager is NPM that we've just spoken about. And there's a command that you can run to basically show you show vulnerabilities in your NPM dependencies. But you have to write that in the command line so you can do that. And as long as your developers are proactively, maybe they have like a monthly check that they go and do to look for CVEs and to go through that. But what Defender for DevOps can do is it can do that searching directly in your pipelines. So you add an action or a task to your pipeline and it'll effectively do that scan for you every single time. Well, it's up to you how you configure it. But in theory, every time you commit new code. You could do that scanning for you, or you could maybe do that as a validation before you hit a different branch. So you could say, as a final check before we go to staging, we're going to do a check for vulnerabilities inside of our dependencies. That means that you are not relying on developers to do that work that's now orchestrated by these systems. And it gives you visibility across potentially all of your repositories as well. Because in my example of, say, alan building software and deploying it, we're just talking about one developer. You could have hundreds of developers, you could have hundreds of repositories of all different systems that you have to track, and Defender for DevOps will scale across both of them, taking it a bit slightly different and talking about infrastructure. Part of that tooling is looking at infrastructure as code templates and container images to look at cloud misconfigurations reaching production environments. So it might be that you configure a virtual machine that isn't behind a firewall or whatever security misconfiguration. Maybe some ports are opened, maybe it's not encrypted X, Y and Z. I won't go through all the different misconfigurations that it can report, but a lot of that checking can now happen before you even deploy it. So before you even get into Defender for Cloud, telling you that you've done the wrong thing after you've deployed it, which is really valuable, don't get me wrong, but it's kind of a pain to remediate at that point. It can be a pain to remediate at that point, especially if it's infrastructure related remediation. So let's shift that left. Let's get it as close to the development team as we possibly can and highlight those issues as soon as we possibly can. And then what Defender DevOps is then going to do? Is it's going to integrate with Defender for Cloud? It's effectively, like I think we've described Defender. It's like Defender Cloud is like just a collection of other defenders, right? It's like a bit of a beast, really, because it's just a group of other no, it's not just a group of other defenders, but there's lots of other defenders inside of it.
You're talking about the protective workload to that point, aren't you?
Yeah. So Defender for Cloud gives you the visibility and the prioritization, right? And it gives you the interface to that. But Defender for DevOps is like one of those other workloads really inside of Defender for Cloud. But what you're going to get is you're going to surface these recommendations inside of Defender for Cloud and it's going to help you to prioritize those recommendations as well. It's going to give you guidance on what it thinks you should look at and give you severity, but also it's going to give you that single pane of glass view across your infrastructure with Defender for Cloud and all of those other I don't know how many there are, Alan ten, maybe. I can't remember the exact number?
A few now.
Yeah, let's call it multiple double digits. Other protective workloads, including CSPM, and it's also going to layer this in as well. So you're going to see it all in one place. There's not another SEC DevOps portal that you've got to go and look at. Teams have one unified place to look at these recommendations as well.
Cool. So it definitely sounds like sort of from my security perspective, I guess it's kind of like it can help with the dev SecOps part at least as well. That methodology is like a catch all. We're checking everything that goes through that's going to go to potentially to production, things like that. That you're right. There are tooling out there that the developers or developers or pull request people, creators of pull requests, but reviewers of pull requests could go and check the code. Sorry, that's what I was trying to get, that maybe they don't have this in that they can go and do the manual checks, but it's based on them doing it as religiously and things like that and how often, et cetera, this is doing automatically. They don't have to necessarily worry about it. They can still do those pre checks if they want to. So when it goes through that bit, they're ten out of ten kind of thing. It's not removing that, it's just making sure and monitoring or documenting that it passed it.
And a lot of that checking is busy work. Right. It's like pulling the code down, running a command on it, and then somehow sharing the results of that with the rest of your team. Right, exactly. What do you do? You then jump into DevOps boards or Jira and then start creating tasks and tickets and all of that sort of stuff. Right. Defender for DevOps is going to help you to automate a lot of that.
Yeah, exactly. And from a security perspective as well, from CISO or security analyst or security engineer, yes. They can go into DevOps and be part of that, whatever DevOps tooling you're using, be a stakeholder, things like that, looking at what's happening within there. But like you said, you could then got this single place in Defender Cloud where they don't have to have access to that. It probably is best practice that they do, I would guess, but it may not. But they got Defender Cloud to be able to see everything from the DevOps side as well as the actual infrastructure. So like you said, if that is not running, you can see it. Or maybe there's extra recommendations since they've done the latest push to production because I guess it's not going to be extremely frequent. Depends how many iterations this product, web app service, et cetera is going. It might only be once a month, might be once every three months of a build. So yeah, I think that's really good to be able to see those results. Things like that or see how good your environment is as well.
Sorry, go on.
I was going to say, I'm guessing that if there were any alerts created for DevOps because I know there's going to be recommendations in there, but if there were any alerts created, I guess it's probably not going to be because it's not an active attack against DevOps. But if there were any instance, then if you had the integration with Microsoft Sentinel, then you'd have alerts in there as well.
Yeah, I think just it folding into Defender for Cloud and how that is structured is one of the most beautiful parts of a lot of those protective workloads. Right. They surface their findings there and then other things can hook in to get access to it. One thing that I haven't mentioned is these static analyzers, which are effectively the tools that run automatically. And there's also one called Cred Scan, which looks for credentials that are baked into your that's baked into your source code. So what can have sometimes happen is when you're testing, you might use like the connection string for a storage account, for instance, because a connection key is.
It called a key?
No, it's connection string. So you might use a connection string whilst you're just testing, and then when you go to staging or production, you might want to put those credentials into maybe a key vault and access them from there so that your actual secrets aren't embedded in your Git repository. Why is that important? Because basically any other developer that has access to that source code has those secrets on their machine at that point. Right. So if you put the production secrets into Git, let's say I do it, I'll use Me Alan, because I'm not doing it correctly, and then you go and pull that code down. In theory, that secret is now on your machine. Now you might, from an RBAC perspective, me or you might not actually have access to the productions, maybe shouldn't have access to production systems. And also if your machine was compromised, then people could steal those secrets and credentials to gain access as well. That's a really great feature. But yeah, there's like five or six. There's things like Es, Lint, terra scan template analyzer, trivia for container images, there's loads of different ones. And there's also anti malware as well from Defender for Endpoint that's added in there as well for checking. So, yeah, really good already. Really good coverage of different tooling.
Cool. Yeah, that sounds really good. Okay, so what platforms are supported?
Both GitHub and Azure DevOps at the moment.
Cool. Okay, so you kind of talked about a little bit about how you configure it, some parts of it at least. So, yeah, can you give us a bit more sort of insight into that? What else do you have to configure to get it all hooked up and things like that?
Okay, so basically you add an extension. You do a connection inside of Defender for Cloud. What that does is it effectively links another is it called an environment in Defender for Cloud? It is. It called an environment. Yeah, it is. You effectively get another environment. Like in Defender for Cloud, you'll see your Azure subscription, your AWS accounts, your GCP projects. You'll also see your connections to your GitHub organizations and accounts, and also to your DevOps organizations as well. We only really use Azure DevOps, so I don't have a lot of knowledge about the GitHub action side, but when I'm talking about how you make these connections and how you actually configure them, it's very similar from both sides. There's just different terminology really, because they're very from a pipeline perspective. So you've got pipelines on Azure DevOps and you've got actions on the GitHub side. They're called different things, but they are kind of the same thing. And it's all Microsoft now. You effectively do your connection in Defender Cloud and you also install an extension into Azure DevOps, which gives you the ability to run different actions inside of your pipeline. So for instance, when you're running your pipeline, what you can say is the first thing you do at the top of your pipeline is, and it's usually automatic, is to check out your Git repository. You could say, right, the first thing that I'm going to do is I'm going to do my scanning, basically, maybe I've got infrastructure in there. So I'll effectively add a step or an analyzer in there to basically scan for infrastructure issues inside of it. So you define that in your pipeline effectively, you can configure it like that and you can decide what happens should that fail. Because some people might say, okay, well, I don't want to fail the build in Dev if I've got a security issue, because it's not actually an issue. Well, it is an issue, but from what I'm doing right now, it's not a problem, is it? It's something that maybe needs for us resolved before we go to a pre prod or a staging system. But we might just want to flag that at that point, maybe in our pipeline to go to pre prod or staging. Maybe at that point we want to put an enforcement in place to say, no, you can't go live, you can't move it to Ops until you've sorted your security issue out and you can configure that. So you can basically say what categories you want to cover and things like that. So it's highly configurable from that perspective. It is slightly different the way that you do that between Azure DevOps and GitHub. But effectively it's kind of the same thing. You'd have to go through and actually configure it yourself on your specific platform to know more there. And then what you can then do is you can enable, pull, request annotations. So what you can then say is, well, once I found these things, report them back to Defender for DevOps and Defender for Cloud to give the visibility there, but also for that developer. Should we annotate the pull requests? If you don't know what a pull request is, effectively it's a request literally for somebody to pull your code into another area. So you're basically saying, hey, I've got this new bit of code that I want to submit into the repository, will you accept it? So I might write some code and then I would open a pull request to Alan because maybe I'll say, right, Alan, I think this is ready to ship maybe into pre prod. Allen might check that manually. That's probably a good thing to do. But that's when these pipelines can then kick in to run things like Defender for DevOps to validate the build automatically. So that's part of DevOps, really. When new code comes in, you'd build it, you'd test it, you'd check it for security issues, and then you get a human to check it as well. You layer on all of that. Add the automation, it makes things really seamless. That pull request annotation is there, I believe that's on both sides, DevOps and GitHub, and that's really going to give you the visibility there and then but also the flexibility on how you deal with those issues that arise.
Yeah, that's really good. I think. So you use pipelinesactions or tasks to get to do all the checking and then when you do a pull request, you have this annotation. So in effect, once it finds a problem with the code or infrastructure code, it actually go and tell you exactly what bits broken. Got an issue within your code, not just, hey, there's a problem with this, the key vault is open and go, great, I've got five of them. Which one do I have to go and find? It's actually going to say, well, actually well, I think I've not seen this work. But assuming it goes off to and goes, yeah, this one is the broken.
One, it will tell you what it's found. Right. But I think the key thing to understand here is that some teams might not want to pull request annotation on. Right. Because it depends whose responsibility it is to orchestrate the remediation of that. Right. So it might be that let's say you're the developer and you've checked in and it just so happens timing thing, one of the dependencies has got a vulnerability. It might be that the team decides that they don't want to tell you about that because they don't want you to go in bump the version number of that package because that could cause other issues, if that makes sense, not security related issues. Right.
And potentially it might not be your part of the code where that vulnerability is as well.
Yeah. So you might want to surface that we'll call it a misconfiguration or that recommendation into Defender for Cloud. And it might be that you then. Start, like some governance rules in Defender for Cloud. Check the Defender for Cloud episode where we talk about governance rules. Right. Because we're not going to talk about that now, but it might be that you start to trigger that then, and you say, who's the repository owner? Oh, the product owner is on Alan's working on Widget One, and the product owner for that is somebody else in Alan's team. So they should be notified of the issue, not Allen. Because like we've spoken about, it might not actually be Alan that's really responsible with going and fixing that in smaller teams. You might want pull request annotation just to go and fix it and just to resolve it as soon as you possibly can. So the main takeaway to that is there is flexibility there for you should you need it. Cool.
Okay. So everyone loves this question. It's normally on most episodes. Do we know how much it costs and how it's sort of cost or licensed, I guess?
Yeah, well, that's the part that I can't give you any answers on quite at the moment, because Defender for DevOps is actually in preview, so it's in limited regions at the moment. So let me get the exact list because I did pull a list of them because that is sometimes quite an issue as well for certain teams. Australia, east central US and West Europe. Right. And it's only in commercial clouds as well. Those commercial clouds as well. At the moment, it's currently in preview, so again, no SLA. It's currently in preview and being tested, but we wanted to do an episode on it because of the value that it can add. And whilst it's in preview, I haven't heard anything about the pricing. Alan, do you have any insights on it? I haven't heard anything about, no, I.
Don'T know how they would I wonder if it's going to be by repository.
Or that's what I assume. I reckon it's going to be I don't know, but it's going to be X amount of dollars per repository per month is my bet. But I've got not less going to.
Do it per run or something like that. And it'd be like a lower cost that's when it's actually taken.
Maybe it'd be like per action step or per task. If you run once a month, it only costs you a real consumption model. Because there is a mix of that in Defender for Cloud, isn't there? There's consumption and then there's fixed, like, resource. It's still consumption, but do you know what I mean? Like run consumption.
Yeah. Per resource, per month or per 10,000.
Transactions per month or whatever. Exactly. We're yet to see that. And just to call out as well, we're also seeing some of the GitHub technology move into this space. I haven't included it into here, but if you've ever heard of CodeQL, a lot of the GitHub, it's not specifically Defender for DevOps, really, but a lot of the GitHub tooling is also coming into DevOps side as well. So if you're an organization that's on the fence of should it be GitHub Enterprise or should it be Azure DevOps, it doesn't seem like they're merging that at the moment. And a lot of these security toolings are being made available on both sides, basically.
Cool. So is there anything else you think of around DevOps? Dev SEC ops SEC DevOps or defender for DevOps.
Yeah, I think the key takeaway for me is that making sure that you're adding some level of security into that workflow. Try and automate that as much as possible to improve your day to day existence and also to improve your security posture. Visibility is obviously really important. A lot of organizations want to do attestation to validate that they've actually got coverage, you know, and to show and have that in one single sort of pane of glass. There are obviously other competitors out there that do Defender for DevOps kind of technologies. So there are other tools in and around that. But if you are Defender for Cloud and you want that singular viewpoint, this is a great way to go.
Cool, great. Well, thanks for the insight. I think that we've gained lots out of it. It's definitely a lot there, as always.
Yeah, and I just wanted to call out if you've missed our previous episode on Azure DevOps. It was season three, episode 19, so actually not very many episodes ago, really. And we did a deep dive into Azure DevOps and Defender for DevOps integrates in with this. So if you are in that sort of world developing software, deploying it, or infrastructure in a DevOps manner, then please definitely go. It's worth a listen, for sure.
Or if you're looking, you've listened to this episode and you think, oh, that's the DevOps. Sounds interesting. Yeah, go and check that episode out. So you get a bit more of a deeper dive into all of the KP. I mean, we've really just in this episode, talk about Pipelines and Git repos.
And I think in that episode we said we just need to talk about the fed of a DevOps on its own because that episode was a bit of a beast anyway. Exactly. So Alan, next episode, I think that's you're you're taking that one. So what are we looking forward to?
Yeah, so I'm going to talk about securing Bring Your Own Devices in an organization, because there is various ways to provide access to your, to your data, to your, to your environment. And whilst previously, I mean, it's been out for a while that you can do quite a lot with Bring Your Own Devices with Microsoft technology, but previously it's always been a managed device. Only if your hardware dies, you can't access your organization, things like that. And with Hybrid working now being quite a thing now, more than work from home, things like that, I think it's worth going through as what technologies can you use to make that be secure, but be quite flexible and maybe potentially reduce costs in hardware, things like that. Because some users might not want to carry two phones around, things like that.
Exactly. Yeah, no, it'll be definitely a great episode. There's lots of technology in that space, and it's being used more and more, isn't it?
Yeah, exactly. And I thought it'd be good to do a scenario as well where we use a lot of technology.
Yeah, definitely.
Cool. Okay, so did you enjoy this episode? If so, please consider leaving us a review on Apple or Spotify. This really helps us reach more people like yourselves. If you have any specific feedback or suggestions we'd love, we have a link in the show notes, so get in contact with us.
Yeah. And if you've made it this far, thank you very much, and we'll catch you all on the next one.
Yeah, thanks all. Thanks all you.