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.
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:
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:
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:
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.
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.
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:
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.
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:
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.
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:
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:
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.
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.
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.
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:
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."
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.
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.
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:
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.
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.
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.
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').
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:
Figure 2.5: Selecting a source Exchange Server and domain controller.
Figure 2.6: Specifying the subjects or attachment names by which you will extract messages.