Check Logfiles Regularly

Once you have finished with one ring, move on to the next and carry out the same steps until all the devices have appropriate rulesets in place. Operations only start at this point. In this phase, it is important to continue to pay attention to the rules and to reports in Defender. Even though rulesets can be considered to be established after some time, you still want to check the reports regularly and analyze outliers. In fact, Microsoft recommends doing this on a daily basis. It is also important to check regularly any exceptions that were created and remove them again if needed. If you are unsure about the effect of a rule, you can switch it back to audit mode at any time, of course. If you want to check the rules that have been set, you can use the Microsoft Defender Advanced Threat Protection (ATP) portal [2], which is the place to go for in-depth information on potential attacks and to pick up scripts or code snippets that simulate attacks, and determine the effects on your systems' attack surfaces.

Three Recommended Standard Rules

Knowing the rules for reducing the attack surface and investigating them for your own requirements is important. Table 1 is an overview of the current crop of 19 attack surface rules (ASRs). All existing rules are unlikely to make sense in every infrastructure or situation. Microsoft only lists three rules for standard protection that you will want to enable without further analysis.

The basic rules include blocking the theft of credentials from the local Windows security authority subsystem (lsass.exe), blocking the exploitation of vulnerable signed drivers, and preventing persistence mechanisms with WMI event subscription, which is primarily an option used by malware to hide itself by using the WMI repository and to execute repeatedly on the target system. Incidentally, the first of the three rules for securing login information can result in numerous log entries, because legitimate apps sometimes also access this type of user data.

The rules can be roughly divided into five categories:

1. protection against exploits and exploitable vulnerabilities,
2. preventing the spread of malware by email and the web,
3. restrictions for Office applications that prevent the execution of malicious code,
4. measures against the theft of login information, and
5. blocking the execution of unsigned or untrusted processes.

Some of the rules use analysis results from Microsoft or other providers in the background. The rule that detects vulnerable signed drivers, for example, checks whether they have been recognized as dangerous elsewhere as soon as they are downloaded. If this is the case, the download is prevented. However, if a malicious driver is already running on a system, it can still be executed, and because these are signed drivers, no other protections are in place. If you would like to have a driver checked explicitly before using it, you can send it to Microsoft for analysis [3].

Hardening Office

Many of the rules relate to the use of Microsoft Office and the files or processes it creates. Time and time again, criminals use this software as a gateway for malware. You can deploy a rule to keep Office applications from creating executable content that allows malware to break out of the Office context and infect the system. Another Office rule keeps all Office applications from creating child processes. In concrete terms this means that processes cannot be started by Visual Basic for Applications (VBA) macros, for example, and stops malware that acts as a dropper from downloading custom code from the Internet and trying to execute it.

The rule for extended ransomware protection also draws on findings from the Microsoft cloud and the Microsoft Antimalware Protection Service (MAPS). To enable it, cloud protection must be active in Defender. This rule does not block files that have been identified as harmless online, have a valid signature, or are so widespread that they cannot be ransomware.

Another point of attack for malware can be shut down with the rule for blocking untrusted and unsigned processes that are executed over USB. This rule stops executable files (e.g., files with the extensions EXE, DLL, or SCR) launching from USB data carriers on a device, including files that users have copied from a connected USB data carrier to the device's hard drive. The rule is not as easy to work around as you might think at first glance.