MODULE 39
Incident Response
Most organizations can’t afford to wonder if an incident will ever happen to them; they should really be wondering when, because negative events or incidents are going to happen to every organization at some point. Incident response is definitely not something that a business can simply “deal with when it comes”; an incident response program requires careful planning in advance. In this module, we’re going to discuss the basics of incident response, including planning, preparing, and executing a solid response. We’ll also discuss mitigation and recovery from incidents, and how to minimize the damage from a negative event by separating affected systems from the rest.
Incident Response Concepts
Several critical concepts are involved with setting up and executing an incident response plan. Some of these involve planning and management functions, such as developing policy, allocating resources, staffing an incident response team, using exercises and drills, and making sure that everyone is trained regarding their responsibilities. Beyond that is putting the plan into motion and executing it when the incident occurs.
An incident could be defined as a negative event that adversely affects the organization, its data and systems, its people, and its overall ability to perform mission or business functions. An incident could be a malicious hacking attack from the outside, it could be an insider threat when someone steals proprietary data and sells it to a competitor, or it could be a natural disaster such as a fire or flood. The focus of this module applies to incidents in general; a more detailed discussion about business continuity and disaster recovery will come later in Modules 41 and 42.
Risk Mitigation Strategies
This module, and those that follow it, emphasizes what you have learned so far about risk management principles. You learned that risk management involves balancing cost and resources applied against mitigation or reduction strategies to reduce threats to vulnerabilities and how they might impact an organization’s data and systems. Incident management and response supports your risk management program by ensuring that the organization is prepared and able to address an incident quickly when it occurs, reducing the damage to your organization and systems. By having an active incident response program, you can control, investigate, and conclude a damaging event more quickly. This reduces risk and enables the organization better to deal with a variety of threats.
Incident Management
An incident response can seem like madness, but there’s actually a method to that madness that you should pay attention to. The National Institute of Standards and Technology (NIST) has provided a very good incident response methodology in its Special Publication (SP) 800-61, rev. 2, Computer Security Incident Handling Guide, that you can use in your organization. It covers the key areas of incident response, including preparation, detection and analysis, containment, and so on. The incident response life cycle that NIST offers is illustrated in Figure 39-1. We’ll discuss much of this methodology in this module.
Figure 39-1 NIST’s incident response life cycle (from NIST SP 800-61, rev. 2)
Incident management is really about having all the proper management buy-in, policies, and commitment of resources to the incident response program. This starts at the top of the organization, when senior managers and executives set the incident management response policy. The policy should direct the establishment of an incident response program, to include building an incident response team, establishing response time frames, defining different levels of incidents, and so on. The policy should also include the appointment of someone who has the overall responsibility for the program.
Once policy is established, incident response procedures can be developed, the team can be staffed and trained, equipment can be purchased, and the business can prepare for the inevitable negative events that will eventually occur. The incident response plan, which is more detailed than the policy itself, will outline the procedures involved with responding to the different types of incidents. The plan should contain information about the different levels and types of incidents, how to respond to them, who will be called, when an incident will be elevated to additional levels of management, and the general chain of events that must happen in order for the incident to be contained.
All of the incident response policy and planning documentation should be reviewed on a periodic basis to ensure that it remains current and considers any new changes to the operating or business environment. Many organizations review this documentation at least annually; in businesses where the operational environment and other factors frequently change, this review should probably occur more often. Incident response plans should also be exercised occasionally to make sure that those folks who have responsibilities and duties related to a response are familiar with what they have to do. Testing these plans can also help to ensure that all the right equipment is in place and that all the response processes work the way they should. Many of these items will be covered in the following sections.
Incident Response Procedures
All the planning that you’ll do when getting your incident response plan in shape really focuses around procedures that will be followed when an incident actually happens. A good set of well-written procedures will help the response go like clockwork; conversely, poor or nonexistent procedures will have everyone running around with their hair on fire wondering what to do and wasting valuable time. Procedures can be written to a very detailed degree or very broadly, depending upon the activities that have to occur when a response is initiated.
The plan should also be written by the same people who will have to do the job during the actual response. For example, if the incident response plan dictates that a server be restored from a backup in case of a hacking attack, the people who will actually have to perform that task during an emergency should be involved in writing those procedures, to ensure that they can perform those tasks and that the procedures are accurate. In any case, the organization should make sure that these procedures are well circulated to the right people and reviewed for accuracy and completeness. In the next few sections, we’ll discuss procedures developed and used during preparation, as well as when the incident response plan is actually executed.
Preparation
Preparation is one most critical parts of incident response, because you must make sure all the right equipment is in place, all the right people are assigned to critical positions, and all those people are trained on what to do, before the incident occurs. You also have a good checklist of procedures that the team can use to respond quickly to and contain an incident. Good preparation also includes having a solid incident response plan that has been tested to make sure that an actual response flows as it should.
Staffing
Staffing the incident response team with qualified people is critical; if, during an incident, people don’t have the training or the experience required to carry out the response, it will probably not go very well. Consider staffing the team with people who have experience in several different areas. Of course, you’ll want technical people who have experience in networking, server administration, security, and so on. It helps if these people have worked in different areas during their careers so they can perform multiple tasks. You also need people who have expertise in areas such as incident response, business continuity, forensics, and disaster recovery, since your incidents may span different types of events and levels of response.
Outside of the technical team, the business may choose to include representatives from a variety of areas within the organization, including HR, accounting, public relations, and so on. Management personnel will also need to be on the team, to be in charge of coordinating the entire response. The same people who are responsible for planning the incident response strategy and providing input to the policy and procedures are likely going to be some of the same people who actually respond to an incident. It makes for a more effective response if this is the case, since those responders have the experience in developing the incident response program from the beginning and will be intimately familiar with how it is set up and how it should be executed.
In addition, these people will have to be trained on all of their incident response tasks and responsibilities. Although some of these responsibilities may mirror their daily job activities, some of their response tasks may be outside of their daily routines. One other aspect of staffing your incident response team is that some of your team members, in the event of an actual incident, may come from outside of the organization and could include members of law enforcement, your Internet service provider, software and equipment vendors, and so on. You’ll have to plan carefully how and when to integrate these outside participants into your team.
Developing a Response Strategy
A response strategy dictates how the organization will respond to different incidents. Some incidents, such as hacking attacks, require a particular level of response and possibly a unique response team. The sequence of response for particular incidents may also differ from those for other types of incidents, and the level of seriousness of an incident will factor into the response strategy. For example, if a piece of malware infects a single PC, it may be considered less serious and more easily contained than a worm that infects the entire network, so the level of response may be different.
The business’s response strategy takes all of this into account. The strategy should define the various types of events that can occur, their levels of impact, and the measured responses that should be taken when they occur. The strategy should also indicate which roles and responsibilities are needed for each type of incident, and which skill sets will be needed for the incident team members. If all of this sounds a lot like the risk assessment and analysis processes, it’s because incident response, like many of the other things we will talk about over the next few modules, is most definitely part of the overall risk management strategy for the organization. Your incident response strategy can be defined as part of the policy document, or as a separate attachment that goes into more detail regarding how the organization will respond to the various incidents that will occur.
Putting It All Together
Once you have put together an incident response policy, staffed the team, and developed a strategy for responding to incidents, your organization must, of course, commit resources (time, money, equipment, facilities, and so on) to the program. This includes time for training the incident response team members as well as exercising the incident response plan. You’ll need to acquire the appropriate equipment and supplies for the response, such as computers, forensics imagers, software, and so on. The organization should also set aside a workspace within the facility where the team can meet, organize, and manage the response. This can be a dedicated workspace or a space where they would normally work in the data center or on the operations floor. Either way, provisions need to be made such that in the event of an incident, priority is given to the incident response team so that they can deal with the issue quickly and efficiently.
Exercising the incident response plan using various scenarios and methods is important to make sure the team members understands their responsibilities and how to perform the tasks they are given during the response effort. We’ll talk more about the different methods of exercising response plans in Modules 41 and 42, but for now you should know that this exercise is a necessary evil you should plan to do at least annually, and possibly more often, and it should be documented, for both recordkeeping purposes as well as for continuous process improvement.
Executing an Incident Response
If you’ve ever been a bystander or an observer when an incident has occurred in an organization, you’ve probably seen a wide range of reactions when the event kicks off. In a well-organized incident response, people quickly and efficiently perform their tasks without panicking, but with a sense of urgency. They have all the equipment and supplies needed to do their jobs, and the incident response process flows smoothly. At the other extreme, people run around with their hair on fire, wondering what to do, and not having a clear sense of direction. The may have to look for equipment to execute the response and may wind up taking production equipment offline to respond to an incident in another area of the business. Usually, however, an organization’s response falls somewhere in the middle of the spectrum. Preparation is important; it gives the organization a greater potential for success during an incident response.
Most of what we’ve discussed up to this point involves the preparation phase of the NIST incident response life cycle. Executing your incident response involves the next two phases of that same life cycle: detection and analysis, as well as containment, eradication, and recovery. Detection involves understanding your infrastructure and environment and being able to discover indications that an incident has occurred. You can detect an incident in different ways, such as through automated intrusion detection systems, antivirus software, and logging alerts. Other incidents may be detected only through manual audits of different events, logs, and procedures.
Incident analysis involves looking at all the potential incidents that you discover to determine which are actual incidents and which are false positives. That in itself can be a full-time job and may require dedicated staff. Because the business is constantly generating computer and network logs and other data, it can be a challenge to stay ahead of the curve and examine the most recent data to determine whether the organization has suffered a negative incident such as a hacking attack. Some incidents are easy to detect, such as a serious malware attack, a web defacement, or denial-of-service attack. Other incidents won’t be so easy to see and may actually occur over long periods of time instead of during a particular workday or in a short time span. Event analysis and correlation is the subject of a much broader conversation than included in this module, but you should understand that analysis is the first step in determining whether you’ve actually experienced an incident.
The goal of incident analysis is to determine exactly what has happened. This includes answering such questions as these: Who is the victim? Who is the perpetrator? What systems or data does the incident affect? Where did the incident occur (on one machine, for example, or from the external network)? When did it occur? Exactly how did it occur? How does it impact the business? Some of these questions can be answered only through an in-depth forensics analysis, which is the subject of the next module. Analysis should tell you exactly what’s happened and what you’re facing, so you can respond appropriately in the next phase of the life cycle, which is concerned with containing an incident.
The next phase (containment, eradication, and recovery, per NIST) involves stopping the incident, eradicating its effects, and recovering from the incident. For serious incidents, you can afford to spend only a short amount of time on analysis, and you may need to focus more on containing the incident to prevent further damage to the business and its infrastructure. During this phase, the incident response team is activated, and even if the cause of the incident and its details aren’t known at the time, the team works to contain it and stop the damage. If the incident is a network attack, for example, the team may need to take a drastic measure such as unplugging the organization from the Internet or shutting down certain services within the business. If it’s a malware attack, the team should focus on containing the malware to the smallest number of systems possible and preventing its spread. If data is being extracted from the network, then containing it would mean stopping that data from leaving the network by shutting down a system or blocking traffic at the perimeter of the network, for example. In any case, the incident response strategy and procedures should dictate exactly how the organization should go about containing the incident and eradicating its effects. Keep in mind that while this phase is going on, the organization should make every effort to preserve evidence of the incident for later analysis and action. This includes preserving log files, properly handling forensic evidence on systems, and so on. Preserving evidence is also a focus of Module 40.
Recovering from an incident involves getting the systems, data, and processes that depend on them back into operation. Depending on the nature of the incident, this may be easier said than done, since critical systems may be damaged or may need to be kept offline for the duration of the recovery, and these systems may be subject to evidence collection after an incident. Modules 41 and 42 go more into depth on recovery processes after a disaster or incident and are relevant to this discussion as well.
First Responder Procedures
First response is a critical phase of the incident response plan, simply because during the first few minutes or hours of an incident several things can happen that affect how well the organization is able to contain and recover from the event. First response is also critical in the preservation of evidence. We’ll discuss first responder procedures from a general perspective, as they apply to most incidents and negative events. The first responder’s overall duties should be to secure the scene (if necessary), determine the scope of the incident, try to determine the seriousness and impact of the incident, and start the notification process for the incident management and response team.
The first response may not be initially executed by members of the incident response team; an incident may be detected and responded to by the personnel or operators on duty at the time the incident occurs. If an incident is very serious, the response may not be able to wait until the response team is activated and called in. Because of this, all personnel should have some measure of training in responding to an incident, whether that training involves simply activating the team and notifying the appropriate personnel, or actually securing the scene, preserving evidence, stopping an attack, and so on. The level of response should allow the team to be notified and activated, and damage to the organization’s infrastructure can be immediately stopped or reduced. At the same time, however, the first responder should make every effort to preserve valuable evidence that will be needed to analyze the incident. For example, if a particular workstation is being attacked over the network, the first responder may need to unplug that workstation from the network, but keep it up and running so that information regarding network connections, running processes, and so on can be collected and analyzed. In some cases, it may even be desirable to allow the attack to continue so that data can be collected and used to identify the attacker and how they got into the network in the first place. Decisions regarding those actions should be discussed in advance, before the incident occurs, and certain criteria should be set forth by management that dictates if and when certain actions will be executed by first responder, based upon the seriousness of the event. It’s important that your procedures are detailed enough that these personnel who are less trained can execute the initial steps in an orderly fashion with a minimum of panic. Write down the procedures and make sure everyone knows where the procedures are located!
Incident Identification
A first response also involves trying to determine the scope of the event, identify what kind of event it is, and determine what systems it affects. The scope of an incident would include whether or not the incident is confined to one workstation, one group of users, or the entire network, for example. The impact of the incident may be difficult to determine at first, so this may be the initial best guess on the part of the first responder. However, it may be better to overestimate the impact to the organization than to underestimate it to prevent serious damage to the infrastructure. The incident response team may find that a questionnaire or checklist is valuable in helping a first responder quickly determine the scope and impact of the incident.
Escalation and Notification
The other key piece of the first responder’s actions is to notify management immediately so the incident response team can be activated and called in. The first responder should be prepared to provide as much information as possible to the incident response team lead so that this person can start the appropriate response measures as soon as he or she arrives. Documenting any actions taken along with any observations or events with regard to the incident are other tasks for the first responder.
Once the team has been notified, the first incident response lead on the scene should determine whether or not the incident should be escalated to upper management, or even outside the organization, such as to the organization’s Internet service provider or law enforcement. If outside expertise is required, the event may have to be escalated even further. The level of seriousness of the event, as well as the scope of the event, will determine how it’s escalated. For example, if an incident such as a hacking attack affects the organization and its internal network, but could also spread to the Internet, another organization, or an upstream provider, the incident should be escalated as quickly as possible. Once again, the organization’s incident management strategy and policy should dictate different levels of impact and how they are escalated based upon predetermined criteria.
Incident Isolation
The incident response team should also try to isolate the incident in impact and scope. For example, in the event of a malware attack, the team should try to isolate the workstations and servers that have been infected from the rest of the network to prevent the malware from spreading. In the event of a denial-of-service attack, the team could isolate the network segment under attack from the outside network, such as by quarantining the device or devices, removing it/them from the network, and even shutting it/them down completely.
Quarantining a device or system is designed to prevent an incident from spreading beyond that device or system to the rest of the infrastructure. It may mean unplugging the device from the network, or even dynamically switching it to an isolated network segment or virtual LAN. Reasons for quarantining a device include a malware attack, denial-of-service or other form of network attack, or even prohibited use by an insider. If a device is removed from the network, it may remain powered on so that valuable evidence can be collected from it, and then the device can be shut down and stored while the incident is being investigated. In any case, it should not be allowed back on the network until it has been sanitized and reimaged, to prevent recurrence of the attack or spread of any malicious software.
Data Breach
These days, a data breach is one of the most commonly occurring security incidents you’ll see plastered across the news. In reality, a data breach is the result of another security incident, whether it’s an attack by hackers, a careless or malicious insider, or even an accident involving faulty processes or procedures. Regardless of the cause, data breaches should be responded to above and beyond the security incident that caused them. An organization will naturally respond to a hacking attack or malicious insider with fairly routine response patterns that include intrusion detection systems, system hardening measures, and so on. The result of some of these incidents—the data breach itself—also has to be responded to in unique ways.
A data breach normally involves data of a sensitive or protected nature, and most often involves data belonging to or concerning an entity outside the organizational business. If the breach is confined only to organizationally owned proprietary or sensitive data, then the organization takes the hit for the loss alone, in the form of lost business, revenue, or just sheer embarrassment. If the breach encompasses data concerning individuals or organizations outside the business, it’s a much more serious issue and could involve not only loss of business revenue, but also legal sanctions and criminal punishment. Normally, the types of data involved in a serious breach include protected health data under the Health Information Portability and Accountability Act (HIPAA), personal financial information, and even personally identifiable information (PII) that could include names, dates of birth, addresses, Social Security numbers, and so on. A recent example of a breach that actually had multiple types of data was the Sony breach in late 2014. In addition to proprietary data (including actual movies), personal data regarding Sony employees was included in the breach. Along with potential fines and other liability issues, the company lost valuable intellectual property, as well as the confidence and goodwill of its stakeholders. In the long run, this may be more damaging than the sheer dollar value of the financial losses.
Your response to a data breach goes beyond the technical aspects of isolating network segments, removing malware, tightening down systems, and so on, although those technical measures are also included, of course. You may also have to respond to a data breach by informing the subjects of the data compromised, such as individuals or companies, as well as other entities, such as law enforcement. You may also have to inform regulatory organizations such as the US Office for Civil Rights, in the event of a protected health information breach, or the Securities and Exchange Commission if financial data has been lost. Law enforcement agencies, such as the Federal Bureau of Investigation and other appropriate entities, may require notification about a data breach. Both state and federal laws dictate how an organization must respond to a data breach, what steps they must take to prevent further damage, and even how they must compensate the victims. Obviously, all this will involve not only upper management and the incident response team, but the organization’s legal personnel and its public relations team, since the breach will likely be plastered all over the news. The organization should ensure that it has a both a technical and a management incident response strategy in place to deal with data breaches.
Damage and Loss Control
The damage from an incident is not always easy to determine. Damage includes technical damage to systems, such as malware infection, data loss, equipment damage or theft, and others. Damage can also include costs related to containment of an incident, as well as costs of eradicating the cause and repairing damage to the infrastructure. These costs might be incurred in terms of labor dollars for response personnel, as well as equipment and software needed not only to clean up the incident, but also to mitigate its effects and prevent it from occurring again.
Damage can also include the intangible aspects of an incident, such as damage to public and consumer confidence in the organization and reputation in the marketplace. If proprietary or sensitive data is lost, the damage could include loss of business and revenue and the inability to compete in the marketplace. Additional damage can come in the form of legal or criminal proceedings against the organization that may result in heavy fines, imprisonment, or even shutting down the business.
Controlling and minimizing the damage and loss from an incident involves taking all the proactive security measures we’ve discussed throughout this book up until this point. These include all of the administrative, technical, and operational measures used to secure an organization’s infrastructure and data. Securing people, systems, and equipment are all key to controlling and minimizing damage and loss.
Post-Response
How an organization deals with an incident after it has been discovered, analyzed, investigated, contained, and eradicated is just as important as a response process. The organization must figure out how to learn from the event and use what it has learned not only to prevent the incident from occurring again, but also to determine how to deal with such events more effectively in the future. The organization should develop a post-response strategy that includes collecting all the data regarding how the incident occurred, what steps could of been taken to prevent it, how effective the response was, and what could have been done better. All of this information can be used to prevent and mitigate future negative events.
Mitigation Steps
Some of the mitigation steps that an organization should take include a proactive look at the threats and vulnerabilities on the network. This goes back to risk assessment and analysis and may mean that the initial assessment was either incomplete or too narrow in scope. The post-response to an incident should cause the organization to go back and examine its risk management process. Once threats and vulnerabilities have been examined, the organization should essentially beef up its risk management program by taking additional measures toward preventing and mitigating the types of incidents it just experienced. Management should look at putting additional resources toward controls that would have prevented the incident in the first place, as well as improving its incident response detection and response capabilities. This may mean spending additional money for equipment and supplies and providing additional training for incident response team members. In any event, the organization should look for deficiencies in its risk management processes and day-to-day business operations that could have contributed to the incident and the level of response.
Lessons Learned
Part of responding to an incident involves taking the lessons learned to heart and using them toward preventing future incidents and responding to them in a more effective way. The organization should examine the circumstances leading up to the incident in detail, making note of deficiencies and how to correct them, as well as the response to the incident, to improve the incident detection, analysis, containment, and eradication processes. These lessons learned should be documented as part of the overall final incident report, and incorporated into the organization’s existing policies, processes, and procedures.
Reporting
There are several aspects of reporting during an incident response. During the response effort, you should report progress on the response and anything discovered about the nature of the incident to management, along with any outside agencies that require the information, such as law enforcement, for example. There should probably be at least a daily briefing for management (and law enforcement, if applicable) on the progress of the response, the damage to the infrastructure, and how the damage is being contained and eradicated.
After the response, you’ll probably be required to submit a final report that details the entire incident from start to finish, the different activities performed as part of the response, the root causes of the incident and how it could have been prevented, any damage to the business or infrastructure, and recommendations for future actions. The report may include a cost breakdown of labor, equipment, and any other supplies needed to respond adequately to the incident. It may also include any deficiencies that were noted during the response, particularly in personnel, training, or other resources. In addition to the report that goes to management, compliance requirements may necessitate that a report be submitted to law enforcement, a regulatory agency, or even to other outside entities (particularly in the case of a data breach). This report may include some the same information as the internal management report, as well as additional information that may be required for legal or compliance purposes. The organization should also make sure that anyone requiring copies of the incident response reports get them, but it should also take measures to protect any sensitive or proprietary information contained in them.
Recovery/Reconstitution
Recovery operations, as well as getting the business processes back into operation, are covered more in depth in Modules 41 and 42. However, it’s important that after an incident the business processes and systems be brought back up to normal functionality as soon as possible to prevent further negative impact on the business. This may involve restoring data from backups, reinstalling servers or network devices, patching systems, and even installing new equipment. All the recovery operations will probably be focused on the damage that was done during the incident and involve recovering those particular systems and data damaged by the event.
Module 39 Questions and Answers
Questions
1. All of the following are considered incidents, except:
A. Hacking attacks
B. Fires
C. Equipment theft
D. Increase in network traffic
2. Which of the following is the first phase of the NIST incident response life cycle?
A. Preparation
B. Eradication
C. Containment
D. Reconstitution
3. Which of the following should the incident response policy cover?
A. Response team notification procedures
B. Procedures for restoring a server in the event of an attack
C. Roles and responsibilities
D. List of response equipment and supplies
4. You are recommending personnel for incident response team lead positions. You have several candidates from which to choose and are recommending personnel based upon key characteristics. On which of the following characteristics should you base your recommendations? (Choose two.)
A. Certifications
B. Seniority
C. Training
D. Experience
5. All of the following should be included in the incident response strategy, except:
A. Defined types of events
B. Procedures for isolating a compromised workstation
C. Levels of impact for events requiring escalation
D. Conditions requiring activation of the incident response team
6. Which of the following are considered part of executing an incident response? (Choose two.)
A. Detection and Analysis
B. Preparation
C. Containment and Eradication
D. Reporting
7. Which of the following are ways to isolate an incident during a response? (Choose all that apply.)
A. Quarantining a system
B. Removing a device from the network
C. Shutting down a system
D. Connecting the system to the demilitarized zone (DMZ) on the network perimeter
8. Which of the following results of an incident may require public disclosure and informing individuals, by law?
A. Prohibited use of a company computer
B. Data breach
C. Web site defacement
D. Equipment theft
9. Which of the following would be considered non-technical damage to a business after a serious computer security-related incident?
A. Corruption of system files on a server, requiring a reload
B. A firmware compromise on a router
C. Loss of business due to lower consumer confidence
D. Data theft due to broken encryption keys by an insider
10. Recovery and reconstitution operations will be most likely focused on __________.
A. installing new perimeter security devices
B. systems and data damaged from the particular incident
C. redesigning the network infrastructure
D. installing new systems not containing the vulnerability that may have led to the incident
Answers
1. D. An increase in network traffic doesn’t necessarily mean that an incident has occurred.
2. A. Preparation is the first phase of the NIST incident response life cycle.
3. C. The organization’s incident response policy should cover key roles and responsibilities.
4. C, D. Training and experience are key characteristics to consider when recommending personnel for incident response team lead positions.
5. B. Procedures for isolating a compromised workstation are more detailed and should not be included in the overall incident response strategy.
6. A, C. Detection, analysis, containment, and eradication are all steps performed when executing an incident response.
7. A, B, C. All of these are ways of isolating an incident. Connecting the system to the demilitarized zone (DMZ) on the network perimeter does not isolate it; it may actually expose it to further attack or disruption.
8. B. A data breach, by law, may require public disclosure and informing individuals whose data has been compromised.
9. C. Loss of business due to lower consumer confidence is considered non-technical damage to an organization that can result from a serious incident.
10. B. Recovery and reconstitution operations will most likely be focused on systems and data damaged from the particular incident.