Managing Windows 10 with Intune – WIP for Office 365

When it comes to managing data these days it can definitely get a little crazy, there are just so many ways data moves around on different devices in different apps. Keeping a close eye on everything can be tricky, but one thing to help out here is Windows Information Protection (WIP). Previously known as enterprise data protection (EDP), windows information protection can help you protect against data leakage without disrupting employee workflows.

You can read more about it in the docs article.

In this blog I’m going to focus on Office 365, Teams and OneDrive since they’re closely intertwined and you’ll see why later.

Okay so let’s get started, from the Intune portal, head over to Client Apps. Here we’ll select “App protection policies” and then “Create Policy”

Go ahead and give it a name, select the platform and enrollment state.

One note if you choose without enrollment:

Before we get to Protected apps, let’s talk about AppLocker real quick. In short, AppLocker consists of application control policies that helps you control which apps and files users can run. In this case, Microsoft has pre-canned Applocker.xml file for the Office 365 suite that define the allowed and exempt apps for us.

Navigate here to grab the latest policies – https://docs.microsoft.com/en-us/windows/security/information-protection/windows-information-protection/enlightened-microsoft-apps-and-wip

Scroll down until you see the below Product Name. Click the blew hyperlink for “O365 ProPlus – Allow and Exempt AppLocker policy files (.zip files)”

Save them.

Extract them.

Now…you may be wondering, why didn’t I just use the ones that are already there and built in?

Mostly because I thought it was good information to know : ) Hah! Not just that but it helps you understand the process of uploading new AppLocker policy files should you go down that rabbit hole someday, not to mention if you wanted to edit them.

Any who, carrying on…

For each the Protected and Exempt apps, we’ll rinse and repeat here.

(If you skip ahead, you’ll see that we end up adding OneDrive and Teams to the protected apps, so feel free to just add them now to avoid some issues that we’ll remediate)

Choose “Import apps”

Click the blue folder to upload.

Select the “Allow” version first, then so the same for Exempt”

In case you’re wondering why it has 1810 in the title for the built in one, that is just the last update version. If you open the “README” that comes with the download you’ll see that’s the case.

For Required settings, we have the following options for how WIP gets enforced.

I’m going with “Allow Overrides” so that I can show the behavior without breaking any workflows.

We’ll come back to “Advanced settings” a little bit later, so for now let’s just hit okay and Create the Policy.

With the Policy created, let’s go ahead and assign it.

To speed things up, I’m going to manually sync my device from Settings > Accounts > Access work or school

Now the first thing we’ll notice is OneDrive is “updating files”, when realistically it’s in panic mode because of its ties to the Office 365 apps which is why I said earlier we’d address OneDrive and Teams. Then a few minutes later we can see Teams having a hard time as well.

What we need to do is go back to the app protection policy that we created, go into protected apps, and add Microsoft Teams and Microsoft OneDrive like such.

Go ahead and run another sync and those two apps will start to recover.

Teams might want to restart during this, best case it’ll hang in there until OneDrive is done processing the changes.

Eventually after a few minutes, Teams and OneDrive will be just fine again.

So now that we have our WIP policies in place, how can we tell?

One way is to open Task Manager and choose the “Details” tab, right click on a column and choose “Select Columns”. Scroll down and check “Enterprise Context”.

You’ll see when sorting by Enterprise context, that your domain and either (Unenlightened) or (Enlightened, Permissive) will show up. Those are the apps within your WIP policies!

Now, how else can we tell? Let’s head back to our WIP policy in Intune. Go into the advanced settings and turn on the “Show the enterprise data protection icon”

Once that’s enabled, you’ll see the brief case on the Teams app and icons on your OneDrive folders.

Some examples of this protection:

If I try copying information out of Teams or any Office program and paste into a non WIP protected application, I’ll see the following:

Trying to upload content to a browser, so this could be personal email or simply trying to upload corporate content where you shouldn’t.

And that’s it!

I have another blog half written that will go into the weeds a bit as well as the Auditing side of this so look out for that. I’d love to hear any questions, comments or corrections.

Thanks

Azure Policy: Your Enterprise Azure Resource Guardrails!

Introduction:

There are numerous conversations surrounding Azure Policy. This post will provide information to accompany those conversations. This post will be a living and constantly modified document throughout the product development.

Post Purpose:

The purpose of this document is to explain the following:

  1. What is Azure Policy

Intended Audience:

The intended audience will be Azure Cloud Engineers and Azure Cloud Security Engineers as well as any other related parties who need information and overview of Azure Policies as part of the overall security governance process of your organization.

What is Azure Policy

Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements. Azure Policy meets this need by evaluating your resources for non-compliance with assigned policies. For example, you can have a policy to allow only a certain inbound and outbound rule within a Network Security Group (NSG). Once this policy is implemented, new and existing resources are evaluated for compliance. With the right type of policy, existing resources can be brought into compliance. Later in this documentation, we'll go over more details on how to create and implement policies with Azure Policy as well as different Effect Types.

  • Effect Types - Azure Policy

