Antivirus and Anti-Spam Strategies and Best Practices

How do I get started with a system for protecting against spam and viruses?

Most organizations already have some type of email security system in place. You may be relying on client-based antivirus software, server-based antivirus software, a Simple Mail Transfer Protocol (SMTP) gateway that handles virus inspection, or some combination of these.

Before moving on, understand that any single solution is probably not sufficient for protecting your servers and users from the crafty devils that are now writing viruses, attacking systems, blasting out spam, or developing phishing schemes. I recently worked with an organization in that needed help with a virus cleanup because the only antivirus solution was on the Exchange server. Although the company had a client-side antivirus solution, it was not distributed to all clients. A few of the clients on the network were infected with a variant of the Sober worm. The company was broadcasting viruses to the Internet almost continually.

At a minimum, a complete solution should address protection for the mail stores on your mail server and protect the client from viruses that they may be exposed to via email messages or a document or a Web page.

At this point, you may be at the "chicken or egg" intersection. Should you develop policies first or put the enforcement mechanism in place first. A definite way to make enemies of your user community is to place restrictions on what they are currently able to do without first informing them. If a user was able to send messages with a 10MB attachment last week, but this week, 10MB attachments are blocked, the user will undoubtedly complain loudly. Users may not be happy with restrictions that are put in place, but if they are informed about them and they are made to understand that these restrictions are necessary to maintain the health and security of the system, they will be more accepting.

The best starting point is to develop a usage policy that will define the restrictions and security constraints for your organization. Defined restrictions should include:

• File and content types that are blocked
• File size and message storage restrictions
• Message content that will be inspected and blocked (such as inappropriate language or inappropriate, non-business content)
• Internal network access types that are allowed (client types and versions)
• Internet email access (client types and versions)

Once the policies are in place and the date that the policy becomes effective is published, you can start enforcement. Choosing mechanisms for email security (and policy enforcement) is also tricky. The process of choosing, building, and tuning the best email security platform for your company is a delicate balancing act between the best possible security, best possible usability, and the most reasonable cost. Given your budget for email security, decide your tolerance for locking down your messaging system and the hardware/software/services products that will help you to do so.

How are spam, viruses, and worms detected?

Just as methods for distributing viruses, worms, Trojan horses, spam, and phishing scams have evolved, so have the mechanisms for detecting them. At first glance, the tools to detect both spam (including phishing schemes) and malicious content (including viruses, worms, and Trojan horses) in an email message seem to be identical. Simply open the message and perform a scan; in reality, the mechanisms are somewhat different and much more sophisticated than even the most advanced virus scanner was just a few years ago.

Virus, Worm, and Trojan Horse Detection

To keep the descriptions reasonably brief, I'm going to bundle viruses, worms, and Trojan horse content into simply the "virus" or malware category. The typical virus that affects many computers on the Internet today is vastly more complex than mail-based viruses such as the Love Bug or Melissa.

Signature or Pattern Detection of Known Viruses

Originally, viruses were detected exclusively through pattern recognition: a file or email messages was opened, and the text of the file or message was compared against a list of strings of known viruses. Although this tactic might have been practical when there was a few thousand known viruses, as of early 2006, Symantec is tracking just over 72,000 total threats. Many of these are not detectable via simple signature scans and pattern detection, as the malware authors have developed methods to change the virus code so that it cannot easily be detected. Viruses that can change their behavior and appearance fall into two categories: polymorphic or metamorphic viruses.

Polymorphic Viruses

With each new infection, polymorphic viruses attempt to change their appearance by swapping their code and inserting padding—such as programming code that does not do anything—into the virus so that it appears to be a different program.

Metamorphic Viruses

Metamorphic viruses mutate in a fashion similar to a polymorphic virus. However, metamorphic viruses can not only switch around blocks of code within the virus but also change program sequences and use different instructions.

Generic Detection

Generic detection is similar to signature detection. If suspected content is not identified using signature detection, the scanning software can look for certain sequences within a possible virus that usually do not change even if the virus is a polymorphic or metamorphic virus.

Heuristic Filters

Heuristic filters are clever in that they can help to find and isolate malware that does not yet have a published signature. They do so by starting with a basic set of rules about the behavior of email-based viruses and use artificial intelligence techniques to make decisions about whether a message contains a virus. Although heuristic filters may catch viruses that have yet to be defined, they are not foolproof and are subject to false positives.

These filters work well with malware detection systems that include a dynamic quarantine. A dynamic quarantine allows scanning systems to conditionally quarantine messages until either the message is manually released by an administrator or is rescanned with new scanning rules or updated virus signatures.

Traffic Analysis

Malware detection using traffic analysis works on the assumption that virus outbreaks generate unusual traffic patterns, such as the same message being sent over and over. Detecting these outbreaks usually involves a combination of artificial intelligence techniques and experienced operator intervention. Also, accurate detection using traffic analysis requires a very large pool of message traffic to analyze. Thus, traffic analysis detection is more accurately performed by a service provider or a managed provider that has access to information about mail being received.

Behavioral Analysis

When using behavioral analysis, a malware detection system creates a "sandbox" for each suspected file or message that it must scan. This sandbox is essentially a virtual computer environment in which the file can be loaded or executed and the behavior monitored. Although this can be a good way to determine whether an unknown attachment or program is carrying malicious code, it requires quite a lot of computing resources and thus does not scale well to large messaging environments on centralized scanning systems. Behavioral analysis scanning systems work best in an environment (such as a managed provider) designed to support largescale scanning operations.

Spam Detection

Detecting spam requires a slightly different approach than detecting malware. Unfortunately, there is much spam and no two spam messages are the same, so signatures are difficult to create. Further, spam can come from many different sources. An alarming trend that has recently emerged is that some organizations that send spam are now in collusion with the authors of viruses and worms. Some virus writers are now writing spam distribution viruses for profit instead of just notoriety.

Virus writers and spam operators are now joining forces to send out spam more quickly and in an attempt to avoid filters.

A virus or worm can deposit a small amount of code that operates in much the same way as viruses such as Sober and SoBig (which have their own SMTP engines.)—except instead of sending out viruses and attempting further infection, this malware sits idle until the spammer is ready to start sending out their next batch of spam mail. When the spammer starts sending mail, they have at their disposal hundreds, thousands, or tens of thousands of computers on every corner of the Internet that can assist in sending messages. These distributed systems can also mount a directory harvesting attack against many mail servers much more efficiently because it takes much longer to recognize what is happening and block the activity.

Real-Time Block Lists

Real-time block lists (RBLs—also known as a real-time black hole lists) are probably the oldest method of spam prevention. RBLs don't assist in any sort of detection, per se. RBLs are lists of known spammers, open relays, dial-up IP addresses, and DHCP addresses. SMTP servers use DNS to query the RBL list to determine whether an IP address is on that list. If the IP address in question is on the RBL list, the connection from that server is rejected.

The accuracy and value of RBLs is widely debated among messaging experts; some messaging administrators consider them to be very effective tools and others consider them less valuable. The primary objection to an RBL is that a mail server's IP address can be erroneously reported to the provider, a mail server can take an IP address that once occupied an open relay, or an entire block of IP addresses may be blocked when only one or two offenders exist in an entire range. Depending on the RBL provider, getting your IP address off the list can be a difficult process.

Keyword Analysis

The earliest anti-spam products that reached the market performed keyword analysis against the content of the message. The earliest generations of these products would simply quarantine, delete, or reject a message if it found one word or phrase that was on the blocked list. This method is very prone to false positives.

Currently, keyword analysis software has taken to creating a rating for the message that indicates the probability that the message is spam—commonly known as the spam confidence level (SCL). Multiple keywords and their proximity to one another are scanned. If the word "free" and "Viagra" are within a few words of one another, the message will have a higher SCL rating than if the word "Viagra" was seen by itself. Of course, again, this can still generate false positives, but at a much lower rate than previous methods.

Bayesian Logic

Bayesian logic is a branch of logic and probability theory named for English mathematician Thomas Bayes. A filter that uses Bayesian logic must be provided with a representative list of the spam that an organization receives (such as asking your users to send all their spam to a certain mailbox). The more spam that you provide to a spam detection system using Bayesian logic, the better it can be trained to detect spam. Some vendors are reporting 99 percent detection rates with less than 1 percent false positive rates when using Bayesian methods. See http://www.paulgraham.com/spam.html for more information about the use of Bayesian logic to detect spam.

