Device Guard: The Theory

Welcome to the second of a three-part series on Device Guard!! In part one, Device Guard: The Holy Grail of Endpoint Security?, the key points were:

• Endpoint security in Windows has evolved, but a true enterprise solution has been lacking
• Solely relying on 3rd party vendor solutions and community-centric intelligence for endpoint security puts organizations in a reactive position
• Windows 10 Device Guard equips enterprises to be proactive, with a more modernized defense strategy for endpoint security

Device Guard is no cup of tea, nor for the faint of heart; there are a number of components in its architecture and detailed processes to follow. Learning more about Device Guard is sure to present some new concepts in Windows that are worth taking the time to understand.
In this blog, I’ll describe how Device Guard makes the endpoint resilient to malware attacks and go deeper into Device Guard’s inner-workings. Finally, I'll highlight some of the risks associated with not implementing Device Guard as part of an organization's overall endpoint security strategy using Windows 10.

What Does Device Guard Do and How Does it Work?

Security in Layers
Cyber-attacks commonly occur through applications, browsers, unpatched vulnerabilities, social-engineering, etc. Device Guard does not eliminate the possibility of being targeted for attacks, but it does significantly reduce the attack surfaces favorited by bad actors and malware writers.
What Device Guard does is harden the various attack surfaces by creating a "chain of trust" or "end-to-end security" from the hardware and firmware configuration involved with the boot process, up through the Windows OS kernel and to software running in Windows. The goal is to ensure all components involved are trusted and have not been compromised or tampered with at any time. This is called defense in-depth security: the endpoint is secured in multiple layers rather than focusing on just one layer and ignoring others.
There a number of attack vectors (layers) on an endpoint that can be exploited when not properly secured. Let's take a look at the following table which shows some popular attack vectors frequented by malware:

● Defense strategy is proactive and prevention-first. Includes UEFI + Secure Boot. Only allows authorized and trusted applications to run, blocks all others.
◐ Defense strategy is proactive and prevention-first, but is subject to tampering should the Windows kernel and OS be compromised. Only allows authorized and trusted applications to run, blocks all others.
○ Defense strategy is reactive based on ability to detect threat and remediation-first. Allows unknown malware to run. Not always successful in detecting known malware even if virus definitions and signature databases are current.
Isolation from Windows Kernel
Running in isolation from the Windows kernel is what gives Device Guard an advantage over traditional endpoint security solutions. When Device Guard is not in use, should the Windows kernel become compromised by malware, it will likely go undetected by signature-based security products that have not updated their signature database/definitions, rendering them ineffective. When Device Guard is protecting the endpoint, the malware will also have the impossible task of compromising Device Guard’s core components.
As Device Guard forms the "chain of trust" between the layers i.e. rows in the attack vector table above, there are two components that enforce trustworthiness of the system: Kernel Mode Code Integrity and User Mode Code Integrity.

Kernel Mode Code Integrity (KMCI)
First introduced in Windows Vista, KMCI ensures that code (drivers, operating system files, programs, etc.) running in the Windows kernel has been signed and trusted. This ensures the Windows kernel has not been compromised prior to the Windows operating system loading.
User Mode Code Integrity (UMCI)
New to Windows 10, UMCI ensures that all subsequent code (software applications running once the Windows operating system is loaded) is trusted.

Runs Inside Secure Hyper-Visor Container
What's new to KMCI is that it runs inside of a Windows hypervisor (Hyper-V) container called Virtual Secure Mode (VSM). VSM creates a security boundary to protect sensitive data such as credentials, password hashes, cryptographic keys, and signatures to identify company defined authorized software, etc. Only KMCI can access VSM when providing code validation and policy enforcement. The secure boundary VSM forms is impenetrable and can only be managed by the hypervisor where it is constantly checked for unsolicited attempts to modify it. VSM’s protection of sensitive data is what makes Device Guard a game-changer in Windows endpoint security!

Windows 10: Disrupting the Revolution of Cyber-Threats with Revolutionary Security! – 0:16:21
Policy-driven. Trustworthiness guaranteed.
In order for Device Guard to be used effectively, it is important to know what code is running in the environment. Rules are created that uniquely identify code that is trusted. The rules define code attributes such as the filename, signature, hash, digital certificates, trusted publisher and vendor information, etc. The rules are later captured in policies. This is effectively whitelisting. Active Directory and enterprise management products like Configuration Manager can be used to centrally manage and distribute the policies to the endpoints. Combined with the functions of modern hardware, and security features and tools in Windows 10, the policies can then be enforced.
When a rule evaluates code trustworthiness, it does a binary-check i.e. Is the code trusted? (True or False). Any code that is not trusted – or is not ‘known-good’ – is blacklisted by default, preventing its execution. The reality is that most malicious code is unsigned and/or untrusted, guaranteeing Device Guard's ability to block the attacks as soon as they occur e.g. malware, worms, viruses, etc.

