Exchange 2010 Security
State-of-the-art won’t do, even the most advanced version of Exchange Server. Security is inevitably a circumstantial matter, and you’ll always have to tailor things to a custom specification. Naturally, you’ll inadvertently annoy your users, since securing attack surfaces is the corollary of taking away things people used to take for granted. Access to services might be disrupted, and features are no longer as easy to reach as before.
Still, there’s hope for ye administrators. Exchange Server 2010 is amongst the most security-conscious offerings from Microsoft (not that it says much), and more importantly it’s designed with customized security implementations in mind. In this article, we’ll take a look at some of the inevitable vulnerabilities that persists in the architecture – after all, it’s written by mortals – and the ways the server can safeguard against intruders, with a little help from its tender carers such as yourselves.
The first port of call is always the mail protocol itself – the Simple Mail Transfer Protocol, which doesn’t lend itself to much confidence judging by the name alone. Indeed, it’s surprisingly simple, and its openly trusting nature, plain text transmission and all, is immensely vulnerable to malicious snooping. Even innocent WiFi sniffing, as exemplified by Google’s recent escapades, are theoretically capable of grabbing these packets.
In Exchange 2010, SMTP is fortified by means of self-signed certification: an identity certificate that is signed by its own creator. In other words, the person that created the certificate also signed off on its legitimacy. Hub Transport server roles utilize it to encrypt general communication within the internal organization without requiring further intervention from administrators. Unless you work in truly security-critical environments, this should be sufficient for all practical purposes. You’d be worrying about external transport instead, and rightly so.
Provided that the destination server is similarly security-conscious, Exchange can enforce a Transport Layer Security (TLS) within the SMTP connection, encrypting outbound messages given a trusted security certificate. Of course, this mechanism is easier to set up within partner domains, where you can implement mutual measures.
This is especially useful if you’re working to comply with regulatory regimes’ demands, such as those from HIPAA. After all, users have been known to transmit enormously sensitive and unencrypted data through email clients, simply because they know other way of doing it safely. Where applicable, a universal implementation can avoid these potential mishaps. Similarly, when you’re done with Hub and proceed with introducing Edge Transport, you can secure the organization by limiting external connectivity to the perimeter network.
Another potential area of concern is spoofing. The name might be more adequately rendered as masquerading, as in Mr. Ripley’s sense of the word, but you get the gist: instead of laboring over cryptanalysis, the infamous Mallory can simply pretend to be the sender and/or the recipient, thereby intercepting all the communication.
Of course, most recipients fall for it, failing to recognize that the sender isn’t whom he or she asserts to be. The only exception is when the recipient finds out that the message is curiously addressed to as well as from oneself, and more often than not promising an inheritance from a Nigerian prince to boot.
So we resort to a cat-and-mouse game, in this case a secure form of the MIME standard, which extends plain text e-mails to support such things as non-ASCII text and bodies, attachments, and multi-parts message bodies. Effectively, it is the electronic equivalent of undersigning an e-mail message. Provided that the recipient finds the certificate originator trustworthy, he or she can rest assured that the person ostensibly represented in the From field is really whom he or she purports to be. Both the front-end that is Outlook 2010 as well as its immensely feature-rich accessory, Outlook Web App, support S/MIME natively.
Since the crypto-structure is already in place, there’s no reason why you can utilize it to encrypt the entire message body while you’re at it. However, as with most other modern security implementation, you need to provide a public-key infrastructure (it’s a fancy way to describe arrangements that bind public keys with user identities through certificate authorities). Happily, since Exchange has hopped onto the Active Directory almost a decade ago, we can nick its Group Policy environments when deploying these measures.
Actually there’s more to Active Directory than this: after all, you don’t call it an integrated environment just because a neighbor pops along for a cup of tea. Its Rights Management Services is closely intertwined with the rest of the security policies in Exchange Server.
For example, messages between individuals in the corporate environment might be better off RMS-encrypted than S/MIME-ed. Exchange Server is simply more comfortable with the former: aside from decrypting the messages, it’ll scan for virulent attachments and deliver in a secure manner. You know there’s always the possibility of intra-company virus transmissions: after all, where else would they gain ground in the first place?
Security has its own module in 2010, and within it there are a grand total of 11 security role groups with explicit management roles. There’s an enormous variety of customization options. Simply pick from one, or mix and match to your heart’s content. However, you can’t do it from within the Management Console.
As part of an effort to delineate delegation demarcations, you have to make changes within membership configuration for built-in role groups as well as custom ones from Active Directory Users and Computer. Or the Management Shell if that’s your cup of tea.
Likewise, client access servers with external attack services can be protected with certificates. When users moan about them, you can use the new Certificate Wizard to ease your workflow. As for the ultimate frontier, the great application-layer firewall for HTTP/IMAP/POP connections, there’s always Forefront Protection. All the spam, viruses, phishing scam and assorted toxic internet pitfalls are quite adequately stopped at the border, in a reverse proxy sort of way, and you can deploy them wherever you want: the hub, the edge, the mailbox server, or even on the cloud if you happen to run on one. Of course, in the latter case, you might want to question why you bought into that “we’ll secure everything on your behalf” tagline in the first place.
Of course, it’s a moot question. The important thing is to secure what you’ve got, at whatever cost.
