Office 2010 Security (Part 1) - Threat Mitigation

by [Published on 9 Feb. 2012 / Last Updated on 9 Feb. 2012]

This article introduces Office 2010 security improvements and explains how Office File Validation can help mitigate against potential threats.

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

Introduction

Over the years most large enterprises together with many small and mid-sized have deployed some version of Microsoft Office as the primary business productivity software for their end-users. When malicious hackers began turning their attention from trying to hack into back-end servers to attempting to compromise the operating system and applications installed on end-user PCs, Microsoft began locking down certain Office features and including new security and privacy capabilities in order to counter these threats.

In many ways, Microsoft has led the industry when it comes to end-user application security. Many of the security innovations Microsoft incorporated into Office over the years have since been emulated by other software vendors. As examples of this, consider the following:

  • With the announcement of the Microsoft Update cloud-based patch distribution service at the RSA conference in February 2003, Office 2003 became the first end-user application that could be automatically patched whenever a new security vulnerability was discovered.
  • With the inclusion of the Office Open XML file formats as the default document formats for Office 2007, Microsoft took the lead in the industry by co-sponsoring together with ECMA the Office OpenXML specification as an open industry standard (ECMA-376). The Office Open XML specification later was standardized by the ISO and IEC as ISO/IEC 29500.
  • Office 2007 also marked a turnabout in Microsoft’s security strategies by becoming the first version of Office designed to be “secure by default.” In other words, the default settings for Office 2007 were designed to block threats from potentially dangerous content at the expense of usability. Security experts know that there is always a tradeoff between security and usability—the more secure something is, the harder it can be to use and vice versa. Previous versions of Office added new features to increase usability with only moderate concern for potential security ramifications. With Office 2007 however, the balance now tipped towards the security side of the equation.
  • With Office 2010 however, Microsoft has basically tried to accomplish two things. First, make Office even more secure by adding new features and enhancing existing features. And second, make these new security features and enhancements easier to use and less intrusive in order to better balance usability vs. security for the platform. My own belief—as these articles are intended to demonstrate—is that Microsoft has been largely successful in these twin efforts.

Two Types of Security Enhancements

Office 2010 security has basically been enhanced in two ways:

  • Threat mitigation – New technologies have been added to the platform in order to better mitigate against potential attacks on the platform.
  • Information control – New features have been added and existing features have been improved in order to enable organizations to protect the flow of business information to ensure its confidentiality, integrity and availability.

Table 1 below lists some of the key protection technologies and features included in Office 2010 in these two areas.

Threat Mitigation Technologies

Information Control Improvements

Office File Validation

Protected View

Trusted Documents

Crypto and digital signature improvements

Document Inspector

Domain-based password enforcement

Table 1: Examples of the two types of security enhancements in Office 2010

The rest of this article and the next one will deal with the three threat mitigation features listed in the table above. The third and final article in the series will dig deeper into some of the information control improvements in Office 2010.

Office File Validation

The introduction of the Office Open XML file formats in Office 2007 was a big improvement because it meant that ordinary Word documents, Excel spreadsheets and PowerPoint presentations were basically just collections of plaintext files that contained XML markup and compressed in archived (zipped) format. And because .docx, .xlsx and .pptx files are basically compressed collections of text files, they can’t contain embedded executables or other binary content that might compromise a targeted computer. In addition, Office files that contained embedded executable content were saved with special file extensions (.docm, .xlsm, .pptm) in order to enable enterprises to control which types of Office files should be blocked at perimeter firewalls and which types should be passed through.

