Windows Information Protection Explained – Windows 10 Creators Update

 

With the release of Windows 10 Creators Update there have been many enhancements to Windows 10. For this post, I’ll focus on an expanded feature that is only available in version 1703 (i.e. Creators Update).

In Windows 10 version 1607 we released Windows Information Protection where devices that are enrolled with Microsoft Intune (or SCCM) may receive policies that protect corporate application content from data leaks. In Windows 10 1703 (i.e. Creators Update) a new feature called Mobile Application Management or MAM is available. If you’re familiar with MAM policies for Intune for iOS and Android we’ve brought similar functionality to Windows 10 Creators Update for non-managed devices. This means that non-managed devices such a home user PC with Creators Update can access corporate data without risking data leakage because the MAM policy will prevent cutting and copying data to unmanaged applications.


Requirements

  • Intune licenses
  • Global Admin for Azure Active Directory
  • Windows 10 Creators Update (any version)

Getting started

Service setup

  1. Navigate to portal.azure.com from a browser
  2. Select Azure Active Directory
  3. Select Mobility (MDM and MAM)
  4. Add or select Microsoft Intune

 

clip_image002

 

Verify the settings look similar to those in the image below. Add a group as well to make sure the policies flow to the proper individuals:

Note: if the MAM Discovery URL is missing, select “Restore default MAM URLs”

clip_image004

Policy setup

From the Azure portal locate the Intune Mobile Application Management (MAM) service. It will look similar to the following:

clip_image006

 

Select “App Policy” and “Add a policy” at the top. Give the policy a name and select Windows 10 under Platform.

clip_image008

 

Now we need to configure what apps the MAM policy will apply to. Do this by selecting “Allowed apps” and then “Add app” at the top of the blade:

clip_image010

Fortunately, many Microsoft applications are already published to select from, for the purposes of this post I’m going to select Microsoft Edge, Notepad, and IE11. The apps in this list are what we call “enlightened apps” where they know about MAM policies. Refer to the links at the end of this post for how non-enlightened apps are supported.

Note: For custom apps, desktop apps, etc. that need to be added, information about these apps is easily found using App Locker via the local policy editor on the device where the apps are installed. More details: https://docs.microsoft.com/en-us/windows/threat-protection/windows-information-protection/app-behavior-with-wip

clip_image012

 

Data Protection

After selecting apps from the list, in my case Notepad, Edge, and IE11 we now need to configure the behavior of when protected data is moved from those apps to non-protected environments (e.g. WordPad).

Select “Required settings” from the policy. The only change I made is to select “Allow Overrides” which means the user will be prompted when they attempt to relocate corporate data outside of the managed app (very similar to how MAM works with iOS and Android):

clip_image014

 

Now move to “Advanced settings” where there are a number of options to further restrict and identify boundaries.  For this post I’ll keep it simple by adding a cloud resource as a network boundary, in this case SharePoint Online and turn on “Show the enterprise data protection icon” for the protected enlightened apps:

clip_image016

Note: Once service and client are configured, you may encounter site access issues, to remediate, add the Value “|/*AppCompat*/” (no quotes) string to the end of the URL string, more details here: https://docs.microsoft.com/en-us/windows/threat-protection/windows-information-protection/app-behavior-with-wip

 

Once the boundaries are set and saved, we need to assign the policy to a group of users.  Feel free to create any group you want in Azure AD, I created one called MAM-WE_Users:

Note: users may be dynamically assigned to Azure AD groups as well for auto assignment to apps, licenses, etc., more details here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-groups-with-advanced-rules

clip_image018

Client setup

The end user will need to attach their non-managed (e.g. personal) Windows device with Creator Update to their workplace by selecting “Settings” then “Access work or school” and then “Connect” as shown below.

Note: Non admin users may enroll in MAM.

clip_image020

 

The user will then be prompted to sign on to their corporate account (i.e. O365, Azure AD, Intune, etc. if available) account as shown below (do not join Azure AD or local AD, typically this is performed only for corporate issued/owned devices).

To summarize, there are two steps, add your email and select next.

clip_image022

 

Once the account is verified, and the device is registered, select the account and the Info:

clip_image024

 

The “Info” button will show the last time the device had a successful sync. Also make sure the Management Server Address is populated. Keep this in mind as we’ll refer to this process after we have the MAM policy set up.

clip_image026

End User Experience

Because I’m protecting “.cbenterprisemobility.sharepoint.com” and selected both IE11 and Edge (they’re both enlightened apps) when I navigate to them we see a little briefcase icon show up.  When I navigate away from this site, the briefcase will go away.

clip_image028

clip_image030

 

For example, when I download a file from SharePoint Online, it will contain a little briefcase on the file icon as well as state the ownership of the file in “File ownership” column.  Additionally, the MAM policy can use either a custom EFS certificate or and Azure Information Protection template (RMS) to protect files.

