Follow me on Twitter @AntonioMaio2

Friday, February 10, 2017

A Practical Overview of Office 365 Advanced Security Management - Part 3
Security Policies

Microsoft Office 365 Advanced Security Management is a capability within the Office 365 platform that allows organizations to go above and beyond the typical security management features, helping them to better secure users, permissions, content and apps. This multi-part blog series will look at how to use the features that make up Advanced Security Management (ASM) and share technical details that will help you to understand the benefits of these robust tools.

In part 1, we provided an Introduction to Advanced Security Management and shared technical information about how it works with the Office 365 Unified Audit Log: A Practical Overview of Office 365 Advanced Security Management - Part 1.

In part 2, we reviewed ASM's Productivity App Discovery Dashboard in depth to see how log files can be imported, how to create reports & interpret the analysis results and how you can try it with built-in sample logs: A Practical Overview of Office 365 Advanced Security Management - Part 2.

In part 3, we review the Security Policies that may be configured to control, monitor and alert on specific user behaviors.

Security Policy Configuration & Management

When configuring security policies its important to remember that policy configuration is never a "set it and forget it" activity. Security policies are almost always based on specific conditions and assumptions that are made at the time in which they are defined. Those conditions or the scenarios under which users work invariably change as our businesses, our roles and our work evolves. As well, the assumptions under which policies are defined can also change, or can be proven to be invalid over time.
  • For example, a business may define a security policy which assumes that the company will never do work outside of a specific part of the world. That policy may state that any logins from outside a specific country will not be accepted and a security team will be automatically alerted if such logins occur. Over time our businesses can expand and open new offices in locations which we didn't anticipate. As a result, this might require us to redefine those policies and therefore modify any configured security policies which are based on this condition.
  • Another example might be that certain internal user groups are not permitted to perform certain activities in the system because there is an assumption that those actions are not necessary for them to fulfill their job function. As a result, a security policy might be configured such that their user accounts are automatically disabled if those users activities are detected. Over time we may find specific work scenarios require users to perform those activities, or a subset of those activities, and that assumption can be proven to be incorrect. As a result, this may require us to reconfigure those security policies so that users are not inadvertently locked out.

These are some simple examples, but they illustrate that managing and modifying security policies that are automatically enforced in our organizations is an ongoing activity. Having a robust and easy to use security policy management console is an important requirement so that we can work with policies accurately and efficiently.

To access the security policy configuration page, we first click Control in the ASM menu and then select Policies:

This takes us to the ASM Policies page where we can create and manage security policies, and where you'll notice that we have 1 policy already configured by default:

The Templates menu item provides us with a slightly different interface for doing much the same thing: creating new policies. It allows us to first select the Policy Template we wish to base our policy on, and from that template create a new policy. We cannot add new policy templates, nor can we change the default settings for these templates. This menu brings us to the following page:

Once you have one or more security policies, the policy table on this page allows you to quickly review various important properties about those policies:
  • Policy name and description
  • The count of how many open alerts have been triggered based on that policy
  • The severity that has been configured for that policy - you can select a severity of Low, Medium or High when creating a policy
  • The category of the policy, which is selected from a list of 7 options when defining a policy - the options are:
    • Threat detection
    • Privileged accounts
    • Compliance
    • Cloud Discovery
    • Sharing control
    • Access control
    • Configuration control
  • The action which is applied to a user account if that policy is triggered - the options are:
    • Send an alert (bell icon)
    • Suspend the user account (lightning bolt icon)
  • Date the policy was last modified
  • Gear icon for modifying the policy settings
  • Ellipsis icon (...) for other options like disabling or deleting the policy

Filtering Policies

The Policies page also allows you to filter the policy list based on several different criteria. You can switch between Basic and Advanced filter controls by clicking the Advanced or Basic button in the top right corner of the filter banner:
  • The Basic filter controls allow you to filter your policy list based on Policy Type, Severity, Policy Name and Category. You simply select the values you want to use to filter your policy list from the dropdowns and controls presented.
  • The Advanced filter controls allow you to build multiple filters on top of one another to control at a very fine grained level which policies are displayed. You simply click the + button below the last filter when you want to add a new filter, and you then configure it. Or you can click the X button beside a filter to remove it. The policy view is automatically updated as each filter is configured.

These filtering controls are most useful when you have a large number of policies and your looking for a very particular policy within your list.

Default 'General Anomaly Detection' Policy

As mentioned, when you first enable ASM you already have 1 security policy configured by default. This is the General Anomaly Detection policy. This policy is pre-configured for you and designed to monitor and analyse all activity in your tenant to provide protection from suspicious logins or suspicious activities by user accounts.

