Sam Kirkman: [00:00:00] So the IT team had set up this automation account as they call it in Microsoft Azure. But the way that they'd set it up, they'd had all this Azure capability in the automation, but they'd added in permissions from the higher level Microsoft Entra world. And in this case, they'd added in Microsoft Intune permissions.

If you have access to Microsoft Word and all of this kind of thing, and you haven't bought standalone licenses, you are probably using Microsoft's platform and the Entra suite. And from organizations that haven't implemented conditional access policies, they'll often find that the defaults are very open.

So if there's one message that I'd give, it's planning is progress. Take the time to plan effectively and tie your actions to the original objectives and the outcomes that you are going for is worth every moment of your time.

Ashish Rajan: If you work in cyber security, specifically Azure security, then this episode is for you.

In this episode we spoke to Sam Kirkman about some of the common vulnerabilities he is seeing in the Azure landscape at large enterprises. And we also spoke about how you can be a bit proactive on how you do security in Azure using native services. Like your [00:01:00] conditional access or perhaps using PIM. We also spoke about what are some of the other things you could consider in your cybersecurity program for 2025, especially if you work in that EU UK landscape as well.

So I hope you enjoy this episode of Cloud Security Podcast. If you have been watching Cloud Security Podcast episodes for a while and are really enjoying them and getting value from it, you can just take a few seconds to support us by liking or subscribing to the channel on YouTube or LinkedIn. That really means a lot.

I hope you enjoyed this episode with Sam. I'll talk to you soon. Hello and welcome to another episode Podcast. I've got Sam. Welcome, Sam. Thank you for coming again. Thanks for having me back. Yeah, it's great to be back. Maybe to a good place to start, if you can share a bit about your professional background.

What are you up to these days?

Sam Kirkman: Sure thing. So I am a penetration tester. That's pretty much been my career for the last few years, for the whole of my career. But alongside that, it's developed into a little bit more. I've done security architecture work. So starting off, finding the vulnerabilities of the pen testing and then moving into helping to advise people on how to actually address those vulnerabilities.

And then that naturally lends itself to rolling up my sleeves and getting stuck into some kind of solutions engineering as well. So it's giving me a really nice rounded picture of the [00:02:00] journey from the outside to the offensive side onto the defensive side, which has been a really interesting experience.

And I've learned a lot from that.

Ashish Rajan: I think we spoke about offensive side last time, but this time we're talking about proactive security. Yes. How do you define? Because I think there's I guess I have a definition, but I'm curious. How do you define proactive security for people who may be hearing the term for the first time?

Sam Kirkman: Yeah, I think there are various definitions across the industry. So the one that we work with at NetSPI, the one that I focus on, is that it's very much aligned with what we know and love. The idea of know what you have, try and protect it, it's those underlying principles. But often when you really look at the detail of how organizations are working on cyber security, it's surprisingly reactive.

And by that, I mean that organizations are often dealing with an incident of some kind, whether major or minor and then they'll start implementing controls in response to that. Sometimes we start to work with organizations that are seeing another competitor get hit and then they'll start reacting but most of the time the steps they take are all in response to a bad thing that has already happened.

So proactive security is about getting ahead of that. Some organizations are already doing so. They [00:03:00] might be putting an EDR before they've had a breach and that's all great, but proactive security still means going further. So a lot of organizations will go and buy certain products and that's their furthest step.

But what we like to see and encourage is organizations to really go and understand their entire context, every single asset that they have, not just systems, but data, personnel, all of that stuff. And then proactively work out what solutions work for those particular assets that they need to protect.

Ashish Rajan: What is an example of reactive security? Because you mentioned EDR, you could have an EDR. That's proactive because most people would think, I'm being proactive if I have an EDR. Maybe to bring it home for people who may be in the Azure land. What would be an example of reactive security there?

Sam Kirkman: The most common that I see is certainly when we deliver security testing. We'll say, hey by the way all of these virtual machines that you've got are just open to the internet with no proper firewalling on. Or what we sometimes see, particularly in Azure, is there are toggles that you can set for your network protection to just make all of those systems available to everything in Azure, which is a really weird control to [00:04:00] have, because you can have great firewall into the public internet, but if you've checked that box, which makes it sound like a great way to just make everything work correctly, and it does, what you're actually saying is I want anything in Azure to be able to talk to my system.

