SYNOPSIS

Exchange Server specifically, and Unified Communications in general, have become increasingly critical components of organizations' infrastructure. They're also carrying increasingly-sensitive information to a growing variety of devices. No longer can we rely on the protection of our intranet to keep these communications safe and private: Our communications now reach well beyond the local network. SSL offers a way to secure the vast majority of our communications, but in modern, multi-server organizations, they can come with a high amount of cost and overhead. In this guide, you'll learn how to use Subject Alternative Name (SAN) certificates to provide the security you need, with less cost and overhead. You'll also learn about other best practices for securing Exchange and Unified Communications platforms, including Microsoft Lync Server, mobile device management, and more.

CHAPTER PREVIEWS

Chapter 1: A SAN Certificate Crash Course

SAN—or Subject Alternative Name—certificates have become increasingly popular in the past few years. Sometimes called wildcard certificates (although that term has a distinct meaning that we'll explore), these special certificates can secure multiple hosts in your organization with a single certificate purchase. In this guide, we'll examine what SAN certificates are, how they work, and specific ways in which they differ from ordinary certificates. We'll look at pros and cons for SAN certificates, and look at ways to mitigate any downsides. We'll also explore how to deploy them in a variety of ways throughout your organization, providing you with better security and potentially much less management overhead.

Chapter 2: Messaging, Unified Communications, Security, and SAN Certificates

More so than in the past, modern messaging environments are full of security risks—and the number of risks seems to grow almost daily. Messaging used to be limited to email, and email access was typically limited to the office network or, at most, to a few dial‐up users. Today, messaging consists of numerous forms of communication including email, real‐time communication, and more, and we're extending the reach of that messaging environment well outside the corporate network. Today's users expect to receive email over the Internet from home and when they're on the road. They want to access email using mobile devices. They want to use public computers in kiosks and hotel business centers. Securing that access is becoming increasingly challenging, and many of the old‐school security techniques can impose significant overhead and cost that, in today's business climate, isn't always welcome.

This chapter will focus on defining these risk areas, with the goal of creating a fairly comprehensive inventory of the risks we need to deal with. We'll also look at some of the general practices currently used by most organizations to mitigate those risks, and explore some of the downsides. Interestingly, SAN certificates—the topic of the previous chapter— offer a solution to a major portion of those risks, and so we'll look at where SAN certificates fit, what they can do, and what they can't.

This chapter will focus specifically on Microsoft‐centric messaging environments: Exchange Server, Office Communications Server (now called Lync), and so on. However, the principles discussed herein are universal: No matter what messaging system you use, you're going to find truths that you recognize and ideas to help make your messaging security better.

Chapter 3: Best Practices for Securing Your Exchange Server

In the previous chapter, we looked at general concerns and techniques around Exchange and messaging security. This chapter will focus specifically on Exchange, with a goal of securing every bit of the Exchange infrastructure. Not every organization will need to apply all the security we discuss here, but you should be able to pick out the pieces that matter to your organization and implement them appropriately.

Business‐Level Concerns for Exchange Security

Before we start actually securing Exchange, we should briefly look at why we're doing so. After all, security is always a compromise between security and convenience. By applying any kind of security to Exchange, we're automatically making it at least slightly harder to manage, maintain, or use. Before doing that, we should examine our reasons for doing so to make sure the tradeoff is appropriate and necessary.

As I outlined in the prior chapter, the main business‐level concern with Exchange is privacy, and there's often an additional need for integrity—making sure that key messages arrive without being tampered, and being able to authoritatively identify the messages' authors. Privacy is the big one, so that's what we'll be focusing on the most.

How we address that need for privacy depends primarily on where we feel our privacy threats originate. Most organizations worry the most about privacy being compromised outside the organization—that is, on the Internet. We'll definitely address that. Many organizations also worry about privacy being compromised inside the organization, which is a completely valid concern. Most intellectual property theft, for example, happens inside the company's office. Many laws and industry rules also focus on maintaining privacy within the organization.

You're going to need to know your organization's specific goals and requirements for security—ideally, communicated as a written security policy—before proceeding with this chapter. Knowing what your organization wants to achieve, from an Exchange security perspective, will let you know which sections of this chapter are applicable to you.

Chapter 4: Best Practices for Securing Your Unified Communications Infrastructure

Exchange Server isn't the only thing we're using to communicate these days. Increasingly, users are also relying on highly‐integrated instant‐messaging tools, such as Microsoft Lync. Originally valued as a way to quickly send short, informal messages to colleagues in realtime, these tools quickly became a synchronous form of email (including email‐like features such as file attachments). Voice and video capabilities came next, and instant messaging clients began to replace phone calls. At the same time, unified communications and unified messaging efforts connected traditional phone systems to Exchange, making a user's "unified inbox" a repository for email, voicemail, and other forms of communications.

As our options for communicating have expanded, so have the ways in which information can be improperly disclosed. It's time to make sure we have a firm grip on what our security goals are for unified communications (UC) and to make sure we're implementing measures to achieve those goals.

Business‐Level Concerns for Communications Infrastructure Security

Our security goals typically look a lot like they did for Exchange itself. As with Exchange security, broader communications security is a compromise: By applying any kind of security to Exchange, we're automatically making it at least slightly harder to manage, maintain, or use. Before doing that, we should examine our reasons for doing so, to make sure the tradeoff is appropriate and necessary. The main reason, of course, is privacy, just as it was for Exchange.

UC can enable users to feel a false sense of security. For example, despite what Hollywood would have you believe, wiretapping is actually quite rare in most countries, and your phone conversations are likely to remain private. Leave a voicemail, however, and it isn't necessarily in the hard‐to‐reach depths of the phone company: These days, it's just as likely to be a voice recording stored in Exchange Server as a message attachment. Move your voice conversation to Microsoft Lync, and you're off the telephone wires completely and instead pumping Voice over IP (VoIP) over your wired and wireless networks. Those communications are actually much easier to tap into. Retrieving your voicemails from email using a mobile device in a coffee shop? Easy to intercept. That's why security is so important across the entire communications infrastructure: Users may instinctively be less cautious because they're using systems and interfaces that seem inherently more secure.