Skip Navigation
Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10
Table of Contents Glossary of Terms
Security Management
Illustration of the Cover of Safeguarding Your Technology  
Chapter 4 in a Nutshell:

Introduction to Security Management
Commonly Asked Questions
Nurturing Support within the Organization
Planning for the Unexpected
Testing and Review
Implementation and Day-to-Day Maintenance
Security Management Checklist

Effective security strikes a balance between protection and convenience.
  Introduction to Security Management

Because system security is the aggregate of individual component security, "system boundaries" must encompass individual users and their workstations.  But because personal computers are just that (personal), staff behavior can't always be dictated without potentially hampering workers' overall productivity.  Recall that security policy becomes ineffective if it's so restrictive that legitimate user access is threatened.  Thus, a key to successful security implementation is finding a reasonable balance between system protection and user autonomy and convenience. The person responsible for finding that balance and actively promoting organizational security is the security manager.  Security management consists of nurturing a security-conscious organizational culture, developing tangible procedures to support security, and managing the myriad of pieces that make up the system.  The security manager ensures that administration and staff are aware of their security roles, support security efforts, and are willing to tolerate the minor inconveniences that are inevitably a part of system change and improvement.  After all, if personnel circumvent security procedures (e.g., write down passwords, share accounts, and disable virus-checking software), they put the entire system at risk.

Important point.   Effective system security depends on creating a workplace environment and organizational structure where management understands and fully supports security efforts, and users are encouraged to exercise caution.  The security manager leads this effort.
A security manager must:
  1. Communicate to staff that protecting the system is not only in the organization"s interests, but also in the best interest of users.

  2. Increase staff awareness of security issues.

  3. Provide for appropriate staff security training.

  4. Monitor user activity to assess security implementation.

back to topback to home page

Commonly Asked Questions   Commonly Asked Questions

Q. Can an organization make do without hiring a security manager?
A. Yes, but while a security manager doesn"t always need to be hired (especially in smaller organizations), someone must perform the functions of security management all the same.  Many organizations prefer to hire a systems administrator and include security management as one of his or her primary duties.  This is an acceptable strategy as long as the administrator has sufficient time to dedicate to security management.  If, however, routine administrative functions take up a considerable part of the administrator"s work day, then the organization will be better served by having someone who is able to focus on system security.

Q. Would assigning a top educational administrator to the security manager role show commitment to system security?
A. Not necessarily.  Although top administrators are often entrusted with sufficient authority to be effective security managers, it is quite possible that they do not possess the technical expertise necessary for the job.  Security managers are responsible for operationalizing all aspects of system security- a task that requires significant technical competence.  A secondary, but important, consideration is that managing system security can demand a great deal of time- time that policy-makers and other top administrators may be unable to devote given their other essential duties.  While it is imperative that top administrators are actively committed to security effectiveness, in most cases it makes sense that the day-to-day administration of system security be assigned to a security/systems professional.

Q. Where does the security manager fit into the organizational hierarchy?
A. Just as the title implies, security managers and system administrators are most often considered to serve in a management capacity.  The important tasks of developing security regulations, training staff, and monitoring implementation require that the security manager be vested with substantial authority.  While the security manager is not to be confused with a superintendent or principal, he or she should be considered to be the system "boss."  If the security manager is not able to confidently address security miscues at even the highest levels of the organizational hierarchy, protecting system resources adequately becomes an impossibility.

back to topback to home page

Nurturing Support within the Organization

Even when an organization is committed to improving its information security, security managers often find themselves having to work harder than should be necessary to remind staff of the importance of each step in the security process.  Fielding questions about the necessity of sometimes burdensome procedures or the expense of technical and training initiatives is an inevitable but important part of the security manager"s job.  Make no mistake about it, the security manager must not only administer security policy but must also champion it.

Garnering Administrator Support

Support for security at the managerial level is essential because security planning must be aligned within the context of greater organizational goals.  Management must make sure that the organization"s broader plans are adequately considered and that security policy conforms to existing rules, regulations, and laws to which the organization is subject- not to mention that adequate funding is budgeted.  After all, every dollar that is invested in security, as necessary as it surely is, takes a dollar away from some other activity.


Security must be a joint effort between decision-makers, technical staff, and all other personnel.

  While technical support staff may have the best understanding of the ramifications of given technology initiatives, only users have the opportunity to implement policies and management the power to enforce them- and policies that are neither implemented nor enforced are worthless.  Real security requires strong, visible support from senior management as a group, as well as personal accountability and exemplary behavior from individual managers.  If management ignores or circumvents security procedures, others will do likewise.

It Really Happens!

Now Melissa was doing it too!

