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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

• 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

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".

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).

 
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.

Backups

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:¹⁶

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.

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

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.

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.

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 should be given access only to files and systems that they need to do their jobs, and nothing more.

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:

• 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.

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.

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