Infosec sea change coming
Infosec sea change coming. By Tracy Burrows, ITWeb contributor. Johannesburg, 9 May 2014. Enterprises need a back-to-basics approach, says Guy Golan, CEO of the Performanta Group. Enterprises are on the verge of losing the cyber security battle in the ...


After my post last week on things a System Administrator can do to protect against zero days in your browser, operating systems and applications, one of the biggies for Windows is to deploy EMET - Microsoft's Enhanced Mitigation Experience Toolkit.  EMET implements advanced security controls that are not native to the operating system.  Using EMET, you can take advantage of security features from Windows 8, even if you are running Windows 7 or even to some extent on XPSP3.  Or you can beef up what's in Windows 8 with features that aren't anywhere but in EMET yet.

I've been running EMET for some time on my "production" laptop, and haven't had it cause an issue - ever.  However, I don't run any "corporate applications", and lots of the dedicated security tools I use are either in VMs or are deployed on different machines.  In a corporate environment, I'd still suggest that EMET is a great way to go, but you'll want to test this tool on a small but representative user group, then deply in stages.  If you've got a reasonably complex environment with apps that have been around since the 90's, then you are like most shops, and you can expect EMET to break things here or there - you'll really want to test this thoroughly before you roll it out en masse.

But there's the rub - how do you deploy EMET to a 20. 200, 2,000 or 20,000 desk environment, without going to every desk?  

And once it's there, how do you manage settings?

A really simple deploy can be done from the login script.  Something like works in lots of cases:

if exist "C:\Program Files (x86)\EMET 4.1\EMET_GUI.exe" goto EMETISOK
msiexec /i "\\uncpath\EMET Setup.msi" /qn /norestart

This assumes you're allowing users to install applications (which I'm hoping you don't do!)

At the other end of the spectrum, Microsoft documents rolling EMET out using SCCM in the EMET User's Guide.

However, if you want something between these two extremes - something more reliable than the login script, but you don't have SCCM in your environment, Carlos Perez has a great "How to deploy EMET using WSUS" doc, found here:

OK, now it's installed, how do you manage all the dials and knobs that make up the dozens of options within EMET? 

You can go a long way down this road with Group Policy.  There are two files you need - EMET.adml and EMET.admx, located in the EMET directory: Deployment\Group Policy Files.  On the host you'll be building your Group Policies (usually on one or more of your Domain Controllers) copy EMET.adml to \Windows\PolicyDefinitions\en-US.  Copy EMET.admx to \Windows\PolicyDefinitions.  Once this is done, you'll have access to many of the EMET settings in Group Policy.

Computer Settings:


And User Settings:

You can also manage EMET from the CLI - you can export your EMET settings to an XML file once it's tuned (Microsoft includes 3 XML files with the tool), and you can import settings stored in  XML from the CLI.  If you have a group of stations or users with settings that are complex enough that Group Policy won't do the trick for you, you can can work out procedures using XML files for these users, either using a login script or a centralized script that might use psexec from Microsoft's sysinternals.

This is a really high level description of how you'd deploy EMET in a typical Windows shop.  Where I've done this, it really has been this simple - this is one of those tools that just works.  But if you've found a "gotcha", or a slick way of getting someting done in EMET, please add to the conversation in our comment form.

Rob VandenBrink

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Computer scientists have uncovered direct evidence that a small but significant percentage of encrypted Web connections are established using forged digital certificates that aren't authorized by the legitimate site owner.

The analysis is important because it's the first to estimate the amount of real-world tampering inflicted on the HTTPS system that millions of sites use to prove their identity and encrypt data traveling to and from end users. Of 3.45 million real-world connections made to Facebook servers using the transport layer security (TLS) or secure sockets layer protocols, 6,845, or about 0.2 percent of them, were established using forged certificates. The vast majority of unauthorized credentials were presented to computers running antivirus programs from companies including Bitdefender, Eset, and others. Commercial firewall and network security appliances were the second most common source of forged certificates.

At least one issuer of certificates—IopFailZeroAccessCreate—was generated by a known malware sample that was presented 112 times by users in 45 different countries. The discovery helps to explain bug reports such as this one made to developers of the Chromium browser describing the mysterious inclusion of a TLS certificate on a large number of end users' computers.

Read 4 remaining paragraphs | Comments

At least one of Microsoft's Patch Tuesday updates looks like an excellent candidate to hackers as they poke around for bugs in the now-retired Windows XP.
Internet Storm Center Infocon Status