NIST SP 800-45 Version 2 日本語訳

Special Publication 800-45 Version 2

Miles Tracy Wayne Jansen Karen Scarfone Jason Butterfield

NIST Special Publication 800-45 Version 2

原本PDFの抜粋画像

C O M P U T E R S E C U R I T Y

原本PDFの抜粋画像

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations.

National Institute of Standards and Technology Special Publication 800-45 Version 2 Natl. Inst. Stand. Technol. Spec. Publ. 800-45 Version 2, 139 pages (Feb. 2007)

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

原本PDFの抜粋画像

Acknowledgements, Version 2

The authors, Wayne Jansen and Karen Scarfone of NIST, Miles Tracy of Federal Reserve Information Technology, and Jason Butterfield of Booz Allen Hamilton, wish to express their thanks to colleagues at both organizations who reviewed drafts of this document. In particular, their appreciation goes to Linda Antil, Rick Ayers, Bill Burr, Tim Grance, and Tim Polk from NIST for their research, technical support, and written contributions to this version of the document. The authors would also like to express their thanks to all those who contributed input during the public comment period and who assisted with our internal review process.

Acknowledgements, Original Version

The authors, Wayne Jansen of NIST and Scott Bisker and Miles Tracy of Booz Allen Hamilton (BAH), wish to express their thanks to colleagues at both organizations who reviewed drafts of this document. In particular, their appreciation goes to John Wack, Murugiah Souppaya, and Tim Grance from NIST, and Steve Allison, Alexis Feringa, Jonathan Holleran, Kevin Kuhlkin, and Mark McLarnon from BAH, for their research, technical support, and written contributions to this document. The authors would also like to express their thanks to all those who contributed input during the public comment period and who assisted with our internal review process.

This page has been left blank intentionally.

Executive Summary

Electronic mail (email) is perhaps the most popularly used system for exchanging business information over the Internet (or any other computer network). At the most basic level, the email process can be divided into two principal components: (1) mail servers, which are hosts that deliver, forward, and store email; and (2) mail clients, which interface with users and allow users to read, compose, send, and store email. This document addresses the security issues of mail servers and mail clients, including Web-based access to mail.

Mail servers and user workstations running mail clients are frequently targeted by attackers. Because the computing and networking technologies that underlie email are ubiquitous and well-understood by many, attackers are able to develop attack methods to exploit security weaknesses. Mail servers are also targeted because they (and public Web servers) must communicate to some degree with untrusted third parties. Additionally, mail clients have been targeted as an effective means of inserting malware into machines and of propagating this code to other machines. As a result, mail servers, mail clients, and the network infrastructure that supports them must be protected. Examples of email security issues include the following:

This document is intended to assist organizations in installing, configuring, and maintaining secure mail servers and mail clients. More specifically, this document discusses the following items in detail:

The following key guidelines are recommended to Federal departments and agencies for maintaining a secure mail server.

Organizations should carefully plan and address the security aspects of the deployment of a mail server.

As it is much more difficult to address security once deployment and implementation have occurred, security should be considered from the initial planning stage. Organizations are more likely to make decisions about configuring computers appropriately and consistently when they develop and use a detailed, well-designed deployment plan. Developing such a plan will support mail server administrators in making the inevitable tradeoff decisions between usability, performance, and risk.

Organizations often fail to take into consideration the human resource requirements for both deployment and operational phases of the mail server and supporting infrastructure. Organizations should address the following points in a deployment plan:

Organizations should implement appropriate security management practices and controls when maintaining and operating a secure mail server.

Appropriate management practices are essential to operating and maintaining a secure mail server. Security practices entail the identification of an organization’s information system assets and the development, documentation, and implementation of policies, standards, procedures, and guidelines that help to ensure the confidentiality, integrity, and availability of information system resources.

To ensure the security of a mail server and the supporting network infrastructure, the following practices should be implemented:

Organizations should ensure that the mail server operating system is deployed, configured, and managed to meet the security requirements of the organization.

The first step in securing a mail server is securing the underlying operating system. Most commonly available mail servers operate on a general-purpose operating system. Many security issues can be avoided if the operating systems underlying mail servers are configured appropriately. Default hardware and software configurations are typically set by manufacturers to emphasize features, functions, and ease of use at the expense of security. Because manufacturers are not aware of each organization’s security needs, each mail server administrator must configure new servers to reflect their organization’s security requirements and reconfigure them as those requirements change. Using security configuration guides or checklists can assist administrators in securing systems consistently and efficiently. Securing an operating system would generally include the following steps:

Organizations should ensure that the mail server application is deployed, configured, and managed to meet the security requirements of the organization.

In many respects, the secure installation and configuration of the mail server application mirrors the operating system process discussed above. The overarching principle, as before, is to install the minimal mail server services required and eliminate any known vulnerabilities through patches or upgrades. If the installation program installs any unnecessary applications, services, or scripts, they should be removed immediately after the installation process completes. Securing the mail server application would generally include the following steps:

Organizations should consider the implementation of cryptographic technologies to protect user authentication and email data.

Most standard email protocols default to unencrypted user authentication and send email data in the clear (unencrypted). Sending this data in the clear may allow an attacker to easily compromise a user account and/or intercept and alter unencrypted emails. At a minimum, most organizations should encrypt the user authentication session even if they do not encrypt the email data itself. Encrypted user authentication is now supported by most standard and proprietary mailbox protocols.

The issues involved with encrypted and signed email data are more complex. Encrypting and signing email places a greater load on the organization’s network infrastructure, may complicate malware scanning and email content filtering, and often requires significant administrative overhead. However, for many organizations the benefits of email encryption and signatures will outweigh the costs.

Organizations should employ their network infrastructure to protect their mail server(s).

The network infrastructure (e.g., firewalls, routers, intrusion detection systems) that supports the mail server plays a critical role in the security of the mail server. In most configurations, the network infrastructure will be the first line of defense between the Internet and a mail server. Network design alone, however, cannot protect a mail server. The frequency, sophistication, and variety of mail server attacks perpetrated today support the idea that mail server security must be implemented through layered and diverse protection mechanisms.

Organizations should ensure that the mail clients are deployed, configured, and used properly to meet the security requirements of the organization.

In many respects, the client side of email represents a greater risk to security than the mail server. Numerous issues need to be carefully considered and addressed to provide an appropriate level of security for mail clients. Securely installing, configuring, and using mail client applications would generally include the following steps:

Maintaining the security of a mail server is an ongoing process.

Maintaining a secure mail server requires constant effort, resources, and vigilance from an organization. Securely administering a mail server on a daily basis is an essential aspect of mail server security. Maintaining the security of a mail server will usually involve the following steps:

This page has been left blank intentionally.

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets, but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.

The purpose of the Guidelines on Electronic Mail Security is to recommend security practices for designing, implementing, and operating email systems on public and private networks. While intended as recommended guidance for Federal departments and agencies, it may be used in the private sector on a voluntary basis.

Mail servers are frequently targeted by attackers. Various types of email content and attachments have also proven to be effective in introducing viruses and other malware into networks through mail clients. Email is extensively used as a vector to deliver attacks that exploit vulnerabilities in users’ workstations or use social engineering methods to trick users. These attacks often lead to the compromise of the user workstation or the release of sensitive information even when the email client is securely configured. This document may be used by organizations interested in enhancing security on existing and future mail systems to reduce the number and frequency of email-related security incidents. This document presents generic principles that apply to all systems.

This guideline does not cover the following aspects relating to securing a mail server:

The document, while technical in nature, provides the background information to help readers understand the topics that are discussed. The intended audience for this document includes the following:

The practices recommended in this document are designed to help mitigate the risks associated with email and other known security problems. They build on and assume the implementation of practices described in other NIST guidelines listed in Appendix E.

The remainder of this document is organized into the following eight major sections:

The document also contains several appendices with supporting material:

As of January 2007, the estimated number of Internet users worldwide exceeded one billion.¹ Most of these users have electronic mail (email) accounts on one or more mail systems, which is a huge leap from its inception in 1971, when Ray Tomlinson, a Department of Defense (DoD) researcher, sent the first ARPANET email message to himself. The ARPANET, precursor to the Internet, was a United States (U.S.) Advanced Research Project Agency (ARPA) project intended to develop a set of communications protocols to transparently connect computing resources in various geographical locations. Messaging applications were available on ARPANET systems; however, they could only be used for sending messages to users with local system accounts. Tomlinson modified the existing messaging system so that users could send messages to users on other ARPANET connected systems. After Tomlinson’s modification was available to other researchers, email quickly became the most heavily used application on the ARPANET.

As the ARPANET evolved into the Internet, email remained one of the most heavily used applications for personal and business users. Since the ARPANET was initially a small and trusted community, there was little need for security. The growth in the popularity of the Internet greatly increased the need for security. Unfortunately, the needed security was lacking because early email standards and implementations placed little emphasis on security. Maintaining compatibility with these standards presents a great challenge in securing email today.