Sender Authentication

Recently, efforts by a number of industry leaders have produced mechanisms for verifying that a sending SMTP server is really authorized to send mail on behalf of a domain. Among these are the Sender Policy Framework (known as SPF, Caller ID, or Sender ID) and DomainKeys. Sender ID seems to have produced the most common mechanism of domain verification. SPF requires that all mail senders on the Internet register the names and IP addresses of their SMTP servers that would send email to the Internet. A receiving system accepts a message and can examine the SMTP headers and the source IP address to determine whether the message originated on an authorized server from the supposed sending domain.

Unfortunately, this early in the life of Sender ID, administrators of many valid mail servers have not yet created the necessary SPF records in DNS, and it remains an inaccurate way of validating the sending server. See http://mostlyexchange.blogspot.com/2005/07/sender-id-is-coming-getyour-txt.html for more information.

Other Factors Involved in Spam Detection

Modern anti-spam filters are now using a number of additional techniques to detect spam. For the most part, none of these are used by themselves to determine whether a message is spam, but rather each is used to increase or decrease the SCL of a particular message. These are often used in conjunction with keyword filters, sender authentication, and RBLs. Factors that can raise the SCL for a message include:

• Messages with a blank subject line
• Messages with a missing sender address
• Subject line or a significant portion of the message in all capital letters
• Message contains phrases common to spam messages such as "To no longer receive our offers," "This is an advertisement," "To be terminated from future deployments," and other such phrases
• Messages that are predominantly links and images with very little text in the message body
• Messages with lots of colored text
• Time of day or the day that the message arrives (on the assumption that non-official mail arrives on the weekend or late at night)

How do I choose an antivirus software package for Exchange?

The process of choosing an antivirus software package is almost universal for all mail systems regardless of whether the mail system is based on Exchange. Almost immediately, I can unequivocally state that no matter how good the antivirus software is that runs on your mail servers or within your perimeter network, this does not exclude the need for antivirus software on all client computers on your network. Thus, if you were thinking that you might not need client-side software, put that thought out of your head.

Exchange Server-Aware Virus Scanning Software

If you are choosing software that will run on the perimeter of your network (such as a Simple Mail Transfer Protocol—SMTP—scanning system in your DMZ), the decision points are going to be almost identical to the decision points for choosing an Exchange-based antivirus software package. The only difference is that the software that runs on your Exchange Server must be Microsoft Exchange AVAPI-aware (antivirus application programming interface). For Exchange 2000, the software must support AVAPI 2.0 and for Exchange 2003, the software must support AVAPI 2.5.

You should never load more than one Exchange AVAPI-aware antivirus package on an Exchange Server.

Software that uses the Exchange AVAPI is written so that it can open individual mailboxes and scan the messages and attachments found in the mailbox. Further, AVAPI can prevent the user from even accessing a message until it has been scanned. AVAPI 2.5-aware software on Exchange 2003 has been improved so that it can scan messages not only in the information store but also as the messages traverse the SMTP queues. This is useful on bridgehead servers.

The only way to scan messages in an Exchange database is to use an AVAPI-based software package. File system-based virus scanning solutions such as Symantec Antivirus Corporate Edition, Kaspersky Lab's Anti-Virus, F-Prot Antivirus, and so on do not have the necessary data structures defined that would allow them to scan data in the mailbox stores or to clean a virus that they might find in the mailbox store. Thus, if a file system-based virus scanner were to make changes to an Exchange mailbox store, the file would be permanently damaged and require restoration from backup.

File system-based antivirus scanning software must never be used to scan an Exchange mailbox store, public folder store, or transaction logs. Corruption is almost guaranteed.

Features and Decision Points

When choosing a virus scanning software package, I tend to become a "feature creep." I have worked in so many environments and have had a number of different requirements for email antivirus scanning software packages both on Exchange Servers and systems that work within the perimeter of your network. Some of the features are more important that others. I have tried to rank my considerations for evaluating an antivirus software package based on what has been most important to the organizations in which I have helped evaluate or implement these packages:

• Configure signature and scanning engine updates hourly or some customizable time interval.
• The ability to use more than one scanning engine and signature set in a single software package.
• The ability to apply file attachment restrictions so that messages carrying certain types of file attachments can be quarantined or deleted. The file attachment list must be customizable based on an organization's policies.
• Override features so that messages with specific characteristics, such as a specific subject, can be stopped in case of a zero-day attack.
• The ability to control actions for different types of threats, such as the ability to clean certain types of threats but delete mass-mailing viruses, Trojan horses, worms, and so on rather than passing the cleaned message on to the user.
• The use of real-time block list (RBL) functionality.
• Centralized reporting and quarantine management for organizations with more than one mail server or SMTP gateway.
• The ability to control and schedule background scans of mailbox stores.
• Intelligent attachment scanning to determine whether a file has been renamed. This is useful, for example, in the case where you do not allow EXE files but a user or a virus/worm has renamed the EXE to TXT but has instructed the user to save it and rename back to EXE.
• Versatility of notification features such as email notifications and event log notifications. Custom notifications are also a compelling feature if you can customize messages such as notification of rejected attachments.
• Automatic management of quarantine folders (purging quarantined items after so many days) and virus logs.
• Versatility of reporting and monitoring features.
• Allow multiple layers of compressed attachment scanning such as scanning a ZIP file within a ZIP file.

Over the past few years, there has been a convergence of antivirus software packages with other message hygiene solutions such as anti-spam and content inspection systems. Although this convergence certainly reduces the amount of hardware and software that you have to deploy, consider this convergence a convenience but don't sacrifice the features and functions you need from your antivirus system merely so that you don't have to deploy as many pieces of software.

What options are available for antivirus and spam protection?

One of the top issues that IT management now reports is the challenge of reducing spam and preventing the spread of hostile content such as viruses and worms. IT management is faced with the overwhelming cry of "Stop this spam!" from the user community and the almost equally loud cry of "Keep viruses and worms off the mail system" from the information security staff.

The number of solutions on the market is almost staggering and each claims to be the ultimate solution to the spam or virus problem. In the past few years, a convergence and consolidation of technologies has happened in the field of message hygiene. Now, most products offer a cradleto-grave solution for fighting spam and viruses rather than requiring separate components, appliances, services, or software packages.

Managed Providers

In the past few years, the trend towards managed providers in the fight against unwanted email content has taken a positive turn. Managed providers handle all your incoming mail by having your DNS MX records for your Internet domain pointed to their Simple Mail Transfer Protocol (SMTP) servers. These servers perform message hygiene/content inspection on messages intended for your mail system, then pass the mail on to your mail system.

IT managers who not long ago would have considered it an unacceptable practice to have their email relayed through third party are now embracing the concept. There are clearly several advantages to using a managed provider:

• Managed providers are usually staffed 24 × 7.
• Managed providers offer almost immediate response to day-zero threats.
• Managed providers have better scalability and, often, multiple locations to provide fault tolerance.
• An organization's mail server can be configured to accept only inbound mail from the provider's SMTP server, thus reducing the potential for a Denial of Service (DoS) attack against that organization's SMTP servers.
• Spam and viruses are filtered by the managed provider and do not ever enter the organization's DMZ or mail servers. Thus, bandwidth, disk space, and system resources are not consumed by unwanted email.
• In the event of Internet connection or mail server failures within an organization's network, the managed provider can queue mail until service is restored.

One weakness of some of these providers is that they may not have a listing of your valid email addresses and thus will not reject mail for your invalid recipients. Even for a small organization with spam problems, this shortcoming can generate a lot of inbound mail traffic as spammers use dictionary spam methods to send mail to random names. When choosing a managed provider, confirm that they can synchronize with your directory or that you can upload a list of valid email addresses to their system.

Protection in the DMZ

A fairly common method of protecting SMTP mail systems is to provide an SMTP relay server in the organization's DMZ or perimeter network. All inbound mail is delivered to the SMTP relay. The SMTP relay in the DMZ performs the message hygiene functions.

In the past, this SMTP relay may have been something as simple as a UNIX or Windows server that performed only message forwarding; the system's hardware may have been an Intel or RISC machine. These systems are potentially far more complex than they were just a few years ago. Although Windows- and UNIX-based servers may still run the software, it now consists of complex message hygiene functions that perform virus detection and spam filtering. The message hygiene system may run on a regular server, but a more common solution is for vendors to package the software on vendor-provided hardware that fits in a 1U or 2U rack space. These software/hardware appliances still run a hardened version of Windows or UNIX, but they hide the additional complexities of these machines from the customer.

