Follow me on Twitter @AntonioMaio2

Thursday, November 3, 2016

Office 365 Security
New Innovations Announced at Microsoft Ignite 2016

I had the privilege of attending the Microsoft Ignite 2016 conference in Atlanta, GA this past September.  It was of course full of great sessions, demos and announcements.  I was impressed at how many of those sessions focused on the security capabilities of the Office 365 platform. I left with the feeling that, through these sessions, announcements, demos and innovations, that Microsoft is clearly demonstrating their commitment and continued investment in providing a secure environment for our corporate data in Office 365.  They've robust feature set that enables both them as operators of the service, and us as customers and users of the service, to protect our sensitive data in Office 365.

That said, the security of our data, even within the Microsoft cloud, is always a shared responsibility. Microsoft provides the most secure cloud platform available and with that robust feature set, they give customers the ability to control how information is secured, accessed, shared, governed and monitored.  Its still up to us as customers to make efficient use of those controls in ways that protect our businesses and keep our users productive.

As we saw at Ignite, Microsoft has continued to innovate providing us ever more robust security controls for Office 365.  In this blog we're going to look at some of the great new security features that were demo'ed and revealed that Microsoft Ignite.  At the end of this blog, I've also included the slides from today's webinar.


1. Site Classification

Originally announced at the May the 4th "Future of SharePoint" event, there several demos at Microsoft Ignite that included the upcoming Site Classification feature.  This feature does not yet appear in public or First Release tenants, but we're told they're rolling out soon.  We've seen many organizations build this feature themselves as part of a custom site creation workflow.  This tends to actually be one of the most popular reasons for customizing the site creation process - in order to ask the site creator the question:

What is the sensitivity of the data that will be stored in this site?

Just about all organizations have sensitive data, but a very common security challenge for them is identifying what data is sensitive or where sensitive data is stored.  Sensitive data can't always be identified by DLP policies that automatically scan data looking for keywords, patterns or regular expressions.  Sometimes it takes a person to identify that a document or piece of data is sensitive.

Its nice to see this soon coming out as a standard feature for all to take advantage of!

Site classification may seem like a small feature but its one that has huge benefits for helping clients identify what data is sensitive, where it may live, and where it may not live.
  • At the time of site creation, it allows people to identify which sites may and which sites may not contain sensitive information.
  • It also educates users visiting a site, letting them know the sensitivity of the information contained within.  This can help users know that they cannot upload a 'confidential' document to a site classified as 'public' or 'general purpose'.

Essentially, the way the feature works is upon creating a site the creator is asked to select the classification of the site from a drop down of options.  The goal here is to have the site creator think about the type of information that will be stored within the site, its sensitivity to the organization and who it may be shared with.


We are told that the classification labels available in the dropdown (internal use, confidential, etc.) will be centrally configurable and may be customized, but we have not yet seen what this configuration looks like.

Below the site classification dropdown we have a User Guidelines link that allows us to provide the site creator with some direction on what the classifications mean.  We can provide a link to a custom page with these classification definitions, so that both site creators and end users visiting sites can better understand when to use each classification label.




Then when a user visits a classified site they'll see the classification label in the site header, informing them of the type of information permitted to be uploaded or added to the site, as well as how they may handle information already within the site.


Finally, we're also told that we'll have programmatic access to a site's classification, allowing us to enforce our own custom policies through custom code based on the sensitivity of data within the site. However, we haven't yet seen what this programmatic access will look like.

2. Conditional Access Policies

One of the most interesting announcements at Ignite was the introduction of Conditional Access Policies to SharePoint Online.  This feature is currently in preview with specific Office 365 customers and is not yet generally available to the public.

Conditional access policies can evaluate in real time the conditions under which a user is trying to access content on a SharePoint site.   These policies allow you to control the level of access a user has from a non-domain joined or un-managed device.  The conditions include the:
  • Permit all access to content from domain joined and non-domain joined devices.
  • Prevent all access to content from non-domain joined devices
  • If we want to allow some collaboration from non-domain joined devices but also ensure that corporate data is not leaked to personal devices, we can disable operations that allow the user to change or make a copy of your data, like download, print or sync content.  