An understanding of how email messages are composed, delivered, and stored is helpful in understanding email security. For most email users, once a message is composed and sent, it leaves the computer and magically appears in the intended recipient’s inbox. This may seem simple but the handling and delivery of an email message can be as complex as that involving physical mail, with processing and sorting occurring at several intermediary locations before arriving at the final destination.

The process starts with message composition. The most basic mail clients typically ask the user to provide the following: subject line, message content, and intended recipients. When these fields are completed and the user sends the message, the message is transformed into a specific standard format specified by Request for Comments (RFC) 2822, Internet Message Format. At the most basic level, the two primary message sections are the header and the body. The header section contains the vital information about the message including origination date, sender, recipient(s), delivery path, subject, and format information. The body of the message contains the actual content of the message.²

Once the message is translated into an RFC 2822 formatted message, it can be transmitted. Using a network connection, the mail client, referred to as a mail user agent (MUA), connects to a mail transfer agent (MTA) operating on the mail server. After initiating communication, the mail client provides the sender’s identity to the server. Next, using the mail server commands, the client tells the server who the intended recipients are. Although the message contains a list of intended recipients, the mail server does not examine the message for this information. Only after the complete recipient list is sent to the server does the client supply the message. From this point, message delivery is under control of the mail server.

Once the mail server is processing the message, several events occur: recipient server identification, connection establishment, and message transmission. Using Domain Name System (DNS) services, the sender’s mail server determines the mail server(s) for the recipient(s). Then, the server opens up a connection(s) to the recipient mail server(s) and sends the message employing a process similar to that used by the originating client. At this point, one of two events could occur. If the sender’s and recipient’s mailboxes are located on the same mail server, the message is delivered using a local delivery agent (LDA). If the sender’s and recipient’s mailboxes are located on different mail servers, the send process is repeated from one MTA to another until the message reaches the recipient’s mailbox.

When the LDA has control of the message, a number of possible events may occur. Depending on the configuration, the LDA could deliver the message or process the message based on a predefined message filter before delivery (filtering can be based on a number of message properties and is discussed in detail in Section 6.2.2). Once the message is delivered, it is placed in the recipient’s mailbox where it is stored until the recipient performs some action on it (e.g., read, delete) using the MUA. Figure 2.1 illustrates the flow of the message through the various mail components discussed previously. This is the general process of sending an email.

Figure 2.1: Example of Message Flow

RFC 2822 provides a standard for transmitting messages containing textual content; however, it does not address messages that contain attachments, such as a mail message with a word processing document or photo included. Making use of the headers in an RFC 2822 message, the Multipurpose Internet Mail Extensions (MIME) provide almost endless possibilities to describe the structure of rich message content. MIME uses the convention of content-type/subtype pairs to specify the native representation or encoding of associated data. Examples of content types include the following:

The current MIME standards include five parts: RFCs 2045, 2046, 2047, 4289 (which replaced 2048), and 2049 (see Appendix B). They address message body format, media types, non-American Standard Code for Information Interchange (non-ASCII) message header extensions, registration procedures, and conformance criteria, respectively. With this added functionality, email features such as message attachments and inline hypertext markup language (HTML) are possible. Although MIME extensions allow for binary message content, such content is incorporated into an RFC 2822 message using Base64 encoding, which provides a textual representation of binary data.³

To ensure reliability and interoperability among various mail applications, mail transport standards were established. In the simplest scenario, an email message is sent from one local user to another local user. For this case, an LDA is responsible for placing the message in the appropriate mailbox. When a message is sent to non-local recipients, an MTA is needed to send the message from the local mail server to the remote mail server. Depending on the type of systems involved, different MTAs may be used, which in turn may support different implementations of a particular message transfer protocol or more than one distinct transfer protocol.

The most common MTA transfer protocol is the Simple Mail Transfer Protocol (SMTP). SMTP is the de-facto Internet standard for sending email messages. Thus, any Internet messaging system must support SMTP to facilitate communication with other email messaging applications. Other messaging systems exist that use different MTA transfer protocols between similar or clustered messaging systems. For the most part, these MTAs are proprietary and work only with specific systems. Sections 2.3.1 and 2.3.2 provide background information on SMTP and SMTP extensions, while Section 2.3.3 discusses proprietary MTAs.

Jon Postel of the University of Southern California developed SMTP in August 1982. As RFC 821, Simple Mail Transfer Protocol, states, “SMTP was developed to ensure a more reliable and efficient way to transport messages.” At the most basic level, SMTP is a minimal language that defines a communications protocol for delivering email messages. Figure 2.2 lists the SMTP commands and syntax as defined in RFC 2821, Simple Mail Transfer Protocol, which replaced RFC 821.

Figure 2.2: SMTP Commands

When a user sends an email, the client contacts its SMTP server and conducts a “conversation” using the SMTP language. A MUA is typically part of the mail client application (e.g., Outlook, Eudora). If an MUA is unavailable, email messages can be sent using a Telnet client connected to the SMTP service. Figure 2.3 depicts a sample SMTP conversation using Telnet. The Telnet and SMTP commands entered by the user for this session are shown in bold. During a manual SMTP Telnet session, the HELP command can be used to determine which of the SMTP commands are enabled on the server.

Figure 2.3: Sample SMTP Conversation

As the number of email users grew, additional functionality was sought in mail clients and SMTP servers. For SMTP servers to support this additional functionality, extensions were added to SMTP. In 1993, RFC 1425 introduced the concept of SMTP service extensions. Subsequently, RFC 1425 was superseded by RFC 1651 in 1994, RFC 1869 in 1995, and RFC 2821 in 2001. These RFCs added three pieces to the SMTP framework:

To be compatible with older SMTP servers, there needed to be a method to allow the mail client application to determine whether the server supported extensions. This was accomplished through the “enhanced hello” (EHLO) command. When connecting to a server, a mail client could issue the EHLO command. If the server supported SMTP extensions, it would give a successful response and list the extensions that were supported. If the server did not support SMTP extensions, it would issue a command failure response prompting the MUA to respond with the standard HELO command. Servers that support SMTP extensions, also known as Extended SMTP (ESMTP), typically respond with ESMTP in their banner.⁴ Figure 2.4 is an excerpt from an ESMTP server transaction involving the EHLO command.

Figure 2.4: Sample ESMTP Conversation

As depicted in Figure 2.4, the sample server supports only one extension – SIZE. Numerous extensions are supported by a variety of SMTP servers. Table 2.1 lists some of the more common SMTP extensions and their associated RFCs. In particular, RFC 2554 specifies a new command and protocol for identifying and authenticating a user. The default configuration of most mail servers typically does not have authenticated relay enabled.

Table 2.1: SMTP Extensions

As mentioned previously, some messaging systems use MTAs that do not support either SMTP or ESMTP. These types of MTAs are designed to work within a closed messaging environment. Many large-scale government, academic, and private organizations have messaging systems that use these types of MTAs. However, these organizations still rely on SMTP or ESMTP-capable MTAs for communicating with external messaging systems. Some examples of messaging systems that use proprietary protocols are MTAs for Lotus Notes and Microsoft Exchange.⁵ Discussion on the benefits and disadvantages of using MTAs that support only proprietary message transfer protocols is outside the scope of this document.

Once a message is delivered by the LDA, users need to access the mail server to retrieve the message. Mail clients (MUAs) are used to access the mail server and retrieve email messages. Several methods exist for users to access their mailboxes, the simplest being direct access.

The simplest scenario for a messaging system would be one in which all users have direct access to their mailbox (common on hosts employing the Unix operating system). For each account that exists on the system, there is a corresponding mailbox in that user’s home directory. When messages are received, users can use command line-based mail programs, such as mail or pine, to directly access the mailbox. Although this method is straightforward, it requires all users accessing the mail server to receive messages to have a user account and a command-line interface on the host operating system.

Allowing users, particularly external users, to have access to a command-line interface is a significant security risk. To mitigate this risk, mailbox access protocols were devised. The two most widely supported mailbox access protocols are Post Office Protocol (POP) and Internet Message Access Protocol (IMAP). They are covered in Sections 2.4.1 and 2.4.2, respectively. As with message transfer protocols for MTAs, other proprietary mailbox access protocols exist that are regularly used by commercial software manufacturers; proprietary protocols are discussed in Section 2.4.3. It is important to understand that POP, IMAP, and indeed most proprietary protocols in their default configuration use cleartext passwords for authentication, which can be intercepted by other hosts attached to the network. Section 2.4.4 briefly discusses the protocols used for Web-based mail access.

POP was first developed in 1984. At its core, POP was nothing more than a way to copy messages from the mail server mailbox to the mail client. It worked much like a traditional post office mailbox. The mail client opens a connection to the mail server mailbox, downloads the email messages, and then closes the connection. As described in RFC 918, only nine commands were originally available for POP (see “Basic Commands” in Figure 2.5).

Figure 2.5: POP3 Commands

Since 1984, POP has gone through several changes and is now in its third iteration as defined in RFC 1939. The basic command set is very similar to the command set of 1984; however, POP version 3 offers a few new optional commands, listed in Figure 2.5. From a security standpoint, the addition of the APOP was important, since it avoids transmitting a user’s password in the clear. Instead, a challenge/response mechanism is used, by which the client responds with a cryptographic hash of the combined challenge sent from the server and the user's password, for verification by a POP mail server performing the same operation for the user in question.