The advantage of providing an initial point of message hygiene in the DMZ network is that all inbound mail is inspected before it ever makes it to the mailbox server. The message hygiene system also protects the internal mail servers by ensuring that no inbound SMTP connection from the Internet arrives directly on the mailbox servers.

Protection on the Mail Server

Message hygiene systems that run directly on the mail server have been around for several years. Some of these systems are not truly integrated with the mail system and simply perform SMTP content inspection on inbound messages before passing the messages on to the mail server's SMTP service. Other systems integrate with the mail system's SMTP service or message storage system.

The Exchange 2003 antivirus API (AVAPI) enables message hygiene systems designed for Exchange to inspect messages as they arrive via the Windows SMTP service or once the message is moved into the information store. AVAPI software will also prevent a user from opening a message until it has been inspected by the message hygiene software.

Although installing message hygiene software directly on the mail server is an important part of a good security practice, it should be considered a second-tier defense. Multiple layers of protection are important. The first line of defense should be an inspection system provided by a managed provider or in the organization's DMZ.

Topic 5: Firewall Strategies and Best Practices

What features should I look for in a firewall?

Choosing a firewall is one of the most important decisions an organization makes with respect to keeping their network safe from outside intrusion. Organizations that have been connected to the Internet for a number of years may be on their third- or fourth-generation firewall. Today's firewalls have far more features than their predecessors did a few years ago. This is due, in part, to customer demand for more functionality and partially due to the evolving threats that are an inherent part of being connected to the Internet.

For a person that does not work with firewalls on a regular basis, figuring out which firewall features are necessary can be a mind-numbing task. For this reason, discuss your security and protection needs with a person knowledgeable in firewalls. Otherwise, you may select a solution that does not meet your existing needs or won't accommodate changes you may require in the near future.

Basic Firewall Features

Firewalls started out as devices that were not much more complex than a simple router. A term that would describe an early firewall is a filtering router. This device could view inbound and outbound IP addresses and decide whether the source and/or destination IP address should be forwarded or discarded. Many routers now actually include this feature.

Application protocol filtering firewalls can examine not only the source and destination IP address of inbound/outbound IP data but also the source and destination port numbers that the application data is using. So, for example, a firewall that is capable of this type of filtering might have a rule that allows inbound port 443 (Hyper Text Transfer Protocol—HTTP—using Secure Sockets Layer—SSL) but only to a specific IP address on the internal network.

Another evolution of firewalls is the stateful inspection feature. Stateful inspection (also known as dynamic packet filtering) is a feature of more advanced firewalls through which the firewall keeps track of inbound and outbound packets over time and analyzes whether the requests and responses are valid for the type of traffic that is being generated. The firewall keeps track of the "state" of each connection and determines whether the traffic is valid for a connection in a particular state.

Any firewall that you choose should at least offer these features. Unless you are looking at very obscure and immature products, all firewalls on the market today support these features.

Common Firewall Configurations

There are a couple of common configurations for firewall deployments. The first of these (and usually the simplest) is a single firewall that provides an internal network connection as well as an external network connection, and a demilitarized zone (DMZ) network connection (the DMZ is often called a screened subnet or a perimeter network).

Figure 5.1 shows an example of a single firewall with a DMZ port. The DMZ contains servers that should be accessible by users from the Internet. Internet users would be able to access the servers in the DMZ but would not necessarily be able to access servers on the internal network.

However, the DMZ servers may be capable of connecting through the firewall to internal servers for data that a user from the Internet requests. Servers with data (such as Exchange servers or domain controllers) should not be placed in the DMZ because the possibility of these servers being compromised is slightly higher than for those on the internal network.

Figure 5.1: Single firewall with a DMZ port.

A second possible configuration for firewalls is to use more than one firewall. Figure 5.2 shows a multi-firewall configuration. Often, when using multiple firewalls, the internal firewall will be from a different vendor than the external firewall. This setup helps mitigate the possibility of an attacker penetrating the network as the result of a weakness in one firewall because the weakness would have to exist on both vendors' firewalls. Sometimes the external firewall is a simple firewall appliance and the internal firewall is a software-based and/or application-layer firewall and thus allows more detailed and complex configurations.

Figure 5.2: Multiple firewall setup.

Appliances vs. Software Firewalls

A single firewall in the configuration in Figure 5.1 may be a firewall "appliance." An appliance firewall is term given to a "blackbox" type solution where the hardware and software are bundled and sold as a single unit. These appliances are often designed as "hardware only" solutions and built to take up as little as 1U of rack space. Although they are not really "hardware only," the illusion of it being hardware only is applicable because you purchase the appliance with the software preloaded on an internal hard drive or firmware.

Hardware-based firewall appliances are desirable for some organizations because they are plugand-play solutions; you simply plug in the device and turn it on. Of course, things are never that simple, but that is the way they are often marketed. One of the most common firewall appliances is the Cisco PIX firewall that Figure 5.3 shows. Other common hardware firewalls include SonicWall, Nokia, NetScreen, and Watchguard.

Figure 5.3: Cisco PIX firewall.

Appliance firewalls are useful because they are shipped as a self-contained unit and usually have out-of-band management features that allow them to be configured via a modem or terminal connection. Firewall appliances are usually not as versatile as a software-based firewall.

Although all firewalls run some type of software and they run on some type of hardware, a "software only" firewall is a product on which you to choose your own hardware on which the software will be installed. Software firewalls usually run on top of a Windows or UNIX operating system (OS). Often, with a software-based firewall, you will have more choices as to what types of add-on products you can purchase and are allowed to work with the firewall.

Application-Layer Firewalls

Simply put, an application-layer firewall is a firewall that can inspect inbound and outbound content at the application layer of the Open Systems Interconnect (OSI) or Department of Defense (DoD) protocol models. An application-layer firewall can examine data such as HTTP headers or SMTP commands in order to determine whether that type of traffic is allowed. For example, you can configure an application-layer firewall so that it will allow outbound HTTP from your users, but will block HTTP data that contains instant messaging content.

Firewall products such as Microsoft ISA Server and Check Point Firewall-1 can even inspect Remote Procedure Call (RPC) traffic to determine whether it is valid traffic for an Exchange Server/Outlook client session and either permit the communication or not.

Features, Features, Features

When you start shopping for a firewall, you want to make sure that it will meet your immediate and near-term needs. It is useful to be able to also project your long-term networking needs, but the firewall should at least accommodate you for the next 1 to 2 years.

Most any modern firewall product you are going to consider is going to include basic features such as IP filtering and port filtering, but what other features may be important? The following list highlights features that you might require or just find useful:

• Make sure the firewall will support the maximum number of concurrent connections you plan to have.
• Will the firewall provide virtual private network (VPN) support and if so, which VPN protocols do you need (Point to Point Tunneling Protocol—PTP, Layer-2 Tunneling Protocol—L2TP, Internet Protocol Security—IPSec)?
• Make sure the management interface is easy to use and is consistent with other interfaces that your IT department currently manages. For example, if you have UNIX and Cisco router administrators on staff, they will easily adapt to a command-line interface of a product such as the Cisco PIX. However, if you are entirely a Windows shop, GUI-based interfaces such as the Microsoft ISA server may be more applicable.
• Is high availability, scalability, and load-balancing a factor for your network? Make sure the firewall you choose can be load balanced.
• Does the firewall offer application-layer inspection? It should be able to inspect the various protocols you will be supporting such as inspecting HTTP headers or SMTP traffic.
• Does the firewall act as a Web caching proxy server for outbound HTTP requests? • Can the firewall act as a reverse proxy server for inbound HTTP/HTTPS requests?
• Does the firewall provide logging, intrusion reports, and usage reports?
• What additional features can be added to the firewall that may meet your security requirements? These might include virus, hostile content, and spam filtering as well as Web site blocking.

What are some of the special considerations when Outlook clients are separated from Exchange Server by a firewall?

If you have ever tried to put an Outlook MAPI client on the other side of a firewall from the

Exchange Server, you have probably experienced some of the same frustrations as your fellow Exchange administrators. Opening ports through the firewall for a POP3, IMAP4, or Web client is much simpler than opening ports for a MAPI client due to the complexity involved with remote procedure calls (RPCs).