Including stuff way outside of your boundary of your subscription and context. It could just be some hacker that's setting up something else and they can now hit your system. And it's just a checkbox, so it's one to watch out for. It's definitely a reactive thing that we see. Once we explain the context, then people start to fix that.

Ashish Rajan: Actually, because you had an example, before we started recording, we were talking about an example that you had from a customer case study as well. Could you lay the groundwork for people who are watching the listening to this. They come from various backgrounds.

Some people may be not familiar with Azure. So maybe if you start with. What is typically seen in enterprise as an Azure layout or architecture?

Sam Kirkman: Sure, there's a few pieces to this, and I think probably the key one is this distinction between what's now known as Microsoft Entra and what used to be called Azure AD or Azure Active Directory.

And then you've got Azure as this separate thing and that's part of the reason Microsoft changed the name, Microsoft Entra. Microsoft Entra and Azure, at least there's some distinction. Yeah, [00:05:00] but the distinction is very not understood across the industry. The easiest way to think about it is Microsoft Entra is your top level business identity and permissions management.

So that sits at the very top and dictates who all the people are inside your organization, how they access everything from their email accounts to every application they sign into with their user information. And then Azure is one of those applications. It's a little box inside that.

It may be a small box, but it's obviously massively powerful, a hugely massive cloud platform. But what we often see is this weird blending of permissions and what we saw in this organization is that they tried to automate a lot of their IT processes, right? They were scaling, which is great. They were really growing and their IT team hadn't grown in headcount. So quite sensibly and understandably, they were using Azure's automation to try and speed up some of the normal day to day processes, issuing machines, setting them up that right thing. So the IT team had set up this automation account as they call it in Microsoft Azure.

And that should have done very basic tasks, maybe spin up a virtual machine, do things all [00:06:00] within the Azure ecosystem. But the way that they'd set it up, they'd had all this Azure capability in the automation but they'd added in permissions from the higher level Microsoft Entra World. Oh. And in this case, they'd added in Microsoft Intune permissions.

And if you haven't come across Intune's Microsoft's device management platform. Yeah. It's how you manage the security of probably all of your laptops and field devices. So what we ended up with is a system that was able to be an administrator across every single device in their organization.

And that was by design, they wanted to automate some stuff. But the point where it became a problem is that a lot of people in that organization had at least limited access to that automation account. They were normal users. They weren't administrators. They weren't IT people. But through a bit of a messed up permission structure, you'd ended up with random people in the organization who could modify that automation.

And at face value, that is hard to understand the risk. But what we were able to demonstrate with that customer is we could pull the credentials out of that automation We then identified hey, these [00:07:00] are Intune administrator credentials, right? So from going from one normal cloud user in the business Somebody who just had a Microsoft 365 account and an exchange email address We were then an Intune administrator which meant we could pivot all the way from the cloud to every single on premises device that they had every laptop every endpoint and all we had to do is find somebody who had an administrator account and then the icing on the cake or the worst case component of this is that not only were we then taking on the permissions of an administrator in the normal on premises Active Directory world. They were also synchronized as a global administrator in Entra and Azure, it gave us access to the entire works Oh, wow And it was all from a very small misunderstanding of the segregation between Azure permissions, which are just infrastructure and technology and services and the Entra permissions, which your bigger business access controls.

Ashish Rajan: To your point about, I guess most people have Microsoft 365 as a very common component everywhere, even if. They feel they're using Azure. They're probably using Microsoft 365. [00:08:00] Are there native controls for this? Or is it like what are some of the native proactive security things that we can look at?

I guess for this.

Sam Kirkman: So the big one is going to be conditional access policies, right? And you're quite right most organizations, even if you're an AWS focused organization for the cloud, if you have any kind of exchange infrastructure in the cloud, if you use SharePoint. If you have access to Microsoft Word and all of this kind of thing, and you haven't bought standalone licenses, you are probably using Microsoft's platform and the Entra suite.

And from organizations that haven't implemented conditional access policies, they'll often find that the defaults are very open. And the unfortunate reality is, as I'm sure we've talked about many times in our field most of the organizations sell services to be useful to their end customers. And Microsoft are no different, just because they're huge.

They want you to be able to use all the Microsoft products with as much ease and simplicity as possible. But the end result of that is that, from a security point of view, everything's wide open by default. There are some good changes towards multi factor and that kind of thing, but one of the conversations I have most often in this space is, what should my conditional access policies look like?

