Microsoft has put many defensive technologies, like ASLR, DEP and SAFESEH into Windows over the years to mitigate against the exploitation of vulnerabilities in Windows and applications. But Microsoft is rightfully very conservative about making such changes for all Windows users. There are other things that can be done which Microsoft has not seen fit to roll into Windows.
Instead, Microsoft puts these in the Enhanced Mitigation Experience Toolkit (EMET - pronounced with two soft e's). EMET is a tool you install on a Windows system which allows you to impose additional restrictions on specific applications on that system. It's common, when Microsoft discloses a vulnerability, for them to announce that use of EMET would mitigate it.
Most recently, in MS14-080, the December Cumulative Security Update for Internet Explorer, 11 of the 14 vulnerabilities were memory corruption vulnerabilities and the bulletin says that "EMET helps to mitigate these vulnerabilities in Internet Explorer on systems where EMET is installed and configured to work with Internet Explorer."
I run EMET on my own systems, but would you do it in an enterprise? Microsoft tells me that:
A wide variety of customers in every segment are using EMET. We're especially encouraged hearing from security researchers and engineers who actually write exploits, saying that they use EMET on all of the computer systems they use.
EMET meets one absolute necessity for enterprise deployment: It is deployable and manageable through Active Directory Group Policy Objects. The US Department of Defense mandates use of EMET in computer systems and GPOs to manage it. The Windows 7 STIG, (Security Technical Implementation Guide - STIGs are implementation rules for computer systems) describes the rules, rationale and some procedures. You could do a lot worse than to start with this document for your own plans. There are STIGs for other Windows versions and many other products.
The main downside to using EMET is that its aggressive techniques increase the potential for application compatibility problems. Techniques, likely bugs in the applications, may trigger mitigations in EMET. This means that you need to test your enterprise applications with EMET before deploying it generally.
It's probably best to choose a test group of sophisticated users for this. As you run into problems you can adjust the mitigations in use on the systems (see the screen below) until they are at least unlikely to cause problems for your applications. You can also choose just to log EMET detections and not take action on them.
The column headers in that screen are the mitigations available and the screen shows the default settings, so you can see the large majority default to on. The EMET User Guide goes into some detail on what the individual mitigations are, but here are a few:
Heapspray Allocations: Exploits commonly place many copies of their code on the heap (a program data storage area in memory) of the process under attack to increase the chances of the code running. It's not clear what EMET is doing to detect or block this.
Mandatory ASLR: ASLR randomizes the location of programs in memory to block ROP (Return Oriented Programming) attacks. But for the program to be protected by ASLR in Windows the developers needs to turn it on deliberately. You still find many programs, or perhaps just one or two DLLs in a program, not set for ASLR. Mandatory ASLR forces all modules in a program to be protected. (There is a similar setting for DEP (Dynamic Execution Prevention) which has a similar requirement for the developer to opt-in.
Export Address Table Access Filtering (EAF/EAF+): If attack code needs to run Windows APIs it needs to find the addresses of the APIs first. Typically, attacks do this by searching through the export address tables of major Windows DLLS, meaning kernel32.dll, ntdll.dll and kernelbase.dll, until it finds the one it needs. EAF attempts to block access to these tables by attack code. EAF+ adds new, more aggressive methods to this problem; you can see from the screen shot above that EMET generally defaults to off for EAF+.
Caller checks: This is another ROP mitigation. EMET checks to see whether a critical function has been reached through a CALL instruction or a RET instruction.
Microsoft calls EMET a "proving ground for new, cutting edge security tactics and features" for Windows. Perhaps "field test" is a better term than proving ground, but it's a particularly apt tool, especially as more enterprises adopt it.
The really ambitious among you can use your test group to attempt to employ more aggressive settings in EMET than the defaults. In the spirit of defense-in-depth and least-privilege, you should tighten settings as much as possible. You can more safely and sanely do this by logging the aggressive settings rather than stopping the application, and the logs may give you something interesting and useful to give to the developer of the software.
That brings up another benefit of EMET: As a testing tool, widely-deployed, it has the potential to help developers make their software more secure. I think we can all get behind that.