The default General Anomaly Detection policy can be modified from its default configuration, or it can be disabled. However, it is strongly recommended that this policy remain enabled and remained configured with its default settings for risks that it monitors. The default settings include the following risk factors:

  • Notice above, you can enable or disable each risk factor. Again, it is recommended that each remain enabled for this particular policy.
  • More importantly, you can configure each risk factor to only apply to specific user activities. This is useful if you want to focus this policy on just specific activities that are considered risky or suspicious, like external sharing for example.

This policy and other 'Anomaly Detection Policies' are useful for issuing automated alerts in many scenarios such as:
  • If a user fails to log in too many times using the same credentials. This may be a sign that an attacker is trying to compromise an account with multiple password guesses.
  • If administrative account suddenly performs an activity that is uncharacteristic for that particular administrator. For example, if an administrator who in the past has never deleted or changed passwords on user accounts suddenly starts to perform several of those actions on multiple accounts within a short period of time. This may be a sign that an attacker has compromised an administrator account, or that a normally trusted administrator has started to perform malicious activity.
  • If an account that has been inactive for some period of time suddenly becomes active. This may be a sign that a user account belonging to an employee that has been away from work has been compromised by an attacker.
  • If a user account is logging in from a location, country or IP address that is considered risky. In this scenario ASM takes input from the Microsoft Security Graph which tracks suspicious or malicious internet activity based on IP address around the world. Using an Activity Policy (described below) you can actually customize this particular risk factor to either look at all locations or IPs that are considered 'risky', to look at activity coming from specific countries which you may know your users should not be working from or to look at activity from specific IP addresses.
  • If user logins occur from multiple locations within a short period of time, where we know that travelling between those locations in that short a time is impossible. For example, if a user logs in from New York now and 3 minutes later logs in from Europe and 3 minutes later logs in from Asia, and so on.
  • If a user logs in from a device type or web browser which that particular user has never accessed before. We have started to see these types of warnings from our online banks, where the first time that I use a new computer or web browser to access my bank account, that online service requires me to verify that it is in fact me. Automatically triggering that additional verification step by the end user is not yet built into ASM or Office 365, but automated alerts can be generated and issued based on this risk factor.
  • If a high rate of activity suddenly occurs from a particular user account which does not look like normal behavior for that user. For example, if a user who normally downloads less than 5 documents per month suddenly downloads 30 documents in 1 hour then this alert may be triggered.

You can and should modify the following settings for this policy so that the appropriate teams are alerted when suspicious behavior is observed:

  • You can determine how many alerts are sent per day, and you can specify which email addresses and/or mobile phone numbers are alerted. Multiple emails or phone numbers can be separated by commas.

As we've mentioned in other posts in this series, when ASM is enabled it creates a baseline profile for every user in your tenant tracking the activities that they perform on a day to day basis. This profile is created over a 1 week period. This gives ASM a data against which to compare future user behavior and therefore take note of behavior that's outside a user's typical pattern. The General Anomaly Detection policy is the security policy that uses those baseline profiles. If you have multiple General Anomaly Detection policies, each policy of this type will result in ASM calculating user profiles for each user that is affected by that policy.

Creating and Editing Policies

There are several ways to create new security policies. The primary methods are the following:
  • On the Policies page, from the banner at the top of the page, click the Create Policy button and then select 1 of 2 policy types:

  • On the Policies page, at the top of the policy table, click the Create Policy button in the policy table and select 1 of 2 policy types:

  • From the Policy Templates page, click the + button beside any of the policy templates to create a new policy based on that template:

When you create a new policy using the first 2 examples above, you must first select whether it will be an 'Activity policy' or a 'Anomaly detection policy'. On the policy templates page, you're selecting this implicitly based on the template on which you click the + button - essentially, all policy templates are Activity policies, except for the 'General Anomaly Detection' template. Activity policies are similar in configuration to Anomaly detection policies, in that they all require a name, description, template, category, and you have the same options available for how alerts are sent. However, there are some key differences:
  • Activity policy
    • Policy evaluation is based on the user activities that are selected as part of the policy. The policy does not use any user profile/baseline data that is calculated by ASM to determine what is 'normal' behavior and what is not.
    • You may select a alert severity.
    • You may select if a policy is triggered based on a single instance of the activity, or repeated instances. You may also select how many repeated instances within a specific time frame are required, if instances only within a single app are required and if the policy should count unique target files/folders per user in order to trigger an alert based on this policy
    • You may select if a user's account should be suspended if they trigger an alert based on the policy.
  • Anomaly detection policy
    • In addition to activities selected when configuring the policy, the evaluation of alerts for this policy type is also based on the user profile/baseline data that is calculated for each user and normalized across the organization. This helps ASM to determine what is normal behavior for each user and what is not.
    • By default, this policy type looks at all monitored user activity, but this configuration can be modified to focus the policy on only specific user activities if needed.
    • The policy looks at specific risk factors as discussed above, such as: Logon Failures, Admin Activity, Inactive Accounts, Location, Impossible Travel, Device and User Agent and finally Activity Rate.
    • The alert's severity is determined for you based on the risk factors that are selected as part of the policy.
    • You may configure an alert threshold for each anomaly detection policy. You may leave the default risk score that ASM uses to determine if alerts should be triggered which is recommended, or you can adjust this threshold if you have a specific need like you're getting too many false positives. This threshold causes alerts to only be triggered if the risk score of a certain detected activity is over a certain number. This can be configured Low, Medium or High, or between 35 and 95 in increments of 5. Every alert will have a risk score that is calculated by ASM based on the severity of its activities. This is a great feature for adjust risks used to trigger alerts if you are finding that you get too many false positives.