clip_image032

 

When I open the file in a managed app (i.e. Notepad) and because the file is protected by policy, the app shows it’s managed by displaying a briefcase icon on the app itself:

clip_image034

Clicking on the briefcase icon we see the following:

clip_image036

 

When I attempt to cut, copy, and even open the file in an unmanaged app such as WordPad I receive the following prompt.  I can choose to give access in which case that action is logged to event viewer or cancel.  This prompt may be hidden from the user completely by changing the policy in Intune.  Separate policies may also be created and targeted at specific groups of users as well.  For example maybe you want to allow Executives to override as shown below and block certain users such as contractors, etc.

clip_image038

 

Closer look at the prompt:

clip_image040

 

If you need to change the file ownership, I right click on a file and change the file ownership to Personal if needed:

clip_image042

 

That’s all, we configured Mobile Application Management for a non-managed or domain enrolled Windows 10 client and successfully protected corporate content from leaking outside of corporate sanctioned applications.

Troubleshooting

  • First place to look is to make sure the settings are correct and sync’s are successful under Windows 10 Settings/Accounts/Access work or school
  • Next steps are to look in event viewer under: Application and Services Logs/Microsoft/Windows/Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin
  • MAM policies also land under: c:windowssystem32AppLocker folder and you can open the “policy” files in notepad.
  • You’ll also find the MAM policy settings populated under the following registry keys: HKEY_LOCAL_MACHINESOFTWAREMicrosoftPolicyManagercurrentdevice
  • When adding apps to protect, the prepopulated apps should be adequate, however if you’re adding protected apps by hand make sure the format is correct or the MAM policy will not take effect on that app.
  • When users upgrade from MAM to MDM on Windows Home edition, they lose access to WIP. On the Home edition, we do not recommend pushing MDM policies to enable users to upgrade.  More details here: https://msdn.microsoft.com/en-us/windows/hardware/commercialize/customize/mdm/implement-server-side-mobile-application-management

Closing thoughts

With all the data theft that happens daily, it’s better to have increased security for non-managed devices than simply guessing if your data is secure from those devices.  Whether your users have iOS, Android, or Windows devices, Intune MAM will protect all three.

Another option is to block unmanaged devices completely and Azure Active Directory Premium with or without Intune will address this scenario via Conditional Access.

For additional details about MAM with and without MDM as well as supporting desktop and custom apps, please refer to:

Azure AD Geolocation by sign-in activity using Power BI

 

If you’re an Office 365 customer or even an Azure customer then you’re probably familiar with Azure Active Directory (or Azure AD).  Azure AD is the core identity provider that the majority of Microsoft services rely on for authentication.  For today’s post I thought it would be interesting to pull sign-in activity into Power BI and show how simple it is to display a dashboard of geolocated sign-ins by user and device.

 

Assumptions

The user creating Power BI reports has an Azure AD Premium and Power BI licenses assigned

Note, if a new user account was recently created, I recommend waiting a day for the sign-in data to fully populate otherwise no sign-in data will be present.  Check the Azure AD Premium admin portal for sign-in activity for the user periodically.  Once the sign-in data is present, refresh the Power BI dataset connection to pull it into Power BI.  More details here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-reporting-faq

 

First we’ll need to sign into Power BI and pull in the Azure AD Activity Logs Content Pack.  Do this in Power BI by selecting Get Data, Services (Get), then search for Azure.  Select Azure Active Directory Activity Logs (Preview) from the search results and provide your Azure AD domain name and then select next.

Once the Azure Active Directory Activity Logs (Preview) content is added we can begin to create a dashboard.  From the Power BI UI find the “Azure Active Directory Activity Logs” under Dataset and select it.  Under “Visualizations” select Map and under “Fields” expand “Signin Activity” and select City, Country, Name, and Total Signins.  Without any further modifications your map should look similar to the following:

 

image

 

Feel free to play around with the data to get the information you find most interesting or better yet, what your security team will find most interesting.  Hover over the data circles to display additional information about the data point.

 

Now a map of sign-ins may be all that is required, however I went a step further and created two slicers to drill in on certain data points.  To add slicers, select the Slicer image from under Visualizations from under Fields expand “Unique Users” and then select “Details.Name”.

 

image

 

To add another slicer, repeat the process from above, only instead of expanding Unique Users, expand “Signin Activity” and then select “Device Information”

image

 

Adding slicers enables me to check mark interesting information and drill down on that specific data point.  Pulling it all together the final dashboard looks like the following:

image

 

If I want to hone in on a specific data point, all I need to do is select either a data point under one of the slicers as shown in the gif below:

AADSigninPowerBI

 

Update
Add a slicer for date and time to show time based sign-in activity:

2017-03-30

