This article originally appeared on Microsoft TechNet at http://technet.microsoft.com/en-us/library/cc875813.aspx
Introduction
All organizations are facing significant legal and regulatory challenges in such areas as information security, privacy, and reliability. These challenges can require major changes to systems and processes across an organization. Businesses must react to and plan for the increasing structure and regulation around accountability and control to meet many legal and ethical objectives. Compliance means meeting all of the legal and business requirements that an organization faces and must demonstrate during the course of operations and in doing business. Compliance also means understanding the legal framework in which judicial and corporate requirements operate. Becoming compliant involves every business department and every employee. Compliance cannot be achieved through the implementation of a single solution or process; it must be built into every business section of an organization.
The regulatory environment is increasingly complex. Compliance is often not a simple process, and regulations vary in the specificity of their requirements. An organization must, therefore, conduct a full assessment of risks and impacts.
The scope of this paper is to describe some of the processes and technologies that you can use to help standardize and streamline regulatory compliance efforts in the area of e-mail confidentiality. This paper presents resources and options that many small to medium businesses encounter while trying to comply with laws and regulations. This paper is not a roadmap to regulatory compliance, nor does it provide legal advice on any of these issues. Readers must consult with their own advisors and attorneys prior to enacting any compliance program or process.
Who Should Read This Guide
The intended audience for this guide includes IT professionals who are responsible for the installation, maintenance, and administration of an e-mail service based on Microsoft® Exchange Server 2003 in their network environments.
The information in this guide applies to small to medium businesses that must deliver confidential e-mail messages on their network.
Overview
Although message security features have been available in Microsoft Exchange Server since the first version of the product, typically only customers that have specialized security requirements and security staff have used these features. Only security specialists and those with cryptography backgrounds needed to understand e-mail message security concepts. With the increased support for Secure/Multipurpose Internet Mail Extensions (S/MIME) in Exchange Server 2003 and the need for regulatory compliance, administrators began to need to understand these principles and concepts.
The Messaging and Security Feature Pack for Windows Mobile 5.0 offers support for S/MIME certificates on smart phones. In addition, Microsoft Exchange Server 2003 Service Pack 2 (SP2) offers support for S/MIME in Microsoft Outlook® Web Access (OWA).
This paper presents an introduction to S/MIME and its related concepts and provides prescriptive guidance on how to implement S/MIME. No background in security is needed. This paper explains general S/MIME concepts so that you can apply the concepts specifically to Exchange Server.
S/MIME Benefits
Before S/MIME, administrators used a widely accepted e-mail protocol to transfer messages, Simple Mail Transfer Protocol (SMTP), which was inherently less secure. Or administrators used more secure but proprietary solutions. In essence, they were forced to choose a solution that emphasized either security or connectivity. With S/MIME, administrators now have an e-mail option that helps provide greater security than SMTP, enabling widespread and secure e-mail connectivity.
S/MIME provides two security services:
- Digital signatures
- Message encryption
These two services are the core of S/MIME-based message security. All other concepts related to message security support these two services. Although the full scope of message security may seem complex, these two services are the basis of message security.
Digital signatures and message encryption are not mutually exclusive services. Each service addresses specific security issues. Digital signatures address authentication and repudiation issues, and message encryption addresses confidentiality issues. Because each service addresses different issues, a message security strategy requires both, often at the same time. These two services are designed to be used in conjunction with one another, because each separately addresses one side of the sender-recipient relationship. Digital signatures address security issues related to senders, whereas encryption primarily addresses security issues related to recipients.
When digital signatures and message encryption are used together, users benefit from both services. Employing both services in messages does not change the handling or processing of either service.
Digital Signatures
Digital signatures are the more commonly used service of S/MIME. As the name suggests, digital signatures are the digital counterpart to the traditional, legal signature on a paper document. As with a legal signature, digital signatures provide the following security capabilities:
- Authentication. A signature serves to validate an identity. It verifies the answer to "who are you" by providing a means of differentiating that entity from all others and proving it’s from a mutually trusted source. Because there is no authentication in SMTP e-mail, there is no way to know who actually sent a message. Authentication in a digital signature helps solve this problem by enabling a recipient to know that a message was sent by the person or organization who claims to have sent the message.
- Non-repudiation. The uniqueness of a signature helps prevent the owner of the signature from disowning the signature. This capability is called non-repudiation. Thus, the authentication that a signature provides gives the means to enforce non-repudiation. The concept of non-repudiation is most familiar in the context of paper contracts: A signed contract is a legally binding document, and it is more difficult to disown an authenticated signature. Digital signatures provide the same function and, increasingly in some areas, are recognized as legally binding, similar to a signature on paper. Because SMTP e-mail does not provide a means of authentication, it cannot provide non-repudiation. It is easy for a sender to disavow ownership of an SMTP e-mail message.
- Data integrity. An additional security service that digital signatures provide is data integrity. Data integrity is a result of the specific operations that make digital signatures possible. With data integrity services, when the recipient of a digitally signed e-mail message validates the digital signature, the recipient helps to assure that the e-mail message that is received is, in fact, the same message that was signed and sent and has not been altered while in transit. Any alteration of the message while in transit after it has been signed invalidates the signature. In this way, digital signatures are able to help provide an assurance that signatures on paper cannot, because it is possible for a paper document to be altered after it has been signed.
Message Encryption
Message encryption provides a solution to information disclosure. SMTP-based Internet e-mail does not secure messages. An SMTP Internet e-mail message can be read by anyone who sees it as it travels or views it where it is stored. S/MIME helps to address these problems through the use of encryption.
Encryption is a way to change information so that it cannot be read or understood until it is changed back into a readable and understandable form.
Although message encryption is not as widely used as digital signatures, it does address what many people perceive as the most serious weakness in Internet e-mail. Message encryption provides two specific security services:
- Confidentiality. Message encryption helps serve to protect the contents of an e-mail message. Only the intended recipient can view the contents, and the contents remain confidential and cannot be known by anyone else who might receive or view the message. Encryption helps provide confidentiality while the message is in transit and in storage.
- Data integrity. As with digital signatures, message encryption helps provide data integrity services as a result of the specific operations that make encryption possible.
S/MIME Requirements
To provide e-mail confidentiality, your environment requires particular software components. This section outlines those components.
Public Key Infrastructure (PKI)
S/MIME solutions require a PKI to provide digital certificates with public key/private key pairs and enable certificate mapping in the Active Directory® directory service. The S/MIME standard specifies that digital certificates used for S/MIME conform to the International Telecommunications Union (ITU) X.509 standard. S/MIME version 3 specifically requires that digital certificates conform to version 3 of X.509. Because S/MIME relies on an established, recognized standard for the structure of digital certificates, the S/MIME standard builds on that standard's growth and thus increases its acceptance.
You can implement a PKI to support S/MIME in one of two ways: provision the internal certificate infrastructure to an external organization, or use Certificate Services in Microsoft Windows Server™ 2003.
For more information about Certificate Services in Windows Server 2003, see the Public Key Infrastructure for Windows Server 2003 Web site, at www.microsoft.com/windowsserver2003/technologies/pki/default.mspx.
The PKI must have a mechanism that deals with certificate revocation. Certificate revocation is necessary when a certificate expires or when an attacker could have compromised a certificate. By revoking a certificate, an administrator denies access to anyone who uses the certificate. Each certificate includes the location of its certificate revocation list (CRL).
For more information about how to manage certificate revocation, see the Manage Certificate Revocation topic at http://technet2.microsoft.com/WindowsServer/en/Library/de0ae267-14e6-46f8-bcc7-8ac480889b951033.mspx.
Certificate Templates
Windows Server 2003 provides specific certificate templates to issue digital certificates for use with S/MIME. Three multi-function user certificate templates can be used to issue certificates for secure e-mail:
- Administrator. Allows an administrator to use a certificate for authentication, Encrypted File System (EFS) encryption, secure e-mail, and certificate trust list signing.
- User. Allows a user to use a certificate for authentication, EFS encryption, and secure e-mail.
- Smart card user. Allows a user to log on with a smart card and sign e-mail. In addition, this certificate provides client authentication.
Note: Microsoft strongly recommends that you upgrade a current Windows Server 2003 PKI to a Windows Server 2003 with Service Pack 1 (SP1) PKI to take advantage of enhanced security features.
For more information about certificate templates, see the Certificate Templates topic on Microsoft TechNet, at http://technet2.microsoft.com/windowsserver/en/library/7D82B420-10EF-4F20-A56F-17EE7EE352D21033.mspx.
Active Directory
Active Directory is a key component for the implementation of S/MIME certificates. To deploy certificates to users for use with e-mail services, an administrator can make use of the Group Policy autoenrollment feature of Active Directory. Also, Active Directory in Windows Server 2003 contains built-in support as the PKI directory for several Microsoft e-mail clients, including Outlook, Outlook Express, and Outlook Web Access (OWA) with S/MIME and the ability to map user accounts to certificates.
For more information about certificate mapping, see the Map certificates to user accounts topic at http://technet2.microsoft.com/WindowsServer/en/library/0539dcf5-82c5-48e6-be8a-57bca16c7e171033.mspx?mfr=true.
Exchange Server 2003
By providing support for a variety of e-mail clients, Exchange Server 2003 administrators can customize their deployment to meet their specific needs. Exchange Server 2003 S/MIME support for clients is similar to the overall support for clients in that customers can use any of the supported clients simultaneously. Thus, an Exchange Server 2003 S/MIME–based solution can support Outlook clients, OWA clients, and Outlook Express clients using POP3 all at the same time. However, because the e-mail client must support S/MIME version 3 and be a supported Exchange Server e-mail client, not all e-mail clients can be S/MIME clients.
S/MIME is also provided in Exchange Server 2000 and Exchange Server 2007.
E-Mail Clients
Exchange Server 2003 supports S/MIME clients through its existing support for client protocols. If a supported client also supports S/MIME, that client can be used with Exchange Server 2003. If the client does not support S/MIME version 3, that client can still be used to read clear-signed messages.
Microsoft Outlook 2003
Outlook supports Messaging Application Programming Interface (MAPI)–based connectivity to Exchange Server 2003. In addition, Outlook can connect by using POP3 and IMAP4. Exchange Server 2003 S/MIME can be used with any version of Outlook that supports X.509 v3 digital certificates. Full support in Outlook for X.509 v3 digital certificates was first introduced with Outlook 2000 Service Release 1 (SR-1).
POP3 and IMAP4 Clients
Exchange Server 2003 provides full support for S/MIME clients through the Internet e-mail standard protocols POP3 and IMAP4, if the e-mail client supports S/MIME version 2 or version 3. Any e-mail client that supports S/MIME version 2 or version 3, and either POP3 or IMAP4, can be used as an e-mail client in an Exchange Server 2003 message security system. Because any e-mail client that supports the S/MIME standard provides full support for all message security services, these clients can be used as full-featured e-mail clients. Microsoft provides S/MIME version 3 support in POP3 and IMAP4 clients in both Outlook Express 5.5 or later and Outlook 2000 SR-1a or later.
Note: Different Internet standards and e-mail clients have their own requirements and ways of handling X.509 v3 certificates. Be aware of these requirements and compatibility issues when deciding which e-mail clients will be supported.
Operational Considerations
After you implement and verify the elements of this solution, you should consider a number of ongoing activities to ensure that the solution will continue to operate successfully for protection of e-mail confidentiality.
Operational considerations include:
- Apply service packs. Among the improvements included in Exchange Server SP2 are anti-spam enhancements. For more information, see the Anti-Spam Enhancements in Exchange Server 2003 Service Pack 2 topic on TechNet.
- Apply the latest security updates. Protect all your servers with updates from the Microsoft Download Center.
- Anticipate technical challenges. Regularly visit Microsoft Update at http://update.microsoft.com/ to download and install other security updates for Exchange Server and Windows Server.
- Run Microsoft Baseline Security Analyzer (MBSA). You can scan for missing security updates on Exchange Server 2003 by downloading MBSA.
- Use the Microsoft Exchange Server Intelligent Message Filter. Help reduce the influx of spam when you combine the Exchange Server Intelligent Message Filter with Outlook 2003 for advanced server-side, heuristics-based message filtering. For details on how to keep the Intelligent Message Filter updated, see the article titled The "Microsoft Exchange Server Intelligent Message Filter v2 Operations Guide" is now available at http://support.microsoft.com/?kbid=907747.
- Run the Microsoft Exchange Server Best Practices Analyzer. This tool, available as a free download, collects configuration data remotely from each server in the topology and automatically analyzes the data. The resulting report details critical configuration issues, potential problems, and non-default product settings. By following these recommendations, you can achieve greater performance, scalability, reliability, and uptime.
- Regularly check for any updated security information. For technical security guidance, visit the Exchange Server 2003 Technical Documentation Library: Security and Protection page, at www.microsoft.com/technet/prodtechnol/exchange/2003/security.mspx.
Digg
del.icio.us
Newvine
furl
StumbleUpon
BlinkList
Newsvine
Magnolia
Facebook
Tailrank
Slashdot
Technorati
Google Bookmarks
Yahoo Favorites
Windows Live
Ask