This section will contain information on the different Effect Types that are associated with Azure Policy. Effect Types are exactly what is sounds like, a determined effect that will occur on a resource based on conditions of the Azure Policy. For example, you could have an Effect Type of ‘Deny’ that will disallow resources from being created based on conditions present in your Policy Definition (e.g. Resources are deployed in the improper Azure Region).

The subsections below will dive into a bit more detail, with practical use cases for each Effect Type.

  • Deny

Whenever a Policy has an Effect Type of ‘Deny’ any new resource that gets created that goes against the conditions defined within the Policy Definition, that deployment of such resources will be denied from creation.

Deny evaluation

When creating or updating a matched resource, deny prevents the request before being sent to the Resource Provider. The request is returned as a 403 (Forbidden). In the portal, the Forbidden can be viewed as a status on the deployment that was prevented by the policy assignment.

During evaluation of existing resources, resources that match a deny policy definition are marked as non-compliant.

Example: If a AZURE Cloud Engineer spins up a new Virtual Network, and attaches an NSG that have default Internet outbound rules, the Engineer will be denied resource creation due to Policy disallowing such actions.

  • Append

Append is used to add additional fields to the requested resource during creation or update.

Append evaluation

Append evaluates before the request gets processed by a Resource Provider during the creation or updating of a resource. Append adds fields to the resource when the if condition of the policy rule is met. If the append effect would override a value in the original request with a different value, then it acts as a deny effect and rejects the request. To append a new value to an existing array, use the [*] version of the alias.

When a policy definition using the append effect is run as part of an evaluation cycle, it doesn't make changes to resources that already exist. Instead, it marks any resource that meets the if condition as non-compliant.

Example: If an AZURE Cloud Engineer forgets to add a required Tag to a resource, upon creation and evaluation, that Tag will be added to the resource automatically.

  • Audit

Audit is used to create a warning event in the activity log when evaluating a non-compliant resource, but it doesn't stop the request.

Audit evaluation

Audit is the last effect checked by Azure Policy during the creation or update of a resource. Azure Policy then sends the resource to the Resource Provider. Audit works the same for a resource request and an evaluation cycle. Azure Policy adds a Microsoft.Authorization/policies/audit/action operation to the activity log and marks the resource as non-compliant.

Example:

If AZURE Cloud Engineer wanted to see how many resources are non-compliant against a condition within a Policy Definition, the engineer can use ‘Audit’ to get a gauge of compliance, evaluate, review, and plan for compliance remediation.

  • AuditIfNotExist

AuditIfNotExist enables auditing on resources that match the if condition, but doesn't have the components specified in the details of the then condition.

AuditIfNotExist evaluation

AuditIfNotExist runs after a Resource Provider has handled a create or update resource request and has returned a success status code. The audit occurs if there are no related resources or if the resources defined by ExistenceCondition don't evaluate to true. Azure Policy adds a Microsoft.Authorization/policies/audit/action operation to the activity log the same way as the audit effect. When triggered, the resource that satisfied the if condition is the resource that is marked as non-compliant.

AuditIfNotExists properties

The details property of the AuditIfNotExists effects has all the subproperties that define the related resources to match.

  • Type [required]
    • Specifies the type of the related resource to match.
    • If details.type is a resource type underneath the if condition resource, the policy queries for resources of this type within the scope of the evaluated resource. Otherwise, policy queries within the same resource group as the evaluated resource.
  • Name (optional)
    • Specifies the exact name of the resource to match and causes the policy to fetch one specific resource instead of all resources of the specified type.
    • When the condition values for if.field.type and then.details.type match, then Name becomes required and must be [field('name')]. However, an audit effect should be considered instead.
  • ResourceGroupName (optional)
    • Allows the matching of the related resource to come from a different resource group.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • Default is the if condition resource's resource group.
  • ExistenceScope (optional)
    • Allowed values are Subscription and ResourceGroup.
    • Sets the scope of where to fetch the related resource to match from.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • For ResourceGroup, would limit to the if condition resource's resource group or the resource group specified in ResourceGroupName.
    • For Subscription, queries the entire subscription for the related resource.
    • Default is ResourceGroup.
  • ExistenceCondition (optional)
    • If not specified, any related resource of type satisfies the effect and doesn't trigger the audit.
    • Uses the same language as the policy rule for the if condition, but is evaluated against each related resource individually.
    • If any matching related resource evaluates to true, the effect is satisfied and doesn't trigger the audit.
    • Can use [field()] to check equivalence with values in the if condition.
    • For example, could be used to validate that the parent resource (in the if condition) is in the same resource location as the matching related resource.

AuditIfNotExists Example:

Azure Policy evaluates Customer’s Azure Virtual Machines to determine if the Antimalware extension exists then audits when missing.

  • DeployIfNotExist

Similar to AuditIfNotExists, DeployIfNotExists executes a template deployment when the condition is met. This will trigger essentially ‘remediation’ upon the Azure resource to bring it into compliance based upon the Policy conditions.

DeployIfNotExists evaluation

DeployIfNotExists runs after a Resource Provider has handled a create or update resource request and has returned a success status code. A template deployment occurs if there are no related resources or if the resources defined by ExistenceCondition don't evaluate to true.

During an evaluation cycle, policy definitions with a DeployIfNotExists effect that match resources are marked as non-compliant, but no action is taken on that resource.

DeployIfNotExists properties

The details property of the DeployIfNotExists effects has all the subproperties that define the related resources to match and the template deployment to execute.

  • Type [required]
    • Specifies the type of the related resource to match.
    • Starts by trying to fetch a resource underneath the if condition resource, then queries within the same resource group as the if condition resource.
  • Name (optional)
    • Specifies the exact name of the resource to match and causes the policy to fetch one specific resource instead of all resources of the specified type.
    • When the condition values for if.field.type and then.details.type match, then Name becomes required and must be [field('name')].
  • ResourceGroupName (optional)
    • Allows the matching of the related resource to come from a different resource group.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • Default is the if condition resource's resource group.
    • If a template deployment is executed, it's deployed in the resource group of this value.
  • ExistenceScope (optional)
    • Allowed values are Subscription and ResourceGroup.
    • Sets the scope of where to fetch the related resource to match from.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • For ResourceGroup, would limit to the if condition resource's resource group or the resource group specified in ResourceGroupName.
    • For Subscription, queries the entire subscription for the related resource.
    • Default is ResourceGroup.
  • ExistenceCondition (optional)
    • If not specified, any related resource of type satisfies the effect and doesn't trigger the deployment.
    • Uses the same language as the policy rule for the if condition, but is evaluated against each related resource individually.
    • If any matching related resource evaluates to true, the effect is satisfied and doesn't trigger the deployment.
    • Can use [field()] to check equivalence with values in the if condition.
    • For example, could be used to validate that the parent resource (in the if condition) is in the same resource location as the matching related resource.
  • roleDefinitionIds [required]
    • This property must include an array of strings that match role-based access control role ID accessible by the subscription. You can consider this part of the ‘remediation’ part of Azure Policy.
  • DeploymentScope (optional)
    • Allowed values are Subscription and ResourceGroup.
    • Sets the type of deployment to be triggered. Subscriptionindicates a deployment at the subscription level, ResourceGroupindicates a deployment to a resource group.
    • location property must be specified in the Deploymentwhen using subscription level deployments.
    • Default is ResourceGroup.
  • Deployment [required]
    • This property should include the full template deployment as it would be passed to the Microsoft.Resources/deploymentsPUT API.

DeployIfNotExists example

Azure Policy evaluates SQL Server databases within Customer’s Azure subscriptions to determine if transparentDataEncryption (TDE) is enabled. If not, then a deployment to enable is executed.

  • Order of Evaluation

Requests to create or update a resource through Azure Resource Manager are evaluated by Azure Policy first. Azure Policy creates a list of all assignments that apply to the resource and then evaluates the resource against each definition. Azure Policy processes several of the effects before handing the request to the appropriate Resource Provider. Doing so prevents unnecessary processing by a Resource Provider when a resource doesn't meet the designed governance controls of Azure Policy.

 

Disabled is checked first to determine if the policy rule should be evaluated.

Append is then evaluated. Since append could alter the request, a change made by append may prevent an audit or deny effect from triggering.

Deny is then evaluated. By evaluating deny before audit, double logging of an undesired resource is prevented.

Audit is then evaluated before the request going to the Resource Provider.

After the Resource Provider returns a success code, AuditIfNotExists and DeployIfNotExists evaluate to determine if additional compliance logging or action is required.

 

  • Mode Types – Azure Policy

Mode Types are available for Azure Policy. There are two modes, ‘All’ and ‘Indexed’. We recommend you set the mode to ‘All’ in most cases. You should use ‘Indexed’ when creating Policies that enforce Tags or Resource Location.

  • Indexed

Indexed Mode only evaluates resource types that support Tags and Location. Indexed should be used when creating policies that enforce tags or locations. While not required, it prevents resources that don't support tags and locations from showing up as non-compliant in the compliance results. The exception is resource groups. Policies that enforce location or tags on a resource group should set mode to all.

  • All

All Mode evaluates resource groups and all resource types. All policy definitions created through the portal use the all mode. If you use PowerShell or Azure CLI, you can specify the mode parameter manually. If the policy definition doesn't include a mode value, it defaults to all in Azure PowerShell and to null in Azure CLI.