So [00:09:00] if you haven't come across those, just for context, they are policies you can apply that'll control who can log in, under what circumstances, and to what target application systems, that kind of thing. And they're pretty granular. So you can do things like make sure that Sam is only allowed to log in from this particular IP address and if he goes through these seven steps.

If you want to do that, most organizations would benefit from having a blanket multifactor authentication absolutely everywhere because that isn't always the case even today But there are some really cool things you can do to stop some of the most advanced attacks we see. So token theft is an example We're seeing that increasingly as things like EDR is becoming more and more widespread. Attackers are having to get quite creative and going down the traditional path of blasting credentials at some cloud portal is less and less effective because of multi factor authentication and a few other controls in there.

At this point, if you can get onto a device and run some malware. It can be easier to steal the existing authentication tokens from that laptop and then just use them for whatever you're up to. So if you're signed into Outlook, or [00:10:00] Word, or any of the usual Microsoft Office suite, an attacker can pull those credentials, or the tokens as we call them and then use them elsewhere.

Unless you implement, its currently in preview, but there is a conditional access policy that you can apply that locks the tokens that your users are issued to the devices that they're on. So if I then come along and steal your token, I think I've won, I'll try that on my hacker's laptop to log in as you, and it'll just not work.

Entra will spot that, block it, and tell you about it. And all of a sudden you've mitigated an entire class of attacks with one conditional access policy.

Ashish Rajan: Would that be the replay attack? So it's an, I can't have a session replay.

Sam Kirkman: Is that what it is? Similar concept, yeah. Okay. Yeah, the traditional attack flow would be alarmingly simple.

My malware would go and steal the tokens that are effectively in a file on your computer. That's the simple way to look at it. And that file is like a token that just represents your identity to Microsoft. And unfortunately, and it's true for most systems out there, if you have that token, usually there isn't any additional validation of that token.

If it's a valid token and it represents Ashish, then it's you, as far as most systems are concerned.

Ashish Rajan: Does it have a [00:11:00] long time to live as well?

Sam Kirkman: Most of them do, yes, yeah.

Ashish Rajan: And it applies to virtual machines?

Sam Kirkman: Yep, yeah. If you're signed into a Microsoft application, you'll have a token somewhere. Oh, wow. Okay, that's pretty bad.

Absolutely, yeah. It scales really badly. And this is exactly the kind of attacks that we're seeing these days, because you can't anymore reliably spray passwords at something like the Microsoft Entra login.

Ashish Rajan: Yeah,

Sam Kirkman: okay. Microsoft will block you if you try and do that. You can get creative but even if you manage to land on a correct password, there's a very good chance your victim will have multi factor auth.

Assuming that's been set up correctly, and then you're still stuck.

Ashish Rajan: Ah, interesting. And I think you mentioned, but that's regular users, what about privileged users?

Sam Kirkman: Yeah, privileged users, there's another level you can go to. So conditional access is still really good, it's absolutely worth taking the time.

Microsoft has some really good templates for conditional access policies, so they're well worth looking at. And of course I'm always happy to talk about it, probably a little too much. There is also for privileged users, Privileged Identity Management, which lets you level up the game that bit further. If there's ever been a time when you've [00:12:00] thought to yourself, it feels a bit uncomfortable that I've got two, three, five, ten global administrators and they're just operating day to day doing their normal stuff and if any one of them gets hacked, I'm in real trouble.

PIM as it's known, Privileged Identity Management PIM is designed to mitigate that. And the way it works is that you have just in time access. So let's say you and I are administrators in a business and traditionally we'd both be administrators and I could go and cause chaos and you'd have no idea about it, especially if i've been hacked by a third party but with PIM every time I want to elevate my access beyond the kind of standard user and become an administrator I'd have to put in a request. And that sounds annoying at first, right?

I don't have to message somebody every single time. But the system's designed very smoothly, so that you can effectively click a button, type in a little message to say, this is why I want to be a global administrator and I'd like to be a global administrator for one hour to perform this task.

And then all you need to do is receive the request, do a little out of band validation, call me, send me a message on your phone, something that's outside [00:13:00] of the Microsoft bubble and that is really important, because there's been some times where people have said, oh yeah, no, I get the PIM request, and then I go on Teams and I ask them, and I'm like, yeah, if that's a fake PIM request, from somebody who's hacked your account, you're just asking the person who's hacked your account whether or not they should elevate you, so do it out of band, but all you need to do is submit the request, have it validated. You click okay, and I'm an admin for one hour, so I can do my job and of course if somebody steals my tokens or breaks into my account in that hour, it's still bad.

