Richard A. Caralli, Julia H. Allen, David W. White. CERT Resilience Management Model
Подождите немного. Документ загружается.
Incident Management and Control 487
IMC:SG4 RESPOND TO AND RECOVER FROM INCIDENTS
The process for responding to and recovering from incidents is established.
The nature of a declared incident is that the organization has already incurred
some effect, however limited, that requires the organization to act. Responding to
and recovering from an incident often requires two primary actions from the
organization:
• immediate limitation or containment of the scope and impact of the incident
• the development and implementation of an appropriate response to stop the ongoing
or future effect of the incident, repairing any remaining damage, and restoring organi-
zational assets and services to the state in which they existed prior to the disruption
Responding and recovering may also require a carefully coordinated and exe-
cuted collaboration between organizational units and external entities (such as
emergency providers) and a plan for handling incident logistics, particularly if
the incident is significant or catastrophic. The logistics of these coordinating
activities can often be planned in advance; however, execution may occur on
demand or spontaneously.
In addition, to avoid reputation damage, the organization must also craft and
implement a communications process that facilitates collaboration and logistical
execution and keeps stakeholders aware of the incident’s evolution and resolu-
tion. (Refer to the Communications process area for more information about develop-
ing, deploying, and managing internal and external communications in support of a
declared incident.)
IMC:SG4.SP1 ESCALATE INCIDENTS
Incidents are escalated to the appropriate stakeholders for input and resolution.
Incidents that the organization has declared and that require an organizational
response must be escalated to those stakeholders that can implement, manage,
and bring to closure an appropriate and timely solution. These stakeholders are
typically internal to the organization (such as a standing incident response team
or an incident-specific team) but could be external in the form of contractors or
other suppliers. (Refer to the External Dependencies Management process area for
information about managing relationships with external entities.) The organization
must establish processes to ensure that incidents are referred to the appropriate
stakeholders because failure to do so will impede the organization’s response and
may increase the level to which the organization is impacted.
Because communication is a vital tool in incident escalation, the organiza-
tion’s incident communications plan must be developed, implemented, and
IMC
488 PART THREE CERT-RMM PROCESS AREAS
tested in order to support effective escalation (see IMC:SG4.SP3). (Communica-
tions activities in support of operational resilience, including when dealing with an
incident, are described in the Communications process area.)
Ty p i c a l w o r k p r o d u c t s
1. Incident escalation procedures
2. Escalation criteria
Subpractices
1. Develop incident escalation criteria.
These criteria should provide guidance on when escalation is appropriate and
necessary, and the level of escalation required.
2. Develop incident escalation procedures.
Incident escalation procedures should consider the type and extent of the incident
and the appropriate stakeholders.
3. Communicate incident escalation criteria and procedures to those who have
responsibility for identifying and escalating incidents.
Ensure that stakeholders such as the service desk are included in the escalation
process.
4. Escalate incidents to appropriate stakeholders for resolution.
IMC:SG4.SP2 DEVELOP INCIDENT RESPONSE
A response to a declared incident is developed and implemented to prevent or limit
organizational impact.
Responding to an organizational incident is often dependent on proper advance
planning by the organization in establishing, defining, and staffing an incident
management capability. In addition, the organization typically has service conti-
nuity plans that can be executed in parallel if an incident has resulted in drasti-
cally affected operations. (Developing, testing, and implementing service continuity
plans are addressed in the Service Continuity process area.)
Responding to an incident describes the actions the organization takes to pre-
vent or contain the impact of an incident on the organization while it is occurring
or shortly after it has occurred. The range, scope, and breadth of the organiza-
tional response will vary widely depending on the nature of the incident. Inci-
dent response may be as simple as notifying users to avoid opening a specific
type of email message or as complicated as having to implement service continu-
ity plans that require relocation of services and operations to an off-site provider.
The broad range of potential incidents requires the organization to have a broad
range of capability in incident response.
The organization’s response to an incident must be founded on a well-structured
incident response capability and plan (as developed in IMC:SG1.SP1). Depending on
the organization, the actions related to incident response can include
Incident Management and Control 489
• containing damage (i.e., by taking hardware or systems offline or by locking down
a facility)
• collecting evidence (including logs and audit trails)
• interviewing relevant staff (those who are involved in reporting or analyzing the
incident and those who are affected by it)
• communicating to stakeholders, including asset owners and incident owners
• developing and implementing corrective actions and controls
• implementing continuity and restoration plans or other emergency actions (See
the Service Continuity process area for more information about continuity planning
and response.)
The organization must consider the best response structure for its unique
organizational structure and context. For some organizations, it makes sense to
establish one or more permanent teams that are responsible for repeatable
capabilities to respond to a broad range of incidents, supplementing the
response with subject matter experts where necessary. In other cases, an organ-
ization may establish a virtual “team” of individuals who may be quickly called
upon to perform specific duties to respond to an incident. In addition, the
organization may have standardized responses for certain types of incidents
(such as denial-of-service attacks) that have been developed through lessons
learned. Some of these responses might be reflected in standard service conti-
nuity plans that the organization has already developed.
In responding to any incident, the organization must consider who is responsible
for coordinating the overall response and ensure that those who must be involved in
the response have been notified. Responders must update the incident knowledgebase
to detail and document the steps taken to contain and repair incident damage so that
future incidents can use this information in root-cause analysis and problem diagno-
sis. (See IMC:SG2.SP4 and IMC:SG3.SP2 for more details.) In addition, the organization
must ensure that actions taken to contain or repair incident damage are performed in
a way that ensures no additional vulnerabilities are introduced or that the effect on
day-to-day operations is limited.
Ty p i c a l w o r k p r o d u c t s
1. Incident response strategy and plan
2. Service continuity plans
3. Restoration plans
4. Updated incident knowledgebase
Subpractices
1. Develop an incident response strategy and plan to limit incident effects and to
repair incident damage.
IMC
490 PART THREE CERT-RMM PROCESS AREAS
The incident response strategy and plan should address at a minimum
• the essential activities (administrative, technical, and physical) that are required
to contain or limit damage and provide service continuity
• existing continuity of operations and restoration plans in the organization’s plan
inventory
• the resources and skills required to perform the incident response strategy and plan
• coordination activities with other internal staff and external agencies that must
be performed to implement the strategy
• the levels of authority and access needed by responders to carry out the strategy
and plan
• objectives for measuring when the strategy and plan are successful
• the estimated cost of implementing the strategy and plan
• the essential activities necessary to restore services to normal operation (recovery),
the resources involved in these activities, and their estimated cost
• legal and regulatory obligations that must be met by the strategy
• standardized responses for certain types of incidents
2. Identify staff who are responsible for coordinating incident response (across all
potential types of incidents) and ensure they have the authority and responsi-
bility to act.
3. Update the incident knowledgebase with information about the incident
response strategy and plan.
IMC:SG4.SP3 COMMUNICATE INCIDENTS
A plan for the communication of incidents to relevant stakeholders and a process for
managing ongoing incident communications are established.
Miscommunications or inaccurate information about organizational incidents
can have dire effects that far exceed the potential damage caused by an incident
itself. As a result, the organization must proactively manage communications
when incidents are detected and throughout their life cycle. This requires the
organization to develop and implement a communications plan that can be read-
ily implemented to manage communications to internal and external stakehold-
ers on a regular basis and as needed. This plan should provide relevant
information to these entities and control or limit the degree to which misinfor-
mation and conjecture can develop. It must also consider the needs of a wide
range of stakeholders that have a vested interest in obtaining information about
organizational incidents in a controlled and regular manner.
The basic structure of the plan may be static, but the plan should be flexible
to address a broad range of incident types, stakeholders, and corresponding
communications needs. In addition, the organization should consider develop-
ing partnerships with external stakeholders so that a coordinated communica-
tions strategy can be developed and implemented when incidents affect the
organization’s external operational environment as well.
Incident Management and Control 491
Ty p i c a l w o r k p r o d u c t s
1. List of incident stakeholders, communications protocols, and channels
2. Incident communications plan
3. Incident status reports (from incident knowledgebase)
Subpractices
1. Identify relevant stakeholders that may have a vested interest or vital role in
communications about an organizational incident.
2. Identify the appropriate communications protocols and channels (media and
message) for each type of stakeholder.
3. Develop and implement an organizational incident management communications
plan.
The incident communications plan should address at a minimum
• the stakeholders with which communications about incidents are required
• the types of media by which communications will be handled
• the various message types and level of communications appropriate to various
stakeholders (For example, incident communications may be vastly different for
incident responders than for those who may simply need to know.)
These are examples of stakeholders that may have to be included in an incident
communication plan:
• members of the incident handling and management team (if the organization has
established such a team), or internal staff who have incident handling and man-
agement job responsibilities
• shareholders
• asset owners (if their asset is the target of the incident) and service owners
• information technology staff (if the target of the incident is the organization’s
technical architecture and infrastructure)
• middle and higher-level managers
• business continuity staff (if they will be required to enact continuity or restoration
plans as a result of the incident)
• human resources departments, particularly if safety is an issue
• communications and public relations staff
• support functions such as legal, audit, and human resources
• legal and law enforcement staff (including federal agencies), if the incident may
have legal ramifications
• external media outlets, including newspaper, television, radio, and internet
• affected customers or upstream suppliers
• local, state, and federal emergency management staff
• local utilities (power, gas, telecommunications, water, etc.), if affected
• regulatory and governing agencies
IMC
492 PART THREE CERT-RMM PROCESS AREAS
• special controls over communications (i.e., encryption or secured communica-
tions) that are appropriate for some stakeholders
• the roles and responsibilities necessary to carry out the plan
• the frequency and timing of communications
• internal and external resources that are involved in supporting the communica-
tions process
4. Identify and obtain commitment from staff who are required to carry out the inci-
dent communications plan.
Ensure that these staff members have the appropriate level of training and skills
necessary to execute and support the plan.
5. Identify and train staff responsible for incident communication and provide gen-
eral guidelines for incident response and other staff for appropriate communica-
tion of incident information.
IMC:SG4.SP4 CLOSE INCIDENTS
Incidents are closed after relevant actions have been taken by the organization.
(Closure of an incident can be performed only after post-incident review prac-
tices have been completed. Practices in IMC:SG5 must be completed before
IMC:SG4.SP4 can be accomplished.)
Incident closure refers to the retirement of an incident that has been
responded to (i.e., there are no further actions required and the organization is
satisfied with the result) and for which the organization has performed a formal
post-incident review (see IMC:SG5). The organization must have a process for
formal closure of incidents (including the practices in IMC:SG5) which results in
formally logging a status of “closed” in the incident knowledgebase.
A “closed” status indicates to all relevant stakeholders that no further actions
are required or outstanding for the incident. It also provides notification to those
affected by the incident that it has been addressed and that they should not be
subject to continuing effects.
Ty p i c a l w o r k p r o d u c t s
1. Criteria for incident closure
2. Updated incident knowledgebase
Subpractices
1. Establish criteria for incident closure.
The criteria for incident closure will vary by organization but will generally occur
after post-incident review has occurred. However, some organizations may estab-
lish concrete closure rules.
2. Define and assign the responsibility for incident closure.
Ty p i c a l l y, t h i s a c t i o n w i l l b e t h e r e s p o n s i b i l i t y o f t h e i n c i d e n t o w n e r o r i n c i d e n t
manager. Only authorized staff should be permitted to close an incident.
Incident Management and Control 493
3. Update the incident knowledgebase to indicate that an incident has been closed.
4. Track inc idents th at have been ope n for an extended period of time without
closure and resolve.
Incidents that appear to be open for an extended period of time may not have
followed the organization’s incident management process or may not have been
formally closed. The status of incidents in the incident database should be
reviewed regularly to determine if open incidents should be closed or need addi-
tional action.
IMC:SG5 ESTABLISH INCIDENT LEARNING
Lessons learned from identifying, analyzing, and responding to incidents are translated into
actions to improve strategies for protecting and sustaining services and assets.
One of the most important aspects of incident management and control is the
ability to understand why an incident occurred and what can be done by the
organization to prevent it in the future. From a risk management standpoint,
using incident lessons learned to improve controls and protection strategies and
to optimize these strategies with continuity planning and response effectively
shifts the organization’s attention from a response mode to a preventive mode.
Incident learning involves a post-incident review by relevant stakeholders, an
active link to the organization’s problem management process, and a formal
translation of lessons learned to improve strategies for protecting and sustaining
services and assets.
The practices of this goal should be considered as part of the closure activity as described in
IMC:SG4.SP4.
IMC:SG5.SP1 PERFORM POST-INCIDENT REVIEW
Post-incident review is performed to determine underlying causes.
Post-incident review is a formal part of the incident closure process. The organiza-
tion conducts a formal examination of the causes of the incident and the ways in
which the organization responded to it, as well as the administrative, technical,
and physical control weaknesses that may have allowed the incident to occur.
To b e e ff e ct iv e, p os t- i nc id en t re vi ew re q ui re s t he i np u t of a l l re le va nt s ta k e-
holders in the incident management process. This includes those who
• reported the incident
• detected the incident
• triaged and analyzed the incident
• responded to the incident
• were affected by the incident
• had the incident communicated to them
IMC
494 PART THREE CERT-RMM PROCESS AREAS
Post-incident review should include a significant root-cause analysis process.
The organization should employ commonly available techniques (such as cause-
and-effect diagrams) to perform root-cause analysis as a means of potentially pre-
venting future incidents of similar type and impact. (Root-cause analysis is also
useful for linking to the organization’s problem management process, as detailed in
IMC:SG5.SP2.) Considerations of other processes that may have caused or aided
the incident should be given, particularly as they may exist in processes such as
change management and configuration management.
Ty p i c a l w o r k p r o d u c t s
1. Criteria for incident closure
2. Post-incident analysis report
3. Recommendations for control improvement
4. Recommendations for improvements to incident management process
5. Updated incident knowledgebase
Subpractices
1. Establish and implement a formal post-incident response activity and require it as
part of closing an incident.
2. Assign responsibility for post-incident review activities to appropriate staff and
ensure they are properly trained.
3. Identify root-cause analysis tools and techniques and ensure all staff who partici-
pate in analysis are trained in their use.
These tools and techniques may include cause-and-effect diagrams, interrelation-
ship diagrams, causal factor tree analysis, etc.
4. Prepare a post-incident analysis report.
This report should detail the organization’s recommendations for improvement in
administrative, technical, and physical controls, as well as improvements to the
incident management process.
5. Document the results of post-incident root-cause analysis in the incident
knowledgebase so that this information is available for use in other processes
such as problem management.
IMC:SG5.SP2 INTEGRATE WITH THE PROBLEM MANAGEMENT PROCESS
A link between incident handling and the organization’s problem management process is
established.
Problem management is the process that an organization uses to identify recur-
ring problems, examine root causes, and develop solutions for these problems
Incident Management and Control 495
to prevent future, similar incidents. There is a strong link between incident manage-
ment and control and problem management in that incident management is
often the process where symptoms of a larger problem are first presented. The
organization’s problem management process and system (which are beyond the
scope of CERT-RMM) need information from post-incident review to be effec-
tive; likewise, incident management may rely on information from problem
management to diagnose and respond to incidents, particularly if no action has
been taken to resolve identified problems or root causes. Formal linkages
between problem management and incident management strengthen the orga-
nization’s overall ability to prevent incidents and minimize costly and reactive
response activities.
Ty p i c a l w o r k p r o d u c t s
1. Problem report
Subpractices
1. Establish a problem management system to ensure that all operational events that
are not part of standard operation (incidents, problems, and errors) are recorded,
analyzed, and resolved in a timely manner.
2. Document problem reports that arise from incident management and deliver
these reports to the problem management process.
The organization’s incident knowledgebase can serve as a central repository that
links the incident management and problem management processes so that
duplicative effort in documenting issues and problems can be avoided.
3. Periodically review problem reports and their status to determine their impact on
future incident detection and analysis.
4. Update the incident knowledgebase with information gathered in the problem
management process.
IMC:SG5.SP3 TRANSLATE EXPERIENCE TO STRATEGY
The lessons learned from incident management are analyzed and translated into service
and asset protection and continuity strategies.
The costs associated with incident detection and response are an investment for
the organization only to the extent that what is learned in these processes can be
used by the organization to make it more efficient and effective in dealing with
future events and in enhancing its approach to resilience. Lessons learned in inci-
dent management should serve as a benchmark for determining the validity and
effectiveness of the organization’s current strategies for protecting and sustaining
assets. In addition, lessons learned should provide valuable information for con-
tinuous improvement of the incident management process.
IMC
496 PART THREE CERT-RMM PROCESS AREAS
Ty p i c a l w o r k p r o d u c t s
1. Controls strategy
2. Service continuity plans
3. Resilience policy
4. Training needs an d requiremen ts
5. Incident management process improvements list
6. Service and asset resilience requirements
7. Updated incident knowledgebase
Subpractices
1. Review incident knowledgebase information and update the following areas
accordingly:
• protection strategies and controls for assets involved in the incident
• continuity plans and strategies for sustaining assets involved in the incident
• information security and other organizational policies that need to reflect new stan-
dards, procedures, and guidelines based on what is learned in the incident handling
• training for staff on information security, business continuity, and IT operations
2. Review incident management and control processes and update them for any per-
ceived deficiencies or omissions.
3. Update resilience requirements for assets and services based on what is learned in
the incident management process.
4. Quantify and monitor the types, volumes, and costs of incidents.
Elaborated Generic Practices by Goal
Refer to the Generic Goals and Practices document in Appendix A for general guidance that
applies to all process areas. This section provides elaborations relative to the application of
the Generic Goals and Practices to the Incident Management and Control process area.
These are examples of areas that have to be addressed after an incident:
• Update protection strategies and controls to protect assets and services from future
incidents of similar type and nature.
• Update policies to reflect lessons learned.
• Update training for employees regarding the incident.
• Revise continuity plans and strategies to protect and sustain services and assets.
• Review and revise life-cycle processes.
• Review and revise asset-level resilience requirements, if necessary.
• Revise incident criteria.
• Develop standardized responses to common incidents.
• Improve incident management processes.