Microsoft Ignites a new Focus on Security (Part 1)

If you would like to read the other parts in this article series please go to:


Microsoft held its very first Ignite conference the first week of May, in Chicago at the McCormick Place Convention Center. When the company announced that they were doing away with the venerable TechEd, which has been held annually in the U.S. (along with sister conferences in Europe, Australia, Asia and even (in 2010) in the Middle East), there was a great deal of negative feedback from IT professionals. The last North American TechEd was held last May in Houston.

The end of TechEd and its replacement by something that was first officially announced as the Unified Technology Event for Enterprises (UTEE?) came last July. The name was changed to Ignite. This came in the wake of Microsoft’s decision the year before to kill the Microsoft Management Summit, the end of TechNet in 2013, and numerous other business decisions by the company that were seen by many as steps toward “throwing the IT pro under the bus” in favor of focus on providing its cloud services.

Thus many eyes in the industry were on Ignite as it opened with over 20,000 in attendance. CEO Satya Nadella kicked things off on Monday with a keynote that went on for almost three hours, then the breakout sessions started. There were over 1100 sessions available throughout the conference, with 115 listed under the ”Security and Access Management” topic. Sessions were targeted to different audiences: IT influencers and implementers (which would include IT pros), IT decision makers, enterprise developers and architects. Ninety-three of the 115 security-related sessions were targeted to influencers and implementers.

Security in the cloud – and on the ground

As one might expect, many of these sessions were focused on security in the cloud: twenty sessions involving securing Office 365, twenty-seven related to security issues for Azure and Azure Active Directory, ten related to Microsoft Intune security. Given the premise that Windows 10 is the “last version of Windows” and the delay in coming out with a new version of Windows Server that has led many speculate about its impending demise, it might come as a surprise that the largest number of security sessions (forty-one) were devoted to Windows security.

These sessions addressed a wide variety of security issues, ranging from web browser and social networking security to the new and enhanced security features in Windows 10. BitLocker, Windows Hello, Windows Defender, Device Guard, containers, and more all got their fifteen minutes of fame.

In this article series, we’re going to provide a brief overview of some of those new technologies (and the improvements that have been made to some already-familiar ones) and then in subsequent articles, we’ll dig more deeply into many of the most interesting ones.

More flexible patching cycles

Although at this point it hasn’t been officially confirmed, comments at Ignite from the vice president of operating systems made the headlines with the indication that Microsoft’s predictable Patch Tuesday monthly security update release cycle might be getting some changes.

PC World reported that Terry Myerson said in the future, instead of issuing a whole slate of patches on the second Tuesday of the month, Microsoft might release security and other updates as a “steady stream of innovation.” You can read more about my take on this idea and its implications – both good and bad – for IT pros and organizations, over on the GFI blog.

Windows 10 Device Guard

The discussion around Device Guard, a new security mechanism that will be built into Windows 10, wasn’t the first time we’ve heard about this feature. It was first announced at this year’s RSA Conference in San Francisco in April, by VP Scott Charney. Several sessions at Ignite provided more information about it.

The purpose of Device Guard is to provide network administrators with a way that they can harden Windows 10 devices against new and unknown types of malware, zero day threats and advanced persistent threats (APTs). It works by blocking everything except “trusted apps.” So what makes an app “trusted?” These are apps that have been digitally signed by trusted software vendors or by the Windows Store. What about your apps that are developed in-house? You can sign those and make them trusted, as well.

Many vendors have signed on to using Device Guard, including HP, Acer, Lenovo and other popular Windows device makers. However, it is also important to note that administrators have complete control over which vendors are to be seen as trusted. If you have apps that weren’t signed by the original vendor but that you deem to be trustworthy, there are tools included that you can use to sign these so that they can run. Microsoft has also indicated that enterprises will be able to send their apps to Redmond to be signed with a key that works only for that organization. Device Guard won’t permit those apps to run on devices in other orgs, so you don’t have the problem of one company having a dangerous app signed and that being distributed, deliberately or accidentally, to another org.

You might be wondering exactly how Device Guard differs from other anti-malware solutions. Here’s the advantage: Device Guard uses hardware and virtualization to keep the process of determining an app’s trustworthiness isolated from the rest of the operating system, which protects the rest of the OS when an app is run. Device Guard itself runs in a separate, minimalist instance of the OS. This means that when Device Guard is enabled, the hypervisor will always be running and this second, stripped-down version of Windows will be running.

Device Guard depends on hardware that has an IOMMU, which is an input/output memory management unit. This is a component that connects the DMA-capable I/O bus to the main memory and maps virtual addresses to physical addresses. There are many advantages to the IOMMU, including protection of memory from malicious attempts at DMA attacks. The down side is that there is some performance hit compared to older CPUs that used direct physical addressing of memory, but with the speed of today’s processors, this should not be an issue.

To use Device Guard, the device will need to have IOMMU protection mechanisms built in (which modern Intel and AMD processors do have, as do some ARM processors). Hardware from major manufacturers will be labeled as Device Guard capable or Device Guard ready. The “ready” devices will already have everything set up to use Device Guard: the IOMMU hardware, drivers installed and the feature enabled. “Capable” devices will have the hardware but you’ll need to install drivers and configure the device to use Device Guard.

Of course you can (and should) use Device Guard in conjunction with more traditional anti-virus software since there are some types of threats that Device Guard doesn’t protect against, including Java and macros in documents. Working together, Device Guard and other security technologies can significantly reduce the threat from various types of malicious code.

Device Guard is going to be an important addition to the Windows 10 security arsenal because it can help to protect against some of the more challenging malware threats that have emerged over the last few years, such as CryptoLocker and BlackPOS. It will help to address the problem of polymorphic malware, which is so-called because it is constantly changing or “morphing” into different variants. This, of course, makes it very difficult for most traditional anti-malware solutions to detect and deal with it. Polymorphic malware may disguise itself by changing file names, variable keys, or by using encryption or compression to hide its true nature and identity.

Device Guard moves the anti-malware effort away from the current “innocent until proven guilty” approach to executable code and toward a more Napoleonic Code approach where apps are considered guilty until proven innocent. This is already the basis of the “principle of least privilege” that best practices dictates for granting access permissions to users, but we have, in the past, given more benefit of the doubt to applications that we give to users.

With traditional anti-malware strategies, all applications are trusted until/unless our anti-malware system identifies them as potential threats. The problem is that, like a terrorist who has no previous arrest record, new or newly mutated malware is considered safe and we let it into our systems. This is “blacklisting” – maintaining a list of apps that are known to be malware and blocking them. Device Guard brings us a new way of “whitelisting” – maintaining a list of apps that are known to be safe and blocking everything else.

This is not, of course, a new concept. AppLocker also operates on the whitelisting principle, as did its predecessor, Software Restriction Policies (SRP). The difference is that SRP and AppLocker were complex and difficult to configure properly. You had different rule collections that applied to different file types, and different rule conditions for each rule collection.

Device Guard implements the whitelisting concept in an entirely different way that is aimed squarely at malware, rather than general control of applications, so it is a security-focused mechanism. Device Guard is only one of a number of security features that are designed to work together to make Windows 10 safer without sacrificing usability.


Ignite definitely ignited some fiery feedback in response to the news that Patch Tuesday might be coming to an end, but it also ignited a good deal of positive response to some of the new Windows 10 security features that are on the horizon, including Device Guard. In Part 2, we’ll look at more of the new security features, products and services, including one that’s getting a lot of attention: Microsoft Advanced Threat Analytics.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top