For a long time, an acceptable practice was to allow remote Outlook clients to access Exchange Server by opening all the necessary RPC ports. Due to a number of RPC-based worms, this is no longer an acceptable practice. However, in midsized and larger networks, a concept that is gaining popularity is the concept of the data center firewall. Figure 5.4 shows an example of how this might be deployed.

Figure 5.4: Implementing a data center firewall.

In addition to the firewall that serves to protect the entire network, an additional firewall (or a filtering router) is placed between the data center network and the networks that host the users. This provides an additional layer of protection from viruses, worms, or other types of security compromises that can occur on the end-user network. Figure 5.4 may seem like a lot of routers, but in a larger network and academic networks where it is difficult to control the configuration of the desktop computers, this additional layer of protection between the users and the servers can give you peace of mind knowing that the critical components of your network are better protected.

To view the RPC ports that are opened and ascertain which ports RPC services are using, you can use the Port Query utility and query the RPC end-point mapper. Figure 5.5 shows the PortQueryUI.exe utility; you can download the Port Query graphical utility at http://tinyurl.com/cbk9n. Microsoft Knowledge Base article 832919 "New features and functionality in PortQry version 2.0" has more information about the PortQryv2 command-line utility.

Figure 5.5: Port Query utility.

Configuring Exchange Servers and Active Directory for Firewall Support

Outlook MAPI clients that use RPCs to communicate with the Exchange Server require access to the Exchange Server's port 135, the RPC end-point mapper, plus the directory service referral port, and the information store. In addition, Outlook requires RPC access to the Global Catalog (GC) servers that are referred to Outlook by the Exchange Server to which they connect. Unfortunately, by default, these RPC ports are not fixed to the same port number; instead, they are dynamic and may be different on different servers or when the server reboots. However, the ports can be statically mapped so that they use the same port number each time.

Exchange Server Ports

To configure an Exchange Server so that the RPC ports that are used by Outlook clients can be accessed through a firewall, there are three ports that must be statically mapped. The first of these is the System Attendant's referral interface. This is the component that Outlook 2000 and later clients use to receive referrals to GC servers. Create a registry value of type REG_DWORD called TCP/IP Port in the HKLM\SYSTEM\CurrentControlServices\MSExchangeSA\Parameters registry key. Set this newly created value to a decimal number above 5000. In this example, I'll use port 5001.

Next, the System Attendant's Name Service Proxy Interface (NSPI) needs to be statically mapped. The NSPI proxy interface is used by Outlook 98 and earlier clients that cannot be referred to a GC. The NSPI proxy interface performs directory lookups on behalf of the Outlook client. Create a registry value of type REG_DWORD called TCP/IP NSPI Port in the HKLM\SYSTEM\CurrentControlServices\MSExchangeSA\Parameters registry key. Set this value to a decimal number above 5000. In this example, I'll use port 5002.

Finally, the TCP port that the information store uses has to be statically mapped. Create a registry value of type REG_DWORD called TCP/IP Port in the

HKLM\SYSTEM\CurrentControlServices\MSExchangeIS\ParametersSystem registry key. Set this value to a decimal number above 5000. In this example, I'll use port 5003. Once the ports have been set, the System Attendant and the Information Store services will need to be restarted.

For MAPI clients to communicate with Exchange Server, the firewall will have to permit ports 135, 5001, 5002, and 5003 be opened to all mailbox and public folder servers. However, there will also need to be ports opened for clients to communicate with Active Directory (AD) GC servers.

Domain Controller Ports

Outlook 2000 and later clients are referred directly to a GC server. By default, the Exchange Server will refer the Outlook clients to GC servers that are in the same AD site as the Exchange Server. For this reason, Outlook clients may need to access any of the GC servers in the site with the Exchange Server.

Outlook can be configured to use a specific GC server or to use a closer GC instead of the one to which it is referred. For more information, see Microsoft Knowledge Base article 319206 "How to configure Outlook to a specific global catalog server or to the closest global catalog server."

Like the information store service and directory service referral ports on an Exchange Server, the AD RPC/MAPI port is dynamic and may change each time the domain controller is restarted. To statically map the RPC port for a domain controller, create a registry value of type REG_DWORD called TCP/IP Port in the HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry key. Set this value to a decimal value between 1024 and 5000; in this example, I am using port number 5000. Microsoft recommends the port range 1204 to 5000; see Microsoft Knowledge Base article 270836 "Exchange Server static port mappings" for more information. Once the domain controller is restarted, it will use port 5000. The firewall will need to have ports 135 and port 5000 opened between the clients and all GC servers that they may use.

If you don't want to open the RPC ports for the GC servers, you can disable the referral interface and Outlook clients will use the NSPI proxy interface. This will slightly increase the load on the Exchange Server, though. To disable the referral interface, create a registry value of type REG_DWORD called No RFR Service in the HKLM\SYSTEM\CurrentControlServices\MSExchangeSA\Parameters registry key. Set this value to 1 to disable the referral service or 0 to enable the referral service. Doing so will not take effect until the System Attendant has been restarted. After the restart, Outlook clients will not need direct access to GC servers.

For more information about how Outlook clients use the NSPI proxy or the directory service referral interface, see Microsoft Knowledge Base article 302914 "How Outlook 2000 Accesses Active Directory".

Alternatives to Opening RPC Ports

If opening up the RPC ports through your firewall to your Exchange Server is not a viable option, you have a few alternatives. For Outlook 2002 and earlier, the most common method of allowing Outlook access to an Exchange Server was to require the user to open a VPN connection. Outlook 2003 allows RPC requests to be encapsulated in HTTP or HTTPS packets and passed through a firewall using port 80 or port 443.

Some firewalls provide an RPC filter that will dynamically open required ports on the external interface of the firewall and pass the correct port requests for Exchange services such as the directory interface or the information store into the internal network. Firewalls such as the Checkpoint Firewall-1 and Microsoft ISA Server provide an RPC publishing feature that supports Outlook. The ISA Server's RPC filter performs application-layer inspection of inbound RPC connections prior to the connection being passed to the Exchange Server, thus ensuring that only legitimate RPC traffic is passed to the internal network and only to Exchange Servers.

Is Outlook using RPC over HTTP the right solution for my remote users?

One of the most compelling features of Exchange 2003 when combined with Outlook 2003 is the ability to use the RPC over HTTP feature. RPC over HTTP enables an Outlook client to encapsulate RPC data inside HTTP frames. The only port that is required to be opened on a firewall is the HTTP or HTTPS ports. That very description helps to clearly delineate exactly who should use RPC over HTTP. RPC over HTTP is intended for Outlook 2003 users that are separated from their Exchange 2003 servers by a firewall such as are shown in Figure 5.6. Opening the necessary RPC ports between the client and the server is considered a security risk.

Figure 5.6: Typical RPC over HTTP implementation.

RPC over HTTP can be deployed for Outlook 2003 clients on a local area network (LAN), but it is best suited for clients connecting to an Exchange 2003 Server when separated by a firewall.

RPC over HTTP can greatly reduce the support necessary for virtual private network (VPN) users because a VPN is no longer required for Outlook 2003 users. Once my own organization had implemented RPC over HTTP, this cut my use of the company VPN by 95 percent; I used a full-time VPN connection almost exclusively for Outlook access to the Exchange Server.

Switching users from a VPN connection on their home or laptop computer to an RPC over HTTP connection only to Exchange not only provides users the functionality they require from their mail system but also helps improve security on the internal network. The RPC over HTTP session is only established to an RPC over HTTP proxy and limits the remote client's potential access to other hosts on the internal network. This configuration for remote Outlook 2003 clients potentially also reduces the number of ports that need to be opened on a firewall and thus improves security.

However, a common misconception is that there is less overhead associated with an RPC over HTTP connection than there is a traditional RPC over TCP/IP connection. The amount of data transferred between the client and the server is almost the same.

A possible downside is that configuring RPC over HTTP is slightly more complex than configuring Outlook 2003 to connect directly to the Exchange Server. If the option is either to use RPC over HTTP or a VPN connection, the benefits and reduced complexity will outweigh the additional configuration. To decide whether RPC over HTTP can be implemented for your organization, a couple of factors need to be considered. They include:

• Does your server infrastructure have the minimum software versions required?
• Do the clients have the minimum software versions required?
• Can you deploy reverse proxy solutions for RPC over HTTP to provide an additional layer of protection?

