Secure Messaging Policies and Procedures

What should email training include?

One of the most valuable exercises in security that you can put your organization through is to develop a well-crafted, concise training program for use of your company's messaging system. Putting together any training program for users on an email system is difficult. Most of your user community will already know how to use their email client; some can use their email client as well or better than people in the IT department.

For this reason, you will have a difficult road to face when bringing your users back in for training that includes use of the email system. Even for a class that only lasts an hour or two, the users' time is valuable and getting buyoff from company management to conduct this training and have people out of their jobs is a difficult concept to sell. Thus, the content of the training class is very important.

Some organizations have set up mandatory refresher classes that users must take once each year and they must sign an updated acceptable use policy statement. If they fail to take this class, their user accounts are disabled.

Refresh the Basics

In any email course, it never hurts to start out with the basics of using the email system, covering topics that all users are familiar with. Reiterating these topics periodically can help reduce security problems and Help desk calls. The basics include:

Using distribution lists, especially distribution lists with large memberships
Recognizing the characteristics of a phishing scheme, messages that may contain a virus, or messages that may carry a Trojan horse
Using rules such as automatic forwarding of email and out of office replies
Exploring the difference between Reply and Reply All
Checking the To, Cc, and Bcc lines prior to sending a message and discussing how some email clients (such as Outlook 2003) will automatically fill in email addresses when you partially type an address that has been recently used
Reminding users that the email system is the property of their employer and as such the IT department may have access to the contents of anyone's mailbox if a valid need arises

Imposed Limits

Any limits that are imposed by the servers, firewalls, or message hygiene systems should be covered so that the users are reminded of these limitations. Limitations may include:

File attachment types that are not permitted
Message system mailbox limits such as the maximum size to which a mailbox may grow
Maximum inbound and outbound message sizes
Maximum number of recipients that a single message can contain
Archival or auto-deletion processes that run and what they do—such as purging messages from the Deleted Items folder or archiving to an archival system any message in the Inbox older than 90 days

Acceptable Use

The acceptable use policy is growing in popularity in many organizations because it helps to define what a user is allowed to do and more importantly what they are not allowed to do. Ideally, users sign the acceptable use policy to indicate that they have read it and understand the restrictions that are being imposed. During training, users should be reminded of items including:

Whether the work email account can be used for personal use
Where users should not use their work email address, such as Internet sites where they register for contests or questionable e-commerce sites—these are an invitation to be spammed
Use of the email system for joke email or inappropriate content such as off-color pictures
User of the email system for sending copyrighted material such as music files or video files (this not only causes the mail system to use a lot of unnecessary disk space, but it can expose an organization to lawsuits)

Information Security

Finally, users should be reminded of the nature of their job and the nature of their business. Any user that processes sensitive information—such as accounting information, sales information, and health care information—must understand the care they must take when sending this type of information via email. Accidental or intentional disclosure is not acceptable.

Organizations that must abide by a regulatory requirement such as the Health Insurance Portability and Accountability Act (HIPAA) must have a subsection of the training that outlines their responsibilities when processing this type of information and the ramifications not only to the organization but also to their job if such information is disclosed. Some users may only be concerned about their own jobs, but violation of some laws could expose a user to prosecution, jail time, or lawsuits. This is especially true when the organization has done due diligence to prevent such disclosures and the responsibility falls on the user.

How do I go about developing an Acceptable Use Policy for email?

An Acceptable Use Policy for your organization can span many different technologies and functions within an information system. This tip will focus on email systems and email communications.

Short of lawyers, few people appreciate the power of the written word. Email has evolved in most organizations from being an informal mechanism for communication in a business to a critical tool for doing business. Few people would pass around a tasteless joke printed in an official memorandum stationary or share their personal music via company courier. However, the casual approach to the use of email has resulted in legal problems for both individuals and entire companies as a result of the endless stream of file sharing, inappropriate jokes, and other objectionable material that now passes through many mail systems.

An Acceptable Use Policy must be part of the core foundation that you build for your messaging system's operations. Defining acceptable and unacceptable use of your messaging system helps to define the expected behavior of the user community, sets the user's expectations, helps with capacity planning, protects your organization from legal problems, and defines consequences if a user does not follow the usage guidelines.

