An overview of Microsoft Outlook email security features

There's often a tension between convenience and security, and that's particularly true of the security features introduced in the Outlook Email Security Update for Microsoft Outlook 98 and Outlook 2000. (The update's features are built into Outlook 2002 and Microsoft Office Outlook 2003).

You are reading tip #1 from "8 tips in 8 minutes: A Microsoft Outlook email security tutorial," excerpted from Chapter 13 of Secure Messaging with Microsoft Exchange 2003 by Paul Robichaux, copyright 2004, published by Microsoft Press.

Five major changes to Microsoft Outlook security

The security update (which is what I'm going to call it, even though it's included in the current version of Outlook) includes five major changes:

• Improved attachment security. Outlook blocks access to some file types altogether, including .exe and .pif files and screen savers. Administrators can specify a second, less restricted set of file types that can't be opened directly, but can be saved to disk.

• More control for users. The ability for users to control programmatic access to the address book and to Outlook's mail-sending functionality.

• Support for letting Exchange administrators specify which sources for code and Component Object Model (COM) add-ins for Outlook should be trusted. Note that this feature is only available in Outlook 2002 and Outlook 2003; it's not present in the security updates for Outlook 2000 and Outlook 98. These restrictions apply only to COM add-ins, not to programs that use Messaging Application Programming Interface (MAPI) or Collaboration Data Objects (CDO).

• Security zone change. A change to the default security zone in which Outlook runs.

• Code change. Code on unpublished or one-off Outlook forms does not run unless specifically allowed by the Exchange administrator.

Microsoft Outlook 2002 attachment security

As a technical solution to what is largely a behavioral problem, Outlook 2002 checks the file type of each message attachment against an internal list of file types. A default list is included with the product, as shown here, but you can override or customize this list using an Exchange public folder.

Level 1
These file types (including .bat, .exe, .vbs, .lnk, and .js) are blocked by Outlook. Recipients get a warning InfoBar listing the blocked files when they open or preview a message with a Level 1 attachment, but they can't see or access the attachment themselves (at least through Outlook; clients using Post Office Protocol [POP], and Internet Message Access Protocol [IMAP] clients other than Outlook can still get to Level 1 files). See a complete list of the Level 1 attachment types.

Level 2
There are no Level 2 file types by default; you have to add them yourself. With Level 2 attachments, you can see the icon for the attachment, and when you double-click it, you are prompted to save the attachment to your hard disk, but you can't run it directly from its current location. After you have saved the attachment, you can decide how to handle it. This is supposed to make users think before blindly double-clicking every collection of bits that lands in their Inbox.

When you attach a file to an outgoing message, Outlook checks the file type against the Level 1 list. If you've attached any Level 1 files, a dialog box warns you that the recipients might not be able to open the attachment. Clicking Yes in this dialog box sends the message as is. Note that you can tell Out-look to not give you this warning; I'll tell you how later.

When you receive a message that contains a Level 1 attachment, your Inbox displays the paper clip in the attachment column to let you know that the message includes an attachment. When you open an e mail message containing an attachment, the attachment is blocked, and the Outlook InfoBar warns you that the attachment is untouchable. The File | Save Attachments command (as well as the View Attachments command on the shortcut menu that opens when you right-click) shows only those attachments that aren't blocked, rendering the others completely inaccessible. When you open the message itself, you'll see a warning InfoBar listing the blocked files, but you can still get to all attachments that have extensions that aren't on the banned list.

If you receive a message containing a Level 2 file as an attachment, the attachment appears normally. However, when you try to open it, you'll get a warning dialog box telling you that it's a bad idea to run the attachment directly and offering to let you save it to disk.

Microsoft Outlook address book and object model security

Outlook supports the Office object model, so you can write scripts and programs that automate repetitive actions. This is a double-edged sword: it's very useful to allow some programs (like synchroniza-tion tools for personal digital assistants [PDAs] or customer relationship management programs) to access contact information, but the same interfaces can be used by viruses or other malicious executables to propagate.

In fact, many macro viruses invade the victim's address book to get addresses to which they can mail themselves; because the security update makes this harder, some virus creators have now switched to scanning local files and harvesting email addresses from them.

To help counter this behavior, Outlook versions that include the Outlook Security Update 2003 turn on object model guards that restrict what outside applications can tell Outlook to do. There are three categories of object model guard: one category restricts calls made with the Simple Messaging Application Programming Interface (Simple MAPI; don't confuse Simple MAPI with Extended MAPI, which is not subject to the object model guard mechanism), one restricts calls made with the Outlook object model, and the third covers calls made using the Collaboration Data Objects (CDO) method. I describe the specific types of access you can guard against later in the chapter.

Microsoft Outlook 2002 and Outlook 2003 Security Zone changes

In Outlook 2002 and Outlook 2003, the default security zone setting is Restricted Sites, rather than Internet. Within the Restricted Sites zone, active scripting is also disabled by default. This security zone disables most automatic scripting and prevents Microsoft ActiveX controls from opening without permission. This change is designed to protect against malware that might be contained in HTML messages. As long as you leave the default Outlook zone set to Restricted Sites, Outlook won't run scripts in HTML messages, and ActiveX controls in those messages are deactivated. You should ensure that you always apply Internet Explorer patches to all machines running Outlook, because Outlook uses Internet Explorer to render HTML messages.

S/MIME security for Microsoft Outlook

S/MIME support is one of Outlook's unheralded important features. (I used to write S/MIME security software, so I admit to being a little biased.) Outlook's support for S/MIME gives you end-to-end protection: messages you create can be signed or encrypted on your computer, and they stay protected as they travel and while they are in the recipient's Exchange mailbox server. Encrypting, signing, de-crypting, and verifying messages is easy, and Outlook gives you a great deal of control over the security settings used with particular certificates. One of the nicest things about Outlook's S/MIME support is that it's completely integrated (through CryptoAPI) with the rest of the system's crypto-graphic functions; if you're using certificates or smart cards for access control or other functions, you will probably be able to use the same certificates with Outlook (as long as the certificates they contain are marked by the issuer as usable with S/MIME).

The reason for the MIME in S/MIME is that the secured content in S/MIME messages is actually made up of Multipurpose Internet Mail Extension (MIME) body parts, as described in Request for Comments (RFC) 1847. That means, for instance, that a plain text message can still contain an attached signature. This is called a clear-signed message, because the message is still readable by clients that don't understand S/MIME signatures. Its opposite, an opaque-signed message, contains the message and signature combined in a single part that cannot be read except by verifying the signature.

The S/MIME version 3 standard, which is what Outlook supports and uses by default, consists of several parts that define various aspects of how clients and servers should create, process, and manipulate secured mail, as follows:

• RFC 3369 describes the Cryptographic Message Syntax (CMS), the format of S/MIME messages. CMS is derived from the older Public Key Cryptography Standards (PKCS) #7 format (RFC 2315), which is why S/MIME-protected messages still appear to have attachments with the .p7m extension that stands for PKCS #7 MIME part. This RFC is interesting primarily because it describes exactly how clients must sign, encrypt, decrypt, and verify messages and how the messages should be structured so that other clients can read them.

• RFC 3370 identifies the algorithms that all S/MIME version 3 software must support to be called S/MIME: Secure Hash Algorithm 1 (SHA-1) and Message Digest-5 (MD5) for hashing, Digital Signature Algorithm (DSA) and RSA for signatures, and RC2 and triple Data Encryption Standard (3DES) for message encryption. Individual implementations are free to add more algorithms to this set, provided they properly identify which algorithms a particular message uses so the recipient can figure it out.

• RFC 2632 describes certificate handling for S/MIME-compatible software. It specifies when and how clients should check for certificate revocation and expiration, how they should handle unknown certificate authority (CA)-specific extensions, and so forth.

• By its own admission, RFC 2633 "defines how to create a MIME body part that has been cryptographically enhanced according to CMS, which is derived from PKCS #7. This memo also defines the application/pkcs7-mime MIME type that can be used to transport those body parts."

As a messaging administrator, you might not ever want to read these RFCs, but they can give you some useful insight into why S/MIME clients act the way they do in some circumstances.

Outlook provides complete S/MIME version 3 support, plus some additional features defined in RFC 2634, including digitally signed message receipts, security labels (like secret or confidential), and a few other features of interest primarily to users of the Defense Messaging System (DMS), which I'm not going to cover in this book.

RPC over HTTPS for Microsoft Outlook

Exchange and Outlook use the remote procedure call (RPC) protocol to communicate. This is fine on local area networks (LANs), but most administrators wisely block RPC traffic at their network perimeter; there is no good reason to allow random Internet hosts to send you RPC packets -- in fact, it's a good idea not to given the past history of vulnerabilities in the Windows RPC stack.

This has posed a conundrum for Exchange administrators: what's the best way to allow remote users access to their mailboxes?

There are several options to choose from: Microsoft Outlook Web Access does a good job overall, but doesn't allow access to stored mail while users are disconnected; POP and IMAP are useful lightweight protocols, but don't offer the full range of Exchange services; virtual private networks (VPNs) allow secure access, but they also allow the remote machine full run of the connected network, which isn't always desirable; and Internet and Security Acceleration (ISA) Server allows publishing RPC-based services while inspecting inbound RPC traffic to ensure its integrity and harmlessness.

In Outlook 2003, Microsoft has added full support for tunneling RPC packets inside of Hypertext Transfer Protocol (or, more precisely, Secure Sockets Layer [SSL]-protected HTTP) packets. With the right configuration, a mobile user can launch Outlook, connect to the corporate network on port 443, and have his or her RPC traffic tunneled from the network entry point to the Exchange server. Users get complete Outlook functionality, and administrators enjoy the protection of blocking plain RPC traffic at the perimeter. However, this magic requires some configuration on the Outlook side, which I discuss later in the chapter.

Microsoft Information Rights Management

There's a popular saying that "information wants to be free."

Although this is in many cases true, the owner of the information might not want it to apply to his or her confidential or proprietary information. Some organizations, like the U.S. government or Apple Computer, deal with this by imposing severe penalties on employees who leak sensitive materials. Most of us don't have that luxury, though, so it would be preferable to have some technological means to give information creators more control over where and how their documents and messages are used.

The Microsoft Office System works with Windows Rights Management Services (RMS) servers (which are built by installing the separate Windows Rights Management Services product on Microsoft Windows Server 2003) to provide a good set of information rights management (IRM) functionality.

The goal behind IRM is simple: people who create documents or messages should be able to specify whether those documents can be modified, forwarded, or copied, and whether (and when) they should expire. The Microsoft Rights Management (RM) implementation uses the XML-based eXtensible rights Markup Language (XrML) to specify what rights the document creator has assigned; then it uses various cryptographic algorithms to securely embed those rights definitions in the document. RMS-protected documents can only be accessed with credentials from an RMS installation. Microsoft has also made available an Internet Explorer plug-in that allows viewing of protected documents from machines that aren't running the Office System.

A complete discussion of how IRM works is outside the purview of this book, because it involves setting up an RMS server and defining IRM usage policies for the organization. In this chapter, I limit my discussion to talking about how to make Outlook work with a functioning RMS server

8 tips in 8 minutes: A Microsoft Outlook email security tutorial

 Home: Introduction
 Tip 1: An overview of Microsoft Outlook email security features
 Tip 2: Customizing the Microsoft Outlook Security Update
 Tip 3: Customizing Outlook email security settings for end users
 Tip 4: Setting up RPC over HTTP for Microsoft Outlook
 Tip 5: Using S/MIME in Microsoft Outlook
 Tip 6: Using Information Rights Management in Microsoft Outlook
 Tip 7: Reaching into Microsoft Outlook's email security toolbox
 Tip 8: Related resources on Microsoft Outlook email security

This chapter is an excerpt from Secure Messaging with Microsoft Exchange 2003 by Paul Robichaux, copyright 2004, published by Microsoft Press. Click here for the chapter download or purchase the book here.