Hendon Publishing - Article Archive Details
Contingency planning for IT security ‘disasters’ means a different kind of preparedness
Written by Jeremy L. Smith
Public safety agencies are the tip of the spear when it comes to crime stopping, emergency response or disaster management. Whether it’s an overturned car or a hurricane, public safety agencies are always there to help and assist. To ensure they can always meet the high demands placed on them by their communities, many agencies created contingency plans. In many cases, this may be part of a National Incident Management Systems (NIMS) program. However, this plan likely addresses only physical calamities like hurricanes, tornadoes or terrorist activities.
Major natural disasters like Hurricane Katrina, the San Diego wildfires, earthquakes and tornadoes or terrorist attacks like 9/11 have received much publicity over the past few years. Accordingly, the Federal Emergency Management Agency (FEMA) has released a good deal of guidance and money in the form of grants to help organizations deal with these types of disasters.
But what happens to agencies when they are hit by a crippling computer virus or brought to their knees by a hacker who’s been able to take a critical system down (like the computer-aided dispatch or 9-1-1 system)? What will they do then? How will they respond to this “electronic disaster?” Few agencies have detailed plans on how to address a major information technology disaster like a denial of service attack, or hacking attempt, virus outbreak, theft of electronic data and more.
Over the years, public safety agencies increasingly rely on information technology (IT) systems. The features and capabilities IT systems provide allow for enhanced service to the communities they serve. The dependence on IT to support mission-critical operations has never been higher. The threat of IT security disasters looms large for public safety agencies now dependent on IT systems for day-to-day operations.
In today’s interconnected and technologically dependant world, public safety agencies must ensure that their contingency plans address IT security disasters.
Public safety agencies will learn how and what to include in their contingency plans to ensure they can proactively plan for IT security disasters and continue to maintain high levels of availability for their communities.
R.D. Porter, the 9-1-1 coordinator for the state of Missouri Office of Administration and key member of the National Emergency Number Association’s Security for Next Generation 911 working group, offers the following on IT disaster planning and its role in public safety: “IT disaster planning is something still very new in a majority of public safety answering point (PSAP) environments. Most PSAPs are still thought of in a very traditional mode of answering the telephone and operating a radio to dispatch emergency responders. As these traditional technologies migrate to a more integrated system of ‘communications’ dependent upon each facet of digital or electronic emergency response, a new look at how disaster planning is done comes to the forefront. There are additional disasters that must be considered such as computer viruses, system hacks, loss of data, just to mention a few of the hazards that should be addressed in the new PSAP planning.”
Here are some important definitions relating to contingency planning.
• IT Security Disaster: For the purposes of this article, an IT security disaster is defined as any significant event that affects the availability and use of an IT system. Examples of IT security disasters—with severity obviously varying/include virus outbreak, hacking, denial of service attack, component failure (i.e. computer’s hard drive fails), and accidental or malicious misuse of systems.
• IT Contingency Planning: The NIST SP800-34 notes that IT contingency planning is: “…a coordinated strategy involving plans, procedures, and technical measures that enable the recovery of IT systems, operations, and data after a disruption. Contingency planning generally includes one or more of the approaches to restore disrupted IT services: restoring IT operations at an alternate location; recovering IT operations using alternate equipment; [and] performing some or all of the affected business processes using non-IT (manual) means (typically acceptable for only short-term disruptions).”
• Business Continuity Plan (BCP): The NIST SP800-34 tells us: “The BCP focuses on sustaining an organization’s business functions during and after a disruption. An example of a business function may be an organization’s payroll process or consumer information process. A BCP may be written for a specific business process or may address all key business processes. IT systems are considered in the BCP in terms of their support to the business processes. In some cases, the BCP may not address long-term recovery of processes and return to normal operations, solely covering interim business continuity requirements. A disaster recovery plan, business resumption plan, and occupant emergency plan may be appended to the BCP. Responsibilities and priorities set in the BCP should be coordinated with those in the continuity of operations plan (COOP) to eliminate possible conflicts.”
• Disaster Recovery Plan (DRP): The NIST SP800-34 offers this definition of a DRP: “As suggested by its name, the DRP applies to major, usually catastrophic, events that deny access to the normal facility for an extended period. Frequently, DRP refers to an IT-focused plan designed to restore operability of the target system, application, or computer facility at an alternate site after an emergency. The DRP scope may overlap that of an IT contingency plan; however, the DRP is narrower in scope and does not address minor disruptions that do not require relocation. Dependent on the organization’s needs, several DRPs may be appended to the BCP.
Although the NIST definition of a DRP refers to “major catastrophic events that deny access to the facility for an extended period of time, usually resulting in relocation,” we are going to include IT security disasters that do not require relocation in our discussion on DRPs. More complex organizations may implement additional complementary plans like a business recovery plan, continuity of operations plan or incident response plan.
Implementing Contingency Planning
Contingency planning is about risk management. It involves identifying, understanding, quantifying and mitigating the risks to your IT systems. Contingency plans are the result of properly conducted risk management and enable you to effectively prepare for different kinds of risks. Readers are strongly encouraged to get familiar with risk management from an IT perspective. As noted earlier, we are using the NIST SP800-34 as a guide in our discussion on contingency planning. The SP800-34 offers a seven-step plan for contingency planning:
1. Develop the contingency planning policy statement
2. Conduct the business impact analysis (BIA)
3. Identify preventive controls
4. Develop recovery strategies
5. Develop an IT contingency plan
6. Plan testing, training, and exercises
7. Plan maintenance
Contingency Planning Policy Statement
Step one of any major project is always getting managerial buy-in. This is no different for contingency planning in the public safety agency. Whether it’s the sheriff, police chief, city manager, or fire chief, the highest levels of management within the agency must recognize their responsibility to ensure the availability of critical systems is carried out. This starts with a formal declaration—on paper, usually in the form of a policy—of the importance of contingency planning. This statement is the formal authority and support of the contingency planning effort and is critical. It also identifies roles and responsibilities as well as the scope of the effort. An organization whose senior leadership fails to take their responsibility seriously will place in peril the success of any contingency planning effort.
Business Impact Analysis
As we noted earlier, contingency planning is all about managing risk. In order to manage risk, one has to understand certain aspects about the “business.” In this case, the business is the public safety agency and refers to the technological systems used to complete the operational mission of the agency. This is probably the most important phase of the process—aside from actually implementing your plan. Here the organization must:
• Identify each IT system used;
• Correlate the IT system to operational mission it supports;
• Identify inter-dependencies (if applicable);
• Quantify / qualify the measure of importance the IT system has to the agency—including what is impacted if the system is unavailable;
• Identify the acceptable outage levels / times for each IT system;
• Determine risks and threats to each system;
• Measure (quantify) the likelihood of the risk / threat occurring;
• And document the results.
At the end of this phase, the agency should have a crystal clear understanding of what IT systems are of the greatest importance to the agency, what will happen if the IT systems is lost, and what threats the systems face—including how likely each risk is to occur.
With this information, the agency now has the ability to make informed decisions about the steps it needs to take to reduce the risk of downtime and increase the availability of IT systems.
Identify Preventive Controls
Armed with the results of the BIA, a public safety agency now can begin to select important “controls” that will be used to reduce the risks identified. Examples of controls include items like firewalls, uninterruptible power supplies, anti-virus software, backup software, and a physical backup location to activate if necessary.
The advantage that a successful BIA gives an agency is the ability to discern which IT system requires the most attention when implementing controls. This has a direct effect on how much money you will need to spend and what types of solutions you will need to implement to properly protect the IT system. Some systems may be deemed less important and may require far less time, resources and money spent on securing it, while others may require just the opposite.
Develop Recovery Strategies
In this phase, the agency begins to identify how it plans to recover from a failure caused by an IT security disaster. For example, if a virus outbreak occurs that completely wipes out the 9-1-1 center’s computers, how will the agency deal with both the short-term and long-term recovery?
Strategies may include solutions like hot / cold sites—completely separate locations that can be activated (or may already be activated) and ready to absorb the workload of the affected system or location. Simpler strategies might involve how to restore backups, replace equipment, and so on.
Develop an IT Contingency Plan
Finally, in this phase, we formally document are previously identified contingency strategies in the form of business continuity plans or disaster recovery plans. Checklists, new documentation, roles, team members, etc. are identified and documented.
As previously noted, a business continuity plan is focused on sustaining an agency’s operation, while the disaster recovery plan deals with how to recover once the disaster is over. They are both integral parts of the contingency planning process.
Testing, Training and Exercises
Contingency plans can be complex. Many decisions face organizations such as how and when to trigger them, who does what and where, and what to do if it doesn’t work. You never want to find out your plan was poorly put together during a crisis. Instead, conduct training classes and exercise to ensure your plan is effective. Make sure important players understand what their roles are. Don’t be afraid to simulate an IT disaster or perform testing to validate your plan’s effectiveness. Anything you can learn in a non-stress situation will be invaluable to you when the real thing happens.
Nothing is ever static when dealing with IT security. Organizations will need to re-evaluate their contingency plans on a regular (preferably scheduled) basis to ensure that it is consistent with the risk the organization is facing.
Contingency planning for IT security “disasters” is an important and necessary component for today’s public safety agency. In today’s interconnected and technologically dependant world, public safety agencies must ensure that their contingency plans address information technology security disasters.
For larger agencies, making these plans may be easier than for small or midsize agencies where creating or updating contingency plans may be beyond the scope and budget of internal resources. However, just because an agency is small doesn’t mean it can ignore these concerns. In fact, a smaller agency might actually experience more “pain” from an IT disaster than a larger agency, simply based on the size and scope of impact. It may be necessary for smaller agencies to turn to outside assistance for consultative help.
Jeremy Smith is an IT security engineer and evangelist. As the co-chairman of the NENA Next-Generation 9-1-1 (NG9-1-1) Security Working Group, he is charged with helping define the IT security standards for 9-1-1. He holds a master’s degree in information systems management with and emphasis on IT security, is a certified information systems security professional (CISSP) and is a former Marine.
Editor’s note: The National Institute for Standards and Technology (NIST) Special Publication 800-34, Contingency Planning Guide for Information Technology (IT) System (NIST SP800-34) was used as a guide for this article as it provides a commonly accepted methodology for contingency planning.
Published in Public Safety IT, Nov/Dec 2008
Rating : Not Yet Rated
Related ProductsIT Security