Get legal advice prior to publishing an Acceptable Use Policy.

Ultimately, the Acceptable Use Policy should be documented, put into place, and be acknowledged by the user community in writing once a system is implemented. Certainly, an Acceptable Use Policy should be in place before restrictions are placed on the users that were previously not in affect (such as message size limits or banned attachment types). One surefire way to alienate your user community is to take away capabilities that they once had without first warning them.

Users do not like to have functionality taken away from them. Unless handled well and thoroughly explained, doing so will alienate your user community and possibly create a rift between IT and the user community.

Starting Point

Sometimes the most difficult part of developing an Acceptable Use Policy is just getting started or realizing that your organization needs to define guidelines for your user community. A good starting point is to define an outline of what types of technical restrictions you need to place on the user community, what measures you need to put into place to improve security, and what types of behavior or actions on the system are considered unacceptable.

Next, pick a team of people to review the policy, provide feedback, and ultimately approve its use. The team (including Human Resources and a legal advisor) should measure the enforceability of the policy.

An Acceptable Use Policy should cover and apply to everyone in an organization. It should not provide exceptions for management or exclude departments or divisions.

Finally, and probably most difficult, is getting the policy in front of the user so that they review it and acknowledge that they understand it. This step can be accomplished in a number of ways:

During an employee's annual performance review
After training for use of the system
When receiving a user name and password to access the system

Keep in mind that if your organization spans multiple states, provinces, or countries, laws governing employee privacy or work regulations may be different. In addition, there may be cultural and social differences that you need to take into consideration.

An Acceptable Use Policy must be "acceptable" to your user community while still protecting your organization from liability and system misuse.

Keeping the policy clearly written and self explanatory is important so that users have an understanding as to why the policy is essential to the organization's stability and security.

Who Should Be Involved?

Picking a team of people to help define the contents and enforceability of an Acceptable Use Policy will help to define the success of the policy and whether it must be revised shortly after it is put in place or stands the test of time (at least a year or two). The team should include users from across departments and specializations in your organization:

The Acceptable Use Policy must have an executive-level sponsor; this is someone from the senior management team that helps to approve the policy and agrees that it speaks for "the company" and not just the IT group. Otherwise, the policy may not be enforceable.
The Human Resources department's input is vital for the development of this policy. HR will more than likely be responsible for collection of signed documents saying that users have reviewed the policy, and HR will ultimately be involved in any type of action against users that do not follow the policy.
The IT group should provide at least one team member, and this team member should be familiar with what types of technical enforcement are possible given current technologies. Other considerations that the IT representative should be able to provide for the group include potential technical enforcement mechanisms that can be implemented if necessary.
The team should include someone from the organization's legal team or from an organization that represents the company's legal interests. This individual must help guide the development of the Acceptable Use Policy in a direction that will keep it within the boundaries of the law, ensure that the organization is not opening itself up to lawsuits, and that the policy provides guidance for any regulatory requirements.
Representatives from the end user community and each major department or division of the company should be involved. The policy should be clear enough that all departments understand the importance of following the policy's guidelines. Guidance from the user community can help make the policy understandable and hopefully help the users to understand why it is important.

What Should an Acceptable Use Policy contain?

Deciding on the text for your Acceptable Use Policy is an interesting balancing act. On one side of the equation is the need to keep the policy readable and understandable; on the other side is the need to ensure that the user is adequately educated about the restrictions that need to be put in place. Although the actual policy may not be divided into behavioral, information security, and technical measure restrictions, it is easier to examine them in that regard.

Technical Measures

The technical portion of the Acceptable Use Policy is the portion that defines the system restrictions placed on the user by either the mail system, perimeter filtering, or other mechanisms. Users do not have much control over technical measures; nonetheless, it is important that the user understand why these measures are in place. Technical measures include:

Mailbox size limits (including the size at which the server will start rejecting mail for the mailbox)
Message size limits internally or to and from the Internet
Forbidden message attachment types including attachment types that are blocked; if you block compressed files (such as ZIP or CAB files), the user should know what to do if they must send or receive a file of that type; if an attachment is blocked, state whether it is deleted or quarantined
Anti-spam technologies in place and the disposition of detected spam (whether it is passed to the user's junk email folder, quarantined, or deleted entirely)
Antivirus technologies in place and whether messages with viruses are cleaned and passed to the user, quarantined, or deleted
Use of system-enforced disclaimers for outbound messages
Automated mailbox cleanup processes such as moving old messages to an alternative folder or purging deleted items that are older than a specified age
Message archival technologies in place and what criteria (age, size, content, job function) are used to archive messages as well as how to retrieve them
Message formats (HTML, rich text, plain text) that are permitted for inbound and outbound messages
Content scanning systems that are in place and the type of content that may be blocked or quarantined for further examination, including jokes or inappropriate content, as well as information such as protected health information, customer records, financial data, or company proprietary information

Behavior Restrictions and Information Security

The behavior portion of the policy defines the factors that the user actually has some control over. This portion the policy is also the part that some users will violate. Coverage should include:

Outlining your organization's policy on written communication with respect to sexual harassment, discrimination, inappropriate remarks, threatening remarks, pornographic material, and other forms of media and ensure that the policy clearly defines that email communication is a form of written communication.
Defining the types of messages that a user is allowed to send, including whether users are allowed to use their work email system for personal messages, and covers sending chain letters, jokes, urban legends, and other personal or non-work related content. Many organizations take an official stance that "personal email" is not allowed but ignore personal email use as long as it is not excessive.
Defining levels of confidentiality and exactly what types of information a user is allowed to send internally and externally. If there are regulatory restrictions on content (such as healthcare information or non-public customer information), define how information may be sent (such as via encrypted emails).
Outlining acceptable distribution of work email addresses. For example, work email addresses should never be used to register for online contests, to access news sites, for magazine subscriptions, and for greeting cards, as these are an invitation to receive spam.
Defining expectations for what a user must do when they receive suspicious email, such as messages with attachments when they don't normally receive attachments from the sender.
Outlining whether mailboxes may be inspected by the IT department; if so, define under what conditions it can happen, such as by order of the Human Resources department.

Mailbox Surfing

Over the years, I have heard about or helped investigate situations in which an organization's mail administrator has decided to go mailbox surfing. In these cases, the administrator (without authority or knowledge of the user) reads through people's email and sent items.

This is a serious breach of ethics and an organization's management should treat this very seriously. Although most users understand that their email can be read by their IT department, they generally understand that it will happen only if necessary or authorized. If your IT department has not had at least a briefing on computing and ethics, this is something you should look into. The Association of Information Technology Professionals has a sample code of ethics at http://www.aitp.org/organization/about/ethics/ethics.jsp.

Truth or Consequences

Finally, the Acceptable Use Policy must have teeth—there must be realistic consequences when the policy is violated and those consequences must be enforceable. In order for the policy to be enforceable, you must have executive-level sponsorship when the policy is put into place. When the first official "punishment" occurs, management must have the intestinal fortitude to stand by that punishment.

The Acceptable Use Policy your organization uses must be realistic and enforceable.

In addition, the punishment must fit the crime; if a user is found to have been sending inappropriate pictures, the policy must define a realistic punishment. A realistic punishment might be that person gets a written reprimand in their HR file.

Finding More Information

Each organization is slightly different with a different corporate culture, security requirements, and management perspective. Thus, a policy that works well for one organization may alienate or anger the users in another. The SANS Institute has good information on security policies as well as sample policies and templates. You can find these at http://www.sans.org/resources/policies.

Another resource is the Electronic Frontier Foundation's Academic Computing Policy Statements archive at http://www.eff.org/Censorship/Academic_edu/CAF/policies. The Connecticut State Government publishes their Electronic Mail Acceptable Use Policy on the Internet; it can serve as a good guideline and can be found at http://www.cmac.state.ct.us/policies/emailcon.htm.

Are there "best practices" for the IT department with respect to messaging security?

Unfortunately, very few organizations provide their IT employees with an IT ethics briefing. Although most IT staff simply use common sense when dealing with IT systems and private information, guidelines are appropriate to ensure that everyone follows consistent procedures. Specifically, guidelines for IT staff should be created when handling potentially sensitive information in a messaging system. Message content may be found in several places within a messaging system infrastructure:

Users' mailboxes
Public folders
Personal mailbox storage files (such as PST files)
Message system queues
Message hygiene/content inspection quarantines
Email archival systems

Mailbox Surfing

In the past 15 years of being a messaging systems consultant, I have been asked on numerous occasions to help audit inappropriate message access by messaging administrators. In one situation, the mail administrator was accessing a user's mailbox simply so he could play a practical joke on the user by sending out a message saying that he was supporting a different sports team from his alma mater. Although this seems like a minor offense, it is nonetheless a breach of privacy and the administrator was fired.

In another case, the mail administrator responsible for reviewing the anti-spam and antivirus quarantines was occasionally seeing sensitive messages. The administrator was then sharing this information with other coworkers. Although the mail administrator had never been advised on the appropriate handling of this type of information, one would think that common sense would prevail and the information would be held in confidence. This administrator was counseled by the organization's human resources department, received an official reprimand, and had her responsibilities changed.

A simple policy that encompasses email access, information disclosure, and IT workers and that covers the disclosure of this type of information might state something like this: "In the course of working with message systems, queues, and quarantines, IT workers will be exposed to private or confidential data. This data must not be disclosed except as part of the worker's official duties for the organization."

Detecting Improper Mailbox Access

In most of these cases, catching the culprit is easy as long as auditing is enabled. On an Exchange Server, the Diagnostics Logging category MSExchangeIS Mailbox, Logons needs to be configured for at least minimum logging. Then monitor the Exchange Server's Application event log for Event ID 1016, indicating that a user account that is not the owner of the mailbox has tried to access the mailbox. This event is shown in Figure 2.1.

Figure 2.1: Event properties indicating that a user is accessing another user's mailbox.

Although event ID 1016 may not indicate an actual intrusion (since the user may have been given permissions to this user's mailbox for official reasons), it does indicate non-owner access of mailboxes that might need to be investigated.

Procedures for Opening Mailboxes

If your organization does not have a policy regarding access to users' mailboxes, develop—at the very least—an informal policy indicating under what circumstances mailboxes may need to be accessed. If you export mail data to personal message stores (such as PST files) or mail is archived to a message archival system, these storage systems should be included in the policy.

Your policy might state something as simple as: "No user mailbox other than administrative or system mailboxes will be accessed by anyone other than the owner of that mailbox or their delegates unless specifically requested by the Human Resources department, Information Assurance/Security department, or the Directory of Information Technology."

A good practice is to create one security group that has been delegated full administrative control to the entire message system, including the ability to open mailboxes. For an Exchange-based mail system, the group must be delegated the Full Control permission to the organization and have the Receive As permission changed from Deny to Allow. The Deny permission is explicitly set for an administrator that has been delegated permissions to the Exchange organization or administrative group using the delegation wizard. You can remove these permissions only on the Security property page (shown in Figure 2.2).

Figure 2.2: Giving a group the ability to open mailboxes.

By default, the Security property page does not appear on the organization and administrative group objects. See the Microsoft article Security Tab Not Available on All Objects in System Manager" for more information about how to enable the Security property page.

Often, the user account that is a member of the security group delegated to have full mailbox access has "two person" integrity on the account, meaning two people are required to logon as this user. For example, one person has the smart card for the account and the other person has the PIN, or each person has one half of the password.

Administrative Accounts and Mailboxes

A few simple steps can improve security for organizations by segmenting permissions and responsibilities. When creating user accounts and mailboxes, keep these points in mind:

User accounts should have no elevated permissions
Create separate accounts for administrators that have their necessary administrative permissions
Typical office automation/knowledge worker tasks such as word processing, spreadsheet manipulation, email communication, and Web surfing should only be done when using non-administrative accounts
Administrative accounts should not have mailboxes
Practice the principal of least permission where administrative accounts are assigned only the permissions they require to do their jobs
Do not create administrative accounts with mailboxes; doing so might make the spread of viruses or other malware easier

Email Client Software on Server Consoles

Another common mistake that administrators make is that they install email client software on their servers. With few exceptions, this is a bad practice for a couple of reasons. The first reason is that the mail client software might interfere with the operation of the mail server software, such as in the case of installing Microsoft Outlook on an Exchange Server.

Do not install email client software on a server. Email client software running on a server may allow servers to be infected with viruses or impeded the functions of a mail server.

The second reason this is a bad practice is that an administrator might access his or her mailbox while working on a server console and infect the server with a virus or worm. In cases in which an email client is required on a server to perform tasks such as automated message processing or to work with a specific application, ensure that the server has adequately configured antivirus software to prevent the server from becoming infected with some type of malware. Except in the case of a lab environment, email client software should not be installed on a mail server.

How do I access users' mailboxes to extract a dangerous message?

In some situations, it might be necessary to open one or more mailboxes in order to extract a sensitive message that was sent to users by accident or to remove a virus or worm that has entered many users' mailboxes. Although this task is technically straightforward, the administrative or security policy ramifications may be more complex. Any administrator that is going to perform such an operation should make sure that they are not violating a Human Resources, data retention, or other security policy.

For Exchange Server, the permission necessary to access other users' mailboxes is not given by default and requires tweaking in order to grant this permission. There is a good reason for this— the ramifications of allowing even a trusted administrator access to some or all mailboxes may be a touchy subject.

The most obvious way to remove items from a user's mailbox is to use Outlook or Outlook Web Access (OWA) to simply delete the message. If you support more than two or three mailboxes, though, this method quickly becomes a protracted and frustrating exercise.

The tool of choice for such exercises is ExMerge; the ExMerge tool can be downloaded from Microsoft's Exchange downloads page. Getting the tool and installing it (just decompress it and copy it to the \program files\exchsrvr\bin folder) is the easy part, getting the necessary permissions to access other users' mailboxes is the more difficult part.

Mailbox Access Permissions

By default, all users or groups that have been delegated administrative permissions to the Exchange organization and administrative groups have the Receive As and Send As permissions set to Deny. This setting is available on the Security property page of any object; the entire Exchange organization's Security property page is shown in Figure 2.3.

Figure 2.3: Security property page seen from Exchange System Manager.

If you are familiar with the Exchange System Manager interface for Exchange 2000 and 2003, you probably realize that the Security property page does not show up on all objects. This includes the top-level Exchange organization and the administrative groups. This is by design so that someone with Exchange Full Administrator permissions (which includes the ability to change the permissions list) cannot accidentally change the denied permissions. These permissions are explicitly set at the organizational level; the only place they can be removed is at this level.

The Enterprise Admins and Domain Admins groups both have the Send As and Receive As permissions denied. The user account that ran the initial Exchange forest preparation (forestprep) is also denied the Send As and Receive As permissions. In many cases, this is the administrator of the forest root domain.

The Send As permission allows someone to send a message as another user; this permission is used by the Exchange Server software to deliver mail. The Receive As permission allows mailboxes to be accessed.

You can enable the Security property page view in Exchange System Manager through the registry. Create a REG_DWORD value called ShowSecurityPage in the

HKEY_CURRENT_USER\Software\Microsoft\Exchange\ExAdmin registry key. Set this value

to 1, and the Security page should show up next time you check the organization or administrative group objects using Exchange System Manager.

There are a couple of ways to approach the delegation of the necessary permissions. The first method that many novice administrators think of is to merely remove the Receive As and Send As Deny permissions at the organization level for the Enterprise Admins and the Domain Admins. This method is effective, but may yield undesirable results because this means that all members of either Domain Admins or Enterprise Admins will be able to open anyone's mailbox.

The second approach is to delegate a user (or group) permissions to the Exchange organization (or to a single administrative group) using the Delegation Wizard in Exchange System Manager. Once the permissions have been delegated, remove the Receive As and Send As Deny permissions. This option will work as well, but it gives that user or group more permissions than they really require.

I am a big proponent of accountability, segmentation of user roles, and practicing the principle of least permissions. For these reasons, I recommend the following procedure for creation of a user that has permissions only to access mail. Then carefully protect that user so that only a selected group of administrators have access to that user account. The procedure I am outlining is for an entire Exchange organization, but you can apply it to an individual administrative group just as easily as the entire organization. The user and group names are also examples, so use whatever is appropriate for your organization.

Create a security group called Exchange Full Mailbox Access
Create a user called ExMergeUser, set a strong password on the user, and make the user a member of the Exchange Full Mailbox Access security group. This user does not need a mailbox.
Delegate the Exchange Full Mailbox Access security group the Exchange View Only Administrator role to the Exchange organization object. This group does not need Exchange administrator abilities.
Using the Exchange System Manager, access the Security property page of the Exchange organization, locate the Exchange Full Mailbox Access security group in the list of groups or users, and select the Allow box for the Receive As permission (Figure 2.4) The Send As permission is not necessary and is excessive.

Figure 2.4: Modifying the View Only permissions to include Receive As.

You might need to wait up to 2 hours for the permissions to take effect or you can stop and restart the information store if you just can't wait.

If the ExMergeUser is a member of Domain Admins, Enterprise Admins, or the Exchange Domain Servers groups, the permissions will not be sufficient because each of these groups is explicitly denied permission to access mailboxes. If you have failures running ExMerge and the ExMerge.log file shows the following errors, you don't have the correct permissions or you have not given them time to sufficiently replicate and take effect:

[16:58:52] Error opening message store (MSEMS). Verify that the Microsoft Exchange Information Store service is running and that you have the correct permissions to log on. (0x8004011d)

[16:58:52] Errors encountered. Copy process aborted for mailbox 'SuriyaS' ('SURIYAS').

Running ExMerge

Once you have squared away the necessary permissions to run ExMerge against the mailboxes from which you intend to remove a message, you can follow a fairly straightforward procedure to extract the data using the ExMerge program's Archive option. The most effective place to run ExMerge is from the console of the Exchange Server that contains the mailboxes you want to access. However, doing so might require additional rights on the part of your ExMergeUser account, such as being a member of the Remote Desktop Users group on the Exchange Server.

Some archival systems might immediately archive a copy of a message as soon as they arrive in a user's mailbox. The archival software must be able to extract from the archive messages that should not have been placed there.

ExMerge allows you to restrict your search for messages using a date/time range, a message subject, or attachment name. If you are attempting to remove a virus or confidential message, you will most definitely want to know the subject or attachment. Using the date/time range is not precise enough to rely upon.

ExMerge will copy or move data from an Exchange Server mailbox to PST files. The PST files will generally take up quite a bit more disk space than the data did when it was in the Exchange Server mailbox store, so allow for plenty of disk space.

ExMerge creates Outlook 97 to 2002 compatible PST files; it does not create the Office Outlook PST file that provides more than 2GB of storage capacity and is used with Outlook 2003 or later.

The following example walks though the process of extracting a message that was accidentally sent to many users on a mailbox server. The message contained sensitive information and should not have been sent to the entire list, and its subject line is "Sales Projections for 2007." This procedure will remove the message from all the mailboxes on the server:

Run ExMerge, and click Next on the first page of the wizard.
Choose the Extract or Import (Two Step Procedure) option, and click Next.
Choose the Step 1: Extract data from an Exchange Server Mailbox, and click Next
On the Source Server page, provide the name of the Exchange Server from which you plan to export mail and the name of a domain controller. The Lightweight Directory Access Protocol (LDAP) port number is optional. Figure 2.5 shows this dialog box.

Figure 2.5: Selecting a source Exchange Server and domain controller.

Click Options to display the Data Selection Criteria dialog box.
On the Data tab, you only need to have the User Messages And Folders options.
On the Import Procedure tab, choose the Archive Data To Target Store option.
On the Message Details tab (shown in Figure 2.6), enter the message subject in the Enter New Message Subject text box, and click Add. Ensure that the criteria you are going to be extracting by is properly entered. If you don't specify a criterion on the Message Details property page, you will export all the message data from your users' mailboxes— they won't be amused.

Figure 2.6: Specifying the subjects or attachment names by which you will extract messages.

Click OK to close the Data Selection Criteria dialog box and return to the Source Server property page, and click Next.
On the Database Selection property page, select each of the check boxes corresponding to each database that you want to search through for the message previously specified, then click Next.
On the Mailbox Selection property page, select the mailboxes that you want to search through. When finished, click Next.
On the Locale Selection property page, click Next.
On the Target Directory property page, specify a location for the PST files that will be created. When finished, click Next twice to start the ExMerge process.
When ExMerge is finished, click Finish.