Information Security Policies for Exchange Server 2003 | Microsoft Exchange Server 2003 Administrators Companion (Pro-Administrators Companion)

The next few sections outline policies that relate to messaging and that should be a part of your overall information security policies. We’ve listed several examples to help illustrate our points.

Password Policies

Because users will need to authenticate to an Exchange 2003 server, and because they will need to be authenticated in the Microsoft Windows Server 2003 Active Directory environment, you will need password policies. Such policies could include the following topics:

Minimum password length
Password complexity
Re-use of old passwords prohibited
User-selected passwords prohibited
Storage of passwords
Anonymous user IDs prohibited (consider Microsoft Outlook Web Access)
Displaying and printing of passwords
Periodic password changes
Transmission of passwords to remote users
Limits on consecutive attempts to log on using a bad password
Help desk password resets
Encryption of passwords
Use of passwords in scripts, code, and other electronic forms
Use of duress passwords
Disclosing passwords to consultants and contractors
Password sharing prohibitions
Forced change of all passwords after system compromise

This list isn’t comprehensive—some topics might or might not be in your password information security policies—but it should get you started. Here are two examples of the way these topics can be expanded into information security policies:

Password sharing prohibited Users are prohibited from sharing their passwords in any form with other users in this company or anyone outside this company. If a member of the IT department needs to log on under your user account, that member must obtain a password re-set on your user account before logging on.
Use of duress password The information about Server X is highly sensitive and, if leaked to non-authorized personnel, would irrevocably and significantly damage the purpose and work of our organization. Therefore, only the Director of Technology is allowed to log on to this server and perform administrative functions. Should the Director of Technology be logging on to the server under a situation of duress, the Director must enter the duress password. This password must execute code that will immediately destroy all data on the server.

The second example is a bit extreme and would be implemented only in environments requiring extremely high security. However, the policy illustrates what must occur in a given scenario. An electronic policy would stipulate how the information was to be deleted. The information security policy dictates only that the information must be deleted.

Logon Policies

Because each user will need to authenticate to Active Directory before using any of the Exchange 2003 services, you will need to focus on your logon policies as part of the Exchange 2003 information security policy development. Here are some ideas for what your policies can cover:

Requirement of a user ID and password to access services on your network
Use of separate user IDs for internal and external logons
No sharing of user IDs and passwords
A security notice in the system logon banner indicating who is authorized to log on to your network
The displaying of the last user name that was used to log on
Limitation on the daily number of logons to prevent unauthorized use of the system
Restriction against multiple logon sessions at multiple nodes
Restriction against automatic logon processes
Automatic logoff process
Requirement to log off when you have left your desk (as opposed to locking the workstation)

Here is an example of an information security policy for the network logon banner in the preceding list:

This system is for the exclusive use of authorized personnel only. If you are not an authorized user, you are instructed to not attempt to log on and to leave this terminal. All activities on this terminal will be monitored and recorded by system personnel. Improper use of this system is strictly prohibited and could result in termination of employment. Criminal activity will also be prosecuted to the fullest extent of the law.

Many locations don’t employ such a banner, but it can be invaluable in court when an unauthorized user logs on to your system and commits criminal activity.

Acceptable Use Policies

Some acceptable use policies directly affect the use of Exchange services. In this section, we list the policies that you should consider implementing, with your Exchange 2003 server in mind:

Prohibition of storage of personal e-mail on company servers
Use of e-mail system for business purposes only
Incidental use of company e-mail system for personal use
Prohibition of using e-mail system for non-approved activities
Permissible uses of company e-mail system
Non-employee use of company e-mail system
Termination of employee and mailbox retention
Voluntary leaving of employee and mailbox retention
Access to e-mail via Outlook Web Access
Use of company e-mail address in e-mail lists
Transference of e-mail to portable devices
Requirement of digital signatures for sensitive e-mails
Requirement of encryption of e-mails for sensitive data
Requirement of SSL for browser-based access to e-mail

As you can see, you have much to consider when writing security policies for e-mail. You won’t end up including every item in this list in your security policies, but you should consider and discuss each one. There might also be other policy items not included here that would be suitable for your environment.