Requirements

Prior to implementing RPC over HTTP, you need to make sure that all the components within your network meet the minimum requirements. The following is a checklist of the minimum requirements for the servers on your network:

• All Exchange Servers must be running Exchange 2003, but I strongly recommend Exchange 2003 SP1 or later due to improvements in configuration. Exchange 2003 must be running on Windows 2003.
• All domain controllers/Global Catalog (GC) servers must be running Windows 2003.
• A server on the inside of your network must be designated as the RPC Proxy server. In a small, single Exchange Server environment, the RPC Proxy service will run on the same server as the Exchange Server. In a large environment, you should use the same server or servers on which the Exchange 2003 front-end servers run.
• The RPC Proxy server must be issued an SSL certificate, and the certificate authority that issues the certificate must be trusted by all client computers.

On the client side, there is also a minimum configuration. The following are requirements for the client:

• Outlook 2003 (recommend Outlook 2003 SP1 or later)
• Windows XP Pro SP1 with the hotfix in KB 331320, though that hotfix is applied in Windows XP SP2.
• The certifying authority that issued the SSL certificate for the RPC Proxy must be trusted by the client.

Deployment Scenarios

If you start putting together the potential permutations of configuration possibilities for RPC over HTTP, you will end up with almost as many combinations as you do organizations that want to deploy it. Figure 5.7 shows a typical deployment of RPC over HTTP for Internet-based clients; this environment can easily be scaled up for larger environments or scaled back for single-server organizations.

Figure 5.7: Typical deployment of RPC over HTTP with front-end server and ISA Server.

One of the most important security precautions that is in place for the organization in Figure 5.7 is that a reverse proxy server such as ISA Server is used to publish the RPC over HTTP resource to the Internet. Internet clients do not connect directly to the RPC Proxy server running on the Exchange 2003 front-end server; instead, they connect to the ISA Server. The ISA Server authenticates the connection, offloads the SSL overhead, and validates URLs before passing the RPC over HTTP data on to the RPC Proxy server.

Additional security and protection for your internal Exchange resources can be provided by using a reverse proxy server to publish RPC resources to the Internet.

Figure 5.7 can easily be scaled up to larger organizations by merely adding additional ISA Server or reverse proxy servers in the DMZ and configuring load balancing and then adding Exchange 2003 front-end servers on the internal network.

Some organizations don't have the level of complexity on the firewall side of things. Figure 5.8 shows an internal firewall, an external firewall, and an ISA Server inside the perimeter network. There is also a front-end server on the internal network. In a single-server environment, the organization may have a single firewall and Exchange Server. RPC over HTTP can easily be scaled back to this point and still provide reverse proxy security. Figure 5.8 shows how a small organization can use RPC over HTTP just as securely as a large organization.

Figure 5.8: Single server and single firewall scenario.

In this scenario, the Exchange 2003 Server also has the RPC Proxy component installed, so only a single server is required.

There are a number of possible deployment scenarios for RPC over HTTP depending on the size of your organization. For more information, read "Exchange Server 2003 RPC over HTTP Deployment Scenarios"

What are best practices for configuring a firewall to support better email security?

Your organization's firewall is the first line of defense against intruders, Denial of Service (DoS) attacks, and unwanted messaging content. Depending on how you look at things, the firewall is also the Internet's first line of defense against your network as well.

There are several actions you can take when configuring your Internet-facing and internal firewalls (if applicable) to provide better messaging security:

• Configure a DMZ or perimeter network to support Simple Mail Transfer Protocol (SMTP) content-inspection systems or HTTP reverse proxy servers.
• Open only the necessary ports between services in the DMZ and the internal mail system resources. For example, don't open inbound port 25 to all internal SMTP servers if the only servers that should be accepting inbound SMTP mail are the Exchange frontend/bridgehead servers.
• Block outbound SMTP message traffic so that only authorized hosts can send SMTP mail to external hosts. Doing so will prevent a client that may become infected with a worm that has its own SMTP engine from sending mail to the Internet. Having your ISP or a business partner call you to inform you that one of your computers is sending out a virus is pretty embarrassing. Most users should never have direct outbound SMTP access. If this is required, have them configured to use your content inspection systems for outbound SMTP relay.
• If possible, provide SMTP application filters that inspect inbound SMTP packets for potential DoS attacks, directory harvesting, or other hostile SMTP traffic.
• If you use a managed provider, configure inbound SMTP to be accepted only from the IP addresses of your managed provider's servers. Your managed provider can give you this list as well as notices of changes to the list.
• Confirm that the firewall's external IP addresses have DNS PTR records created with the owner of the reverse lookup zones. These IP addresses are often evaluated by remote SMTP servers and potentially rejected if there is not a valid PTR record.

Topic 6: Protecting and Controlling Sensitive Information in Email

What are common methods for data to leak out of a company?

Email systems have provided both an incredible platform for moving important data between an organization's knowledge workers and a method of quickly disseminating confidential information to unauthorized parties. Email has become one of the most common vectors for sensitive information being leaked to external organizations whether the intent is malicious or accidental. Although this is information that many IT managers and even company executives would like to ignore, a large portion of security breaches, systems being compromised, or data being leaked actually comes from within the organization. The 2002 Computer Crime and Security Survey conducted by CSI and the San Francisco office of the Federal Bureau of Investigation (FBI) Computer Intrusion Squad estimate that approximately 60 percent of security breaches come from within an organization's network.

Once information leaves your organization, you no longer have any control of the dissemination of that information.

Content filtering vendor SurfControl conducted a poll recently that found that nearly 40 percent of email users have received confidential information that was not meant for them. Another 15 percent of respondents admit accidentally sending confidential information.

A 2004 report by Jupiter Research found that large organizations were reporting email forwarding as being among their top three security breaches. Some IT administrators, managers, and executives will immediately think of confidential information that could leak out of the organization and harm the organization. Others may not immediately feel like they have any information that could be compromised. However, if you think about it, all organizations have accounting information, internal plans for the future, competitors, and human resources information. What are some examples of information leaks that can easily occur via email? The following list highlights answers to that question:

• An employee may intentionally seek to steal trade secrets of an organization by using the company email system to send client lists, sales information, pricing information, insider information, marketing plans, and so on to a competitor.
• Instead of using the internal email system, an employee may use their own personal Webmail account to upload information to the Internet and send that information to others, thus bypassing internal content inspection controls that you have put in place.
• Information that is passed between any two users within your company can accidentally be misaddressed and include someone on the outside.
• Future plans or internal problems may be leaked to the media by a disgruntled employee.
• Human resources information may be sent intentionally or unintentionally to other employees or outsiders.
• Employees send confidential information to someone that they believe to be trustworthy, but the recipient misuses that information.

Ramifications of Data Leaks

No one wants their internal company problems or sensitive information to appear on the front page of the Wall Street Journal, but leaks happen and they happen frequently. What are some of the ramifications of important data being leaked to outside sources?

• Leaked information can cause enormous financial losses. If the company is a publicly held company, a leak can (and usually does) extend to the price of the company's stock.
• Public embarrassment and a loss of customer confidence can occur when information is disclosed.
• Reputations and credibility can be damaged.
• Legal action can be taken if the disclosure causes a law to be violated such as a privacy law. This legal action can come in the form of civil or criminal action based on the situation and the laws that were violated.
• Employee confidence can be eroded if preliminary company plans are leaked to the media. In a few situations, this has caused key employees to resign in order to avoid future problems.
• In the case of government information, such as military plans or intelligence gathering, lives can be placed at risk.

Depending on the type of information that is leaked and to whom the information is disclosed, a company may not survive. For example, information that is leaked to a competitor who can make better use of something such as marketing information and thus beat your company to market with your new "key" product.

Is S/MIME the Answer?

The S/MIME standards provide an email user with properly equipped client software to digitally sign a message (to authenticate the sender) and to digitally encrypt the message (to protect the content during data transmission and while the message is stored). Upon initial examination, you may be tempted to think that implementing S/MIME is the total answer to your data protection needs, and S/MIME messages that are encrypted will protect the message from unauthorized access. However, once a message and its attachments are sent to someone using S/MIME encryption or signing, the recipient still has complete and total control of that messaging content.

The Bottom Line

