Often I make suggestions to Microsoft privately, occasionally I do so publicly.  I’m doing this one publicly to generate broader discussion and hopefully a consensus.  I already mentioned this on Twitter a few weeks ago, but the full discussion requires a blog entry.

Microsoft’s EMET (the Enhanced Mitigation Experience Toolkit) is a security tool aimed primarily at Enterprise Information Technology departments.  It can be used by, and is available to, sophisticated end users.  However it really isn’t designed for typical end-user use.  This is a call for Microsoft to create an “EMET Lite” that is available with or packaged into all Windows systems, with management provided by Microsoft via Windows Update.

To get an idea of why EMET Lite might be desirable take a look at the results from this week’s Pwn2Own hacking contest.  No one was able to claim the $150,000 Grand Prize for hacking IE11 with EMET running.  All major browsers, including IE11 without EMET, were hacked.

Ok, so what is EMET?  Let’s go back to the effort that Microsoft started in the early days of Windows XP when it became apparent that the OS had severe security problems in the Internet environment.  It started to add features (DEP, SEHOP, ASLR, etc.) to the operating system that applications could use to harden themselves against attacks.  Why did applications have to explicitly turn those features on instead of the OS just imposing them?  Easy, in many cases applications required minor changes to be compatible with the new security features.  So the model from Windows XP SP2 on has been that executables have to indicate when built that the features should be turned on.

Now Microsoft itself made turning on those features part of the Security Development Lifecycle (SDL) for its products, so those are fairly well protected.  And over the years many other software developers have adopted SDL or similar processes and turned on these features.  But what about applications that haven’t turned on those features?  What about bespoke applications that an IT shop writes that are no longer being actively developed?  What about apps that the source code is unavailable for?  Tweaking these apps and rebuilding them to use the features runs from impractical to impossible.  The answer to that problem was EMET.

EMET allows an IT shop to force one or more security features on for a particular executable.  So let’s take an example of how it was intended to be used.  You have a bespoke order processing application, and you have some kind of internal testing methodology for verifying changes to that application.  So you take EMET and you use it to turn on one or more of the features.  Then you test to see if you’ve broken the app.  If you haven’t broken the app then you deploy an EMET rule to all your clients turning on the features(s) for the order processing app.

The key here is that the IT department is responsible for testing and making sure the app is compatible with the selected security features.  And if the app is updated, the IT department is responsible for re-testing that the features don’t break it.  These are things beyond Microsoft’s control, and beyond what 99.99% of end-users are willing to deal with.  That’s why EMET is a toolkit and not simply an OS feature.

But if Microsoft is already mitigating its own software, and so are many ISVs, then isn’t EMET essentially only for bespoke apps?  Well, no.

Microsoft keeps expanding the set of mitigations available through EMET, with mitigations appearing in it before they are available through the OS and development tools.  Moreover, even if a new mitigation were available and used to protect “IE12” that wouldn’t help IE11.  So EMET can be used to add newer mitigation techniques to current, or older, software releases.

This is great for IT shops who can, and should, be using EMET to protect all software running on systems they are responsible for.  But what about the rest of us?

I propose that Microsoft create an EMET Lite that is distributed to users much as Microsoft Security Essentials and Windows Defender are today.  That is, either a free and recommended download or built-in to newer versions of the operating system.  The key differentiator between EMET and EMET Lite is that for the latter all of the rules would be generated by Microsoft and managed via Windows Update.    This places a burden on Microsoft, which is likely why they haven’t done it to date.  But for a company worried enough about security that they created EMET, and with evidence of the value of an EMET Lite such as the Pwn2Own results, Microsoft should take on this burden.

How much of a burden would Microsoft managing the EMET Lite rules actually be?  I don’t think it would be substantial.  Take as an example a default set of rules that come with the EMET 5 Technical Preview.  They turn on mitigations for “Microsoft Internet Explorer, WordPad, applications that are part of the Microsoft Office suite, Adobe Acrobat 8-11, Adobe Reader 8-11, and Oracle Java 6 and 7.”  So if you install EMET and accept the defaults you already have protected critical software using Microsoft supplied rules.  Now all they need to do is offer to update those rules as needed with Windows Update and you are rather close to my EMET Lite offering.

EMET Lite could be offered in a way that was almost totally transparent to end-users.  It could be distributed via Windows Update as a recommended download (and built in to post Update 1 versions of Windows 8.1 and later).  Once downloaded Windows Update would maintain the rule-set.  Telemetry from application crashes, as well as Microsoft’s other feedback loops, would be used to fix broken rules.  The testing processes used for Anti-Malware signatures and Patch Tuesday updates could be applied to proposed rule changes.

Third parties could be encouraged to validate and supply rules for their own software that Microsoft would then ship, though this carries some complexity and risks.  It seems that Microsoft already has many cooperation frameworks which could be extended to cover this case.  If not, Microsoft might simply let third-parties install and maintain their own rules.

EMET Lite also offers Microsoft an additional way to deal with some zero-day issues while it, or an ISV, develop a patch.  It could ship a new rule, or create a “Fix It” solution that installs a new rule, turning on a mitigation even if that creates a compatibility problem pending a real fix.  The Fix It path is particularly attractive because it allows Microsoft Customer Support to help customers while engineering is still investigating a permanent solution.

The benefits of EMET Lite seem enormous, the downside minimal.  Microsoft would take on some extra costs and risk.  But those costs and risk seem pretty minimal compared to the benefit that EMET is demonstrating.  Now is the time for EMET to move from IT toolkit to mass market security tool via an EMET Lite.