RFC 2449, POP3 Extension Mechanism, defines an extension to POP3 that allows clients to discover additional information about POP3 servers, such as which extensions and optional commands they support. Figure 2.5 shows the command added to POP3 by the extension.

The POP mailbox access standard has some significant limitations. Typically, when users retrieve their email, copies of the messages that reside on the server are deleted. This means that the user has the sole responsibility of maintaining message archives. Although this may be acceptable for personal accounts, it is generally unacceptable for most commercial or governmental organizations that have to meet certain legal requirements. In addition, if a user employs several workstations for retrieving email, the messages are dispersed on multiple hosts. POP may be configured so that the original messages are not deleted from the server. However, the user will either have to download all of the messages previously viewed as well as the new messages when accessing a mailbox from another host, or have to set up a retention period after which messages are automatically deleted from the server.

To address the above-mentioned issues with POP, IMAP was developed in 1988. The IMAP protocol was developed as a functional superset of the POP version 2 protocol. At the most basic level, IMAP was designed so user mailboxes could be centrally located and accessed from multiple mail clients or MUAs.

Initially, IMAP offered very little functionality beyond that of POP, but since 1988, it has evolved into a robust mailbox access protocol. The current edition of the IMAP standard is RFC 3501: Internet Message Access Protocol – Version 4, Revision 1 (4rev1). Because IMAP 4rev1 supports many different features, it has a much wider command set than that of POP. Figure 2.6 provides a list of IMAP 4rev1 commands. Additionally, with the CAPABILITY command, the IMAP server can be queried to determine if other IMAP extensions are supported.

Figure 2.6: IMAP 4 Revision 1 Commands

Table 2.2 lists the associated RFCs for the noted IMAP extensions. IMAP has been extended with a challenge/response mechanism comparable to APOP, which is called the Challenge-Response Authentication Mechanism (CRAM). CRAM requires the client to make note of the challenge data sent by the server and respond with a string consisting of the user’s name, a space, and a digest computed by applying a keyed hash algorithm⁶ against the timestamp sent with the challenge, using a shared secret as the key.

Table 2.2: IMAP Extension RFC Documents

Proprietary mailbox access protocols are designed to work within closed messaging environments. Microsoft Exchange and Lotus Notes are examples of messaging systems that use proprietary mailbox access protocols. These proprietary protocols offer additional functionality when used with their associated clients. Nearly all proprietary messaging systems support standard protocols, including SMTP, POP, and IMAP, in order to interoperate with other types of MTAs and MUAs. Organizations must decide for themselves whether it is appropriate to support proprietary protocols in their mail clients and servers. As mentioned earlier, regardless of whether they are standard or proprietary, most access protocols default to weak authentication mechanisms (unencrypted authentication information). Therefore, organizations need to configure the access protocols to support stronger forms of authentication.

Web-based mail applications, also known as Webmail applications, are increasingly being used as a means of email service delivery, because Web browsers that enable access to the client are available on nearly every Internet-enabled device. A user simply runs a Web browser and connects to a Web site that hosts the Web-based mail application. The connection is made using either Hypertext Transfer Protocol (HTTP) or HTTP over Transport Layer Security (TLS), also known as HTTPS. HTTPS encrypts the communications, which protects both authentication information and email message content. HTTP alone does not offer any protection, so organizations should consider using HTTPS for Web-based mail application communications.

Web-based mail applications incorporate much of the mail-handling functionality of traditional mail clients and communicate with their associated mail servers using the same mailbox access protocols described earlier—SMTP, POP, and IMAP, as well as proprietary protocols. The mailbox access protocols are used between the Web servers and mail servers only; the protocols are not carried between the Web servers and Web browsers.

This page has been left blank intentionally.

Organizations often want to protect the confidentiality and integrity of some of their email messages, such as preventing the exposure of personally identifiable information in an email attachment. Email messages can be protected by using cryptography in various ways, such as the following:

The first two methods, message signing and message body encryption, are often used together. For example, if a message needs to be encrypted to protect its confidentiality, it is usually digitally signed as well, so that the recipient can ensure the integrity of the message and verify the identity of the signer. Messages that are digitally signed are usually not encrypted if the confidentiality of the contents does not need to be protected.

The third cryptography method listed above, encrypting the transmissions between mail servers, is typically applicable only when two organizations want to protect emails regularly sent between them. For example, the organizations could establish a virtual private network (VPN) to encrypt the communications between their mail servers over the Internet. Unlike methods that can only encrypt a message body, a VPN can encrypt entire messages, including email header information such as senders, recipients, and subjects. In some cases, organizations may need to protect header information. However, a VPN solution alone cannot provide a message signing mechanism, nor can it provide protection for email messages along the entire route from sender to recipient.⁷

Because most email messages are protected individually by digitally signing and optionally encrypting them, this section focuses on the use of these methods. The most widely used standards for signing messages and encrypting message bodies are Open Pretty Good Privacy (OpenPGP) and Secure/Multipurpose Internet Mail Extensions (S/MIME).⁸ Both are based in part on the concept of public key cryptography, which involves a user having a pair of related keys: a public key that anyone can hold, and a private key that is held exclusively by its owner. Because public key cryptography is so computationally intense, it is used sparingly in email security; symmetric key cryptography, which is much more efficient, is much more heavily used.

Symmetric key cryptography requires a single key to be shared between communicating parties, the sender and recipient of an email message. The process involves the sender generating a random key and encrypting the message with it using a symmetric key encryption algorithm. The sender then encrypts the symmetric key with a corresponding public key encryption algorithm using the recipient’s public key, and sends both the encrypted message and encrypted symmetric key together to the recipient. This hybrid process uses public key encryption only to encrypt the symmetric key. Because only the intended message recipient holds the private key that is needed to recover the symmetric key, no other party can decrypt the message and read it. Digital signature techniques rely on the creation of a digest or fingerprint of the information (i.e., the message being sent) using a cryptographic hash, which can be signed more efficiently than the entire message.⁹

Federal organizations are required to use cryptographic algorithms that have been approved by the Federal government.¹⁰ Other organizations may wish to choose encryption schemes approved by the Federal government because these are well-tested and secure. Table 3.1 presents general recommendations for selecting cryptographic suites for protecting email messages.

Table 3.1: Recommended Cipher Suites

OpenPGP is a protocol for encrypting and signing messages and for creating certificates using public key cryptography. It is based on an earlier protocol, PGP, which was created by Phil Zimmerman and implemented as a product first released in June 1991. The initial PGP protocol was proprietary and used some encryption algorithms with intellectual property restrictions. In 1996, version 5.x of PGP was defined in IETF RFC 1991, PGP Message Exchange Formats. Subsequently, OpenPGP was developed as a new standard protocol based on PGP version 5.x. OpenPGP is defined in RFC 2440, OpenPGP Message Format, and RFC 3156, MIME Security with OpenPGP.¹⁴

Many free and commercial products that use the OpenPGP standard are currently available. The software can be downloaded or purchased from a variety of Web sites.¹⁵ Some OpenPGP-based products fully support the cryptographic algorithms recommended to the Federal government by NIST in FIPS PUB 140-2 and other publications, including 3DES and AES for data encryption, Digital Signature Algorithm (DSA)¹⁶ and RSA for digital signatures, and SHA for hashing.¹⁷ Some implementations of OpenPGP support other encryption schemes not addressed here.

Although certain aspects of OpenPGP do use public key cryptography, such as digitally signed message digests, the actual encryption of the message body is performed with a symmetric key algorithm, as outlined earlier. The following is a brief description of signing and encrypting a message with OpenPGP (some steps may occur in a different order):

The recipient reverses the steps to recover the session key, decrypt the message, and verify the signature. Popular mail clients such as Mozilla Thunderbird, Apple Mail, Eudora, and Microsoft Outlook require the installation of plug-ins to enable the user to send and receive OpenPGP-encrypted messages. The OpenPGP distribution sites listed earlier in this section contain instructions on how to use OpenPGP with various mail client applications.

There are also security gateway servers available that can use OpenPGP to encrypt, decrypt, sign, and verify signatures on email messages on behalf of users. If two organizations exchanging emails both use compatible security gateway servers, then the use of OpenPGP is essentially transparent to users. If only one organization has such a gateway, it can still be used to protect messages, but it is not a transparent process at all to users at other organizations. If a gateway user sends an email to a recipient at another organization, that recipient will actually receive a notification email from the gateway that explains how to retrieve the protected email, typically through an SSL-encrypted HTTP session. Some gateways can also perform these functions for emails sent to lists of users. For example, a single user could send an encrypted and signed email to a mailing list address. The gateway would decrypt the email and re-encrypt it for all the individual recipients of the mailing list. Each recipient can then decrypt the email and verify the original signature.

