So You Survived the Disaster. Did Your Company?

The 2001 attacks in New York and Washington have hopefully placed the importance of “Business Continuity” plans and processes in the forefront of everyone’s mind. Of course, Business Continuity is a new enough term that you may not know what that is. In short, it is a plan that will provide “continuity” of your business in the event of a disaster.

Many companies have a backup and restoration process, a virus policy, and even a systems security policy for hacker prevention. However, most companies’ policies are woefully incomplete in all three of these areas. To make matters worse, these plans are scattered about the company and they leave out one of the most important pieces, actual recovery after a major disaster has occurred.

Let’s tackle each item one at a time:

Backup and Restoration

By now we all know (or at least I hope so) of the importance of performing regular backups. The reason for doing this is obvious: in the event of some form of database corruption, disk failure, or even user error, as in someone deletes a file then realizes they shouldn’t have, you want to make sure you have a way to recover the information.

When one of these things happens (notice I said when, not if) you can recover from it no worse for the wear. However, what happens if the building that houses your data center burns to the ground? Do you have a policy to take care of that? Does your backup policy allow for such an event? In this case a simple backup and restoration policy is not sufficient because your backups have also been destroyed. You need to start looking at things such as off-site storage of backup media. In this case, off-site storage does not refer to keeping tapes at somebody’s house or simply in another building on your campus. What happens in case of massive flood, hurricane, tornado, earthquake, or (heaven forbid) a bomb? You need a secure place that is designed to house sensitive, mission critical data. These types of places will walk you through their physical security (man-traps, metal detectors, etc.) as well as natural disaster security. They should have such things as high capacity sump pumps in case of flood, heavily buttressed walls in case of a tornado or hurricane, and shelving units designed to collapse together, forming “mini pyramids” in case of massive earthquake. You should have a full backup going to a place like this once a week.

{mospagebreak title=Still, This Is Not Enough}

Think about it this way: if there has been some major natural disaster, and there has been wide spread damage (including damaged computer systems), don’t you think almost every company in your area is going to be looking to purchase new computer equipment? Don’t you think that will put a significant strain on the supply chain for computers and computer supplies? Is your building still standing and capable of housing your computers? And if it is, will you have power to run the computers in the first place?

This is why you need more. You need to start thinking in terms of continuity in the event of a disaster. If you don’t think such things are important, take a trip to back in time to Florida during Q3 of 2004.

To complete your full “data security” plan you’ll need a reciprocal agreement, with another company in a geographically and geologically separated area, (meaning one that is at least 900 miles away to either the east or the west). The agreement you make is that if some natural disaster hits your area then your partner will provide enough computing resources and manufacturing space to allow you to do business — take orders, process AR, process AP, do payroll, and squeak out just enough orders to keep you in business — until the computers you order can get to you and you can find other manufacturing space or simply have power restored to your building. As the name “reciprocal agreement” implies, you agree to do the same for them should a disaster hit them.

Now, if a disaster does hit, you can get your tapes out of storage, head over to your partner company and get your company back online while your competitors are still fighting just to get computer orders filled and figuring out a way they can manufacture anything in the first place without power.

A plan such as the one I am talking about isn’t just good business sense; it is a monumental competitive advantage.

{mospagebreak title=Virus and Hacker Protection}

Virus Protection

While most companies have virus scanners in place, few truly stay on top of keeping their virus signature files updated. Few really stay on top of the CERT (Computer Emergency Response Team), something easily done by going to

A truly robust virus policy includes not only making sure that a scanner is on every computer that attaches to your local area network (no matter how that attachment happens), but also includes checking for new virus signature files from your virus protection vendor daily. It also includes a daily scan of the newsgroups on the subject of viruses and keeping up to date with the CERT advisories.

To tie this item together with the one above, this means having a specific virus scan, with your virus software, performed on your reciprocal partners’ computers. It also means trying this process in with your total disaster restoration plan.

Hacker Protection

This is a tricky one. Most companies have some sort of firewall to protect themselves from hackers that are coming from outside the company. The only problem is that there are now so many different types of attacks that merely putting a firewall in place is no longer enough. Additionally, most unauthorized accesses to you systems will not come from outside your company, it will be unauthorized access from your employees.