In this last case a user can only use their device to read or view content.  There is no way for them to edit, delete or save a copy of the data onto an unmanaged device.  Enabling this policy also limits a user to using a web browser to access content.  Even if you try to print a document from the web browser's print function, you'll be prevented if this policy is enabled.
    • You can also specifically allow users to download files that cannot be viewed online (files that are not Microsoft Word, Excel, PowerPoint or OneNote files).

    The configuration of Conditional Access Policies is performed by a SharePoint Online administrator in your tenant in the following page:


    Optionally, you can also use policies to control access based on a user's "location".  In this case, "location" actually means the network that they are connected to.  We simply need to enable the policy and then supply the IP address ranges that we wish to allow access.


    If a user is connecting to SharePoint Online from one of these IP address ranges, they will be permitted to access the SharePoint sites.  If they are not connecting from a permitted IP address range, then they'll be denied access.  You do need to be cautious when configuring this policy option because if you misconfigure the IP ranges, you can inadvertently lock yourself out of all your SharePoint site collections.

    When configured, conditional access policies apply to all site collections.  There is no ability to configure these policies on a site-specific basis.

    There are additional conditional access policies that may be applied related to the compliance status of a device that is being used to access SharePoint sites.  These policies require deployment of Microsoft InTune to the organization.  You can learn more about these policies here: https://docs.microsoft.com/en-us/intune/deploy-use/restrict-access-to-sharepoint-online-with-microsoft-intune.

    3. Additional External Sharing Controls

    We've had some helpful External Sharing controls for the SharePoint Online administrator within a tenant for some time.  These primarily control the default sharing settings for all site collections, and External Sharing still needs to be enabled for each individual site collection, along with the type of sharing permitted.

    However, at Ignite we saw the addition of a few new controls.  




    As always, we can control the external sharing capabilities that are available for all site collections: 
    • whether to not allow external sharing at all
    • whether to permit sharing only with users that exist within the Azure AD directory - these are known users for which we have created accounts in our Office 365 tenant but not necessarily given them licenses
    • whether to permit external sharing and force users to authenticate - these are users with Microsoft accounts (hotmail.com, live.com, outlook.com, etc.) or other accounts federated with Office 365
    • whether to allow authenticated users and anonymous (guest) links
    We've been able to control the length of time that anonymous (guest) links are valid for some time as well.  

    As many know, we can only share the following types of objects or containers external:
    • Sites - only to authenticated users
    • Folders - to authenticated users and through anonymous (guest) links
    • Documents - to authenticated users and through anonymous (guest) links

    NEW: One thing that is new and can be seen in the screenshot is the ability to control specifically the actions users can perform when accessing folders or files through anonymous (guest) links.  
    • Select whether users can only view files or can view & edit files 
    • Select whether users can only view folders or can view, edit and upload to folders
    Keep in mind, some of these controls are not live yet in all tenants or even First Release tenants, and were demo'ed by Microsoft at Ignite in their own internal TEST environments.

    You've also been able to select the type of guest links that are available when sharing, either direct for internal users that have already been given permissions, internal for people that are already part of the organization but have not been given permissions, or complete anonymous for users outside the organization.

    Some of the additional settings we've also had for a while are:
    • Allowed Domains - permit sharing only to specific domains, by listing them (gmail.com, hotmail.com, customer domains, etc.)
    • denied domains - prevent sharing to specific domains, also by listing them
    • prevent external users from sharing files, folders or sites for which they are not the owner - this means that external users that you share content with will not themselves be able to share content with others that are external to the site, unless they are the owner
    • forcing external users to accept a sharing invitation from the email account it was sent to - this prevents external users from forwarding a sharing request to other users by forwarding the sharing email they received
    Keep in mind that these additional settings do not apply to anonymous (guest) links because those users do not need to authenticate when accessing content shared with them.

    Finally, there are some email notifications options for OneDrive for Business sites:
    • the owner of a OneDrive for Business site may receive an automated email when users to which content is shared invite additional users to access shared files within the site
    • a OneDrive for Business site owner can receive an automated email whenever an external user accepts a sharing invitation to access their files

    These notifications give OneDrive for Business site owners a lot more visibility and control around external sharing of their content.

    4. Enhanced DLP Policy Management

    At Ignite we saw that Microsoft has enhanced the process for creating DLP policies in Office 365.  Not only do we have a new streamlined user experience for creating DLP policies, which makes it much clearer to understand what we need to specify when we want to protect our sensitive data, but we also have new features for preventing sharing of sensitive data at more granular levels.  Office 365 has had Exchange DLP policies for quite some time, but now Microsoft is integrating Exchange DLP policies with SharePoint and OneDrive policies, so we can have a single set of policies which apply across all 3 workloads if we wish.

    Note: this user experience is not yet live in public or First Release tenants of Office 365.

    As usual, when we want to create a DLP policy we launch the Office 365 Security and Compliance center.  We then click on Security Policies in the left hand menu and click +Create.


    We then select the type of policy we wish to create, and they can be Financial, Medical or Privacy. The types of polices relate to subsets of the 80 sensitive data types now available with Office 365 DLP (data types like social security numbers, credit card numbers, drivers license numbers, etc.).  We can also create custom policies.


    Selecting a policy type will inform us of which sensitive data types are included in that policy template.  In this case our financial data policy will look for credit card numbers, bank account numbers and ABA routing numbers.


    We give our policy a meaningful name and description.


    We select where we want policies to be applied, either all locations/workloads or specific ones.  If we select specific locations, now we can not only choose SharePoint and OneDrive for Business, but we can also choose Exchange Online.  We can also optionally choose to include or exclude specific SharePoint sites.

    NEW: Exchange Online has had DLP built in for quite some time, but what's new here is that I can now select Exchange Online along with SharePoint and OneDrive for Business in the same DLP policy.  I can now manage 1 set of policies that apply to my data across a wider set of workloads.  I can also get very specific by either including or excluding specific SharePoint sites.  Having more choice when configuring security policies is a fantastic advancement.




    We then confirm the sensitive data types that were selected with our policy template (we selected Financial earlier), or we can select custom sensitive data types here.  We also select under which conditions does this policy apply - either when sharing content inside my organization, or only when it is shared outside the organization.


    Now we can choose additional settings that allow us to target very specific sharing scenarios in which we want our policy to apply.

    • We can select to show a policy tip and if we want to customize the tip, as we previously could. 
    • A new setting is the ability to detect the sharing of large quantities of sensitive data and specify what 'large' means - it could be 10 instances, 50, 100 or whatever your policy dictates.  
    • You can select to issue an incident alert and specify various settings about that incident alert such as who it is sent to.
    • You can also specifically block people from sharing content which contains this type of sensitive data, determine if a user is permitted to override the policy, if they must provide a business justification (which is logged) to override and if users automatically override the rule for the particular document if they report the warning as a false positive. 


    You can select if you wish to enable the rule now, or if you want to only run it in Test mode, which is a always recommended practice before deploying DLP policies to your Production environment.


    Finally, you can review or edit your policy settings one more time and create your policy.



    In terms of user experience, policies are enforced in the user experience largely as they previously were, with icons for documents containing sensitive data to show if a policy tip will appear to either warn the user or block the user from accessing the content.  Clicking the icons will display the policy tips, but they are now displayed in a side panel in the new library user experience.

    An important limitation that is still there with DLP policies is that they are only applied to documents, and not yet applied on list items.

    5. Hybrid Audit Logs & Insights

    Early this year Microsoft introduced Activity Monitoring or what is sometimes called the Audit Logs into Office 365.  This is a feature where various workloads in Office 365, like SharePoint, Exchange, OneDrive for Business and Administration will log all activities performed by both end users and administrators to a central 'audit log'.  As well, that log is searchable from the Security and Compliance Center, through PowerShell, or through the Activity Management API.

    Well, at Microsoft Ignite they announced that they will be shipping Hybrid Audit Logs and Insights with SharePoint 2016 Feature Pack 1, which is now due out in November (this month)!  This is great news!

    • It means that on premise SharePoint 2016 farms will be able to centrally configure audit logging so that logs are automatically shipped to an Office 365 tenant.  
    • Security teams and administrators will be able to centrally search all audit log entries from one interface, regardless of if the log entries are from an on premise environment, the online environment or both.  
    • Automated email alerts on suspicious activities may not be configured for both online activities and on premise activities from one interface. 

    Hybrid Auditing is configured through the SharePoint 2016 (with Feature Pack 1) Hybrid Picker.


    Accessing logs from the on premise SharePoint 2016 farm is then done through the same Audit Log Search interface currently used in Office 365.  You can search the audit log with that GUI based on date range, user, IP address, activity, document or item, or other details, and entries for both on premise and online environments will be included in your results.


    Ultimately, this means that security teams will be able to work with 1 set of logs and alerts for both on premise and online environments, more quickly identify suspicious or malicious behavior and more quickly react with appropriate action.

    6. Manage User Sessions

    Finally, whether it was introduced just before Microsoft Ignite or during the conference, there is another great new capability I want to highlight for securing access to your data.  Let's say I'm monitoring activity logs or I'm receiving alerts about suspicious behavior in my tenant, like a user downloading or deleting large amounts of data from a SharePoint team site.  If I trust the user, I may suspect that the user's account is currently being used by a malicious attacker.

    In this case I can easily take some immediate action through the user administration console to force the user to sign-out all sessions and have to re-authenticate to the service.

    In the user administration page, I can select a user and under their OneDrive Settings section there is a link to initiate a one-time event will force all of the user's current sessions to sign out and require that user to log in once again.


    This is a great feature that gives admins and security teams a quick and easy method of forcing a user to re-authenticate and potentially stopping an attacker who has taken over the user's account.  If you suspect that the user's credentials have been stolen you can also reset the user's password in the same user management console, and communicate that password to the user out of band.

    Today's Webinar

    Thanks to everyone that attended our webinar today on this topic.  It was a really quick review of some of the security innovations Microsoft announced at Office 365.  I hope this blog provides more detail on this feature set.



       -Antonio


    No comments:

    Post a Comment