EMET: To be, or not to be, A Server-Based Protection Mechanism

Hi Folks – Platforms PFE Dan Cuomo here to discuss a common question seen in the field:

“My customer is deploying EMET and would like to know if it is supported on Server Operating Systems.”

On the surface there is a simple answer to this question, however with a little poking, a little prodding, the question quickly becomes:

“Does EMET protect Server workloads?”

This is a more complicated question that usually incurs some email-based eye-rolling when we tell them, like most questions, “It depends.” They really didn’t mean to ask that question either and so after some more poking, and some more prodding, a number of different questions are uncovered, all of which require a little more analysis than the typical “YES” or “NO” question. So in the next few paragraphs we’ll discuss the reasons for this question, and how to have this conversation with decision makers in the organization.

Is EMET Supported on Server Operating Systems?

The simple answer to the server support question is an emphatic “YES!” As you can see in the EMET support article (summary below), EMET 5.2 can be installed on most currently supported operating systems (as of the writing of this article) and their derivatives. For example, the Client OS’ 7, 8, and 8.1 are all supported as are the Server OS’ 2008, 2008 R2, 2012, and 2012 R2. (Note that EMET 5.5 Beta provides support for Windows 10)

Operating System (min supported)

EMET 5.2

Windows 10

N

Windows 8.1

Y

Windows 8

Y

Windows Server 2012 R2

Y

Windows Server 2012

Y

Windows 7 Service Pack 1

Y

Windows Server 2008 R2 Service Pack 1

Y

Windows Server 2008 Service Pack 2

Y

Windows Vista Service Pack 2

Y

[Short and Sweet] :

Q: Is EMET Supported on server Operating Systems?

A: Yes, EMET is supported on currently supported server Operating Systems

Can EMET Protect My Legacy Server Operating Systems?

One reason customers consider deploying EMET is to protect their legacy systems such as Windows XP (EoL: April 8th, 2014) and Server 2003 (EoL: July 14th 2015). Many customers may still be wondering if they _really _need to migrate or event how to get started. This link and this Tech Ed video It’s the End of the World As You Know It…Windows Server 2003 End of Life will give you a bunch of great information. If you want the Cliffsnotes, yes you REALLY need to migrate; one thing you won’t find on this page is a link to download EMET.

You may be wondering if you can avoid migrating a legacy system to a newer, supported operating system if you install EMET. The absence of EMET from the prior links as well as this video should make it abundantly clear that that the answer is “NO.” You still need to migrate off of the legacy operating systems. In addition, once the server operating systems goes out of support, EMET is no longer supported on that platform. For example, now that we’ve passed July 14th, any remaining 2003 systems in your enterprise are no longer supported. Likewise, the EMET application on those systems is also unsupported.

EMET primarily mitigates user-mode application exploits that target applications like Microsoft Office, Internet Explorer, and Adobe Acrobat. As such, it may provide some additional protection while you’re migrating, however it will not protect you against all exploits targeted at this legacy platform and it is certainly not a long-term “silver-bullet” to enterprise security. Your safest course of action is to upgrade those legacy systems to a newer, supported operating system.

Note: Having just read that the last sentence, many of you are currently misinterpreting what I said as proof that you don’t really need to upgrade if you have a mission critical application that only runs on a legacy OS. STOP IT!!!

All joking aside, I will tell you that nearly every customer I have encountered thinks they’re the exception to the rule. In reality, there are few actual exceptions. If you don’t know what to do or how to get started, I implore you to contact us to see how we can help you.

[Short and Sweet]:

Q: Will EMET protect your legacy operating system?

A: Nope. While EMET could mitigate some potential vulnerabilities on a legacy system, it should not be considered a long-term alternative to migrating to a support OS.

What should I protect with EMET?

OK, let’s recap. We now know EMET can be installed on supported server operating systems. In addition, it can provide some level of protection while you’re migrating off a legacy OS. But what applications should you configure EMET to protect in these environments?

When considering an application protection strategy, keep in mind that “agents” are most likely already sprawling throughout your enterprise, consuming valuable system resources. I’ve regularly heard customers say, “Not another agent!?” With this in mind, focus on a risk-management based approach. This would include applications that are:

1. Most likely to be exploited

2. Consuming content from external or untrusted sources

Most likely to be exploited:

In addition to being the least desirable high school yearbook award, this category describes applications that are highly targeted by attackers. This often boils down to the widespread use of an application. Protecting applications that attackers believe yield a high reward (for example, those that affect many people) should be considered essential.

An example of this would be Microsoft Word or Adobe Acrobat. Both of these applications have a large user base. An attacker would know that if successful, the exploit would affect many customers. In contrast, an exploit that targets a “home-grown” LOB application would yield a low-reward.