As security becomes more and more important in our business transactions, you might need to clarify when e-mails should be encrypted and signed. Saying that all e-mails should encrypted and signed is the easy answer but might not be warranted. In many scenarios, specifying that only some types of content should be encrypted and/or signed when sent is more appropriate treatment. You might even need to specify a policy regarding which third-party Certificate Authorities (CA) can be trusted.

Computer Viruses, Trojans, and Worms

Because most computer viruses, Trojans, and worms (which we’ll refer to generically as viruses in our discussion) are spread though the use of e-mail, you must write information security policies about the viruses. Simply installing antivirus software is often not enough protection. Users should be told how to treat suspicious e-mails, what and what not to do when they suspect they have been infected, and how to avoid committing actions that would introduce viruses on your network. Here is a list of items to consider when writing security policies about viruses and e-mail:

Users must not attempt to clean viruses on their own
Duty to report suspicious e-mail
Antivirus software must be installed and working on all network nodes
Prohibition against downloading software from third-party sources
Prohibition against using unapproved antivirus software
All outbound e-mail and attachments must be virus-free
Virus checking at firewalls, servers, workstations, and other network devices
Use of multiple antivirus software packages from different vendors
Virus checking of all software downloaded from third-party sources
Updating of virus definitions on firewalls, servers, desktops, laptops, and other network devices
Prohibition against use of personal floppy disks without virus checking
Antivirus software must be current
Prohibition against scanning of Exchange databases and transaction logs with virus-checking software
Content must be decrypted before checking for viruses
Backup or imaging of servers before cleaning for viruses

All user involvement with computer viruses prohibited

Caution

Do not scan Exchange databases and transaction logs by antivirus software. Scanning the Exchange databases and/or transaction logs with the file-based antivirus scanning utilities will, at some point, corrupt your databases or transaction logs. Never directly scan the Exchange databases or transaction logs with antivirus scanning software. Some of the patterns of 1s and 0s will look like a virus signature and, if the software attempts to clean the file, the file will become corrupted.

Caution

Use antivirus software written specifically for Exchange server to avoid database and transaction log corruption. Use this software to scan the databases and use the normal file-based scanning software to scan everything on your Exchange server except the databases (*.stm and *.edb) and their supporting transaction logs (E*******.log).

Schema Extensions by Exchange Server 2003

Because the installation of Exchange Server 2003 extends the schema in your organization, you should include a few security policies about this extension. Consider the following requirements:

The schema extension by Exchange Server 2003 should be tested in a laboratory environment first.
All “home-grown” applications must be tested for quality assurance and compatibility with the schema extensions introduced by Exchange Server 2003.
Installing Exchange 2003 in your production environment before all quality assurance and compatibility tests have been successfully passed is strictly prohibited.

Since Exchange is also a development environment, here are some issues that should be discussed regarding ongoing development on your Exchange Server 2003:

Separation between testing and production environments
Development Staff has administrative access to testing environment but not to production environment
No testing by developers in production environment
Use of images or backups of production servers on test servers
Formal change control procedure required for all production servers
Production system changes must be consistent with security policies and architecture
Requirement to document all changes to production system
Requirement to test all production system changes for security vulnerabilities in test environment first
Movement of software from test environment to production environment

Third-party applications will be installed on your Exchange 2003 server, so consider the following issues when writing your information security policies:

Test third-party applications for Exchange Server 2003 in the test environment first.
Assess third-party applications for security vulnerabilities.
Installing third-party applications if known security vulnerabilities cannot be fixed is prohibited.
Running non-essential services on servers and workstations is prohibited.
Conduct periodic operating system and application audit on all servers.
Implement security patches and fixes promptly.
Test all security patches and fixes in test environment before installing in production environment.
Run the same service pack levels and same security fixes on all Exchange servers.
Management approval is required for installation of service packs and security fixes on all Exchange servers after the software has been successfully tested in the test environment.
Set the timing of changes to production systems that cause a re-boot of production servers.
Back up or image Exchange production servers before installing new software.
Third-party software vendors must supply a written integrity statement.

