In today’s security environment it is really no longer possible for human beings to manage security, it typically needs to be out sourced to software. Signature based security is too slow to keep up with constantly changing attacks and the best way is to look for anomalies in behaviour patterns.

Office 365 Cloud App Security is service that is included in E5 licenses but also available as a separate stand alone purchase (called Microsoft Cloud App Security in the store). Unfortunately, you can’t add Office 365 Cloud App Security to Business plans only Enterprise plans.

Basically, Office 365 Cloud App Security allows you to configure policies that trigger alerts for specific activity as well as suspending accounts exhibiting suspicious activity. Let’s see how.

To get to Office 365 Cloud App Security you need to navigate to the Security & Compliance Center as an Office 365 administrator. Open the Alerts heading on the left and select Manage advanced alerts from the options that appear.

On the right you will see a check box to Turn on Office 365 Cloud App Security.

Once this has been selected you will be able to select the button to Go to Office 365 App Security.

On this page you may see a number of policies in place already. Here, I’m going add a new policy. To get to this page again I select the Control option from the menu across the top of the page and then Policies from the items that appear.

To add a policy I now select the Create Policy button on the right as shown above, and then Activity policy from the items that appear. You may have less items in this list, it depends on what licenses you have in place for your tenant.

For the Policy Template option I am going to select from a list of pre existing templates and use the Logon from a risky IP address which is described as:

Alert when a user logs on to your sanctioned apps from a risky IP address. By default, the Risky IP address category contains addresses that have IP address tags of Anonymous proxy, TOR or Botnet. You can add more IP addresses to this category in the IP address ranges settings page. 

You can see the list of existing policy templates above and of course, you can create your own custom one.

Once I have selected the policy I scroll down to the actual rules which appear in the Create filters for the policy section as shown above.

Basically you’ll see in this case that the rule looks at whether an IP is “risky” and the activity equals logon.

You can of course edit or define your own rules here if you want.

If you are wondering where the “risky” IP range is defined you’ll find these sorts of things in the upper left under the COG icon as shown above. In this case, look under the IP address ranges.

Once you save the settings you’ll be returned to the Policies page where you should now see the new policy as shown above.

To test this policy, I’m going to fire up a Tor browser and login to Office 365.

As expected, in a very short space of time (note it isn’t immediate. It may take a moment or two to appear) I get an alert and can view these by selecting the Alert option from the menu across the top of the page.

If I then click to open one of these alerts and select the General option in the middle of the page I get more information as shown above. You’ll see on the right that the IP category = “Risky” and this is because of a match to Tor and Anonymous proxy.

If I now select the User option in the middle of the page I get further information as to which user triggered this as shown above.

Likewise if I select the IP address option I get information about the networking in detail.

From here you can take actions on the alerts such as dismissing or digging deeper into the logs.

My advice would therefore be to enable all the default policy templates for your tenant as I have done for mine as shown above.

You’ll notice that I also have some custom policies in place as well. One of these is to provide an alert for repeated failed login attempts by a user.

Another policy is the one above that monitors logins by global administrators. You’ll see that I also restrict that policy to only apply when I am not on a corporate (i.e. office LAN) IP address.

My advice with custom policies is to start simply and broadly and tighten the rules up over time. There is nothing worse than setting a policy and getting deluged with alerts, so take it slow and increase restrictions over time to ensure you don’t overload yourself with false positives.

As I dig deeper into what is possible more I’m sure I’ll be adding additional policies to keep my tenant secure and provide a level of monitoring that no human could do. However, in today’s environment of increased attached I’d really recommend you look at adding Office 365 Cloud App Security to your tenant for enhanced protection.