Applications consuming content from external or untrusted sources

This category describes applications that consume or access content from an external or untrusted source such as the internet. For example, both Microsoft Word and Adobe Acrobat handle “untrusted” content when a user downloads and opens *.docx or *.pdf from the internet. However, opening *.docx or *.pdf from an intranet SharePoint site is of low risk. Another example would be any web browser that has access to the internet.

When you first configure EMET you’re greeted with the wizard shown below:

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/emet1.png)

If you select the option to “Use Recommended Settings” (shown above), you are among other things, configuring EMET to use the “Recommended Software.xml” protection profile included with the installer. The included applications (shown below) are recommended by the EMET Product Group and have gone through testing to verify that, by-and-large, the mitigations selected will reduce the number of false-positives and incompatibilities incurred with EMET.

Note: False-positives and incompatibilities are likely to occur as many applications make use of the exact behavior that the mitigations intend to block. Please review__EMET mitigation guidelines__for a list of known application mitigation compatibility issues.

Please also review Kurt Falde’s article on__Troubleshooting an EMET Mitigation Application Crash__for information on what to do when you find an incompatible application mitigation.

It is imperative to thoroughly test your configuration making sure that the pilot contains a good representation of target systems. For example, make sure to include all necessary plug-ins or add-ins to applications that will be encountered in the enterprise for both client and server operating systems.

The included protection profiles are great low-risk way to get started. These profiles contain the “low-hanging fruit” and provide the biggest gains. The applications included in the recommended software protection profile (shown below) cover a range of popular applications and those that consume external or untrusted content.

](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/emet2.png)

The popular protection profile is a superset of the recommended protection profile. It adds a number of additional applications that fit the same bill. Once you’ve tested the applications in the recommended list, test the applications in the popular list against a group of machines that are representative of your target environment.

[Short and Sweet]:

Q: What should you protect with EMET?

A: Stick to the applications in the recommended and popular protection profiles. These include applications that have been tested, are widespread, and may handle external or untrusted content.

What about generic Microsoft processes?

Nope. Technically speaking, you can ask EMET to protect any application that runs on a system. However, keep in mind that these additional applications have not been tested and may not behave as expected. We specifically call this out in the EMET mitigations guidelines, “System and network services are also out-of-scope for EMET. Although it is technically possible to protect these services by using EMET, we do not advise you to do this.”

This includes servers that you really care about, like domain controllers. Between you and me, if you’re thinking about protecting LSASS.EXE or MSExchangeIS.exe, this is what we in “the biz” call an “RGE” (resume generating event). Put down the mouse and step away slowly…

[Short and Sweet]:

Q: What about generic Microsoft processes?

A: Nope, stick to the applications in the recommended and popular profile lists.

What else should I consider?

Some of you savvy readers out there are probably saying to yourself,

“Now hold the phone, Dan. We follow pretty stringent guidelines about what does or does not get installed on servers. We have enforced rules that prevent the installation of the applications listed in the protection profiles.”

“In fact, we even make sure that administrative users are unable to reach the internet from servers. We’re confident that none of the applications you spoke of previously will reach our servers.

Before completely discarding EMET, it’s important to note that EMET does provide other capabilities that you may be able to leverage, such as certificate trust pinning. However, if you can honestly tell me that there is no way that those applications will get installed on your systems and that they can never come in contact with untrusted content, you may not need EMET on your servers. On a side-note, if you’re looking for a PFE, I know someone who would love to work in an environment like that J

It’s to these customers I usually recommend a Microsoft Security Risk Assessment (#ShamelessPlug) or other security assessment that helps make sure that your perception is reality. Some of the best advice I’ve been given is, “trust, but verify.”

In contrast, perhaps your team is just too big, or too widespread. Maybe you don’t have the necessary process, procedure, or technology to eliminate this risk in your server environment. In cases like these I would advise rolling out EMET to your server infrastructure as well.

[Short and Sweet]:

Q: What else should I consider?

A: Look at your IT team structure. Review your processes and procedures. Have a third party look at them. Verify EMET can’t help you before you decide you don’t need it!

Summary

As you have now seen, this seemingly simple question spirals into a complicated one very quickly. EMET is supported on servers, and can be used to enhance security across a wide range of platforms. Use the built-in protection profiles as a baseline and thoroughly test your target systems prior to deployment.

Lastly, if your technology, process, and procedures for server security are foolproof, then feel free to focus your efforts elsewhere. Otherwise consider EMET part of your IT security “flu-shot.” Take the time now and roll it out before you have a problem.

Thanks for reading,

Dan Cuomo