It just drove Carl crazy.  First it was Dr. Dawson who flouted security regulations-- but what more was Carl to do after his polite reminders about security policies had been ignored by the Superintendent?  Then the Deputy, Dr. Cosgrove, began dismissing the policies as well.  Soon both assistant superintendents had decided that they, too, need not comply with inconvenient security regulations.  And now it had finally reached Melissa, the executive secretary.  Carl didn't blame her-- of course she wasn't going to play by the rules when no one else in her office did. But as the security manager, Carl was worried that when word got out that Melissa no longer changed her password regularly or used a screensaver, the rest of the support staff would quit following regulations as well.  And from there it was a slippery slope until staff in the schools realized that the central office wasn't following agreed-upon security policies.  At this pace, Carl knew it wouldn't take long for the district's entire investment in system security to unravel.


  Management can encourage an atmosphere of security, or they can undermine it- their behavior in large part determines whether staff who are meticulous about security are considered to be the oddballs, or the norm.

Employees also have an ethical responsibility to maintain the security of confidential information entrusted to them.
  Ensuring User Support

Computers and networks are valuable tools to their users.  Many people rely on them every day to help perform their jobs more efficiently.  When computer resources are not available, fulfilling job requirements can become considerably more difficult.  One important role a security manager plays is communicating to staff that protecting the system is in their best interests as well as those of the organization.

back to topback to home page

Planning for the Unexpected

Traditional computer security frequently relies heavily upon protecting systems from attack and minimizing the likelihood of software and equipment failure, but little attention is usually paid to how to handle an attack or failure once it actually occurs.  The result is that when a problem does occur, many decisions are made in haste.  Often, such decisions reflect this lack of forethought and don"t contribute to tracking down the source of the incident, collecting evidence to be used in prosecution efforts, protecting the valuable information contained on the system, or preparing for system recovery.

Important point.   A good policy whenever security is threatened, whether it be a disk crash, an external intruder attack, or natural disaster, is to have planned for potential adverse events in advance. The only way to be sure that you have planned in advance for such troubles is to plan now- because you can never predict exactly when a security breach will happen.  It could happen in a year, a month, or this afternoon.  Planning for emergencies beforehand goes beyond "good policy."  There is no substitute for security breach response planning and other more overarching contingency planning!

It Really Happens!

The district"s backup drive finally broke beyond repair.  But Rita, the security manager, was prepared for the eventuality, and quickly produced a copy of a maintenance contract with her vendor that covered exactly this type of event.  She called the sales representative and was told that she'd receive a replacement drive within 48 hours.  She said that would be fine because the system wasn't due for another complete backup for three more days.  Two days later the replacement part arrived as promised, but, to the sales representative's chagrin, it wasn't compatible with the district's system- the wrong part had been sent!  Remarkably, Rita maintained her composure as the salesman told her that despite his unyielding efforts to correct the mistake, a new part couldn't possibly reach her rural site for another 48 hours.  They'd have to postpone the backup cycle.  "Not necessarily," Rita replied with determination.

Ten minutes later Rita was on her way to the County Office Building.  Two years earlier she had collaborated with the County Administrator before purchasing technology for the district.  The two had agreed to buy compatible equipment that could be shared if an emergency ever arose.  While Rita acknowledged that she wasn't quite facing a dire emergency, borrowing the county"s backup drive for an evening was a fairly simple procedure- and was exactly what she was going to do to prevent a delay in her backup routine.  All of her advanced planning was finally paying off.

Possible responses to an attack:
  1. Protect and Proceed

  2. Pursue and Prosecute

  3. Panic and Pray

The primary goal of "Protect and Proceed" is the preservation of site assets and the timely return to normal activities.

The primary goal of "Protect and Prosecute" is the identification of intruders and the gathering of evidence of all unauthorized activities.

  Security Breach Response Planning

There are three common responses to an attack on an information system: "protect and proceed," "pursue and prosecute," and "panic and pray."  Either of the first two strategies, while clearly opposite in design, can be appropriate depending on the nature of the security breach and the philosophy of the organization.  The third approach, "panic and pray," while unfortunately more common than the first two, is never an effective response.  In fact, the entire rationale for contingency planning is to minimize the need for panic and prayer in the event of a security incident.

Protect and Proceed.  If management fears that the site is particularly vulnerable to attack, it may choose a "protect and proceed" strategy.   Upon detection of an attack, attempts are made to actively interfere with the intruder's penetration, prevent further encroachment, and begin immediate damage assessment and recovery.  This process may involve shutting down facilities, closing off access to the network, or other drastic measures.  The drawback is that unless the intruder is identified directly, he, she, or it may come back into the site via a different path, or may attack another site.

