Taming Permissions Gone Wild: Building an Entra ID Application Governance Framework

What in the Sam Hill is happening? PowerPoint is prompting me for permissions to advance to the next slide? Of course I want to advance to the next slide. Okay. Let's accept it. Let's just get through the presentation. Oh, wait. Should I consent on behalf of my organization? What does that even mean? Okay. Alright. Sorry about that. Moving on. Again, of course, I wanna play the blasted animations. Wait, what are those other permissions? View your basic profile, maintain access to data you've given it access to, whatever. Just accept, get going. This isn't even a demo disaster. This is a PowerPoint poop. All right. Sorry about that. Isaiah needs access to session eyes. Okay. I'll take care of that later. Isaiah again. Graphite p x four. Oh, k. Maybe I can walk this under the presentation. Sorry about this. I I gotta respond to this request real quick. Okay. So we see here in this email, we can see a few different bits of information. We can see who made the request. We can see their email address. Or is that their UPN? We can see what app they're requesting. And we can also see their justification. In this case, this justification is actually a pretty good one. What we don't see here though is we don't see the API that we're requesting access to. In this case, we know it happens to be graph. But you could also have SharePoint, Exchange Online, any number of other things. Alright. So let's review this one. You click on the link, it takes you to the Enterprise or to the Entra ID Enterprise Applications Admin Consent Requests. And then we click on the Graph Explorer. And it pops this up and from here I can review the application and that would take me into the Enterprise app page and enter ID. We can also click deny. I said we can click deny. Okay. There we go. We can click deny. Does anyone know what deny does in this scenario? Okay. Deny says, we're denying this request for admin consent. And it's just denying that individual request. Whereas block says, we're going to block all future requests to this app. The way it actually does that is quite interesting. It creates, if this is the first time, it creates an enterprise application in your tenant but it marks it as disabled. If it's an existing enterprise app, it'll mark it as disabled. Alright. Then we can review the permission. We can also see who requested it. And then we can click on review permissions and consent. Okay. Yada yada yada. Let's hit accept. Hey, it granted us consent. Oh, this is new. This is interesting. What's with this all preview thing? Let's check that out. Okay. We got graph. We got doodle. Let's see what other requests have been made against graph. Okay. Diego, I really, really need it. I want it bad. I've seen actual justifications like this. This is perhaps the strongest argument in favor of having a more robust system for requesting things outside of what Entra ID gives you. Is the justifications tend to be like this. Okay. Can you click allow and continue back there? Nope. Okay. Let's switch to backup power. Here we go. Okay. For those of you who saw Sarah's talk this morning, I am not Sarah. This is this is a Microsoft forms QR code. I would like to get some info from you guys if you'd like. How many consent requests you get a week as well as do you feel overwhelmed with them? So if you guys wouldn't mind, I promise I'm not gonna do a gotcha like she did. I'm not I'm not capturing anything. Come on, you guys you guys can see the preview. You guys can see the preview of the URL. Curse Sarah for ruining this part of my presentation. Seriously, there's no gotcha here. You can see the URL right there. That's exactly what it goes to. I'm not collecting any identifying information. 13 responses. Okay. Well, that's not bad. Let's see how what data we get on the other other one. Oh, someone else responded. Thank you. Okay. A wide variety there. Alright. So as you can now see, unlike Sarah, I'm trustworthy. Okay. And you can safely you can safely go through any other QR code I've got. Okay. Alrighty. Okay. We clicked through that one, that that admin consent pretty fast. Did we just open ourselves up to what happened to Microsoft a couple years ago? Midnight Blizzard exploited an enterprise app that had been granted access to things it shouldn't have had. The story is actually quite fascinating, we don't have time to go into that, but the bottom line is that when you click accept on those admin consents, you may be opening yourself up to something pretty crazy. It's football season, so we need what? An instant replay. No, we're not gonna debate Michigan versus Western Michigan. But we are gonna use instant replay to figure out what we just did when we accepted that admin consent request. Alright. So here we get to know who the authenticated user is. Not who made the request but who's responding to it. When it says review for your organization, that means this is admin consent. We get the app name and the publisher name. But if you don't see this blue check mark next to it, it is not verified. The publisher of the app can put whatever they want. The blue check mark means this. It means that the publisher has access to a tenant that is linked to a Microsoft partner, and using MFA, they attested that they published that application. That is it. This is a very, very low bar. However, there are many applications that we all use in our enterprises today that have not passed that bar. Some of them it's okay. Some of them we're willing to to accept that. But there's others that that's not really a good thing. Because if it's not been verified, you have no way of knowing that the app is really what it says it is. Next, we see the permissions requested. Then we also get what the meaning of admin consent is. And just for those who don't know, if I hit admin consent, what does that mean? No one else is gonna get prompted. The app can do this for everyone in the organization without them even realizing it because the instant they log into that app, boom. It's the the permission's already been consented. Now this is a good idea when it's an app that we have preapproved and it can be widely used because it reduces friction. The last thing to see here is this link. Well, no there's two things. My apps. End users can actually go here and review what consent requests they've given and they can revoke them. And as we all know, all of our users are doing this weekly. Right? The last thing to see on this one is there is a link to report suspicious apps. What happens if you click on this link? Does Microsoft send a team of ninjas to the home of the developer? No. I actually don't know what happens. I love getting under the hood of Entra ID, which means using the Graph API Explorer. Just quick show of hands, who uses Graph API Explorer? Okay. I love getting under the hood and seeing what's behind the scenes, looking at it in JSON. No AI was used in making this whatsoever. So let's break it down. What did we actually do? Well, Graph API Explorer ties to a client ID. That happens to be the object ID of the enterprise app, not the app ID. When it says review for your organization, again that means admin consent. So consent type is all principles, which means the principal ID is null. And here's the permissions that corresponds to scope. Resource ID does not show up over here, sadly. What is resource ID? What's that? Yeah, it it's the target app. So the client ID is the client app, the one that's going to be receiving the permission. The resource ID is the one that we're going to get permission to do something to. Read it, write it, delete it, etcetera. Okay, since the surveys aren't necessarily the greatest, who here feels like they have a rock solid understanding of admin consents? Because I I I if we if everyone here says they've got a rock solid, I'll skip a few slides. But if others prefer that we go through this, then I'll go through it. So who feels like they have a rock solid understanding of admin consent? Okay. We'll go through this then. Excellent. Okay. So first we're gonna contrast an end user consent when we got a verified app versus a not verified versus when the admin workflow's off. So with a a verified app and depending upon what my policies are, but this is what we get. It says permissions requested and I can and it's verified. We can see through the checkbox, the checkmark and then I can click accept. It says permissions requested. Over here, we see the approval required and I have to put in a justification because Atlassian hasn't done that minimum little step. Atlassian's a great product but I guess they just don't care about Microsoft enough to validate that their app is from them. So it's unverified. And depending upon your policies, it may look like this then, where it says approval required. So even though this is asking for low risk permissions, we're still getting prompted to send it to the admins. If I turn off the admin workflow, it looks like this, where it says, need admin approval. And I don't have the mechanism to submit it to the admins through Entra ID. What do I have to do instead? What's that? Send them the link to what? Yeah. Yep. They have to open a help desk ticket basically. Or as we heard in Joe Kaplan's talk, they go pester a friend who has access. And how did that work out, Joe? Okay. So user consent settings. We got a few choices here. We can say you can't consent to anything and this is a valid this is a viable choice for some organizations. If you say users can't consent to anything, what does this mean? Everything's a ticket. We can also select allow user consent for verified applications for certain selected permissions. This means low risk permissions. We can also select Microsoft's recommended, which is let Microsoft recommend, manage it. This is actually pretty broad. This means they can consent to almost anything. In fact, let's go back in time. You didn't know I had that power. Oh, first, a point. The higher up on this list here, the improved security, but also the more work you have to do. Back in time. Before August 2025, the default option here was what we see in yellow. Allow user consent for apps. What's the difference between this and the Microsoft recommended? Microsoft took away the ability for end users to consent to things like files.read.all, sites.read.all. And a few other things dealing with applications that none of us use or care about like Teams and Chats and things like that, right? All all relatively minor stuff. No, this was important. But the fact that this was the default for a long long time means that we have a lot of cleanup to do. We have end users who over the years have consented to granting other applications files.read.all And sites.read.all. And sites.read.write.all. So we've got a lot of cleanup to do. Okay. User consent settings live in policy slash authorization policy. Again, we're getting under the hood. When you have the do not allow consent, here's what it looks like in the JSON. We're gonna ignore those existing ones. Those just have to do with Teams and chat. Again, stuff we don't care about because we're just identity folks. And then if you select allow user consent for applications, it adds this policy we see there in yellow. Let's take a moment and break that down. The first part of it says, manage permission grants for self. So that means I can only do stuff for myself. I can't consent for the organization. I can't consent for someone else. I can only consent for myself. The second part is the policy name. Microsoft dash user dash default dash low. This is a built in policy. This is the one that says, for a verified app, I can consent if it is asking for low risk permissions. So these policies are about who can consent under what conditions. Now what's interesting is this is assigned, you see, who is this assigned to? The default user role. That means anyone in the tenant, anyone in the tenant can consent for themselves to a verified app with low permissions. If we select let Microsoft manage our settings, now you see what's different here in blue. K? Instead of low, it says recommended. And it has those changes we just talked about. There's another option you can select which is enable user consent for popular mail clients. And that adds this other one here in green. Okay. When a consent request comes in or or when a user is presented with a consent request, these policies are about expanding who and when they can say yes. When they can consent. So it is entirely possible that a consent request may arrive and more than one policy applies to it. Because the policies aren't about saying no, they're not about denying access, they're about saying yes. So I could have a consent request that comes in and there could be five different policies that apply to it. So just bear that in mind for later. What does admin consent policies look like? Well, first of all, we can allow users to make the admin consent request or not. And going either way is very valid. In a large organization, like Joe talked about just a couple hours ago before lunch, they you probably don't do that. You probably have it turned off. I'm guessing. Okay? Because you want them to go through a very rigorous, very well defined process for requesting applications. But in smaller organizations, where they don't have the manpower to build such extensive things, this may be the right approach. Additionally, we can also designate who can get these. We can designate users, groups, and we can also do roles that get it. One thing to note, we can add people here and they can say no. They can deny or block a request. But only limited sets of people can say yes. So even though we put someone here in this list, they may not be able to say yes. They can only say no. It's kind of an interesting permission to hear. By default, only cloud app admins and global administrators can say yes to admin consents. So this is one way that you can offload work from your global and cloud app admins, giving other people the power to say no and to respond through the requests. Insert your James Bond joke about doctor no. Okay. What does an end user consent request look like under the hood? Well, consent type is instead of all principals, it says principal, which means that the principal ID actually corresponds to the user. And then the rest is the same. Okay. End user making a request versus an admin making a request. So here at Atlassian, this is an unverified app. And over there we have an admin who isn't doing an admin consent, he's simply making a request to use the app. What's the difference here? Well, on the left, we we have to enter a justification. Whereas on the right, the admin can simply hit accept. And the admin can turn it into an admin consent by checking that box. If you check that box, this becomes an admin consent. That's that major difference there. This is to contrast, this is what it looks like when the end user can consent for a verified app with low risk permissions. The user can just accept. Okay. Oh, okay. Global admins and cloud app admins. Unless you have made other provisions using custom consent policies, which we will touch on a bit later. Yes? Can the AI administrator now do that? That's an excellent question. I am not certain. So I'm not gonna pretend I know. That's a good question. Permissions change all the time in Entra ID. And I unfortunately can't keep up with everything everything. But excellent question. So we'll we'll look that up afterwards. Alright. So here is admin consent for a verified app versus not verified. So permissions requested. When we see this, if the app is not published by Microsoft nor verified, you'll see a message to that effect and you won't see the blue check mark. Okay. Here we're contrasting an admin user request versus an admin consent. So again, I check that box, it becomes an ad, it's an admin user request, it becomes an admin consent versus the admin consent. So if I check this box, it becomes this, review for your organization. Which means what? Everyone gets it. No one else gets prompted. Okay. Let's break down those permissions that we just granted. Let's start with the bottom two. Maintain access to data you've already given it access to is also known as offline access. And this is a very low risk permission unless it's paired with higher level permissions. Sign in to read user profile, also known as user dot read, is also very low risk permission. These two are actually pretty much the min bar for granting an app the ability to use your tenant for authentication. What about the one up there? Read and write all agent ID users full profiles. And when what the heck was I thinking in granting that? This is a very powerful permission because with it, someone could make changes to the users that exist to support agent IDs. My talk is also AI light, but we touch on it here and there in a few ways. Okay. I think we've hammered home admin consent enough, but if not, take a moment and read this. Because there's a saving grace. Even when we do grant admin consent, and this is foreshadowing for something coming up, I guess if you tell them it's foreshadowing, then it's not anyway. Unless you restrict access to the application, everyone will be able to use that app and won't get prompted. We consented to something, what the heck did we just do? Where do we go? Anyone had ever had buyer's remorse? Okay. Anyone had approver's remorse? This is where you go for approver's remorse. You're gonna go into enterprise applications and you're gonna go to the specific application and you go to permissions and then you can look and see things that we've consented to as admins. You can see what users have consented to. You can also see what type of permissions have been have been consented. What are the two types of permissions? That's right. Okay. Yep. Everything ever unless you're in a really big organization and the UI breaks. And then you have to go after it through graph. Or some third party tool that happens to to grab that data for you. Yes. There's actually a pretty decent PowerShell script included on Microsoft site. I was about to say TechNet, whatever it's called now. And sorry, I guess I just carbon dated myself in the IT world there. So use TechNet and there's a link to a PowerShell script where you can use that to go revoke permissions that have been consented to. So that is, and then you could build your own custom solution off that to go revoke permissions on a periodic basis and force re consent. However, you should know that if you do that, what's gonna happen? You're gonna be prompted for consent again. So this is a high friction move. Okay. Since I wasn't all that successful in getting the last one to show, who feels they've got a rock solid understanding of the difference between app only and delegated permissions? Okay. So good. We'll still need to go through a few. Here's a quick example. Delegated permissions. Featherstone has read write to all her own files. There's an app that someone admin consented to that read all files from all users. What's the resulting permissions? Drumroll please. Read all for Featherstone's files. Because the app is acting on her behalf, it can't do anything she can't do. It can't read or write other user files. But why can't it write her files? She can write her files. It hasn't been delegated to the app. So it can only read her files. Now when this app is acting on behalf of someone else, I'll I'll pick on Scott because I can read his name tag from here. Sorry Scott. If if Scott has consented and the app is acting on Scott's behalf, it can only read Scott's files. Okay. Just to hammer the point home, read all files for all users is the in delegated permissions, it's the intersection of the app delegated permissions and the user's permissions. App only permissions, this is just like giving permissions to an on-site service account. Whatever permissions you give it are the permissions it has. It can do it on its own, not acting on behalf of a user. So if it can read all files belonging to all users, it can read all files belonging to all users. If you can read and write all files in a particular folder, you can read and write all files in that folder. How bad is it? How bad did I screw up? How bad did I screw up in granting that consent? What's that? It's delegated. Okay. So that's a saving grace. Because why? Why why is that a saving grace for us? That's right. So Isaiah, Isaiah Langer may not have permissions to actually do anything with agent IDs. So does that mean that we're totally good? No. What else, if we decided though that this was a permission that we needed to grant, what else can we do to ameliorate the situation? We could revoke it or we can go into the enterprise app and we can hit assignment required and we can specify users or groups. And presto, this is now limited to me, j w and the members of that security group. Okay. So that's our first elementary step in a situation where we have an app that has more permissions than we want to give it, but we have to have it there. How are enterprise apps represented in Entra ID? When we go behind the scenes, how are they represented? Anyone? Okay. There's an app ID, but what's the object name? Service principal. Exactly right. And we can see that here that the object ID and the app ID are there. Where do we get Enterprise apps from? Yes. All of that that Joe just said. Let me repeat. App registrations, Microsoft provides some like Power BI and Exchange Online. Admins can install things from the Entra app gallery and also whenever an end user consents. So if you're allowing consents, you're allowing end users to create enterprise applications in your tenant. Which may or may not be a bad thing depending on what you're trying to do and depending on the politics of your organization. And I don't mean republican democrat. Okay. I'm not talking that kind of politics. Alright. Who can register apps? Well, it's controlled right here. You can allow users to register apps. Now an app registration is different than an enterprise app. And I think most of you have some level of understanding of that, but we will hit a couple points on that in a moment. This is a bad idea. Allowing end users to register their own apps is generally a bad idea. However, who here is in higher ed? Okay. You may be in situations where you're kinda forced to do that. Where different researching teams may have said, hey, we have to have this. There actually is another way. We can put people into a role, the application developer role, and allow selected people to register apps. Admin app admins can do it. Cloud application administrators can do it. Or you can build a workflow process, similar to what Joe was talking about. We didn't plan this, but my talk is building pretty well off his, I think. Okay. Who feels they've got a rock solid understanding of the difference between an enterprise app and an app registration? Okay. Just real quickly, we can see here that the app ID is the same but the object ID is different. These are different objects. An enterprise app always ties back to an app registration somewhere in someone's tenant. When I create an app registration in my tenant, it creates an enterprise app in my tenant. If I make my app registration multi tenant, then other people could potentially install it into their tenant. Do they get an app registration? No. They get an enterprise app. The enterprise app, we can think of it as an instance of my app registration. It's not a perfect analogy, but it's close. Last point on this, there's many others we could go over, but the last point is permissions. On the right, you see the app registration and that's where the permissions are configured. On the left is the enterprise app where the permissions are consented to. The UI gives us the ability to consent on the right in the app registration, but the consent actually happens on the enterprise app, not on the app registration despite what the UI does for us. Okay. Once upon a client, a major research university, they had some mighty struggles with this. And the result was thousands upon thousands of enterprise applications, some of which were over permissioned, some of which were unused, and a few of which were rather risky. That looks fun though, doesn't it? So I set about trying to help them build an application governance framework. We have to have a source of authority. We have to have a defined scope. We have to have criteria for when we're gonna allow end users to consent. We have to have a rationale for admin consents. We have to have an appeals process. We have to define who's gonna respond to the consent requests, a method for triaging the existing applications, because we gotta both plug the hole in the boat and bail things out. And then defining who should be able to register apps, that's another hole in the boat if you don't plug that. And then finally, there's two kinds of policies that you need to bear in mind. There's policies in Entra ID and then there's policies in Microsoft Defender for cloud applications. Okay. So let's talk about why this is so important. This bears no resemblance to a certain film made by a certain publisher that purports to have the happiest place on earth. What we see here is an octopus woman holding up a contract and what is it doing? It's blocking someone yelling at her. This is especially important in organizations that are decentralized, like universities, where there are a lot of people who have a lot of power or feel they do. They feel anyone who has the title of dean or vice president, and I'm not saying that they're all acting this way, but many of them feel like that entitles them to yell at the IT people to get what they want. Even if they don't yell, sometimes just talking to them can be intimidating. So, it can be really really hard to say no. And this isn't limited to just universities. Okay. So what's your source of authority? Your CISO. What's your scope? Am I just focusing on one Entra ID tenant or am I covering a whole bunch? Or am I trying to cover every app in the enterprise? Makes a difference. What should your consent, what should your criteria be for end users consenting? We've talked about this, verified apps, low permissions, delegated permissions only. I also recommend you create a policy, if you have any kind of developers, create a policy that gives them the ability to consent for permissions for apps that they own. Now, whether you're doing this through some kind of automation workflow you've built or doing this directly through Entra, you need to offload this work from your global admin somehow. Okay. This is an eye chart, but it'll be included with the slides explaining the differences in low permissions, what you see as an ad, as a user consent, as an admin consent, what it is in graph, what the explanation is and and a bit bit of other things. Permissions can be customizable. We can customize what are low permissions. We can also customize medium and high. So low permissions, adding a permission here doesn't do a thing for you unless you select this middle option only. Only the middle option causes the low to have any effect. Why? Because this one says no one can consent and this one says that we're gonna ignore the low. Okay. So, medium and high have no effect whatsoever unless you create custom consent policies. What's your rationale for admin consent? Well, here's what I propose for you. A verified app. If it's not a verified app, you say no, provisionally. Force them to go through the appeals process. There will be verified apps that you end up consenting to. There's a thing called Microsoft three sixty five certified. There's only a couple 100 apps that are actually that way, so it's not really worth considering at this point for most things. Does it exist in the Defender Cloud App Catalog? Oh, what's that? We'll get to that. If you see it in the Entra app gallery, it's probably in the Defender Cloud App Catalog too. What's its risk score? Wait, risk score? Where do we get this from? Let me show you. It's on a scale from zero to 10 and you're also looking at the permissions requested. Risk scores. Depending upon your licensing, I don't have time to go into the specific licensing, but if you have the right licensing, you can see risk scores in the Entra app gallery and in the Defender Cloud App Catalog and in Cloud App Discovery. And these all are using the same thing. So on a scale from zero to ten, zero is bad, 10 is good. Oh, did I hear someone ask where that, what what that's calculated from? Categories. Four categories. Oh, how does that further break down? Okay, I know that's a bit of an eye chart but general is looking at things like when it was founded, security is dealing with security things, is it encrypted, does it have audit trails. Compliance, is it compliant with ISO 27,001, etcetera. Legal, does it comply with GDPR? Okay. These scores can be customized for your tenant. If you're in university, FERPA might be important to you. Should be. If you're a hospital, HIPAA is important to you. If you're a bank, HIPAA is not as important to you, but GLBA is. So how do you customize that? Well you get in through Cloud App Discovery, you go to Cloud Discovery, Actions and then Cloud Discovery settings. And here you could mess with everything. By default, general is a one and everything inside it's a two. All the other categories are two. But you can go to zero to eight. And so it waits them. What's your appeals process? Help desk ticket. Who should this go to? Some kind of cloud app governance board. They look at the risk score categories in more detail. Find ways to minimize the permissions and figure out whether they're going to limit who should access the app. In the end, you're weighing the business needs versus the security risks. But here's my one message. If you take nothing else away, take this home. Do not make these decisions alone, especially in a decentralized power environment. You need backup, like in all those cop shows. Call for backup. You need a charter and you need a cloud app governance board. Simply having an appeals process will be very valuable to you. Because if you say no to someone, they get upset. But if you say, provisionally no, but here's how you can get an exception granted, they have a path to go and they won't yell at you as much. Any actual yelling that occurs is not guaranteed or my fault. Alright, sorry. Had to put in the legal disclaimer. Who should respond to your requests? Well, we gotta kinda go through admin consent to figure that out. We can put anyone in here but remember, we can give them the power to say no without giving them the power to say yes. Still a way to offload things. It can send emails out, defaults thirty days before it expires. We can create custom policies. We can create a helper team policy where we manually say they have to look at the risk score and see if it's over eight. So unverified apps, low risk permissions, and then they're manually checking to see that the risk score is eight or greater, go ahead. That's probably a good thing. Salesforce admins. Grant permissions to Salesforce apps. SharePoint admins, when it's targeting the SharePoint API and the app dev stuff we already talked about. How do you create custom consent policies? It's a little tricky, but you're gonna have to do this through PowerShell or Graph. And you create a set. You create the policy and you create several include sets or several exclude sets. And you can say any app, any verified app, you can say what kind of permission we're dealing with, you can use those permission categories we looked at. For teams and groups, you can use sensitivity labels. And then you have to assign it to a role. This is the last step that the documentation doesn't make very clear. You have to assign it to a role. You can assign it to the default user role or you can assign it to an Entra role. Let me skip over this. Okay. If you're gonna do custom policies, look at the existing ones to study them, to understand them. Alright, this is also, this is probably the second most important point. Microsoft Cloud App Defender is your friend. Why? Because it can help us triage the unholy trio of risky apps, highly privileged apps, over privileged apps and unused apps. Wait, David, that's four. I know, but trio sounds better. Okay. Cloud App Defender gives us a different risk score. This is confusing. The Cloud App Catalog gives us a score from zero to 10. High is good, low is bad. The app governance piece of Cloud App Defender gives us a risk score from zero to a 100. Zero is good, a 100 is bad. Thank you, Microsoft. Exactly. Trying to solve similar but different problems. This one is fact, is uses five factors. Is the application inactive? Does it have over privileged permissions? What does that mean? Permissions it hasn't used in the last ninety days. Unfortunately, it's mostly just looking at graph for that. Is it highly privileged? Is it external to your organization? Does it come from an unverified publisher? Just a contrast, here's the Cloud App Discovery score for Spike. In this tenant, it was a four. Why? Even though security was 10, why did it score so low? Because compliance is a zero and I waited compliance extra high in this tenant. But here, cloud app, the app governance said it was a 98. Get this thing out of here. Okay. Alright. How to get risks worse? You've got thousands of enterprise apps. How do you know what you've already implemented that's risky? Here's the cheat code. Export a list of your service principles to JSON. Include the home page and the other URLs. Create a dummy log. Upload it into Cloud App Discovery and then download the report about twenty, thirty minutes later. And ****, you now have a risk score for every single enterprise app. Well, most enterprise apps. No, some enterprise apps in your tenant because some of them aren't in the catalog at all, which should tell you they're even riskier. Now, of course, homegrown ones won't be there. What do you do with unused apps? We're gonna do a screen test. Notify the owners, give the help desk a BOLO, be on the lookout for problems with this application. You give them the URLs, you disable the app. Don't delete the app. Third most important point. When you're doing this, don't delete the app. Disable it. Why? Who here has ever been an accountant? Hey, none of us. Do you know what the accounts do at quarter end? Do you know what they do at year end? Sometimes they pull up apps that they only use once a year. K. If you've deleted it, that's bad. If you've disabled it, it's easily recoverable. Risky apps. With management's permission, disable it right away. K. Again, I can't stress enough, have management permission before you do that. Notify the help desk, overprivileged apps. Review the permissions, try and get the publisher to use lower permissions, create a script to remove permissions, but have a script ready to re, re add them. Highly privileged apps. Oh, okay. Again, building on something Joe was talking about. Custom security attributes to apply con stricter conditional access policies. This is huge. This is huge. Okay. We talked about who should register apps. Their app policies. Please please please block passwords. When you have registered apps, they can authenticate using secret keys, which is really just a password. Don't allow this. Also, limit the time on certificates. And there's a few other items that I recommend as well. There are also policies in cloud app governance that you can use to monitor things. Like right here, we're suggesting a couple policies. Okay. So what have we learned today? We've learned the importance of getting back up so we can say no. Have a charter so that you don't get yelled at as much. Again, I can't guarantee you're gonna eliminate yelling, but it can reduce it. You've learned, we've reviewed the difference between delegated and app only permissions, user consent versus admin consent, and we've learned about risk scores and customizing risk scores. How many of you knew there were risk scores out there for the apps? Okay. A handful. Alright. Alright. Very good. And we don't have time to go through that, but if you went to Joe's then you got a good taste of that. Okay. I'm probably out of time completely. Obviously, it was hard to get through all of that, but, we'll take one question if there is a question in the audience. Because that was, of course, a lot of stuff that you've covered that probably needs to be processed, my friend. Yeah? Here. Thank you. Great talk. Thank you. Have you ever successfully reached out to a vendor and had them go through the verification process? No, but I've heard of other people who have. I give it a higher realistic probability than Santa Claus' existence, so a much higher probability. Good question. Good question. And that was the only question that we had time for. David, it was great having you. There's lots of stuff that you have to review. We'll have the video up after the conference because, of course, there was stuff that you've, shared that you'll need to just have a look at again to really process it. Thanks a lot, David. It's great having you.