diff --git a/.openpublishing.redirection.json b/.openpublishing.redirection.json index 505a82596b..7c1508564b 100644 --- a/.openpublishing.redirection.json +++ b/.openpublishing.redirection.json @@ -1,6 +1,11 @@ { "redirections": [ { +"source_path": "windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md", +"redirect_url": "/itpro/windows/keep-secure/create-wip-policy-using-intune", +"redirect_document_id": false +}, +{ "source_path": "windows/keep-secure/configure-windows-defender-in-windows-10.md", "redirect_url": "/itpro/windows/keep-secure/deploy-manage-report-windows-defender-antivirus", "redirect_document_id": true diff --git a/windows/deploy/change-history-for-deploy-windows-10.md b/windows/deploy/change-history-for-deploy-windows-10.md index 22008ff62d..d506e4b7fc 100644 --- a/windows/deploy/change-history-for-deploy-windows-10.md +++ b/windows/deploy/change-history-for-deploy-windows-10.md @@ -18,6 +18,7 @@ This topic lists new and updated topics in the [Deploy Windows 10](index.md) doc | [Deploy Windows 10 in a test lab using System Center Configuration Manager](windows-10-poc-sc-config-mgr.md) | Updated: The "refresh" and "replace" procedures were swapped in order so that it would not be necessary to save and restore VMs. Also a missing step was added to include the State migration point role. | | [Step by step guide: Configure a test lab to deploy Windows 10](windows-10-poc.md)| Updated with minor fixes. | | [Manage Windows upgrades with Upgrade Readiness](manage-windows-upgrades-with-upgrade-readiness.md)| Updated child topics under this node to include new feature and user interface changes. | +| [Get started with Upgrade Readiness](upgrade-readiness-get-started.md)| Added a table summarizing connection scenarios under the Enable data sharing topic. | ## RELEASE: Windows 10, version 1703 The topics in this library have been updated for Windows 10, version 1703 (also known as the Creators Update). The provisioning topics have been moved to [Configure Windows 10](../configure/index.md). diff --git a/windows/keep-secure/TOC.md b/windows/keep-secure/TOC.md index 38d5a79370..4a5486b19e 100644 --- a/windows/keep-secure/TOC.md +++ b/windows/keep-secure/TOC.md @@ -20,6 +20,7 @@ #### [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md) #### [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md) #### [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md) +#### [Deploy Managed Installer for Device Guard](deploy-managed-installer-for-device-guard.md) ### [Deploy Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md) ## [Mitigate threats by using Windows 10 security features](overview-of-threat-mitigations-in-windows-10.md) ## [Protect derived domain credentials with Credential Guard](credential-guard.md) @@ -33,7 +34,6 @@ ## [Protect your enterprise data using Windows Information Protection (WIP)](protect-enterprise-data-using-wip.md) ### [Create a Windows Information Protection (WIP) policy](overview-create-wip-policy.md) #### [Create a Windows Information Protection (WIP) policy using Microsoft Intune](create-wip-policy-using-intune.md) -##### [Add apps to your Windows Information Protection (WIP) policy by using the Microsoft Intune custom URI functionality](add-apps-to-protected-list-using-custom-uri.md) ##### [Deploy your Windows Information Protection (WIP) policy](deploy-wip-policy-using-intune.md) ##### [Create and deploy a VPN policy for Windows Information Protection (WIP) using Microsoft Intune](create-vpn-and-wip-policy-using-intune.md) #### [Create and deploy a Windows Information Protection (WIP) policy using System Center Configuration Manager](create-wip-policy-using-sccm.md) @@ -42,6 +42,7 @@ ### [Mandatory tasks and settings required to turn on Windows Information Protection (WIP)](mandatory-settings-for-wip.md) ### [Testing scenarios for Windows Information Protection (WIP)](testing-scenarios-for-wip.md) ### [Limitations while using Windows Information Protection (WIP)](limitations-with-wip.md) +### [How to collect Windows Information Protection (WIP) audit event logs](collect-wip-audit-event-logs.md) ### [General guidance and best practices for Windows Information Protection (WIP)](guidance-and-best-practices-wip.md) #### [Enlightened apps for use with Windows Information Protection (WIP)](enlightened-microsoft-apps-and-wip.md) #### [Unenlightened and enlightened app behavior while using Windows Information Protection (WIP)](app-behavior-with-wip.md) diff --git a/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md b/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md deleted file mode 100644 index fa9e88df53..0000000000 --- a/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: Add apps to your Windows Information Protection (WIP) policy by using Microsoft Intune custom URI functionality (Windows 10) -description: Add apps to your Windows Information Protection (WIP) allowed app list, by using the Microsoft Intune custom URI functionality and AppLocker. -ms.assetid: b50db35d-a2a9-4b78-a95d-a1b066e66880 -keywords: WIP, Enterprise Data Protection, protected apps, protected app list -ms.prod: w10 -ms.mktglfcycl: explore -ms.pagetype: security -ms.sitesec: library -author: eross-msft -localizationpriority: high ---- - -# Add apps to your Windows Information Protection (WIP) policy by using the Microsoft Intune custom URI functionality -**Applies to:** - -- Windows 10, version 1607 and later -- Windows 10 Mobile - -You can add apps to your Windows Information Protection (WIP) protected app list using the Microsoft Intune custom URI functionality and AppLocker. For more info about how to create a custom URI using Intune, [Windows 10 custom policy settings in Microsoft Intune](https://go.microsoft.com/fwlink/p/?LinkID=691330). - ->[!IMPORTANT] ->Results can be unpredictable if you configure your policy using both the UI and the Custom URI method together. We recommend using a single method for each policy. - -## Add Store apps -1. Go to the AppLocker UI by opening a command line window and running secpol.msc. The local security policy MMC snap-in opens showing the **Security Settings**. - -2. In the left pane, expand **Application Control Policies**, expand **AppLocker**, right-click **Packaged app Rules**, and then click **Automatically Generate Rules**. - - The **Automatically Generate Packaged app Rules** wizard opens, letting you create WIP-protected app polices for all of the installed apps on the device or for packaged apps within a specific folder. - -3. In the **Folder and Permissions** screen, keep the default value of **Everyone** in the **User or security group that the rules will apply to** box. - - You want to keep this value because your WIP policy needs to apply to the device being managed, not a single user or group of users. - -4. Type the name you’ll use to tag the rules into the **Name to identify this set of rules** box, and then click **Next**. - - This name should be easily recognizable, such as *WIP_StoreApps_Rules*. - -5. In the **Rules Preferences** screen, keep the default settings, and then click **Next** to start generating the rules. - - >[!Note] - >We recommend that you use **Publisher** rules because they only work with apps you've specifically defined and they can be configured to not require updating simply because a new version came out.

If you can't use **Publisher** rules, we then recommend that you use **File hash** rules. **File hash** rules are a secure alternative that can be used on unsigned code. The primary disadvantage to **File hash** is that every time a binary changes (such as, through servicing updates or upgrades), you'll need to create a new rule. - -6. In the **Review Rules** screen, look over your rules to make sure they’re right, and then click **Create** to add them to your collection of rules. - -7. In the left pane, right-click **AppLocker**, click **Export Policies**, go to where you want to save the XML file and type a file name, click **Save**, and then clear your AppLocker rules. - - >[!Important] - >Be aware that what you're saving are the actual AppLocker rules using your local policy. You don't want to apply these rules to your employee devices, you just want to use them to create and export the XML content. You must delete the AppLocker rules before you apply your policy. - -8. Open the Intune administration console, and go to the **Policy** node, click **Add Policy** from the **Tasks** area, go to **Windows**, click the **Custom Configuration (Windows 10 Desktop and Mobile and later)** policy, click **Create and Deploy a Custom Policy**, and then click **Create Policy**. - -9. Type a name (required) and an optional description for your policy into the **Name** and **Description** boxes. - -10. In the **Add one or more OMA-URI settings that control functionality on Windows devices** box, click **Add**. - -11. Type your new **Setting Name** and **Description** into the associated boxes, keeping the default **Data Type** of **String**. - -12. In the **OMA-URI** box, type `./Vendor/MSFT/AppLocker/EnterpriseDataProtection//StoreApp EXE` - -13. Open File Explorer, go to the location where you saved your new XML file, and open it using an XML editor, such as Notepad. - -14. Copy the text that has a **Type** of `Appx`, within the **RuleCollection** tags, and then go back to Intune and paste the text into the **Value** box of the **Add or edit OMA-URI Setting** box. For example: - - ``` - - ``` - -15. Click **OK** to close the **Add or edit OMA-URI Setting** box, and then click **Save Policy**. - - After saving the policy, you’ll need to deploy it to your employee’s devices. For more info, see the [Deploy your Windows Information Protection (WIP) policy](deploy-wip-policy-using-intune.md) topic. - -## Add Desktop apps -1. Open the Local Security Policy snap-in (SecPol.msc). - -2. In the left pane, expand **Application Control Policies**, expand **AppLocker**, right-click **Executable Rules**, and then click **Automatically Generate Rules**. - - The **Automatically Generate Executable Rules** wizard opens, letting you create WIP-protected app polices by analyzing the files within a specific folder. - -3. In the **Folder and Permissions** screen, keep the default value of **Everyone** in the **User or security group that the rules will apply to** box. - - You want to keep this value because your WIP policy needs to apply to the device being managed, not a single user or group of users. - -4. Type the name you’ll use to tag the rules into the **Name to identify this set of rules** box, and then click **Next**. - - This name should be easily recognizable, such as *WIP_DesktopApps_Rules*. - -5. In the **Rules Preferences** screen, keep the default settings, and then click **Next** to start generating the rules. - - >[!Important] - >You can also use **Path** rules instead of the **File hash** if you have concerns about unsigned files potentially changing the hash value if they're updated in the future. - - >[!Note] - >We recommend that you use **Publisher** rules because they only work with apps you've specifically defined and they can be configured to not require updating simply because a new version came out.

If you can't use **Publisher** rules, we then recommend that you use **File hash** rules. **File hash** rules are a secure alternative that can be used on unsigned code. The primary disadvantage to **File hash** is that every time a binary changes (such as, through servicing updates or upgrades), you'll need to create a new rule.

Finally, there's **Path** rules. **Path** rules are easier to set up and maintain, but can let apps bypass Windows Information Protection (WIP) by simply renaming and moving an unallowed file to match one of the apps on the **Protected App** list. For example, if your **Path** rule says to allow `%PROGRAMFILES%/NOTEPAD.EXE`, it becomes possible to rename DisallowedApp.exe to Notepad.exe, move it into the specified path above, and have it suddenly be allowed. - -6. In the **Review Rules** screen, look over your rules to make sure they’re right, and then click **Create** to add them to your collection of rules. - -7. In the left pane, right-click **AppLocker**, click **Export Policies**, go to where you want to save the XML file and type a file name, click **Save**, and then clear your AppLocker rules. - - >[!Important] - >Be aware that what you're saving are the actual AppLocker rules using your local policy. You don't want to apply these rules to your employee devices, you just want to use them to create and export the XML content. You must delete the AppLocker rules before you apply your policy. - -8. Open the Intune administration console, and go to the **Policy** node, click **Add Policy** from the **Tasks** area, go to **Windows**, click the **Custom Configuration (Windows 10 Desktop and Mobile and later)** policy, click **Create and Deploy a Custom Policy**, and then click **Create Policy**. - -9. Type a name (required) and an optional description for your policy into the **Name** and **Description** boxes. - -10. In the **Add one or more OMA-URI settings that control functionality on Windows devices** box, click **Add**. - -11. Type your new **Setting Name** and **Description** into the associated boxes, keeping the default **Data Type** of **String**. - -12. In the **OMA-URI** box, type `./Vendor/MSFT/AppLocker/EnterpriseDataProtection//EXE` - -13. Open File Explorer, go to the location where you saved your new XML file, and open it using an XML editor, such as Notepad. - -14. Copy the text that has a **Type** of `EXE`, within in the **RuleCollection** tags, and then go back to Intune and paste the text into the **Value** box of the **Add or edit OMA-URI Setting** box. For example: - - ``` - - ``` - -15. Click **OK** to close the **Add or edit OMA-URI Setting** box, and then click **Save Policy**. - - After saving the policy, you’ll need to deploy it to your employee’s devices. For more info, see the [Deploy your Windows Information Protection (WIP) policy](deploy-wip-policy-using-intune.md) topic. - ->[!NOTE] ->Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this topic, see [Contributing to TechNet content](https://github.com/Microsoft/windows-itpro-docs/blob/master/CONTRIBUTING.md). - -## Related topics -- [Create a Windows Information Protection (WIP) policy using Microsoft Intune](create-wip-policy-using-intune.md) - -- [Deploy your Windows Information Protection (WIP) policy](deploy-wip-policy-using-intune.md) - -- [Create and deploy a VPN policy for Windows Information Protection (WIP) using Microsoft Intune](create-vpn-and-wip-policy-using-intune.md) diff --git a/windows/keep-secure/change-history-for-keep-windows-10-secure.md b/windows/keep-secure/change-history-for-keep-windows-10-secure.md index ece3a3c127..98cdb92a4b 100644 --- a/windows/keep-secure/change-history-for-keep-windows-10-secure.md +++ b/windows/keep-secure/change-history-for-keep-windows-10-secure.md @@ -16,6 +16,7 @@ This topic lists new and updated topics in the [Keep Windows 10 secure](index.md ## March 2017 |New or changed topic |Description | |---------------------|------------| +|[How to collect Windows Information Protection (WIP) audit event logs](collect-wip-audit-event-logs.md) |New | |[Mandatory tasks and settings required to turn on Windows Information Protection (WIP)](mandatory-settings-for-wip.md) |Updated based on Windows 10, version 1703. | |[Create a Windows Information Protection (WIP) policy using Microsoft Intune](create-wip-policy-using-intune.md) |Updated based on Windows 10, version 1703. | |[Deploy your Windows Information Protection (WIP) policy using Microsoft Intune](deploy-wip-policy-using-intune.md) |Updated based on Windows 10, version 1703. diff --git a/windows/keep-secure/collect-wip-audit-event-logs.md b/windows/keep-secure/collect-wip-audit-event-logs.md new file mode 100644 index 0000000000..fed5d91fb9 --- /dev/null +++ b/windows/keep-secure/collect-wip-audit-event-logs.md @@ -0,0 +1,172 @@ +--- +title: How to collect Windows Information Protection (WIP) audit event logs (Windows 10) +description: How to collect and understand your Windows Information Protection audit event logs by using the Reporting configuration service provider (CSP) or the Windows Event Forwarding (for Windows desktop domain-joined devices only). +ms.prod: w10 +ms.mktglfcycl: explore +ms.sitesec: library +ms.pagetype: security +author: eross-msft +localizationpriority: high +--- + +# How to collect Windows Information Protection (WIP) audit event logs + +**Applies to:** + +- Windows 10 and later +- Windows 10 Mobile and later + +Windows Information Protection (WIP) creates audit events in the following situations: + +- If an employee changes the File ownership for a file from **Work** to **Personal**. + +- If data is marked as **Work**, but shared to a personal app or webpage. For example, through copying and pasting, dragging and dropping, sharing a contact, uploading to a personal webpage, or if the user grants a personal app provides temporary access to a work file. + +- If an app has custom audit events. + +## Collect WIP audit logs by using the Reporting configuration service provider (CSP) +Collect the WIP audit logs from your employee’s devices by following the guidance provided by the [Reporting configuration service provider (CSP)](https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/reporting-csp) documentation. This topic provides info about the actual audit events. + +>[!Note] +>The **Data** element in the response includes the requested audit logs in an XML-encoded format. + +### User element and attributes +This table includes all available attributes for the **User** element. + +|Attribute |Value type |Description | +|----------|-----------|------------| +|UserID |String |The security identifier (SID) of the user corresponding to this audit report. | +|EnterpriseID |String |The enterprise ID corresponding to this audit report. | + +### Log element and attributes +This table includes all available attributes/elements for the **Log** element. The response can contain zero (0) or more **Log** elements. + +|Attribute/Element |Value type |Description | +|----------|-----------|------------| +|ProviderType |String |This is always **EDPAudit**. | +|LogType |String |Includes:| +|TimeStamp |Int |Uses the [FILETIME structure](https://msdn.microsoft.com/library/windows/desktop/ms724284(v=vs.85).aspx) to represent the time that the event happened. | +|Policy |String |How the work data was shared to the personal location: | +|Justification |String |Not implemented. This will always be either blank or NULL.

**Note**
Reserved for future use to collect the user justification for changing from **Work** to **Personal**. | +|Object |String |A description of the shared work data. For example, if an employee opens a work file by using a personal app, this would be the file path. | +|DataInfo |String |Any additional info about how the work file changed: | +|Action |Int |Provides info about what happened when the work data was shared to personal, including: | +|FilePath |String |The file path to the file specified in the audit event. For example, the location of a file that’s been decrypted by an employee or uploaded to a personal website. | +|SourceApplicationName |String |The source app or website. For the source app, this is the AppLocker identity. For the source website, this is the hostname. | +|SourceName |String |A string provided by the app that’s logging the event. It’s intended to describe the source of the work data. | +|DestinationEnterpriseID |String |The enterprise ID value for the app or website where the employee is sharing the data.

**NULL**, **Personal**, or **blank** means there’s no enterprise ID because the work data was shared to a personal location. Because we don’t currently support multiple enrollments, you’ll always see one of these values. | +|DestinationApplicationName |String |The destination app or website. For the destination app, this is the AppLocker identity. For the destination website, this is the hostname. | +|DestinationName |String |A string provided by the app that’s logging the event. It’s intended to describe the destination of the work data. | +|Application |String |The AppLocker identity for the app where the audit event happened. | + +### Examples +Here are a few examples of responses from the Reporting CSP. + +#### File ownership on a file is changed from work to personal +``` +110SyncHdr200212Replace200314Get200414./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logsxml<?xml version="1.0" encoding="utf-8"?> +<Reporting Version="com.contoso/2.0/MDM/Reporting"> + <User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com"> + <Log ProviderType="EDPAudit" LogType="ProtectionRemoved" TimeStamp="131357166318347527"> + <Policy>Protection removed</Policy> + <Justification>NULL</Justification> + <FilePath>C:\Users\TestUser\Desktop\tmp\demo\Work document.docx</FilePath> + </Log> + </User> +</Reporting> +``` + +#### A work file is uploaded to a personal webpage in Edge +``` +110SyncHdr200212Replace200314Get200414./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logsxml<?xml version="1.0" encoding="utf-8"?> +<Reporting Version="com.contoso/2.0/MDM/Reporting"> + <User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com"> + <Log ProviderType="EDPAudit" LogType="DataCopied" TimeStamp="131357192409318534"> + <Policy>CopyPaste</Policy> + <Justification>NULL</Justification> + <SourceApplicationName>NULL</SourceApplicationName> + <DestinationEnterpriseID>NULL</DestinationEnterpriseID> + <DestinationApplicationName>mail.contoso.com</DestinationApplicationName> + <DataInfo>C:\Users\TestUser\Desktop\tmp\demo\Work document.docx</DataInfo> + </Log> + </User> +</Reporting> +``` + +#### Work data is pasted into a personal webpage +``` +110SyncHdr200212Replace200314Get200414./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logsxml<?xml version="1.0" encoding="utf-8"?> +<Reporting Version="com.contoso/2.0/MDM/Reporting"> + <User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com"> + <Log ProviderType="EDPAudit" LogType="DataCopied" TimeStamp="131357193734179782"> + <Policy>CopyPaste</Policy> + <Justification>NULL</Justification> + <SourceApplicationName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT OFFICE 2016\WINWORD.EXE\16.0.8027.1000</SourceApplicationName> + <DestinationEnterpriseID>NULL</DestinationEnterpriseID> + <DestinationApplicationName>mail.contoso.com</DestinationApplicationName> + <DataInfo>EnterpriseDataProtectionId|Object Descriptor|Rich Text Format|HTML Format|AnsiText|Text|EnhancedMetafile|Embed Source|Link Source|Link Source Descriptor|ObjectLink|Hyperlink</DataInfo> + </Log> + </User> +</Reporting> +``` + +#### A work file is opened with a personal application +``` +110SyncHdr200212Replace200314Get200414./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logsxml<?xml version="1.0" encoding="utf-8"?> +<Reporting Version="com.contoso/2.0/MDM/Reporting"> + <User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com"> + <Log ProviderType="EDPAudit" LogType="ApplicationGenerated" TimeStamp="131357194991209469"> + <Policy>NULL</Policy> + <Justification></Justification> + <Object>C:\Users\TestUser\Desktop\tmp\demo\Work document.docx</Object> + <Action>1</Action> + <SourceName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING SYSTEM\WORDPAD.EXE\10.0.15063.2</SourceName> + <DestinationEnterpriseID>Personal</DestinationEnterpriseID> + <DestinationName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING SYSTEM\WORDPAD.EXE\10.0.15063.2</DestinationName> + <Application>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING SYSTEM\WORDPAD.EXE\10.0.15063.2</Application> + </Log> + </User> +</Reporting> +``` + +#### Work data is pasted into a personal application +``` +110SyncHdr200212Replace200314Get200414./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logsxml<?xml version="1.0" encoding="utf-8"?> +<Reporting Version="com.contoso/2.0/MDM/Reporting"> + <User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com"> + <Log ProviderType="EDPAudit" LogType="DataCopied" TimeStamp="131357196076537270"> + <Policy>CopyPaste</Policy> + <Justification>NULL</Justification> + <SourceApplicationName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT OFFICE 2016\WINWORD.EXE\16.0.8027.1000</SourceApplicationName> + <DestinationEnterpriseID>NULL</DestinationEnterpriseID> + <DestinationApplicationName></DestinationApplicationName> + <DataInfo>EnterpriseDataProtectionId|Object Descriptor|Rich Text Format|HTML Format|AnsiText|Text|EnhancedMetafile|Embed Source|Link Source|Link Source Descriptor|ObjectLink|Hyperlink</DataInfo> + </Log> + </User> +</Reporting> +``` + +## Collect WIP audit logs by using Windows Event Forwarding (for Windows desktop domain-joined devices only) +Use Windows Event Forwarding to collect and aggregate your WIP audit events. You can view your audit events in the Event Viewer. + +>[!NOTE] +>Windows 10 Mobile requires you to use the [Reporting CSP process](#collect-wip-audit-logs-by-using-the-reporting-configuration-service-provider-csp) instead. + +**To view the WIP events in the Event Viewer** +1. Open Event Viewer. + +2. In the console tree under **Application and Services Logs\Microsoft\Windows**, click **EDP-Audit-Regular** and **EDP-Audit-TCB**. + + + + + + + + + + + + + + diff --git a/windows/keep-secure/create-wip-policy-using-intune.md b/windows/keep-secure/create-wip-policy-using-intune.md index a4d71f320a..86c24132cb 100644 --- a/windows/keep-secure/create-wip-policy-using-intune.md +++ b/windows/keep-secure/create-wip-policy-using-intune.md @@ -417,12 +417,12 @@ There are no default locations included with WIP, you must add each of your netw Proxy servers proxy.contoso.com:80;proxy2.contoso.com:443 - Specify the proxy servers your devices will go through to reach your cloud resources. Using this server type indicates that the cloud resources you’re connecting to are enterprise resources.

This list shouldn’t include any servers listed in the Proxy servers list, which are used for non-WIP-protected traffic.

If you have multiple resources, you must separate them using the ";" delimiter. + Specify the proxy servers your devices will go through to reach your cloud resources. Using this server type indicates that the cloud resources you’re connecting to are enterprise resources.

This list shouldn’t include any servers listed in the Internal proxy servers list, which are used for non-WIP-protected traffic.

If you have multiple resources, you must separate them using the ";" delimiter. Internal proxy servers contoso.internalproxy1.com;contoso.internalproxy2.com - Specify the proxy servers your devices will go through to reach your cloud resources.

Using this server type indicates that the cloud resources you’re connecting to are enterprise resources.

This list shouldn’t include any servers listed in the Enterprise Proxy Servers list, which are used for non-WIP-protected traffic.

If you have multiple resources, you must separate them using the ";" delimiter. + Specify the proxy servers your devices will go through to reach your cloud resources. Using this server type indicates that the cloud resources you’re connecting to are enterprise resources.

This list shouldn’t include any servers listed in the Proxy servers list, which are used for WIP-protected traffic.

If you have multiple resources, you must separate them using the ";" delimiter. IPv4 ranges diff --git a/windows/keep-secure/deploy-managed-installer-for-device-guard.md b/windows/keep-secure/deploy-managed-installer-for-device-guard.md new file mode 100644 index 0000000000..cf53463610 --- /dev/null +++ b/windows/keep-secure/deploy-managed-installer-for-device-guard.md @@ -0,0 +1,182 @@ +--- +title: Deploy Managed Installer for Device Guard (Windows 10) +description: Explains how you can use a managed installer to automatically authorize applications deployed and installed by a designated software distribution solution, such as System Center Configuration Manager. +keywords: virtualization, security, malware +ms.prod: w10 +ms.mktglfcycl: deploy +localizationpriority: high +author: mdsakibMSFT +--- + +# Deploy Managed Installer for Device Guard + +Creating and maintaining application execution control policies has always been challenging and options for addressing this has been a frequently cited request for customers of AppLocker and Device Guard’s [configurable code integrity (CI)](device-guard-deployment-guide.md). +This is especially true for enterprises with large, ever changing software catalogs. + +Windows 10, version 1703 (also known as the Windows 10 Creators Update) provides a new option, known as a managed installer, that allows IT administrators to automatically authorize applications deployed and installed by a designated software distribution solution, such as System Center Configuration Manager. +A managed installer helps an IT admin balance security and manageability requirements when employing application execution control policies by providing an option that does not require specifying explicit rules for software that is being managed through a software distribution solution. + +## How does a managed installer work? + +A managed installer uses a new rule collection in AppLocker to specify one or more executables that are trusted by the organization as an authorized source for application deployment. +Specifying an executable as a managed installer will cause Windows to tag files that are written from the executable’s process (or processes it launches) as having originated from a trusted installation authority. + +Once the IT administrator adds the Allow: Managed Installer option to a configurable CI policy for Device Guard, the configurable CI component will subsequently check for the presence of the origin information when evaluating other application execution control rules specified in the policy. +If there are no deny rules present for the file, it will be authorized based on the managed installer origin information. + +> [!NOTE] +> Admins needs to ensure that there is a CI policy in place to allow the system to boot and run any other authorized applications that may not be deployed through a managed installer. +> +> Examples of CI policies available in C:\Windows\schemas\CodeIntegrity\ExamplePolicies help authorize Windows OS components, WHQL signed drivers and all Store apps. +> Admins can reference and customize them as needed for their Device Guard deployment. + +## Configuring a managed installer with AppLocker and configurable code integrity policy + +Setting up managed installer tracking and application execution enforcement requires applying both an AppLocker and configurable CI policy with specific rules and options enabled. +There are three primary steps to keep in mind: + +- Specify managed installers using the Managed Installer rule collection in AppLocker policy +- Enable service enforcement in AppLocker policy +- Enable the managed installer option in a configurable CI policy + +### Specify managed installers using the Managed Installer rule collection in AppLocker policy + +The identity of the managed installer executable(s) is specified in an AppLocker policy in a Managed Installer rule collection. +Currently the AppLocker policy creation UI and cmdlets do not allow for directly specifying rules for the Managed Installer rule collection, however a text editor can be used to make the simple changes needed to an EXE or DLL rule collection policy to specify Type="ManagedInstaller". + +An example of a valid Managed Installer rule collection is shown below. + +```code + + + + + + + + + + + + + + + + +``` + +## Enable service enforcement in AppLocker policy + +Since many installation processes rely on services, it is typically necessary to enable tracking of services. +Correct tracking of services requires the presence of at least one rule in the rule collection – a simple audit only rule will suffice. +For example: + +```code + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +``` + +### Enable the managed installer option in CI policy + +In order to enable trust for the binaries laid down by managed installers, the Allow: Managed Installer option must be specified in your configurable CI policy. . +This can be done by using the [Set-RuleOption cmdlet](https://technet.microsoft.com/itpro/powershell/windows/configci/set-ruleoption). +An example of the managed installer option being set in policy is shown below. + +```code + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +``` + +## Security considerations with managed installer + +Since managed installer is a heuristic-based mechanism, it does not provide the same security guarantees that explicit allow or deny rules do. +It is best suited for deployment to systems where each user is configured as a standard user and where all software is deployed and installed by a software distribution solution, such as System Center Configuration Manager. + +Users with administrator privileges on the system may be able to circumvent the intent of Device Guard configurable CI when the managed installer option is allowed. +If the authorized managed installer process performs installations in the context of a user with standard privileges, then it is possible that standard users may be able to circumvent the intent of Device Guard configurable CI policy. +In some cases, the heuristic tracking and authorizing applications may be active on the first execution of an application that is laid down from a designated managed installer. +Typically, this would occur if the managed installer executes the application directly as part of the installation process. +To avoid this, ensure that the application deployment solution being used as a managed installer limits running applications as part of installation. + +## Known limitations with managed installer + +- Application execution control based on managed installer does not support applications that self-update. +If an application deployed by a managed installer subsequently updates itself, the updated application files will no longer include the managed installer origin EA information and will not be authorized to run. +Enterprises should deploy and install all application updates using the managed installer. +In some cases, it may be possible to also designate an application binary that performs the self-updates as a managed installer. +Proper review for functionality and security should be performed for the application before using this method. + +- Although configurable CI policies can be deployed in both audit and enforced mode, the managed installer option is currently only recommended for use with policies set to enforced except in lab environments. +Using the managed installer option with configurable CI policies set to audit only may result in unexpected behavior if the policy is subsequently changed to enforced mode. + +- Modern apps deployed through a managed installer will not be tracked by the heuristic and will need to be appropriately authorized in policy. + +- Executables that extract files and then attempt to execute may fail the heuristic. +In some cases, it may be possible to also designate an application binary that performs such an operation as a managed installer. +Proper review for functionality and security should be performed for the application before using this method. + +- The managed installer heuristic does not authorize drivers. +The configurable code integrity policy being used must have rules that allow the necessary drivers to run. + +- In some cases, the code integrity logs will contain error events for native images generated for .NET assemblies. +Typically, the error is functionally benign as a blocked native image will result in the corresponding assembly being re-interpreted. +Review for functionality and performance for the related applications using the native images maybe necessary in some cases. \ No newline at end of file diff --git a/windows/whats-new/whats-new-windows-10-version-1703.md b/windows/whats-new/whats-new-windows-10-version-1703.md index 285eefdb36..0cdfd78a3e 100644 --- a/windows/whats-new/whats-new-windows-10-version-1703.md +++ b/windows/whats-new/whats-new-windows-10-version-1703.md @@ -202,7 +202,9 @@ To check out all the details, see [Configure Delivery Optimization for Windows 1 ### Uninstalled in-box apps no longer automatically reinstall -Starting with Windows 10, version 1703, in-box apps that were uninstalled by the user won't automatically reinstall as part of the next feature update installation process. (Apps de-provisioned by IT administrators will still be reinstalled) +Starting with Windows 10, version 1703, in-box apps that were uninstalled by the user won't automatically reinstall as part of the feature update installation process. + +Additionally, apps de-provisioned by admins on Windows 10, version 1703 machines will stay de-provisioned after future feature update installations. This will not apply to the update from Windows 10, version 1607 (or earlier) to version 1703. ## Management