But if they break into my account when I'm not elevated, they don't have global admin permissions. They're stuck.

Ashish Rajan: And I guess maybe to extend this example a bit, you mentioned SharePoint earlier. Does this kind of extend on to SharePoint and OneDrive kind of thing as well?

Sam Kirkman: Yeah, and that is a really complicated angle because data is at the core of every single business, of course it is.

And unstructured data tends to live on platforms like SharePoint and OneDrive. So SharePoint generally being the central resource that is shared by a lot of people in a team or a company. And then OneDrive is effectively backed by SharePoint's technology, [00:14:00] but that's all often used from an individual's point of view.

But then you can have people sharing files from their OneDrive as if it's available in SharePoint, and it gets very complicated very fast. But Microsoft know that and they've implemented some pretty cool technology in what's now known as Purview, which allows you to do some pretty good stuff, ranging from simply logging and monitoring what data is being accessed and by who.

To being able to implement data loss prevention policies and a few other similar things to be able to automatically tag data. Say for example, you've got a team within your organization that handles, say, financial information. Yeah. You can have everything created by that department to be automatically tagged as financially sensitive.

Oh, and then you can apply a set of controls to say, all of this data must be encrypted at all times. It cannot leave the organization. It can't even be accessed from a device that's outside the organization, but then you might want your marketing team or your events team to be able to go and access their information that's tagged as public or semi public with far weaker controls because that fits their workflow. And the thing I really like about all of this stuff we're [00:15:00] talking about is that it solves one of the biggest problems in the security space, which is that implementing controls annoys people. Because it gets in the way of them doing their job, or at least it used to.

But if you spend the time on this, if you're proactive about setting it up by engaging with the stakeholders in your organization, you can implement controls that actually work really nicely with their workflow. If you really nail it, you can actually make things easier for those teams.

It just takes that extra bit of proactive time and effort.

Ashish Rajan: Yeah, and I guess your point is, I love the sharing part because it made me think about if I'm sharing between OneDrive, SharePoint, the identity thing we spoke about and conditional policies, does that kind of extend on to not just Azure, but also extends to Sharepoint and OneDrive as well, the conditional access policy?

Sam Kirkman: Absolutely, yes. Yeah, you can do some really quite heavy duty controls if you want to. There's some, Microsoft are continuing to innovate in that space. Other vendors are as well. Within the conditional access space, one of the best controls that I see is when users have to have a domain joined device.

So their laptop will have to be joined [00:16:00] to EntraID or AzureAD as it may be known in some organizations still. And they'll also have to use multi factor authentication and then the document must have the right protective controls on. So the way the Microsoft Office Suite now works, which is worth mentioning, is that if you encrypt a document, it can be encrypted and the user won't know, as long as they're signed in and they meet all of the controls.

Ashish Rajan: Yeah.

Sam Kirkman: Microsoft will just manage that encryption for you. It's completely encrypted, it'll pass all of your compliance checks, it'll be functionally inaccessible to anybody outside your organization, even if they get a copy of the file. But to the end user, as long as they pass those conditional access checks, it'll just open like any other document.

But if I steal that from your laptop and run it on my laptop, it's an encrypted blob of AES 256 encrypted data I'm not getting in. I'm just not. It's a brilliant balance of really smooth.

Ashish Rajan: Those are native controls. Where does ASM I know we kind of love acronyms in this world of cyber security.

What is ASM and where does it fit into proactive security?

Sam Kirkman: So ASM, attack surface management, is that particular acronym. And it's a key part of getting to [00:17:00] the level where you've got a solid baseline, effectively. All of the stuff we talked about here takes a fair amount of time and effort to implement.

But once it's there, it's generally set and forget and you just move with the organization as you grow and change. That's very difficult to do in the world of vulnerabilities because vulnerabilities are being released on a daily basis around the world for if you're a big enough organization you'll be dealing with those on a near enough daily basis. Yeah. Traditionally speaking that's been managed by teams of human beings that have been running vulnerability scans and processing huge volumes of output and dealing With a lot of noise and if you're going to spend the time on proactive security like with conditional access policies and all that you can't be spending all of your time dealing with vulnerability by vulnerability on a case by case basis.