Entire books have been written on this subject, so I’m not going to go into it here in great depth. But even supposing you are keeping up on the latest security measures, you still need to ensure that you are keeping up with the CERT advisories (, monitoring alt.2600 (and it’s sub newsgroups) and that you are a part of the user groups for all of your hardware mission critical software. This will ensure that you stay on top of any new security holes being exploited.

Having Enough Protection

There is a final problem with most companies. The above three policies are virtually always created independently of one another. The plans exist, but they are separate plans, with documentation in separate places, and often with separate people overseeing each item.

Think of it this way: you have a backup and restoration policy to prevent the loss of your company’s data. You also have a virus policy to prevent the loss or corruption of your company’s data. And you have Hacker policies to prevent the loss (and unauthorized use) of your company’s data.

Anyone see a pattern here?

All three of them are created to prevent the loss, corruption, or improper use of your data, so they should be created together, and managed together. In short, they should be part of a unified “Business Continuity” document. Essentially, this document explains, in minute detail, all of the processes in the event of a disaster. In this case, disaster means anything that prevents you from getting at whatever data that is needed, when it is needed: a virus hits even one computer on your network, an accidental file deletion, a hacker breaks through your security system, a hurricane causes the collapse of every building in your campus, or anything else that prevents you from doing business exactly when it needs to be done.

Getting something comprehensive like this setup can be time-intensive. However, once it is in place much of the maintenance can be automated. That only leaves a little necessary hand-holding to keep the reciprocal agreement I had talked about earlier in tact. If done properly, this can be an enjoyable break from the daily grind. I would like to say now that a specialist in this area should oversee the creation of the systems and processes. If this specialist knows what they are doing, they will have created the following document as the final deliverable when work is completed.

{mospagebreak title=The Business Continuity Table of Contents}

This document, once fully put together will be quite thick and it should contain (at a minimum):

  • The exact procedure on how to fully startup every server on your network. This includes exact click-by-click and word-by-word descriptions of any commands that need to be typed in after the ON button has been hit, and it should have a picture of each server and the location of the ON button labeled.

  • The name of your virus software.

  • Virus software revision level.

  • The phone number to the technical support for your virus software.

  • Virus signature update frequency.

  • Location of the scripts that obtain the new virus signature file(s) from your vendor. If you do not have scripts to do this, then it should contain an exact click-by-click and word-by-word explanation on how to obtain a new signature file and get it loaded into the virus software.

  • A printout of the script that performs the update (if your company uses one).

  • Exact click-by-click and word-by-word explanation on how to launch the script.

  • Exact click-by-click and word-by-word procedures for performing a manual virus scan.

  • Exact procedures for what to do when a virus is found that can be cleaned from a file.

  • Exact procedures for what to do when a virus is found that can NOT be cleaned from a file.

  • The name of your backup and recovery software.

  • The revision level of your backup software.

  • The phone number to the technical support for your backup software.

  • The storage location of your back up media.

  • The rotation schedule for your backup media, where and when you obtain a new clean tape, where to put the tapes that are being swapped out, and where and when the offsite people pickup the tapes.

  • The exact procedure to startup your backup software if it is not started upon system launch.

  • The exact procedure to perform a full manual backup.

  • The exact procedure to restore a file and how to find the appropriate media the file will be on.

  • Exact procedures (including passwords and the like) for obtaining backup media from your offsite storage company.

  • A detailed description of your security system (e.g. firewalls, proxy servers, security groups, access levels, etc.).

  • A listing of the rev levels for each piece of software.

  • The phone numbers to technical support for each piece of software.

  • Contact phone numbers for each of your security and network admin personnel.

  • Contact phone numbers for network security experts (unless you’ve hired a “white hat” hacker, you don’t have one in your company, so you should have the number to a consulting company with an expert) in case you suspect a hacker attack is taking place or you suspect your security has been breached.

  • The name, phone number, and address to your reciprocal partner company.

  • The full reciprocal agreement.

  • An English language summary of what the contract says.

  • A detailed procedure to get your reciprocal partner company online with your data.

  • Detailed procedures on how to “do business” with all of your data sitting on servers you are not used to working with.

  • Detailed procedures on how to input orders, process them, how to run payroll, how to run AR, how to run AP, and anything else you simply must have computer access to run the basics of your business.

  • Detailed procedures on how to send your reciprocal partner your data, and an explanation on how your partner gets that data, loads it, and gives you access to it.

  • Detailed procedures on how to get your reciprocal partner up and running with the most up to date data possible for the systems being run on their servers.

  • Finally, it should contain the dates of when you tested all of this and exactly what was tested. Just to be clear, you should be testing the various processes at least twice a year, the more often, the better.

{mospagebreak title=Putting It Together}

By looking at what belongs in the document you may have trouble putting together why this all belongs together. Let’s look at it this way:

If you have hackers breach your security and they start deleting files, don’t you want to know how those files get restored AND how to eliminate the attack, and possibly track them so they can be prosecuted?

If a virus hits and it can’t be cleaned, don’t you want to know how to restore a version of the file before the corruption happened?

If a real disaster hits and your network personnel that take care of this stuff on a daily basis are killed or otherwise incapacitated (or are simply too busy dealing with their own families and don’t come to work), don’t you want very detailed procedures in place so you can get your business back up and running?

And don’t you want it to be all in one place so you don’t have to hunt for four or five different documents right in the middle of a state-wide crisis?

That means that having one copy of the document printed out and put on a shelf somewhere is useless. If the “disaster” is a fire that guts your building and ruins your computers, obviously a printed document isn’t going to do you much good, so what are you going to do? My point here is that you need to have several copies printed. One goes in each and every server room, one goes to your offsite storage company, another goes to your reciprocal partner, and two copies go to each and every corporate officer (the “C” level folks, such as your Chief Executive Officer, Chief Financial Officer, Chief Operating Officer, etc) one to keep in their office, and another copy that stays at their home. Also, you will want this file a part of every backup that is performed, and it should be sent in electronic form to your reciprocal partner (on top of the printed version).

Now you can be sure that not only is your network safe, but also should something truly disastrous happen you can find the document that will allow you to get your business back up and running again well ahead of your competition.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye