If your job has anything to do with IT security, you're probably familiar with the importance of maintaining the confidentiality, integrity, and availability (CIA) of the systems for which you're responsible. These days, those systems are sure to include mail servers, most often Microsoft Exchange Server systems. Email is a business-critical application, and its security is a must. If you find yourself dealing with Exchange security—whether you're an Exchange administrator or a security pro—you first need to know how to measure the three CIA components as they relate to your messaging environment. After you know how to track the CIA of your Exchange servers, you can find ways to improve it. I'm going to concentrate on how to improve confidentiality and integrity rather than availability, which is a much broader and more-thoroughly documented topic. See the Related Reading box for articles that provide more information about availability and other topics in this article.
Measuring Messaging CIA
Most of the time, messaging administrators measure their systems' health by monitoring performance. Depending on the service level agreements (SLAs) these administrators need to support, they might track a combination of system performance, message-delivery times and latencies, and client performance. But from a security standpoint, measuring messaging CIA is more difficult. Some metrics revolve around simple numeric measures, whereas others are more qualitative. If your organization has both dedicated messaging and security administrators, you can work together to gather these measurements.
To measure confidentiality, you might count or track the number of messages that contain confidential content. Doing so requires you to come up with a list of criteria for determining whether a message is confidential, then implement a means of searching stored or in-transit email to find messages that meet those criteria. In some cases, such a procedure might come perilously close to intrusive network monitoring, but generally you can simply monitor outbound messages at your network gateway. You might also find it helpful to determine which groups in your organization routinely process sensitive data (legal departments come to mind), particularly if those groups must communicate such information to outside parties, in which case they'll likely use email to do so.
Measuring integrity is even trickier than measuring confidentiality. You can track how often errors or corruptions occur in your mailbox and public folder databases, but you also need a way to measure the more critical aspects of message integrity. These aspects include the presence (and nature) of spoofed messages and whether they originate from inside or outside the organization. Look for forged messages, bogus transactions, and the like.
Availability is fairly easy to track. At any given time, users can send, receive, and read messages—or they can't. Consider measuring the number and duration of planned outages (e.g., those scheduled for maintenance), the number and duration of unplanned outages (e.g., those that occur during system failures or disaster-recovery operations), average delivery time for internal messages, average elapsed time for outbound messages (i.e., the length of time it takes for a message to go from the client to the external gateway), and average elapsed time for inbound messages (i.e., the time it takes for a message to go from the gateway to a recipient's mailbox).
Improving Confidentiality
SMTP was never designed to protect message confidentiality. Unfortunately, that means that unless you take protective actions, your message traffic is going to be exposed to anyone who can sniff the packets flowing by. Given that you might not be able to control where your users connect from (e.g., airport Internet kiosks), messages can be more exposed than you suspect. Fortunately you can take several steps to improve confidentiality of transitory and stored messages on both client and server.
First, think about the email that flows to and from your Internet gateway servers. SMTP doesn't include encryption functionality, although the Internet Engineering Task Force (IETF) has defined a set of extensions to the SMTP protocol, enabling the use of the Transport Layer Security (TLS) protocol to encrypt transitory traffic. TLS is a descendant of Secure Sockets Layer (SSL), so if you're familiar with SSL, you already understand the basic concept behind using TLS with SMTP. Either the sending or receiving server can issue the SMTP STARTTLS verb, then the two ends negotiate a mutually acceptable encryption algorithm and key length. You can configure Exchange to require the use of STARTTLS, but if you do so, you won't be able to accept unencrypted mail from servers that don't support TLS with SMTP. To work around this limitation, you can create a separate SMTP connector for the domains that you know support TLS, then set the connector's address space to include those domains. Exchange will route outbound email to those domains over the connector, so those messages will be protected by TLS in transit. Inbound mail and outbound mail that isn't heading to the specified domains will use the default SMTP virtual server, so you won't lose those messages. Also be aware that Exchange Server 2003 and Exchange 2000 Server use SMTP as the core transport protocol for intraorganization mail, so mail flowing between the servers in your organization won't be protected unless you deploy IP Security (IPSec) or Virtual LANs (VLANs) to safeguard internal-server traffic.
Second, consider how users connect to your mail server. If you permit unencrypted POP or IMAP connections, I suggest you stop doing so. Even if you require users to employ the SSL-enabled versions of those protocols (Exchange supports several authentication methods for POP and IMAP), Exchange enables Basic authentication by default, so it's safer and simpler by far just to disable the protocols—even if you don't use them. The same rule applies to Microsoft Outlook Web Access (OWA): Never permit unsecured HTTP connections to OWA. Configuring OWA to force the use of SSL is easy; see the Windows IT Pro article "Maximize OWA 2000," October 2001, InstantDoc ID 22253, for more information.
Third, think about the email that travels between users on your internal network or VPN. By default, this email isn't encrypted, although for users who use Outlook with Exchange, messages might be protected by Outlook's remote procedure call (RPC) encryption (which isn't strong cryptographically but offers some protection). For better security, you can enable the use of IPSec between your LAN clients and Exchange servers. Of course, IPSec is supported only in Windows 2000 and later and requires careful planning and testing, but a wealth of IPSec-related documentation exists on the Security Administrator Web site (http://www.windowsitpro.com/windowssecurity). For users who get email from outside the firewall, you can deploy RPC over HTTP Secure (HTTPS) for Exchange 2003 and Microsoft Office Outlook 2003; doing so provides good security combined with easy access. For increased security, you can pair RPC over HTTPS with the RPC publishing functionality of Microsoft Internet Security and Acceleration (ISA) Server 2004.
Fourth, consider stored email. Exchange imposes access controls to prevent users from reading one another's email, but administrators can circumvent these controls (though not without leaving traces). Obviously, if you don't trust your administrators you have a bigger problem than just email security. Still, in many environments, you'll want to supplement the built-in ACLs by using some type of encryption. In practice, that means you need to use Secure MIME (S/MIME). With S/MIME, the sender encrypts (or digitally signs) a message before it leaves the client machine, and the message remains encrypted or signed until the recipient opens it. S/MIME-protected messages are stored in protected form on the Exchange server, so they can't be decrypted by administrators who have (or gain) access to the message database unless those administrators have the ability to recover the user's private key. You can help prevent that by separating Exchange and public key infrastructure (PKI) administration roles, using hardware tokens or smart cards for private-key storage, and requiring multiple-administrator concurrence for key recovery. S/MIME deployment requires a fair amount of planning and forethought, particularly with respect to how you implement your PKI. Microsoft offers a good guide to S/MIME basics called the Exchange Server 2003 Message Security Guide (http://www.microsoft.com/downloads/details.aspx?familyid=2305405c-faf1-488a-a856-ad467bb59b26n). S/MIME offers other benefits (including nonrepudiation and integrity controls), so it's worth looking into if your security requirements justify it. If you're wondering whether you can put Exchange databases on a volume protected by the Encrypting File System (EFS)—Microsoft doesn't officially support the configuration, and it usually imposes a significant performance penalty.
Improving Integrity
How do you go about improving messaging integrity? Keep in mind that when you're dealing with Exchange, there are two measurements of integrity: Whether your messaging data is free of corruption and whether it's protected against tampering. Both are important.
Maintaining the integrity of your messaging data requires several interlocking types of effort. First and most obviously, you need to keep bad or corrupt data out of your message store. That means finding an appropriate antivirus solution. In most cases, you should scan messages in three places: at the gateway, on your Exchange servers, and on the client desktop machines. Using different scanners in these locations adds protection by raising the chances that at least one of the vendors you've chosen will quickly deploy a signature update for a newly released virus. Depending on your environment, you might also consider using content-scanning or monitoring tools to block certain types of attachments or messages at your perimeter gateway. Doing so can add significant protection against viruses or malicious software (malware) that spread through email.
Next, you need to protect against corruption of the data that does reach your mailbox databases. The number-one cause of data corruption on Exchange servers is disk hardware. Seemingly innocuous problems, such as a loose SCSI cable or a just-outside-of-specification power supply, can cause serious difficulties. When you use an Exchange-aware backup tool to run an online backup, the Exchange Information Store (also known as the IS) checks each database page as the page is written to disk. If the checksum that Exchange computes on the fly doesn't match the checksum stored in the page on disk, Exchange figures that the data written to disk is invalid and logs a -1018 error in the event log. This error is a serious one that means you probably have corrupt data in one or more database pages. Exchange 2003 Service Pack 1 (SP1) includes a feature that can automatically recover from single-bit errors that would otherwise cause a -1018 (such single-bit upsets represent about 40 percent of the volume of -1018 errors observed in the field, so that's valuable protection). Apart from upgrading to Exchange 2003 SP1, the best protection against these events is to perform regular backups, take good care of your storage hardware, and watch the event log for -1018 errors so that you can fix them quickly.
You also need to prevent message data from being tampered with, either in transit or when stored. For stored data, your options are simple: either depend on Windows' ACL mechanisms to keep people out of mail that doesn't belong to them, or digitally sign the data by using S/MIME. In truth, the biggest problem with maintaining the integrity of stored messages involves people who use legitimate access to messages or documents to fiddle with them, and that's primarily a policy problem that doesn't have a technical solution.
If your primary concern is protecting messages from tampering while they're moving through your network, you have two options. One is S/MIME; any alterations to a digitally signed message will cause the message to fail the signature check on the receiving end. The other is IPSec, which protects the network session in which the message is transmitted without altering the message contents. Both of these technologies can improve confidentiality and integrity at the same time.
Secure Exchange
Microsoft has published a series of security operations guides covering Windows 2000, Exchange 2003, and Exchange 2000. These guides, and other security information concerning Exchange, are available online at http://www.microsoft.com/technet/security/prodtech/mailexch/default.mspx. I've written two books about Exchange 2003 and Exchange 2000; you can read more about them at my Web site (http://www.e2ksecurity.com). The Exchange product team maintains a group blog, You Had Me at EHLO (http://blogs.msdn.com/exchange), that often contains useful security information or background material that can help you enhance the CIA of your Exchange systems. If you want to learn more about increasing availability for Exchange, I suggest you visit the Windows IT Pro Exchange & Outlook Administrator Web site at http://www.windowsitpro.com/microsoftexchangeoutlook. I also recommend Jerry Cochran's Mission-Critical Microsoft Exchange 2003 (Digital Press) or its Exchange 2000 counterpart, Mission-Critical Microsoft Exchange 2000 (Digital Press).
