Originally published in Intranet Journal (09-Sep-2004)
When we think about all the things that can affect the integrity of an intranet—hardware failures, hard disk crashes, data corruption, viruses, power outages, malicious attacks by outsiders or disgruntled employees, careless misuse, natural disasters—the odds seem stacked against us. How can we possibly keep a system running from day-to-day when there are so many forces working against us? It all begins with proper planning and preparation.
The procedures and mechanisms you put into place to ensure intranet integrity must focus more on prevention than reaction. If you plan for all foreseeable contingencies, your actions will be well-orchestrated. But if you're left scrambling—wondering what to do after a hard disk crash or a virus infecting the heart of your e-mail system—for a solution to the problem, you'll end up slapping on as many band aids as you can get your hands on rather than finding a real solution. It will be a race against the clock to get your system back up onto its feet—all the while, your users will be sitting around waiting for the system to return to normal.
In Part 1 of this series on maintaining intranet integrity, I discussed intranet architecture types that can be put into place to support a wide range of intranet priority types—from low to mission critical systems. I also stressed the importance of implementing an architecture that reflects the need for system availability; the higher the intranet priority, the higher the need for data and processor redundancy.
In this article I'll be focusing on some other things that must be in place to ensure the overall integrity of your intranet:
Of all the malevolent IT gremlins that negatively impact computer systems around the world, none are highlighted by the media as much as viruses and hackers. Their effects can range from minor annoyances to full-on system corruption. And for those unfortunate enough to have been intimately acquainted with these gremlins without the appropriate contingencies and failsafes in place, premature hair loss can be traced right alongside data loss.
We have all at one point or another felt the impact of viruses or hacking—either directly or indirectly. But the severity of this impact can be greatly influenced by our own response to the incident. If you're caught unaware, even the slightest mishap can cause you to flee the building and seek asylum in a mountaintop monastery. And in these situations it might not even be the virus or hacker that does the most damage, it might very well be your own actions—or over-reactions.
For any one particular system to be secure—be it your intranet, e-mail, or payroll—all systems around it must also be secure. One compromised system may result in a rippling affect and cause others to suffer a similar fate.
The security mechanisms you need to have in place, however, will vary depending on the systems you're running. Certain applications may have proprietary security architectures and maintain its own list of user accounts and access control lists (ACLs). Others may tie directly into your network operating system's security.
But regardless of any proprietary software, internal networks should have these common security components in place to ensure overall system integrity:
Unfortunately, despite all the technological security mechanisms you put into place to prevent system corruption, they don't stop careless misuse by unwitting, albeit well-meaning, employees. Educating your staff on the usage of their systems and the proper handling of sensitive information is crucial in avoiding accidental mishaps.
All IT systems need a regular checkup to stay healthy. Preventative maintenance measures—applying system patches, de-fragmenting hard disks, auditing server logs, processor and traffic payload tests—do a lot to keep possible problems at bay. But proper system maintenance also means downtime, something your users may not be able to afford.
Those who have implemented intranet architectures incorporating some form of server redundancy don't need to worry that much about downtime since one server (or a series of servers) can always remain online while they're working on another. Those without redundant resources, on the other hand, need to schedule maintenance so that the effects of downtime on their user community is minimized.
Scheduling maintenance downtime for an intranet with a local user-base is a fairly simple matter: Just do it during off-peak hours, such as in the evening or overnight. This schedule must remain the same so that users will come to expect it and plan their own work accordingly. And if it's necessary to deviate from this schedule, make sure that adequate prior notice is given to the users.
However, with the globalization of the workforce, extranets are becoming increasingly important, allowing a remote office in Sydney, Australia to securely access their intranet located in New York City. Planning a maintenance schedule in these situations may be a little trickier because of time zone differences; your local downtime may very well be another office's primetime. But by reviewing your Web server usage logs, you'll be able to find a window of opportunity—a gap where usages is low—in which to perform any required maintenance without too much interruption on your global user community.
Although I've never been overly susceptible to paranoia, I keep three levels of data redundancy for my personal computer alone: the live data on my notebook, duplicates on an external hard disk, and finally, a set off-site CD-ROMs. Should my notebook ever take a swan dive out the window, I can simply plug my external hard disk to another computer and still have all my vital data available.
But it really surprises me that some people in the business community still think of data backups for corporate systems as an optional step rather than a mandatory one. An intranet, being a constantly growing entity, can have dozens, even hundreds, of new documents added to it during the course of a single day. Without proper data backups (or some form of redundant data storage) you could very easily lose days, or weeks, worth of work with a single disk crash.
Putting together an effective data backup routine requires you to consider:
IT applications are prone to all manner of potential system-threatening problems. While we can do our part to minimize the likelihood of disaster, we can never eliminate it altogether. Problems will occur regardless of what we do, but it's the actions we take when we encounter them that will ultimately determine the impact of the outcome.
Everything I've discussed regarding intranet integrity will be totally meaningless if you don't know what to do when disaster strikes. It's a simple formula: Disaster breeds panic, panic breeds confusion, and confusion breeds mistakes. You can have all the technological failsafes you want in place, but at the heart of any system's integrity must be people with the knowledge and wherewithal to put Humpty Dumpty back together again.
To be fully prepared to deal with potential catastrophes, you need to have a disaster recovery plan in place to handle these types of situations. And those responsible for system integrity need to have an intimate familiarity with everything that can go wrong and how to recover from disaster—from minor hiccups to a full-system meltdowns. Otherwise, anything that's done from the point of failure onwards might be done on the fly—influenced by haste to get the system up-and-running again—and even make matters worse in the long run.
To develop a comprehensive disaster recovery plan you need to:
Like many things dealing with security, system failure, or data loss, far too many people have a "it'll never happen to me" attitude—that's, of course, until it does happen to them. I've seen it all too many times: anti-virus software is installed after PCs are infected, backups are kept after a hard disk crash, a firewall is installed after a hacker is found snooping around internal company resources. By then the damage has already been done, and the victims are forced to wear their IT battle scars like badges of (dis)honor.
It's time for everyone to look at system integrity measures as preventative rather than reactive. But unfortunately for some people, they will learn this very same lesson through a baptism of fire. Hopefully, the scars won't be so deep that they can never recover.
Copyright © 2004 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.