S/MIME, which was originally proposed in 1995 by RSA Data Security, Inc., is based on their proprietary (although widely supported) Public Key Cryptography Standard (PKCS) #7 for data format of encrypted messages, and the X.509 version 3 standard for digital certificates.¹⁸ S/MIME version 2 achieved wide adoption throughout the Internet mail industry. Although it is not a recognized IETF standard, it is specified by informational RFCs 2311, 2312, 2313, 2314, 2315, and 2268.

S/MIME version 3 was developed by the IETF S/MIME Working Group, which now coordinates all development of the S/MIME standard,¹⁹ and adopted as an IETF standard in July 1999. S/MIME version 3 is specified by the following RFCs:

The most significant feature of S/MIME is its built-in and nearly “automatic” nature. Because of heavy industry involvement from manufacturers, S/MIME functionality exists with default installations of common mail clients such as Mozilla and Outlook Express.

The actual process by which S/MIME-enabled mail clients send messages is similar to that of OpenPGP.²⁰ S/MIME version 3.1 supports two symmetric key encryption algorithms recommended by FIPS PUB 140-2: AES, which is recommended but optional for compliant implementations to support, and 3DES, which is mandatory for implementations to support. Organizations using S/MIME to protect emails should use AES or 3DES (preferably AES, which is considered a stronger algorithm than 3DES).

As with OpenPGP, there are security gateway servers available that can use S/MIME to encrypt, decrypt, sign, and verify signatures on email messages on behalf of users. These gateways are very similar to those described in Section 3.1, and many of the gateways actually support both OpenPGP and S/MIME.

Both OpenPGP and S/MIME use digital certificates to manage keys. A digital certificate identifies the entity (e.g., a user) that was issued the certificate, the public key of the entity’s public key pair, and other information, such as the date of expiration, signed by some trusted party. However, differences exist in the key management models used by OpenPGP and S/MIME to establish trust using digital certificates.

The default and traditional model that OpenPGP uses for key management is referred to as the “web of trust,” which has no central key issuing or approving authority. The web of trust relies on the personal decisions of users for management and control. For example, if Alice trusts Bob and Carol trusts Alice, then Carol should trust Bob’s emails. While this is suitable for individual users and very small organizations, the overhead of such a system is unworkable in most medium to large organizations. Some organizations deploy keyservers that users can access to get others’ keys and store their own keys. Although this does promote scalability, the process is typically controlled mainly by individual users, and organizations are often not comfortable trusting keyservers to provide sufficient assurance of user identity.

Conversely, S/MIME works on a classical, more hierarchical arrangement of authorities that the organization chooses to trust. Typically, there is a master registration and approving authority, referred to as a root Certificate Authority (CA), that issues a public key certificate for itself and any subordinate CAs it sanctions. Subordinate CAs normally issue certificates to users and also to any other subordinate CAs that they in turn sanction, forming a hierarchy. Such a public key infrastructure can be used to establish a chain of trust between any two users holding valid certificates issued under it. By default, S/MIME-enabled mail clients depend on the trust of their immediate master CA when processing S/MIME transactions. This authority can be either a third-party CA²¹ or a CA that is controlled by the organization issuing the certificates.

Having an organization exchange OpenPGP or S/MIME-protected emails with other organizations is usually extremely complicated, especially when attempting to maintain transparency for the users. The biggest challenges are key exchange and establishing trust relationships between the organizations. Organizations can connect their PKIs or use a mutually trusted third-party PKI, but in either case there are often technical and legal or regulatory challenges. Also, support for OpenPGP and S/MIME varies considerably depending on the mail client in use.

Third-party services are available that allow organizations to exchange encrypted email without having to establish trust relationships or worry about mail application compatibility. However, the use of such services necessitates placing sensitive messages on third-party servers, which itself can be a security concern. The use of mail encryption gateways between two organizations typically has lesser key management concerns because the keys are maintained on the gateways and a trust relationship already exists between the gateways.

Work is currently underway on a possible method of reducing key management concerns for email signing and encryption. Identity-based encryption (IBE) is a form of public key encryption that allows any string to be used as a public key. By using email addresses as public keys, IBE could simplify key management, making it much easier for senders to protect the emails that they send. However, there are serious barriers to adoption of IBE, including no open standards for IBE and no FIPS-approved IBE products. Informational Internet-Drafts have been started that propose how IBE could be performed using S/MIME.

Although encrypting email provides additional security, it does come at a cost, so organizations should carefully weigh the issues associated with encrypting email messages:

The most critical aspect of deploying a secure mail server is careful planning before installation, configuration, and deployment. Careful planning will ensure that the mail server is as secure as possible and in compliance with all relative organizational policies. Many mail server security and performance problems can be traced back to a lack of planning or management controls. The importance of management controls is difficult to overstate. In many organizations, the information technology support structure is highly fragmented. This fragmentation leads to inconsistencies, and these inconsistencies can lead to security vulnerabilities.

Security of the mail server should be considered from the initial planning stage at the beginning of the systems development life cycle to maximize security and minimize costs. It is much more difficult and expensive to address security once implementation and deployment have occurred. Organizations are more likely to make decisions about configuring hosts appropriately and consistently when they begin by developing and using a detailed, well-designed deployment plan. Developing such a plan enables organizations to make informed tradeoff decisions between usability and performance, and risk. A deployment plan allows organizations to maintain secure configurations and aids in identifying security vulnerabilities, which often manifest themselves as deviations from the plan.

In the planning stages of a mail server, the following items should be considered [Alle00]:

The choice of mail server application may determine the choice of operating system. However, to the degree possible, mail server administrators should choose an operating system that provides the following [Alle00]:

In addition, organizations should consider the availability of trained, experienced staff to administer the server and server products. Many organizations have learned the difficult lesson that a capable and experienced administrator for one type of operating environment is not automatically as effective for another.

Given the sensitive nature of the mail server, it is critical that it is located in an area that provides a secure physical environment. When planning the location of the mail server, the following items should be considered:

Because mail server security is tightly intertwined with the organization’s general information system security posture, a number of IT and system security staff may be interested in mail server planning, implementation, and administration. This section provides a list of those roles and identifies their responsibilities as related to mail server security. These roles may vary with the organization, however, and not all organizations will have the identical roles described here.

The Senior IT Management/CIO ensures that the organization’s security posture is adequate. The Senior IT Management provides direction and advisory services for the protection of information systems for the entire organization. The Senior IT Management/CIO is responsible for the following activities that are associated with mail servers:

The Information Systems Security Program Managers (ISSPM) oversee the implementation of and compliance with the standards, rules, and regulations specified in the organization’s security policy. The ISSPMs are responsible for the following activities associated with mail servers:

Information Systems Security Officers (ISSO) are responsible for overseeing all aspects of information security within a specific organizational entity. They ensure that the organization’s information security practices comply with organizational and departmental policies, standards, and procedures. ISSOs are responsible for the following activities associated with mail servers:

Mail server administrators are system architects responsible for the overall design, implementation, and maintenance of a mail server. Network administrators are responsible for the overall design, implementation, and maintenance of a network. On a daily basis, mail server and network administrators contend with the security requirements of the specific system(s) for which they are responsible. Security issues and solutions can originate from either outside (e.g., security patches and fixes from the manufacturer or computer security incident response teams) or within the organization (e.g., the security office). The administrators are responsible for the following activities associated with mail servers:

Appropriate management practices are critical to operating and maintaining a secure mail server. Security practices entail the identification of an organization’s information system assets and the development, documentation, and implementation of policies, standards, procedures, and guidelines that ensure confidentiality, integrity, and availability of information system resources.

To ensure the security of a mail server and the supporting network infrastructure, organizations should implement the following practices:

The objective of system security planning is to improve protection of information system resources.²⁴ Plans that adequately protect information assets require managers and information owners—directly affected by and interested in the information and/or processing capabilities—to be convinced that their information assets are adequately protected from loss, misuse, unauthorized access or modification, unavailability, and undetected activities.

The purpose of the system security plan is to provide an overview of the security and privacy requirements of the system and describe the controls in place or planned for meeting those requirements. The system security plan also delineates responsibilities and expected behavior of all individuals who access the system. The system security plan should be viewed as documentation of the structured process of planning adequate, cost-effective security protection for a system. It should reflect input from various managers with responsibilities concerning the system, including information owners, the system owner, and the senior agency information security officer (SAISO).

For Federal agencies, all information systems must be covered by a system security plan. Other organizations should strongly consider the completion of a system security plan for each of their systems as well. The information system owner²⁵ is generally the party responsible for ensuring that the security plan is developed and maintained and that the system is deployed and operated according to the agreed-upon security requirements.

In general, an effective system security plan should include the following:

The greatest challenge and expense in developing and securely maintaining a mail server is providing the necessary human resources to adequately perform the required functions. Many organizations fail to fully realize the amount of expense and skills required to field a secure mail server. This failure often results in overworked employees and insecure systems. From the initial planning stages, organizations need to determine the necessary human resource requirements. Appropriate and sufficient human resources are the single most important aspect of mail server security. Organizations should also consider the fact that, in general, technical solutions are not a substitute for skilled and experienced personnel.

When considering the human resource implications of developing and deploying a mail server, organizations should address the following in the deployment plan:

Once the organization has staffed the project and the mail server is active, it will be necessary to ensure the number and skills of the personnel are still adequate. The threat and vulnerability levels of hosts including mail servers are constantly changing, as is the technology. This means that what is adequate today may not be tomorrow.

When addressing mail server security issues, it is an excellent idea to keep some general information security principles in mind [Curt01 and Salt75]:

This page has been left blank intentionally.

Protecting a mail server from compromise involves hardening the underlying operating system, the mail server application, and the network to prevent malicious entities from directly attacking the mail server. The first step in securing a mail server, hardening the underlying operating system, is discussed at length in this section. (Securing the mail server application and the network are addressed in Sections 6 and 7, respectively).

All commonly available mail servers operate on a general-purpose operating system. Many security issues can be avoided if the operating systems underlying the mail servers are configured appropriately. Default hardware and software configurations are typically set by manufacturers to emphasize features, functions, and ease of use at the expense of security. Because manufacturers are unaware of each organization’s security needs, each mail server administrator must configure new servers to reflect their organization’s security requirements and reconfigure them as those requirements change. The practices recommended here are designed to help mail server administrators configure and deploy mail servers that satisfy their organization's security requirements.²⁷ Mail server administrators managing existing mail servers should confirm that their systems address the issues discussed.

The techniques for hardening different operating systems vary greatly; therefore, this section includes the generic procedures common in securing most operating systems. Security configuration guides and checklists for many operating systems are publicly available; these documents typically contain recommendations for settings that improve the default level of security, and they may also contain step-by-step instructions for securing systems.²⁸ In addition, many organizations maintain their own guidelines specific to their requirements. Some automated tools also exist for hardening operating systems and their use is strongly recommended.

Five basic steps are necessary to maintain basic operating system security:

The first step is discussed in Section 4.1. The other steps are covered in Sections 5.1 and 5.2.

This section provides an overview of the second, third, and fourth steps in the list above. The combined result of these steps should be to have reasonable protection for the mail server’s operating system.

Once an operating system is installed, applying needed patches or upgrades to correct for known vulnerabilities is essential. Any operating system has known vulnerabilities that should be corrected before using it to host a mail server. To adequately detect and correct these vulnerabilities, mail server administrators should do the following:

Administrators should ensure that mail servers, particularly new ones, are adequately protected during the patching process. For example, a mail server that is not fully patched or not configured securely could be compromised by threats if it is publicly accessible while it is being patched. When preparing new mail servers for deployment, administrators should do either of the following:

Administrators should generally not apply patches to mail servers without first testing them on another identically configured server, because patches can inadvertently cause operational problems. Although administrators can configure mail servers to download patches automatically, the servers should not be configured to install them automatically so that they can first be tested.

Ideally, a mail server should be on a dedicated, single-purpose host. When configuring the operating system, disable everything except that which is expressly permitted – that is, disable all services and applications, enable only those required by the mail server, and then remove the unneeded services and applications. If possible, install the minimal operating system configuration that is required for the mail server application. Choose the “minimal installation” option, if available, to minimize the effort required in removing unnecessary services. In addition, many uninstall scripts or programs are far from perfect in completely removing all components of a service; therefore, it is always better not to install unnecessary services. Some common types of services and applications that should usually be disabled if not required include the following:

Removing unnecessary services and applications is preferable to simply disabling them through configuration settings, because attacks that attempt to alter settings and activate a disabled service cannot succeed when the functional components are completely removed. Disabled services could also be enabled inadvertently through human error.

Eliminating or disabling unnecessary services enhances the security of a mail server in several ways [Alle00]:

Organizations should determine the services to be enabled on a mail server. Services in addition to the mail server service that might be installed include directory protocols to access the organization’s user directory and remote administration services. These services may be required in certain instances, but they may increase the risks to the server. Whether the risks outweigh the benefits is a decision for each organization to make.

If Web-based mail access is to be provided, the Web server running the mail application should be on a separate host from the mail server. Having the Web and mail servers on separate hosts limits the impact if one of them is compromised when compared with having both servers on the same host. The benefits of the latter arrangement are efficient and protected communications, because the Web and mail servers communicate directly within a host instead of over a network.

For mail servers, the authorized users who can configure the operating system are limited to a small number of designated mail server administrators. The users who can access the mail server, however, may range from unrestricted to restricted subsets of the organization’s employees. To enforce policy restrictions, if required, the mail server administrator must configure the operating system to authenticate a prospective user by requiring proof that the user is authorized for such access.

Enabling authentication by the host computer involves configuring parts of the operating system, firmware, and applications, such as the software that implements a network service. In special cases, for high-value/high-risk sites, organizations may also use authentication hardware, such as tokens or one-time password devices. Use of authentication mechanisms where authentication information is reusable (e.g., passwords) and transmitted in the clear over a network is strongly discouraged, because the information can be intercepted and used by an attacker to masquerade as an authorized user.

To ensure the appropriate user authentication is in place, take the following steps [Alle00]:

The choice to deny login is another situation that requires the mail server administrator to make a decision that balances security and convenience. Implementing this recommendation can help prevent some kinds of attacks, but it can also allow an attacker to make failed login attempts to prevent user access, a denial of service (DoS) condition.

Failed network login attempts should not prevent an authorized user or administrator from logging in at the console. Note that all failed login attempts whether via the network or console should be logged. If remote administration is not to be implemented (see Section 9.5), disable the ability for the administrator or root level accounts to log in from the network.

As mentioned earlier, attackers using network sniffers can easily capture passwords passed across a network in clear text. However, passwords are economical and appropriate if properly protected while in transit. Implement authentication and encryption technologies, such as Secure Sockets Layer (SSL)/Transport Layer Security (TLS), Secure Shell (SSH), or Virtual Private Networks (VPNs) (for remote users), to protect passwords during transmission. Requiring server side authentication to be used with encryption technologies reduces the likelihood of successful man-in-the-middle attacks.

All commonly used modern server operating systems provide the capability to specify access privileges individually for files, directories, devices, and other computational resources. By carefully setting access controls and denying personnel unauthorized access, the mail server administrator can reduce security breaches. For example, denying read access to files and directories helps to protect confidentiality of information, and denying unnecessary write (modify) access can help maintain the integrity of information. Limiting the execution privilege of most system-related tools to authorized system administrators can prevent users from making configuration changes that could reduce security. It also can restrict the attacker’s ability to use those tools to attack the system or other systems on the network.

Operating systems often do not include all of the security controls necessary to secure the operating system, services, and applications adequately. In such cases, administrators need to select, install, and configure additional software to provide the missing controls. Commonly needed controls include the following:

Some mail server administrators also install one or more forms of host-based intrusion detection software on their servers. For example, file integrity checking software can identify changes to critical system files.

When planning security controls, mail server administrators should consider the resources that the security controls will consume. A server’s performance could degrade if it does not have enough memory and processing capacity for the controls.

Periodic security testing of the operating system is a vital way to identify vulnerabilities and to ensure that the existing security precautions are effective. Methods for testing operating systems include vulnerability scanning and penetration testing. Vulnerability scanning usually entails using an automated vulnerability scanner to scan a host or groups of hosts on a network for application, network, and operating system vulnerabilities. Penetration testing is a testing process designed to compromise a network using the tools and methodologies of an attacker. It involves iteratively identifying and exploiting the weakest areas of the network to gain access to the remainder of the network, eventually compromising the overall security of the network. Vulnerability scanning should be conducted periodically, such as weekly or monthly, and penetration testing should be conducted at least annually. Because both of these testing techniques also are applicable to testing the mail server application, they are discussed in detail in Section 9.4.35

Hardening mail server applications is an important step in protecting mail servers from compromise. This section provides recommendations for securely installing mail servers and configuring operating system and mail server access controls. Another important part of mail security is protecting the email content that traverses the server, which includes content filtering, malware scanning, and spam prevention. Securing access to mailboxes by encrypting communications, including Web-based mail access, is also addressed in this section. Email content security can also involve email encryption to preserve confidentiality and digital signatures to support integrity and non-repudiation; these are discussed in Section 3.

After ensuring that the mail server’s operating system is secured properly, the next step is to install the mail server application and secure it from likely threats. The subsections that follow provide an overview of these two actions.

In many respects, the secure installation and configuration of the mail server application mirrors the operating system process discussed in Section 5. The overarching principle, as before, is to install only the services required for the mail server and to eliminate any known vulnerabilities through patches or upgrades. Any unnecessary applications, services, or scripts that are installed should be removed immediately once the installation process is complete. During the installation of the mail server, the following steps should be performed:

Most mail server host operating systems provide the capability to specify access privileges individually for files, devices, and other computational resources on that host. Any information that the mail server can access using these controls can potentially be distributed to all users accessing the mail server. The mail server software is likely to include mechanisms to provide additional file, device, and resource access controls specific to its operation. It is important to set identical permissions for both the operating system and mail server application; otherwise, too much or too little access may be granted to users. Mail server administrators should consider how best to configure access controls to protect information stored on their public mail server from two perspectives:

The proper setting of access controls can help prevent the disclosure of sensitive or restricted information that is not intended for public dissemination. In addition, access controls can be used to limit resource use in the event of a DoS attack against the mail server.

Typical files to which access should be controlled are as follows:

Ensure that the mail server application executes only under a unique individual user and group identity with very restrictive access controls. Thus, new user and group identities to be used exclusively by the mail server software need to be established. The new user and new group should be independent and unique from all other users and groups. This is a prerequisite for implementing the access controls described in the following steps. Although the server may initially have to run with root (Unix) or administrator/system (Windows) privileges to bind to the necessary TCP ports, do not allow the server to continue to run at this level of access.

In addition, use the mail server operating system to limit files accessed by the mail service processes. These processes should have read-only access to those files necessary to perform the service and should have no access to other files, such as server log files. Use mail server host operating system access controls to enforce the following:

It is also necessary to ensure that the mail server cannot save files outside the specified file structure dedicated to the mail server. This may be a configuration choice in the server software, or it may be a choice in how the server process is controlled by the operating system. Ensure that such directories and files (outside the specified directory tree) cannot be accessed, even if users know the locations of those files.

On Linux and Unix hosts, consider using a “chroot jail” for the mail server application. Using chroot changes the mail server’s “view” of the host file system such that the apparent root directory is not the real file system root directory but rather one of its subparts. Thus, if the mail server is successfully compromised, the attacker only gains access to the limited subpart of the file system accessible via chroot. This is a very powerful security measure.

To mitigate the effects of certain types of DoS attacks, configure the mail server to limit the amount of operating system resources it can consume. Some examples include:

To some degree, these actions protect against attacks that attempt to fill the file system on the mail server host operating system with extraneous and incorrect information that may cause the system to crash. This also protects against attacks that attempt to fill primary random access memory with unnecessary processes to slow down or crash the system, thus limiting mail server availability. Logging information generated by the mail server host operating system may help in recognizing such attacks. As discussed in Section 9.1, administrators should store mail server logs on centralized logging servers whenever possible, and also store logs locally if feasible. If an attack causes the mail server to be compromised, the attacker could modify or erase locally stored logs to conceal information on the attack. Having a copy of the logs on a centralized logging server gives administrators more information to use when investigating such a compromise.

Email has increasingly been used as a means for sending binary files in the form of attachments. Initially, this did not pose much of a security risk because attachments were mostly small word processing documents or photos. As more organizations began using email for day-to-day collaboration, the size and types of email attachments increased. Today, many email messages are sent with attachments such as program executables, pictures, music, and sounds. Many forms of malware, including viruses, worms, Trojan horses, and spyware—malware intended to violate a user’s privacy—are often transmitted in attachments. Increasingly, attackers are using email to deliver zero-day attacks at targeted organizations before these vulnerabilities are known publicly. These attacks are often targeted at office productivity software and give the attacker control over users’ workstations. This control can be exploited to escalate privileges, gain access to sensitive information, monitor users’ actions (e.g., keystrokes), and perform other malicious actions.

Determining whether to allow certain types of attachments can be a difficult decision for an organization. Not allowing any attachments would simplify a system and make it more secure; however, it would dramatically reduce its usefulness, and users might employ encoding tricks to work around the restriction to “get the job done”. Ultimately, organizations choose to allow at least some email attachments.

Organizations should determine which types of attachments to allow. The simplest approach is to allow all types of attachments. If this is the case, then some sort of malware scanner (e.g., anti-virus software, anti-spyware software) should be installed in the mail transit path to filter out known malware, and perhaps even some behavior blocking utility installed at the client to prevent any unwanted operations by executable attachments from occurring. A better approach is to filter potentially dangerous attachment types (e.g., .vbs, .ws, .wsc file extensions) at the mail server or mail gateway, while conducting malware scans on allowed file types. Although filtering on such extensions is a good first step, its effectiveness is limited because attackers can alter the extensions. Instead of simply checking the extension, filtering should check the file header, footer, or other identifying aspects of the file if possible to identify the attachment. Organizations might also wish to consider setting different rules for internally originated versus externally originated email or trusted versus untrusted organizations (e.g., trust .gov/.mil domains), although this latter option is subject to email address spoofing.

Attachment filtering is not completely effective unless all attachments are blocked, and that is not feasible. Some of the most useful attachment types, such as those from office productivity suites, are also some of the riskiest. Also, sophisticated attackers can obfuscate the true nature of their malicious attachments in various ways. For example, attackers sometimes send emails that have hyperlinks to a malicious file on a remote Web site; if a user clicks on the hyperlink and it uses HTTPS instead of HTTP, the malicious file will be downloaded while protected by HTTPS, concealing it from detection by network-based security controls. Organizations could filter active hyperlinks in email messages to prevent this, but this would reduce the usability of email messages for users. Also, an organization might find it desirable for users to place hyperlinks to files in their email messages instead of attaching the files to their messages, since this reduces the load on the mail servers.

Organizations should also consider restricting the maximum acceptable size for email attachments. This benefits mail servers in several ways, including decreasing mail queue latency, storage requirements, and server processor requirements. The combination of these benefits decreases the likelihood of a successful denial of service attack caused by a deluge of oversized messages. [Mell05] However, setting a low maximum size for attachments could inadvertently cause legitimate content to be blocked, reducing the usability and value of the mail system.

Email encryption tends to make filtering more complicated or ineffective. Once a message is encrypted, filtering on the mail server and/or perimeter devices is ineffective unless they can decrypt the message, scan it, and re-encrypt it. This is problematic because of the huge performance requirement. Privacy and other concerns with this sort of solution also exist. Generally speaking, if encryption is used extensively, then filtering has to occur at the end point (mail client user workstation), which is susceptible to being bypassed.

Another vector for email-borne malware that is often overlooked is personal mail accounts accessed via Web browsers. Organizations need to determine if having access to personal mail accounts from organizational computers is appropriate, and if so, take measures to ensure users do not put organization assets at risk when accessing their personal accounts.

In addition to email attachments, malware can be transmitted via email by other means. For example, many mail clients support HTML-based messages. These messages often contain active content in the form of a client-side scripting language or control objects that can affect the client. The most popular types of active content are ActiveX, Java, JavaScript, and Visual Basic Script (VBScript). Organizations should determine whether or not to allow or block active content or forms of active content within email messages.³⁶ HTML-based messages also frequently contain other undesirable content, such as spam messages and phishing attempts.³⁷ Phishing refers to use of deceptive computer-based means to trick individuals into disclosing sensitive personal information. For example, an attacker could send victims an email message that looks as if it were sent from a well-known organization, such as an online business, credit card company, or financial institution. The email is intended to deceive users into responding to the email and disclosing personal data.

If a mail server does not have malware scanning software installed (e.g., anti-virus software, anti-spyware software), or the software is ineffective, the potential security threat posed by malware increases for end users. Some popular mail clients have default configurations that are used by malware to infect client hosts and transmit malware to other users. Section 8 contains additional information on configuring mail clients to improve their security. In addition to mail client configuration, it is important that the mail client hosts use anti-virus software and possibly other security technologies as well to protect them from email-borne threats.

Section 6.2.1 discusses the need for malware scanning for both individual mail clients and the mail infrastructure. Sections 6.2.2 discusses content filtering technologies that can also be helpful at stopping email-borne threats. In addition to deploying and configuring technologies, an organization should also conduct training and awareness activities for users, particularly telecommuters using computers outside the organization’s control, so that users can better recognize malicious email messages and attachments and handle them appropriately. This is discussed in Section 6.2.3.

To protect against viruses, worms, and other forms of malware, it is necessary to implement scanning at one or more points within the email delivery process. Malware scanning can be implemented on the firewall, mail relay, or mail gateway appliance as the email data enters the organization’s network, on the mail server itself, and/or on the end users’ hosts. Each option has its own strengths and weaknesses, which are discussed below. Generally, organizations should implement at least two levels of malware scanning—one at the end users’ host level and one at the mail server or the firewall/mail relay/mail gateway level—and should consider implementing malware scanning at all three levels.

When providing multiple layers of malware protection, organizations should consider choosing products from different manufacturers. Diversity increases the chances of blocking the latest threats, because the response time of individual manufacturers to new threats varies. This means that when the newest threats appear, one product can often detect them earlier than another over some period of time (typically hours, perhaps a few days). Since each manufacturer uses different detection methods, some products are also better able to detect certain types of new threats than other products.

The first option is scanning for malware at the firewall (application proxy), mail relay (see Figure 6.1), or mail gateway appliance, which can intercept messages before they reach the organization’s mail server. The device listens on TCP port 25 for SMTP connections, scans each message, then forwards the messages not containing malware to the mail server, which is configured to listen on an unprivileged, unused port, rather than the usual port 25. A disadvantage to this approach is that constant scanning of the SMTP stream can reduce firewall/ mail relay/mail gateway performance. Whether this performance hit is significant depends on mail load, including both the typical number of emails per day and the peak rates of emails, and quality of service requirements. One remedy to improve performance is to offload malware scanning to a dedicated server.

Figure 6.1: Malware Scanning Implemented on Firewall