This was just a simple method of creating a Power BI report that show’s a lot of rich data points that may help you understand where your users are logging in across the globe from what browser or device.  In addition, use the Azure AD Premium to create conditional access policies to protect user identities, corporate information, and block malicious devices, apps, and browsers from unsecure locations.

Azure Active Directory + O365 Conditional Access Scenarios Explained

Hi everyone, with all the cross integration between Azure Active Directory and Office 365 it time to explain these conditional access in detail.  While Office 365 offers a level of controls by service, Azure Active Directory and Microsoft Intune can come over the top of those services an provide further controls or leverage conditional access controls configured already in O365. 

Let’s dive into a few of these scenarios.

 

Device/App based conditional access with Microsoft Intune

Microsoft Intune offers various levels of conditional access based on device and app state.  Conditional access policies may be set on whether or not a device is enrolled with Intune (i.e. MDM) or if the designated application is being used to access email (e.g. Outlook app vs. native email apps).  Additional controls of may be applied based on what type of app is allowed to access the service be that a web browser or a native application.  There are even application policies that may be applied to a mobile app to further control where data is moved, saved, etc. (i.e. Intune Mobile Application Management).

There are a wealth of conditional access controls available within Intune that may be used to protect company information from leaking.  The device based controls go beyond O365 services to 3rd party mobile apps, customer apps, on premises web apps, and 3rd party SaaS applications.

Intune also has integration with a number of 3rd party security and mobile defense partners such as Lookout, Citrix, Cisco ISE, and Skycure

 

O365 per app Conditional Access

One of many Azure Active Directory (Azure AD) differentiators from other identity providers (idps) is Azure AD can carve up O365 and apply Conditional Access (CA) policies on a service by service basis.  For example, a CA policy such as requiring Multi-Factor Authentication (MFA) can be applied to Exchange Online while leaving SharePoint Online without a CA policy (e.g. not prompt for MFA or allow a certain device type to access).  Azure AD can also apply conditional access policies on a per app basis for 3rd party SaaS apps and internal web apps via Azure AD Application Proxy.


SharePoint Online limited access

This is a new feature currently in preview, however it’s a form of Conditional Access.  Coupled with Azure AD Conditional Access policies, SharePoint Online access may be granted to browser based sessions with additional service/app restrictions configured through SharePoint Online.  For example, if the policies are configured in both services, and an end user attempts to access SharePoint Online on a device that isn’t enrolled with Microsoft Intune and/or SharePoint Online site is viewed as an unsecured device, the user will only have read only access.  In addition, download, print, and sync may be blocked as well.  This type of policy allows users to continue to be productive regardless of what type of device or browser being utilized.  Note: SharePoint on-prem is not supported.

The following is an example from my environment using Tor browser.  The user will receive a notification at the top of the SharePoint Online Page when accessed from an unsecured device or browser and block downloading and printing of content.  In addition a conditional access policy in Azure AD can be set to block access completely if needed.

clip_image001

 

OneDrive for Business and Mobile Application Management (MAM) in service features

A number of new device based access settings have been deployed directly to the OneDrive for Business (OD4B) service.  One of those is Mobile Application Management (MAM).  To utilize the MAM settings within OD4B an Intune license is required.  The MAM settings also are one in the same as those in Intune which means that if they’re enabled in OD4B they’ll show up in Intune and vice versa.  However, MAM settings in Intune will override those set in OD4B admin portal.

clip_image002

 

In summary, these features are all market differentiators and allow O365 and SPE or EMS customers to create unique sign-on and device based access scenarios on a per app basis across O365, 3rd party SaaS apps, and on-premises web applications.

 

When utilizing Office 365 I encourage everyone to consider the Enterprise Mobility and Security offering.

Azure AD Security – Protect Those Accounts, Services, and Audit Access!

Everyday I’m asked questions about Enterprise Mobility + Security as well as other Microsoft services. I’m also asked how we can provide single-sign on to SaaS and on-premises applications using Azure AD Premium. What surprises me though is how few organizations ask me about providing additional protection layers to protect accounts as well as the services themselves from credentials that have been compromised (unless I bring the topic up).  However, not a day goes by where I’m not asked about second factor authentication (i.e. Multi-Factor Authentication). Although MFA is extremely important and I highly recommend turning it on and testing within your organization, there are other important security mechanisms that can be turned on as well.

As you may have heard, identity is the new control plane, meaning protection starts at the account.

Azure AD Identity Protection

Do you have cloud only accounts or are you synchronizing your Active Directory accounts to Azure AD (e.g. O365, Dynamics CRM, etc.)? If you’re using O365 then you are, regardless of what identity provider you’re using. Azure AD Identity Protection can help you secure those identity today.

In a previous post I walked through setting up and implementing Azure AD Identity Protection, however below is a video where in the first half I log in as a user using a Tor browser and I’m able to access the service without challenge. In the second half, I turn on identity protection and when I attempt to sign on using a Tor browser, I’m challenged with multi-factor. A simple sign-on policy can protect you and your users from irregular sign-on activity and stolen credentials.

 

