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 55. This week is myself, Michael and Sarah. Glad there's a mark of taking a vacation. We also have a guest this week, Matt Sosman, who's here to talk to us about some of the practicalities of Zero Trust. But before we get to Matt, let's take a quick lap around the news. Sarah, why don't you kick things off?
At the time we're recording this, it was RSA last week. I didn't go to RSA this time, but as you would expect at RSA, there's quite a few announcements. The big one, of course, is we announced Microsoft Entra. Entra is our suite of identity-based security solutions. So that includes good old Azure AD, Microsoft Entra permissions management. Now that's our Cloud Infrastructure Entitlement Management, or CIM.
I'm not sure how we're going to say that, because that's CIM, but then we have CIM within S as well. So I know some in the US, often people say CIM for the one that starts with an S. I pronounce them the same. So I guess we'll find out how you pronounce those. That was, for those of you who are aware, Microsoft Entra permissions management is what we're now calling what was Cloud Knox, which we acquired not too long ago. And then the other product in there is Microsoft Entra Verified ID.
So a lot of stuff, a lot of cool things that we've put into one suite of products. So there's a lot of, we'll have links of course in the show notes as usual, but go check out Entra, because that is our, we call it our modern identity and access solutions. And I'm sure we'll have some people, in fact, we'll have to go find some people, Michael, to come on and have a chat to us about that. For some other announcements, then we've also got Defender for Cloud.
They have announced that they've now got GA for GCP onboarding. So if you're using GCP and you want to use Defender for Cloud to monitor your VMs over there, you can do that. And you could do it at the organization level rather than having to do each project, which is much nicer. We've got just-in-time access for AWS VMs. So it's not just an Azure thing anymore. I'm not gonna list all of these, but Defender for Cosmos DB is also GA now. And I'm gonna jump in and steal Michael's thunder.
We're also, Defender for Cloud is also offering protection for SQL servers running on AWS EC2, GCP Compute Engine, and a couple of other ones as well. So sorry, Michael, I know I shouldn't touch SQL because that's your baby. So, yeah, again, I'll link in the show notes. I'm not gonna... And then, of course, I've got to finish with my baby Sentinel. Not as many things to talk about, but our main thing is that we're really expanding our solutions marketplace.
That's the thing that comes under Content Hub. So we've got now... There's more than 175 solutions. If you don't know the difference, I'll just recap because I couldn't not... If you don't know the difference between a solution and a data connector, we used to very much focus on data connectors in Sentinel, but now we focus on solutions. So a solution is a data connector. It can also be workbooks, notebooks, analytics rules, hunting queries.
A solution is like the whole package of things that you need to work with a particular data source. And going forward, we'll definitely be talking about solutions rather than connectors. So go and check that out. We're also... Another thing that's gonna be really cool is we're gonna have a unified GitHub community for our CIM and SOAR and XDR because you may know, if you spend time in our GitHub, that Sentinel is currently separate for two defender. And of course, they are all...
They all work together and there are overlaps between the two. So we're actually gonna unify all of that into a new GitHub community, which is really nice. And I'm gonna stop there. That's my news for this time. Over to you, Michael. So in case you missed it, so Sarah just mentioned that SQL Server is my baby. So even though we announced this, I announced it briefly in episode 54. Yes, I've moved over now from working directly with our customers to the Azure database platform.
So I'm working on SQL Server, Azure SQL DB, Cosmos DB on the back end, security compliance, governments, all that sort of good stuff. So really nice low level engineering stuff. So I get to work on code and designs and threat models and that sort of stuff, which is right in my wheelhouse. I'm super excited for that move. It's also interesting, Sarah, that you mentioned Microsoft Entra. So something else that's not been talked about, but I'll mention it briefly.
So myself and two colleagues, Heinrich Ganssenbein and Simone Kurtz, are working on a book for Microsoft Press right now, tentatively entitled, Designing and Developing Secure Azure Solutions. We're on the last chapter right now, which is actually on identity. I left it to the last chapter on purpose because I'm absolutely terrified of the topic.
But as we're sort of writing this thing, next thing you know, this whole suite of products comes out that sort of wraps products that we're talking about, like as your active directory. So we've had to go through and make some little edits to the document. But yeah, so we're really excited about this book. Scott Guthrie is writing the forward for the book. We're gonna be covering design, development, compliance, cryptography, network for developers. We're gonna cover the whole gamut.
So I'm really excited for the book to come out. Not sure the exact date yet, but yeah, we're on the last chapter right now in terms of the drafts anyway. So I'm really excited about that. So on the topic of news, so I have a couple of items. Yes, thank you Sarah for stealing that one from me about the SQL Server databases on AWS. But anyway, first one is we now have some new server roles for Azure SQL Database and SQL Server 2022. These are in public preview.
They allow you to do certain levels of administration within the SQL Database without being an admin. And that is really cool because that is a great example of least privilege, right? I mean, historically there are some tasks that require you basically be the sys admin, come on in and do all these things. Well, the problem is a sys admin has basically unfettered access to absolutely everything. And that can be really problematic for some customers.
So now we have some new server roles that will allow you to grant people specific rights to do certain administrative tasks without being able to do everything else. So really granular access and that's really great to see. Another one, which is another one from SQL Server is we now have common criteria EAL4 certification for the SQL 19 series of products. So EAL4 is a big deal for certain customers, especially those in governments or in the military. They require certain levels of assurance.
Notice we say assurance. There's more to security than just security. There's basically trustworthyness of the system. And so we've now attained the EAL4 certification. Again, I'll provide notes for that in the show notes. We now also have, funnily enough, another SQL related news item. We now have import and export of SQL database using over private link.
So this is actually a big deal because right now for the import and export service requires you basically trust Azure services, which basically means you trust absolutely all the Azure services. And some customers just don't like that. So in public preview right now, we have private link support. And again, as I mentioned, there's some private podcasts that you'll see more and more PaaS offerings moved to using private link for their sort of network isolations story.
One other one is Azure Bastion now allows you to use IP based connections rather than just DNS names. This is just to make it easy for some types of customers who prefer to use IP addresses versus DNS names. Historically, it would only work with DNS names. And the last one talking of naming is as you container apps now has full support for custom domains in TLS certificates. So back in prior to now, you had to use sort of Azure wildcard certificates. Well, now you don't have to.
You can have your own custom domain and you can have your own TLS certificate in there. So that sort of wraps up the news. So now let's turn our attention to our guest. Thank you so much for joining us this week, Matt. Do you want to give us a quick overview of kind of what you do at Microsoft? Yeah, thanks again for having me.
So, so Matt Sosman, I've been at Microsoft 10 years, multiple roles, working in our consulting services division, worked in marketing for a while, worked in our field as a field seller. And now I'm over on the identity engineering team. And so my primary focus is the strategy for ISV partners when it comes to zero trust. So we'll talk a little bit about that today and what that means.
But I really try to think about zero trust all day long and see how we can go out and help our customers get out there and get secured. So that's a little bit about me. We've had two other people talking about zero trust and I always say the very same thing which I'm going to say right here, which is a lot of people see zero trust and they think, oh, that's just architecture, right? That's just some marketing speak, you know, some marketing speak for buying Microsoft products.
I don't agree with that. I've seen a lot of customers actually take a very, very practical view of zero trust. I've just been working recently with a bank, a large bank, looking at a zero trust sort of plan of attack for the next few years. And they're looking at very specific areas around zero trust and then adopting technologies, some of the technologies they already have. But one of the key things is doing like a gap analysis.
Let's find out where you're missing some defenses that can help sort of flesh out the zero trust story. So kind of what's your perspective on zero trust and how are you seeing customers practically use it? Yeah, it's a great question. You know, it's funny when you go out and talk to people, everybody has a kind of a different definition of zero trust and how they think about it. And different vendors out there have their own definition.
But for me, when I look at it, it's more around having a structure and a rhyme and a reason to your security program and making sure that it's set up in such a way that it actually enables the business. You know, oftentimes I've been doing IT for ongoing 20 years now. And oftentimes as an IT pro, we forget about, you know, what we're actually trying to do for the business.
And so, you know, with zero trust, it's around enabling users to be more productive, but also what are the business outcomes, right? In other words, what are you trying to do and why are you trying to do it? Let's not just lock down that SQL database because we can, what does it actually mean to do it? And how does that help us in the outcomes we're actually trying to drive as an example?
And so, you know, so when I think about my definition around it, it's how do we take those, the foundational principles to zero trust, right? Verify explicitly, use at least privilege access and assume breach. And how do we translate that into business terms that can allow the business to take advantage of the technology and not the other way around? And so one of the ways we do that is through meeting the customer where they're at.
And what that means, and we'll probably get more into this here in a little bit, but helping them understand how do we take that heterogeneous architecture you have and how do we help connect to the dots? So if you have technology from vendor A and technology from vendor B, how do we bring both of those together that can help your overall zero trust posture and help that program move forward? So that's kind of my overall approach to it and how I think about it. That makes complete sense.
And I'd like to sort of throw sort of my hat into the ring here and explain how we did it with this one bank that really, really resonated with the customer. And I'd like to sort of get your feeling. So as you mentioned, there are three pillars to zero trust, at least the way we talk about it at Microsoft. Number one is assume breach. By the way, these are in no particular order, but number one is assume breach. Number two is verify explicitly. And number three is lease privilege.
And then we have the sort of six major categories. So we have identity endpoints, applications, network, infrastructure and data. And so what I did for this customer was I said, okay, let's look at these six categories and let's look at the three pillars of zero trust and let's map what current products you have that sort of meet the goals of this intersection. And let's see where there are gaps. And so let me just pick on just on two, for example, verify explicitly and identity.
So what they were using there was as your active directory and conditional access. And that made absolute sense to me, right? So you've got conditional access policies coming into play and perhaps they may force the use of multifactual authentication for certain accounts or based on some signal that's coming in to say, hey, this guy's, you know, well, this person's logging in from a, you know, an interesting IP address. We need to prompt for a second fact or that kind of stuff.
Another one they have, which is really interesting is in the area of assume breach and data, they were using Microsoft information protection. The nice thing about that is, you know, if you assume breach and the attack is on the network and the attacker has access to everything, then the attacker only has access to the ciphertext, right? They don't have access to the plain text messages because everything is covered by a MIB policy and Microsoft information protection policy.
And what was really cool here is we took, what essentially ends up being these 18 sections, again, it's assume breach, verify explicitly and lease privilege. And then that was actually on the Y axis. And then on the X axis, we had identity, endpoints, applications, network, infrastructure and data. And we filled in each of those 18 sections and said, what do you currently have here? And then are there any gaps? And we actually found like four gaps that had absolutely nothing whatsoever.
And one of them was, for example, lease privilege and network. They actually had nothing to sort of restrict network access to, you know, lease privilege manner. And another one was actually lease privilege again and infrastructure.
So it was really interesting because this really gave the customer a nice insight into what they currently had in terms of services and both Microsoft and other vendors to see what they currently had, what their inventory looked like today and what they should do moving forward. And that made absolute sense to the customer because it's not sort of ethereal anymore, right?
You're sort of saying, here are these three parts of zero trust and here are these six, you know, things that we sort of focus on. What products or services do you have in each of those areas? One that they had, which turns out one thing they had a lot of for assuming breach, lease privilege and verify explicitly was like things like Microsoft Endpoint Protection. They made heavy use of that.
So, I mean, is that the sort of thing that, the sort of thinking that you're seeing some customers use or am I just totally off track and you've seen customers do other things? And by the way, I'm totally open to being said that, hey, what I did wasn't great. That's my hit. I'm here to learn as well. Personally, I don't think there's any right or wrong way, right? It's, you know, every customer is going to be different. Every organization's other group is going to be different.
And so they have to do what they need to do that works best for them. And so, you know, what you outlined, that sounds like a great approach for what their needs were and what they had to do. What I find interesting about it is, you kind of lose this, when you start peeling back the onion and you get into the technology, the technology is really cool.
I mean, I can geek out on that all day long, but what's even cooler about it is when we can distill that into terms that, dare I say, a business executive, something that's non-technical at the organization, i.e. the CIO, can actually understand to go tell the rest of the C-suite, that's when the magic starts to happen. I'll give you a great example. You talked about MIP a little bit. So, you know, over the pandemic, we saw the boom and work from home and work anywhere.
Yeah, people are starting to come back to the office, but we do see organizations out there that they're actually thinking about going 100% remote or majority of their work force being remote. And this is where previously, they never would have entertained it because the security team, you know, it's like, oh, that's too insecure. How would we ever even do this? But when you start to look at something like MIP, it encrypts the data. And so, I can send you whatever I want.
I could send you highly proprietary information, but it's encrypted, AES-256. Now, you have to have my identity to open it, and I would have to explicitly assign you permissions to open it. But the cool part about it is I could revoke that data. So, if I accidentally send you something and you have permissions to it, I can actually revoke it in flight with MIP. And there's all sorts of other controls around it, auditing and like even block screenshots.
Like, I mean, there's so many details there. Well, when you started to steal that, you take that to one of these executives. What we saw in a particular customer example I had in the last six months, where they're thinking about enabling more of their workforce to actually be permanently remote, they got a concern around, well, how do we prevent data from being accessed on personal devices, right? You're at home, you've got a personal computer right next to your work computer.
How are you preventing data spillage? Well, in comes MIP. And now, all of a sudden, the ideas start flying around. Here's how we can, we might be able to make this work kind of thing, right? And so, and that's where it gets excited. And then you start going above and beyond the other technologies. And that's where the use cases really start coming out of the woodwork. And the business starts seeing the potential and going back to my kind of my introduction there.
It's all about what are you trying to do and why are you trying to do it? But in business terms, how does this, what's the outcome for the business? How does it actually move us forward? Well, if I can enable my data to be securely accessed anywhere anytime, well, that enables me to, you know, work remotely like in this case. Now, all of a sudden, that enables all sorts of new outcomes, right? Think about contractors, think about vendors, even customers.
So what you did, I wouldn't say it's not wrong, right? It's absolutely right for those circumstances of that customer, but everybody's different. But it's a matter of getting creative, I think is my point. And that requires an understanding of what are you trying to actually do? Because there's so many times out there where you get into these conversations. And we're so deep in the technology, we kind of lose sight of the pot of gold into the rainbow, right?
We almost had to take a step back, regroup, and actually understand what's our objective. And if we get that clarity, then we could start to figure out, OK, now how do we use that technology to get there? So in your case, you did exactly that with MIPS and some of those other technologies. So that was kind of a long, long-winded answer. But that's kind of how I think about it. And everybody's different too.
And so that's where, if you don't have an understanding of the technology, it's not necessarily a bad thing. But that's where you need to get help. And you need to understand that, hey, maybe we need to bring in some outside help, a consultancy firm, or whoever that can come in to help you understand the technology that you already own. Now, yeah, I work for Microsoft, right? But let's pretend for a moment, you're my customer, Michael. And Sarah works at your company as well.
And obviously, you use Microsoft technologies, but you're going to use third-party security vendors as well, right? So now it's about having a deep understanding of how all those technologies work, and then figuring out how do we piece them together so we can achieve those business outcomes. And that's often the challenge. And again, that's kind of what I'm looking at here at Microsoft, is how do we help a customer stitch that together? Let me pause here, kind of going on a tangent here.
But that's how I'm thinking through it. Yeah, so back to this bank scenario. So at Microsoft, we have this zero-trust maturity sort of assessment. You talk about sort of the pragmatics of it. So what we do with this customer is we actually went through this maturity assessment. It's relatively short. And the whole point is to understand sort of how mature you are in these different areas, like what do you use for endpoint protection? Where is the endpoint protection?
What do you use for information protection? There's a whole bunch of stuff. And then from that, we end up, one of the outcomes of that is a whole bunch of user stories. So for example, you could load them into Azure DevOps or GRO and whatever your system is for managing stories or work items. Then you assign those to people and people go and investigate to find out what they have and where the gaps are and what have you. And that's why we end up coming with this grid, right?
With the shows, the three areas of zero trust and then these six categories. Because that then helps take these stories and assign them a point on this grid. So that way we could always find out who the right person was to assign them to. And again, that really helped drive the customer. I'm not going to be wrong, these customers, this customer is incredibly savvy. They just wanted some guidance on just the structure of zero trust. They like the idea of the three pillars of zero trust.
They like the idea of assuming breach. And that's a whole mental flip, assuming breach. I'll give you another example of that. I was working with a large bank in South America. I'm not going to name, even name the country. There's a very large bank in South America and they were going online with an online presence. And I was reviewing the security architecture of their design and we got to a point where they were storing passwords. And I'm like, so what are you actually storing?
And they said, well, we're encrypting. We're encrypting the passwords. So where's the key stored to decrypt that? Well, it's over there. It doesn't matter where over there is, it's over there. I said, but what happens if the attacker gets that key? Well, they can decrypt everything. Well, OK, so now we need to stop and think about this for a minute because let's assume breach. Let's just think about that for a minute.
Assume breach, the attacker is on the network and has unfettered access to absolutely everything. Well, now the attacker can decrypt every single password. And the customer nodded. Didn't like the fact they had to nod, but they nodded. I said, yeah, we need to think a little bit harder than that because you're a large bank and what you're doing is significant and will be attacked, guaranteed. So let's assume breach.
So I said, do you actually need to know the password or do you need to know the user owns the password? And I said, well, we just need to know the user owns the password. Well, rather than encrypting it, we can do it. I don't want to get into all the crypto wonkiness here, but I'm going to. We can store a what's called a salted iterated hash of the password. The nice thing about that is you can quickly verify the user possesses the password, but not actually store the password.
So now actually look at it from an assumed reach perspective. So if the attacker gets on the network and has absolutely unfettered access to absolutely everything, let's just say it's 10 million people, the data that the attacker gets is something the attacker cannot use. It's not the password. You can't decrypt it. There is no password to decrypt. You're just basically storing something that verifies the user actually owns the password. That's all you're doing.
It's nothing the attacker can replay. So they had about just a few weeks to go until they were finally shipping, and they made this small change. And it was a relatively small change. And obviously we had to go through all the appropriate checks and tests to make sure that it didn't cause regressions. But they ended up shipping with this change, or they went live with this change, I should say.
And we made a point of telling upper management that the change that was made, even though it was relatively late, supported zero trust ideas of assumed region. If the attacker is on the network, the attacker has nothing that they can use, nothing whatsoever. Doesn't matter by any stretch of anyone's imagination, there's just nothing you can use there. And the board loved that, especially when it was a very small engineering change. But the main change wasn't just the engineering change.
It was actually basically a mental change. Was it just thinking about the design of the system? Let's just assume the attacker is on the network and has access to absolutely everything. Now what? And if the answer is, well, we're in deep trouble, that's not the right answer. You need to think longer and harder than just, well, we're in trouble. So I like that idea of putting new concepts into people's heads because it will help you design systems in a much more secure manner.
Yeah, that's a great point. That's kind of what I meant by my comment around, if you were my customer, I may make a recommendation, bring in a consultancy firm to help you think through that. Because it is a huge mental mind shift to think about what if an attacker is actually on the network, what could be compromised right now that maybe we don't know about?
And when you start to think about in large enterprise, many of these legacy line of business apps, they were written years ago, the person, or Tina wrote it, they're long gone. It's just kind of, the lights are still being kept on, but nobody's really maintaining it. Well, when we start to think about assumed reach, it means a lot of different things. But one of it means, let's go back and start to review, are there passwords stored in the database?
How are these legacy apps functioning and architected? Do we need to start looking at maybe third party solutions that can help secure some of these apps that are legacy, that maybe the developer no longer supports or anything like that, but there's solutions out there that can help to protect those and specialize in it. So it causes you to start to think about a lot.
Another thing around assumed breach that I come across frequently is from a SOC perspective, are you actually monitoring the things that are important? So oftentimes we think about, oh, just send all the logs. Okay, that's, yes, that's helpful, but somebody has to put in the logic, and somebody has to write the workflows and all of the other automation pieces around, what do you do with that data coming from the logs?
Not only that, but you also have to think about manpower, and you have to think about how is your SOC structured? And the phrase that I keep hearing time and time again is if nobody's behind the wheel, or you have a couple of people behind the wheel, and you have a lot of wheels, you're probably gonna get alert fatigue, and you're gonna have gaps in visibility. So now how do we become more efficient?
And that's another lens of assumed breach, and how do we actually monitor when there is something going on? And making sure we have the right solutions in place from a technology perspective, make sure we have the right processes in place to respond to it. And it goes way beyond just looking at data in a log. And so that's kind of that other mental mind shift, for years we've been used to just send all of the syslog data to the SEM, and the SEM will deal with it. May not always be the case.
And so you definitely wanna go through and make sure that things are properly set up and that you've accounted for that. Mind if I share a quick story here about Zero Trust? Yeah, go for it. So back when the pandemic first started, and it was like the first week of March 20th, and the world sent everybody to work from home, we started having customers call us, phone was ringing off the hook, how do we do this?
There was one customer, they were a bank, they had this culture, they never actually sent people to work from home. So they actually all had desktop PCs, very old school, but they had desktop PCs, and okay, now we all gotta work from home. And this was not a large enterprise, this was more of a mid-sized organization, but it was a big struggle for them. So they went out and told their employees, just go out and here's a stipend, go out there and buy the laptop of choice.
We started having people buy iPads and Macs and PCs and who knows what. And then they started figuring out, well, with the pandemic came the Great Reshuffle and the Great Resignations, and some of these employees started leaving the organization. Well, here they have a personal device that they are using to access company data on. They now left the organization, the company data is still there. So you've left the organization, but you still have data on the device.
Now, have they been using MIPS? Sure, that would have helped provide some protection. So make a long story short, we started working through some scenarios with them and what we came to the conclusion was, let the employee go out there and purchase whatever device they want with that stipend, but let's employ something like Azure Virtual Desktop or some kind of VDI, where everything you're accessing is within that workspace. And you can't spill data outside that workspace.
So if I'm on my personal iPad and I try to copy a file from that Azure Virtual Desktop to my local iPad, policy will block it. So we started looking at that with that customer and make a long story short, I just talked to them about three or four months ago.
You're doing quite well from a security perspective because everything is happening within that Azure Virtual Desktop kind of instance, if you will, everything's being monitored and they've got policy where they can actually control the flow of data. And if employee leaves the organization, their standard process of killing email access, of course, but then killing access that Azure Virtual Desktop instance.
So that's another way of looking at zero trust is kind of containerizing how your employees access the data. One more short story for you is kind of the opposite. How do we give the employee the ability to do whatever they want? And so we had another organization during the pandemic that went out, they purchased Microsoft 365 and they got all the great productivity tools.
One of the really cool parts about security that Microsoft has, like MIP as an example, it's actually integrated with all the tools. For this organization, they never had to actually think about how do we get MIP encryption to work in an office? It just works, right? I mean, sure, there's policy, you have to configure and that kind of thing, but you're not having to go out and make code changes or anything like that, API calls and that kind of thing.
So what I'm trying to say is, again, you have to kind of look at what are you trying to actually get done and how does it actually help the business? And then from there, try to figure out the right technology. Now, what we often hear is, man, I'm not using everything that's from Microsoft, right? Sure, I've got maybe Sentinel or I've got MIP as an example, but I might be using a third-party EDR platform. I may be using a third-party identity provider. How do I get all of those to work together?
And so that's where, here at Microsoft, we've got a program called MISA, the Microsoft Intelligence Security Association, where we've gone out and we've worked with these third parties to perform native integrations with our first-party products and kind of analogy of we're able to tie the knot together. So if you're using a third-party, whatever, third-party EDR platform, how do we make sure it works with the rest of your Microsoft tool sets?
Well, through that MISA program, we've gone out and done that work. And so that can help benefit those customers out there that have that heterogeneous architecture without having to worry about, oh, do I need to go out and flesh out everything for vendor A to vendor B and that kind of thing? Let's take a look at it, because more than likely what you already own is included at MISA program, where we actually already have pre-billed integrations that just need to be enabled and configured.
So again, that's kind of another way to look at zero trust and that last mile, but that's often your biggest risk. And so just wrap my tangent here. You could do everything that you can to try to protect it and try to get these policies configured, but that last mile is still going to be a problem for you. Whether that last mile is third-party solutions, try to integrate with Microsoft first-party, or it's the end user. And like an example I gave about them using personal devices.
And so as IT, that's something that we often don't really think about. And so I think kind of the moral of all these stories is bringing it back to zero trust is a mindset change. And it's not a product, you don't go out and buy it. It's not an end state. It's not a, hey, how long will it take us to achieve zero trust? It's what's our structure and our framework? What's the journey look like that we're going to take? And how are we going to do it?
And what changes need to be made in the organization to allow us to do it, not just with technology, but organizationally as well. So lots to think about, but I'll pause there. I'm going to have to jump in here because you talked about SOCs and as a security operation center. Matt, what's your take? Because you know I love to talk about Sentinel. Everybody knows that.
Going back more to that, because one of my favorite phrases, and I used to have stickers with it on, and I need to get them reprinted, is that collection is not detection. You know, just collecting logs is not in itself going to do anything. So what are your thoughts on that, assuming breach and collecting logs in that security operations environment?
I mean, if we rewind 10, even 20 years, right, and we look at sending log data to a SEM, SEM seemed, you know, whatever we want to call it, right, but send it to that centralized platform that collects all the log data. Somebody still has to look at that. And so we started to think about years ago, well, let's hire the best talent.
Let's send to Vegas every year, go to the conferences from the vendor, throw all the certifications at them, and then they can go through the log data and try to figure it out. Well, fast forward, that didn't work out too well, because no human can possibly go through the massive volume in these logs, right? So that doesn't work. So now we need machine learning to look at patterns. We need, you know, artificial intelligence to be able to make decisions.
But we also still need humans that possess the skill to build out the policy. So like in Sentinel terms, analytic rules. So I've got all this data that's coming in from this, you know, security tool, all this log data. Sentinel can, you know, obviously, and so you could talk way more about this on IKAM, but it's intelligent. But however, there's probably some additional context around that log data that I would need to build some rules in so that Sentinel's aware of it.
So my point is like somebody has to do the work. And then on top of that, somebody has to be behind the wheel to actually monitor. And so I once met a managed service provider just a couple of years ago. They did all of this work to send, and they weren't using Sentinel. They were using another SIM, but they did all this work to send all of their log data from all their tools to a SIM. But they didn't have anybody actually monitoring it. They were relying on just email alerts.
It's like, well, it's a little bit more to it than that, right? And so you don't want to also get that false sense of security, right? Oh, we'll just send it all to the SIM and be done with it. But you know, there's a lot more that you need to invest in that from time and energy to be able to build this out in such a way, but then have that process to make a green field to where you're constantly iterating on it and you're documenting it, right?
And then what's the reporting structure around it, right? How often are you sitting down, running the reports and sitting down if you're a managed service provider running with your clients or sitting down with the SOC and maybe the CSO and reviewing what's happened over this past quarter according to the data and trying to do better, right? So I mean, there's a lot that goes in there that, again, that assumed reachment mindset and the whole zero trust mindset, it starts to unpack all of that.
But, you know, Sarah, I would love to get your thoughts on that, but that's how I start to think about just from a SOC perspective. We got to do it differently than we have been. I think it's my point. Yeah, I mean, we probably don't have enough time on the podcast right now for me to talk about all of my thoughts, but I'll tell you a story as well. Seeing as we're in story mode this week. I once saw a couple and again, it wasn't Sentinel, it was a different scene.
But in some of my previous consulting life, they had some organizations that were working to a particular standard that was part of their industry vertical. And the standard basically said that they needed to log to a central place. And so they locked to a central place that they put a seam in place and they were sending logs to it, but they didn't actually look at it.
But because the requirement that the standard they were following just said they had to log it, they had met that standard that they could tick a box. Was it really very useful from a security perspective? I would argue definitely not. But these are the things we see, right? And definitely we can have a whole different discussion on standards and whether adhering to standards, well, compliance, well, compliance is not security. That's probably an episode in itself.
But yeah, I know exactly what you mean. Yeah, you know, again, like when I think of my, when you talk about, you know, how do I approach your trust differently than maybe others? I think everybody has their own approach to it, right? But again, like my approach, I look at it from a practical standpoint, but more from a business standpoint. And how do we actually make this work for the organization? How does it help us move things forward?
And in many cases, we've seen Zero Trust do wonderful things at a business level, right? I.e. enable a company to outsource more. If that was their end goal was let's outsource more, but security was stopping it. We've seen Zero Trust actually empower that and enable that and drive that.
We've seen Zero Trust do things like help the company acquire more customers, because now they're able to, you know, interact with customers in a digital way and Zero Trust comes in and provides a security layer for that. So we've seen all sorts of great use cases, but you do have to take a step back and think about, you know, what are we trying to do and why? Really, why is the most important part? You probably want to start with that. But it does require almost a rewrite of the book.
And it's tough for me to say, because I've been an IT professional most of my career, but you do need to make sure that leadership is on board and making sure that not only are you making technical changes, but also make an organizational changes, i.e. strategy and mindset shift and cultural shift and all of those things, if you really want Zero Trust to have an impact. So it's interesting to bring that up. So Sarah and I actually have had a conversation over the last week or so.
Like if you look at the audit logs that come out of SQL Server or Azure SQL DB, they're pretty hard to understand unless you actually know what each of the line items means.
But, you know, when you fold in some of the kind of intelligence that's built into Sentinel, the fact that it's got functionality built into it to actually make sense of SQL logs, again, it just makes so much more sense about what's going on in your Azure SQL DB or your SQL MI or your SQL Server on-prem or in a VM, it makes so much more sense so you actually understand precisely what's going on. Make no mistake, those things can produce absolutely massive series of logs.
And so, yeah, it's great to see tools like Sentinel making sense of all that. Alright Matt, so one question that we ask all our guests is if you had just one thought to leave our listeners with, what would it be? You know, I'm going to be really simple. Great question. Just do the basics. If you go out and you read the breach reports from Verizon and Microsoft and IBM and whoever, usually what you'll find in the root cause of these data breaches is the basics were missed.
Identity hygiene or patching of systems. Again, it's hard for me to say as an IT pro, but you want to almost take a step back and figure out where we're missing on the basics. And let's go back in and make sure we are covering the basics first. And I mean basics, right? If it's making sure you've got multi-factor authentication deployed for every user, go through and double check kind of thing, right? Or your patching program or whatever it may be, password stored in a database.
So that's kind of the final thought I'll leave is just make sure you're doing the basics. And as you go through that journey, you will like, guarantee you will start to figure out additional things that you can add to that roadmap and then start building up your zero trust strategy. So that's what I'll leave us with. Yeah, thanks for that. I think, yeah, people need to, you know, perhaps not take a cynical approach to zero trust. It's not a marketing term.
It's not a, but it's by the same token, it's not a product. It's not a product Microsoft will sell to you. It's a series of practices. It's a series of technologies. It's a series of tools. It's a series of mindsets with a goal of sort of protecting environments and this sort of this modern world, you know, within which we live. So again, thank you so much for taking the time to see us this week. And to all our listeners out there, stay safe 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.