The benefits of scanning email at the firewall, mail relay, or mail gateway appliance are as follows:

Scanning for malware at the firewall, mail relay, or mail gateway appliance has a number of weaknesses:

The second option for placement of a mail malware scanner is on the mail server itself (see Figure 6.2). Many third-party applications are available to scan the contents of the message stores for most popular mail servers. These applications inspect the email sent between internal users, which normally do not pass through the organization’s firewall/mail relay/mail gateway. Performing scanning on the mail server also provides an additional layer of protection against malware, and also helps to stop internal malware outbreaks. Some mail servers offer application programming interfaces (API) that support the integration of malware scanning, content filtering, attachment blocking, and other security services within the MTA.

Figure 6.2: Malware Scanning Implemented on Mail Server

The major disadvantage of implementing malware scanning on the mail server is the negative effect on the performance of the mail server caused by the requirement to scan all messages. Also disadvantageous is that malware scanning on the mail server often requires significant modifications to the existing mail server configuration. However, this option provides a number of advantages:

Scanning for malware at the mail server has a number of weaknesses:

When considering mail server-based malware scanners, look for the following qualities:

Malware scanners can also be located on client hosts (see Figure 6.3). This type of malware scanner is installed on user workstations and mobile devices, such as personal digital assistants (PDA). Incoming emails are scanned as they are opened by the user, and outbound emails are checked as the user attempts to send them. The primary advantage of this type of configuration is that scanning is distributed across many hosts and therefore has minimal effect on the performance of each individual host. Also, if a client machine becomes infected with malware, this layer of protection might stop the malware from spreading to the mail server and other mail clients.

Figure 6.3: Malware Scanning Implemented on User Workstations

The greatest challenge of implementing malware scanning on user workstations is the difficulty in managing and regularly updating the distributed malware scanners. However, enterprise-level solutions for malware scanning provide a means of central administration of malware scanners on individual hosts. Another weakness is that to the degree that users have control of the malware scanner, end users may disable some or all of its functionality (whether accidentally or intentionally). Enterprise solutions offer the capability to lock down some or all of the clients’ scanners’ functionality to ensure they are configured correctly.

The benefits of client-side malware scanning are as follows:

The disadvantages of client-side malware scanning are as follows:

Content filtering works in a similar manner to malware scanning at the firewall or mail server except that it is looking for emails containing undesirable content other than malware, such as spam or emails containing inappropriate language. When implementing file-type restrictions and malware scanning, only a certain level of security is provided. The contents of an email message or its attachments could prove much more damaging to an organization than a virus or rogue executable. For this case, some sort of content filtering mechanism should be employed.

For maximum effectiveness, content filtering should be performed on all incoming and outgoing messages and conducted in the same locations as malware scanning—on the firewall/mail relay/mail gateway, mail servers, and end users’ hosts. In fact, many products are available for popular messaging systems that incorporate content filtering, malware scanning, and file-type restriction (see Appendix D for a listing of common products). Incorporation of these features into one product can reduce the administration of security controls.

In general, rules are defined to forward, quarantine, park, clean, block, or delete any data passing through the server depending upon the results of the scan. Typical items that would be caught by the filter and possible actions taken on them could be as follows:

Another key feature of content filtering packages is the scanning of outbound data. A lexical analysis can be performed that scans email messages for words and phrases that might be viewed as inappropriate for use in organizational email. The lexical analysis can also save possible litigation against an organization by preventing inappropriate content, including hoaxes and spam (see Section 6.3), from leaving the organization. In addition, a lexical analysis might include searches for key words and phrases indicating that sensitive data is leaving the enterprise.

Organizations should also take steps to prevent email address spoofing, such as ensuring that external users cannot send emails to internal users that have one of the organization’s email addresses as the spoofed sender. For example, a hypothetical company WidgetsRUs should block any incoming email with a “from” address in the domain widgetsrus.com at its mail gateway. Attackers often spoof email addresses to make their malicious emails appear to be from internal users, because it can trick users into trusting the emails. Checking digital signatures on emails is a way that users can detect some spoofing attempts.³⁸

Before implementing any filtering solution, it is imperative to determine how the existing network and applications actually work. This entails running network analyzers (sniffers); analyzing router, firewall, and server log files; and interviewing all appropriate system and network administrators. It is also imperative to analyze the existing organization information system security policy, or draft one if one does not exist. Clearly defined security policies are critical to translating the organization’s security goals into filter rules. Great care must be taken in crafting the rules because an incorrectly configured filter may fail to filter inappropriate content or may accidentally filter appropriate content. These steps will make it easier to choose the appropriate filtering software and determine the types of rules that need to be configured.

Another effective way to decrease the number of unwanted messages reaching mail servers is using Lightweight Directory Access Protocol (LDAP) lookup on a mail gateway or firewall as a filtering mechanism. LDAP lookup allows the gateway or firewall to query the organization’s user directory directly for user information. When an email is received by the gateway or firewall, it contacts the user directory to see if the email is addressed to a user that actually exists. If the user is not in the directory, the email is rejected and does not reach the mail server. Much of the spam sent to a domain is generated using a database of common usernames. Most of these addresses do not exist for a particular domain, but it is an easy method for spammers to get their messages to many users quickly. Using LDAP lookup prevents these messages from slowing the mail server.

Many Internet service providers (ISP) and third-party companies offer malware scanning and content filtering services, including spam filtering. These services can be helpful for organizations that wish to add an extra layer of defense but do not want to implement or maintain the extra layer of protection themselves. The services delete or tag messages before they reach an organization’s mail server, therefore increasing its efficiency. Because these services may monitor emails for many organizations, they can often identify new unwanted messages very quickly. Disadvantages of using such a service include the following:

Although email content filtering is critical to most organizations’ security posture, a number of legal implications should be addressed before deployment. Content filtering needs to be backed up by a clearly defined written security policy. The email policy should include an explicit statement that email will be monitored for compliance, a description of any administrative or disciplinary actions that could result if the policy is violated, and a requirement for employees to acknowledge reading and understanding the policy. Although the policy should outline the organization’s thinking, expectations, and restrictions regarding security, due regard should also be given to employee and individual rights. For instance, under some circumstances employees may have a right to privacy when it comes to their own correspondence; however, when representing their organization, the organization may be held legally responsible for what they say or do. Without an established policy, such issues often lead to misunderstanding and problems that can be difficult to resolve.

Similarly, in some situations, email messages may be deemed to carry the same legal weight as written documents, especially when digitally signed. This can mean having to store messages to comply with record-keeping requirements, including employees’ personal messages. As such, all employees should be made aware of the security policy. To the extent possible, the security policy should be broadly distributed to employees [McKi01]. Moreover, it may be advisable to require employees to acknowledge the policy as part of their contract of employment or as a condition of working on a contract, and to also require employees to re-acknowledge the policy on a regular basis. Many email filter applications can add a legal disclaimer to all incoming and outgoing messages, ensuring recipients understand the legal weight (or lack thereof) of the emails received from or through the organization.

Appropriate legal, privacy, personnel, and human resources authorities should be consulted when forming the policy. Inevitably, this means having the policy reviewed by experts to ensure that it is legally correct and does not infringe upon the rights of employees. Additionally, it is important to investigate all areas of an organization to determine how workers go about their work and what level of security is most appropriate. Completely restricting access to Internet resources might solve most security issues at a stroke, but this is usually an unacceptable tradeoff. This is where email filtering tools can help, enabling security policies to be more easily converted from theory into practice.

As previously mentioned, personal email accounts are problematic, especially those accessed via a Web browser that tend to bypass the email content filtering controls. In particular, if a user is using an SSL-encrypted Web page for personal email access and the organization does not decrypt and analyze SSL-encrypted HTTPS traffic, the content may be allowed out or in even though it would not be if it went through normal channels. Many organizations also allow encrypted protocols outbound (e.g., from their internal network to the Internet) such as SSH or IPsec that can also be used to tunnel traffic in or out of the organization without the restrictions of filtering.

If an organization allows mail protocols, such as SMTP, outbound to the Internet for all internal users, content filtering may be bypassed by users setting up their own mail servers. Organizations should be aware that certain products and applications use SMTP email for communications. It is not uncommon in large organizations for a significant percentage of the outbound email traffic to be generated by servers other than the centralized enterprise mail servers. Often these emails are generated from electronic commerce applications communicating with customers or business partners. One way to address the problem is to set up a mail gateway or application proxy at the perimeter that does content filtering on all email, even those messages generated by or destined to servers other than the centralized enterprise mail servers. Section 7 provides additional information on network architectures and mail gateway placements.

In addition to using anti-virus software and/or other malware scanning tools, as well as content filtering software, organizations should educate users about the dangers posed by email-borne malware and effective ways of avoiding threats, including the following actions:

Users should also be aware of the dangers of phishing attacks and how to avoid them. The Federal Trade Commission (FTC) posted a consumer alert outlining steps that users should take: [FTC06]