Azure AD Identity Protection Demo

Azure AD Privileged Identity Management (PIM)

Protecting the account itself is in my opinion non-negotiable and if you’re using Azure, O365, Dynamics CRM, Intune, or any other Microsoft services that leverage Azure AD, I highly recommend turning on Azure AD Identity Protection. However, what about protecting access to the service itself? You can by using Azure AD Privileged Identity Management.

What is Azure AD Privileged Identity Management?

Organizations want to minimize the number of people who have access to secure information or resources, because that reduces the chance of a malicious user getting that access. However, users still need to carry out privileged operations in Azure, Office 365, or SaaS apps. Organizations give users privileged access in Azure AD without monitoring what those users are doing with their admin privileges. Azure AD Privileged Identity Management helps to resolve this risk.

Azure AD Privileged Identity Management helps you:

  • See which users are Azure AD administrators
  • Enable on-demand, “just in time” administrative access to Microsoft Online Services like Office 365 and Intune
  • Get reports about administrator access history and changes in administrator assignments
  • Get alerts about access to a privileged role

Azure AD Privileged Identity Management can manage the built-in Azure AD organizational roles, including:

  • Global Administrator
  • Billing Administrator
  • Service Administrator
  • User Administrator
  • Password Administrator

Source

However, those are not the only roles available, did you know Exchange Online, Skype for Business, Intune, and many other roles are available as well? Which means global admins can protect access to elevated admin permissions and require admins to request access as well as provide additional info before their credentials are elevated.

More details about additional roles available in Azure AD PIM here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-privileged-identity-management-roles

The following video steps through a user elevating permissions to access the admin console for Skype for Business using Azure AD Privileged Identity Management. The user is only allowed one hour to accomplish their task (global admin can adjust the policy to span 1 to 72 hours if needed per role), once the one hour is up, the user would need to go through the process again to elevate their account permissions.

Azure AD PIM Demo

Reporting

Reporting on identity and access is critical as well. It’s important to have systems in place to protect identities and services, however it’s equally important to have insight as to who’s accessing the services, from where, from what, how, and when. Last week the Azure AD team announced an Azure AD content pack for Power BI.

Here are a few reports from a fresh environment I’ve created:

image

image

image

For more details on how to get started with Azure AD and the Power BI content pack please visit: https://powerbi.microsoft.com/en-us/blog/azure-active-directory-meets-power-bi/preview/

I encourage everyone to start protecting your identities and services today. There’s always going to be risk, why not reduce the risk by implementing safeguards to prevent unchallenged access.

Azure AD Identity Protection

With all the news about cyber-attacks and data leakage and stolen credentials, it’s important that a multilayered security approach is in place no matter how small or large the organization. Even as individuals, implementing a multilayered security approach for our personal accounts is beneficial (e.g. two-factor authentication).

I’ve posted in the past about Microsoft Advanced Threat Analytics (ATA) and Cloud App Security and how both solutions provide insight, alerts, and governance across on premises and cloud applications. Identities are the new control plane and securing them beyond just a password is a priority among many organizations I work with. If an identity is stolen, the person or even company is at risk for losing precious personal info and intellectual property which can have devastating financial implications that are difficult to recover from.

What keeps me up at night is that my customers may be at risk for leaked identities and other security vulnerabilities, so I do my best every day to educate them about threats and solutions Microsoft provides to assist with detection and remediation of these types of vulnerabilities and attacks.

Now I understand that there is no single fix or silver bullet to prevent attacks from happening. Security is typically implemented in a layered approach which is why Microsoft has invested significantly in multiple security oriented organizations over the past few years as well as ramped up their own solutions. See details here: https://www.microsoft.com/en-us/cloud-platform/enterprise-mobility-products

In my opinion, every organization should assume compromise, whether it’s a legitimate employee accessing information they shouldn’t by accident or a hacker that’s been sitting quietly monitoring network traffic for clear text passwords or by using a user name password acquired by social engineering. No matter what the scenario, it’s important to be notified of such occurrences. In my previous posts you’ll find Microsoft ATA and Cloud App Security look for user and entity behavior analytics (UEBA) as well allow for direct API access into well know services such as Office 365, Salesforce, Box, and so on. But what happens when credentials are leaked? How do you know when a user signs in from another part of the globe if it’s really them?

To combat against stolen credentials, Microsoft has released a solution called Azure AD Identity Protection that will assist with protecting user identities from being utilized in an unsecure manner. Based on the risk level, Azure AD Identity Protection will take appropriate action (based on a risk profile) such as requiring a user the change their password or by forcing multi-factor authentication.

First we need to define the types of risks events Azure AD Identity Protection detects today:

Leaked credentials Typically, when a breach occurs, credentials are sold or accessed on the dark web and used in attempt to access services.
Impossible travel to atypical locations Multiple sign-in’s from different locations across the globe.
Sign-ins from infected devices Device infected with malware that communicate with a bot server.
Sign-ins from anonymous IP addresses Typically done by proxying, for example using Tor browser.
Sign-ins from IP addresses with suspicious activity IPs which a high number of failed sign-in attempts occurred.
Sign-ins from unfamiliar locations Uses past sign-in locations to determine unfamiliar location.
Lockout events (not in public preview)

Read more about risk events here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-identityprotection-risk-events-types/

Setting the risk detection levels

Now that we have an understanding of the type of risks detected, we need to set the risk level. Risk levels can be set as High, Medium, or Low.

There are two types of risk levels, User risk and Sign-in risk:

  • User risk indicates the likelihood that the user’s identity has been compromised.
  • Sign-in risk indicates the likelihood that someone other than the account owner is attempting to sign-on using the identity.

To set the risk detection levels navigate to https://portal.azure.com and sign-in with your administrator credentials (you have MFA enabled for all Azure admins right? 🙂 ).

Quick Tip: To further protect azure administrator accounts further see Privileged Identity Management.

To add Azure AD Identity Protection, select “New” on the left hand navigation bar, then type in “identity” then select “Azure AD Identity Protection” from the search results.

clip_image001

clip_image003

This will open a new blade, select “Create” at the bottom of the blade:

clip_image004

On the next blade, select “Create” again:

clip_image005

Once created you’ll see the following blade:

clip_image007

From here we’ll need to configure Azure AD Identity Protection so the service can start detection. Under “CONFIGURE” on the left hand side, select “User risk policy”. There are multiple options on the new blade to configure, mainly what users the policy will assigned to, the risk condition (High, Medium, Low), controls (require MFA or password change or both), and enforcing the policy by turning on or off.

Note: I recommend starting with a small subset of users to learn more about the user experience when an account is at risk.

clip_image008

For example, in my environment I have my user risk policy configured as follows:

Users

clip_image009

Conditions

clip_image011

Controls

clip_image012

Note: My sign-in risk policy is identical to my user risk policy.

For MFA, I require my users to register for MFA.

Analyzing the results

As the service begins to monitor it will begin to detect risks as shown below. I used a Tor browser to kick off events because the Tor browser will proxy through different parts of the globe. So it will simulate impossible travel and so on.

clip_image014

When I investigate by selecting the options below “INVESTIGATE” is see I have a couple users at risk and users that I’ve remediated. For these particular users who are flagged for risk, I can allow them through if I think their sign on is legitimate.

clip_image016

Here are the risk events that Azure AD Identity Protection has found:

clip_image018

Here are the Vulnerabilities Azure AD Identity Protection has found:

clip_image020

Clearly I need to go in and remove a few administrators from my demo environment, however with Azure AD Identity Protection, I’m made aware of these issues and vulnerabilities and I can take action.

End user experience

When an end user signs into Office 365 using a Tor browser they’ll have the following experience:

clip_image022

Select “More details”

clip_image024

Here is shows additional details about the app, device, and user:

clip_image026

Accessing Azure AD Identity Protection via Microsoft Graph API

For those who are interested in pulling the raw data out to import into their SIEM or BI you’ll want to look at the APIs for Azure AD Identity protection in Microsoft Graph: https://blogs.technet.microsoft.com/enterprisemobility/2016/08/02/apis-for-azuread-identity-protection-are-now-available-in-the-microsoft-graph/

Here I log into my MSOL account via PowerShell:

clip_image028

Then I ran a PowerShell script (example) to list all the risk events as shown below:

clip_image030

For a more readable format you can change the formatting of the raw output:

clip_image032

 

Or group by “location” for example…and so on:

clip_image002

To learn more about Azure AD Identity Protection, please visit: https://azure.microsoft.com/en-us/documentation/articles/active-directory-identityprotection/

Microsoft Cloud App Security

 

Have you ever wondered what is going on within the SaaS services your organization is using?

Are you curious about what unsanctioned SaaS apps employees may be storing company data in?

Do you want to know where and when sensitive data is stored in the cloud?

Do you want to know who’s accessing sensitive data in the cloud?

 

If you’re like me, those questions are top of mine when create a new cloud subscription and giving up control is sometimes difficult to do.  However, with Microsoft Cloud App Security you don’t have to give up control or visibility into SaaS based services anymore.

 

What is Cloud App Security?

Microsoft Cloud App Security is a comprehensive service that provides deeper visibility, comprehensive controls, and improved protection for your cloud applications. Cloud App Security is designed to help you extend the visibility, auditing, and control you have on-premises to your cloud applications.

