In order for Anti-malware policies to be enforced correctly, you must enable Managed Definitions to deploy Microsoft anti-malware definitions through Tanium. If your endpoints have Windows versions 7 or older, enable SCEP.
See Microsoft Technet: AppLocker for more information about creating AppLocker rules.
By default, blacklist rules allow all executables to be run. Whitelist rules allow only applications to be run by Administrators unless otherwise specified.
You should deploy a policy in audit mode with reporting enabled in your test environment before deploying the policy in your production environment. Review any warning events in the reports and modify the policy as needed.
Follow this example workflow to better understand how Protect’s default Whitelist Rule Template works.
Example workflow using default Whitelist Rule Template
This workflow can help you confirm you are achieving the results you want with your Protect whitelist policy.
- Enforce Protect’s default Whitelist Rules Template in Audit Only mode on a representative computer group.
- Create the AppLocker Warnings report to run for the appropriate number of days. The policy will need to be enforced for approximately 7 to 30 days in order to collect an accurate representation of user activity on the endpoint.
- Based on the aggregated data of blocked applications in the AppLocker Warnings report, click next to the application to go to Tanium™ Interact to view detailed event information about that specific application.
- Select the AUDIT row(s) in the resulting Question Results and click Drill Down.
- On the Create Question tab of the Select Drilldown Question window, begin typing applocker threat details and click on the resulting query Get AppLocker Threat Details Last X Days from all machines.
- In the Number of days to display results for field, enter the same number of days for which you created the report (in this example, 7) and click Go.
- The Question Results page will show the paths for the application. To allow the application to run, edit the policy and add the path in the Allow section of the policy.
- Click Enforce Changes and Confirm Save of Enforced Policy.
Complete EMET documentation is available in Microsoft's Enhanced Mitigation Experience Toolkit (EMET) 5.5 User Guide. If you are creating EMET rules, it is important to review and understand the toolkit. Be sure to thoroughly test EMET mitigations and their impacts before deploying them widely in your enterprise. For more information about application compatibility issues, refer to Microsoft’s EMET mitigations guidelines.
EMET rules can help prevent the most common techniques attackers might use to exploit vulnerabilities in computer systems by diverting, terminating, blocking, and invalidating those actions. EMET allows customers to leverage security mitigation that provides several unique benefits:
- EMET profiles help harden legacy applications: EMET can help manage the risk while old software is being phased out by making it harder for hackers to exploit vulnerabilities in legacy software.
- EMET profiles help verify SSL certificates trust while surfing websites: EMET offers the possibility to enforce a set of pinning rules that can verify SSL certificates of specified domains against their issuing Root CA (configurable certificate pinning) to prevent “man in the middle” attacks.
Be sure to consider the following when creating EMET rules:
- Because EMET can alter the execution of applications, it may cause some applications to crash unexpectedly. Be sure to test all EMET profiles before deploying them enterprise-wide.
- Different mitigations are available on different Windows operating systems, and EMET rules might need to be targeted at computer groups based on operating system type.
- Specific applications can “opt in” to certain EMET mitigations. Some mitigations might be system-wide and affect everything that runs on the host.
- Because changing the system-wide Data Execution Prevention (DEP) setting can cause service disruptions, Protect ignores the system-wide DEP setting in an EMET rule.
- A reboot might be required for some system-wide EMET mitigations.
- Configure EMET reporting settings to meet your needs before enforcing EMET profiles widely in the enterprise.
EMET reporting settings
If Tray Icon is selected, end users will receive popup notifications from EMET from the Windows Notification Tray in the taskbar. If Early Warning is selected, EMET-related information, including details about exploit activity, will be shared with Microsoft. If Windows Event Log is checked, EMET-related data will be logged to the Windows Event Log subsystem, and this data can be mined and monitored for information on potential exploits or application incompatibilities. These settings are enabled by default in EMET 5.5.
EMET’s default action settings
EMET’s configuration interface allows administrators to set default action to be taken when an exploit is attempted against a protected application. These settings are Stop on exploit, meaning the application will terminate or crash, or Audit only, meaning EMET will log the attack, but not terminate the process. Be aware that Audit Only is not supported for all mitigations. See Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) 5.5 User Guide for more details.
If EMET is causing applications to crash, see the Enhanced Mitigation Experience Toolkit (EMET) 5.5 User Guide for troubleshooting steps and further guidance, including the possibility that the application could be under attack.
With Protect, do not manage Windows Firewall with Group Policy Management Editor. In order for firewall policies created under Protect to take effect, the Group Policy Firewall setting must be set to Not configured.
Windows SRP is capable of blocking applications launched by the user. Windows SRP does not prevent Windows services from starting. SRP does not prevent SYSTEM privileges from launching applications. For more information, see Microsoft TechNet Software Restriction Policies.
|Maximum number of policies||100|
|Maximum number of AppLocker rules per policy||100|
|Maximum number of firewall rules per policy||1000|
|Maximum number of SRP management rules per policy||100|
Last updated: 7/17/2018 4:11 PM | Feedback