MCAS is an amazing tool. My configuration has gone from 14 to 23 to 93 policies! The alert flood is serious! Unfortunately, that means that it’s really hard to find the serious stuff among the clutter. Let’s look at a couple of common policies that trigger a lot of alerts and take some action to reduce the noise.
Impossible Travel
The Impossible Travel policy can be a very noisy one. Our goal will be to elevate the serious alerts and reduce the informational ones. I’m going to consider that a failed login is informational and that what I really want to know is if there’s been a successful login so I can take immediate action.
- Add trusted IP’s
- Set to alert on Successful Signin only
- After review, consider Suspend user governance action
- Consider blocking specific user agents in another rule
The first step to reducing the number of false positives is to add your trusted IP’s into Cloud App Security. Enriching CAS with this data is well hidden. It’s actually under the gear icon next to your name when you’re logged into CAS. Click the IP address ranges option and then add all of your trusted IP addresses. This will cause the Impossible Travel alert to ignore any activity from those locations.
Next, we want to make sure that the policy is set to trigger on successful sign ins. This is now the default setting, but if your policy has been in effect for a long time, it might be set to All sign ins.
Those two settings alone should reduce the number of alerts significantly. Now we can move our severity settings up to high. Indicating to ourselves that an alert from this rule represents a network intrusion.
In my practice I send alerts generated by MCAS into Teams channels. However, we only send those with high severity. Policies that generate low severity as considered informational and we let those alerts stay within MCAS.
Block threatening user agent strings
It’s not that informational alerts aren’t useful. They can provide very useful information about attackers. For example, we found that most attempts on our cloud came from Windows 7, Firefox, or Unknown(BAV2ROPC) which is apparently an Outlook mobile client. To find the types of devices that are attacking your environment, look into the activity log for the alert and view the Device type field for locations outside our country. Click the device type field to get the exact user agent string you’ll need to create your rule. Since in our environment none of these things should be trying to login, I have created a rule that reviews the activity logs and suspends the user should any matching activity be found.
I should mention that soon after adding Unknown(BAV2ROPC) that my account became suspended due to attackers within my own Country. This actually made me happy! My conditional access rules prevent login from Countries other than my own, but it left open the vulnerability to attackers from the USA, this shutdown that at least via OWA.
Next, I added an additional filter for activity type does not equal failed login so that I can only be suspended in the event of a successful login.
By make a few simple changes we can greatly reduce the amount of noise generated by MCAS and begin to use it powers for good and provide our tech staff with real actionable material to work with.
All we do is support IT professionals. Help for IT Pros, Super Secret News, Security community, MSP Legislation community, Kits, papers, MSP training and more. https://www.thirdtier.net
