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 70. This week, it's just myself, Michael and Sarah. We're here with two guests, Beau Fahl and Lou McCurry, who are here to talk to us about Microsoft Purview. But before we get to our guests, let's take a quick lap around the news. Sarah, why don't you kick things off?
A couple of really cool new features in Defender for Cloud that it's worth going to have a look at, which is the Attack Path blade and also the Cloud Security Explorer. So if you're using Defender for Cloud, the Attack Path will actually use your environment context to look at your security issues and it will tell you which things are the biggest security risks, which obviously is important because we can't fix everything all the time immediately, so it will help you prioritize.
So that's one thing you should go and look at. The other one is the Cloud Security Explorer, which will allow you to, again, go and run graph-based queries on the Cloud Security graph around identifying risks, which is another way of getting information out of Defender for Cloud about your security posture, if that's something that you need to do. And then moving on to my favorite, which is, of course, my baby, Azure Sentinel or Microsoft Sentinel even.
It's not had that name for a while, but I think the big one I wanted to shout out here is that the Microsoft 365 Defender data connector is finally GA. For those of you who have been following this saga or use Sentinel, you know that the Microsoft 365 Defender data connector has been in public preview for a very long time and some organizations will not use it until it is GA. So if you're one of those people, hooray, it is here.
The other two things come out recently that I wanted to call out is scheduling for analytics rules, which means it's in preview, but what it means is that you can actually schedule your analytics rules execution times. You didn't used to be able to do this. When you clicked go on your create in Sentinel, the analytics rule would start running and then it would have a defined frequency, but you couldn't set the exact time that you wanted it to run.
You could try and do it awkwardly hitting the create button, but it didn't work well. But now we have a way that you can actually do that scheduling, which is awesome. And I'm going to leave it at that for Sentinel. There's a couple of other things. Make sure you go to aka.ms slash as new for all the new Sentinel stuff.
We've also had some new announcements in the purview side of things, but rather than me talk about that, I think that that would be something I will leave when we get to our guests. That's everything from me for the news this time, Michael. You only have one item. One of the things I'm a huge fan of, Trusted Launch for VMs is now available for US government regions. If you're not familiar with Trusted Launch, Trusted Launch uses virtual TPMs.
It's a really foundational technology that's built into Windows, just this notion of Trusted Launch. It helps mitigate things like bootkits and rootkits, allows you to use credential guard. It also allows you to address some critical Department of Defense STIG requirements. STIGs are essentially documents that are used by the government for making sure that they're adhering to appropriate security practices. So this is really great to see.
So it's general availability for Trusted Launch for Azure VMs in Azure for US government regions, which is great to see. Michael, I have to interrupt you there because I have trauma related to STIGs. In a previous job years and years ago, I know of the STIGs because we used to use them to manually assess the security of virtual machines for our customers. That was horrible. So I just wanted to add that in. That's why I know what STIGs are.
They are great documents, by the way, but I don't recommend doing a manual assessment on them. I actually worked on one of the STIGs for secure software development back in the day. That was actually a lot of fun doing it with DISA to produce this document. So yeah, I'm a huge fan of STIGs. They're very complete, but I would agree they can be complex. And if you're doing it manually, they can be less than optimal. All right. So now let's turn our attention to our guests.
As I mentioned, we have Bo and Lou here to talk to us about Microsoft Purview. Now before we get on to that discussion, here's an interesting fun fact. I actually work in the Azure Data Team, security engineering, and we technically have Purview within our sort of Ballywig. So I'm interested to see what you gentlemen have to talk about because as far as I'm concerned, we do Purview. So it'll be really interesting to see what...
I'm not a marketing guy by any stretch, so let's see what you guys have got to say. So Bo and Lou, again, thank you so much for joining us on the podcast. We'd like to spend a moment and introduce yourself. It's good to be here, Michael. We all do Purview. That's the reality of it. So I'm Lou McCurry. I'm on the East Coast of Australia here looking after the risk and compliance solutions within the Purview stack. I'm one of the technical specialists here.
And Bo is my colleague over there in Perth. Yeah. How's it going, everyone? So I'm Bo Foll. I'm a technology specialist alongside Lou. I operate out of Perth, Western Australia, and I look after the Purview stack as well. It's just interesting on that point you made, Michael, around the Purview name, if you like. It's a bit of a marketing exercise at the moment because what's actually happened is Microsoft Purview itself relates to a collection of solutions rather than a product name now.
So what you would have thought of as Azure Purview in the past is actually is now referred to as data map, data catalog, or data estate insights, or the data governance side of the equation. Bo and I work on the other side of the Purview solutions stack in the risk and compliance solutions, the data risk stuff. So things relating to DLP, information protection, et cetera, those sorts of solutions. But collectively, it's all now under the Microsoft Purview family name. OK, that's good to know.
I'm going to be honest with you. I was really confused when we first started. Again, I'm really happy. I'm a nerd and not a marketing guy. OK, Sarah, why don't you kick it off in terms of, let's see what these guys have got to say. Bo and Lou, for the uninitiated, just for a level set before we get into it, what is Purview and why should people care about it as well?
Yeah, so I guess briefly speaking, it's had that rebrand that Lou was talking about before where they joined the old compliance section within M365 with the Azure Purview section and made one complete product. So I guess while we're talking about what it is and why people care about it, it is more aligned to, I guess, a data security conversation. It used to be a more compliance focused.
And I think that message has landed the wrong way so that a group of those technologies, we would be having the wrong target audience when we're having those conversations. A lot of it comes down to the fact that data security is the pure focus and you can get compliance out of it, but it encompasses a bunch of different technologies.
So there's things like information protection, where we have a look at classifying and placing protective controls on that information, like, for example, encrypting it to specific users or groups. It has data loss prevention. So that's to help data exfiltration, as most of us already know, whether that's accidental or malicious, and there's been some big changes announced recently that we'll have a chat about later.
It's got insider risk, and this is kind of like what we want to call as our same within M365. So it correlates other information within the tenant to assign a risk level to a user based on behavior. Let's say there might be a typical exfiltration sequence that gets detected where someone's put in their resignation, they've downloaded a bunch of information from SharePoint, and then they've copied it across to a USB.
That will alert, we'll get telemetry on that as well, and that can also be fed into things like Sentinel, for example. There's things like comms compliance. So this is part of insider risk, and it gives us more visibility in alerting into comms platforms for things like harassment. And that goes into Teams, it goes into Exchange, we can put it into third party products with data connectors.
And I guess the final last little bits in there is there's information governance, which is kind of tied to what we normally call our records management or ADRMS related capabilities. So that allows us to put controls over data and use automatic workflows to retain or delete data at a particular time. And that helps with things like data hoarding, for example. And I guess the last bit in here that is actually focused on compliance is compliance manager.
So that's where we use built in templates to measure and track an organization's compliance to a specific regulation. So for example, ISO 27001. So as you can see, there's a lot of technologies and disciplines in there. So it's good just to touch base on what they can do and what they can accomplish. Yeah, but I might add to that because we do have a lot of individual solutions within the purview stack there.
But you know, I want to stress the point that it is an integrated platform, and it does work seamlessly. And it might help to think about, I guess, the risks that we're trying to mitigate with these solutions. But if you think about the kind of collaboration our customers are doing these days where you're dealing with sensitive information, which might come into an organization via an email.
So that email comes into an organization, it might contain some PII or some other sensitive information within an organization. Oftentimes that information will be exchanged via messaging. And there's risks here of data leakage within an organization. That information ends up somewhere within shared storage, so within SharePoint. And it's there for the sake of secure collaboration. But there's still a risk here of data exposure.
From here, there's also that risk, the insider threat risk that Bo sort of spoke to where there's a risk that people might start offloading this to personal cloud storage locations. So there's some data theft potential here, whether it's malicious or accidental.
And even at the end point itself, offloading or moving files across USB keys or even physically printing sensitive information, especially in the context of people working from home with personal devices and God knows who's living with them in their household. So who's seeing this hard copy?
So with all of that risk, if you like, the idea is within that purview stack is that the solutions, individual solutions Bo was speaking to do actually inform each other, they work together, they provide insights all the way through that stack. Basically, what I'm hearing here, and I know you've given us a really good overview there, both of you, is that actually, because I always thought, honestly, that purview is just a compliance thing. And actually, that's a part of it.
But in fact, that data security piece is probably way, way more important and kind of a bigger part of the product. There was a misconception that when it was called compliance, that was its core focus. It was a tool to meet regulatory compliance, for example. But really, it's all about that data security or data protection side of things. So I think it's more of a byproduct. So these things can achieve compliance in terms of regulation, but it's more about securing the data itself.
So like information protection, for example, when we encrypt our data, that can achieve a compliance regulation obligation that we need to meet. But the core focus we're actually trying to do in that situation is safeguarding and protecting that data. So I think in general, the language that we, as Microsoft and the industry itself, has to change in relation to that. It's not purely a compliance focus.
We need to make sure that those conversations we're having are about data security or data protection, because that's what we're actually looking to protect going forward. But we have a lot of conversations where we're speaking about compliance and the audience thinks we're there to focus about regulations. So in the typical sense, we'll end up with the wrong people in that room.
So we'll end up with people like auditors or regulators instead of people that are actually looking to safeguard that information. But really, we kind of need to have those conversations with the CSO, privacy officers, or like SecOps instead of a typical compliance crowd. We've got a lot of stories where we'll go in to speak to a customer or to a different audience. And then they'll realize and we'll realize that we're speaking about two completely different things.
So the language you're using here is really important. Yeah. But the risks are the same. And that's the interesting thing as well, because I'm finding my job at the moment is much more interesting and rewarding than it's been for a long time, because those risks that I was talking about earlier don't change. But the difference in audience means that we need to satisfy different requirements.
So I'm talking to people about how to implement these DRP controls and how to put in place protective markings with encryption and how to secure SharePoint sites. And we're having that conversation because they've got operational requirements and they've got a real threat they're trying to mitigate. But then I'll have the same conversation with a different audience who are more compliance focused. And for them, it's about aligning those controls with some regulatory framework.
So we're still talking about the same thing, but the motivations are different. For them, it's all about we've got an audit coming and I've got to be able to prove that we're actually going to be able to satisfy and secure our data. But it all comes back to the same purview solution stack, if you like. All right. So I have a few questions slash comments slash observations. So you mentioned SharePoint a few times, but this is not restricted to protecting data that's in SharePoint, right?
Like I could have a blob store and it has your blob store and assign labels and so on to that, to the data that's in a blob store, is that right? Like it can be in many, many places, not just SharePoint. Yeah, spot on. So it goes by default out of the box. It goes into all of the M365 areas, SharePoint Teams, Exchange, OneDrive, Yammer.
With the Azure purview side of things that we spoke about before, that's where we can do things like extending those sensitivity labels under information protection across into things like storage blobs, SQL databases, S3 buckets. That's how we can extend it over. So we can do things like if the system anywhere detects something like a credit card, let's put a highly confidential sensitivity label across onto that data.
That can do things like encryption or it can do things like watermarking or safeguarding that data for reporting as well. Yeah. My colleague, Andreas Walter, actually wrote a blog post that came out about a month ago on integration with purview policies and SQL, which is all pretty cool stuff. So that's question number one and the observation as well. You also said DLP, data loss prevention. But don't we already have a product that does that? I can add to that as well. It is purview.
So that data loss prevention is part of the purview stack? Oh, part of the purview family. So we're just sort of rebranding it and bring it all under one governance umbrella. Yeah, spot on. So it used to be called within M365, the compliance stack. Okay. Now all of that stuff that was compliance previously, so things like data loss prevention, insider risk, information protection, that's all under the purview family umbrella now.
Okay. So it's a little bit like, okay, this is again, I'm not a marketing person as well. So what Entra is to identity, purview is to like compliance management of data. Is that a fair analogy? Yes. Risk and data governance, yeah. Spot on. The challenge here, Michael, is the fact that all of these individual solutions we're talking about, you know, data protection, DLP, et cetera, they're evolving as well.
So if I come back briefly to sensitivity labels, you know, in the past, this was exclusively about putting a label on a Word document or an email, a little drop thing for sensitivity labeling, confidential versus personal, et cetera. We can do so much more with these labels now, including what we've just talked about. But we have this ability now to do container labeling versus content labeling. So all the traditional ways of applying a label to a document or an email, et cetera.
But now we can create a label within our stack that exposes into your side of the equation, if you like, within the data governance side of things. But also that label can actually apply to Microsoft 365 Groups. We can apply a label to a Teams meeting. We can apply a label to a Teams channel. These labels are a way of identifying sensitive information or sensitive locations that need to be managed in some way.
So when that label is applied to a Teams channel, for example, it doesn't apply markings, but it controls whether or not you can invite external guests and what happens with the documents within that channel and the Teams chats and so on and so forth. But the main point here, without overcomplicating it, is that what we're doing is centralizing all of that. So the definition of what is sensitive for my organization is done once.
And I create that once on our site, in our console, if you like, because that never changes. And then now that I've defined what is sensitive, the second part of that conversation, how do I control this information when it's in the SQL database, when it's being discussed in a Teams chat, when it's being exchanged within a SharePoint site? And DLP is a similar thing as well, because we now have what we refer to as unified DLP. So it's much more than just transport rules in exchange now.
DLP spans endpoint DLP. We reach into the CASB as well. So we've got file policies that we generate from outside that come from the same console. There's DLP that applies to Power BI, there's DLP that applies to Teams chat, it goes on and on. So our traditional understanding of some of these solutions is kind of evolving as well, which makes it a lot of fun, especially when I'm talking to customers who've been using a lot of these solutions for a long time.
Because in those cases, it's often a bit of an awakening. Is something you're probably not aware you have access to? There's so much more control here and capability. What does a day in Per-View look like? Here I am, I'm in charge of data governance. And what would my day look like? What things would I be administering? What alerts would I be looking for? What policies would I be setting? I'm just curious.
So typically, if you've got that capability, all of that telemetry is going into the insider risk engine. So all of those DLP alerts, all of the MIP access. So then life with like a Per-View admin, for example, is we'd be focusing on the insider risk portal and generating alerts out of that. Then you can do your investigations.
For example, with an insider risk, if we've detected something, let's say we've hooked it into the HR system, someone's resigned, they've then dumped a bunch of SharePoint information onto a USB drive and we've blocked it, for example. We can then automatically do that investigation.
We can reach out into eDiscovery, for example, which is our electronic discovery product within Per-View, and we can lock down all that information that users touched and keep that evidence put across so that we can actually do that further investigation. So it's more depending on where you are within an environment, you can do that alerting and that monitoring from insider risk.
A lot of the other time, it might be, for example, you might be a records manager and you're looking after the information governance side of things. So there's particular regulations or information like credit card data that you shouldn't keep for longer than you need to.
So the system could be built to say, if we've got credit card information that hasn't been accessed for seven years, for example, trigger what's called a disposition review where someone will come in and review that information and then delete it automatically.
I think part of the Per-View instance is that it's so broad and covers so many different groups and organizations within a business that depending on what product and what your actual information you're trying to look after, your day to day will be different. Yeah, I find often I'm also just walking customers back and just getting back to the fundamentals. So describe your workflow, describe your information flow, because it's possible to start the very basic level.
And, you know, let's talk about a user who is jumping into SharePoint, downgrading the sensitivity of the document so that they can then download it and then exfiltrate the content. Now, everything I just described will be visible within auditing. So how do I know this is happening? How can I be alerted of it? Well, you can jump into the audit log and have a look at the raw data and try and correlate what's going on and connect the dots.
The next step up is to say, well, let's put some DLP policy in there to control that. So now I'm generating DLP alerts, which might get a bit noisy, frankly, but at the same time, you know, they're going to be informative. And I've got an operational task now to manage these DLP alerts and investigate those. The next step up to Bo's point is that let's look at all that activity and let's be a bit clever about this and actually generate some insight as opposed to just raw alerts.
So tell me what my people are doing and where's all this information going and where do I prioritize my attention? And with all that in mind, give me one alert when something I really care about is happening. And I'll drill down from the top within insider risk management. And I can see that I've got an insider threat going on with this particular user. As I drill down the stack, I'll then get to the DLP alerts, which may or may not have been responded to.
And then if I need more detail, drill down into the audit log and actually see the all the activity, date, time, you know, where's it happening from, et cetera. That for me is I think the value of when we talk about purview collectively, it's that conversation about purview as opposed to having four separate conversations with four different groups of people.
One about data auditing, the second one about information protection, the third one about DLP and potentially two different people with different policies. Rather having four conversations, let's have one. Tell me what the risk is. Let's think about that and we work top down. Yeah, and it comes down a lot like because we target or we have those conversations with so many different target audiences within a business. Let's say eDiscovery, for example, might be legal or HR.
Same with something like communications compliance. If we're looking for harassment, for example, that might be a HR job. That SecOps might be more concerned on data loss prevention and what's being exfiltrated. Whereas, like I said before, the data governance side of thing might be those records managers or privacy officers within an organization. It's very broad. Actually, this makes Sarah happy. That alert that I'm talking about with an insider risk can be pumped out to Sentinel.
Then you can do correlation against other services outside of the Microsoft 365 stack and just go deeper if you need to. That makes me very happy. I've got a question.
For those of us, you've already touched on this, but when I think DLP, it reminds me of as an end user, it reminds me of that old school network based DLP where one of the employers I used to work for, basically all you had to do was, let's be honest, all you had to do was zip up a file, put it in a zip file, and then you could email it out.
I have had a play around with Purview and I know it's a lot more smart than that, but I wondered if you could just tell me about how much more smart it is than that old, you know, network based DLP that probably quite a few people who are listening are familiar with. Yeah. Our DLP solution goes across N365. It can go out into the inbuilt agent within Windows as well with endpoint DLP to detect things like copying something across to a USB.
All of these different bits of technology tie into a central area called sensitive information types. We have over, I think, 300 in the system at the moment covering things like credit card information, Australia's driver's licenses, things like that, depending on your country. We can use those as well within DLP to automatically find, classify, and block that data from being shared. As of a couple of days ago as well, we announced something called adaptive protection.
Within our DLP engine, it can talk to inside risk. Inside risk, depending on a person's behavior within an organization, can assign that user a risk level. Let's say they've done a bunch of dodgy behavior over time. They're at a high risk level. We can adaptively put a DLP policy across to every user that has a high risk level. We can say, if you're a high risk user, automatically put in a DLP action where they can't share anything externally at all.
Whereas, if we're a medium risk, let's say they've got to do an override when they try to share and put a justification in. If you're a low risk user, you can share that information externally, depending on what that information is. I think that adaptive protection step up is a bit of a game changer for us.
With that tie into inside risk, because we have all that new telemetry, we were able to automate that assignment of DLP policies instead of someone manually finding out a user is risky and having to move them into those different policies manually. That's a big difference for us. Yeah. That's a massive update actually, because your risk level is dynamic as well.
I might be able to copy stuff over to my USB key today and get endpoint DLP giving me a warning, like a tool tip if you like, and I can dismiss that and just go my merry way. But if all of a sudden, let's say for argument's sake, I tend my resignation or I'm doing something else that's dodgy, it will adapt. What I was able to do yesterday is no longer possible. I'm now being blocked from copying across.
One of the nice things with this new capability is our ability to go back on existing DLP policies. One of the challenges we've seen from customers is if they're too stringent with DLP, it gets really noisy and users get frustrated. When people higher up in the food chain complain, often the response is dumb down the policy and just weaken it. Let's just drop it back from block to warn instead. There's a real risk there in doing that.
By going back to those policies and actually making them adaptive, what happens is we will block when it's justified, but we will drop it back to just a warning to keep everybody happy and productive. It's the best of both worlds. It's all very well labeling an object saying, hey, this document is sensitive or whatever, but that doesn't really count for much really unless the data is encrypted. If it is sensitive, you want to really encrypt it.
Can I automatically encrypt something that's detected as being sensitive? There's multiple stages that we can apply to information protection. The first one typically is discovery where we look at your data estate after you've defined your sensitive information types. As Bo has mentioned, we've got over 300 out of the box ones and you can add your own. You get a sense of, well, there's all my PII and there's all my stuff.
The next step is to say, well, we're going to map these sensitive information types to this label. What does confidential mean? Anything with a credit card number is confidential. Anything with this is confidential, et cetera. You then end up with the ability to apply that protective marking onto a document. Within the same policy builder, there's an option to say, now let's encrypt it as well and control people's access to this based on groups. It's very flexible.
You can give part of the organization co-author rights and other parts read-only access and other parts of the organization zero access. It's protection that travels with that content, which is really important. Now, I was having this conversation with a customer and they were walking through their console while we were talking and I was demonstrating as well.
They did a bit of the click through and I got to the point where I said, and this is where you can see where your labels are currently applied. As you can see in my demo environment, I've got confidential applied to 4,500 emails. They said, oh, we've got 15,000 emails that have left our organization all marked as confidential. Then I said, but I'm okay with that because all my emails are protected with encryption. They said, oh, we haven't gotten to that bit yet.
The problem with that is that their end users doing the right thing are creating emails and dragging attachments in, sending them externally and applying a label called confidential, which is a marking only and hitting send without any encryption or protection on that content. That's a problem. It's a long answer to your question, Michael, but yes, we can do automatic encryption. Hopefully through that little anecdote, the important thing is that's even more obvious.
Yeah. The number of times I've seen an email flying across the wire where it said, this document is proprietary and confidential, but it's not encrypted. A lot of the time it'll come down to the organization's maturity as well. They get a bit worried that if they start encrypting things, people will lose access and that's not really the case. We can specify, for example, let's say the SOC group within AD has full access to these documents. They can do whatever they want.
Everyone else in the organization has read-only access, so they can't print it, they can't forward it, they can't send it. As long as you go through that activity at the beginning to map those controls against those sensitivity labels, it's not like you're going to get locked out of the document entirely. You're still going to have access. You're still going to be able to do your work.
It's just making sure they're at that level where they're comfortable and moving forward and putting encryption across everything. I'm not even going to go down the rabbit hole of key management, but that can be another conversation for another day. My guess is that the key management is pretty much handled by Purview, so you don't have to because it could become a complete nightmare. Correct. We can do bring your own key. There are options there for that as well, but you're right.
Folks, I know that there were some Purview announcements this week, well, the week that we're recording this. Do you want to tell our listeners a little bit about some of those new things that we've just announced? The key thing I want to stress is that adaptive protection that we have now. I think that's a big game changer for us and that the way that we have Purview with its integration, as far as I'm aware, I don't think anyone else can deliver that capability.
That saves a lot of time in manually managing your DLP policies. I know a lot of, at least the customers that I speak to, are really keen for it. That's currently in public preview, so everyone should be getting access to it. If not already, it'll be coming really shortly to your tenant. Definitely worth having a play with. Just a quick reminder, we do all that without any agents. Zero deployment. That is cool because people hate installing agents. Agreed. Agents sometimes worry me as well.
I've seen many vulnerabilities in agents over the years, so. In a previous life, I was rolling out a capability. I was a desktop service owner and I had a KPI on agent health, which speaks to the problem with agents. Forget about the solution we're rolling out. It was all about the health of the agent. The ability to actually implement the solution itself was secondary.
So, Bo and Lou, the thing that we always ask our guests before we finish is, if you had a final thought that you wanted to leave our listeners with, what would it be? I guess the thing I kind of speak about a lot is don't focus on purview being purely compliance focused. Focus it being data protection and data security.
We need to make sure that when we're using that language, we're having conversations with the right people, but the focus is to make sure that data that we are holding as organizations is protected and that we're not keeping it longer than it needs to be. If we're doing that and we're doing it correctly, it puts everyone in a better place moving forward. Yeah, my final thought is don't think about the product name. Think about the risk.
So, when I have customers coming looking for a DLP conversation, in reality, it's an inside of threat conversation and DLP is one of the possible outcomes of that conversation in terms of control. There's a lot of capability there. Well, let's bring this episode to an end. Bo and Lou, thanks so much for joining us this week. I know you guys are very busy. From my perspective, we look after some parts of purview and those guys are really, really busy. So, again, thank you so much for joining us.
To all our listeners out there, we hope you found this useful. 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 AzureSecPod. Background music is from ccmixtr.com and licensed under the Creative Commons license.