How to configure Windows 10 and Windows 11 Security in 2023?

In the previous Article, you learned about the risks and impact of personally owned devices on information security and the practical steps you can take to ensure the appropriate protection is applied. In this Article, we'll look at the new security options available with Windows 10 and how they can be combined with existing security to enhance protection. We will explore their benefits and their hardware and software requirements and point you to caveats when implementing some of them.
We will cover the following topics in this Article:

• Windows Hello and Windows Hello for Business
• Virtual-based security
• Credential Guard
• Device Guard
• Windows Defender Application Guard (WDAG) for Microsoft Edge
• Windows Defender Exploit Guard
• Device Health Attestation
• New BitLocker options
• Local Administrator Password Solution

Today's security challenges

Welcome to computer viruses, Trojan horse, rootkits, Backdoors, worms, ransomware, scareware, rogue security software, scamware, crapware, malware, adware, spyware, riskware, grayware, unwanted software, and many, many other threats.
And they are getting more and more sophisticated. Scared? The cyber-security landscape has changed a lot in the past years. Have you also adapted to it? You can speak of a revolution of cyber threats.
Cybercrime has moved on to cyber-espionage, cyber-warfare, and cyberterror. Where former attackers focused on Fortune 500 companies, you see attackers now go after any target, all verticals, all supply chains, subcontractors, small businesses, and line-level individuals. Malware and vulnerabilities have moved on to credential theft at a large scale and advanced persistent threats. You need to combat this revolution, and it is a very challenging task.
The following figure shows the evolution of attacks:

In the past, attacks were frequently run by what we call script kiddies, who were mostly unskilled individuals using scripts and programs developed by others. Their attacks were unsophisticated and mostly motivated by mischief or fame. The most impact was made by Blaster and Slammer in this time.
Since 2005, organized crime came more and more into the game. Their attacks were more sophisticated and differentiated. New threats such as ransomware, click fraud, and identity theft became commonplace. They are motivated by monetizing cybercrime. Since 2010, we've seen an upcoming trend of CryptoLockers. The organized crime scene even provides 24/7 hotlines if you become a victim of such CryptoLockers and you have problems entering the paid unlock key.
Since 2012, we speak of now in terms of cyber threats. We know nation states, terror groups, and activists are also a threat. They use very sophisticated and well-sourced attacks. They have different motives such as IP theft, damage, disruption, and revenge. In the past, it took several days to weeks from planning to exploit. Today, it takes only hours or days, and we speak of zero-day exploits.
We need a new approach to addressing threats. The economic model of attacks needs to be ruined. No more scaling and large attack styles. We need to break the attack playbooks. Each attack needs to be unique and time consuming again. And we need to eliminate all actual vectors of attack. To this effect, four main pillars for threat protection have been named:

• Device protection
• Threat resistance
• Identity protection
• Information protection

When observing typical attack timelines, the average time between first host compromise and domain admin compromise is only 24-48 hours. But it takes between 11-14 months to detect the attack. So we need to redefine the defense stack in pre-breach and post-breach environments and assume a breach at some point. So there is a fifth pillar called breach detection, investigation, and response.

Device protection is aimed at improving your hardware protection. Hackers could easily drop malware such as a rootkit onto your device and compromise your device before the OS is started. You can compare such a rootkit with a hypervisor, and if it is well written, the OS will not be able to detect it at all. Well-known things such as Trusted Platform Module (TPM), Unified Extensible Firmware Interface (UEFI), secure boot, and Early Launch Antimalware (ELAM) functionality can help protect your device integrity and protect your OS before it starts. New security has been added to Windows 10 with virtualization-based security containers and new biometric sensors for two-factor authentication.
Threat resistance is aimed at hardening your OS against viruses, Trojans, and other malware. Well-known things such as the SmartScreen reputation filter, client firewall, and Windows Defender anti-malware can hardly keep up with around 390,000 new malware programs that are created each day.
New security was introduced in Windows 10 with Device Guard, a tamperproof advanced AppLocker, WDAG, and secure OS containers for applications such as Edge, and Edge has been hardened further by limiting its access to certain dynamic-link libraries (DLL) APIs and removing outdated and security-critical technology.
Identity protection is aimed at getting rid of passwords and protecting secondary credentials with the new security of Windows Hello and Credential Guard. This defends against Pass-the-Hash (PtH) attacks with the help of a secure OS container using VBScript. Together with Windows Hello and next-generation credential services, the attack surface is further limited and sensitive information is protected.
Information protection is aimed at protecting information as long it resides in the device to protect against loss or theft and to protect data when transferring between devices. Well-known solutions such as BitLocker and BitLocker to Go are combined with new Windows 10 security with the new BitLocker Algorithm XTS and Windows Information Protection a.k.a. Enterprise Data Protection, and a good combination of Encrypted File System (EFS) and Rights Management System (RMS) with easy boundary definition and B2B support in a transparent container for all sensitive data.
In the modern world of cyber threats, we must assume the potential for a breach. So breach detection, investigation and response is aimed at detecting these breaches faster and starting countermeasures as soon as possible. With improved Windows 10 security with more granular conditional access, new Device Health Attestation (DHA), and Windows Defender Advanced Threat Protection (ATP) on the client side, this post-breach protection should be enhanced. On the server side, the addition of Microsoft Advanced Threat Analytics (ATA) will help us detect suspicious behavior. ATP and ATA will be covered in another chapter.
Let's have a look at the new Windows 10 security features.

