Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, reliability, and compliance on the Microsoft Cloud Platform. Hey everybody, welcome to Episode 45. This week is myself, Michael, Sarah, and Mark. We also have a guest, Kristen Burke, who's here to talk to us about Zero Trust in a SOC, Security Operations Center. But before we get to Kristen, let's take a quick lap around the news. Sarah, why don't you kick things off?
It's one of those weeks when I'm going to talk about my baby, I'm going to talk about what's new in Sentinel, a couple of things that are actually worth mentioning if you are using it. One of my very talented colleagues has created a workbook and a tutorial for KQL. KQL is Kusto Query Language, we use it in Sentinel and other Microsoft products. It's worth learning if you're using Microsoft Things.
We've got a nice blog post which we'll link to in the show notes, and the workbook is actually already found in the product. So it can help you go learn some KQL if you're getting up to speed on it. Also, if you're using multiple workspaces in your Sentinel deployment, you can now look at 30 workspaces simultaneously. It used to be 10.
So in particular, that's pretty useful if you're a service provider, or maybe if you're an organization that has multiple workspaces, or multiple tenants, if you've got different entities. Then another cool thing that's gone into public preview is the Health Data Table. What it does is it helps you monitor your connector health. So we get asked for this all the time. If I turn on this connector, if it stops sending or something goes wrong, how will I know?
So now that Sentinel Health Data Table will help you do that. So check that one out too, very cool. I'm just going to keep it nice and brief this time. Yeah. So from my side, nothing specific on the news links perspective, but how did the interesting realization that we're refining out?
I've been working on some updates to the Cloud Adoption Framework Secure Guidance, our guidance for the security program level teams and structures and goals and metrics, and also having some similar discussions within the Open Group Zero Trust Architecture Forum. One of the points of clarity I came to through all these discussions was that security really has two different operational arms within the security organization function.
One of them, most people recognize, and actually Chris and Sierra who's spent some time in our Microsoft SOC, and there's the SOC, dealing with the actual incidents to realize risk, the oh gosh, there is an attacker live real and dealing with it. But then there's the other half of it. This one I feel like has been missing from a lot of security organizations for a long time, is proactive preventive or we're calling, process management because security doesn't own the IT operations environment.
They don't own the servers or the databases or anything like that. The uptime of that usually lands on IT ops or sometimes DevOps teams. But security actually does need to have an operational team that's monitoring that stuff, that's looking for the risk, that's helping those teams correct the risk, coming up with plans, et cetera. That's one of the things that was an interesting realization is there really are two distinct and important functions in there.
But that was the big realization for me since the last time. I have a few items that peaked my interest over the last few weeks. The first is in public preview, support for managed identities and Azure cash for Redis. I did not see this one coming. I've been talking the last few months about, we're seeing more PaaS services supporting managed identities and obviously now Redis cash has got that.
What this means is that you can have an RBAC policy on a storage account that only allows that Redis cash to actually write to it and nothing else. This is really great to see. Again, I've mentioned this many times, but we've seen more and more PaaS services support managed identity. So that way you don't have to worry about the credential. This is great to see one that I honestly did not see coming. Next one is also in public preview is managed certificate support in API management.
If you're using TLS into the front end of any system for that matter, managing certificates especially as they're getting close to expiry, tends to leave people sweating. Well, we've now got basically automated certificate support including free certificate provisioning. So this is another great thing to see. Next one is now in GA is FIPS enabled node pools and Azure Kubernetes. Normally, Sarah would talk about this, but this is crypto so it's in my wheelhouse.
We now have the ability to run FIPS 140-2. I'm surprised that it's 140-2. My guess is the evaluation must have happened before September 2021. It's now been replaced by FIPS 140-3. But basically what this is is you have cryptographic algorithms, and then you have some implementations of those in modules. So for example, in libraries. Well, those libraries also need to be evaluated to make sure that they are correct implementation of the algorithms.
That's what gets you the FIPS 140-2 or FIPS 140-3 verification. So that's now available in AKS. Really important for people like government customers. So for example, for part of FedRAMP compliance. So this is really great to see. Next one and the last one is, I did not see this one coming either. There are price reductions for Azure confidential compute VMs. In some instances for the DCS version 2 and the DCS version 3 series VMs, these are the ones that support confidential compute.
We're seeing price reductions up to about 33 percent, which brings them much more in line with general purpose VMs. This can only help with the adoption of confidential computing workloads, especially if you want to run things like SQL, Azure SQL DB with always encrypted and secure enclaves. You have to use a DCS series VM. So the cost of that is going to come down, well, approximately 33 percent. That's fantastic. That actually went into effect on the first of January this year.
So the price reduction is retrospective. So that's all the news I have. So with that, let's now turn our attention to our guest. This week we have Kristen Burke, who's here to talk to us about how to help your SOC during a zero-trust transition. Kristen, welcome to the podcast. Can you spend a little moment to explain what you do and how you've been at Microsoft? Thank you so much for having me. I've been at Microsoft for eight years now, and I've been in security for about 18 years.
So the last four years, I've worked as a SOC architect for our DSR, Digital Security and Resilience Internal SOC. So at Microsoft, there are a bunch of different SOCs actually, but we're the SOC that takes care of the corporate identities and workstations and any policies. So we're the most like, if you go to a different company that doesn't have five SOCs, you were the most like the corporate SOC for any other company.
I've been an architect for the SOC and instant response teams, that's Security Operations Center. A lot of times when I'm talking about zero trust or the zero trust transition, I'm talking about Microsoft's internal transition, what we have done with our own corporate environment, with our own corporate network, and making sure that we have good policies for moving forward on a zero trust or bust as Brett Arsenault or CISO likes to say.
One of the things I wanted to ask you about, Kristen, we've put the security operations or security operations center SOC under zero trust as part of like an overall sort of big zero trust modernization plan. Of course, there's also zero trust access control, which is like a kind of sitting next to a kind of parallel initiative to the security operations piece.
I wanted to see what your thoughts are on that and how Microsoft views that sort of from that sort of CISO's perspective, as well as the other kind of interactions with the other elements of zero trust. I'd love to kind of hear your perspective on how SOC and zero trust interact in different ways.
At least at Microsoft, I think that we have several different teams and DSR is a larger team where you have people who basically run security policies or security initiatives, and then the SOC is separate from that. I think that at Microsoft, it has been more of these people who drive security principles and initiatives driving zero trust at the company and really the decisions being made at the CISO and CVP level for what we're going to do for zero trust.
But I think that to some extent, having the SOC and the help desk under that, super involved in making sure that they are very engaged and sort of step together with the policy makers, I think is super important.
And I think that if you have SOC in your planning and when you're sharing with people, your ideas for zero trust and your principles for zero trust, and you have the SOC in there as part of that sort of V team, then I think that's the perfect place for them to be because I think almost everything you do is zero trust. All of the initiatives you take, like reducing the VPN usage and least privilege and MFA, all has impact on the SOC.
One of the things that was, I might be jumping ahead a little bit here, but I know Microsoft is looking to sort of move beyond VPN and kind of deprecate them, I think is one way to talk about that, but essentially really trying to go beyond the VPN and get remote access done in a different way. Can you talk a little bit about like Microsoft's efforts in there and how that works? Sure. So it began with the decision to do that.
Obviously, having VPN was not any different than having somebody connect to the corporate network. And therefore, from a zero trust perspective, that doesn't work. That's still connecting you to the corporate network and assuming that the corporate network is secure. So what started happening was Microsoft started to deprecate the use of VPN by stopping devices from having the VPN automatically connect. I think it was automatically connecting on your device.
As soon as you turned your device on, I think it automatically connected to the VPN for years, since I think I've started here. And they stopped doing that. And then I think one of the policies they decided or they took was that they were going to also deprecate, even like having the VPN config on a device. So it's sort of this step-by-step approach to try to get people used to the idea that they don't have to have VPN to access corporate applications or internal resources.
It's hard for people, I think, any kind of culture shift like that. And Microsoft is difficult to manage. And I also think it's a little bit difficult for some of the application owners and the internal resources to realize that they aren't going to depend on VPN. So it's working from both sides. It's working on the side of let's reduce the footprint on endpoint devices.
And then from the other side, also making sure that the resource owners are understanding that they shouldn't depend on VPN for connectivity anymore. They should be using device health as an access restriction. So I'm not a networking person by any stretch of anyone's imagination. All right. So VPN gives me a tunnel to the corporate resources. And so we're now saying you something different that's not VPN. So I have two questions, which probably leads to a third question.
So the first question is, so what are we using instead? To which zero trust principle are we enforcing? Or more accurately, if you want to look at it from a negative perspective, what zero trust principle are VPNs violating? And the third question is, and this is a much broader question, is what does the Microsoft take on zero trust? I know that I read documentation from this company and that company and this federal organization.
And I say, oh, they all have their own interpretation of zero trust. So what is our interpretation of zero trust? So I'm not the Microsoft zero trust expert. So I may or may not be able to answer your last question. Effectively, we have like eight blogs on it for inside track. So I'm absolutely happy to send links to you. But we are using the internet. So basically, instead of VPN, because VPN leads you to believe that if you connect to VPN, your device is managed secure, has secure access.
And that's not the case because the corporate network is not secure. Because that's the sort of what zero trust is, is that you don't trust the corporate network. Because it isn't to be trusted. It is a soon breach. And so we're using the internet and making sure that devices are healthy. And we have MFA and we have conditional access. And that we have healthy devices that have Microsoft Defender for endpoint on them. We have healthy devices that are BitLocker encrypted.
So it's more focused on the device itself and making sure that it is appropriate to join or corporate network than it is just having any device connect to VPN. And therefore, we assume that it's secure. Does that help? Yeah, it helps a lot. Yeah, because I think it's always important to sort of, you know, make a statement about something, you know, sort of hark back to the actual policy or belief that's being violated or enforced. Mark, do you have an opinion? Of course you got an opinion.
Yeah, I've always got an opinion. One of the things that I've learned is that there's been sort of an implicit, you know, kind of slightly to your point, Michael, there's been this implicit assumption in security that because it is on the network, therefore it is trusted, right? And that's been the implicit, not opinion, the implicit assumption that's been shattered by attackers and is now being recognized with the assumed breach or assumed compromise mindset.
And, you know, we used to use network access, or you're on the network as a proxy for, you know, you're a trusted managed device. And so it's really sort of the recognition that we've had this hidden assumption that is, in my opinion, the foundation of zero trust, and it's setting us back to square one is like, okay, we tried a shortcut with whether we meant to or not, didn't work.
And now how do we actually do security, assuming we can't rely on the network as this, you know, and all be all trust signal or, you know, 80% trust signal that we did. That's how I think about it. So, so, Kristen, you know, just kind of wrap up on that, the VPN topic. I wanted to kind of bring it back to the sock that we talked about at the beginning. You know, like, so how did this shift from VPN, you know, to all these different things?
And I got to share my one tip before I finish the questions. Sorry. Like the one thing I learned from like Carmichael Patton and some of the others was that the VPN logs were actually a treasure trove to figure out what apps people are actually still using on the corporate network. And so that was a really good, you know, place to mine to figure out, okay, what apps are people using the most so that we can burn down the right apps in the order, as opposed to just some arbitrary list.
So that's my tip. That's my value add. Let me show you, I get that right. So what you're saying is, you know, if we've got, say, three internal apps, and obviously they're gonna have a lot more than that, but let's just humor me. And you see hits on A and B, but nothing on C. You know, C is not being used, right? You know, it's not being used because it's not being hit. You're not seeing the network traffic. Is that kind of what you're saying? Yeah, there's two sides to that.
One is that we know C isn't being used or it's not being used by people that are working from home, which, you know, for a period was just about everybody. But it was also telling us that A and B are the ones we should work on publishing or modernizing or, you know, upgrading to the cloud or what have you. And by modernizing, you mean that it doesn't need VPN anymore, just to be clear.
Yeah. And it may be, hey, we're going to replace that with a SaaS application because there's a better one, right? And we know that's the top of the list because it's the most used thing. And so we should bump up the priority of it. Maybe that's the one we should publish through the Azure AD app proxy. But whatever our modernization plan is of which there's six or eight different options, you know, what people are using the VPN for.
If you're trying to get rid of the VPN, you go after your biggest hitters first and you deal with the ones that people are using. And so people are dependent on it less and less and less. Make sense? I guess that was a question for me. Yes. Yes. Okay. So let me finish my original question before I completely lose my train of thought.
So as all these things are happening and the apps are moving and people are starting to use the VPN less and all this kind of stuff, like how did that impact, you know, the visibility and the detections and the response processes in the SOC? I'm curious about that. So, and this is one of the reasons to take your SOC on the journey along with you.
So a lot of these deprecation goals or deprecation schedules perhaps didn't necessarily make it to the entire SOC for them to understand what was happening. And so even the, hey, we're going to deprecate the VPN. Like when you go and look for attacker activity, you can look in the VPN logs, but that is not the whole story. And I think that having someone who is joining those two thoughts, right? Like I see what's happening. I see we're deprecating VPN.
I see we're making people have healthy devices before they access these resources. Now you need to look at this other telemetry. Now you need to look at app telemetry perhaps, or you need to look at the, you know, the network URLs that you're seeing in Microsoft Defender for Endpoint. And VPN is not a dependency. Therefore, when you go in VPN logs and you're like, I don't see anything. I think we're good.
That's not necessarily true because VPN is not the dependency that people need to get to these resources. So I think just, just a larger understanding of that of like, as you transition, you transition your SOC with it. The SOC really depends on telemetry. Telemetry is the most important thing. And so I think that having someone who is continually updating what telemetry matters, this telemetry is getting smaller.
This telemetry is what you need to use now when you're looking for something as opposed to these playbooks, because SOCs are so dependent on playbooks in a lot of ways, making sure somebody's updating those to be, to go along with your zero trust transition. Gotcha.
So it's not just the, hey, we need to make sure we're dealing with a new perimeter and all this stuff, but, you know, the specific details as well that, hey, you know, we've, you know, as we change out the specific solutions that we've got the logs, the playbooks, etc. You know, changing out and following where the enterprise is going.
Yes. So yeah, one of the questions I wanted to get some insight on, because I know like one of the big transformations, you know, for SOCs is, you know, shifting from a very network heavy, network focused SOC, you know, with those being the sort of the sources of data, into a little bit more identity driven. Because when you talk about SaaS apps and mobile devices accessing SaaS apps, there's no network intercept, right?
It's a cloud provider and a mobile device on, you know, some telecos network, telephone companies network. You know, how, I'm curious how that shift from network to identity, you know, looked from the SOCs perspective, and, you know, like what kind of, you know, skills and tools and things you had to change to kind of keep up with that. I think it's, I mean, it goes along the lines, the same lines as the VPN, right?
If the SOC doesn't know what's happening, then they can't be aware of it and they can't and they can't know what telemetry they need to switch to. And I think that, you know, like you said, like they were digging through network logs and they would be digging through NetFlow data and that, but instead now it's more focused on the endpoint detection and using the endpoint detection, using the Microsoft Cloud app security proxy, you know, using those types of things more.
I think it's just a matter of someone has to be, like outside of the SOC, because they're not doing the analysts, you know, tasks every day, but they have to be knowledgeable about what changes are happening on the network.
Like they have to be on a V team with the networking team, with the identity management team and see the new things that are coming out and then know how to translate that into, okay, well, if we're not going to see network, really network traffic is not going to be the biggest focus anymore, I need to be able to translate that into a SOC perspective where I need to say, okay, you're not going to use this anymore, you're going to use this telemetry,
this is what this telemetry means, you need to go to AAD and you need to be digging through those logs and those become more important and sort of convincing or not convincing because I'm sure they'll be convinced, but, you know, teaching the SOC that that's the new place they need to look, because especially at Microsoft, when we are cloud first, we're always going first into everything where Windows 11 first, you know, and on our own endpoints, it's somebody has to be on top of that
at all times to make sure that people, the SOC knows where the telemetry is. So to your point, it's really about having someone in the middle saying, hey, everybody, these changes are coming, having awareness of the changes that are coming, being sure that you know that and you're well informed and then translating that into SOC capabilities, SOC playbooks and SOC telemetry,
I think it's just really pivotal. And I assume there's like training and readiness as well, because if folks are, you know, familiar with networking and they're not familiar with like the terminology and the architecture and the flows for authentication, they probably need to have
some training and whatnot, right? Yes, when I was a SOC architect, I would set up training sessions, maybe every two weeks, to make sure that we were covering some of these different capabilities and scenarios and what is conditional access even and how do you use it and what does it actually mean for the user? And I think we try as much as we can, but to your point, you're 100% accurate, is that there are things that people have known forever. They came into the SOC with this knowledge
and you're right. I mean, if you're not giving them training sessions, if you're not updating their knowledge, then yes, they will still be thinking kind of the old school mentality and it gets very difficult to look for threats when you're thinking about the old ways of doing things. Hey, so you brought up something really interesting there. You said, when I was a security architect, sorry, SOC architect, so a couple of questions. One, what does that mean? I mean, what is that?
What was it? What is a day in the life of a SOC architect look like? That's number one. And number two, how does zero trust ideas change what a SOC architect needs to consider on a daily basis? So a SOC architect, I call myself that. I'm actually not even sure what my job was, but it was four years of originally the job was making sure that the SOC feedback to our product teams was delivered appropriately. So like for customers, we have the CXE team, the customer engagement team,
who gives great feedback on how different customers are using our products. I did that for the SOC. So basically, it was just making sure that every time that they came up with a new piece of software, even at the beginning of Microsoft Defender for Endpoint, when it was just starting out, then putting it on devices and making sure that the right feedback was given to the product teams. And then it sort of grew from there into, okay, what data does the SOC need? What data sets do
they need? What telemetry are we missing? In this last incident that occurred somewhere and we were looking for IOCs on our network, like where could we find them or where couldn't we look for them? And getting more telemetry. And then it kind of grew into being that person that is sort of the in-between between things we're rolling out on the network and things that the SOC needs to know about. And so I tried to be that person as well. So it was kind of whatever the SOC needed as a job
was my job is the answer. I'm not sure what it is at a different company, but that's what I had to do. Architect is actually a really good name for that. Architects tend to be gap sellers. Yes, exactly. And your second question was how do the Zero Trust sort of ideas affect the SOC? Just overall. So I think we covered VPN, but I think things like network segmentation can be
absolutely critical for the SOC. If you are in the SOC and you are looking for something with indicators or an attacker and you don't know that there's network segmentation between two spaces on your network and you think that an attacker could move from one network segment to the other because you don't know it's segmented. You think it's flat and you think everything's connected, then that is really difficult. You might go down a rabbit hole that you didn't need to go down.
You did not need to do all this investigation into something where there is network segmentation and so there is no connectivity and the attacker would not be able to get there. So it's about a lot of times saving time as well. I think in a conditional access way as well, sometimes devices don't have access to resources if they're unhealthy, but making sure that your
SOC has really, really good telemetry on what is healthy and what is not. A lot of times you'll look in Azure AD and it will say that something is connected, but if you use Intune as well, then it isn't actually connected because AD will tell you that and it's true from an AD perspective,
but Intune obviously manages your devices. So I think that making sure that it's super, super clear to the SOC that yes, this has access, no, this doesn't have access because it is completely pivotal to a risk assessment and to any kind of investigation knowing what the attacker has access to or does not. Michael, did that answer your question? It actually really has. This is an area I don't really spend a lot of time on and I know that Mark does. So this is actually really useful
for me, incredibly useful. I've learned a lot so far. So yeah, that really did answer my question. I'm so glad. One thing I want to just ask and kind of, I think it's probably a confirmation thing, but my understanding, especially based on your last comments there, is pretty much a SOC is always, I think of that quote from the matrix that, hey, time is always against us, right? Because there's always more work, more things you could investigate than you possibly could.
And so you're constantly triaging. You're constantly prioritizing. You're constantly trying to say, do I need to continue this thread or do I need to drop it and move to the next thing? I mean, is that a good description of kind of the day-to-day within the SOC? Yes, that is 100% accurate. And we just simply do not have time to spend cycles on things that are not as risky as others. And so prioritization is probably the most important thing when you get
to the point of triaging alerts and events. So yes, that is accurate. So having this understanding of what attacker can go where, what account works where, if this account had multi-factor or didn't, or this account had access to a resource or didn't is super, super crucial to be able to prioritize those alerts, to be able to make sure that you're working on the highest priority alerts. Yeah, because waste is your enemy because waste keeps you away from the mission, basically.
Yes. And you always have to watch for burnout of the SOC. I think when the SOC gets frustrated, because, oh, I didn't even have to look at that because it's not even connected and they didn't know it's a frustration. And you try to keep your SOC from feeling that frustration because burnout is always sort of just something that you really have to worry about for SOC analysts, because they just have so much volume of learning, especially at an enormous company like Microsoft.
It's really, really important to make sure that they're looking at very, very high fidelity, critical alerts. Yeah, I think the rule of thumb that I heard from our SOC director that has since retired was 90% true positive is what we target for our inbound tier one, I think it was, was alerts that if it doesn't have a track record of being 90% true positive, it's probably not going to get on their metrics and pop in their queue. Is that still true or?
Yes, we try our best to do that as you can imagine having really good methodology for your fidelity calculations, having really good sort of proof of fidelity calculations, because as you can imagine, if something happens and something isn't on boarded because of fidelity reasons, you need to be able to prove why it's not on boarded for fidelity reasons. So making sure that that is documented excessively and revisited a lot too. It may not have great fidelity today, but it may have great
fidelity in a month. And so making sure that that's something you revisit as well is really important. Yeah, because I mean, it's the attacker's job to essentially break you on that because the attacker wants to avoid your detections and they don't want to be reliably detected. And so you're pretty much like wrestling with them every day. Yes, it's fun, but it's challenging. So, Kristen, we've talked a lot about different challenges, different issues. How do you think
about preventing these things? Are we looking at change management or other sort of process things? How do you think about sort of heading off some of these if I'm in a sort of average organizational sock that's sort of working their way through the maturity curve and trying to get better at what they're doing, shifting tools, etc? Like, what were some of
the lessons learned that you'd share there? I think one thing that Microsoft does that I really appreciate to try to keep things from happening like if the deprecation of VPN and making sure that everybody, not stopping that from happening, but making sure that everybody is on board with that. One thing we do is it's called Client Cab and it's basically an advisory board that takes every anything that anybody wants to roll out on the corporate network is supposed to go through that
advisory board. And so people are supposed to come and they're supposed to create an ADO item and give all the risk analysis of it and say, this is what I want to roll out. This is what we're doing. This is why we're doing it. Come and give an analysis of what actions they want to take.
For instance, network segmentation or the VPN deprecation or conditional access policies, additional access policies, anything that affects users and making sure that not only is the sock on board with that and they really have a vote in, hey, we can't do that this week. We're completely overwhelmed with something. Can you push it to next week? But also, honestly, I haven't really talked much about the help desk, but I think in a lot of ways the help desk is left
behind as well. Your help desk is the first place when people, when anything is broken, when people can't do anything, when you're deprecating VPN and people are like, I can't get my VPN to work. I don't understand what's happening. Help desk is the first line of people that's
going to hear that. So I think definitely making sure that all of those teams are involved and have a vote and are informed just to involve as many people as possible to make sure that everybody is not only on board, which they totally should be, but are well informed and aware of what's happening and then can give you feedback on, hey, we've seen 10 tickets for this this week. Help us make this better for users. This needs to be a better experience before we roll it out
further. So that's just really important. And I just wanted to highlight the help desk too, because I think the help desk takes a bulk of the work when a lot of these things happen, much like the SOC does. And I just want to support them as much as I can. And you said ADO. I assume you mean Azure DevOps, kind of the way we track changes. Okay. Yes. Thank you for clarifying.
So I'm going to have to ask the question because obviously this was the question I would ask, but tell us about Sentinel and how that's been used in the Microsoft SOC and how that relates to everything we've already talked about. You knew I had to bring it in. Sentinel is great. Obviously, we made our transition. We have another blog that I can give you the link to, Michael, to post. We have a blog about how we moved from ArcSight to Sentinel.
And we did that in July. It was the final kind of changeover. We ran them side by side and then we moved over completely to Sentinel. It's been incredibly useful for us, especially in the telemetry aspect of being able to have those connectors that will directly connect a lot of our raw data from our products into Sentinel and being able to query them all together and write detections
on top of them all together in one spot has been really, really helpful for our team. It's made the SOC much more efficient, being able to come up with a detection that they want to onboard and then having all of the data there for the engineering team to be able to write that detection. So I think it's really been changed a lot of methodology we've used and made us faster
and made us better at writing detections. And in the blog, you'll see how much data we ingest, which is an extraordinary amount of data and how efficient and effective Sentinel is at ingesting that and providing it for the SOC in almost real time for them to be able to query. So it's been really great for us. I'm sure there'll be another blog on the transition, but May Lau, one of my co-workers did an amazing job on that. So I'll absolutely send that link and it's been
really great for us. So we really appreciate the tool and are looking forward to using even more in the future with risk IQ integration and any other acquisitions we make. It's great. Every time we add something to it, it's fantastic. This has been really useful for me and Linda. Linda, great deal. I have no doubt that everything that you do will have an impact on my day-to-day work there, right? Yes. You will be both a victim and a beneficiary of the Zero Trust rollout, Michael,
but you will see changes on your devices, but all for the better. It'll make us all more secure. So it's very exciting because we all want better security on the corporate network and we want to be able to sort of be the leaders in this space. So we do it and then other customers do it when we show them how successful it is. So one thing we always ask our guests is, if you had one final thought to leave our listeners with, what would it be? Zero Trust is really, really important for
all companies to try to at least aspire to in some form. Even if you can't get there all the way with Zero Trust immediately, taking some of these particular principles like MFA for all accounts and having sort of going to network segmentation, if you can, micro segmentation, and making sure they have really good telemetry for all of your devices and identities is really, really important,
but just make sure that you bring all the teams along with you. Make sure that you have a V team of the SOC and the help desk and any network team and anyone else that has a stake in this and make sure that everybody is brought along and everybody is bought in so that it works the best for everybody and we can keep everybody secure because it's really, really important. Zero Trust is really important. Just make sure you bring everybody with you. Again, thank you so much for joining us,
Sweet Kristin. Really appreciate you taking the time. I know you're busy. As I mentioned, I've learned a lot and I have no doubt that Sarah got to validate her use of Sentinel. You and Mark just basically geeked out anyway. But again, thank you so much for joining us. And to all our listeners out there, thank you so much for listening. Take care and we'll see you next time. Thanks for listening to the Azure Security Podcast. You can find show notes and other resources at
our website azsecuritypodcast.net. If you have any questions, please find us on Twitter at azuresetpod. Background music is from ccmixter.com and licensed under the Creative Commons license.