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.
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:
- Communicate to staff that protecting the system is not
only in the organization”s interests, but also in the best interest
- Increase staff awareness of security issues.
- Provide for appropriate staff security training.
- Monitor user activity to assess security implementation.
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
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
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
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.
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.
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
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
Possible responses to an attack:
- Protect and Proceed
- Pursue and Prosecute
- 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
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.
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.
Be inclusive when building the contingency planning team by including:12
- Key policy-makers
- The security manager
- Building management
- Technical support
- Other representative staff
- Local authorities
- Key outside contacts (e.g., contractors and suppliers)
Obtain and/or approximate:13
- 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”.
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
- 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
- A “hot” site is an off-site facility that includes computers,
backed up data, etc. (everything necessary for resuming
- 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
- 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
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 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).
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.
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
- 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).
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?
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).
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
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
“That is good news,” the manager responded. “But what’s the bad
“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
“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?
- The organization’s security professional(s)
- Employee teams (peer reviewers from within the organization)
- External reviewer teams (from cooperatives, consortia, or other
- Hired external expert security consultants
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
- What amount of exposure to data loss can your organization comfortably
- How old is your equipment? How reliable is it?
- What is the nature of your workplace? Do you process new data
To further evaluate the type of backup strategy that will best meet
your organization’s needs, also weigh the following factors:16
- 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.
- 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.
- The value of the data:
If the data are particularly valuable, back them up more often.
If not, frequent backup may be less necessary.
- 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:
- 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.
- 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.
- 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
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
- 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 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:
In the same room- great for easily recovering files after data
loss, but bad if a threat gets “in” the room.
In the same building- less convenient for correcting mistakes,
but physical separation increases security as a single event is less likely
to damage everything
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.
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.
any of a near countless number of species of creepy, crawly
insects, or, more commonly, unexpected programming errors in computer software.
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
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
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:
- 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
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,
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
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.
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.
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.
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
- 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?