Tag: Security

All the Guards–Part 3

This article is a part of a series. The previous article can be found here:

All the Guards – Part 2 (Virtualization Based Security)

In this article I’m going to focus on the next component:

Device Guard

Device Guard is a group of key features, designed to harden a computer system against malware. Its focus is preventing malicious code from running by ensuring only known good code can run.


It’s worth noting here that these are enterprise features, and as such are included only in the Windows Enterprise client.


Device Guard consists of three primary components:
     – Configurable Code Integrity (CCI) – Ensures that only trusted code runs from the boot loader onwards. Requires code integrity policies
     – VSM Protected Code Integrity – Moves Kernel Mode Code Integrity (KMCI) and Hypervisor Code Integrity (HVCI) components into VSM, hardening them from attack.
     – Platform and UEFI Secure Boot – Ensuring the boot binaries and UEFI firmware are signed and have not been tampered with


When these features are enabled together, the system is protected by Device Guard, providing class leading malware resistance in Windows 10.

But:

Why we no longer use the Device Guard brand

When we originally promoted Device Guard, we did so with a specific security promise in mind. Although there were no direct dependencies between WDAC and HVCI, we intentionally focused our discussion around the lockdown state achieved when using them together. However, since HVCI relies on Windows virtualization-based security, it has hardware, firmware, and kernel driver compatibility requirements that some older systems can’t meet. This misled many people to assume that if systems couldn’t use HVCI, they couldn’t use WDAC either.


WDAC has no specific hardware or software requirements other than running Windows 10, which means customers were denied the benefits of this powerful application control capability due to Device Guard confusion.

But there is this article:

Windows 10 Device Guard and Credential Guard Demystified

that still talks about Device Guard??

also this:

Overview of Device Guard in Windows Server 2016

From what I can determine the major component to focus here is not Device Guard but:

Code integrity

So from:

Device Guard signing

Device Guard signing is a Device Guard feature that gives admins a single place to sign catalog files and code integrity policies. After admins have created catalog files for unsigned apps and signed the catalog files, they can add the signers to a code integrity policy.

Device Guard is a feature set that consists of both hardware and software system integrity hardening features. These features use new virtualization-based security options and the trust-nothing mobile device operating system model. A key feature in this model is called configurable code integrity, which allows your organization to choose exactly which software or trusted software publishers are allowed to run code on your client machines. Also, Device Guard offers organizations a way to sign existing line-of-business (LOB) applications so that they can trust their own code, without the requirement that the application be repackaged. Also, this same method of signing allows organizations to trust individual third-party applications.

From what I can understand of all this is that part of Device Guard kind of still exists but to implement you would need to implement:

Sign code integrity policy with Device Guard signing

The other part that was Device Guard is now Windows Defender Application Control (WDAC):

Deploying Windows Defender Application Control (WDAC) policies

The confusion about Device Guard is compounded by the way it is referred to in Endpoint Manager, for example here in the Windows 10 security baseline policy:

image

Here, it seems that Device Guard refers to things like Virtualization Based Security and items yet to be covered in this series, System Guard and Credential Guard.

Device Guard is good example of where all of this gets very confusing. It kind of exists but it doesn’t exist. It also seems to be referenced differently in different places. From what I can determine, unless you want to go down the path of signing your applications so they can all be verified at boot then don’t worry about Device Guard. Where you will need to consider some of the Device Guard feature is if you choose to implement Windows Defender Application Control which I have covered off previously here:

Windows Defender Application Control (WDAC) basics

and here

Basics of deploying Windows Defender Application Control (WDAC) using Intune

WDAC is more focused on software rather than hardware, while Device Guard, in its original form, was more about hardware. Again, very confusing. Unfortunately, the confusion with all these Guards doesn’t end here, so let’s move onto the next component:

Next – System Guard

All the Guards–Part 2

This article is a part of a series. The previous article can be found here:

All the Guards – Part 1 (Secure Boot)

In this article I’m going to focus on the next component:

Virtualization Based Security (VBS)

In order to use VSM, you’ll need a number of hardware features to be present and enabled in the firmware of the machine:
     – UEFI running in Native Mode (not Compatibility/CSM/Legacy mode)
     – Windows 64bit and it’s associated requirements
     – Second Layer Address Translation (SLAT) and Virtualization Extensions (Eg, Intel VT or AMD V)
A Trusted Platform Module (TPM) is recommended.

There is a more details in link in the above article of what you need but most modern PC’s today should be capable, however you may want to check this article:

The potential performance impact of Device Guard (HVCI)

The idea is that by enabling virtualization on devices, then you can start to “sand box” and isolate different processes on a machine in their own unique and protected container. However, to achieve all that (which will be covered in upcoming articles) you’ll need to enable virtualization on your device.

image

Various policies and configurations can achieve this for you automatically but to do it manually open Control Panel, then select Programs and Features and then Turn Windows features on or off on the left. Scroll through the list of features and expand the Hyper-V one as shown above. Select Hyper-V Hypervisor as shown, and then select OK to save and update your device configuration. Typically, you’ll also need to reboot your device for virtualization to be enabled.

Here are others ways you can enable this feature:

Enable virtualization-based protection of code integrity

I will also note that new Surface PC’s will come with this feature enabled per:

New Surface PCs enable virtualization-based security (VBS) by default to empower customers to do more, securely

There is a small performance hit to your device as is now running virtualised processes, however on most modern Windows devices you should not really notice this.