As you can see, overall change and control procedures are important. Also, most of these policy items assume the company has invested in a development environment in which new software can be tested. Creating a list of standards against which new software can be measured is difficult, but you can use the following standards as a starting point for developing your own quality and compatibility measurements:

Ability to send and receive e-mail
Ability to send and receive signed e-mail
Ability to send and receive encrypted e-mail
Ability to send and receive signed and encrypted e-mail
Ability to access public folder
Ability to post to a public folder
Ability to run custom applications presented via a public folder
Ability to perform all mailbox functions, such as calendaring, tasks, and journals
Ability to enforce inbox rules
Ability to use Out Of Office Assistant
Ability to recover a mailbox

Test the more common functions and check the newsgroups (news.microsoft.com) for any complaints or bugs that were found in the new software. If the new software is from a third-party source, find out from its company whether there are any known issues with this software and Exchange Server 2003.

Data Security

Because Exchange will host critical and sensitive information, consider the following for Exchange Server 2003:

Statement that information is an important company asset
Legal ownership of e-mail and messages
Requirement of disclaimer notices on all e-mail
Prohibition of downloaded company e-mail to personal home computers
Use of company information for non-business uses
Using e-mail to transfer company information to third-parties
Right of company to examine e-mail content at any time
Right of company to monitor use of e-mail
All e-mail activity monitored and reported to management
Prohibition of disclosure of confidential information via e-mail
Prohibition of responding to e-mail receipts
Acceptable use of e-mail receipts
Prohibition of stationary in e-mails
Use of signatures in e-mail
Confidentiality e-mail agreements required for all employees
New confidentiality e-mail agreement required for change in employment status
Prohibition against giving non-employees e-mail accounts on production system
Data classification scheme
Acceptable retention of hardcopy e-mails
Removal of sensitive information from the company’s network via e-mail
Permission required to take secret information off company’s premises
Scrubbing Exchange databases after backup that hold secret information
Shredders required to dispose of hardcopies of e-mail
Dissemination of confidential or secret information prohibited via distribution lists or e-mail server lists

Data security encompasses many issues. Let’s discuss a few of them. First, if you can define a data classification scheme such as public, private, confidential, or secret, you can tie the encryption and signing of e-mail to certain levels of content. For example, you could require that all e-mail containing confidential information be signed, and all e-mail containing secret information be both signed and encrypted. Spelling this requirement out in a set of policies will help your users know when to use these advanced methods of sending and receiving messages and protect your company.

Second, check with your legal counsel regarding ownership and monitoring of e-mail. A user can assert a right of privacy for their company-given e-mail account unless the company clearly informs the user that e-mail hosted on a company server is company property.

Finally, if your users send out confidential or sensitive content in their e-mails, it may be a good idea to add a disclaimer to all outgoing e-mails to protect the user and the company in the event the e-mail is accidentally sent to the wrong recipient. Check with your legal counsel.

Legal Exposure to Unwanted E-Mail Content

This section focuses on adult or offensive content that is received by employees in your company. A set of information security policies should be developed with these security issues in mind:

No company endorsement of unwanted, received e-mail content
Requirement to make reasonable efforts to block all offensive e-mail
Requirement of user to notify management of received offensive e-mail
Prohibition of sending or forwarding offensive content, such as jokes, in e-mail
Right of company to remove offensive material and e-mail without warning
Disclaimer of responsibility or liability for message contents
Requirement of disclaimer that personal statements do not necessarily reflect the company’s views, positions, and opinions
Prohibition of using e-mail to engage in sexual, ethnic, or racial harassment
Prohibition of using outbound e-mail to engage in sexual, ethnic, or racial harassment

Every element of this list should be included in your security policies, because, for example, adult spam likely violates your sexual harassment policies, and jokes innocently passed between co-workers might leave your company exposed to unnecessary sexual harassment liability.

Backing Up and Archiving Exchange Databases

