Regulations and data management in a hybrid world

 

I speak with a lot of organizations and often they’re interested in locating, tagging, and controlling data for various reasons such as legal, regulatory, or protecting personal and proprietary information.

However, there’s one regulation that keeps popping up and it’s the new EU General Data Protection Regulation or GDPR.  GDPR will be enforced on May 25, 2018, which is just around the corner.  Unfortunately, GDPR is not a one-time process, it’s an ongoing regulation and failure to comply could result in heavy fines.  For most organizations, data may be stored across all types of systems and services including backups so locating and managing data across those environments may be difficult.

For this post, Microsoft provides guidance around GDPR and I’ve utilized some of the terms and guidance provided to simply the overview.

To learn more about how Microsoft is addressing GPDR please visit: https://www.microsoft.com/en-us/TrustCenter/Privacy/gdpr/default.aspx

The categories below align with the Microsoft GDPR guidance provided in documentation above, however I’ve attempted to simplify while targeting Office 365 and Enterprise Mobility + Security.  The last topic I’ll discuss is how to identity and classify information across SharePoint Server and file shares.

 

Let’s take a look at the four pillars of addressing data management requirements:

image

clip_image001[4]

 

Tying everything together, we have a process to identify, manage, protect, and report on data:

clip_image002[4]

 

Now that we have a definable process, let’s align the Microsoft services around all four categories, again the area of focus here is EMS and O365:

clip_image003[4]

image

 

 

Let’s take close look at some of the details across the Microsoft offerings:

Azure Active Directory

  • Lay the foundation for your organization by protecting access to sensitive information, which starts with modernizing your identities with Azure Active Directory. Whether a cloud or on premises application, Azure Active Directory will act as a controlled gateway to your data.

Azure Information Protection

  • Automated Classification, Labeling, and Protection + File scanner for file servers and SharePoint.

Office 365 Data Loss Prevention

  • Identify and retain data by applying retention policies to data across O365 services. Discover data through eDiscovery and actions on data via O365 audit logs.

Exchange Online

  • Prevent data from leaking by creating message rules to stop sensitive information from being sent through email. Ties into Data Loss Prevention as described above.

Microsoft Cloud App Security

  • Discover, monitor access, and apply governance to sensitive data across cloud services.

Microsoft Intune Application Protection

  • Protect information from leaking to non-protected applications and accounts across devices such as iOS, Android, and Windows.

Microsoft Power BI

  • Create insightful and visual reports by importing audit data into Power BI.

 

SharePoint Server and File Shares

I understand the previously mentioned services are great for managing data across cloud services, however what about on premises environments?

Azure Information Protection includes a scanning tool called the Azure Information Protection scanner or AIP scanner.  The AIP scanner is used to comb through file shares and SharePoint and identity and/or classify + protect data.

Once the AIP scanner is installed, use it to report on information you’re looking for and when discovery is complete, run the AIP scanner and apply classification and protection across those files.

Below is the output of an AIP scanner scan I ran against a few sample files.  The AIP scanner will look for specific information based on the AIP policies that are configured (e.g. credit card info).

image

For more information about the Azure Information Protection scanner please visit: https://docs.microsoft.com/en-us/information-protection/deploy-use/deploy-aip-scanner

 

All the services described above dovetail nicely with GDPR and other regulations requiring control of data.  If you don’t believe your organization is affected by a regulation such as GDPR I highly encourage further research as you may find out that your organization actually is.  Unfortunately, there are steep penalties with non-compliance so doing some research before May will save organizations time and money.

 

Again, to learn more about how Microsoft is addressing GPDR as well as managing data across other services such as Microsoft Azure, Dynamics 365, SQL Server, etc. please visit: https://www.microsoft.com/en-us/TrustCenter/Privacy/gdpr/default.aspx

Azure AD Connect Pass-Through Authentication – tracking sign-on activity with event viewer and Microsoft OMS

 

Quick post today around Active Directory sign-on auditing when using AAD Connect Pass-Through Authentication.

 

Azure AD Connect Pass-Through Authentication (PTA) provides the ability to pass authentication off directly to domain controllers. When passwords are reset or changed they’re reflected in Azure AD immediately via Azure AD Connect sync. Additionally, self-service password reset (SSPR) may be enabled in Azure Active Directory and those resets are written back to the domain controller as well.

To learn more about the available sign-on options please visit: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-user-signin

Many organizations already have extensive auditing set up to track sign-on activities and need to continue to track sign-on activity in across all services and need to maintain tracking no matter what services or applications are in use.  To continue the auditing practice with Azure AD Connect PTA let’s walk through how this is achieved.

 

Requirements

  • Active Directory Auditing is enabled via Group Policy.  Look under Audit Policies –> Logon/Logoff and Account Logon and enable auditing there.
  • Azure AD Connect with Pass-Through Authentication and Password Write Back enabled.
  • Optional: an additional Pass-Through Authentication connector deployed for high availability.

 

Example of my Active Directory audit policies:

image

image

 

Lets take a look at what to look for when using Azure AD Connect PTA.

As a user sign’s on to O365, or a federated SaaS app, or an internal application published to Azure AD, there are three events that are logged, two events to the domain controller: 4768, 4769 and one event to the server where ADD Connect is installed and PTA is enabled: 4624 (if additional PTA connectors are deployed for high availability look on those servers for 4624 as well).

 

On the domain controller look for events 4768 and 4769:

clip_image001

clip_image002

 

On the server where AD Connect is installed (and or additional PTA connector servers) look for event 4624:

clip_image004

 

Additionally, we can roll up these events to a SIEM for further aggregation of sign-on events and auditing. In my case I chose to use Log Analytics within the Microsoft Operations Management Suite:

clip_image006

 

To learn more about Azure AD Connect Pass-Through Authentication please visit the following links:

AAD Connect PTA: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication

AAD Connect PTA w/Desktop SSO: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso

AAD Connect PTA TS Guide: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-troubleshoot-sso

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/