Stop Cloud & Hybrid Apps from being Cyber Attack Entry Points

QUICK LINKS:

00:28 — Cross app integrations

02:13 — Attack demo

03:49 — How app governance detects and mitigates risks

05:37 — Behind the policy and how to block apps

06:43 — Templates

07:36 — Wrap up

Link References:

• Enable a trial by going to https://aka.ms/appgovernance
• To learn more, check out https://aka.ms/appgovernancedocs

Unfamiliar with Microsoft Mechanics?

We are Microsoft’s official video series for IT. You can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft.

• Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries?sub_confirmation=1
• Join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog
• Watch or listen via podcast here: https://microsoftmechanics.libsyn.com/website

Keep getting this insider knowledge, join us on social:

• Follow us on Twitter: https://twitter.com/MSFTMechanics
• Follow us on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/

Video Transcript:

-Coming up, with your cloud and hybrid apps now increasingly connected to your data and services, we look at how you can prevent them from becoming entry points to cyber attacks and exploits with Microsoft app governance, which is now generally available. In the next few minutes I’ll walk through a cloud app-based attack, and show you how app governance helps you to quickly get visibility into the compliance posture of all your connected cloud apps, identify anomalous behaviors in risk, and take action to respond to threats.

-Now, as more and more of us are adopting cloud-based services, creating connections between those apps and connecting them to data sources and information through APIs are a normal part of everyday app architecture and add a lot of efficiency and convenience. For example, these types of integrations are how apps like Microsoft Teams leverage Microsoft graph APIs to access key information in the Office substrate. Like your calendar, when you view your meetings, Teams gets it’s calendar data from Exchange Online. Or, when you create a new file, Microsoft Teams will post that file to SharePoint Online. Importantly, each of these cross app integrations include a set of parameters: what that app is permitted to access and what’s done with the data, like allowing read access, but maybe blocking rights or downloads.

-And that’s just an example of what we do for Microsoft apps. And you might be creating similar integrations for your in-house apps, where you connect to capabilities or data sources exposed via the Microsoft Graph or other published APIs too. Now, while this type of cross app connectivity can help improve productivity, optimize processes, and code efficiency, and reduce things like duplicated services, if you don’t know which apps are connected, or what they’re doing, they may end up accessing more information than they should, which then becomes a path into your organization for malicious actors to exploit.

-And the reality is, you may have hundreds or maybe thousands of cloud apps inside of your organization, which makes it almost impossible to test and verify and continually retest each and every app and keep a handle on their activities. This is where app governance from Microsoft comes in, to reduce apps as a potential attack vector by continually monitoring the operations they perform in your environment, and automatically and proactively disabling high-risk apps.

-To show you how this works, I’m going to walk you through how you use app governance to find and stop a real attack, along with what you can do to automatically respond to future attacks. Now, we’ll start with a common scenario, where an app has been internally built and forgotten, and the original developer isn’t even around anymore. In our case, it’s a trusted OAuth app built a few years ago, and it has a higher set of privileges than it actually needs, and isn’t used that much. Meanwhile our bad actor, targeting the organization, is able to get valid Microsoft 365 credentials for a privileged user via a public site that publishes breached passwords. Now these types of sites actually do exist, and are a great tool for hackers, even though their primary purpose is really to alert users of the impact of personal data breaches.

-Next, armed with these credentials, our bad actor scans the environment to find our vulnerable app with its high level of permissions, and uses them to add another set of credentials for that app. Now this gives them persistent, high-privileged access with read and write permissions to high-privileged files stored in SharePoint and OneDrive. So now, they can exfiltrate the data that they want, mass download the files they want, and even modify them using encryption for ransom, which will infect the entire organization. By the way, similar to attacks that we’ve seen out in the wild, you may have noticed that our bad actor did not target the user account directly, which could be subject to things like conditional access restrictions. That way, even if the hacked user changes their password or enables multi-factor authentication, the attacker still has persistent access and IT is oblivious to unwanted activity from this trusted internal app.

-Now let’s see how app governance then would detect this and help mitigate the risk. So, I’m in the app governance dashboard, and each app highlighted here as an OAuth-enabled cloud app, that can access Microsoft 365 data using graph APIs. Here, you can see apps with high privilege, alert details and also data access trends over time. Under top alerts, you can see that we have a high severity alert that we need to investigate. It was triggered by a policy that looks for excessive data usage with our LOB app. So, I’m going to click in here to view the threat and policy alerts, and there’s our anomalous data access alert. And now, this links me directly to the offending app, our Contoso file parser.

-Now, I’ll drill into this alert to find out more, and you’ll see a complete view of the app’s behavior. So first, we can see, in this case our app publisher was not verified, and that’s because it was an internally-developed app from a citizen developer. Next, in usage, it’s found that the volume of data access is trending higher than usual. And this is important, because the app may have been verified as low-risk when it was initially authorized, but now it’s accessing a lot more data compared to its previous behavior.

-Next then in users, we can see the number of consented users and the user with the most data usage also happens to be a priority user. Finally, the permissions granted to this app are very high. It can read and write all files stored in SharePoint and OneDrive. And this is already a significant risk in itself. So, taking into account all these factors, we can directly take action here and disable the app. And once I do this, it can no longer authenticate the organizations Microsoft 365 data or resources, and you’ve mitigated the risk from this point forward.

-And there are ways that I’ll show you in a moment to stop the attack in its tracks, before significant data has been compromised. But before we do that, let’s see exactly what’s behind the policy that detected our alert. I can see our policy here, and I’m going to go ahead and click edit. And in this case, the policy’s primary function is to detect whether data usage for the app is higher than usual. In this case, we’re looking for apps that access more than 200 MB of data per day. In fact, to visualize this, if we hop back to the data usage trend of our app, you can see that it’s analyzing the usage patterns, and if it exceeds 200 MB here, like we see what this recent spike, the alerts going to get triggered. And I can manually take action then to mitigate it.

-Now, let me show you how to proactively block the app, once app governance detects anomalous behavior. And to automate remediation, I’ll go to the next screen. And you can use an action to find your policy settings here to automatically disable the app, which neutralizes the threat immediately, without you having to take manual action. Additionally, as you would expect, any alert signals from app governance also appear in Microsoft Offender. In fact, here’s the alert that we just saw in app governance. And this can help you piece together the broader story behind the given attack. Now, we’ve also made it easier to enable and customize policies like this one.

-In fact, there are built-in templates to get you started quickly, in just a few clicks. This includes templates for app usage, which looks for patterns like an increase in app users, or higher than usual data volume. Another, is for high-risk app permissions to alert you of apps that might have more permission than they actually need. And the third here, is to find new apps that haven’t yet been certified for Microsoft 365. And of course, you can create custom policies as you can see here, with 18 policy product kits available to detect other types of behavior. The good news is, once enabled, these policies continually assess the activities, the permissions, and verification status of each and every app connected to your environment to ensure that they’re behaving as intended, with alerts or automated actions triggered when they don’t.

-So that was a quick overview of app governance and how it can help you to proactively identify high-risk apps connected to your Microsoft 365 services, so you can quickly take action. App governance now provides additional app behavior context in Microsoft Defender for Cloud Apps, formerly known as Microsoft Cloud App Security. You can find it and enable a trial by going to aka.ms/appgovernance. It’s an authenticated link, so you’ll need to have Microsoft 365 admin center privileges to sign up. And to learn more, check out aka.ms/appgovernancedocs, And subscribe to Microsoft Mechanics if you haven’t already. And thank you so much for watching.