Regardless of the communication medium, there are always entities that attempt to exploit any means of communication to publicize their ideas or products. Email is no exception. The most common terms for these messages are unsolicited commercial email (UCE), which is better known as spam. Most email users receive spam on a daily basis. Because email is largely unregulated, system administrators should police email traffic that traverses the servers they operate to reduce the amount of spam that reaches users. An added benefit of implementing server-based spam control is that it will reduce mailbox sizes, which in turn reduces server storage requirements.⁴⁰

To control spam messages, administrators must address the following three concerns:

Because the Internet has no centralized policing authority, non-profit organizations and commercial companies have created lists of mail servers that have been identified as being used to send unsolicited email messages. These lists are often referred to as open relay blacklists (ORB) or DNS blacklists (DNSBL). Many popular mail server applications can be configured to query multiple ORBs and reject messages originating from the listed mail servers. These lists are updated on a daily basis; therefore, using them can drastically reduce spam message delivery. Additionally, most mail servers can be configured to reject messages from an explicitly defined set of domains.

ORB spam control is not foolproof. Open relays are connected and disconnected regularly. Mail server administrators who wish to participate in the policing effort may submit UCE complaints to Web sites provided in Appendix E.

As mentioned previously, configuring mail relay authentication decreases the likelihood of someone using a particular mail server to send spam. An added benefit of implementing authenticated relay is increased security and usability.

Two methods are available for controlling mail relay. The first is to control the subnet or domain from which messages are being sent. This method is effective if the perimeter of the messaging system resides within known address ranges. However, if remote users have hosts with different address ranges, this method is not useful. To accommodate remote users, a more robust configuration is needed.

The second method is to require users to authenticate themselves before sending any messages. This is commonly referred to as authenticated relay, or SMTP AUTH, which is the SMTP extension that supports user authentication. Unfortunately, the default configuration of most mail servers does not implement authenticated relay; therefore, mail server administrators must configure the server appropriately. Requiring authenticated relay is one of the least used but most powerful security features of mail servers. (Refer to manufacturer documentation for configuring SMTP AUTH.)

Mail server administrators must use caution if choosing to have an authenticated relay. An improperly configured mail server could be exploited and used to send or relay spam. If the mail server is found to be an open relay, it might be put on a blacklist (as described in Section 6.3). Any organizations subscribing to and using these blacklists will not be able to receive any email from a blacklisted server, whether the messages are spam or valid emails.

If a mail server administrator learns that one of his or her mail servers is on a blacklist, the administrator will have to fix the open relay problem and perform testing to ensure the server is no longer relaying. The administrator then needs to determine which blacklists the server is on and check with each blacklist maintainer to get instructions on how to remove the server from the lists. Until the server has been removed from all blacklists and the updated blacklists have been propagated to their subscribers, outbound email from the organization may not reach all of its recipients. See Appendix D for a listing of Web sites that provide open relay testing tools as well as the maintainers of commonly used blacklists.

In Section 2, different mail transport and mailbox access protocols were discussed. Like many Internet protocols, most of these protocols did not initially incorporate any form of encryption or cryptographic authentication. These deficits posed three problems for email users. First, for users sending messages, the contents could be intercepted and read at any host on the path between the sender and recipient or even forged or modified. An apt paradigm from “regular” mail would be a postcard. Any person who handles the postcard could read the message on the back. Second, the recipients could not verify that messages were not modified by others during transit or actually originated by the sender. Third, rather than supplying non-reusable authentication information, a user accessing a mailbox would send a password over the network in the clear, which could be easily observed and reused by an attacker. Unfortunately, in most default configurations, mail clients are set up to send the user’s password in the clear, allowing it to be intercepted by other computers on the local network segment of the client or any host responsible for forwarding the password to the mail server.

The first two problems were addressed in Section 3, which discussed ways to protect messages. The third problem can be resolved by applying the same method normally used to secure World Wide Web (WWW) traffic – the Transport Layer Security (TLS) protocol.

TLS is similar to the Secure Sockets Layer (SSL) protocol, upon which it is based, and can be used in combination with POP, IMAP, and SMTP to encrypt communication between mail clients and servers. RFC 2595 defines how to use TLS to combat communications eavesdropping, to implement secure mailbox access and to further strengthen SMTP MTAs that incorporate SMTP AUTH. Figure 6.4 shows a sample configuration that enables TLS support for newer versions of sendmail.

define(`CERT_DIR', `MAIL_SETTINGS_DIR`'certs')dnl define(`confCACERT_PATH', `CERT_DIR')dnl define(`confCACERT', `CERT_DIR/CAcert.pem')dnl define(`confSERVER_CERT', `CERT_DIR/MYcert.pem')dnl define(`confSERVER_KEY', `CERT_DIR/MYkey.pem')dnl define(`confCLIENT_CERT', `CERT_DIR/cert.pem')dnl define(`confCLIENT_KEY', `CERT_DIR/MYkey.pem')dnl

Figure 6.4: Sendmail TLS Configuration Example from sendmail.mc

Increasingly, organizations are providing Web browser-based access to their messaging systems. Enabling this type of access could introduce security issues at both the client (see Section 8.4) and server. Although Web site security is outside the scope of this document, there are several key concepts that should be followed:

For some organizations, the processing requirements of dedicating a Web server to SSL/TLS communication may not be possible to accommodate. In cases such as this, the initial authentication should be encrypted.

Some organizations choose to use hardware appliances for their Web access solution. These appliances not only provide secure Web-based access to mail servers, but they also provide firewall, content filtering, and malware protection capabilities. The appliances typically are easier and faster to install and maintain than creating Web servers, and they often use hardened operating systems with all non-essential components disabled or removed, which limits the possible vulnerabilities the appliances might have. Some appliances offer additional capabilities, such as offering administrators granular control over user groups and access, performing SSL encryption for sessions, and terminating user sessions automatically after a period of inactivity. Appliances are available that support the most commonly used Web-based mail systems.

Client security issues exist that also need to be considered before an organization approves the deployment of Web access to email. These issues are discussed in Section 8.4.

This page has been left blank intentionally.

The network infrastructure that supports the mail server plays a critical role in the security of the mail server. In most configurations, the network infrastructure is the first line of defense between the Internet and a mail server. Network design alone, however, cannot protect a mail server. The frequency, sophistication, and variety of attacks perpetrated today lend support to the idea that email security must be implemented through layered and diverse protection mechanisms. This section discusses those network components that can support and protect mail servers to further enhance their overall security. While security issues are paramount, network infrastructure considerations are influenced by many factors other than security, including cost, performance, and reliability.

Firewalls and routers are devices or systems that control the flow of network traffic between networks. They can protect mail servers from vulnerabilities inherent in the Transmission Control Protocol/Internet Protocol (TCP/IP) suite and help reduce the security issues associated with insecure applications and operating systems. However, an organization has many choices when determining a network environment for the mail server, and security may not be the principal factor in deciding among those options. Network composition and structure are the first and in many respects the most critical decisions that affect mail server security, since they determine what network infrastructure elements protect the mail server. For example, if the mail server is located before the organization’s main firewall, then the firewall cannot be used to control traffic to and from the mail server. Network composition and structure also determine what other portions of the network are vulnerable if the mail server is compromised. For example, an externally accessible mail server located on the internal production network subjects the internal network to attack if the mail server is compromised.

Some organizations choose to locate their public mail servers on their internal production networks. That is, their mail servers reside on the same network as the internal users and servers. The principal weakness of this layout is that it exposes internal network components to additional risks. Mail servers are often targets of attackers. If attackers manage to compromise a mail server, they will have access to the internal network and be able to more easily compromise internal hosts. Therefore, this layout is not recommended.

Another network layout that is not generally recommended is placing the mail server before an organization’s firewall or router that provides IP filtering. In this structure, the network provides little, if any, protection for the mail server. Because the mail server itself has to maintain security, it provides a single point of failure. To be even somewhat secure in this location, the mail server operating system and application have to be well-hardened, with all unnecessary and insecure services disabled and all necessary security patches applied. To maintain the “security” of the setup, the mail server administrator must stay up-to-date on vulnerabilities and related patches. Another limitation of this structure is that providing any sort of secure remote administration capability is difficult.

A demilitarized zone (DMZ) describes a host or network segment inserted as a “neutral zone” between an organization’s private network and the Internet. It prevents outside users of the mail server from gaining direct access to an organization’s internal network (intranet). A DMZ mitigates the risks of locating a mail server on an internal network or exposing it directly to the Internet. It is a compromise solution that offers the most benefits with the least amount of risk for most organizations. The DMZ allows access to the resources located within it to both internal and external users. There are a wide variety of DMZ configurations, each with its own strengths and weaknesses.

Creating a DMZ involves placing a firewall between an organization’s border router and its internal network, and creating a new network segment that can only be reached through the DMZ device. The mail server or mail gateway is placed on the new segment, along with other network infrastructure components and servers that need to be externally accessible. For example, if Web-based mail access is offered, the associated servers are typically placed on the DMZ. In some configurations, the border router itself may act as a basic firewall. Figure 7.1 illustrates an example of this simple DMZ using a router with access control lists (ACL) to restrict certain types of network traffic to and from the DMZ.