Windows Hello/Windows Hello for Business

According to Microsoft's newest security report, the password length recommendation has been raised to a minimum of 12 characters. But strong passwords can be difficult to remember, and forcing users to frequently change their passwords will often lead to yellow sticky note problems. Also, users often reuse passwords. Passwords are sometimes shared among individuals. Server breaches can expose passwords, especially if they are stored in plain-text or hashed without a salt. Also, users can unintentionally expose their passwords due to phishing attacks.
So passwords are no longer sufficient because they are frequently weak, the same password is used in too many locations, and due to increased cloud calculation power they can easily be cracked by brute force attack or rainbow tables if too short. They can easily be stolen, breached, or phished.
Additionally, PtH attacks are now a very real threat. PtH was discovered in 1997 when the Server Message Block (SMB) client accepted NTLM password hashes. It was weaponized in 2008 by Hernan Ochoa from Amplia Security.
The hash changes only when the password is changed. Additionally, there is a relationship between the password and hash. If the password is too short, it can easily be brute-forced or calculated. Even worse is the use of the smart card-only feature because the hash will only change when you toggle this feature or when you change your smart card. Also, a stolen password can be used on multiple computers, and in most cases, you will not even notice that someone else is using your credentials.
We need to move to a more secure, password-free experience. And Windows Hello is capable of providing one. Microsoft is a board member of Fast IDentity Online (for more information visit https://www.fidonet.com/index.php) and uses standardized hardware and software described in FIDO 2.0.
When using Windows Hello, your credentials (consumer mode) or your asymmetric private key (business mode) are stored inside your TPM. Your PIN or biometric factor is used to unlock your TPM.

To be able to use biometric sensors, you need to first define a PIN. Don't be baffled by the word PIN. It is not a numerical-only password; it can be also alphanumeric with special characters. The complexity of the PIN can be managed by Group Policy Object (GPO) or Mobile device management (MDM). And where with a normal password you are only capable of setting the complexity, here you can define each of lowercase, uppercase, digits, and special characters with not allowed, allowed, and required, giving you a more granular control over the PINs.

The PIN is defined per device and does not roam. So even a six character long PIN could be more safe than a 12 character long traditional password, as the PIN can only be used on the device owning it, whereas a password, once compromised, can be used in most cases on every device in the domain.
Windows Hello currently supports three types of biometric sensors: fingerprint, face, and iris. More login types such as biometric rings and blood vessel scan are currently being evaluated and will be added with future releases of Windows 10.
Don't worry; the scan of your fingerprint generates a template, which cannot be transformed back to a fingerprint. These templates are only stored locally. So even if an attacker compromises your system, he or she will not be able to get your fingerprint scan. Windows 10 is not the world's largest fingerprint collector!
The biometric data used to support Windows Hello is stored on the local device only. It doesn’t roam and is never sent to external devices or servers. The use of TPM is strongly recommended. While using TPM is more secure and robust, Windows also contains an alternate software-based mechanism that will be used when no TPM is available. The use of Windows Hello on machines without TPM can be prevented by GPO (set Use a hardware security device to Enabled).

Fingerprint-capable devices need to meet the biometric requirements (biometric requirements: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-biometric-requirements) for false and true acceptance rate, implement anti-spoofing techniques, and provide a Windows Biometric Framework (WBF) driver for being allowed as Windows Hello fingerprint devices. But even if there are detailed requirements, the quality of anti-spoofing and liveness detection can vary among different models. You should look at fingerprint devices with capacitive, thermal, or ultrasound liveness detection if you want to ensure more security. But these sensors are more expensive. Also, large-area sensor models are usually safer than swipe models. There is no GPO possibility to limit to certain fingerprint models, so you should disable unwanted models directly inside the BIOS/UEFI firmware of your devices.
For face and iris scans, all devices must also meet the strict Microsoft sensor specifications (infrared sensors, IR illuminators, resolution, and so on). But why does Windows Hello use infrared instead of normal color images? Because IR can handle low-light and side-light situations more robustly, it is generally more immune to makeup and facial hair. Additionally, it helps with spoofing because it doesn't allow photos or LCD displays.
If your biometric device does not meet the biometric requirements and therefore has no WBF-certified driver, it will not be offered as a biometric sensor in the Windows Hello system control. But you will still be able to use a PIN with Windows Hello. If you enforce the use of biometrics by GPO, it will only apply to certified sensors.
If your biometric data is not recognized any longer by your device (such as due to a finger injury, using wet fingers with capacitive sensor models, or by wearing new glasses) you will still be able to use your PIN as a backup. If you are wearing glasses, you should register multiple times with the face recognition system with and without glasses to get the best user experience.

Differences between Windows Hello and Windows Hello for Business

Windows Hello is targeted toward individuals/consumer devices. PIN or biometric verification is used on your personal device to reduce the risk of keyloggers or password phishing, but the login process still uses your password hash. As you are normally not joined to a domain and your hash cannot harm other devices, this is a reduced risk.
Windows Hello for Business can be configured by GPO or MDM and uses a PIN backed by asymmetric (public/private key) or certificate-based authentication. By eliminating the use of hashes, the security is considerably increased. To use this asymmetric key mode, you need to use Azure AD or implement a Windows Server 2016 domain controller. With the use of Windows Server 2016, you can enable the Next Generation Credential mode and eliminate the relationship between password and hash. With this mode, the hash can be more random and changed more often.

Besides the already shown PIN complexity GPO, you can also enforce enrollment to Windows Hello for Business, use of TPM security device, use of certificate on-premises authentication, enrollment to biometrics, and (if connected to Azure AD Premium) the use of phone sign in as a second factor.

To protect your credentials inside your system memory, we will need Virtualization-based security (VBS) and Credential Guard, which will be described next.

Virtualization-based security

VBS, a.k.a. Isolated User Mode (IUM) provides a new trust boundary for system software. VBS is included with the Enterprise (including LTSB), Education, and IoT Enterprise editions of Windows 10. It leverages platform virtualization to enhance platform security by limiting access to high-value security assets, even from supervisor mode code (CPL). VBS provides a secure execution environment and protects several Windows 10 services such as LSA credential isolation and Kernel Mode Code Integrity (KMCI). On the server OS, it additionally provides a virtual TPM (vTPM).
VBS uses the hypervisor to protect a mini kernel and other important parts/services of the OS by enforcing read, write, and execute permissions across system memory.
By separating these services, it enhances the OS protection against kernelmode attacks and other attacks. Even if malware gains access to the kernel, effects are limited because the hypervisor prevents the malware from executing code.
The new security features--Credential Guard, Device Guard, and Application Guard--use this VBS mode. So to use any of these three security features, you need to activate VBS first. Here is a high-level schema of Windows 10 with VBS activated:

Even if malware gains access to the Windows kernel, critical isolated services inside the VBS-secured OS stay safe. The attack surface with VBS is further limited by having only a minimal set of functionality, no driver support, and many security features, such as Code Integrity and Control Flow Guard (CFG).
To be able to use VBS, you have to use x64 architecture (for Hyper-V support) and your hardware needs to have some features available and activated.
The most up-to-date requirements for VBS can always be found at https://docs.microsoft.com/en-US/windows-hardware/design/minimum/device-guard-and-credential-guard. As you can see, new hardware requirements are added with each iteration of Windows 10 to secure against all possibilities. The following are needed at minimum to enable VBS:

• 64 bit CPU
• 64 bit OS
• UEFI 2.3.1c or higher firmware
• No Legacy/BIOS mode activated
• Secure Boot activated
• Hyper-V hypervisor feature activated
• Virtualization support:
• Virtualization extensions (Intel VT-x or AMD-V)
• Second Level Address Translation (SLAT) (Intel EPT or AMD RVI)
• Input Output Memory Management Unit (IOMMU) (Intel VT-d or AMD Vi)
• TPM 1.2 or (recommended) 2.0

As you can see, Secure Boot activation is mandatory. Secure boot itself needs UEFI mode. All hardware with a Windows 8 or Windows modern hardware logo needs to support UEFI 2.3.1 and Secure Boot. So you should look for this logo or ask your hardware vendor for compatibility. All systems meeting these requirements should be installed in UEFI mode or converted with the MBR2GPT tool from legacy to UEFI mode to substantially increase security. If all requirements are met, you can activate the VBS feature.

In Windows 10 version 1511, VBS needs to be activated by installing the Hyper-V Hypervisor and the Isolated User Mode features on demand. Since Windows 10 version 1607, the Isolated User Mode feature is no longer present, and VBS is automatically activated as soon as the Hyper-V Hypervisor feature is installed and hardware prerequisites are fulfilled. As long as you only install Hyper-V Hypervisor and not Hyper-V Services, the user is not able to do harm to your environment by creating extra VMs or virtual switches. The feature can be installed by GUI, PowerShell, DISM, or an Unattend.xml file when deploying the image. A restart is needed after adding the feature.
VBS contains several security mechanisms to protect itself against any known attack. These security mechanisms, such as the absence of device driver support inside VBS and enforced Code Integrity will be described in more detail in the Credential Guard and Device Guard sections.

Credential Guard

As already described in the Windows Hello section, the PtH vulnerability has become a very common threat. Hacker tools such as Mimikatz can dump the system memory and debug your LSASS.exe, containing all the currently active credentials, including hashes. When PtH was weaponized, Windows 7 was already mainstream, and the design of Windows 8.0 was also completed. They could not react/redesign their kernel to prevent this memory dump. Every service was able to dump your Local Security Authority Subsystem (LSASS). With Windows 8.1, a new protected process level (PPL) was introduced. When RunAsPPL was activated, the LSASS process would run with a higher protection level (system level) and therefore no longer be accessible by illegal/corrupt services. But Mimikatz evolved and found a weak spot with device drivers. Even when running in the PPL, LSASS could be accessed by corrupted device drivers. A more disruptive security element was needed. Since Windows 8.0, the client OS is also capable of the HyperV feature. Hyper-V protects the memory contents of its guests. The idea of a second virtual OS, Virtualization-based security, was born.
To better protect VBS against known attack vectors such as using corrupt device drivers, the VBS OS does not support device drivers at all. The binaries inside the VBS are protected by Code Integrity (signed binaries) and CFG (a table of all possible states of a executable). So even in the unlikely event that malware is capable of entering VBS, the malware/infected binaries are identified by Code Integrity and will not be executed. And even if they should be capable of fooling the Code Integrity, the different jump behavior of executables will be detected by the control flow guard and the executable will be terminated.

Credential Guard uses VBS to isolate Windows authentication from the Windows operating system. In the VBS protected system, the high-level OS and the VBS OS communicate with remote procedure calls (RPCs). When activating Credential Guard, you will see in addition to the well-known LSASS a new process called LSAISO. This LSAISO is not the LSAISO running inside VBS, but an additional LSAISO running inside the high-level OS to help the communication of LSASS between the two environments.
The high-level-OS LSASS only contains a reference GUID for the credential. Only the VBS LSASS contains the hash.
Malware could try to get the GUID, but the LSASS/LSAISO processes will only communicate with its counterparts, so the GUID could be known to the malware without it doing any harm.
Unfortunately, Credential Guard is referenced inside the GPO and inside Msinfo32 also as Device Guard. To activate Credential Guard on your system, your system needs to be capable of running the VBS OS, and the VBS feature needs to be active/running.
To check your hardware for compatibility, you can use the Device Guard and Credential Guard hardware readiness tool (for more information visit https://www.microsoft.com/en-us/download/details.aspx?id=53337). Credential Guard can be controlled by GPO or MDM. You will find the related GPO in the machine GPO section under System | Device Guard.

Select the Turn On Virtualization Based Security entry and configure it to Enabled. For platform security level, select Secure Boot at minimum, or better, select Secure Boot and DMA Protection.
Next, you need to configure the Credential Guard configuration to Enabled without lock or Enabled with UEFI lock. A reboot is required after the policy is applied to activate Credential Guard:

To check whether VBS and Credential Guard are up and running, you can check your task manager. If you see a process called LsaIso.exe, it indicates Credential Guard is running:

Alternatively, you could use MSINFO32.exe and look at the system summary entries for Device Guard: Virtualization-based security should be Running, and Virtualization-based security Services Running should be set to Credential Guard:

If Credential Guard cannot be activated on your device, check compatibility with Device Guard and Credential Guard hardware readiness tool or event viewer for an error event ID.
In addition to the Credential Guard configuration, there is the Virtualizationbased protection of Code Integrity, a.k.a. Device Guard, which will be covered next.

Device Guard

You can run your system in two ways. One is trusting everything until there is evidence it is malicious. The evidence needs to be provided by, for example, your antivirus solution. This is a method of the past that could hardly keep up with the over 390,000 daily newly generated malware. The other is you trust only known software/executables/scripts.
But have you ever tried to whitelist all executables of your image with software restriction policies or AppLocker? First you need to inventory all executables and then create a policy based on a digital certificate, hash, or path. There are a huge number of executables. And not all are digitally signed. So you need to fall back to filenames and hashes. But what if you use an application that creates unsigned randomly named executables in your temporary folder during runtime? You have to punch a huge security hole into your AppLocker rules by allowing a generic path for execution.
Besides the executables, you need to whitelist all DLLs. Not only are there so many DLL files that they make inventory and rule creation more complex, you will also notice a possible performance degradation of your system when checking all your DLLs with AppLocker.
And what about scripts? Most of your scripts are not signed, and it is common to create and execute scripts during the runtime of executables. Again, you have to punch huge holes into your AppLocker security by allowing paths or generic names without signatures.
Also, AppLocker can be tampered with by an administrator or malware so that it doesn't restart after reboot. A more restrictive, tamper-proof, but easyto-manage solution is needed. Welcome to Code Integrity, a.k.a. Device Guard.
Code Integrity was already introduced with Windows Vista. In the desktop version of Windows 8.0, it was called KMCI. It enforced digital signatures, integrity of Windows kernel binaries, Windows first-party drivers, and x64 driver signatures. In the mobile and Windows RT versions, Code Integrity was additionally extended to user mode code integrity (UMCI) and enforced digital signature and integrity of all executables. This was one reason why mobile and RT were only able to run correctly signed apps from the Windows Store. So we already have practical knowledge of implementing such CI.
But why was it not sufficient? The version used in Windows 8.x had one major drawback: it was running inside the same kernel space of the highlevel OS and could be tampered with by malware. And the UMCI required an enterprise-friendly possibility to sign LOB and Win32 apps.

In Windows 10, the KMCI and UMCI components moved inside the secure VBS container. Additionally, Code Integrity is now configurable, so in KMCI mode too, third-party drivers can be allowed/integrated into the KMCI policy. And in UMCI, all executables, both classic Win32 apps and modern UI (appx) apps, can be integrated into a Code Integrity policy or a trusted and signed catalog file. The Code Integrity policy is burned into hardware, that is, stored into tamper-proof TPM. So even if you boot from a Windows Preinstallation Environment (Win PE) DVD or reinstall your OS, the policy stays intact and protects your OS.

Device Guard Code Integrity uses digital signatures if possible. If there is no digital signature, it can fallback to file hashes. The more file hashes you have, the more likely you will break your system/Code Integrity policy with the next app update. So you should try to keep the use of hashes to a minimum to avoid unnecessary problems after patching.
Device Guard is used to white-list all your executables, DLLs, and scripts. On top of Device Guard, you can use AppLocker for additional blacklisting.

During the boot-up of Windows and loading of the kernel, not all components of Device Guard are available, so the usage of signed catalog files is only possible for UMCI. To create such a blueprint of your image, that is, Code Integrity policy, you need to perform the following steps:
1. Prepare your golden system, which will be used for the collection of the enforcement policy.
2. Enable VBS and Device Guard on the system. Set Device Guard to Audit Mode.
3. Collect all file information with PowerShell cmdlets to create a policy.
4. Repeat steps 1-3 for all different hardware models/base image configurations. Merge multiple policies or deploy differentiated policies. Keep in mind that there can only be one active Device Guard policy at one same time on the same system.
5. Convert the policy to binary format and sign it.
6. Deploy your policy in audit mode to the target system and test.
7. Use Windows PowerShell cmdlets to create a policy from the audit log and merge.
8. Enable enforcement of the policy and test.
To enable Device Guard on a system, VBS needs to be activated first. After that, you can enable Device Guard with the following GPO:

After the successful creation of such a Code Integrity policy, it can be enforced either through GPO or MDM. A Code Integrity policy once applied to a system can only replaced by another Code Integrity policy with the same signing cert. Be careful with using very short-lived certs as the policy needs to be replaced before the cert is outdated. The Code Integrity policy needs to be on a UNC path or a locally valid path. UNC is preferred, as a local path needs an extra copy job:

For creating, signing, and testing, the following Device Guard PowerShell cmdlets are available in Windows 10:

As an alternative, you can create a catalog file for applications. This can only be used for applications/UMCI components, as during bootup of the system, when drivers and system components are checked, the suitable program parts of Device Guard are not yet ready to scan catalog files, and so only Device Guard policies work for these KMCI components. To create a signed catalog file of an application, you need to perform the following steps:
1. Prepare your catalog system, which will be used for the collection of all new file added information of the catalog file.
2. Enable VBS and Device Guard on the system. Set Device Guard to Audit Mode.
3. Run PackageInspector.exe start C: for an initial scan of the system.
4. Install the application(s).
5. Stop information collection with PackageInspector.exe stop c: -name \Catalog.cat -cdfpath \Catalog.cdf (You can change the names of the .cat and .cdf files).
6. Sign the catalog file with SignTool.exe.
7. Copy the signed catalog file to target system at C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
8. After successful testing, deploy the catalog file to all your systems in this folder.
There is no official limit of catalog files documented, but you should try to keep it low/clean up unnecessary catalog files.
The third option is to automatically add applications installed by your managed installer to the Device Guard Code Integrity. This option was added with Windows 10 1703. A managed installer uses a rule to trust one or more executables as an authorized source for application deployment. By specifying an executable as a managed installer, all files written from that executable's process will be tagged by Windows as having originated from a trusted installation authority. At the time of writing this book, there is no GUI dialog to define a managed installer, and it has several known limitations. All necessary steps, including the manual modification of XML files, are documented at https://docs.microsoft.com/en-us/windows/device-security/device-guard/deploy-managed-installer-for-device-guard.
In a future version of Windows 10, a fourth method of adding applications with scripts to the gold standard will be added. Keep an eye on the Windows Insider Preview builds to get first-hand information as soon as it is available.
Besides the enforcement of Code Integrity, there are also other enforcements introduced by Device Guard. On the kernel memory and driver side, the following enforcements are made:

• Code Integrity rules are still enforced even if a vulnerability allows unauthorized kernel mode access, because it runs in a secure VBS space
• Memory pages are only marked executable if they are successfully validated by Code Integrity
• Device Guard KMCI-protection-activated kernel memory cannot be marked both writable and executable to reduce the risk of selfmodifying malicious code that is hard to detect
• Unfortunately, not all drivers will be currently compatible and they can no longer write and execute kernel memory, so updated Device Guard compatible drivers are needed

To test all your existing drivers before enforcing Device Guard on these systems, you can use the Device Guard and Credential Guard hardware readiness tool. The tool can be found at https://www.microsoft.com/en-us/download/details.aspx?id=53337.
Additionally, there are enforcements in script handling with Device Guard activated:

• Windows Script Host will require signed scripts: all VBScript (.vbs and .vbe), JScript (.js), Windows Script File (.wsf), and Windows Script Components (.wsc) files need to be signed or they will not execute.
• All MSIs must be signed or they will not execute.
• Unsigned PowerShell scripts will be in Constrained Language mode, which will block several dangerous commands/cmdlets. To use the full potential of PowerShell, the script needs to be signed to run in Full Language mode.
• Other scripts such as .bat and .cmd are currently not restricted.

Besides these limitations and enforcements, where is Device Guard applicable? We need to distinguish four different use cases, from tightly managed up to Bring Your Own Device (BYOD).
Fixed workload:

• Very well-defined software and hardware configuration
• Tightly managed
• Low churn rate
• Ideally no user or standard users only

In the fixed-workload scenario (such as kiosk-mode PCs and production-line PCs), you can activate all the necessary parts of the security chain with Secure Boot, VBS, and Device Guard, and you can run KMCI protected by VBS and UMCI in enforced mode.
Fully managed:

• Well-defined hardware configuration
• Managed software only
• Tightly managed
• Ideally standard users only

In a fully managed scenario (should be the typical office workplace PC without an admin user), you can again activate all required parts of the security chain with Secure Boot, VBS, and Device Guard, and you can run KMCI protected by VBS and UMCI in enforced mode. If a user has admin rights, he or she cannot install his or her own software as it will be blocked by Device Guard.
Lightly managed:

• Multiple and varied hardware configurations
• User can install unmanaged software
• Standard or admin users

In the lightly managed scenario (which is still found far too often), you can only activate some parts of the security chain. Secure Boot and VBS should be available without problems. But KMCI with VBS protection needs to be checked. UMCI can only be activated in audit mode, and logs need to be inspected regularly. Due to high false-positive hits for unmanaged software, the logs are hard to read/interpret.
BYOD:

• Personally owned devices
• Highly variable hardware and software

In the BYOD scenario, no parts of the security chain, such as Secure Boot, VBS, or Device Guard, even in audit mode, can be activated.
With the current implementation of Device Guard, you can run it only in fixed workload and fully managed scenarios. Even then, you are not capable of activating it on all clients, and you should activate it on as many scenarios as possible to raise the security bar and improve your knowledge of Device Guard.
With future implementations of Device Guard, the lightly managed scenario will be able to be protected without too much overhead. Also, scan times of Code Integrity policy creation and catalog file creation will be improved and new security features will be added soon.
A violation of KMCI will result in a blue screen. If you see the following blue screen repeatedly, check your Code Integrity policy and scan for malware:

Windows Defender Application Guard for Microsoft Edge

With Redstone 3/Windows 10 1709, a new security feature with the cumbersome name WDAG for Microsoft Edge was introduced. Even though it has an unwieldy name, its functionality can be explained easily. The concept of VBS is extended to software containers. So it will execute exposed software such as your browser in an extra virtual OS and connect only by Remote Desktop Protocol (RDP). The first program capable of this was Microsoft Edge, but other products will follow with the next versions of Windows 10. If a Microsoft Edge instance running in such a secure container gets hacked, it does not have access to the host OS. When Microsoft Edge is displaying a intranet or trustworthy site, it will be executed in the host OS. When surfing on other sites, a new instance in the Windows OS will be executed and connected by RDP.

To get this security feature activated, you need Hyper-V and VBS running, so you will need the 64 bit OS and CPU virtualization extensions. For Hyper-V guests, you need to activate the Hyper-V nesting feature. As it will add a third OS to your memory, the absolute minimum RAM should be 4 GB. 8 GB or more is recommended. This security feature also needs an Enterprise SKU. When VBS is up and running, you can add the Windows Defender Application Guard feature, which can be found in Insider Preview builds since 16251 and in retail Windows 10 version 1709. It is also possible to control this feature with the GPO Turn On/Off Windows Defender Application Guard (WDAG). The feature needs a restart to activate.

In standalone mode (when no network isolation GPO is applied) the user can open a protected Edge instance with the context menu.

Organizations can control various aspects of WDAG. To define trusted sites for WDAG, they need the Enterprise resource domains hosted in the cloud GPO. This GPO can be found under Computer Configuration | Administrative Templates | Network | Network Isolation. To add, for example, all PacktPub and Microsoft sites to your trusted sites list, you need to enable this GPO and add the following line to Enterprise's cloud resources: .packtpub.com|.microsoft.com.
All entries need to start with . and multiple entries need to be separated with the pipe character (|). Placeholder characters like * or ? are not allowed. If a resource needs a proxy address to access, you need to pair the domain using a trailing comma followed by the proxy address.
WDAG-specific GPOs can be found under Computer Configuration | Administrative Templates | Windows Components | Windows Defender Application Guard after importing the 1709 GPO templates (in fact, they've already partially existed since 1703 but weren't functional in the release version).
The Configure Windows Defender Application Guard clipboard settings GPO controls clipboard operations. By default, clipboard operations from and to WDAG Edge are blocked completely. You can enable copying from WDAG to host and/or vice versa. Clipboard content can be limited to text only, images only, or text and images. Enabling the clipboard lowers security.
The Configure Windows Defender Application Guard Print Settings GPO controls printing capabilities. By default, all print functionality is turned off in Application Guard. You can enable printing and limit it to XPS, PDF, local only, network only, and a lot of combinations of these four options or enable all printing. Enabling print functionalities lowers security.
The Allow data persistence for Windows Defender Application Guard GPO controls whether user data such as cookies and favorites as well as downloaded files will persist inside the Application Guard silo. By default, WDAG deletes all user data within the Application Guard container after the instance is stopped. When the GPO is enabled, you can still delete the content using the Reset-ApplicationGuard PowerShell command.
If you just need the Edge log files of an Application Guard container, there is the Allow auditing events in Windows Defender Application Guard GPO. By default, audit event logs aren't collected for WDAG. When you enable this setting, auditing events will be logged in host events.
On the first start of WDAG after start/reboot, you will see a short splash telling you when WDAG gets started. At the time of writing this book, depending on RAM, HDD, and CPU, this can take from 10-20 seconds up to 1-2 minutes on very old or limited systems.

Additionally, the user gets a (disengageable) information box informing him or her about the WDAG mode with a link to more information.

The Edge icon shows a shield symbol when running in WDAG mode.
With the disengaged information box, the user will only see an orange Application Guard notice in the upper left corner. Here is a comparison between the normal trusted site mode and Application Guard mode:

Task Manager will not show protected Edge instances but the WDAG RDP client instead:

With the current implementation of WDAG, there is no easy way to check the memory consumption of the applications running inside the Application Guard container. Currently, Microsoft Edge is the first product supporting the new WDAG mode. More Microsoft products will follow. The third-party Virtualization-based security solution Bromium can run side by side with WDAG.

Windows Defender Exploit Guard

Since a long time ago, you could enable extra security on your OS using the free Enhanced Mitigation Experience Toolkit (EMET). Development of EMET was stopped last year, and support for it will end in July 2018. Also, the latest version of EMET 5.5.2 is no longer supported on Windows 10 1709 and will be uninstalled with an in-place upgrade, and installation of EMET will be actively blocked.
But no worries; all the functionality of EMET and even more features are now built in to Windows 10 1709. This new security feature is named Windows Defender Exploit Guard and is located inside the Windows Defender Security Center under App & browser control | Exploit protection:

By accessing the Exploit protection settings, you can control system-wide settings and program-specific overrides. Be carefully with system-wide settings. Per-program settings are made by a scheme enforcing the feature in the name of the app. As App-V schemes and EMET/Exploit Guard schemes cannot be nested, Exploit Guard settings will not be enforced on App-V apps.

System-wide settings contain the (already known from EMET) Data Execution Prevention (DEP) setting, which prevents code execution from data-only memory pages; Address Space Layout Randomization (ASLR), now called (Mandatory ASLR), which forces relocation of images (DLLs); and Structured Exception Handling Overwrite Protection (SEHOP), which ensures the integrity of the exception handler before executing it, validating heap integrity for heap spray and heap corruption.
Additionally, you can now enforce CFG which ensures integrity of all indirect calls, and Bottom-up ASLR, which will randomize all locations for virtual memory allocations.
Program settings can be defined by the program name or exact file path. Per program, you can override every system-wide setting and define more settings. And as a huge improvement over EMET, you can activate an audit on every setting. Where EMET was more like a trial-and-error way of configuration (activate all settings and then deactivate settings one by one until the app works), the new audit helps in effectively finding incompatible settings very quickly.

Per program settings of Exploit Guard include Arbitrary Code Guard (ACG), which prevents code page modification; Block low integrity images, which prevents loading of images marked with low integrity; Block remote images, which prevents loading of images from remote devices; Block untrusted fonts, which prevents loading any GDI-based fonts not installed in the system fonts directory; Code integrity guard, which only allows the loading of images signed by Microsoft; Disable extension points to disable various extensible mechanisms that allow DLL injection into all processes such as window hooks; Disable Win32k system call to stop programs from using any Win32k system call; Do not allow child processes to prevent programs from creating child processes; Export address filtering (EAF) to detect dangerous exported functions being resolved by malicious code; Import address filtering (IAF), which does the same as EAF but for imported functions; Simulate execution (SimExec) to ensure that calls to sensitive functions return to legitimate callers; Validate API invocation (CallerCheck), which ensures that sensitive APIs are invoked by legitimate callers; Validate handle usage, which raises an exception on any invalid handle references; Validate image dependency integrity, which enforces code signing for Windows image dependency loading; and Validate stack integrity (StackPivot), which ensures that the stack has not been redirected for sensitive functions.

Each of these functions adds security to your applications at the cost of CPU overhead. As this overhead depends on the code of the app, there are no general numbers on the performance hit for most of the security features. You need to check the performance of each of your apps individually.
Settings can only be changed/removed as an admin user. All settings can be edited in the GUI and exported as XML for configuring by GPO.

Device Health Attestation

Already Windows 8.0 introduced a new possibility of evaluating the health of the boot process called Measured Boot, a recorded variant of the Secure Boot. But the suitable enterprise counter part for checking the health data and enforcing access control was not available at that time.
With Windows 10 1511 the technique was named as Windows Provable PC Health (PPCH) and later on with Windows 1607 and newer renamed to DHA. On Windows Server 2016 the counterpart is named Health Attestation Service (HAS).
But what does DHA exactly? It will combine Secure Boot, VBS, ELAM, and protection of your early-boot drivers and measures them with the help of your TPM 2.0. These measured boot data results are collected by the health attestation configuration service provider (CSP) and sent to a Remote HAS for verification/comparison against current policies:

The health attestation process will check your hardware boot components (for example, PCR values), OS boot components (for example, boot counter) and if Device Guard is enabled, current Device Guard policy. Further on the Windows kernel (for example, signing) will be checked, your ELAM compatible anti-malware will be launched as the first kernel mode driver and measured and last but not least all necessary early boot drivers will be measured.
When your client is requesting access to a protected corporate resource, your client needs a valid health attestation. The health attestation CSP will send the collected data to the pre-provisioned URI. Currently the DHA service is designed to expect a Microsoft cloud service as HAS counterpart (has.spserv.microsoft.com). An on premises only variant is currently investigated and possibly available in a future release of Windows 10. The collected data is signed and contains your TPM log, the Attestation Identity Key (AIK) data (PCR values, boot counter, and so on) and the AIK certificate information.
The remote device health attestation service verifies the certificate and compares the data against its configured values. If everything is within range, a device health token containing the health information together with a valid issuance time will be generated, encrypted, signed, and sent back to client. The client stores the health encrypted blob in its local store.

These steps are done after activation of health attestation and on every boot and redone as soon as the validity date of the health token expired. When accessing a high-value asset in your corporate environment, the client will send its valid health token to the identity provider and a conditional access decision will grant or deny access. When health criteria are not met or token is outdated no access is granted.

On client side you will need Windows 10 installed in UEFI mode with activated Secure Boot and TPM 2.0. With the current implementation of DHA you will need on backend side the HAS Microsoft cloud service, a MDM solution supporting DHA (for example, InTune) and Azure AD standalone or Azure AD with AD connector in hybrid mode.
Use of VBS, Credential Guard and Device Guard for further improving security is recommended.
The activation of health attestation on client side will be done as part of enrollment with the MDM provider. Without configuration health attestation will be disabled by default.

DHA is a consequent improvement over the discontinued Network Access Protection (NAP). It will provide an easy way to increase device security and integrity without boss around your users.

Windows Defender Security Center

The Windows Defender Security Center introduced with 1703 and extended with 1709 will be described together with Windows Defender ATP in next.

New BitLocker options

The Advanced Encryption Standard (AES) hard-disk encryption (BitLocker) used since Windows Vista was AES Cipher Block Chaining (AES-CBC). Vista and Windows 7 provided also AES-CBC with Elephant Diffuser. To support BitLocker hardware encryption with so-called encrypted drives (eDrives), the support for Elephant Diffuser was dropped with Windows 8.0. AES with Diffuser can still be accessed, but new encryption can only be done in AES-CBC 128 or 256 bit.
With the introduction of Windows 10 1511, a new AES standard called AES-XEX based on tweaked-codebook mode with ciphertext stealing (XTS-AES) was implemented. XTS-AES provides additional protection from a class of attacks on encryption that rely on manipulating ciphertext to cause predictable changes in plain text by adding additional permutations. XTS-AES will not be back-ported to older OSes.
By default, Windows 10 1511 and newer will use XTS-AES for the OS drive and fixed data drives. For compatibility reasons, removable drives will use the old AES-CBC method. As soon as all OSes accessing the removable drive are Windows 10 1511 or newer, you can safely switch to XTS-AES for removable drives as well.

To distinguish between AES with Diffuser (Vista/Server 2008 till Windows 7/Server 2008 R2), AES-CBC only (Windows 8/Server 2012 till Windows 10 1507/Server 2012 R2), and new AES-CBC + XTS-AES (Windows 10 1511 and later/Server 2016), there are now 3 different GPOs:

Local Administrator Password Solution

Where do you store the password of the local admin account on every PC in your domain? Options include:

• The account is disabled, only use a domain account/group for local admin rights (what about when the domain isn't available?)
• Use the same password on every machine, set at the time it is built (great way to allow malware to spread across the entire network in seconds!)
• Use a spreadsheet or other centralized notes to record them for other admins to access-but it's okay because it's on a secure network share and password protected (because no one could possibly make a copy or crack the weak security of Excel, right?)

And what do you do when you want to change the password after your system has been compromised, or one of your admins leaves, or a user has discovered the password and is now using it to install software and make unauthorized changes? These are your options:

• Change them one by one: visiting each terminal manually or remotely
• Use PowerShell or another scripting tool (do you keep using the same password for each PC?)
• Group Policy Preferences (this option is not secure and the function has now been disabled)

To resolve this issue, Microsoft provides the Local Administrator Password Solution (LAPS). You can download the package from the Microsoft website: https://www.microsoft.com/en-us/download/confirmation.aspx?id=46899.
Once downloaded, you will see the following new files:

AD preparation

In order to deploy this solution, there are some basic steps that need to be followed; refer to the operations guide for more information about the following:

• AD schema update: Before this solution can be used, the AD schema needs to be extended by two new attributes.
• Administrator permissions: There are several permissions that must be set in order to allow the computers to update AD with their local administrator account details and to prevent unauthorized access to the passwords once they are stored in Active Directory:
• Add machine rights to enable each managed computer to update the new schema attributes
• Remove extended rights from all users to prevent access to the passwords
• Add user rights to enable the appropriate user or group to be able to retrieve the passwords

Now to the installation

When you first install LAPS manually, you will see the following prompts:

Click on Next.

You will need to install the Management Tools on the PC where you will retrieve passwords as well as the AdmPwd GPO Extension if you want the same machine to be managed:

Click on Next.

Click on Install.

Once the installation is complete, the following will be available.

LAPS UI

The main user interface allows the administrator to query AD, based on the computer name, and retrieve the password details.
In the Start menu, you will see the following shortcut icon:

When you launch it, you will be presented with the following screen, which can be used to retrieve passwords for specific computers in your domain, and set the new expiration date/time:

Group Policy client-side extension

This needs to be deployed to each managed computer. This can be managed using a variety of methods, including the software installation feature of Group Policy, SCCM, login script, manual install, and so on.
If you want to script this, you can use this command line to perform a silent install:

msiexec /i <file location>\LAPS.x64.msi /quiet
msiexec /i <file location>\LAPS.x86.msi /quiet

Just change <file location> to a local or network path:

Example: msiexec /i \\server\share\LAPS.x64.msi /quiet

Group Policy configuration options

Now we configure the Group Policy to apply password changes to this PC:

Password settings: The following options are available for configuring the local settings for passwords managed by this solution:

Name of administrator account to manage: This is for when you have changed the name of the default administrator or created a new account:

Password expiration policy: This setting ensures the policy does not conflict with the security policy defined at the domain level:

Enable or disable the policy: This setting allows you to create the policy in a disabled state, and then enable the policy when ready to deploy:

Once you have configured the policy and targeted it to an OU, you can run GPUpdate on the target machine, or wait for the default refresh time.
Test that the passwords have been changed and that you can successfully retrieve the password using the LAPS UI.

Summary

In this article, you learned about the new and improved security capabilities of Windows 10 and how they can protect you in the current cyber-security threat scenario. Raising the security level is an ongoing effort, and future releases of Windows 10 will bring additional security features soon. But even with all these security features, a breach can occur. So it is important to detect such a breach as soon as possible, find its point of origin, and take suitable countermeasures.