Monitoring identity, cloud apps and email at different service tiers

Today I want to give you two ideas that you can take to your customers as new offerings. Some of you may already be doing some form of this, but based on my recent survey results, identity protection and monitoring in the cloud is still an area that is wanting for development.

The time for this conversation is ripe with the recent high-profile Solorigate attack that impacted so many customers, including several US government agencies. I suggest that we are living in an era now that demands a higher level of attention to the entire attack kill chain.

For a few years we have been hyper-focused on preventing bad stuff from happening in the first place: Email protection, Multi-factor authentication, Conditional Access, limiting admin privilege and so on. And we cannot stop paying attention to those things, but we also must go further now and ask, “What if our defenses fail?” Because at some point, they probably will. Even with all the above-mentioned items in place.

Getting “post-breach” defenses activated can be viewed as a journey, rather than a single event. Ultimately you will have several different domains or “areas” to which you must apply higher scrutiny:

• Email and SaaS apps
• On-premises network
• Endpoints
• WAN and VPN links
• IaaS and PaaS environments
• Physical environment

I will suggest that we begin the journey at the top of this list, focusing on the corporate identity which is our passport to Email and cloud apps. There are so many ways to deliver better visibility into potential compromises, and of course we cannot cover them all here; when you first start going down this path, there is only so much you can accomplish with the limited time and resources you have, right? So let’s keep it simple, but try to get some good mileage from our efforts.

Tier 1: Basic Email and Cloud App Monitoring

In a Basic service tier we just need to cover a few essentials; the idea is to keep our costs low, and the start-up efforts minimal while still making forward progress against our goals.

