Securing Exchange Server 2010 is a process that involves making key decisions that can negatively affect access to features and ease of use. Exchange administrators are often seen as the bad guy for doing the right things — security-wise — for the organization.
There’s good news for administrators; Exchange Server 2010 is more secure and feature-rich out-of-the-box than its predecessors. This tip introduces some major security vulnerabilities of Exchange 2010 and how the server can protect itself against them.
Transport security in Exchange 2010
The SMTP protocol is the first challenge to Exchange 2010 security. SMTP is vulnerable to snooping since SMTP is an extremely open protocol that sends information in clear text.
Self-signed certificates are used in Exchange 2010 to enhance SMTP security. By default, the hub transport role leverages self-signed certificates to encrypt communications between transport servers within the organization, with no additional administrative intervention.
External-facing transport servers use opportunistic transport layer security (TLS) when connecting to remote SMTP hosts. This allows them to send encrypted communications outbound if the remote server has a trusted certificate. Administrators can also enable domain security for partner SMTP domains for mutual TLS encryption (Figure 2).
Organizations that require encryption for regulatory compliance purposes like HIPAA can benefit from this feature. When an edge transport server role is introduced, an additional layer of security becomes available to the organization when external connectivity is limited to the perimeter network.
Protecting Exchange 2010 users from spoofing
Another potential vulnerability is the fact that messages sent with SMTP can be easily manipulated. One way that a message can be manipulated that could have disastrous consequences is spoofing.
Spoofing is the process of pretending to be someone you are not in an email message. In many cases, the recipient of a spoofed message does not identify that the message didn’t originate from the actual sender. A great example of this is when you receive an email from yourself advertising the latest get-rich-quick scheme.
Secure Multipurpose Internet Mail Extension (S/MIME) certificates can protect Exchange organizations from email address spoofing. S/MIME certificates let users digitally sign a message that they are sending. If the recipient trusts the certificate authority that issued the certificate, he can verify that the person in the From: field is, in fact, the same person who sent the message. Outlook 2010 and Outlook Web App (OWA) clients both support S/MIME
You can also use S/MIME certificates to encrypt the actual messages that users send to one another. S/MIME requires an organization to invest in a public key infrastructure (PKI) solution. Leveraging Active Directory Group Policy and Exchange Server 2010 can facilitate S/MIME deployment.
Exchange Server 2010 and Active Directory integration
The latest addition to the message security feature set is the tight integration between Exchange Server 2010 and Active Directory Rights Management Services (AD RMS). If an organization introduces AD RMS, administrators can use it to enforce compliance for security policies.
An example of this might include encrypting email messages as they’re sent between certain individuals in an organization. AD RMS is better than S/MIME because it enables Exchange 2010 transport servers to decrypt messages, scan for viruses that may be attached and then securely deliver the messages to the target recipients.
Role Based Access Control (RBAC) in Exchange 2010
Much like transport servers, Client access server (CAS) roles are often Internet-facing. There are a variety of Internet protocols that can be used to access users’ mailboxes, which makes the CAS role vulnerable. Protocols such as HTTP (OWA/ActiveSync/Outlook Anywhere), IMAP4 and POP3 each have potential vulnerabilities. However, similar to SMTP, they can be protected with certificates.
The CAS role cannot use self-signed certificates without making users aware that they’re not from a trusted certificate authority . Additional certificates from trusted CAs must be obtained for the CAS servers.
Exchange Server 2010 includes a new Certificate Wizard (Figure 7) in the EMC that simplifies the request-and-import process. With an increasing dependence on certificates for security, it’s nice to have assistance to ensure that all potential vulnerabilities are being accounted for as new certificate requests are generated. It’s also helpful that you don’t need to use the Exchange Management Shell.
Protecting Exchange Server 2010 with ForeFront
Just as an edge transport server creates an additional layer of protection for SMTP communication, there needs to be an equivalent protection for HTTP, IMAP4 and POP3 connections. To provide protection, an application layer firewall becomes a reverse proxy for the applications that use these protocols.</ p>
Microsoft strongly recommends using an application firewall and provides two related products, both of which are next-generation ISA servers that can protect the CAS roles in the perimeter network.
Forefront Protection for Exchange 2010 (FPE) is the latest Microsoft technology you can use to protect your organization from spam, viruses, phishing and other security issues. You can deploy FPE on the edge, hub and mailbox server roles on-premise; you can also use Forefront Online Protection for Exchange 2010 (FOPE) in the cloud, in addition to on-premise protection.
Windows Management and Scripting 