Cloud App Security is a critical component of the Microsoft Cloud Security stack. It is a comprehensive solution that helps organizations take full advantage of the promise of cloud applications while maintaining control with improved visibility into activity. It also increases protection of critical data across cloud applications. With tools to help uncover Shadow IT, assess risk, enforce policies, investigate activities and stop threats, organizations can safely move to the cloud while maintaining control of critical data.

Source: https://technet.microsoft.com/en-US/library/mt489024(TechNet.10).aspx

 

The architecture of Cloud App Security is shown in the image below:

clip_image001

Image Source: https://technet.microsoft.com/en-US/library/mt489024(TechNet.10).aspx

 

Getting started with Cloud App Security

In the past, setting up security solutions required hardware and software, firewall configuration, etc. All things that require time and money to implement. However, with Cloud App Security setting it up is straight forward. Simply logon or start a trial of Office 365 and enable a trial of Cloud App Security from the O365 admin tenant.

More details here: https://technet.microsoft.com/en-us/library/mt657569.aspx

 

Using Cloud App Security

Once the Cloud App Security subscription is live, login to the admin portal and get a feel for the interface.

A fresh Cloud App Security interface won’t have any data in it, however mine does, as shown below:

image

The dashboard provides an overview of activities, alerts, and violations. Select any of the items to drill down for more information. On the left we see apps that are sanctioned and threat detections (I’ll cover this later in the post).

 

Application Discovery

Most organizations I speak with want to know who’s using what cloud applications and how much corporate data is being stored in sanctioned and unsanctioned cloud applications. Cloud App Security offers a method to manually or automatically (via log collectors), import traffic logs from network devices. By ingesting traffic logs into Cloud App Security you’ll gain visibility of cloud application and data usage.

See a list of supported network devices here: https://technet.microsoft.com/en-US/library/mt489024(TechNet.10).aspx

Here’s an example of what Cloud App Security found when I uploaded a network log file:

SNAGHTML1f1eafcd

Based on the log file, Cloud App Security discovered 512 applications in use across the organization with only 7 of these sanctioned by the admin within Cloud App Security. In other words, 98% of the cloud applications discovered are unsanctioned applications. Let’s see how many of those applications are risky.

Notice on the left the term “Score”, the lower the score the riskier the application. So if an application has a score of 1 it’s potentially bad, but if it has a score of 10, the app is general well known, and marked as safer.  The scoring takes the information provide in the application and averages it.

Also, by looking at the results I can see that there are two cloud storage providers in use, OneDrive and Box. So as a company, a decision will need to made on what cloud storage provider to standardize on, then monitor usage in Cloud App Security over a period of time to make sure users are moving to the sanctioned cloud storage provider.

image

 

Looking at a risky application we see the following information. Compare a risky application with that of an application that have a higher score. Note that with the riskier application, little is known about the vendor and this application clearly does not meet any compliance regulations. However, if you find something to be incorrect, the setting and scoring can be manually changed.

image

 

What about off network devices?

If you’re interested in agent based application discovery that is integrated with Azure Active Directory, please visit: http://social.technet.microsoft.com/wiki/contents/articles/30962.getting-started-with-cloud-app-discovery.aspx – completely separate from Cloud App Discovery at this time.

 

Application Integration via API

