Incident Response Plan

profilesepola
bd_ch_10_sect_02_03.html
Home>Computer Science homework help>Incident Response Plan

Incident Response Planning

The scenario at the beginning of this chapter depicts an incident and not a disaster, despite Joel’s declaration otherwise. By now, it should be clear why a technology manager, like Iris, must become involved in assessing the damage to two drenched accounting offices and the break room. Because the incident at RWW was determined by Iris to have caused minimal damage, a corresponding IR plan would have been activated if RWW had a properly developed IR plan. If the fire had spread beyond the break room, triggered the sprinkler systems throughout the building, and caused employee injuries, then an IR plan (even if RWW had one) would not have been adequate to deal with the situation. Instead, it would be necessary to initiate the DR plan and the BC plan, both of which are discussed later in this chapter. When one of the threats that were identified in Chapters 1 and 2 is made manifest in an actual adverse event, the adverse event is classified as an InfoSec incident, but only if it has all of the following characteristics:

  • It is directed against information assets.

  • It has a realistic chance of success.

  • It threatens the confidentiality, integrity, or availability of information resources and assets.

The prevention of threats and attacks has been intentionally omitted from this discussion because guarding against such possibilities is primarily the responsibility of the InfoSec department, which works with the rest of the organization to implement sound policy, effective risk controls, and ongoing training and awareness programs. It is important to understand that IR is a reactive measure, not a preventive one.

The responsibility for creating an organization’s IR plan usually falls to the CISO or an IT manager with security responsibilities. With the aid of other managers and systems administrators on the CP team, the CISO should select members from each community of interest to form an independent IR team, which executes the IR plan. The roles and responsibilities of the members of the IR team should be clearly documented and communicated throughout the organization. The IR plan also includes an alert roster, which lists certain critical agencies to be contacted during the course of an incident.

Using the multistep CP process discussed in the previous section as a model, the CP team can create the IR plan. According to NIST SP 800-61, Rev. 2, the IR plan should include the following elements:

  • Mission

  • Strategies and goals

  • Senior management approval

  • Organizational approach to incident response

  • How the incident response team will communicate with the rest of the organization and with other organizations

  • Metrics for measuring incident response capability and its effectiveness

  • Roadmap for maturing incident response capability

  • How the program fits into the overall organization*

    Cichonski, P., Millar, T., Grance, T., and Scarfone, K. “Special Publication 800-61, Rev. 2: Computer Security Incident Handling Guide.” Accessed 7/12/15 from http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.

During this planning process, the IR procedures , commonly referred to as standard operating procedures (SOPs), take shape. For every incident scenario, the CP team creates three sets of incident-handling procedures:

  1. During the Incident—The planners develop and document the procedures that must be performed during the incident. These procedures are grouped and assigned to individuals. Systems administrators’ tasks differ from managerial tasks, so members of the planning committee must draft a set of function-specific procedures.

  2. After the Incident—Once the procedures for handling an incident are drafted, the planners develop and document the procedures that must be performed immediately after the incident has ceased. Again, separate functional areas may develop different procedures.

  3. Before the Incident—The planners draft a third set of procedures, those tasks that must be performed to prepare for the incident. These procedures include details of the data backup schedules, disaster recovery preparation, training schedules, testing plans, copies of service agreements, and BC plans, if any. At this level, the BC plan could consist of just additional material on a service bureau that stores data off-site via electronic vaulting, with an agreement to provide office space and lease equipment as needed.

Figure 10-7 presents an example of pages from the IR plan that support each of these phases. Once these sets of procedures are clearly documented, the IR portion of the IR plan is assembled and the critical information outlined in these planning sections is recorded.

Figure 10-7. Example of IRP Incident-Handling Procedures Incident Response Planning

Planning for an incident and the responses to it requires a detailed understanding of the information systems and the threats they face. The BIA provides the data used to develop the IR plan. The IRP team seeks to develop a series of predefined responses that will guide the team and InfoSec staff through the IR steps. Predefining incident responses enables the organization to react to a detected incident quickly and effectively, without confusion or wasted time and effort.

The execution of the IR plan typically falls to the CSIRT. As noted previously, the CSIRT is a subset of the IR team and is composed of technical and managerial IT and InfoSec professionals prepared to diagnose and respond to an incident. In some organizations, the CSIRT may simply be a loose or informal association of IT and InfoSec staffers who would be called up if an attack was detected on the organization’s information assets. In other, more formal implementations, the CSIRT is a set of policies, procedures, technologies, people, and data put in place to prevent, detect, react to, and recover from an incident that could potentially damage the organization’s information. At some level, every member of an organization is a member of the CSIRT, since every action they take can cause or avert an incident.

