Of course the effects of a compromised kernel mode driver are more disastrous, but are they harder to compromise in the first place?
closed as too broad by Steffen Ullrich, kasperd, AndrolGenhald, schroeder♦ Nov 1 '18 at 15:13
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Two Terms to get familiar with for Windows kernel mode security are Virtualization Based Security and HyperVisor-Enforced Code Integrity.
Virtualization Based Security (VBS) - VBS uses hardware virtualization features to create and isolate a secure region of memory from the normal operating system.
HyperVisor-Enforced Code Integrity (HVIC) - uses VBS to beef up code integrity policy enforcement. Kernel mode code integrity checks all kernel mode drivers and binaries pre-execution, and blocks unsigned drivers or system files from being loaded into system memory. <-- Note this does not protect the integrity of kernel mode data. Modifying key data structures can still compromise system integrity. One example of this is to intercept and drop messages from sysmon (kernel mode) to logging (user mode)
While this HVIC is great for keeping simple unsigned malicious driver attacks out of kernel mode Return Oriented Programming attacks are still quite possible in the Windows kernel mode. This if properly done and combined with a signed but vulnerable driver(there are plenty of these out there) can lead to arbitrary code execution.
The compensating control that everyone should be using is to monitor all driver loads. As a next step, blacklist all known vulnerable drivers which are not required in your environment (and heavily monitor any known vulnerable drivers which are required). Finally, if you have a mature environment, white-list only the drivers you need and sleep a bit easier.