Pursue and Prosecute. This alternative to the "protect and proceed" approach adopts the opposite philosophy and goals.   Here, the primary goal is to allow intruders to continue to access the system until they can be identified and have evidence of their unauthorized activities gathered against them.  While this approach is endorsed by law enforcement agencies and prosecutors because of the evidence it can provide, the major drawback is that the system and its information remain open to potential damage while the organization is trying to identify the source and collect its evidence.

Important point.


Prosecution is not the only possible outcome when an intruder is identified. If the culprit is an employee or a student, the organization may choose to take internal disciplinary action.

  Careful consideration must be given to both of these security breach response philosophies by site management.  It is imperative that forethought and planning take place before a problem occurs or else staff may not know how to respond in the event of a real emergency: to protect and proceed, or pursue and prosecute?  In fact, the strategy eventually adopted might even be one of "it depends upon the circumstances."  For example, an education organization might be willing to accept the additional risks of allowing an intruder to access financial records (that have been properly backed up) while he or she is incriminating him- or herself and being identified.  On the other hand, the organization might decide that threats that access confidential student records must be thwarted immediately because the potential costs of disclosure are not worth the benefits of capturing the intruder.  Regardless of the approach selected, the pros and cons must be examined thoroughly by policy-makers, and users must be made aware of their responsibilities.

Another decision that management must make concerns any distinctions it chooses to make about different types of unauthorized users.  Sites may find it helpful to define who it considers to be "insiders" and "outsiders" by referring to administrative, legal, or political boundaries.  These boundaries imply what type of action should be taken to reprimand an offending party- from written censure to pressing legal charges.  Security plans need to spell out these options and how an appropriate response will be determined if someone is caught behaving in an unauthorized manner.


  Security plans should also include procedures for interaction with outside organizations, including law enforcement agencies and other security support sites.  The procedures should state who is authorized to make such contact and how it should be handled.  Contact information for security support organizations can be found in Appendix E.
  Contingency Planning

Hard drives will crash, electrical surges will zap data, and files will be erased accidentally.  General system security (Chapters 5-9) is designed and implemented to protect an organization from these disturbing events.  But as valuable as locks, virus scanners, disk labels, and passwords can be, if a fire, flood, or sophisticated intruder knocks at your door uninvited, be prepared for trouble.

Make no mistake about the term contingency planning- events that could happen will happen, it's just a matter of when.


For those in the world who are not invincible (read "everyone"), being prepared to overcome the unpredictable is wise and necessary.

  Contingency planning does not protect the organization from a threat but, instead, explicitly details what is to happen if (when) there is a penetration or the system goes down.  It prepares the organization for recovery from a breach in security as quickly and efficiently as possible.  In fact, another term for contingency-type planning is recovery planning.  Planning for recovery from loss or downtime is not pessimistic as much as it is realistic.

Contingency planning can be complex and detailed; after all, it amounts to a blueprint for jump-starting the most important aspects of the organization from scratch and, perhaps, even at another site- all during or, at best, immediately after a catastrophe has struck.  The following outline includes recommended steps and considerations for effectively and completely preparing a contingency plan.  As with all other guidelines offered in this document, each organization (and its security manager and policy-makers) will need to consider these recommendations and customize them to meet their unique needs.


Something you should do.
  Be inclusive when building the contingency planning team by including:12
  • Key policy-makers

  • The security manager

  • Building management

  • Technical support

  • End-users

  • Other representative staff

  • Local authorities

  • Key outside contacts (e.g., contractors and suppliers)

Something you should do.
Obtain and/or approximate:
  • An exhaustive list of critical activities performed within the organization (as should be identified in your risk assessment)

  • An accurate estimate of the minimum space and equipment necessary for restoring essential operations

  • A time frame for starting initial operations after a security incident

  • A list of key personnel and their responsibilities

Something you should do.

Contingency planning should be as specific as possible: If threat "a" happens, the organization will respond by doing "b"; if "c" happens, it will do "d".

