03-02-2018 10:49 AM - edited 03-06-2018 08:33 AM
03-02-2018 10:49 AM - edited 03-06-2018 08:33 AM
Windows Defender System Guard: Making a leap forward in platform security with Memory integrity in Core isolation (VBS)
The escalating sophistication of cyberattacks is marked by the increased use of kernel-level exploits that attempt to run malware with the highest privileges and evade security solutions and software sandboxes. For example, kernel exploits famously gave the WannaCry and Petya ransomware a remote code execution capability, resulting in wide scale global outbreaks, the likes of which have not been seen in many years. Windows 10 remained resilient to these attacks, but Microsoft is constantly evolving protections to stay ahead of threat actors.
Since the initial release of Windows 10 (1507), enterprise customers have had the option to enable virtualization-based security (VBS) and hypervisor protected code integrity (HVCI) to increase platform threat resistance. In Windows 10 Creators Update (1709) we consolidated these system integrity features in Windows Defender System Guard.
In an upcoming release of Windows 10, we will be bringing a subset of VBS features to all editions of Windows to ensure our customers remain safe from increasingly sophisticated attacks. Devices that meet hardware and firmware requirements will have parts of VBS enabled by default. Additionally, as part of this effort, Hypervisor protected code integrity (HVCI) will also be available and turned on by default in clean installs; for older systems, customers will have the ability to opt in post upgrade using the UI in Windows Defender Security Center (WDSC). This enhancement will ensure that the kernel process that verifies code integrity runs in a secure runtime environment provided by VBS. This will allow Windows 10 to protect the widest possible range of diverse users and scenarios. As a Windows Insider, you are seeing this already in current builds as an opportunity for early adoption and feedback to our team!
In addition, with Memory integrity protection, kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable. This is an enhancement to intrusion prevention capabilities in Windows Defender Exploit Guard.
While hypervisor-protected code integrity compliance has been a requirement for all drivers since Windows 10 Anniversary Update (1607), some drivers may still not be compatible. This may cause devices or software to malfunction. Such issues may occur after Memory integrity protection has been turned on or during the enablement process itself. If you’re an application developer and want to validate if your drivers and software packages are compliant with memory integrity, you can follow the steps outlined here.
We worked hard to mitigate impacted experiences, so if an incompatibility exists for a boot-critical driver, Memory integrity protection will be silently turned off. If you encounter incompatibilities with other apps, Microsoft advises that you check for updates for the specific app and version encountering the issue before turning off memory integrity protection. The following links show some examples of commonly-used APIs that cause executable memory to be allocated, along with some example fixes:
Given the reliance on hardware and the need to have compatible kernel drivers, enabling a feature like memory integrity can be challenging even for adept users. In the next Windows 10 version, we will make enablement simple and straightforward to the end user, via the Windows Defender Security Center app to manage this feature set.
The Windows Defender Security Center app will include a new section called Device security.
The Device security section will show overall device status in terms of built-in hardware protection. VBS and memory integrity status are reported in Core isolation details.
In Core isolation, you can turn Memory integrity (hypervisor-protected code integrity) on or off. In some scenarios where you may encounter application compatibility issues, you may need to turn this off. This will require a system reboot.
At Microsoft, we are constantly innovating and raising the bar for security. We invest in next-gen security products, but some of our investments involve transforming the platform itself. Memory integrity protection using virtualization-based security is one of the ways in which we continue to harden the platform against sophisticated attacks.
Send us feedback via the Hub, log bugs, and help us make Windows 10 even more secure by emailing our team.
Chris Riggs and Nazmus Sakib
Windows Enterprise Security team
03-18-2018 04:15 AM
03-22-2018 03:40 PM
03-22-2018 05:50 PM
Hopefully at some stage all the rest of the Defender Suite will be able to be simply configured in a similar fashion? Although I'm guessing that by it's very nature that "Application Control" might be a bit more complex...
I have provided feedback/suggestions to Nazmus Sakib in a separate thread.
Now proceeding at testing the other functions related to the ASD Essential 8, good work on the expanding Defender Suite
05-11-2018 03:08 AM - edited 05-11-2018 04:24 AM
It would be nice if after enabling Memory Integrity in Core Isolation, the BSOD 'SYSTEM_THREAD_EXCEPTION_NOT_HANDLED' mentioned which driver tried to write to a memory page.
When booted in regular old "non-integrity" mode, the `Device Guard and Credential Guard hardware readiness tool` does not show any driver with executable pages on my system. This makes it hard to track down the offending driver. At this early point Windows does not write any BSOD error report to disk.
Edit: Hmm, I managed to enable a tiny bit more error reporting on screen. Now to figure out what it means (with address randomization it probably means almost nothing):