Confidentiality and Privacy

Confidentiality and privacy are the two security domains that users most commonly associate with messaging systems; rightly or wrongly, most e-mail users expect their messages to remain confidential and private. There’s a subtle distinction between these two aspects of security, though, and it takes careful planning to deliver both in your messaging systems.

Confidentiality Versus Privacy

Confidentiality means that information stored or transmitted cannot be read except by the intended recipients. Privacy means that information is not disclosed except under the control, and with the permission of, the owner. For messaging systems, these two attributes quickly become intertwined. Consider these basic scenarios to see the relationship between them, and the effect that various Exchange features have on them.

First, imagine that Alice sends an unencrypted message to Bob. The message could potentially be read by an eavesdropper who monitors the network connection between Alice and her server, between Alice’s server and Bob’s server, or between Bob’s server and his desktop machine. Neither privacy nor confidentiality is preserved in this case, because neither Alice nor Bob can control who else sees the message while it’s in transit or while it’s stored.

Now, what happens if Alice sends a Secure Multipurpose Internet Mail Extensions (S/MIME) encrypted message to Bob? Let’s assume that Exchange’s message tracking feature is turned off so that no record of the message’s transit path is preserved. Because the message is encrypted before it leaves Alice’s machine, the copy stored in her Sent Items folder is also encrypted. Likewise, the copy stored in Bob’s Inbox is encrypted. The encrypted message is transmitted between servers, so confidentiality is preserved. However, an attacker can still see that Alice is sending a message to Bob, and the attacker can read the message headers, so privacy is not completely preserved.

There’s a third scenario, too. Let’s say that Alice doesn’t use S/MIME, but that her server and Bob’s server communicate over a link secured by the Internet Protocol security (IPsec) extensions. In that case, the message isn’t protected between the servers and the users, and it’s stored unencrypted. Confidentiality and privacy are protected only as the message travels between servers.

Note

If these three scenarios seem confusingly similar, don’t worry; we cover them again, with diagrams, in Chapter 2, “Security Protocols and Algorithms,” and Chapter 12, “E-Mail Encryption,” explains how Exchange implements secure end-to-end messaging between Alice and Bob.

The unifying theme in these three scenarios is that the degree of privacy and confidentiality provided varies according to the security mechanisms used. In the next chapter, we examine the security algorithms and protocols commonly used with Exchange to build a foundation for understanding exactly how they protect privacy and confidentiality in messaging systems; for now, though, we can examine some basic protective concepts.

Protecting Confidentiality

As Ben Franklin said, “Three may keep a secret, if two of them are dead.” This is perhaps too drastic an approach for most situations. However, it’s useful to examine how confidentiality is kept in high-value business transactions, like bidding for oil and gas leases or helping two large companies that are merging (think Chrysler- Daimler Benz or Ford-Volvo) pick a new name and create identity materials. The protections used in situations like this include the following:

• Making good trust decisions At some point, you have to trust your administrators; after all, they have administrative privileges on computers to which they have unlimited physical access, so it’s likely that they can read anything they choose to. Depending on the value of the data in your systems, it might be worth the additional expense to do the same kinds of background checks commonly done for senior executive positions.

• Encrypting critical information so that it’s unreadable to unauthorized personnel Encryption is a staple of military and diplomatic communications because messages are often sent using methods that are easily intercepted. It’s also an extremely useful solution for preserving the confidentiality of business communications. Of course, sensitive data has to be decrypted at some point so that humans can work with it, and it remains vulnerable to attack during that time. However, when users encrypt data themselves, they can prevent a dishonest administrator from intercepting the message.

• Imposing strong physical and network security controls Whenever possible, you should prevent eavesdroppers from gaining access to your communications in the first place. This can be as simple as locking your mail servers in a room and tightly restricting access or as complex as using IPsec to encrypt all traffic traversing your network. Physical and network security go hand-in-hand, because an attacker who can gain physical access to a network connection can still be foiled by the right network protections, like restricting which media access control (MAC) addresses ports on a network switch talk to or using the Institute of Electrical and Electronics Engineers (IEEE) 802.1X authentication protocol on wireless connections.

• Applying legal or administrative constraints Nondisclosure agreements might seem useless because they don’t provide any technical protection. However, most people abide by their agreements, especially if there’s a financial penalty associated with breaking them. Administrative policies, like requiring at least two administrators to work together to recover a user’s encryption key (see Chapter 12), can also be useful.

