Last summer, James Yip wrote a good article on how to use Defender for Cloud Apps (MDCA) to manage third-party applications. As an example, he discussed setting up Microsoft’s MDCA connector for Salesforce.com and talked about some of the challenges inherent in using a Microsoft product to monitor and manage a non-Microsoft solution. That got me thinking about two lesser-known MDCA features: cloud discovery and the cloud app catalog.
The App Catalog: Bringing Back the Wish Book
When I was a kid, every year, Sears Roebuck would publish a Christmas catalog known as the Sears Wish Book. This was a valuable aid to Christmas shopping in our family; I never knew what to buy my mom, but Sears helpfully included pages of slippers, bath powder, and other options that saved me from having to exercise any judgment or initiative in selecting a present. Likewise, kids could just circle the things they were most interested in, freeing parents from the need to pretend interest in whatever fad toys and games were hot at the moment. Sadly, the MDCA Cloud app catalog is a lot less fun, but still quite useful when evaluating cloud apps for use in your environment.
The Cloud App Catalog is intended to give you a fairly high-level risk score that indicates Microsoft’s evaluation of the security quality of the app and the app vendor. This score is based on four factors:
- Data extracted by MDCA from cloud app sessions (e.g. what HTTP security headers do the app recognize and emit?)
- Human analysis by the MDCA team (a set of contractors that Microsoft uses along with an attestation checklist to look for things like “does the app claim to encrypt data at rest”)
- Customer and vendor input, where either party can point out errors or omissions from the preceding steps.
Each app listed in the catalog (and Microsoft claims there are more than 31,000 of them!) is rated in four categories: general information about the app and the company that provides it, security (which includes information about whether the app supports MFA, whether its TLS certificates are valid, when the last reported breach was, and so on), compliance (which specific compliance or governance attestations the app claims, e.g. is it HIPPA compliant? Is the vendor ISO 27001 certified?), and legal (mostly concerned with various aspects of GDPR). Figure 1 shows a sample rating for cnn.com, which I chose to illustrate that the catalog contains many “applications” that are not what you might normally consider as applications. Besides CNN, the catalog includes popular social media tools, instant messaging applications, and other services that your users might be running on your network, even if they aren’t business applications. This makes perfect sense when you consider that the intent behind MDCA is to give you oversight and management capability for all the cloud apps running on your network.
You can use the catalog in multiple ways. One way is to use it to look up applications that have been detected on your network that you’re not familiar with. Another is to look at app categories to compare scores when you’re considering deploying a new type of application—obviously, you wouldn’t make a deployment decision based solely on this data, but it’s a useful signal to consider.
Inventory is one of the ongoing challenges in managing enterprise applications. Managing applications begins with knowing what applications are installed and/or active on your network, and this is difficult given the array of different application types (browser-based, mobile, and desktop apps generally have to be managed using different tools), devices, operating systems, and so forth found in a typical heterogeneous enterprise environment. One way to solve this is to inventory the endpoint, which is one of the key reasons people use Microsoft Endpoint Manager. Another, and often more useful, way is to inventory the network traffic generated by applications and use it to tell what applications are being used. This is exactly what MDCA can do: if you enable app discovery in MDCA, it will attempt to build and maintain an accurate inventory of what cloud applications are in use. The simplest way to do this is to feed it a set of your firewall logs, which will give you a point-in-time snapshot view of app usage. To get ongoing visibility, you can connect MDCA to Defender for Endpoint (which will allow you to monitor apps on individual devices), install a log collector that collates and uploads the logs, or funnel your network traffic through a device from Menlo Security, iboss, Corrata, or Zscaler that integrates directly with MDCA.
What do you do with the discovery data? That’s the interesting question. You probably have a pretty good informal understanding of the apps people use: along with the provisioned business applications you’re paying for, you will probably see lots of Netflix, Gmail, Facebook, and so on. Paying money for MDCA to tell you what you already know doesn’t seem like a great idea. However, there is clearly value in discovering shadow-IT applications that are being used for business—and potentially with confidential data—without your organization’s approval. You can also highlight the usage of applications that you particularly don’t want on your network, and you can define policies to highlight the use of unsanctioned applications based not just on the application itself, but on the categories of risk that the application exposes. This risk data comes from the app catalog—another use case for the catalog, but one that you don’t necessarily have to do yourself manually.
Getting started with MDCA app discovery
The MDCA documentation includes a long list of supported firewalls. Even if you don’t think you’d benefit from building policies to control cloud application usage through MDCA, it’s worth your time to grab a couple of weeks worth of logs and upload them to MDCA to see what the application usage in your organization actually is, compared to what you think it is. You can easily do that with a free trial of MDCA, although you only get one of those per tenant, so you might want to consolidate that testing with other testing activities. Once you know what applications are in use, you can use the app catalog to check their risk scores to give you a clearer picture of what risk those applications might impose and then decide how to proceed.