With regard to Microsoft 365 subscriptions, you should first of all enable the Unified audit log, and then configure Alert policies in the Security & Compliance center (https://protection.office.com/alertpolicies). These are also available now at the new Security admin center (https://security.microsoft.com/alertpolicies). These are the same policies.

There are a number of built-in policies already present here for most subscriptions. You will see some additional built-in policies with a subscription to Microsoft Defender for Office 365 P2 (available standalone or included with Office 365 E5 or the Microsoft 365 E5 Security add-on).

There are certain events worth knowing about, such as Creation of forwarding/redirect rules, or Suspicious email sending patterns detected. If you have the Report message add-in deployed in your organization (and you ought to), then you can also enable the policy called Email reported by user as malware or phish (because no filter will catch 100%). This allows you to do some additional investigation if needed (aided by Automatic Investigation + Response if you have that P2 subscription).

Be sure to configure all of the built-in alerts so that they go to your service desk/ticketing system. Optionally, you can configure additional custom events to monitor. You want real people to follow up with these events (note: some of the events categorized as “informational” are still important).

This is something that you can (and should) do right away, with little or no experience (you will learn by doing). But this does create additional work on the back end! When one of these alerts rolls in the door, you need to have someone available to react, evaluate, and remediate if necessary. That makes this a new service with MRR potential. Every single MSP out there should be doing this if they aren’t already.

Another simple thing you could do at this tier is enable some Dark web monitoring with a third-party service. For example, if your corporate credentials are exposed on the dark web, you can receive a notification about this event, which might indicate that it is time to force password changes for the impacted user(s).

Tier 2: Identity Protection + Cloud App Security

In our second service tier, the goal is to improve our detection capabilities (to capture more subtle activities and additional signals) and to automate some of our response and remediation efforts. But at this stage, we are not yet looking for a complex tool like a SIEM, which adds significant time and expense to your operations. For a happy middle ground I recommend Microsoft Cloud App Security (MCAS).

Similar to the alert policies that we have in the Security center, MCAS comes with many pre-canned alerts that we can enable. And some of these are really valuable: for example being able to alert on uncommon or unusual activities within cloud apps, or strange login activities like impossible travel (e.g. I sign in from Minneapolis, USA and then a few minutes later from Paris, France). However, MCAS has a few extra tricks up its sleeve that make it especially attractive to service providers and their customers.

First, we can include governance actions within our alert policies, so that when an alert is triggered by some event, we can have the system take certain actions to mitigate or remediate the situation before a human has to get involved.

Second, we have the ability to use our own templates and customize the “from” address for email alerts. This makes it easier for our ticketing system to automatically associate alerts with our customers according to the sending email domain (be sure to add MailChimp’s information for Email authentication to your DNS records).

Third, we have the ability to add delegated admin access for our MSSP, so that as a service provider, we can quickly switch between customer instances of MCAS right from the native admin web UI.

You can add additional admin users to the customer’s instance from their portal under Settings > Manage admin access.

But wait, there’s more. You can also connect third-party SaaS apps to MCAS for monitoring (Settings > App connectors).

This tool can do even more for us paired with Azure AD Identity Protection and Microsoft Defender for Identity (which is a monitoring tool for your local Active Directory). A subscription bundle such as Enterprise Mobility + Security E5, or Microsoft 365 E5 Security, or the full Microsoft 365 E5 will contain all the requisite parts to give us what Microsoft dubs a “Unified SecOps investigation experience.“

Aside: My dream product from Microsoft would be an SMB package: “Microsoft 365 Defender for SMB” with Email, MCAS, Identity Protection and Endpoint all rolled into one. Similar to Microsoft 365 E5 Security but “right-sized” to fit the SMB market, and fully compatible with the Microsoft 365 Business Premium plan (the E5 Security bundle cannot be stapled on to a Business plan at this time).

Each of these tools is relatively easy to set up and use. For example, the Microsoft Defender for Identity installation is really simple; there is a download available from the portal at https://portal.atp.azure.com.

You just have to install this sensor and plug in the access key on each domain controller in your network. And just like that, you can export your security data to the cloud for analysis and alerting.

Back in the MCAS portal under Settings > Settings > Threat protection, you can enable the integrations to Azure AD Identity Protection and Microsoft Defender for Identity with just a couple of clicks.

This will pull in data from Azure AD and on-premises AD (when you have the sensor installed), giving you end-to-end visibility over your hybrid identity picture. You will find additional alert policies automatically added (be sure to configure them as you have the others).

As well, we get a really nice view of identity risk with dynamically updated “Investigation priority scores” (the higher a user’s score, the higher the probability is that this user is compromised). This will look at signals from on-prem AD, Azure AD and any other cloud apps you have connected.

As a bonus, at this tier you do not really need a third-party service to monitor the dark web; Azure AD Identity Protection will do this for us (which also impacts each user’s risk score), and we can even configure the User risk policy in Azure AD to automatically force password changes when these types of credential exposures are detected in the wild (resets are validated with MFA, of course).

Even though this solution includes a bit more automation, we also have a larger number of detections available (many of which are more subtle), and not all events can be “auto-healed.” So you should still plan to factor labor into your calculations for offering this service. I suggest you create bands such as:

• Up to 25 users
• Up to 50 users
• Up to 100 users
• Up to 200 users

Estimate that someone on your service desk needs to investigate or “triage” up to 5 incidents per month per 50 users at an average time of 15-20 minutes per incident. Then price accordingly. Run this model with a pilot group of customers willing to be guinea pigs for a couple of months. Some events may require more time, some may be less; adjust your offer as needed and then continue releasing to other rings from there.

Note: This is just “back of the napkin” stuff that is right off the top of my head; you should do your own work to create real offerings. Also note: I would suggest that a more serious breach event where an adversary has established persistence or dominance should turn into T&M at your “Incident Response” rate (which may be higher than typical services).

Discussing with customers: Security is a journey, not an event

Through working with others, I have found that these steps are a “fast track” to tangible results and new revenue. When you discuss this journey with your customers, explain why we need to start moving toward a zero-trust model, where we assume that nothing can be trusted, and that we might be breached at any given moment (even right now). This requires a fundamentally new approach, and as part of that we want to be able to:

1. Detect when someone is “inside the house” who does not belong, and
2. Contain and remove the unauthorized person(s) as quickly as possible

What we have laid out above does not even include endpoint security, and specifically we haven’t discussed Endpoint Detection and Response (EDR). Obviously, I would recommend this component be on your roadmap as well. But remember that you don’t have to do everything at once, and what we’re discussing here today is just one potential path through the weeds: you are free to create your own journey!

Partly I chose to begin with the identity and cloud apps piece because this still accounts for about 81% of security breaches in the wild according to Microsoft (and I am certain email is at the top of this list). Therefore we should attempt to provide our customers with concrete solutions that we can spin up quickly in the cloud without needing to deploy new security software on servers and endpoints, or monkey around too much with on-prem hardware and appliances (these projects can be longer and more difficult).

I believe this is a very realistic starting point for new MSSP’s with only minor experience (i.e. if you consider yourself a “Baby SOC”).

For more information on these and other cybersecurity solutions built on the Microsoft cloud, check out my courses at SquareOne by ITProMentor.com.