Can You Handle the Headaches? Analyzing and Optimizing the Effectiveness of the Incident Management Process

Transcription

1 LAW, INVESTIGATIONS, AND ETHICS Can You Handle the Headaches? Analyzing and Optimizing the Effectiveness of the Incident Management Laurence J. Wolf Recovering from incidents in a timely appropriate manner is vital to maintaining operational efficiency, controlling costs, and keeping users happy and productive. A key to quick recovery is having an incident management process in place. An analysis of the incident management process can offer insight into how effectively the process supports problem detection and isolation and systems restoration. An analysis of the incident management process can contribute to systems and application resilience, the capacity to keep failures from dramatically affecting users. Highly available and secure systems are a business imperative, for good reason. Averting a system crash or hacker attack can prevent loss of revenue, production delays, and escalating costs. The sobering reality, though, is that the powerful, complex technologies we all rely on aren t perfect. They can and do break down. People create problems, too. Often, they don t adhere to best practices or they lack needed knowledge. They make mistakes. And sometimes, they re just plain malicious. As stated above, whether incidents result from glitches or attacks, recovering from them in a timely appropriate manner is vital to maintaining operational efficiency, controlling costs, and keeping users happy and productive. A key to quick recovery is having an incident management process in place that enables network, systems, and security management organizations to correctly address problems and maintain service levels. The incident management LAURENCE J. WOLF, CISSP, is Senior Manger in Deloitte s Enterprise Risk Services Practice. He has 19 years of experience in systems, networks, security, and software development, and resilient design, implementation, and testing, as well as business continuity planning. He has spent the past 12 years working at and consulting for Wall Street financial firms and has a degree in electrical engineering from the University of Pennsylvania. Acknowledgments must be given to Vik Bhat and Danny Rojas for their help and assistance in formalizing this methodology. L A W, I N V E S T I G A T I O N S, A N D E T H I C S 9

2 Incident management is a complex interaction of people, processes, tools, and communication. And different circumstances can require distinct approaches. process embraces the processes, procedures, and supporting tools to detect, isolate, and restore failed or malfunctioning systems. An analysis of the incident management process provides a baseline against which all incident-related activities can be compared and creates a framework for conducting a gap analysis to determine the best path to improvement. Diligently applied, an analysis of the incident management process can help equip technical organizations to accelerate problem resolution, keep problems from reoccurring, and improve feedback to users waiting, patiently or otherwise, for problems to be fixed. Again, it also can contribute to systems and application resilience. ADDRESSING THE AVAILABILITY AND SECURITY IMPERATIVES Organizations define availability differently depending on their needs. One may require uptime. For another, having systems humming during the business workday with a four-hour incident recovery time is fine. Many organizations dedicate considerable human and technical resources to creating an incident management process that satisfies uptime requirements. Typically the process provides both proactive monitoring, such as pre-outage conditions and performance measurement, and reactive monitoring, including fault management and system and user outages. Although some organizations successfully use the incident management process, others struggle to understand and implement it. Incident management is a complex interaction of people, processes, tools, and communication. And different circumstances can require distinct approaches. To conduct an effective analysis of the incident management process, an organization needs to understand its distinct requirements. It may face technical issues, such as a fault management system that does not provide timely information. It may have a disorganized approach to problem resolution. Or, it may not view a problem as a priority when it should. In addition, different problems can require different levels of communication. An outage, for example, can require frequent, widely distributed progress updates for anxious users. A security violation, on the other hand, may mean limited sharing of circumstances, damage, and problem resolution. Regardless of the origin or nature of problems, analysis of the incident management process can break the process down into discernable steps, which can be documented and compared against an ideal process. Analysis of the gaps between the organization s process and the ideal can be used to develop remediation plans to improve performance. VISUALIZING THE IDEAL PROCESS In the ideal incident management process, each phase of the process operates like a clock. Confusion and misinformation do not exist. Communications are perfect. s are detected instantly and confirmed, and data is routed to the correct technical group, which quickly solves both known and unknown problems. Once solved, problems are sorted, collated, aggregated, and harmonized in a postmortem process. That process builds a knowledge base that is used to determine the root cause of the problem, enabling remediation and prevention of repeat occurrences. Of course, several obstacles stand in the way of the ideal incident management process. The organization may have institutional knowledge gaps resulting from poor organization or the introduction of new systems. Individual staff may not have the expertise or knowledge of organizational systems to handle incidents. The organization may not have the needed tools. An organization should carefully assess and prioritize its needs to gain the best results with the least effort. For example, lost passwords may take three minutes to reset, so improving this process would yield 10 I N F O R M A T I O N S Y S T E M S S E C U R I T Y W W W. I N F O S E C T O D A Y. C O M

3 FIGURE 1 Generalized Ideal Incident Management Help Desk Operational Personnel Detection Detection Resolution Net Ops Sys Ops DBA Storage Update Users Escalation in group or to vendor support resolved? 4 Management Systems 2 Sufficient clues or problem routing indications? Multicast the problem? Broadcast Specific Group Multi-Group 1 3 Isolated? Isolation Net Ops Sys Ops DBA Storage Update Users New clues or indicators? Escalate in group? Detection Detection Post Mortem Known Cause? Able to determine Root Cause? Track for Future Research/ Inform Relevant Users Incident and Root Cause Tracking Fix Root Cause Root Resolved 5 Phases 1. Detection Isolation 4. Resolution 5. Post-Mortem/Knowledgebase Building Input/ Output Service Decision Documentation Database Terminiation little gain on a per-user basis. On the other hand, the loss of an entire system might be a multihour or even multiday event involving all of the users in that organization. EXPLORING THE GENERALIZED IDEAL INCIDENT MANAGEMENT PROCESS The generalized ideal incident management process can be broken down into five key, general steps: 1. Detection Isolation 4. Resolution 5. Postmortem Analysis of the incident management process involves creating a flowchart that breaks these steps down in sufficient detail. An example of required detail is incident escalation. Escalation is a subtask of both the isolation and resolution steps, with user notification occurring at both those steps and the postmortem step. Some complex organizations, for example, those with separate subgroups to handle networks, systems, and security, may have or need a multilayer escalation process. Figure 1 shows the full life cycle of an incident, comprising the five key steps and related subtasks. The groups shown in the isolation and resolution steps are merely examples of groups that may be involved in L A W, I N V E S T I G A T I O N S, A N D E T H I C S 11

4 FIGURE 2 Detection Sources of Input Information Help Desk Operational Personnel Initial Input Data Management Systems Detection the full life cycle of a problem or in the development and management of the infrastructure itself. The discussion of each process step is accompanied by a list of potential gaps that can impede effective problem resolution. Your organization may have unique issues and methods that need to be understood beyond the suggested review points. PROBLEM DETECTION In the problem detection process, three types of information sources can feed information regarding the current incident: 1. A help desk function that receives notification from the end-user community that service is unavailable. 2. Operational personnel who detect a problem from the infrastructure perspective before service disruption is noticed by the end-user. 3. Fault management systems that monitor and detect incidents automatically trigger alerts based on system thresholds and system failures. These sources provide initial problem input data, as seen in Figure 2. This data influences how effectively the problem is routed among IT personnel. Detection: Gap Analysis Key Points Does the organization understand if and when a problem has occurred? Does the organization have any unique problem detection methods? Has the organization evaluated its technical toolkit from these viewpoints: view: Whether the organization has the necessary tools to account for each step of the incident management process from detection to postmortem Architecture view: Whether all architecture components within the IT infrastructure are being monitored proactively, both intraday and trend, and reactively for fault detection Organizational view: Whether each organizational subunit has, maintains, and monitors the necessary incident management tools Integration view: Whether the tools are effectively integrated with one another and into a central management framework (e.g., HP OpenView) Are there delays in understanding that problems are occurring? Is operational staff alert and ready during critical business hours? 12 I N F O R M A T I O N S Y S T E M S S E C U R I T Y

5 FIGURE 3 : Decision Instances : Types Sufficient clues or problem routing indications? Broadcast Detection Specific Group Isolation Multicast the problem? Multi-Group Knowledge Management (via Post Mortem Feedback ) Has the primary data source been identified? If the help desk is the fastest source of problem detection, tools and operational personnel may need improvement. What is the quality of data received from all sources? Is alarm correlation employed to prevent repeats of alarms that may distract personnel? Are problems closely tracked by logging time-stamped actions? PROBLEM ROUTING During the problem routing process, the initial input data is used to determine whether there are sufficient clues or problem routing indicators to route the problem to the appropriate information technology group, that is, the group with the expertise to effectively isolate and resolve it. Figure 3 shows how problem routing occurs, depending on initial incident input. The broadcast approach is executed when there is insufficient information to determine that a specific IT group should address the problem. All IT groups receive initial incident information and collectively decide which group or groups should own the problem. The owner or owners are then assigned responsibility for problem isolation. When sufficient information exists, a decision is made to determine whether to disperse the information to specific multiple groups (multigroup approach) or to an individual group (specific group approach) for further incident response. Knowledge management plays a vital role in diagnosing the problem and effectively routing it to the appropriate groups. Incident knowledge is integrated into the problem routing process as it becomes available through a feedback mechanism that incorporates postmortem analysis and other knowledge base sources. As the knowledge base increases, incidents can be categorized, isolated, and resolved more quickly, decreasing overall incident response time. The expanded knowledge base also filters false positive information that can potentially have IT groups follow incorrect approaches toward incident response. s can be categorized into these types: Trivial forgotten passwords, software requests, user log-in problems L A W, I N V E S T I G A T I O N S, A N D E T H I C S 13

6 Many organizations have the talent required to work through problems, but connecting the talent to the problem is often the key issue toward achieving a timely resolution. ntrivial three subtypes: User outage a loss of service to the user System outage no loss of service to the user, but a specific system is out of service Pre-outage indicators system alerts such as high CPU utilization or high error rates; or human indicators, such as user reports that an application is behaving slowly Enterprise problems that affect a large number of users and systems, such as an enterprisewide or Internet outage. Using these designations allow more effective problem escalation, and, in times of overload, give guidance for a triage process. An organizational function designated as the problem coordinator should have overall responsibility for incident management and coordination efforts. This role is particularly important in a multigroup situation to ensure proper escalation at routing and in the later stages of isolation and resolution. : Gap Analysis Key Points Is there a way to understand the scope of an incident? Have incidents been categorized into trivial, nontrivial, and enterprise? Is problem routing organized, or does one person often end up sweating over it alone in a room? Is there a preplanned escalation process if a problem lingers? Is there a role equivalent to the problem coordinator to drive an incident to resolution? Is triage employed in any formal manner when needed? Are event correlation tools in place to factor seemingly unrelated events into the actual cause to speed routing to the correct group? Is there a knowledge base from which to operate? Is it formal, electronic, and accessible to all who may need it? Or, is it embedded in the minds of certain key personnel, and thus subject to their availability and lost when they are gone from the organization? Are problems closely tracked by logging time-stamped actions? PROBLEM ISOLATION The isolation process begins once a problem has been routed to the appropriate IT group or groups. Several decision instances and additional steps are used to achieve problem isolation as seen in Figure 4. The process is characterized by iterative steps that attempt to further pinpoint the source of the incident, as well as areas affected by the outage. If there is sufficient information to determine what the problem is, a decision instance is reached, at which it is determined whether escalation should be executed within the IT group involved in prior problem routing. The problem can either be assigned to the appropriate IT group with the expertise to isolate the problem, or the process can continue by escalation within the IT group involved in the routing phase. Many organizations have the talent required to work through problems, but connecting the talent to the problem is often the key issue toward achieving a timely resolution. The problem coordinator plays a key role in this stage to keep the process moving. The escalation process is iterative until the problem has been isolated and is ready for resolution by the correct group or groups. If there are not enough indicators to formulate an approach toward problem isolation, the IT group assigned during the problem routing process executes an escalation step and sends a multicast to other IT groups for insight and support. The main objective of this process is to isolate the problem quickly and accurately. It is vital that the process not linger with a person or group that is not equipped to understand the problem correctly. 14 I N F O R M A T I O N S Y S T E M S S E C U R I T Y W W W. I N F O S E C T O D A Y. C O M

7 Isolation: Gap Analysis Key Points Is there an effective methodology for problem isolation? Is there a tight escalation schedule for unresolved issues? Does each group maintain an escalation schedule to bring more talent to a problem in a timely manner? Is there a role equivalent to the problem coordinator to drive an incident to resolution? Is triage employed in any formal manner when needed? Are event correlation tools in place to factor seemingly unrelated events into the actual cause to speed routing to the correct group? Is there a knowledge base from which to operate? Is it formal, electronic, and accessible to all who may need it? Or, is it embedded in the minds of certain key personnel, and thus subject to their availability and lost when they are gone from the organization? Is there a means to effectively communicate problem status to users when appropriate? Are problems closely tracked by logging time-stamped actions? PROBLEM RESOLUTION In the problem resolution process shown in Figure 5, IT groups that have isolated the problem redirect their efforts toward resolution. When the resolution process is nontrivial and requires additional resources and time, the user community is notified that the problem resolution process is active. Escalation procedures are then executed within the group assigned to resolve the issue and, if applicable, vendor support can be reached for further technical guidance or assistance to achieve resolution. The identified IT groups responsible for problem resolution should have adequate resources and technical expertise to resolve the incident. This process flow will iterate until a resolution has been achieved. Resolution: Gap Analysis Key Points Is there an effective methodology for problem isolation? Have service level agreements been established with vendors to ensure their FIGURE 4 Isolation : Decision Instances : Isolation Steps Isolated? Broadcast Isolation Net Ops Sys Ops DBA Storage New Clues or Indicators? Specific Group Resolution Isolated? Multi-Group Isolation L A W, I N V E S T I G A T I O N S, A N D E T H I C S 15

8 FIGURE 5 Resolution : Decision Instances : Resolution Steps Resolved? Isolation Resolution Net Ops Sys Ops DBA Storage Escalate in Group or to Vendor Support Post Mortem Update Users Resolution support once their responsibility is identified? Is there a tight escalation schedule for unresolved issues to bring more talent to a problem in a timely manner? Is there a role equivalent to the problem coordinator to drive an incident to resolution? Is there a knowledge base from which to operate? Is it formal, electronic, and accessible to all who may need it? Or, is it embedded in the minds of certain key personnel, and thus subject to their availability and lost when they are gone from the organization? Is there a means to effectively communicate problem status to users when appropriate? Are problems closely tracked by logging time-stamped actions? Are there facilities to test problem resolution ideas without affecting functioning production systems? POSTMORTEM Once the problem has been resolved, affected users are informed that service is available, and the postmortem process is initiated. During the postmortem process shown in Figure 6, IT groups responsible for resolution continue the incident management process by determining whether the root cause of the incident is known or determinable. If so, the information is tracked in a centralized repository that can be accessed by IT groups involved in incident management. An attempt to fix the root cause can be made by leveraging known root cause information, technical expertise, and environment characteristics. Whether the exercise is successful or not, the detailed steps and fixes are stored in the incident and root cause tracking repository for linkage into the problem routing process. An essential element of the postmortem process is the link between the incident and root cause tracking repository, or knowledge base, and the problem routing process. Knowledge transfer must occur in order to influence and minimize overall incident response time, specifically the time involved in determining who actually should be responsible for the process management of an incident. routing requires the intelligence to rapidly query the repository for common symptoms, characteristics, repeated occurrences, and other factors. As a result, IT groups should strive for a collaborative approach to incident management. Educating front-end support 16 I N F O R M A T I O N S Y S T E M S S E C U R I T Y

9 FIGURE 6 Postmortem Inform Relevant Users Track for Future Research/ Resolution Execute Post Mortem Incident and Root Cause Tracking Repository/ Database Root Resolved Fix Root Cause Known Cause? Able to determine Root Cause? Post Mortem personnel in the routing, isolation, and restoration phases can speed up the entire process by reducing time gaps caused by lack of data points against which problem symptoms can be compared. Postmortem: Gap Analysis Key Points Is a formal postmortem process in place? Does the group meet on a regular schedule to review issues? Does the postmortem group meet immediately following a major incident? Is there a knowledge base system in which to enter postmortem results? Is it formal, electronic, and accessible to all who may need it? Or, is it embedded in the minds of certain key personnel, and thus subject to their availability and lost when they are gone from the organization? As new techniques for troubleshooting and problem resolution are learned are they entered into the knowledge base? Is the knowledge base readily accessible to everyone throughout the process? Are repeat problems approached with the thought that there may be a root cause generating the issue (e.g., if servers keep failing in a rack in the data center, the root cause may be faulty power to that rack)? Is the knowledgebase built such that trends can be determined using a database that allows reporting on the various fields? All information about a problem must have a place in the database to allow both trending and root-cause analysis through harmonization, aggregation, and decomposition processes. Is there an organizational focus on root cause analysis and resolution? Is closure reported to relevant users following problem resolution? Is there an effective means of user notification? Do tools effectively feed the postmortem and problem resolution process? SYSTEM RESILIENCE AND ITS EFFECT ON PROBLEM RESOLUTION Users measure performance by their own view of the availability of the system in question. High availability will result in good perception, and low availability in poor perception. That said, there are limits to the effectiveness of any incident management L A W, I N V E S T I G A T I O N S, A N D E T H I C S 17

10 Implementing resilience improvements places a greater burden on operational personnel and the tools they use to understand that a failure has occurred and to restore systems. process. matter the quality of the process, when things fail users will note it. To create a positive user perception, outages visible to the user community must be kept to a minimum. If applications and systems have resilience if an effective incident management process can restore them in minimal time users perception of the incident management process will be much higher than if they don t. This will be true even if failures occur. While normal operations proceed from the client viewpoint, in the background IT can restore the failed systems and bring the application back to a state of full resilience. When a system is designed to be highly available, there is the presumption that the extra time and money spent on it bring value to the provider and system users, specifically uptime in the face of failure. If, however, the system fails to be as available as expected, then the value invested was wasted. Two points should be remembered regarding resilient systems: 1. Element failure does not equal system failure. 2. Good system design does not equal good system implementation. If a resilient system is properly designed and built, single failures internal to the system, or full site failures, do not affect users in a dramatic way. System engineers and administrators can detect, isolate, and restore the system to full resilience without interfering with user functions. Testing must be performed to ensure that the desired resilience exists and has not diminished over time due to environmental changes or other causes. In addition, proper implementation and maintenance are critical to the perception of the incident response capability. If systems are considered to be warm standby, a failure equals user downtime. Murphy s Law tells us that if a failure occurs, it will be at the worst possible time with the greatest consequences, including lower confidence in the user community and loss of customers and revenue. Adding resilience should be considered when downtime is costly or generates poor user perception. Keep in mind that although resilience improves user perception, it also takes away one of the three key sources of problem detection, the user. Therefore, implementing resilience improvements places a greater burden on operational personnel and the tools they use to understand that a failure has occurred and to restore systems. ENHANCING THE INCIDENT MANAGEMENT PROCESS: AN EXAMPLE One of our clients had a number of perceptions about its incident management process. These perceptions included: The organization s staff comprised highquality people. Good tools were in place. The organization was aligned around its systems. However, the client also saw that: Outages were significantly longer than they should have been. Users were dissatisfied. Through analysis of the incident management process, the client realized that: The problem routing process tended to stall rather then escalate. Users were rarely informed of problem status, prompting excessive calls to the help desk and technical managers. Extended outages tended to be much longer than needed because of a failure to route problems in a timely manner and triage between problem types. Postmortem activities were not conducted on a regular basis. An organized and accessible knowledge base did not exist. Although there were islands of data and highly knowledgeable people that acted as the knowledge base, many data points were never captured as institutional knowledge. 18 I N F O R M A T I O N S Y S T E M S S E C U R I T Y W W W. I N F O S E C T O D A Y. C O M

11 FIGURE 7 Incident and Response Alignment Types Detection Isolation Resolution Post Mortem Trivial -1 rmal time to process trivial incidents Post Mortem n-trivial: Pre-Outage Indicators 15 min 15 min Isolation and Resolution Times Post Mortem within 1 day n-trivial: System Outage 15 min 15 min Isolation and Resolution Times Post Mortem within 1 day n-trivial: User Outage 15 min 15 min Isolation and Resolution Times Post Mortem within 1 day Enterprise Time to resolve enterprise incidents Same-Day Post Mortem Coordinator assumes responsibility, if problem not resolved Relevant Broadcast -1 Relevant Broadcast Many trivial problems may constitute an enterprise problem improvements recommended centered on: Creating a problem coordinator role to ensure the organization and its talents were applied to problems in an effective manner. Creating an intranet page to provide problem status to users. This vastly reduced repeat calls to the help desk and to managers and key personnel involved in problem resolution. In certain cases, improving application resilience to improve user perception of quality. Establishing a regular and emergency postmortem process. Creating a formal knowledge base populated with institutional knowledge and postmortem results and making it widely available. Emphasizing event coloration and root cause analysis. Instituting a formal escalation process based on whether problems are trivial, nontrivial, or enterprise. Figure 7 shows the formal problem coordinator role and the alignment of the incident process with each problem type. The result was an improved process that, when needed, involved the problem coordinator to focus the problem. This reduced large time gaps created when problem routing stalled. In one case, a problem was in the wrong group for two-and-a-half hours before finally getting to the right personnel. Once there, the problem was resolved in 45 minutes. The client also instituted a formal triage process to focus resources in times of stress. To facilitate communications between various groups and the problem coordinator, an instant messaging system was employed, which was already in use in the organization. One out-of-the-box problem detection issue noted was that large numbers of trivial incidents were not being correlated into a root cause that was an enterprise issue. For example, prior to process improvement, a large number of users failing to access a service would be viewed simply as minor incidents, perhaps a bad day with lots L A W, I N V E S T I G A T I O N S, A N D E T H I C S 19

12 Symptoms must be reviewed to achieve knowledge of root cause issues. of individual password issues. In reality, this was symptomatic of an application that had encountered a strange state of rejecting new log-ins, but allowing established users to maintain service. Once realized after an excessive amount of time the application log-in issue was able to be resolved. Symptoms must be reviewed to achieve knowledge of root cause issues. TOWARD AN EFFECTIVE INCIDENT MANAGEMENT PROCESS Many organizations recognize the need to improve their incident management process. Others are a major incident away from the same realization. Often, the complexity of the incident management process will mirror the complexity of the organization. In some cases analysis of an organization s network group, systems group, and security group will all be needed, with common touch points such as help desk issues and the postmortem process. Improvements should be taken on incrementally and absorbed into the organization, while maintaining a holistic view of the environment. Done right, analysis of the incident management process can deliver rapid return on investment in the form of improved coordination, reduced downtime, and improved user satisfaction. Finally, strong consideration should be given to enhancing application and system resilience. Because this can be a complex undertaking, focus on core applications where downtime equals loss of revenue. This will ensure that the results are worth the effort. Also consider enhancing data resilience. Being able to recover the maximum amount of data in the event of a failure, or maintain a complete data set mirrored in more than one location, can be key to maintaining both user satisfaction and revenue streams. System malfunctions and failures can be merely annoyances, or enterprise-shaking crises. By analyzing and understanding the effectiveness of their incident management process, organizations can better equip themselves to resolve problems quickly and prevent them from escalating and recurring. Deloitte Development LLC. Used by permission. The views presented in this journal are those of the authors and do not necessarily reflect the views of the publisher, the (ISC) 2, or of the journal s board of advisers. Information Systems Security (ISSN X) is published bi-monthly by Auerbach Publications, CRC Press LLC, 2000 N.W. Corporate Blvd., Boca Raton, FL Editorial offices: Auerbach Publications, 270 Madison Avenue, New York, NY Subscription rates: $175/year in the U.S., U.S. possessions, and Canada. For prices elsewhere, please inquire. Periodicals postage paid at Boca Raton and other mailing offices. Printed in U.S. Copyright 2004 CRC Press LLC. All rights, including translation into other languages, reserved by the publisher in the U.S., Great Britain, Mexico, and all countries participating in the International Copyright Convention and Pan American Copyright Convention. Product or corporate names may be trademarks or registered trademarks, and are only used for identification and explanation, without intent to infringe. This journal contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or the consequences of their use. part of this journal may be reproduced in any form by microfilm, xerography, or otherwise or incorporated in any information retrieval systems without the written permission of the copyright owner. Authorization to photocopy items for internal or personal use, or the personal or internal use of specific clients, may be granted by CRC Press LLC, provided that $20.00 per article photocopied is paid directly to Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA USA. The fee code for users of the Transactional Reporting Service is ISSN X/04/$20.00+$0.00. The fee is subject to change without notice. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. Postmaster: Send address changes to Information Systems Security, 2000 N.W. Corporate Blvd., Boca Raton, FL I N F O R M A T I O N S Y S T E M S S E C U R I T Y