What are the risks of not using it?

Impacted by “other” failing systems
With today’s antimalware defense strategies and processes, it appears that malware writers are out-smarting security vendors. As discussed in part one of the blog series, it is really just the reactive-nature of security that is primarily at fault. Nonetheless, if perimeter networks, firewalls, IDS/IPS systems, and email scanning fail to detect the malware, endpoint security is the last hope for prevention and mitigation. End-user behavior is another risk to be concerned with, when nearly 50% of users open e-mails and click on phishing links (inside the email) within the first hour after the message was sent. Training and education can sometimes fall short in nurturing responsible computing behaviors when, for example, users are lured to malicious websites. Also, what about dealing with the inherent risks of following bad administrative practices like, not deploying patches in a timely manner to fix known vulnerabilities?
Verizon's 2015 Data Breach report shows that 99.9% of exploited vulnerabilities were compromised more than a year after the CVE (Common Vulnerabilities and Exposures) was published. In other words, the endpoints were unpatched for more than a year when in fact they could have been secured long before the compromise was even attempted. Evidence shows that security measures can be porous and ineffective.
Fear of an APT
By this time, the risks are compounded and converging while the attacks become more lethal. Falling victim to an Advanced Persistent Threat (APT) attack is arguably the most feared of them all e.g. Target (2013), Sony (2014), Home-Depot (2014). APT's are intelligent and sophisticated attacks that sometimes employ social-engineering tactics, targeting specific businesses and organizations. Because of their stealth characteristics, once a vulnerability is exploited by malware and creates a “backdoor” into the organization the APT sometimes progresses to stealing data rather than causing damage to the endpoint or critical systems on the network, often going undetected for long periods of time. For example, the Anthem hack is suspected to have started in April 2014, nine months before being discovered. In 2013, C&K Systems, Inc. (Goodwill Industries) was hacked for 18 months before KrebsOnSecurity.com broke the story in July 2014.
Below is an illustration chronicling the steps of an APT attack:

The most secure implementation of Device Guard could halt steps 1, 2 & 3 in their tracks, making steps 4 & 5 nonexistent and the entire APT effort non-lethal. The primary risk of not using Device Guard, or even a less than secure implementation of it, is that organizations are left with a false sense of security, remaining dependent upon marginally defensive measures. It's not that today's antimalware and antivirus solutions are inherently bad, but that they are becoming increasingly ineffective as the sole enforcers of endpoint security.
Summary
To summarize the key points of this second part of the series:

• Device Guard hardens various attack surfaces on an endpoint creating a "chain of trust" from the hardware through to the Windows OS kernel and to software running in Windows
• Device Guard components run in isolation from the Windows kernel and is secured by a Windows Hyper-V container called Virtual Secure Mode (VSM)
• Device Guard uses a policy-based system which defines various attributes to identify code that is trusted during the endpoint’s boot process, loading of the Windows OS kernel and applications running when the full OS loads
• Various risks in the organization caused by the failures of other security systems and inadequate processes exacerbate endpoint security when Device Guard is not used or not implemented in the most secure manner

Stay tuned for part three of this blog series Device Guard – The Practice, where I’ll be covering:

• What are the prerequisites for Device Guard?
• How to best implement Device Guard

To learn more about Windows 10 and ConfigMgr migration topics from 1E, register for upcoming webinars and watch recorded webinars on demand:
On-Demand Webinars:

• Creaking Infrastructure, Stressed IT Staff and Cranky Users. Does Your Windows 10 Migration Have To Be This Way?
• When Is Your Windows 10 Migration Done? Never!
• Windows 10 Security: Reasons to be Cheerful (and Not So Cheerful)
• Turbocharge Your Windows 10 Migration with Nomad 6.0
• Is Your Enterprise Ready for Win10? – with MVP Johan Arwidmark (@jarwidmark)
• High-Velocity Win10 Migration – with MVP Johan Arwidmark
• Taming the Worst Win 10 Deployment Troubles – with MVP Johan Arwidmark
• Preparing for the Future of SCCM – with MVP Kent Agerlund (@agerlund)