Perform and/or delegate the following duties as part of the development of a contingency plan:14
  • Create an inventory of all assets, including information (data), software, hardware, documentation and supplies- include item by item, the manufacturer's name, model, serial number, and other supporting evidence.  Perhaps videotape your facility, including close-ups.  Keep it up-to-date and don't forget peripherals.

  • Set up reciprocal agreements with comparable organizations to share each other"s equipment in the event of an emergency at one site (e.g., school district to school district, school district to state department, school district to school, school to local nonprofit). The key is that you have compatible equipment requirements (e.g., MAC to MAC or Windows to Windows).

  • Make plans to procure hardware, software, and other equipment as necessary to ensure that mission-critical activities are resumed with minimal delay.  Keep in mind that old equipment that you have replaced may no longer ideally meet your needs, but might suffice in a pinch if it still meets your minimum requirements.

  • Establish contractual agreements with "hot" and "cold" backup sites as appropriate.
  1. A "hot" site is an off-site facility that includes computers, backed up data, etc. (everything necessary for resuming operations)

  2. A "cold" site is an off-site facility that includes everything necessary for resuming operations with the exception of actual computers (if some delay is acceptable, then the expense can be incurred when and only when necessary)
  • Identify alternative meeting and start-up locations to be used in case regular facilities are damaged or destroyed.

  • Prepare directions to all off-site locations (if and when moving off-site is actually required).

  • Establish procedures for obtaining off-site backup records (i.e., who, what, where, how, and under whose direction).

  • Gather and safeguard contact information and procedures for communicating with key personnel, suppliers, and other important contacts.

  • Arrange with manufacturers to provide priority delivery of emergency orders.

  • Locate support resources that might be needed (e.g., equipment repair, trucking, and cleaning companies).

  • Establish emergency agreements with data recovery specialists.

  • Arrange for uninterrupted site security with local police and fire departments.

Something you should do.
Specify the following within the plan:15
  • Individual roles and responsibilities- by name and job title so that everyone knows exactly what needs to be done

  • Actions to be taken in advance of an occurrence or undesirable event Actions to be taken at the onset of an undesirable event to limit damage, loss, and compromise

  • Actions to be taken to restore critical functions

  • Actions to be taken to reestablish normal operations
Test, test, test and retest your system before there's a real emergency.  
Test the plan:
  • Test the plan frequently and completely.

  • Analyze test results to determine further needs (e.g., more training and better backup storage).
Periodically try to restore files that have been backed up (be sure to make secondary backups so that you are not risking your only backup copy of the data, but otherwise make the process identical to a real emergency).
Something you should do.   Deal with damage appropriately:
  • If a disaster actually occurs, document all costs (even interim assessment costs) and videotape the damage (to serve as proof of loss).

  • Don't do anything about water damage to technical equipment except immediately contact professional recovery technicians.

  • Be prepared to overcome downtime on your own- insurance settlements can take time to be resolved.  Once settled, rebuilding, repurchasing, and reinstalling can take even more time, so don't expect that anything short of being completely prepared will get your office rolling again in a reasonable amount of time.

Something you should do.
Give consideration to other significant issues:
  • Don't make the plan unnecessarily complicated.

  • Make one individual responsible for maintaining the plan, but have it structured so that others are authorized and prepared to implement it if needed.

  • Keep the plan in a secure but convenient location so that it can be accessed as needed.

  • Update the plan regularly and whenever changes are made to your system.

  • Recognize that people always come first (before equipment, information, or mission).

Quote- It's no one's fault, but everyone's problem.  (Robert F. Wagner, Jr.)

This anecdote may sound far-fetched, but something remarkably similar was reported to have happened after the 1996 California earthquake.

It Really Happens!

The Great Quake, as it was soon called, took everyone by surprise- including the regional education agency that had been compiling student records for the state legislature for more than two months.  Don Jones was in charge of the project and found himself in quite a predicament.  Luckily, or unluckily depending on the outcome of his actions, he didn't think about what he was about to do-- he just ran back into the burning building to get a copy of his backup data tapes.  He returned to an astonished group of co-workers who were amazed that he would, quite literally, risk his life to protect "his" data.  He made it out alive, so he might say that it was worth the risk, but wouldn't it have been easier to have just practiced off-site storage?

back to topback to home page


  Don't let your organization contribute to the numerous stories of contingency plans that failed because of a minor oversight that easily could have been remedied, but wasn't identified until it was too late.
Testing and Review

Most organizations undergo some sort of annual financial auditing as a regular part of their fiscal life.  So, too, are security audits an important part of running any computing environment.  A complete security audit should include an examination of any policies that affect or are affected by system security, as well as a thorough test of each mechanism that is in place to enforce said policies.  After all, a plan isn't much good if it can't be implemented- and the only way to really be sure that security policies and mechanisms are being implemented properly is through extensive testing (or during a real emergency, at which point it is too late to correct shortcomings).

When a threat or disaster is actually happening is not the time to discover the meaning of the phrase-a false sense of security.


Keep in mind that there are limits to reasonable testing.  The purpose of testing is to verify that security procedures are being implemented properly and meet critical policy goals, not to prove the absoluteness of every aspect of the system and policy.
  Although security drills can't be scheduled every day of the week without seriously affecting office productivity (and probably morale), they should be conducted as frequently as is necessary to determine that security procedures are being implemented effectively.  What kind of drills?  Well, if your risk assessment (see Chapter 2) identifies a particular type of natural disaster as a primary threat to your organization, then a drill based on that scenario could be constructed (e.g., a test to verify your backup and recovery mechanisms after an earthquake).  On the other hand, if your greatest threat is from external intruders attempting to penetrate your system, a drill might be conducted that simulates a hacker attack in order to observe access countermeasures in action.

