Reinicio remoto del equipo

The process mapping work grew out of a project aimed at assessing the effectiveness of CSIRTs. We had been chartered to develop a CSIRT assessment technique for specific cus-tomers and decided to incorporate a new risk analysis methodology being developed by the SEI. That risk analysis methodology is based on a process-mapping, or workflow-design, technique called swimlane diagramming. It also relies on several custom-developed data col-lection and risk analysis artifacts.

Process modeling techniques are useful for illustrating an abstraction of a business process, highlighting key activities and artifacts required to conduct the process. A workflow model is a specific type of process modeling technique, providing a description of how tasks are done, by whom, in what order, and how quickly. It differs from other modeling techniques, such as data flow diagrams and flow charts, because it specifically defines interrelationships and de-pendencies among tasks and activities; other modeling techniques do not provide this

24 “Map” in this context relates to the process workflow diagrams and supporting descriptions.

40 CMU/SEI-2004-TR-015

mation. Understanding interrelationships and dependencies among tasks and activities is im-portant when analyzing the risk inherent in a business process, such as incident management.

For this reason, workflow modeling became an integral part of our risk analysis work.

As indicated above, we specifically selected swimlane diagramming as our central modeling technique. (To see an example of a swimlane diagram, please refer to page 33.) Swimlane diagrams highlight relevant process variables—the “who, what, and when”—in a simple no-tation. They show an entire business process from beginning to completion and are valuable for understanding the as-is workflow, as well as for defining the to-be workflow. These dia-grams are valuable for depicting the following key items [Sharp 01]:

• roles – the actors or performers who participate in the process

• responsibilities – the tasks for which each actor is responsible

• routes – the workflows and decisions connecting tasks together and defining the path an individual work item takes through the process

While workflow modeling provides several critical pieces of information vital to risk analy-sis, we needed to extend the technique to fully capture the broad range of information re-quired. With respect to the swimlane diagrams, we followed the principles outlined in Work-flow Modeling [Sharp 01]. We tried to keep the diagrams as simple as possible, which can be quite challenging for a process as complex as incident management. We limited our use of symbols, attempting to keep the diagrams readable by the widest audience possible. We also made liberal use of textual annotation in the diagrams to provide additional information about the process where appropriate. We used standard icons on the diagrams where appropriate.

The primary reason for using annotation and icons in certain instances was to capture addi-tional information related to the risk analysis technique. For example, we denoted the inputs and outputs related to each task directly on the swimlane diagram because this information is essential to analyzing risk. (For more information about swimlane diagrams and how to read them, refer to Workflow Modeling [Sharp 01].)

While the interrelationship, dependency, timing, and sequencing information illustrated by a swimlane diagram is necessary to conduct a risk analysis, additional data is required to ensure that the analysis is complete. Process risk also includes information related to how a work process is executed. Unfortunately, swimlane diagrams do not provide enough information about process execution, which led us to further extend the workflow modeling technique.

We designed a table called a process description to document additional information about each process, including how the process is conducted, which procedures must be followed, and which technology supports the process. The information documented in swimlane dia-grams and process descriptions provides sufficient data for the risk analysis.

Finally, to facilitate a risk analysis at a given site, we developed a generic incident manage-ment practice that could be easily tailored to that site. The generic practice provides the basis for the technical information presented in this report. As we began building the generic model, we realized how many variations existed with respect to roles and responsibilities for each incident management activity. For example, the people responsible for receiving

infor-CMU/SEI-2004-TR-015 41

mation reported by the constituency (from D2: Receive Information) can include the follow-ing:

• help desk staff

• CSIRT triage staff

• CSIRT hotline staff

• CSIRT manager

• incident handlers

• information security officer

• system and network administrators

• third-party answering service

• coordination center

Because of the sheer number of potential roles and responsibilities potentially associated with each incident management activity, we determined that our generic workflow diagrams had to differ from classic swimlane diagrams in one important respect. The large number of poten-tial actors or performers for each activity, if included on the diagrams, precluded our ability to keep the diagrams simple and readable. We thus moved information about roles and re-sponsibilities to the process descriptions and eliminated this information from the workflow diagrams. However, when performing a risk analysis for an organization, the first step is to determine precisely who is responsible for performing each incident management activity, enabling us to create a unique swimlane diagram for that organization.

3.3.1 Additional Uses for the Workflow Model

Upon developing the initial version of the incident management model, we saw how it could serve multiple purposes. It provides a needed structure for organizing the body of knowledge in the incident management domain, bringing with it the potential for influencing the devel-opment of future products and services. However, it is important to keep in mind the original intent of the model as you review the details presented in this report. Its format reflects our original purpose for creating it, which is assessing the effectiveness of CSIRTs or other inci-dent management capabilities. You should view the model presented in the following pages as a prototype or work in progress rather than a final product.

Early feedback indicates that the prototype has uses far beyond what we imagined when we first began working on it. We now see the incident management model as a stand-alone prod-uct rather than simply part of an assessment. We intend to continue developing the model, improving its content based on input from the community and providing progressively more detail over time. As the model evolves, its format and content might change, reflecting its expanding role in our product suite.

42 CMU/SEI-2004-TR-015

3.4 Guide to Reading the Incident Management