What is the bottom line? Employees must be trustworthy. Although mechanisms—such as authentication, SSL, S/MIME encryption, content inspection, and enterprise rights management—can be put in place to support your security policies, a determined user that is given access to this information can still disclose it. Anyone given access to sensitive information must be made to understand the ramifications of accidental or intentional information disclosure. Furthermore, there must be consequences that employees face if they are either careless or malicious with sensitive information.

What is Enterprise Rights Management?

Rights management broadly describes protection technologies for all types of digital media, whereas Enterprise Rights Management (ERM) can be considered a business application of rights management. ERM is considered a subset of the rights management umbrella, but is more focused towards corporate or government applications. ERM is closely related to Digital Rights Management (DRM), but the term DRM is more closely identified with the protection of commercial media content such as music and movies.

In one form or another, rights management technologies have been around for a long time and have other sibling technologies such as copy protection and technical protection measures. Content protection of digital media such as DVD movies, CD music, and even software has been available for quite some time. For years, some specialized software packages have required a "dongle" or USB key be attached to a computer before the software can be used. As copying technologies have become more prevalent and the ability to distribute content quickly to many people has emerged, protection of digital media has become even more important.

The popularity of the Internet and the emergence of digital media have given new cause for concern about copying and distribution of protected media because a copy of digital media is a perfect copy, unlike a copy of a video tape (the quality of a video tape is not as good as the source). A DVD or CD without protection can quickly and easily be copied and shared with thousands of Internet users through peer-to-peer file-sharing programs. Software that was licensed for one computer can be installed and used on other computers if it is not adequately protected.

ERM has evolved from the concept of DRM because sensitive documents, presentations, spreadsheets, and other organizational information can easily be accessed by unauthorized persons, accidentally or intentionally passed on to others, or modified without authorization. ERM technologies focus on business applications and allow the creator of digital content (specifically documents, spreadsheets, presentations, and email) to encrypt the content they create and specify access privileges that the other users have to this content. Implementations, features, benefits, and file formats/applications supported vary from one vendor to the next. Common features that are found in ERM solutions include:

• Encrypting content so that only authorized persons can consume that content
• Controlling the types of access the content consumer may have, including read, copy, modify, print, or forward
• Specifying expiration dates after which the content is no longer accessible by the consumer or after which new content supersedes the existing content
• Allowing persistence of the digital rights whether the file or email message remains within an organization's boundaries, if it is burned to optical media, emailed to users in another organization, or stored on portable media (USB drives)
• Revoking or modifying access rights if the content owner deems this necessary to prevent further access
• Providing access and audit trails

The benefits of these features are clearly obvious. Content creators can control the content they create both within their corporate boundaries as well as outside. Even if USB media is lost, a laptop is stolen, content is accidentally forwarded to unauthorized persons, or content is intentionally passed on to someone the content creator did not intend, the content remains protected.

ERM solutions provide an organization with a persistent mechanism of policy enforcement regardless of where the data is accessed.

When an author creates protected media, an ERM system enables them to specify restrictions that are placed on the users of that content. Some ERM systems include the ability to revoke rights later after the content has been distributed and enable auditing usage of protected content. However, the application (and possibly the operating system—OS) must support the ERM system being used.

Applications must be enabled to perform and enforce rights management functions. Information Rights Management (IRM) is functionality that is built-in to an application to allow creation of or viewing of ERM-protected content. Figure 6.1 shows an example of permissions that can be assigned to a document by the rights management components of Microsoft Word 2003 and Windows XP Pro.

Figure 6.1: Defining permissions on a document in Microsoft Word.

Once these permissions are assigned, the document is encrypted and the access restrictions that have been placed on the document follow the document wherever it may be sent; this is true even if the document leaves an organization's internal servers.

S/MIME messaging protects email message content from authorized viewing in transit and while stored. ERM solutions protect additional content types and provide limitations as to what the recipient can do with that content. S/MIME and ERM can be used together when it is necessary for attestation of message content due to regulatory requirements such as Sarbanes-Oxley.

Components of an ERM System

Understanding the various components and requirements of an ERM system can better help with the planning and deployment of an ERM solution for your organization. There are both client- and server-side applications as well as components such as digital certificates and, of course, the protected content.

RMS Enabled Applications

For users to protect the content they create, the application they are using must be rights management enabled. Applications such as Internet Explorer (IE—through an add-on) and Microsoft Office Professional 2003 are automatically capable of using Microsoft's Windows Rights Management Services (RMS) ERM solution. Liquid Machines extends Microsoft's baseline support with extensions for earlier versions of Microsoft Office, Adobe Acrobat, and other file types and provides RMS support for RIM Blackberry devices. The Windows Vista operating system (OS) will include features that allow any document type to be converted to an XPS document and to be protected with RMS. Vendors such as Authentica provide plug-ins for Microsoft Office and Adobe Acrobat applications that work with the Authentica Policy Server.

RMS Client Software

Windows client OSs prior to Windows Vista that are going to participate in an RMS-trusted environment must have the client software installed. RMS-enabled applications must interact with this software when creating protected content or when the recipient of protected content consumes that content. The client software provides the necessary APIs for the RMS-enabled application, handles communication with the RMS server, stores certificates, and handles client authentication. The person receiving the RMS-protected content is referred to as the recipient in some ERM solutions, while other solutions may refer to the RMS client software as the recipient.

RMS Server Software

The RMS server software handles the certification of trusted entities, licensing of rightsprotected content, and authentication of credentials as well as validates rights account certificates. In some implementations of ERM solutions, RMS servers may have multiple roles, such as the user provisioning and content licensing server. The server that issues usage licenses is called the License Server.

The RMS server creates the rights and policies that can be applied to content and pushes these to the client; in addition, the server provides a repository for the encryption keys that are used to encrypt the protected content, a method of identifying and authenticating users such as or an Active Directory (AD), and a license generator. The Windows Rights Management Services support only AD authentication, but some other solutions support generic LDAP authentication.

Keys and Certificates

The RMS client software works in a similar fashion to PKI applications in that it uses public and private keys for client/server authentication and for protecting content encryption keys. There are a number of certificates that are used by the RMS client software to protect the encryption keys, authenticate to the rights management server, and to send information to the rights management server. In a Windows Rights Management Services environment, these include:

• The Machine Certificate is used to identify a trusted machine. There is one machine certificate issued to a computer for each user that uses that computer. This setup allows the computer to participate in the RMS environment.
• The Rights Account Certificate (aka Rights Management Account Certificate) is issued to a trusted user. The RAC allows a user to consume protected content if the user is so authorized.
• A Client Licensor Certificate (CLC) is issued to publish content even when the client is not connected to a rights management server; this is the default method of publishing for Microsoft Office 2003. The CLC is issued to a user to allow that user to publish content on behalf of the rights management server. This certificate includes the CLC public key, the CLC private key (encrypted with the user's RAC public key), and a copy of the rights management server's Server Licensor Certificate.
• A Publishing License (PL) is created by the creator of protected content and includes rights and conditions under which the content may be consumed. The PL contains the policy information, the content encryption key, and the URL of the licensing server. The content encryption key is protected by encrypting it with the public key of the RMS server.
• The Use License (UL) is issued to a user by a rights management server to allow the user to consume content based on the conditions in the publishing license. The UL contains the symmetric AES encryption key used to encrypt protected content. The AES encryption key is encrypted using the user's RAC public key.
• Advanced Encryption Standard (AES) keys are the 128-bit symmetric keys that are used for encryption and decryption of protected content. These keys are either protected with the user's public key in ULs or to the RMS server's public key and/or the CLC public key in publishing licenses.
• XrML certificates are the format that Microsoft uses to store rights management system policy information. XrML is a rights expression language that allows the definition of rights and restrictions that can be placed on protected content.
• Rights Expression Language (REL) was developed by the Motion Pictures Experts Group (MPEG) for expressing rights that can be granted to digital content.

Protected Content

Protected content is generated by RMS-enabled applications. Although the exact steps that ERM vendors follow may be somewhat different, there are some similarities: for example, a protected file includes AES encrypted content, the rights information, and the URL of a rights management server.

Figure 6.2 shows an example of a file's contents once it has been protected with rights management software using Microsoft Office applications. All the components necessary to protect the content are embedded in a single file including the encrypted content. There are variances on this concept with other implementations; even Microsoft Outlook varies slightly in that UL are not appended to the document but are cached in the user's profile directory instead.

Figure 6.2: File protected with rights management software.

The publishing license is created when the file content is protected. This includes the encryption key that is used to encrypt and decrypt the protected content. The content key is encrypted with the rights management server's public key. The rights information contains a list of individual email addresses of users or groups that are allowed to access the content. This is also protected with the rights management server's public key.

For each of the users that have licensed the content, there is an end user license in the file (unless the rights management policy on the document prohibits caching of ULs). The ULs include the rights for a particular user and the encryption key. The user's individual rights and the content key are encrypted with the user's public key by the rights management server.

What can Enterprise Rights Management do for my company?

Deploying an Enterprise Rights Management (ERM) system offers many benefits for your organization. In the simplest description, an ERM system allows a more comprehensive enforcement of your organization's information security policy. Although there is far more to an ERM than that, this description gives you a good starting point for understanding the benefits of

ERM.

ERM systems help a company enforce their information security policies.

As you may already be aware, email allows for a quick and easy information leak out of your organization whether the leak is intentional or accidental. An ERM solution significantly reduces the likelihood of accidental disclosure and makes intentional disclosure more difficult by limiting what the information consumer can do with the information. Unlike an S/MIME solution that can protect email content, an ERM solution can protect any type of binary content to which an application can be enabled—such as documents, spreadsheets, Web pages, presentations, and PDF files.

ERM solutions prevent accidental disclosure or sharing of sensitive information. A user must consciously act to subvert information security policy.

For organizations that are affected by laws governing private information or information security, ERM can help ensure compliance with these laws. In the United States, these laws include the Health Insurance Portability and Accountability Act (HIPAA), the Sarbanes-Oxley Act (SOX), the Gramm-Leach-Bliley Act (GLBA), and other regulations that are enforced by the Federal Trade Commission (FTC).

Governments are now enacting "disclosure laws" that cover when sensitive or private information about a company's customers is disclosed. Recently enacted laws such as the California Security Breach Information Act (SB 1386) states that companies must alert customers whenever "unencrypted personal information was or is reasonably believed to have been acquired by an unauthorized person." Similar laws are now in effect in 23 states and will likely be adopted at the federal level. Best practices and regulations such as NASD 2711 stipulate that investment banking be run separately from research and trading to ensure trust in the public markets. However, unless physical separation is maintained, technologies that improve communications, such as email or portal services, can serve as a conduit of improper communication. This is often referred to as the "Chinese or Ethical Wall" scenario.

ERM solutions are not just for organizations that are concerned with regulatory compliance, though. Any organization that handles sensitive information, proprietary information, or intellectually property can benefit from ERM solutions. Unlike traditional means of securing data—such as firewalls, encryption, and file system permissions—enforcement of an organization's information security policies does not stop at the organization's boundaries. Information can be securely shared with business partners, customers, and vendors; the use of the information can be audited, expired at the end of a project, or superseded by more recent content.

To get a better idea of how some organizations have benefited from ERM solutions and how ERM has helped them overcome some of their information security problems, the following sections explore a few ERM scenarios.

ERM and Compartmentalized Information

A government agency operates a classified network that is physically separated from its other networks. However, not all users that use this classified network are cleared to access all the information that is stored, processed, or shared. In the past, email containing compartmentalized information has frequently been sent to distribution lists that included users that are not cleared for that particular classification of information. In some cases, protecting the information is important enough that the email administrator has to rebuild the server and restore data from a backup that was taken prior to the accidental disclosure. Classified information is occasionally (and accidentally) placed on removable media (floppies, CD-ROM, USB drives) and moved to another network. These types of spillage of information are costly in terms of time, resources, and often lost information.

ERM solutions allow this organization's content authors to prepare content that is specific to a particular compartment and apply an ERM template to that content when it is created. This template automatically defines the users that are allowed to consume the content and it defines what their rights to the content consist of, such as print, copy, modify, or forward. Users from other compartments can be temporarily cleared to view specific information without having to give them access to an entire public folder, file share, or Web server.

Confidential Reports to Customers

A consulting company provides confidential analysis of risk assessments, security vulnerabilities, and mitigation recommendations to their customers. The reports contain large amounts of sensitive infrastructure information about the customer's network and computer systems as well as current vulnerabilities and potential threats to the customer. Quite naturally, customers are very concerned that this information does not fall into the wrong hands. The reports also contain proprietary analysis information and methodologies that the consulting company uses to gather and analyze the information. In the past, these reports have been passed along to their competitors despite non-disclosure agreements (NDAs).

Clearly document watermarks and threat-of-legal-menace NDAs were not enough to protect this information. In order to better protect both their customers' sensitive information as well as their own intellectual properties, the consulting company had to implement some mechanism that provides tighter controls for the information they are providing to their customers.

Implementing an ERM system allows the consulting company to publish protected content that can be released to the customer but the consulting company still retains a great degree of control over the content. A consulting report is valid for 60 days from date of issue after which the content expires. All access to each report is audited by the rights management server. Specific recipients at each customer are allowed to read the document, but only one user (usually the person responsible for information security or the Director of Information Technology) is assigned the rights to make printed copies.

The consultancy has found that an organization is much more likely to treat printed copies with greater care when only a single person is responsible for dissemination of the reports. The NDA now includes statements defining the responsibility and disposition of the printed copies of any reports issued to customers.

Preventing Accidental Disclosures of Sales Information

A large reseller of computer equipment has had a couple of embarrassing incidents in which customer pricing and profit repots have accidentally been released to customers by careless email users. In some of these cases, this has resulted in lost sales and lost customers. In one case, the recipient forwarded a customer's pricing data on to a competitor. The company had to implement some type of situation that would protect their sales data and statistics from accidental disclosure.

All "internal only" sales-related content must now be protected at creation. The rights associated with the content are applied via a rights management template so that the rights are applied consistently every time. The rights allow anyone in the sales organization and company executives to review the information, but only the content owners can modify the information or print it out. Content expiration for all proposals are automatically assigned a lifetime of 90 days so that out-of-date information is not used.

How does Enterprise Rights Management work?

On first glance, the big picture for Enterprise Rights Management (ERM) is deceptively simple. ERM helps protect sensitive content and helps an organization enforce information security policies. When you start digging into the first layer of technical details, though, ERM systems may appear to be overly complex and difficult to manage; furthermore, the system may appear to be difficult enough to use that typical corporate users would refuse to use the solution.

At least that was my initial impression, but upon learning more about ERM solutions from both the end-user perspective and the configuration, the complexity was merely a lack of basic understanding of the concepts and the flow of rights and information. And much to my relief, the complexity of ERM solutions is hidden from the end user. Using an ERM solution is not much more difficult that saving a document.

For an IT administrator or a messaging administrator intent on providing better information protection and information security policy enforcement, a basic understanding of the concepts and the inner workings is helpful when deploying or supporting ERM solutions. Keep in mind that there several vendors with ERM solutions on the market. Each of these has strengths and weaknesses and the components are set up differently. For my example of how an ERM solution works, I'm using the Microsoft Windows Rights Management Server for Windows Server 2003 (WS2K3), the Windows Rights Management client, and Office 2003 Professional applications.

Publishing Licenses and Usage Licenses

Different ERM solutions handle the creation of Publishing Licenses and Usage Licenses differently. The Publishing License is created when the content publisher sends the encrypted content keys and rights information to the Rights Management Server (RMS) Licensing server and the RMS system signs that information. The Usage License is created when a content consumer sends the Publishing License to the RMS Licensing server along with the consumer's Rights Account Certificate; the RMS Licensing server creates the Usage License that will allow the user to open this content.

Both of these pieces are key components to any ERM solution; however, the storage of these components, usage, and issuance of the Usage Licenses may differ from system to system. Some vendors rely exclusively on a policy server to store the rights information, while others (such as Microsoft) embedded the Publishing License into the projected content; once the user has received a Usage License, that license is also embedded in the content. This setup allows the content consumer to use the content offline and eliminates a potential point of failure.

RMS

The core of most ERM solutions is the RMS. In a single RMS-system organization, the RMS handles two primary functions. The first function is user certification; when a user uses the RMS client software for the first time to either consume protected content or create protected content, the RMS' certification function is responsible for issuing new user certificates (also known as an account certificate).

The second responsibility of an RMS is through the licensing services. Licensing services are responsible for issuing publishing licenses when protected content is created and issuing use licenses when protected content is consumed. In a larger environment, additional licensing servers may be configured for fault tolerance or to provide closer licensing services to users across slow WAN links. Figure 6.3 shows an organization with an RMS root server and two additional licensing servers.

Figure 6.3: Components of a Windows RMS setup.

In a smaller organization, a single RMS would handle both user certification and licensing. In larger organizations, there could be many licensing servers and many RMSs in an RMS cluster. An RMS cluster is multiple RMSs that share a single database and can be scaled by adding additional RMSs that all share a common SQL Server database.

RMSs use Active Directory (AD) to authenticate all users of the RMS system when issuing certificates or enrolling users. AD stores the service connection point (SCP) which directs users to their RMS. AD is also used to resolve permissions that are assigned to distribution lists; this is necessary when content is protected and assigned for use by distribution groups.

Publisher Setup

In an RMS system, the creator of protected content (or at least the person that applies the rights to content) is known as the "publisher." Before the publisher can create protected content, a number of perquisites have to be met—RMS-enabled applications and the client software must be installed and the user and the machine must be licensed. The process of setting up the client is called bootstrapping.

RMS-Enabled Applications

First and foremost, before protected content can be created or consumed, the user must have

RMS-enabled applications. Office 2003 Professional applications such as Microsoft Word, Excel, PowerPoint, and Outlook are already enabled and ready for use. If Web-based content needs to be protected, the HTML content can be created using Word 2003 and viewed with Internet Explorer (IE) and the Rights Management Add-on for IE.

If you are supporting applications other than the Office 2003 Professional suite, such as Office XP or earlier versions of the Office Suite or Adobe Acrobat, vendors such as Liquid Machines and GigaTrust have additional tools to protect content consumed by these applications.

If you have specialized applications that are not covered by the principal vendors, the Rights Management Software Development Kit (SDK) can be used to extend your custom applications to enable RMS features and protection.

Rights Management Client Software

All Windows RMS applications must interact with a common piece of client software. Although rights management functions are built-in to the Windows Vista operating system (OS), earlier versions of Windows must use the Windows Rights Management Service (WRMS) client; the current version is WRMS Service Pack (SP1), which can be installed directly (you don't need to install the original version first). If a user tries to set RMS permissions on a file without the RMS client, the user will receive a notice informing them that the WRMS client needs to be installed (see Figure 6.4).

Figure 6.4: The user is warned if they don't have RMS client software.

The WRMS client can be installed on Windows 2000 (Win2K) SP4 and later, Windows XP SP1 and later, and WS2K3. Prior to any RMS-enabled application being used, the client software must be installed; there are no configuration options and there are no user-executable components to this software. The software does not need to be activated or used at installation, so it can be installed when the OS and applications are installed or as part of an imaging process.

Using RMS for the First Time

Before users can create and consume content, they must be trusted by the RMS system. There are multiple parts to this process, including having a Machine Certificate issued to the computer as well as certificates issued to the user that allow the user to publish both online and offline. The RMS client software has to locate an RMS using the SCP information in AD. The steps to user provisioning are conceptually shown in Figure 6.5.

Figure 6.5: RMS user provisioning process.

In the first step, the RMS client software generates a public/private key pair, connects to the RMS, and requests that the public key be signed so that a Machine Certificate can be created. One Machine Certificate is issued per user per machine. The Machine Certificate is used to authenticate the computer in the RMS environment and to unlock users' private keys upon request. This process is completely transparent to the user (and the administrator) and does not require that the user have administrative permissions on the computer.

The second step of the user provisioning process requires that the user become trusted by the RMS system by obtaining a Rights Management Account Certificate. This process requires that the user provide domain credentials; the RMS (step 3 in Figure 6.5) authenticates the user against AD.

Once authenticated, the user's public/private key pair is generated, the Rights Management

Account Certificate (containing the user's public key) is created, the Rights Management Account Certificate and the private key are stored in the SQL database, and the user's private key is encrypted with the public key found in the Machine Certificate. This extra step ensures that the user's private key remains protected and ensures that the only way the user can create or consume RMS-protected content is from a trusted workstation. The user is now trusted by the RMS system and can create or consume content.

Except for being challenged for credentials, the Rights Management Account Certificate creation process is completely transparent to the end user.

Finally, in step 4, the user is issued a Client Licensor Certificate (CLC). The CLC is used to allow the user to create protected content without having to connect to the RMS. The CLC is signed by the RMS' public key and contains the CLC public key, the CLC private key (encrypted by the user's Rights Management Account Certificate public key), and a copy of the RMS' Licensor Certificate. The CLC will enable the user to publish protected content on behalf of the RMS.

Creating Protected Content

Now that both the machine and the user are trusted by the RMS system, the user can create protected content. Microsoft Office 2003 Professional applications all have a File, Permissions option on their menus; the Permissions option can also be placed on a toolbar if it is frequently used. Figure 6.6 shows Office 2003 and the Permissions options; to protect this sensitive message with rights management, the user must choose the Restrict Permissions As option. As the contents of this message reveal, this message is something that the originator clearly does not want disclosed either intentionally or accidentally. Protecting the message contents via ERM will impose the necessary restrictions on the message.

Figure 6.6: Protecting a sensitive message.

When the user chooses the Restrict Permissions As option from the Permissions menu, the application (in this case, Outlook 2003) will go through the necessary steps to protect the content. These steps are conceptually illustrated in Figure 6.7. Although the process in Figure 6.7 seems fairly complex, all the user had to do was to choose an option from the menu.

All RMS client to RMS server communication takes place over HTTP or HTTPS.

In the first step, the RMS client generates an advanced encryption standard (AES) content key (this is a symmetric key); this key is used to encrypt the contents of the data to be protected. Next, the RMS client software encrypts the AES key twice; once with the user's public RMS key and once with the RMS' public key. The encrypted content keys and the rights information are then sent to an RMS; in a midsized or large RMS environment, this may not be the same RMS that provisioned the user but instead a dedicated RMS Licensing server.

Figure 6.7: Creating RMS-protected content.

When the encrypted content keys and rights information is received by the RMS Licensing server, the RMS Licensing server verifies that the user is trusted by the RMS system, creates the publishing license, and signs it with the RMS' private key. The Publishing License is then retrieved by the client.

The RMS-enabled client software appends the Publishing License to the encrypted content. In the case of a document or spreadsheet, the file is then saved with the Publishing License and the encrypted content. The file is now protected regardless of whether it is on the local file system, optical media, or a USB storage device. In the example in Figure 6.7, the content is an email message; the message is sent on to the email server and ultimately to the intended recipients.

With the Windows RMS solution, security policy information is distributed with the protected content. Only RMS-enabled applications can open the protected content. The RMS-enabled application enforces the rights restrictions.

All the content publisher had to do is set the permissions option, and the appearance of the message is altered slightly (see Figure 6.8); in the area above the To line of the message, the rights information is displayed (recipients cannot forward, print, or copy the content).

Figure 6.8: The message display changes once the message is protected.

The procedure illustrated in Figure 6.7 uses the Rights Account Certificate (RAC) and requires connectivity to an RMS Licensing server in order to create protected content. If the publisher is working offline and has a Client Licensor Certificate (CLC), they can create protected content on behalf of the RMS.

Consuming Protected Content

The final part of the puzzle is when the recipient receives the protected content; the content must be decrypted and the rights information examined so that the RMS-enabled application can present the recipient with the correct rights to the content. When the RMS-enabled application opens the message, the only information that the application can see is the Publishing License containing the encrypted content keys, the rights information, and the URL of the RMS Licensing server.

Based on the Publishing License, the only two private keys that can open the encrypted content key and thus decrypt the protected content are the user that created the content and the RMS' private key.

The RMS client software takes the Publishing License and its RAC and sends a request for a Use License to the RMS Licensing server via HTTP or HTTPS. The RMS Licensing server validates the requestor's RAC, inspects the Publishing License for the rights list, and validates the requesting user in AD.

An RMS must be available on the network in order for a Use License to be issued.

The RMS then uses its private key to decrypt the AES content encryption key and then encrypts the AES content encryption key with the recipient's RAC public key. The Use License is created that contains the AES encrypted key and is returned to the recipient. The RMS-enabled application can now open the content and will enforce the published rights. In the case of a Word document or Excel spreadsheet, the Use License is embedded into that recipient's copy of the document. For Outlook 2003, though, the Use License is stored in the user's local user profile directory.

---