Looking Past Security Defaults
Microsoft is doing more and more to apply security defaults to our tenants, and in general, I applaud this effort. The huge scale of Microsoft 365 means that they have trillions of signals available to help them identify the biggest threats, and they’re using that data to identify the most important areas to harden—both by changing security defaults but also by making invisible changes to the service to address vulnerabilities.
However, as a tenant administrator, you shouldn’t assume that Microsoft will do all of your job for you. The security defaults in Entra, and the many other default security settings applied to Entra, Exchange Online, SharePoint Online, and Teams, are a starting point. They may suffice for smaller tenants, but for most of us, there’s still some additional work to be done. In this column, I want to touch on three specific alerts you should configure in your tenant to help make you aware of potential security issues as early as possible.
Alerting: Necessary, but not Sufficient
Before I point out my suggestions, it’s important that you understand the concept of alert fatigue, in which “busy workers… become desensitized to safety alerts, and as a result ignore or fail to respond appropriately to such warnings.” Airport security workers, nurses, and, yes, system administrators all suffer from that desensitization; humans are pretty bad overall at dealing with repetitive and constant alarms, especially if many of them turn out to be false. I mention that because just turning on these alert settings may not do you much good if you don’t have a good system for handling the alerts. That may be consolidating and filtering them through Sentinel or another SIEM; it might also involve fine-tuning the alerts to make sure you’re only getting the ones that are actually the most important to you.
Alert #1: Suspicious Email Sending Patterns
It’s certainly true that some people send or receive more mail than whatever the average is in your organization. For example, at my day job, it wouldn’t be unusual for our CEO to receive between 5 and 10x the number of messages per day, on average, that our least-active mailboxes get. But it would be unusual to see him suddenly receive 10,000 messages, or send messages to 50 previously-unseen recipients, in an hour.
Here’s an example of how to set alerts using Defender to warn you of unusual spikes in mail activity. If you wanted to fire an alert if your CEO’s mailbox sent more than 200 messages per hour, here’s what you’d do:
- Open the Defender portal and navigate to Email & collaboration > Policies & rules.
- Select Alert policy, then click + New Alert Policy.
- Give the policy a name, severity, and description. Set the activity type to Mail flow, then click Next.
- In the Create alert settings blade, create an alert where the activity is User submitted email and the mail submission type is Not junk. Then select the When the volume of matched activities reaches a threshold radio button.
- Enter 200 in the activities field and choose A single user in the On field, then click Next.
- Choose the users who should get the notifications, then click Next.
- In the Review your Settings page, review the settings and choose whether you want to enable the alert rule right now or later.
Alert #2: Suspicious Inbox Rules
The second alert is similar in structure to the first, but for a different purpose. Attackers who are able to compromise a mailbox login will often create inbox rules to redirect or hide messages that might indicate the compromise, or to forward messages for exfiltration. You can, and should, use the steps above to create an alert policy to notify you if users create rules that forward messages to external domains. In general, very few organizations have a legitimate reason for users to forward work email to an outside domain, so in addition to protecting you against compromise, this alert policy may also help you catch people who are sending sensitive data to external systems on purpose.
Alert #3: Unusual Sign-in Locations
The third alert is probably best understood as a signal indicating that you should investigate further. If you define named locations for your conditional access policies, then you can do two useful things. One is to block logins from certain places. For example, you might decide, quite reasonably, to block any access attempts from North Korea, Syria, Iran, and Russia, or to block access from certain IP ranges (such as your guest wireless network). Another is to use Entra ID Identity Protection risk detections to warn you of risky sign-ins, which may include sign-in attempts arriving from unfamiliar locations.
Moving Forward
It’s not enough just to configure these alerts, though. There are two other things you need to plan for.
First, have a plan for what you’ll do when you see one of these alerts. Who gets the alerts? What are they supposed to do next? What happens if the designated person is on vacation, out sick, etc? Is all of this stuff documented somewhere?
Second, put a reminder in your calendar to review the alert settings periodically. For example, if you’ve defined named locations and used them to signal risky sign-ins, do you need to update or change the set of locations you’re tracking?
Once you’ve done those things you may very well decide that there are other additional conditions you want alerting for, but these three will give you some immediate visibility into potential indicators of compromise that you need to know about ASAP. Don’t wait.