Activity Policies
When you create an Activity Policy, you will see the following page. Some of the steps in creating a policy are basic and have been described above like select a template, name, description, severity and category.

The real core of an activity policy is in the activities that you select to monitor. ASM policies are made up of filters that are very flexible and allow administrators to choose exactly which user activities they would like to alert on based on attributes like user, location, device, IP address, activity type and more.

  • In the 'Select a filter' dropdown select 1 out of 17 filters. These include Activity ID, Activity objects, Activity type, Administrative activity, Alert ID, App, Date, Device type, Files and folders, IP address (raw IP, category, tag), Impersonated activity, Location, Matched policy, Registered ISP, User (name, from a domain, from a group), User agent string or User agent tag.
  • Each filter will then require slightly different settings. Generally, you'll then select a condition (equal, not equal) and then the value that you wish to monitor - in this example we're monitoring for a particular types of activities. Notice in this dropdown you can select multiple activities
  • Click the + button below your last filter in order to add additional filters. You can then select the filter type and properties for that filter, and continue to build up the conditions you wish to monitor with this policy.
  • Note: all activities and properties selected in a policy are AND'ed together and therefore all must be true for alerts to be triggered by that policy.

Another nice feature is that you can even click the Edit and Preview Results button in the top-right corner of the section where you are configuring filters to get a quick preview of what the policy will find. This preview will be built based on searching your current audit log entries in ASM.

There is some great additional documentation on Cloud App Security which is applicable also to ASM available here: Activity Policies.

Anomaly Detection Policies
When you create an Anomaly Detection Policy, you will see a page very similar to the above, but with the same configuration settings as the default general anomaly policy shown earlier. You can create multiple Anomaly Detection Policies, up to a maximum of 5. Each policy can have an impact on performance given the work it must do. However, you might create multiple if you want to focus it on certain user groups with different outcomes or alerting different teams if suspicious activity is observed. For example, if suspicious behavior is observed in the general user community, you may wish to alert the organization's information security team. However, if suspicious behavior is observed within the information security team, then perhaps you want to alert the organization's CISO or their team. You can do this by configuring 2 such policies. Its important to note that ASM will not only create that per-user profile of activity (per Anomaly Detection policy), but it will also keep a per-user risk score to identify how risky a user's sessions generally are. These scores are not available for us to use, but used by ASM internally. However, ASM will also internally baseline the risk scores across the entire organization, because what is risky to 1 organization may not be risky to another. This logic helps ASM to avoid triggering too many alerts or false positives. In addition, as alerts are resolved within ASM (in the Alerts page) that feedback is used by ASM to adjust the risk scores and user baselines, and again improve how it alerts on suspicious user behavior.

Policy Outcomes
Finally, if a policy is triggered by a user, the outcome is a configurable combination of the following:
  • Log an alert in the Advanced Security Management Alerts page (to be reviewed in a future post)
  • (Optionally) Send an alert to one or more users or groups, either by email and/or text message
  • (Optionally) Suspend the user account to prevent it from logging in and kill any current sessions (only for Activity Policies). When a user account is suspended based on a triggered alert, if you need to re-enable the user account an Office 365 administrator who has the user administration role (or global administrator role) will need to do that within the Office 365 Administration Console, in the user management pages.

We do hope that more policy outcome options will be added in the future.

Editing Policies
In the table listing your policies, if you click anywhere on a policy like its name, description or some other property in the table you will be brought to the Alerts page and it will be filtered to show you alerts related to the policy you clicked on. To edit a policy you must click the Gear icon in the row for the policy you are configuring. You can also click the Ellipsis (...) to disable or delete a policy.
The pages to edit policies are the same as those used to create policies which are shown above.

What's Next

This post gave a detailed review of how to configure and make effective use of Security Policies within Office 365 Advanced Security Management. Clearly there is a lot of security value to be gained from these capabilities, allowing you to automatically monitor, alert and react to suspicious activities.

The next post will look at how to configure common use cases within the ASM management console, discussing scenarios in detail that are applicable to a wide range of organizations.


No comments:

Post a Comment