It Really Happens!

City Schools committed itself to top-rate system security.  It assigned a staff member to serve as a full-time security manager, purchased state-of-the-art backup equipment, and refurbished an old building it owned on the edge of town to serve as off-site storage for its backup tapes.  The security manager, having attended numerous technology and security conferences to keep abreast of his job responsibilities, took pride in his system and tested every step of his backup procedures right up until the tapes hit the shelves at the off-site storage facility.  To the best of the manager's knowledge, security drills had proven time and again that the system could truly be trusted.  One night, as the manager lay in bed thinking about how wonderful the City Schools security system was, he realized that he'd never actually reloaded backup tapes from off-site storage.  He was, of course, very confident that the facility (with its fire-retardant renovations, anti-static carpeting, and full-time security guard) was secure, but acknowledged that he couldn't be sure until he actually tested it.

The next morning, he went to the facility, checked in with the security guard, entered the combination to unlock the door, and signed out a sample tape.  He took it to his office and tried to reload it on a stand-alone "test" computer, but, to his great surprise, found that the tape held no data.  He immediately returned to the storage facility to withdraw another tape but again, upon trying to read the data, found that there were no files.

Quicker than a flash, the security manager called in a team of high-tech security consultants to diagnose his problem.  He showed them his records of test after test and drill after drill that verified that all pre-storage steps to backing up the data were being implemented properly.  The specialists were convinced that the off-site facility was the place to begin the investigation.  As they approached the building, the security manager mentioned that while he hadn't thought to budget for the high hourly charges of the expert consultants, they should take whatever time they needed to figure out the problem because he wanted that backup system running properly.  To this, the lead consultant replied as he walked toward the door, "Well, in that case I think that I've got some good news and some bad news to tell you.  The good news is that I've already identified your problem and will only have to charge you for one hour's work."

"That is good news," the manager responded.  "But what's the bad news?"

"The bad news is that electrical transformer behind the storage facility.  Unless you have lead walls, it's emanating enough residual electricity to erase every tape you have in the building.  You're going to have to move your storage site."

"But we have a very secure site here," the manager contended desperately.  "It has a security guard, a state-of-the-art sprinkler system, and anti-static carpeting."

"And it also has a giant, tape erasing, electrical plant in its back yard.  I'm sorry, but this site will never be secure.  Every backup tape that gets within 50 feet of the building is going to have all of its data erased.  But look at the bright side- while you may have lost the investment in the facility, at least you found all this out before you really needed the backed up data.  Take last night's tapes to another storage location and you should be okay."


Although security can't be tested each day, testing must be performed frequently enough to verify the effectiveness of security initiatives.
  If full-fledged security drills prove to be too time-consuming and disruptive to normal operations to be implemented on a large scale, consider testing individual facets of the security system one at a time.  Backup procedures can be examined to make sure that data can be recovered from storage tapes.  Log files can be checked to make sure that information that is supposed to be maintained has been done so accurately.  And other features of the system can be evaluated and analyzed as well.  When a security drill is performed, great care should be given to devising the test.  It is important to clearly identify what is being tested, how the test will be conducted, and what results are to be expected.  All aspects of this process should be documented and included in, or as an adjunct to, the security policy.

Who performs security audits and drills?
  1. The organization's security professional(s)

  2. Employee teams (peer reviewers from within the organization)

  3. External reviewer teams (from cooperatives, consortia, or other partner organizations)

  4. Hired external expert security consultants

back to topback to home page

Implementation and Day-to-Day Maintenance

Security is more than keeping hackers and other trouble-makers out of your system.  It involves a host of internal practices that serve to protect information in the case of system or disk failure.  Some of the main activities security managers engage in on a day-to-day basis include administering backup and virus protection mechanisms, staying abreast of software updates, managing user accounts, and monitoring system activity.


Recommended practices concerning actual backup procedures are included in Chapter 6.


It is almost impossible to over-emphasize the need for a good backup strategy.  System backups not only protect the organization in the event of hardware failure or accidental deletions, but they also protect staff against unauthorized or accidental changes made to file contents.  If an error is ever made (and we all know that they are), having the option of accessing an unaltered backup can be very appealing.  But reaching into those archives is a viable strategy only when backup files have been made properly- a backup of a file that contains the errors and/or viruses you are trying to eliminate usually isn't very helpful.  Similarly, backup files need to be created at appropriate intervals and themselves must be well protected from damage and destruction.

