disaster recovery business continuity n.
Skip this Video
Loading SlideShow in 5 Seconds..
Disaster Recovery & Business Continuity PowerPoint Presentation
Download Presentation
Disaster Recovery & Business Continuity

Disaster Recovery & Business Continuity

243 Views Download Presentation
Download Presentation

Disaster Recovery & Business Continuity

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Disaster Recovery & Business Continuity Slides based on Whitman, M. and Mattord, H., Principles of Information Security; Thomson Course Technology 2003

  2. Learning Objectives Upon completion of this lesson the student should be able to: • Describe what contingency planning is and how incident response planning, disaster recovery planning, and business continuity plans are related to contingency planning. • Discuss the elements that comprise a business impact analysis and the information that is collected for the attack profile. • Recognize the components of an incident response plan.

  3. Learning Objectives Upon completion of this lesson the student should be able to: • Explain the steps involved in incident reaction and incident recovery. • Define the disaster recovery plan and its parts. • Define the business continuity plan and its parts. • Discuss the reasons for and against involving law enforcement officials in incident responses and when may be required.

  4. Introduction - So far we have: • Identified the following the problems facing the organization • Assessed a value for the organization’s information assets • Analyzed the threats in the organization’s environment • Identified potential vulnerabilities • Assessed the risks associated with current levels of the organization’s exposure

  5. Introduction - So far we have: • Prepared solid business reasons to support the risk strategy the organization should adopt for each information asset • Begun to develop a security blueprint for future actions • Outlined information security architecture or the necessary policies and technologies to guide the organization’s next steps. • The next step is to examine the topic of contingency planning within the information security context

  6. Contingency Planning Design: blueprint for security Chapter 6 FIGURE 7-1 Contingency Planning and the SecSDLC Contingency Planning and the SecSDLC

  7. Continuity Strategy • Managers must provide strategic planning to assure continuous information systems availability ready to use when an attack occurs • Plans for events of this type are referred to in a number of ways: • Business Continuity Plans (BCPs) • Disaster Recovery Plans (DRPs) • Incident Response Plans (IRPs) • Contingency Plans • Large organizations may have many types of plans, small organizations may have one simple plan, but most have inadequate planning

  8. Contingency Planning • Contingency Planning (CP): • Incident Response Planning (IRP) • Disaster Recovery Planning (DRP) • Business Continuity Planning (BCP) • The primary functions of these three planning types: • IRP focuses on immediate response, but if the attack escalates or is disastrous the process changes to disaster recovery and BCP • DRP typically focuses on restoring systems after disasters occur, and as such is closely associated with BCP • BCP occurs concurrently with DRP when the damage is major or long term, requiring more than simple restoration of information and information resources

  9. Continuity Strategy • Primary functions of these three types of planning: • IRP: immediate response • If attack escalates or is disastrous, process changes to disaster recovery and BCP • DRP: restoring systems after disasters occur • Closely associated with BCP • BCP: occurs concurrently with DRP when damage is major or long term • For events requiring more than simple restoration of information and information resources

  10. Contingency Planning Team • Before any planning can begin, a team has to plan the effort and prepare the resulting documents • Champion - A high-level manager to support, promote, and endorse the findings of the project

  11. Contingency Planning Team • Project Manager - Leads the project and makes sure a sound project planning process is used, a complete and useful project plan is developed, and project resources are prudently managed • Team Members - Should be the managers or their representatives from the various communities of interest: Business, IT, and Information Security

  12. Contingency Planning Hierarchy Contingency Planning IncidentResponse Disaster Recovery BusinessContinuity FIGURE 7-2 Contingency Planning Hierarchy

  13. Contingency Planning Timeline Incident Response (IRP) Disaster Recovery Planning (DRP) Business Continuity (BCP) Attack Post Attack(hours) Post Attack(days) FIGURE 7-3 Contingency Planning Timeline

  14. Major Steps in Contingency Planning Business impact analysis (BIA) Incident responseplanning Disaster recoveryplanning Business continuityplanning Incident planning Plan for disaster recovery Establish Continuity strategy Identification of threats and attacks Business unit analysis Incident detection Crisis Management Plan for continuity of operations Scenarios of successful attacks Incident reaction Assessment of potential damages Recovery operations Continuity management Incident recovery Classification of subordinate plans FIGURE 7-4 Major Steps in Contingency Planning

  15. Business Impact Analysis • Begin with Business Impact Analysis (BIA) if the attack succeeds, what do we do then? • The CP team conducts the BIA in the following stages: • Threat attack identification • Business unit analysis • Attack success scenarios • Potential damage assessment • Subordinate plan classification

  16. Threat Attack Identification & Prioritization • Update threat list with latest developments and add the attack profile • The attack profile is the detailed description of activities during an attack • Must be developed for every serious threat the organization faces • Used to determine the extent of damage that could result to a business unit if the attack were successful

  17. Table 7-1 – Attack Profile TABLE 7-1 Attack Profile

  18. Business Unit Analysis • Second major task within BIA is analysis and prioritization of business functions within the organization • Identify functional areas of the organization and prioritize them as to which are most vital • Focus on a prioritized list of various functions the organization performs

  19. Attack Success Scenario Development • Next create a series of scenarios depicting the impact a successful attack from each threat could have on each prioritized functional area with: • details on the method of attack • the indicators of attack • the broad consequences • Attack success scenarios details are added to the attack profile including: • Best case • Worst case • Most likely alternate outcomes

  20. Potential Damage Assessment • From attack success scenarios developed, the BIA planning team must estimate costs of the best, worst, and most likely cases • Costs include actions of the response team • This final result is referred to as an attack scenario end case

  21. Subordinate Plan Classification • Once potential damage has been assessed, a subordinate plan must be developed or identified • Subordinate plans will take into account the identification of, reaction to, and recovery from each attack scenario • An attack scenario end case is categorized as disastrous or not • The qualifying difference is whether or not an organization is able to take effective action during the event to combat the effect of the attack

  22. Incident Response Planning • Incident response planning covers identification of, classification of, and response to an incident • An incident is an attack against an information asset that poses a clear threat to the confidentiality, integrity, or availability of information resources • Attacks are only classified as incidents if they have the following characteristics: • Are directed against information assets • Have a realistic chance of success • Could threaten the confidentiality, integrity, or availability of information resources • IR is more reactive than proactive, with the exception of the planning that must occur to prepare the IR teams to be ready to react to an incident

  23. Incident Planning • Pre-defined responses enable the organization to react quickly and effectively to the detected incident • Two assumptions for good IR: • 1) The organization has an IR team • 2) The organization can detect the incident • IR team consists of individuals needed to handle systems as the incident takes place

  24. Incident Planning • IR teams act to verify the threat, determine the appropriate response, and coordinate the actions necessary to deal with the situation • Military process of planned team responses can be used in an incident response • Planners must develop a set of documents guiding the actions of each involved individual reacting to and recovering from the incident • Plans must be properly organized and stored

  25. Incident Response Plan • Format and Content • Plan must be organized to support quick and easy access to required information • Accomplished through a number of measures • Simplest is to create a directory of possible incidents with tabbed sections for each incident • When someone needs to respond to an incident, they simply open the binder, flip to the appropriate section, and follow the clearly outlined procedures for an assigned role

  26. Incident Response Plan • Storage • Plan should be protected as sensitive information • On the other hand, the organization needs this information readily available • Testing • An untested plan is not a useful plan. The levels of testing strategies can vary: • Checklist • Structured walk-through • Simulation • Parallel • Full-interruption

  27. Incident Detection • The most common occurrence is a complaint about technology support, often delivered to the help desk • Possible detections: • intrusion detection systems, both host-based and network-based • virus detection software • systems administrators • end users • Only through careful training can the organization hope to quickly identify and classify an incident • Once an attack is properly identified, the organization can respond

  28. Possible indicators of incidents: Presence of unfamiliar files Unknown programs or processes Unusual consumption of computing resources Unusual system crashes Probable indicators of incidents: Activities at unexpected times Presence of new accounts Reported attacks Notification from IDS Definite indicators of incidents: Use of dormant accounts Changes to logs Presence of hacker tools Notifications by partner or peer Notification by hacker Predefined situations that signal an automatic incident: Loss of availability Loss of integrity Loss of confidentiality Violation of policy Violation of law Incident Indicators

  29. Incident or Disaster • When Does an Incident Become a Disaster? • The organization is unable to mitigate the impact of an incident during the incident • The level of damage or destruction is so severe the organization is unable to quickly recover • It is up to the organization to decide which incidents are to be classified as disasters and thus receive the appropriate level of response

  30. Incident Reaction • Incident reaction consists of actions that guide the organization to stop the incident, mitigate the impact of the incident, and provide information for the recovery from the incident • In reacting to the incident a number of actions must occur quickly including: • notification of key personnel • assignment of tasks • documentation of the incident

  31. Notification of Key Personnel • Most organizations maintain alert rosters for emergencies • Alert roster contains contact information for individuals to be notified in an incident • Two ways to activate an alert roster: • A sequential roster is activated as a contact person calls each and every person on the roster [safer & better] • A hierarchical roster is activated as the first person calls a few other people on the roster, who in turn call a few other people, and so on (commonly called a calling tree) [faster] • The alert message is a scripted description of the incident, just enough information so that everyone knows what part of the IRP to implement

  32. Incident Documentation • Documenting the event is important: • First, ensure that the event is recorded for the organization’s records • What happened • How it happened • What actions were take • Record who, what, when, where, why, & how • Second, be able to prove, should it ever be questioned, that the organization did everything possible to prevent the spread of the incident • Finally, a good incident record can be used as a simulation in future training sessions

  33. Incident Containment Strategies • Before an incident can be contained, the affected areas of the information and information systems must be determined • The organization can stop the incident and attempt to recover control through a number of strategies including: • severing the affected circuits • disabling accounts • reconfiguring a firewall • ultimate containment option (reserved for only the most drastic of scenarios) involves a full stop of all computers and network devices in the organization

  34. Incident Recovery • Once the incident has been contained, and control of the systems regained, the next stage is recovery • First task: identify human resources needed and launch them into action • Full extent of damage must be assessed • The organization repairs vulnerabilities, addresses any shortcomings in safeguards, and restores data and services of the systems

  35. Damage Assessment • Incident damage assessment is immediate determination of the scope of the breach of CIA of information and assets after an incident • Sources of information include: • system logs • intrusion detection logs • configuration logs and documents • documentation from the incident response • results of a detailed assessment of systems and data storage

  36. Computer Forensics • Related to incident damage assessment is the field of computer forensics • This is the process of collecting, analyzing, and preserving computer-related evidence • Evidence may prove action or intent • Computer evidence must be carefully collected, documented, and maintained to be acceptable in formal proceedings • Individuals assessing damage need special training

  37. Recovery In the recovery process: • Identify vulnerabilities that allowed the incident to occur and spread and resolve them • Address safeguards that failed to stop or limit the incident, or were missing from the system in the first place • Install, replace or upgrade them • Evaluate monitoring capabilities • Improve their detection and reporting methods, or simply install new monitoring capabilities • Restore data from backups • Restore services and processes in use • Continuously monitor the system • Restore confidence of the members of the organization’s communities of interest • Conduct an after-action review

  38. Automated Response • New systems can respond to incidents autonomously • Trap and trace uses a combination of resources to detect intrusion then trace back to source • Trapping may involve honeypots or honeynets • Enticement is the process of attracting attention to a system by placing tantalizing bits of information in key locations • Entrapment is luring an individual into committing a crime to get a conviction • Enticement is legal and ethical, while entrapment is not

  39. Disaster Recovery Planning • Disaster recovery planning (DRP) is planning the preparation for and recovery from a disaster • The contingency planning team must decide which actions constitute disasters and which constitute incidents • When situations are classified as disasters plans change as to how to respond may occur - take action to secure the most valuable assets to preserve value for the longer term even at the risk of more disruption • DRP strives to reestablish operations at the ‘primary’ site

  40. DRP Steps • Clearly establish priorities • Clearly delegate roles and responsibilities • Initiate the alert roster and notify key personnel • Task someone with documentation of the disaster • If (and only if) it is possible, make some attempts to mitigate impact of the disaster on the operations of the organization

  41. Crisis Management • Crisis management is actions taken during and after a disaster focusing on the people involved and addressing the viability of the business • The crisis management team is responsible for managing the event from an enterprise perspective and covers: • Supporting personnel and families during the crisis • Determining impact on normal business operations and, if necessary, making a disaster declaration • Keeping the public informed • Communicating with major customers, suppliers, partners, regulatory agencies, industry organizations, the media, and other interested parties

  42. Disaster Recovery Planning • Establish a command center to support communications • Include individuals from all functional areas of the organization to facilitate communications and cooperation • Some key areas of crisis management include: • Verifying personnel head count • Checking the alert roster • Checking emergency information cards

  43. DRP Structure • Similar to the IRP, DRP is organized by disaster, and provides procedures to execute during and after a disaster • Provides details on the roles and responsibilities for those involved in the effort, and identifies the personnel and agencies that must be notified • Just as the IRP must be tested, so must the DRP, using the same testing mechanisms • Each organization must examine its scenarios, developed during the initial contingency planning, to determine how to respond to the various disasters

  44. Business Continuity Planning • Business continuity planning outlines reestablishment of critical business operations during a disaster that impacts operations • If a disaster has rendered the business unusable for continued operations, there must be a plan to allow the business to continue to function

  45. Developing Continuity Programs (BCPs) • A business continuity program, as documented in the BCP, is a function of contingency planning • Once incident response plans and disaster recovery plans are in place, the organization needs to address the possibility of finding temporary facilities to support the continued viability of the business • BCP consists primarily of selecting a continuity strategy and integrating off-site data storage and recovery functions

  46. Developing Continuity Programs (BCPs) • First part of the BCP is performed when joint DRP/BCP plan is developed • Cornerstone of BCP is identification of critical business functions & resources needed to support them • Contingency planning team needs to appoint a team to evaluate/compare various alternatives available and recommend which strategy should be selected and implemented • Strategy selected usually involves an off-site facility, which should be inspected, configured, secured and tested on a periodic basis

  47. Continuity Strategies • There are a number of strategies for planning for business continuity • Determining factor in selection between these options is usually cost • In general, three exclusive options exist: • hot sites • warm sites • cold sites • And three shared functions: • timeshare • service bureaus • mutual agreements

  48. Off-Site Disaster Data Storage • To get these types of sites up and running quickly, the organization must have the ability to port data into the new site’s systems • These include: • Electronic vaulting - bulk batch-transfer of data to an off-site facility • Remote Journaling - transfer of live transactions to an off-site facility; only transactions are transferred not archived data; transfer is real-time • Database shadowing - Not only processing duplicate real-time data storage, but also duplicates databases at the remote site to multiple servers

  49. Model for IR/DR/BC Plan • The single document set approach supports concise planning and encourages smaller organizations to develop, test, and use IR/DR plans • The model presented is based on analyses of disaster recovery and incident response plans of dozens of organizations

  50. The Planning Document • Establish responsibility for managing the document, typically the security administrator • Appoint a secretary to document the activities and results of the planning session(s) • Independent incident response and disaster recovery teams are formed, with a common planning committee • Outline the roles and responsibilities for each team member • Develop the alert roster and lists of critical agencies • Identify and prioritize threats to the organization’s information and information systems