The CSIRT should be available for contact by anyone who discovers or suspects that an incident involving the organization has occurred. One or more team members, depending on the magnitude of the incident and availability of personnel, then handle the incident. The incident handlers analyze the incident data, determine the impact of the incident, and act appropriately to limit the damage to the organization and restore normal services. Although the CSIRT may have only a few members, the team’s success depends on the participation and cooperation of individuals throughout the organization.

The CSIRT consists of professionals who are capable of handling the information systems and functional areas affected by an incident. For example, imagine a firefighting team responding to an emergency call. Rather than responding to the fire as individuals, every member of the team has a specific role to perform, so that the team acts as a unified body that assesses the situation, determines the appropriate response, and coordinates the response. Similarly, each member of the IR team must know his or her specific role, work in concert with other team members, and execute the objectives of the IR plan.

Incident response actions can be organized into three basic phases:

  • Detection—Recognition that an incident is under way

  • Reaction—Responding to the incident in a predetermined fashion to contain and mitigate its potential damage

  • Recovery—Returning all systems and data to their state before the incident

Table 10-2 shows the incident handling checklist from NIST SP 800-61, Rev 2.

Table 10-2. Incident Handling Checklist from NIST SP 800-61, Rev. 2

  Action Completed
  Detection and Analysis  
1. Determine whether an incident has occurred  
1.1 Analyze the precursors and indicators  
1.2 Look for correlating information  
1.3 Perform research (e.g., search engines, knowledge base)  
1.4 As soon as the handler believes an incident has occurred, begin documenting the investigation and gathering evidence  
2. Prioritize handling the incident based on the relevant factors (functional impact, information impact, recoverability effort, etc.)  
3. Report the incident to the appropriate internal personnel and external organizations  
  Containment, Eradication, and Recovery  
4. Acquire, preserve, secure, and document evidence  
5. Contain the incident  
6. Eradicate the incident  
6.1 Identify and mitigate all vulnerabilities that were exploited  
6.2 Remove malware, inappropriate materials, and other components  
6.3 If more affected hosts are discovered (e.g., new malware infections), repeat the Detection and Analysis steps (1.1, 1.2) to identify all other affected hosts, then contain (5) and eradicate (6) the incident for them  
7. Recover from the incident  
7.1 Return affected systems to an operationally ready state  
7.2 Confirm that the affected systems are functioning normally  
7.3 If necessary, implement additional monitoring to look for future related activity  
  Post-Incident Activity  
8. Create a follow-up report  
9. Hold a lessons learned meeting (mandatory for major incidents, optional otherwise)*  

While not explicitly noted in the NIST document, most organizations will document the findings from this activity and use it to update relevant plans, policies, and procedures.

Source: NIST SP 800-61, Rev. 2.

Data Protection in Preparation for Incidents

An organization has several options for protecting its information and getting operations up and running quickly after an incident:

  • Traditional Data Backups—The organization can use a combination of on-site and off-site tape-drive or hard-drive backup methods, in a variety of rotation schemes; because the backup point is some time in the past, recent data is potentially lost. Most common data backup schemes involve random array of independent disks (RAID) or disk-to-disk-to-tape methods.

  • Electronic Vaulting—The organization can employ bulk batch-transfer of data to an off-site facility; transfer is usually conducted via leased lines or secure Internet connections. The receiving server archives the data as it is received. Some DR companies specialize in electronic vaulting A backup method that uses bulk batch transfer of data to an off-site facility; this transfer is usually conducted via leased lines or secure Internet connections. Incident response procedures (IR procedures) Detailed, step-by-step methods of preparing, detecting, reacting to, and recovering from an incident. services.

  • Remote Journaling—The organization can transfer live transactions to an off-site facility; remote journaling The backup of data to an off-site facility in close to real time based on transactions as they occur. differs from electronic vaulting in two ways:

    • (1)

      Only transactions are transferred, not archived data; and

    • (2)

      the transfer takes place online and in much closer to real time.

    While electronic vaulting is akin to a traditional backup, with a dump of data to the off-site storage, remote journaling involves online activities on a systems level, much like server fault tolerance, where data is written to two locations simultaneously.

  • Database Shadowing—The organization can store duplicate online transaction data, along with duplicate databases, at the remote site on a redundant server; database shadowing A backup strategy to store duplicate online transaction data along with duplicate databases at the remote site on a redundant server. This server combines electronic vaulting with remote journaling by writing multiple copies of the database simultaneously to two locations. combines electronic vaulting with remote journaling by writing multiple copies of the database simultaneously to two separate locations.

Industry recommendations for data backups include the “3-2-1 rule,” which encourages maintaining three copies of important data (the original and two backup copies) on at least two different media (like hard drives and tape backups), with at least one copy stored off-site.

Listen webReader by ReadSpeaker Open/close toolbar