With that now complete we are ready to look at the next phase of this process:

Next – Device Guard

All the Guards–Part 1

A while back I wrote an article about all the Defender products Microsoft has:

All the Defenders

Turns out that Microsoft also has a range of “Guard” products as well. In general, you can think of Microsoft Guard products as interfacing and working in combination with the physical device to enhance the security of your environment.

You’ll also find that there is plenty of cross over between Defender and Guard products, for example, Windows Defender Application Guard (WDAG).

What I’m going to try and do here is look specifically at all the products that have the name ‘guard’ in them and show how they help improve the security of your environment. I will readily admit, that because of the integration of hardware and software here, getting definitive answers on many questions has proved extremely challenging. Thus, I’ll do my best here to share what I have learned but I’m sure there is still more to uncover.

To commence this journey we need to examine the actual Windows 10 boot process, which is nicely covered in this article from Microsoft:

Secure the Windows 10 boot process

and from which I’ll quote:

Secure Boot

When the PC starts, the firmware checks the signature of each piece of boot software, including UEFI firmware drivers (also known as Option ROMs), EFI applications, and the operating system. If the signatures are valid, the PC boots, and the firmware gives control to the operating system.


When a PC equipped with UEFI starts, the PC first verifies that the firmware is digitally signed, reducing the risk of firmware rootkits. If Secure Boot is enabled, the firmware examines the bootloader’s digital signature to verify that it hasn’t been modified. If the bootloader is intact, the firmware starts the bootloader only if one of the following conditions is true:


– The bootloader was signed using a trusted certificate. In the case of PCs certified for Windows 10, the Microsoft® certificate is trusted.
– The user has manually approved the bootloader’s digital signature. This allows the user to load non-Microsoft operating systems.

The first step you’ll need to take is to ensure that your UEFI boot is enabled on your device. You can follow this article:

Enable Secure Boot on your device

To verify you have Secure Boot enabled you can:

image

Run the system configuration utility (Start | MSINFO) which should show you something like:

image

Here you should find both the BIOS mode set to UEFI and the Secure Boot State set to ON.

image

You can also run the PowerShell command:

confirm-securebootuefi

as an administrator as shown above, which should return as True.

image

 Finally, you can also open Windows Defender on your device, select Device Security and under the Secure boot option, shown above, you should see Secure boot is ON.

Windows 10 startup process

The above, from the Secure the Windows 10 boot process gives you a good idea of how the boot sequence proceeds. To again quote the article:

Trusted Boot

Trusted Boot takes over where Secure Boot leaves off. The bootloader verifies the digital signature of the Windows 10 kernel before loading it. The Windows 10 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM. If a file has been modified, the bootloader detects the problem and refuses to load the corrupted component. Often, Windows 10 can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.

Measured Boot

Working with the TPM and non-Microsoft software, Measured Boot in Windows 10 allows a trusted server on the network to verify the integrity of the Windows startup process. Measured Boot uses the following process:


    1. The PC’s UEFI firmware stores in the TPM a hash of the firmware, bootloader, boot drivers, and everything that will be loaded before the anti-malware app.
     2. At the end of the startup process, Windows starts the non-Microsoft remote attestation client. The trusted attestation server sends the client a unique key.
     3. The TPM uses the unique key to digitally sign the log recorded by the UEFI.
     4. The client sends the log to the server, possibly with other security information.


Depending on the implementation and configuration, the server can now determine whether the client is healthy and grant the client access to either a limited quarantine network or to the full network.

Windows 10 includes the application programming interfaces to support Measured Boot, but you’ll need non-Microsoft tools to implement a remote attestation client and trusted attestation server to take advantage of it.

Now that the boot process is complete and secure, thanks to Secure Boot, we can move onto the next phase in protection with Windows 10 Guards,

Next – Virtualization Based Security

Secwerks–The bug

Registrations still open:

CIAOPS Secwerks

A virtual 16 hour level 400+ event focused on teaching the security best practices for Microsoft 365.

This remote classroom style learning event will be conducted over four half day sessions and cover topics such as Email security, Device configurations, Windows 10 Security features and more.

If you manage an Office 365 or Microsoft 365 environment, this event is for you.

Testing for the PrintNightmare vulnerability

Taking inspiration from:

https://github.com/gentilkiwi/mimikatz/tree/master/mimispool#readme

I’ve updated my own security testing script here:

https://github.com/directorcia/Office365/blob/master/sec-test.ps1

to check for the PrintNightmare vulnerability.

The video

https://www.youtube.com/watch?v=LvmRlc40WWI

gives you a walk through of the process when you run my security testing script and results on a vulnerable system.


Basics of deploying Windows Defender Application Control (WDAC) using Intune

Windows Defender Application Control (WDAC) is the more modern approach to application white listing on a windows 10 device when compared to AppLocker. It is however, just as easy to deploy using Intune as this video shows:

https://www.youtube.com/watch?v=M2cZrV-mRlo

You firstly need to create your WDAC policy as an XML file. Then you use the PowerShell command:

ConvertFrom-CIPolicy

to ‘compile’ it into a .bin file. You upload this .bin file into an Intune device configuration policy and apply that to all the desired machine.

Remember, unlike AppLocker, WDAC applies to the whole machine, not individual users of that machine.

Remember, WDAC is already part of Windows 10 so there is no additional cost and using Intune, it will work with both Windows 10 Enterprise and Professional to help you secure your environment.