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.
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: 5/23/2018 10:30 AM | Feedback