So attack surface management is this idea that you can do a lot of automation in that space to manage your attack surface on a day to day basis so that you're not dealing with these ebbs and flows of massive spikes of traffic of understanding how to process your vulnerabilities and address them. What we often see is maybe a vulnerability has come out for a firewall and we'll have customers saying, we [00:18:00] have no idea how many firewalls we have.

Do we even have these firewalls? Are we on Palo Alto? Are we on Cisco? And this kind of thing. And that causes chaos for the organization that slows them down. So attack surface management is about knowing what you've what vulnerabilities affect it at all times. So the next time something is raised as an issue you can log on to your ASM platform and you know what you've got whether it's vulnerable and how to fix it and that entire journey can go from weeks down to hours maybe even minutes depending on your workflow.

Ashish Rajan: Fair and I guess to your point does that look at both internal and external? That's ideally

Sam Kirkman: Yeah, there's quite a few different vendors out there one of the things I'm really proud of at NetSPI is that we've worked really hard to get visibility across both. Yeah. The internet is obviously a massive space Yeah, so we can absolutely scan things from a perimeter perspective and good ASM will do discovery as well so it won't just see what you tell it to look at it will also find things that we proactive security Exactly part of the philosophy and then on the inside we spent a long time and that's by working at how best to [00:19:00] implement that because a lot of the traditional approaches are agent based.

And I can hear some of the IT admins listening to this going, Oh, I don't want another agent to manage. Because it gets chaotic. There's a lot of process, especially for big orgs. So we've taken the approach of leveraging your existing infrastructure to find your asset. So what that means is if you have, say, an EDR platform, Defender for Endpoint, CrowdStrike, Falcon, any of these systems, instead of making you install an agent, we pull from their data.

Cause CrowdStrike is going to know where you've installed their agent. And the same is true for lots of other bits of technology. You might have all sorts of patch management bits of software. Obviously you're likely to have maybe Entra to manage your devices or Intune, all these different things.

And we pull from all of the different partial sources that you've got to find your internal assets. And then we give you the entire view in one place.

Ashish Rajan: Maybe specifically for the UK and Europe landscape where you primarily operate in, what's the requirement for ASM in this space?

People obviously hear this term, and they might question the fact that, oh, is that something that I may need? And is my environment in the UK and Europe landscape very different compared to, say, some of the [00:20:00] other parts of the world?

Sam Kirkman: It's really heightened in focus as a result of the new NIS2 directive.

Networking and kind of infrastructure security. It's Europe's way of saying this matters. And it matters to a similar level to GDPR. Yep. You might remember when the fines were announced as a as percentages of revenue in GDPR. And if you haven't come across NIS2, it works the same.

Oh, slightly lower threshold, slightly more forgiving. But we're still talking percentages of your revenue if you fail at these kind of basic security principles. Almost the first one of which is know what assets you've got. Get your basic foundations right for understanding what you've got, how dangerous is it? Are you managing it well, that kind of thing. So all of a sudden the focus is on having a good understanding of your attack surface. Yeah. And the sympathy and forgiveness for organizations that aren't taking those correct proactive steps is ebbing away as we go on.

Ashish Rajan: So it's similar to GDPR where it's primarily for people who have sensitive data that they work and operate with.

Is the NIS similar as well? Is that only for critical enterprise scale or? It's a small, I don't know, a legal firm [00:21:00] also should be concerned about these kind of things?

Sam Kirkman: So NIS has done it based on sector or industry. Okay. So you've got the critical side of things, so that's going to be your food supply, your energy supply, that kind of thing, finance, that and anything that you'd describe as particularly bad if it goes wrong, but it also has an important category.

Which includes a much broader range of organizations that are, of course, important, but not necessarily critical to the operations of a country. And then when you expand on the fact that all of those organizations will have third party supplier relationships and this kind of thing, we're reaching this level where even if you're not going to get directly audited by the European Union and the regulating bodies, you are likely to be required to meet those standards because of the business that you do with businesses that are regulated.

Ashish Rajan: Yeah, especially if you work with banks and stuff and you're third party, you're using them somehow. , you need to be compliant as well.

Sam Kirkman: Definitely, Yeah. I think the way that the NIS Director works is that if you're in the critical bucket, there are proactive engagements of those organizations to validate, are you doing things [00:22:00] correctly?

If you're in the important category, you basically get to wait until something goes wrong before you'll be investigated. But I'd challenge most organizations that they probably don't want to get audited. They'd rather get it right the first time. And of course, if you're working with a critical organization, they're going to be applying pressure to you.

