Which type of security control refers to responding and fixing a security incident

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:

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.

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.

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.

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

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.

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

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)

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?

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

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

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

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

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.

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.

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

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.