Which type of backup strategy makes sense for your organization?  That depends on the types and number of files in the system, the level of technical expertise within the organization, and the organization's commitment to security- information that can be found in the results of a well-executed risk assessment (see Chapter 2).  Even after needs unique to the organization have been identified, however, there are several more overarching issues that need to be considered before establishing backup plans:

  1. What amount of exposure to data loss can your organization comfortably tolerate?

  2. How old is your equipment?  How reliable is it?

  3. What is the nature of your workplace?  Do you process new data everyday?

To further evaluate the type of backup strategy that will best meet your organization's needs, also weigh the following factors:16

  1. The time and effort required to make changes to the files:
    If changes to the file take only a little time, backing up those changes may not be imperative.  If the changes require a great deal of work (e.g., entering data collected from a long form), don't risk that effort and instead back it up frequently.

  2. The time and effort required to back up the files:
    If the actual backing up process requires little effort, why put it off?  If it is time consuming, be more aware of proper timing.

  3. The value of the data:
    If the data are particularly valuable, back them up more often.  If not, frequent backup may be less necessary.

  4. The rate of file change:
    If a document changes rapidly (e.g., because of the operator's speed in data entry), more frequent backup is probably needed.

You may choose a combination of complete and partial backup routines.  However, when initiating any system, a complete backup should first be done to serve as a reference point.
In general, there are three types of backup strategies:
  1. A complete backup- backing up your entire hard drive.  The advantage of this strategy is its completeness; you will get a snapshot of all your hard disk's contents.

  2. A partial backup- only backing up selected directories.  This is useful and efficient if your work is concentrated in a specific area of your hard disk.

  3. An incremental backup- only backing up those files that have been changed since the last backup.  It means using backup software to scan the files to see if they have been changed since the last backup cycle.  If so, the file is saved; if not, the previous backup is maintained.

Above all, devise a backup strategy that is realistic for your organization's setting.
  So how do all of these factors get synthesized into an effective strategy for meeting an organization's needs?  The answer is simple: use the information available in order to devise a backup plan that is most likely to be implemented.  Whatever the solution might be, be creative enough to develop the strategy that is most likely to ensure that your data gets backed up.  It is imperative to establish realistic policies based on your agency's environment.

In any case, set a backup schedule that fits your agency's needs and work style and stick with it.  Here are a few examples of common backup routines:

  • Twice daily: partial at noon, full at end of day

  • Once daily: full backup at end of day

  • Three times weekly: full backup at end of every other day

  • Twice weekly: full backup Tuesday, partial on Thursday

  • Once a week: full backup

  • Monthly: full backup

Option C, "In a secure off-site location," is the best option from purely a security perspective. See Chapter 5 for recommendations on securing a location.
  A last major planning issue to consider is what to do with backup files once they have been created.  The choice of backup location depends on the agency's needs, resources, and ability to secure its physical structure (see Chapter 5).  Any single option, or mixture of options, can be chosen as long as they meet the site's needs and have a realistic chance of being implemented.  Backup storage options include:

Option A: In the same room- great for easily recovering files after data loss, but bad if a threat gets "in" the room.
Option B: In the same building- less convenient for correcting mistakes, but physical separation increases security as a single event is less likely to damage everything
Option C: In a secure, off-site location- not convenient at all for quick data recovery, but excellent for protection if maintained in a secure facility.
  Like all security decisions, selecting a location for off-site storage facilities should be based on risk assessment findings.  If, for example, risk assessment shows that an earthquake is the threat of chief concern, locating an off-site storage facility 100 miles away but along the same fault line makes little sense.  Similarly, if risk assessment identifies flood as a paramount threat, the location of off-site storage should be outside the same flood plain.

See Chapter 6 for more specific guidelines about combating viruses and other rogue programming.
  Virus Protection

Any machine that is connected to a network or that interacts with others via diskettes or a modem is vulnerable to rogue programs: computer viruses, worms, Trojan horses, and the like.  It is the security manager's duty to develop and monitor procedures for preventing viruses and other rogue programs from infiltrating the system.  As a rule of thumb, no diskette from outside the system (including brand name, shrink-wrapped software) should ever be used on a system machine without first having been scanned by an up-to-date antivirus program.

The most effective protection against a virus is having a clean, up-to-date backup file.

Bug definition and pronunciation- any of a near countless number of species of creepy, crawly insects, or, more commonly, unexpected programming errors in computer software.
  Software Updates

It goes without saying that computer systems have bugs.  Even operating systems, upon which we depend for so much of the protection of our information, have bugs.  Because of this, software publishers release updates on a frequent basis.  Often these updates are, in fact, plugs for holes in the software's security that have been discovered.  It is important that whenever these bugs are identified, the system manager takes all action possible to remedy them as soon as possible in order to minimize exposure.

A corollary to the "bug problem" deals with the source for obtaining upgrades to software.  Many computer systems and software packages come with support from the manufacturer or supplier.  Remedies that come directly from such a source tend to be trustworthy and can usually be implemented fairly quickly after receipt (and proper testing no matter the source).  Other sources, such as software posted on Internet sites, must be scrutinized more closely.

As a general rule, trust manufacturer upgrades more than those that are posted on the Internet.

  Effective security demands "checks and balances" so that every user, including the system adminis-trator and security manager, is accountable for system activity- no one should be able to print his or her own paycheck without being monitored.
  User Account Management

As stated throughout this chapter, a single person needs to have primary responsibility for an information system.  For this person, the security manager or systems administrator, to effectively supervise the system, he or she needs to have access to all system components and files- access that is commonly referred to as "system administrator privileges."  It is generally considered to be good practice to share system administrator access privileges with someone other than the system administrator, if for no other reason than to have emergency system access should the administrator ever become unavailable.  But, having said this, such total access also requires total accountability, and should be limited to the fewest number of staff as is necessary to keep the system secure- after all, each person with total system access has the ability to override any and all security features.

  Users other than the system manager (and an accountable replacement in case of emergency) should be given access to the system based solely on their job needs.  Restricting user access minimizes the opportunities for accidents and other possibly inappropriate actions (see Chapter 8).  Through the use of user accounts, each authorized user is identified before accessing the system, and any action that is made by that user is classified as such.

Users should be given access only to files and systems that they need to do their jobs, and nothing more.


To recognize deviations from normal system use, the manager must understand how the system behaves when it is running properly.
  System Use Monitoring

System monitoring can be done by either the security manager or by software designed specifically for that purpose.  Monitoring a system involves looking at all aspects of the system, identifying patterns of regular use, and searching for anything unusual.   Most operating systems store information about system use in special files referred to as log files.  Examination of these log files on a regular basis is often the first line of defense in detecting unauthorized use of the system.  System managers should:

Something you should do.  
  • Compare lists of currently logged-in users and past log-in histories.  Most users typically log in and out at roughly the same time each day.  An account logged in outside the "normal" time for the account may be a sign of unauthorized activity and require investigation and explanation.

  • Check system logs for unusual error messages.  For example, a large number of failed log-in attempts in a short period of time may indicate that someone is trying to guess passwords.

While the security manager is responsible for monitoring user activity, doing so becomes much more feasible when working with and not against the staff.

It Really Happens!

Steve was serious about the security of his school's computer system.  And although some folks may have thought that he was perhaps too serious, it didn't stop him from making them toe the security line all the same.  He was a no-nonsense kind of security manager.

When he noticed some extraordinarily odd system activity one afternoon during his daily (but randomly timed) monitoring operations, he was fast on the trail of the troublemaker.  Steve knew he was an efficient security manager, but he surprised even himself by so quickly tracing the violations back to Mrs. Todd, the fifth-grade teacher.  He should have known to never have trusted Mrs. Todd.  No one could be that nice- it had to be a ruse.

Steve marched down the hall and through the door into the empty classroom in time to find the culprit still seated at her computer.  He could barely control himself, "What in the world do you think you're doing?  You could lose your job for hacking my system.  In fact, I'm going to do my best to see that you do!"

As Steve could have predicted, Mrs. Todd denied that she had done anything improper. "But, Mr. Johnson, what are you talking about?... And please don't use that tone with me."
"Tone?" Steve replied in amazement. "You're lucky that all I use is "tone" with you.  Now let me see what you're doing here."  He walked behind Mrs. Todd's desk and looked at her monitor screen.  "Hmm," Steve thought out loud, surprised to see that she was working on the electronic grade book that was on her own hard drive and didn't require being logged on to the network.  "What were you doing before I got here?  Were you on the network?"

Mrs. Todd looked puzzled, "No, I've been in my grade book since the children left.  Why?"
Before Steve could continue with his interrogation, Mrs. Yow, the Principal, charged into the room.  "What is all the commotion about, Steve?  I could hear you hollering half-way down the hall."
"I caught Mrs. Todd tampering with the report card files on the network.  It's a serious offense to our security system."

Mrs. Todd was quick to defend herself.  "He did no such thing, Mrs. Yow.  He couldn't have caught me doing that because I would never do such a thing.  Look, I'm working on my own grade book."

Steve was surprised that Mrs. Todd was able to maintain such a straight face when he had caught her nearly red-handed.  But before he could say anything, Mrs. Yow reached for Mrs. Todd's keyboard.  She hit a few function keys and clicked the mouse once or twice.  Steve could tell that she was pulling up an audit trail of the computer's use.  He loved having a principal who knew her way around the equipment!

"Steve," Mrs. Yow asked, "what time did the violation take place?"

"Three o'clock," he replied, "right after last period.  That's when Mrs. Todd said she got on the computer.  Quite a coincidence, huh?"

The principal stared at him, "It must have been a coincidence, because the audit trail shows that she's been in her grade book file since 3:02 p.m.  No activity before that since eight o'clock this morning."  Mrs. Yow frowned at Steve before looking apologetically at the fifth-grade teacher, "I'm sorry Mrs. Todd.  He may get carried away sometimes, but he does have a big job in keeping our network safe."  She looked back at Steve, "Did you really need to make such a scene when you weren't even sure that you were accusing the right person?"

Steve tried to reply, but Mrs. Todd cut him off.  "That's okay, he must have really thought he had found the culprit."  She laughed, "Me, a computer hacker, isn't that a story?"

Steve looked at the woman who now defended him.  Just moments earlier, he had wrongly accused her of hacking and had threatened her job.  So, she might really be that sweet after all.

"Come on, Steve," Mrs. Yow finally said, breaking the silence, "we've got a hacker to identify.  This time, no going off half-cocked with accusations until we know what we're talking about."

Post-script: Over the next two weeks, Steve and Mrs. Yow monitored a hacker who was masquerading as several different staff members (including Mrs. Yow) and attempting to enter protected report card files.  After much analysis, Steve identified a bug in the password software that allowed the hacker to misrepresent himself as an authorized user.  Once this was accomplished, they were able to trace the unauthorized activities back to the machine from which the intruder was working- and, subsequently, were able to catch the eighth-grade student who was trying to pull off the charade.  After dealing with the troublesome student appropriately (during which time Steve let Mrs. Yow do most of the talking), Steve again apologized to sweet Mrs. Todd for his unwarranted accusations and unprofessional behavior.


  The task of systems monitoring is not as daunting as it may seem. Security managers can execute many monitoring tasks periodically throughout the day during even the briefest of free moments (e.g., while waiting on hold on the telephone).  By executing the commands frequently, the manager will rapidly become familiar with seeing "normal" activities and become better able to spot things that are out of the ordinary.

The single most important thing about monitoring system use is that it be done regularly.  Picking one day out of the month to monitor the system is not a solid security strategy, since a breach can take place in a matter of hours or even minutes.  Only by maintaining a constant vigil can you expect to detect security violations in time to react to them- hence one appeal of monitoring software that, unlike even the most dedicated of administrators, is able to work 24 hours and seven days a week.

Despite the advantages that regular system monitoring provides, some intruders will be aware of the standard log-in mechanisms used by systems they are attacking and will actively attempt to evade these mechanisms.  Thus, while regular monitoring is useful in detecting intruders, it does not guarantee that your system is secure and should not be considered an infallible method of detecting unauthorized use.

Commonly Asked Questions  
A Final (But Very Important) Question
Q.How does a security manager verify that the system for which he or she is responsible is actually secure?

A. 1) Read this document and follow the security guidelines as outlined in the checklists at the end of each chapter.

   2) Practice, drill, and test each and every security measure being implemented.