Ashish Rajan: Of course, and they might be proactive about it as well. Thanks for the word again. Final question also on the context of, so last time when we were talking about this kind of BlackHat Europe being on the tail end of the year. A lot of people are still working on their roadmap for security program should look like for 2025.

What's your recommendation for people who are thinking about proactive security for their cybersecurity program for 2025? We spoke about the offensive side last time and I'll probably put a link somewhere for that previous year. Is that different now? Do you look based on the conversations you've had with different customers and different use cases in Azure?

And otherwise, have you changed the way you think about how people should bring their security program or should plan their security program for the next year.

Sam Kirkman: I think I'm pleased to be able to say that what we talked about last year is still the usual. Perfect. I'm glad it's not expired. But there are [00:23:00] things that we learn every year that we go through this journey, we learn more from our customers and people that we speak to.

And one of the big things that stood out for me is the frequency with which people are rushing to get these roadmaps together to make sure that they can make change. Because all that time you spend planning feels like no progress. And I've seen and spoken to a few security leaders, chief information security officers who've said, we threw this together in kind of a month, it was intense meetings.

Yeah. Now we're making progress. I thought that's interesting. How has that process gone? And all of them said, yeah, we spent a lot of our budget so far, but it's hard to know if we're succeeding.

Ashish Rajan: Yeah.

Sam Kirkman: So if there's one message that I'd give, It's planning is progress. Take the time to plan effectively.

And one of the things that I'm talking about with folks here at Black Hat is taking the time to plan effectively and tie your actions to the original objectives and the outcomes that you were going for is worth every moment of your time because there are plenty of occasions and plenty of businesses that I've worked with where I've come in and maybe a security architect capacity and I've been told, Oh, we've bought products A, B and C and I need you [00:24:00] to implement them.

And I go, great. I'll Why? And the answer is oh they were some of the best in the market. It's like great, but best at what? Yeah, what are you trying to mitigate here? What's your risk? Are you what most worried about a ransomware attack that comes in via your frontline staff? Are you most worried about an internal threat actor?

Somebody who's disgruntled or something of that nature? Third party risk. Yeah. What are your threats? What are your risks? What are you trying to prevent here? And how do those controls actually do that? And once you go to that level, you'll start to be able to say, you know what? It's probably worth taking an extra few weeks to make sure that this vendor is the right vendor.

And then not just the best in the industry. Cause the best in the industries. Great if you need them.

Ashish Rajan: Yeah,

Sam Kirkman: if they're the right fit for you So that extra bit of time is still progress and I would encourage anybody that's part of that road mapping planning process Yeah to generally push back on the leaders that are probably pushing them to hurry up.

Let's do it right once yep instead of badly twice

Ashish Rajan: Especially for something like an annual planning as well. So you won't be able to [00:25:00] revisit this until the next year as well. So that's why

Sam Kirkman: I've seen five year plans. Oh my God. Yeah. Yeah. I think

Ashish Rajan: five, I feel like post COVID world, those really doing five year planning was like a one year plan.

If I make it next year, that's true. I'm actually thinking of the financials. Oh yeah. Those guys. Yeah, for sure. Where can people find information on the whole ASM side of things and the kind of work you guys are doing? Where can they find information on that.

Sam Kirkman: Easiest thing to do would be netspi.com/emea and you'll find everything from that.

You can always find me on LinkedIn as well, and that's always happy to have a chat pointing me in the right direction. I think that covers it. Awesome. All right. Thank

Ashish Rajan: you. Thanks so much for coming in, man. Great to be with you. Thank you. Thanks everyone. Thank you for listening or watching this episode of Cloud Security Podcast.

We have been running for the past five years, so I'm sure we haven't covered everything cloud security yet. And if there's a particular cloud security topic that we can cover for you in an interview format on Cloud Security Podcast, or make a training video on tutorials on Cloud Security Bootcamp, definitely reach out to us on info@cloudsecuritypodcast.tv by the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, [00:26:00] you might be interested in our sister AI Cybersecurity Podcast, which I run with former CSO of Robinhood, Caleb Sima, where we talk about everything AI and cybersecurity. How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of ChatGPT, and everything else continues.

If you have any other suggestions, definitely drop them on info at cloudsecuritypodcast. tv. I'll drop that in the description and the show notes as well so you can reach out to us easily. Otherwise, I will see you in the next episode. Peace.

‍