But there were some problems with this scenario:

  • Earlier versions of Office had used the letacy Office binary file formats (.doc, .xls, .ppt) and since these formats were binary in nature it was relatively easy for attackers to either embed malicious executable code inside files created using earlier versions of Office or modify selected bits within these files to cause the receiving Office application to crash or perform some malicious action. The way that hackers determined which bits to change within binary Office files was simply done by making random changes to these files until something happened that could be exploited for malicious purposes.
  • Zillions of older Office files saved in these legacy binary formats were (and are) still kicking around both within organizations and on the Internet. While Microsoft provided tools for migrating these legacy documents to the new file formats, it could cost businesses significant time and effort (and hence money) to do this.
  • Even if you migrated your legacy documents to the new XML file formats and standardized on using these new formats, that still wouldn’t be enough since some of your business partners or customers might still be using the old file formats for sending business documents to you.
  • Some enterprises (and end-users) resisted the change to the new XML file formats for various reasons ranging from “We don’t know the consequences of changing to the new file formats” to “We’re afraid of incompatibilities that might arise with existing custom workflow processes” to “We’ve always done it this way and we don’t like changing things ever” and so on.

But the biggest problem with the old binary file formats for Office 2003 and earlier was that there was no easy way to validate legacy Office files to ensure they were safe to open before actually opening them. With Office XML files, this was easy to do because a built-in parser in Office 2007 could check that the file conformed to a predefined XML Schema Definition (XSD) before the file was opened. But for legacy binary Office files, no such XSD existed in office 2007.

With Office 2010 however, new XSDs have been introduced that allow for validation of legacy binary Office files prior to opening them. This lets Office check to make sure an older .doc or .xls file is safe to open before it is actually opened on the computer.

In addition, these XSDs are updated by Microsoft whenever new vulnerabilities are discovered in legacy binary Office file formats (either by Microsoft Security Research or by third-party security organizations) and these updated XSDs are automatically downloaded to users’ PCs so that their copy of Office 2010 will always have the latest versions of these XSDs to ensure maximum protection from compromised or corrupted legacy binary Office files.

This new Office File Validation feature of Office 2010 applies only to the following file types used by Office 97-2003:

.doc, .xls and .ppt

.dot, .xlt, .pps and .pot

End-User Experience for Office File Validation

The end-user experience for Office File Validation is basically like this. If the user tries to open an older .doc file and Office 2010 determines that there is something wrong with the file (i.e. it doesn’t conform to the XSD for .doc files either because the file is corrupt or it contains some malicious code) then instead of opening the file for editing, Office opens the file in a special non-editing mode called Protected View. The signal to the user that this has happened is the appearance of a Message Bar that looks something like the following:


Figure 1: This message bar indicates that a legacy binary Office file has failed Office File Validation.

If the user (or administrator) has chosen to include the user’s PC in the Microsoft Customer Experience Improvement Program (CEIP) for Office 2010, then information relating to the failed file validation event on the user’s PC will be uploaded to Microsoft at the scheduled time.

We’ll look at what happens in Protected Mode in the next article.

Administrator Options for Configuring Office File Validation

As the administrator for your organization, you can use Group Policy to configure how Office File Validation works on end-user PCs. Note that the three policy settings described below are all per-user policy settings.

First, you can disable Office File Validation entirely for a particular Office 2010 application by using the policy setting shown in Figure 1 below, though doing this is not recommended:


Figure 2: Policy setting for disabling Offline File Validation for Word 2010.

Second, you can change how Offline File Validation works for a particular Office 2010 application by using the policy setting shown in the next figure below. The default action for a legacy binary Office file that fails validation is to open it in Protected View, but you can change this to either blocking the file from being opened at all (more secure if you are worried about users simply opening files in normal view for editing when they are first opened in Protected View) or opening the file in normal view for editing (which essentially just turns off file validation for the application):


Figure 3: Policy setting for configuring what happens when a legacy binary Word document fails validation.

Finally, the last figure below shows the policy setting for controlling whether information concerning files that failed validation should be uploaded to Microsoft:


Figure 4: Policy setting for configuring whether information about files that failed validation should be uploaded to Microsoft.

Conclusion

This article introduced the different security improvements in Office 2010 and examined one of them (Offline File Validation) in details from both end-user and administrator perspectives. The next article in this series will look in detail at two other improvements: Protected View and Trusted Documents.

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

Featured Links