At various points in the remainder of the book, we discuss how each of these approaches can help you protect the confidentiality of message traffic.

Protecting Privacy

In general, privacy is harder to protect than confidentiality because the range of data that users consider private can vary quite widely, and there are many possible routes for disclosure. In addition, users tend to be more sensitive to, but less aware of, threats to their privacy than to the confidentiality of messages they send. Messaging privacy depends on two main items: restricting the availability of data about messages and restricting who can read mail, either while it is in transit or after storage.

Every message contains header data that we normally ignore for confidentiality purposes. Message headers provide lots of useful information about who originated a message, to whom it was sent, the names and Internet Protocol (IP) addresses of internal Simple Mail Transfer Protocol (SMTP) hosts that handled it before it reached the border of your messaging system, and so on. Most of this data is relatively worthless in itself. However, it’s possible to gather a significant amount of information about a target by watching who sends mail to whom. Take a look at the headers you might see on a typical e-mailed long distance bill:

Received: from sun1.fabrikam.com ([192.168. 0.35]) by cyclone. robichaux.local with Microsoft SMTPSVC(5.0 .2195.4905); Sun, 23 Jun 2002 10:34:52 -0500 Received: (from adatum.com@localhost) by sun1.fabrikam.com (8.9.3+Sun/8.9.3) id LAA04470; Sun, 23 Jun 2002 11:41:14 -0400 (EDT) Date: Sun, 23 Jun 2002 11:41:14 -0400 (EDT) Message-Id: <[e-mail]> From: [e-mail] Comment: 06/23/02|NEXTBILL|[e-mail]|2xxxxxxxxx Reply-To: [e-mail] To: [e-mail] Subject: Your Online Statement (2xxxxxxxxx) MIME-Version: 1.0 Content-Type: text/html Return-Path: [e-mail] X-OriginalArrivalTime: 23 Jun 2002 15:34:53.0365 (UTC) FILETIME= [851B7E50:01C21ACB] 

From this, I learn that my provider has outsourced its e-bill service to a third party, what version of the UNIX sendmail program they used to send me the message (8.9.3), the operating system of their mail server (Sun Solaris), and the name and IP address of the server. I also see that the company kindly included my telephone number in the Comment and Subject fields. So much for my privacy! Some of this information would be extremely useful to an attacker; besides that, passively watching message headers go by could tell me quite a bit about what users on my server (or my target’s server) are doing and who they’re doing it with. Law enforcement does this kind of traffic analysis all the time with telephone systems, because they don’t need a court order to do so; the FBI and other agencies have automated systems that can perform e-mail-based traffic analysis pursuant to lawfully issued search warrants. The good news is that you can block exposure of some of this data, as you’ll see in Chapter 8, “SMTP Relaying and Spam Control.”

The second privacy factor is potentially more troublesome: most users don’t worry about confidentiality of messages they send through their servers as much as they do their privacy. Users tend to assume that someone is watching out for the organization’s interests by protecting confidentiality, but they tend not to assume that their mail is being, or might be, monitored by the same someone. The biggest threat to e-mail privacy isn’t some shadowy attacker lurking on the Internet; it’s the administrators of the messaging system! Exchange offers good default protections that keep administrators out of mail that isn’t theirs, but like most locks, these protections keep honest folks honest. By the nature of an administrator’s privilege level, he or she can often circumvent these protections (although not without leaving tell-tale traces).

Of course, there will be times when through no fault of your own you’ll read someone else’s mail. At most organizations, someone has to read messages sent to the Postmaster mailbox, and these messages often include misdirected or misaddressed mail that communicants would consider private. There are also a number of circumstances that might require administrators to monitor a user’s mail.

The best defense for users’ privacy is to make them explicitly aware that the owner of the server (for example, the company or organization that provides their messaging service) might read their mail if necessary. This awareness is often driven by an acceptable use policy of some sort. The policy details should be specific to your organization, and you should have your human resources department help you formulate the policy to make sure it is legally correct. In conjunction with that policy, you should educate your users about how to protect their messaging privacy with technical tools like Exchange’s advanced security module, which uses S/MIME to protect messages against eavesdropping and tampering.