8.3 Keep it running
|
8.3 Keep it running
Let's set the scenario you have a company of 10,000 to 15,000 users. Messaging is mission critical. If the messaging servers are down for more than four business hours, you could lose business. With that said, what are some of the issues and problems that you must deal with, and, more important, what are the solutions?
As you can probably guess, you must start with policies and then go to procedures. What policies does your company have in place? Following are a few possible examples:
-
Acceptable use
-
Mass-mail
-
E-mail virus scanning
-
Content scanning
-
Message retention
We will discuss each of these and look at the issue, impact, and potential solution. It is important to understand that no one solution will fit every case. When you build the solution for your business, you will need to look at the following factors: service levels (SLAs), the business needs and the cost of security, the corporate culture, and the actual risk and benefits of your selected solutions.
8.3.1 Acceptable use
The messaging acceptable use policies should be part of an overall policy document that covers computing resources. At this time we will focus on messaging.
Every company should review the following two issues that may need to be part of its acceptable use policies: an initial discussion about the use of e-mail, and why e-mail is important to the company. Describe the business environment that involves e-mail. Discuss how company proprietary information will need to be managed if sent via e-mail. Each acceptable use document should include specifics about the responsibility of the employee (or user). Also, the document should show examples of unacceptable behavior. In many companies, a document will be published that is entitled "Messaging Policies, Procedures, and Guidelines."
Following is an example of an acceptable use document:
| Note | The Company Messaging Acceptable Use Policy and Procedure Document Number 234567 Introduction The Company provides e-mail as an import asset for the day-to-day operations between both employees and our customers. The Company considers all e-mail sent by the Company employees on the Company's computing and network environment to be the Company's property. Requirements Employees cannot expect that e-mail is private or confidential. Due to the retention policies of the Company (see the Company retention policy document #12345), there is a legal risk posed by stored and archived e-mail messages. Messaging, also known as e-mail, should not be used in any way that is harmful to the Company. Examples of such harmful messaging usage can include the following:
User Responsibilities Use only those computing and information technology resources for which you have authorization. Use computing and information technology resources only for their intended purpose. Protect the access and integrity of computing and information technology resources. Check e-mail daily and remain within your limited disk quota. Delete unwanted messages immediately, because they take up disk storage. Keep messages remaining in your electronic mailbox to a minimum. Use good net e-mail etiquette. See the Company document #12345-12 for more information about net etiquette. Also, any employees using a laptop will encrypt e-mail when traveling. |
One problem that is very common in the business world is the "flame" letter. This is basically the same as calling the coworker in the next cubical a moron. The court system routinely treats e-mail messages the same way it has always treated any written letters and memos; an e-mail that is spontaneously written and then sent (signed is even worse) may provide evidence against an individual or a company. Think before you send off that message. Yes, we may agree that the dude in the next cubicle is a moron, but don't put that in an e-mail message! After you create your acceptable use policies, make sure you put a good plan in place to communicate the contents of the documents to your employees.
8.3.2 Mass-mail
Mass-mail is another area that many companies overlook. Mass-mail is the ability to send a message to large groups of users within the company. In smaller companies, this may not be a problem, but in larger companies it can be. Following is a real-life example. A woman we'll call her Mabel had a picture of her dog. Now most people like dogs, but not everyone appreciates pictures of dogs wearing cute outfits, hats, and the like. Mabel had had this picture of her dog taken by a professional photographer, and because this picture looked so cute, Mabel decided to scan in the picture with a very high-resolution scanner. She then e-mailed it to herself at work. This picture of Fifi was then put into a mail message and sent to 10,000 users. The picture was only about four meg, so it wasn't too bad, but the problem was that the user community got really mad, really fuming mad. This message was forwarded, replied to, and copied. About 20 more variations of this message were sent into discussion databases. If you do the math, 10,000 users times four meg is not very good but still not really bad. The servers could have handled this volume if it stopped there. The problem was in the response from the user community; this is what really multiplied the message. It took a week to stop these messages from flowing and to purge them out of the system. What is the lesson? (Do not send pictures of your dog via e-mail, but there's more.) The answer is in the mass-mail system that is part of your e-mail system. Following are several solutions:
-
Add mass-mail procedures to your acceptable use policy documents.
-
Train users on the use of mass-mail and when to use it.
-
Create a solution in which you can control the mass-mail features in your mail system and limit access to the mass-mail system.
The first two solutions actually work. But the bad news is, they only work in small companies. The larger the company, the harder it is to control the mass-mail system if it is open to the general e-mail user population. Also, there is another potential problem. Spammers have been known to discover the name of an e-mail group that exists in a company's e-mail system. When this happens, they can then bounce a message into the company's corporate messaging environment and invite its employees to a pornographic site. Now that is really bad. Why? Because some of the users in the company may do the following:
-
Try to dual with the spammer
-
Actually launch the URL sent to them
-
Possibly launch an attachment, if it is included, which can spread viruses.
Again, if you have a small company, you may not need a mass-mail solution. Also, check with your e-mail vendor to see if it has solutions that can manage mass-mail. We'll look at an example of a creative solution, but first, review the following goals for our solution:
Goals
-
Create a corporate communication system that will allow for sending mail to a large group of users in a large organization.
-
Keep the general population from sending messages to the "massmail groups."
-
Keep external users from bouncing messages into a large group (spam mail).
-
Control when mass-mail messages are being sent.
-
Have large virtual groups without actually creating groups (maintaining groups can take up a lot of time).
-
Use existing groups, if needed.
-
Use various directory sources to send messages.
-
Send messages to internal, external, and Internet destinations.
-
Send via a browser.
-
Identify the directory sources: These can be X.500, LDAP, or any consistent authorities source. The main issue is having an authoritative data source for the directory information. The following information is needed:
-
User name (required)
-
Some type of unique key (required)
-
E-mail address (required)
-
Information about location, job title, and so forth (optional)
-
Public keys (if needed)
-
-
The "pseudocode" is the instruction that will actually perform the lookup in the directory source. The user that has access to send corporate communication will see a title name for the code. The end user will never see the exposed code. An administrator will create pseudocode entries, such as the following:
-
Title South Region Users (what the user sees)
-
Code Select all users where region = South
-
Title All Users in France (what the user sees)
-
Code Select all users where country = France
-
Title All Users (what the user sees)
-
Code Select all users
-
-
Engine profile settings will include references to the data sources, messaging, or any settings related to internal processing.
-
The mail engine will actually send the message, process the pseudocode, and place the message in the mailbox. Using this mechanism, you can hide all of the recipients and control the "From" and "Send to" fields. As part of this process, the engine will attempt to group recipients by servers so that when the message is sent, it will cut down on the network traffic.
-
The "Corp Comm" database is what the users access in order to send a message. Only users with the appropriate access will be able to send messages. Workflow approval can be added as needed (that is, document placed in draft, approved, the schedule to be sent). The user will be able to create, schedule, and send documents from this database. Minor modifications to a standard mail file will be needed. Authorized users will be able to select a target "group" (virtual group) from a drop-down list, which is driven by the pseudocode. If needed, a simple "Create a group on the fly" can be added. If workflow is not needed, then messages can be mailed in. If authorized users sign the mail, then those messages will be automatically sent to the mail engine after some type of validation.
-
The profile document is what controls the workflow to the "Corp Comm" database and references the pseudocode (see Figure 8.4).
Figure 8.4
-
8.3.3 E-mail virus scanning
Virus scanning seems simple. The question you need to answer is, "Do we really need to scan e-mail messages?" The answer may not be so simple. Following are some of the options:
-
Do not scan any messages.
-
Scan all messages sent and received by an end user.
-
Scan messages going to the Internet.
-
Scan messages received from the Internet.
Do not scan any messages
Many companies will have a desktop virus scanning policy. (Actually all companies should have some type of virus scanning policy, but we are focusing on messaging in this chapter.) If your company does not send messages to the Internet, then you may not want to scan messages. We have a difficult time recommending this option, as very few companies do not send messages to the Internet. Overall, this option is not a good one.
Scan all messages sent and received by an end user
Absolutes don't necessarily fit. The time and cost of scanning all messages may not make sense. In order to implement this solution, you will need to scan messages before they leave each client. Some cases exist in which a company wants to scan all messages, such as a company that has clients scattered all over the trusted network, and there are many different access points to the Internet.