back to topback to home page

Security Management Checklist

While it may be tempting to simply refer to the following checklist as your security plan, to do so would limit the effectiveness of the recom-mendations. They are most useful when initiated as part of a larger plan to develop and implement security policy throughout an organization. Other chapters in this document also address ways to customize policy to your organization's specific needs- a concept that should not be ignored if you want to maximize the effectiveness of any given guideline.

Security Checklist for Chapter 4
The brevity of a checklist can be helpful,
but it in no way makes up for the detail of the text.

Check Points
for Policy Development and Implementation
  1. Has it been communicated to staff that protecting the system is in everyone's best interests?
      Click here
  1. Has an effort been made to increase staff awareness of security issues?
      Click here
  1. Has appropriate staff security training been provided?
      Click here
  1. Are security activities regularly monitored (see Step 14 below)?
      Click here
  1. Has administrator support been garnered?
      Click here
  1. Has user support been sought?
      Click here
  1. Has a security breach response plan been developed?
      Click here
  1. Have contingency plans been developed to deal with significant and probable threats (addressing the issues raised on pages 42-44)?
      Click here
  1. Are response and contingency plans frequently and exhaustively tested?
      Click here
  1. Has a backup plan been developed and implemented?
      Click here
  1. Is a virus protection system in place?
      Click here
  1. Are software updates tracked?
      Click here
  1. Are user accounts managed appropriately?
      Click here
  1. Is system use monitored appropriately?
      Click here

back to topback to home page
back to previous chapternext chapter