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.