Cloud App Security offers several applications that monitored and accessed via a direct API. For example, Office 365 and Salesforce.com have API integration directly with Cloud App Security (and there many more apps that have API integration as well, see https://technet.microsoft.com/en-us/library/mt657563.aspx).

The advantage of having direct API integration is gaining visibility and control over the service. Do you recall at the beginning of this post I stated that I don’t like to give up control much? Cloud App Security gives control back.

For example, I have Salesforce.com configured with SSO using Azure Active Directory (Azure AD). I also do what’s called user provisioning into Salesforce.com with Azure AD, so as users are created in my on-premises AD environment, they are synchronized up to Azure AD. If there is the attribute of “Sales” in the “department” field of the AD user object, those users are automatically added to a Salesforce corporate group I created in Azure AD (this is called dynamic group membership). Once users land in that particular group they’re automatically provisioned into Salesforce.com. However, I still like to know when users are provisioned and de-provisioned from my SaaS services (e.g. Salesforce.com). In Cloud App Security I configured a policy that tracks account activity in Salesforce.com.

 

Let’s take a look at policies in Cloud App Security

From the Cloud App Security admin portal, at the top select Control and Policies from the dropdown menu:

image

In my environment I’ve configured a few policies as shown below:

image

 

To create a policy, select “Create policy” in blue and select the type of policy you’d like to create:

Let take a moment to learn about the types of polices in the list before creating a new policy:

Activity Policy

Activity policies allow you to enforce a wide range of automated processes leveraging the app provider’s APIs. These policies enable you to monitor specific activities carried out by various users, or follow unexpectedly high rates of a certain type of activity.

Anomaly detection policy
Anomaly detection policies enable you to look for unusual activities on your cloud based on the risk factors you set here to alert you when something happens that is different from either the baseline of your organization or from the user’s regular activity.

App discovery policy
App discovery policies enable you to set alerts that notify you when new apps are detected within your organization.

Cloud Discovery anomaly detection policy
Cloud Discovery anomaly detection policies look at the logs you use for discovering cloud apps and search for unusual occurrences. For example, when a user who never used Dropbox before suddenly uploads 600 GB to Dropbox, or when there are a lot more transactions than usual on a particular app.

File policy
File policies enable you to scan your cloud apps for specified files or file types (shared, shared with external domains), data (proprietary information, PII, credit card information, etc.) and apply governance actions to the files (governance actions are cloud-app specific).

image

 

For the purposes of tracking Salesforce.com account activity I chose “Activity policy” from the menu. Within the policy creation page, I configured a number of fields as shown below. Basically the policy says, I want to be alerted when users are added to Salesforce.com. This helps me keep track of who’s using the service without having to log into Salesforce.com or Azure AD to find out. It’s a simple policy, but effective and gets me the info I need.

image

Because this is a fresh policy there is the option at the top to select from a pre-canned list of policy templates or create your own templates as shown below:

clip_image018

More details here: https://technet.microsoft.com/library/mt657556.aspx

 

Once a user is created in Salesforce.com an alert is generated that looks like the following:

Note: “Joe Sales” was created via Azure AD automatic account provisioning into Salesforce.com

image

 

Let’s take a look at a File Policy for DLP

I have files stored in O365 (i.e. SharePoint Online/OneDrive). My policy looks for credit card numbers and alerts me when it finds them. I can also configure the policy to take action automatically such as when it finds credit card numbers in files, remove permissions, quarantine the user who’s accessing them, and so on. If necessary, you can use regular expressions within policies as well. Here, I just use the canned “credit card number” expression and it works well.

image

When the policy combs through the files in the services configured (i.e. services that have direct API integration with Cloud App Security, in this case OneDrive) they’ll trigger alerts based on what it finds as shown below:

image

Let’s dig into the alert and see what it came up with:

image

Based on the screenshot above, Microsoft Cloud App Security used the DLP policy I configured to find the file with credit card numbers I planted in OneDrive. As an admin, I can take manual action or configure automated actions as shown previously during the file policy creation step.

Here’s what manual actions you can take if you need to investigate further:

image

 

Those are just a couple examples of application discovery, data loss prevention (DLP), policy creation and enforcement within Microsoft Cloud App Security. Find out what your business requires and configure policies based on those guidelines.

 

To learn more about Microsoft Cloud App Security please visit: http://www.microsoft.com/en-us/server-cloud/products/cloud-app-security/

Microsoft Windows Store for Business and Azure AD Join

With Windows 10 available, many organizations are considering upgrading. There are a lot of reasons to consider upgrading to Windows 10 and if you’re interested in learning more please visit: https://technet.microsoft.com/en-us/library/dn986867(v=vs.85).aspx

If you’re interested in learning more about the Windows 10 Roadmap for Business please visit: https://www.microsoft.com/en-us/WindowsForBusiness/windows-roadmap 

First I’ll walk through the registration of a Windows 10 device with Azure Active Directory (Azure AD), then I’ll walk through setting up WS4B.  After, I’ll access the Windows Store from a Windows 10 device where the private business store resides.

During the setup process, users will have the choice (if you’re not deploying using MDT or System Center Configuration Manager for auto deployment) to choose how they’ll authenticate. They can either perform a traditional domain join or join Azure AD.

To learn more about the differences between domain join and Azure AD join please visit: https://blogs.technet.microsoft.com/ad/2016/02/17/azure-ad-domain-join-windows-10/

If your devices are Azure AD joined and you maintain an AD forest on premises, then you’ll be interested in learning more about how to writeback the device objects to Active Directory on premises.

For more information on writing back device info to Active Directory please visit: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-feature-device-writeback/

There’s also the ability to have Windows devices automatically register with Azure AD as they’re domain joined.  Links about automatic device registration across the various Windows OS versions are below:

 

Joining a Windows 10 Device to Azure Active Directory

One of the advantages to joining devices to Azure AD is single sign-on (SSO) benefits. In traditional domain joined environments typically this is provided by way of a federated identity provider (e.g. Active Directory Federation Services or ADFS). However, when devices are joined directly with Azure AD the direct benefit is SSO to cloud applications such as Office 365 and other SaaS based applications that have a federated trust directly with Azure AD.

Let’s walk through how to join a device to Azure AD. The following walks through the OOBE experience, however devices that are already set up can be joined as well.

Note: if the device is already domain joined, refer to the links above for device writeback and registration.

Install Windows 10 and after Windows 10 has completed the setup process, select “Join Azure AD”

clip_image002

Type in a user name and password (make sure the user is licensed for Intune or EMS via the O365 admin portal). Select “Sign in” to enroll the device with Azure AD:

clip_image004

clip_image006

clip_image008

clip_image010 clip_image012

Once registration is complete I’m asked to set up a PIN:

clip_image014

PIN setup process

clip_image016

There are three methods to verify your identity via Multi-Factor Authentication. Select the method that best suits your needs. I chose to use the Mobile App.

clip_image018

Download or open the Azure Authenticator app on iOS, Android, or Windows Phone and scan the QR code or use the code provided:

clip_image020

Because I used the mobile app, Azure Authenticator has now registered the account:

clip_image021

Back on the Windows 10 device, once the QR code is scanned or entered and register with the Azure Authenticator app, the Next button lights up. Select Next.

clip_image023

Select how you’d like to authenticate; I chose to receive a notification on my phone (via the Azure Authenticator app):

clip_image025

clip_image027

On my phone, I select “Verify” to complete the process:

clip_image028

Lastly I need to select a country and enter my phone number and select Next:

clip_image030

Now I’m asked to provide a PIN:

clip_image032

After a pin is entered I’m logged into the device under the Azure AD credentials I registered with:

clip_image034

To prove I’m logged in as and Azure AD registered user, I open a command prompt and type in “whoami” without quotes:

clip_image035

On the backend, my device auto registers with Microsoft Intune for mobile device and application management. Intune will also deploy the policies I’ve configured such as configuring Windows Update, Windows Defender, Enterprise Data Protection, OS Upgrade, and so on.

For example, the following are the Windows Defender settings from the same device I registered, as you can see the settings are grayed out; that’s because my Intune policy was deployed to the device:

clip_image037

What about group policies?

If the device is enrolled and managed by Intune, I recommend sticking with Intune policies. However, if there are group policies that your organization already uses, then the more restrictive policy will always take precedence (either Intune or GP). The Intune admin console will point any conflicts out as well.

 

Windows Store for Business

What is Windows Store for Business?

With the new Windows Store for Business, organizations can make volume purchases of Windows apps. The Store for Business provides app purchases based on organizational identity, flexible distribution options, and the ability to reclaim or re-use licenses. Organizations can also use the Store for Business to create a private store for their employees that includes apps from the Store, as well private Line-of-Business (LOB) apps.

Source and more info: https://technet.microsoft.com/itpro/windows/whats-new/windows-store-for-business-overview

Now that I have my Windows 10 device registered with Azure AD (and enrolled with Intune), let’s take a look at the Windows Store for Business.

Navigate to: http://www.microsoft.com/en-us/business-store and either sign up or sign in with your organizational account.

clip_image039

clip_image041

 

The first thing I do is connect WS4B to Microsoft Intune. To connect the services, select Settings and then Management Tools:

clip_image043

Select “Add a management tool”

clip_image045

Search for Microsoft Intune and select Microsoft Intune from the list:

clip_image046

Microsoft Intune will be added and activated:

clip_image048

Adding Applications

Select “Shop” in WS4B to view and add applications. This is very similar to a volume purchase program (VPP):

clip_image050

Select an app to add, in my case I selected Foxit MobilePDF. Then select “Get the app” – other apps have online and offline options that you can select as well.

clip_image052

The distribute screen will open and we have a few options to select from as shown below. I selected to assign the app to people, in this case all FTE group I created in O365. Once you’ve selected an option select “Confirm” to add the app to the WS4B inventory.

clip_image053

clip_image054

Now I’m taken to the WS4B inventory page where all of the apps added may be seen and modified. Select an app to see who it’s been assigned to.

clip_image056

 

Intune Volume Purchase Program (VPP)

Let’s move over the Intune admin portal to view the VPP apps added by WS4B. After I log into Intune I select APPS then Volume-Purchased Apps. Here’s a brief list of some of the apps that came over from WS4B:

image

 

Windows Store for Business on the Windows Client

Let’s now look at where to access applications in the private store. To view the published apps search for or open the Windows Store on a Windows 10 machine (I’m using the device joined with Azure AD). From there you’ll see a list of tabs and on the far right there’s a new tab for WS4B as shown below:

 

clip_image060

 

In my environment I select “Contoso cbcloudmobility” and see the following apps I’ve published so far:

image

 

When I select Sway, I’m provided an option to install:

clip_image064

 

If you’re wondering if LOB apps can be published, the answer is yes. From the WD4B portal select “Manage” and then “New LOB Apps” from there you can go to the LOB Publishers page to invite publishers.

More details here: https://technet.microsoft.com/library/mt606952%28v=vs.85%29.aspx

clip_image066

 

This concludes the walk-through of registering a Windows 10 device with Azure AD and publishing applications via the Windows Store for Business. Try it out to see how it would work for your organization.