Surprisingly, some organizations do not guard their backup tapes and media very well. Most organizations view the backup of databases as a routine software procedure. However, more thought needs to be given to the backing up and storage of Exchange databases. Here are some elements to consider when writing security policies in this area:

Acceptable archival storage media
Regular testing of archival storage media
Backup media stored in separate fire zones from Exchange servers
Backup media rooms must be fire-proofed
Backup media rooms must be physically secure
Offsite storage of backup media required
Specification of backup process and frequency
Users notified that Exchange data is routinely backed up
Requirement to encrypt backup media
Two copies of backup media required for confidential or secret information
Two copies of backup media stored offsite for confidential or secret information
Monthly trial backup and restore required to test backup processes and media
Quarterly audit of backup processes required
Minimum information retention period for mailboxes
Minimum backup media retention period
Regular purging of old e-mails or outdated information for all user’s mailboxes
Requirement to retain a copy of all e-mail

You can move a user’s mailbox between databases, so you can place those users who send and receive the most sensitive e-mails in a single database and then require multiple backups of that database along with message journaling, increasing the chance that information can be recovered in the event of a disaster.

In certain industries, laws and rules might stipulate that you implement a certain backup and retention policy. Some of this work might have been done for you already in industry standards. Be sure to pay attention to those standards.

E-Mail Integrity

In this section, we outline some issues that you should consider regarding e-mail integrity:

E-mail address changes confirmed via previous address
E-mail originator must be clearly identified
E-mail system must reject all e-mail that does not have a verifiable originator
Employees must make truthful statements in their messages
Prohibition against misrepresentation of identity in e-mail system
Employee contact information must be consistently represented
Right to free speech does not apply to company’s e-mail system
Contracts cannot be signed using digital signatures
Only designated employees can form contracts via e-mail and digital signatures
Prohibition of use of encryption technologies that cannot be decrypted by system personnel
No trusting of non-approved certificate authorities
Maximum life for all encryption keys
Process for generating encryption keys
Requirement of minimum key length
Protection of private keys

We understand there is positive case law regarding contracts that can be formed and signed using a digital signature. However, you need to check with your legal counsel on whether you want to allow this to occur.

Also, check with your legal counsel regarding whether a person’s First Amendment rights can be curbed by the company. This free speech issue could potentially be controversial, so clarify it and be proactive.

Finally, because we are encrypting more and more, specifying which CAs can be trusted is important. Also, specify which encryption methods are acceptable in your organization and prohibit the encryption of data that can’t be decrypted by your company.

Miscellaneous Elements to Consider

The information security issues listed in the preceding lists aren’t comprehensive, so we’ve provided one last list of items that didn’t quite fit in our categories. Although we’re calling the items in the following list miscellaneous, these items are critical for you to consider when writing information security policies for your organization:

Prohibiting the use of e-mail addresses other than official company addresses for company use
Forwarding company e-mail to non-company addresses prohibited
No use of the e-mail system as an electronic database
Periodic destruction of archived e-mail databases employed without warning
Owner authorization required to read e-mail messages of other workers
Prohibiting the altering of e-mail message headers
Prohibiting the sending of unsolicited bulk e-mail
User must stop sending e-mail messages after request to stop has been received
Authorization to send e-mail to distribution lists required
Prohibition against opening attachments unless they are expected
Use of e-mail system requires attendance at authorized training sessions

Some of you are going to love the element in this list about not using the e-mail system as an electronic database. We have heard more than a few Exchange administrators complain about users filing and saving every e-mail forever. Perhaps this element alone will pique your interest in writing these information security policies!

Several of these elements ensure users don’t use your company system for spam. If your marketing department or sales department sends out bulk e-mail, you’ll want to word the policy such that authorization is required and that all bulk e- mail is not inherently prohibited.

Forwarding company e-mail to personal e-mail accounts is often prohibited. This policy will ensure that those who work with sensitive information cannot send that information to their own e-mail account and then sell the information to your company’s competitors. Auditing the mailboxes of these users will ensure that they follow the policy. A written policy, in and of itself, can’t keep someone from doing anything prohibited, but it can give you cover to monitor user activities and expose the user if a policy is being violated.