Incident Management Processes Introduction

Incident Management Processes Introduction

Table of Contents

Notices ............................................................................................................................................ 2

Incident Management Processes: Introduction, Prepare and Protect ........................................... 2

Purpose ........................................................................................................................................... 3

Building Your Incident Management Plan ...................................................................................... 4

What Supports Your IM Plan? ......................................................................................................... 6

Page 1 of 7

Notices

19Managing CSIRTs© 2020 Carnegie Mellon University

[DISTRIBUTION STATEMENT A] Approved for public release and unlimited distribution.

Incident Management Processes: Introduction, Prepare and Protect



Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213

[DISTRIBUTION STATEMENT A] Approved for public release

and unlimited distribution.

Incident Management Processes: Introduction, Prepare and Protect

Managing Computer Security

Incident Response Teams

(CSIRTs)

**001 Hello. This module is Incident

Management Processes.

Page 2 of 7

Purpose



Purpose

To understand the various processes involved in incident management.

To review best practices associated with incident management activities.

**002 The purpose of this module is

to understand the various processes

involved in incident management and

to review some best practices

associated with these incident

management activities.

Page 3 of 7

Building Your Incident Management Plan



Your IM plan details what

IM processes are

performed across your

enterprise, including

• relationships between

processes

• who performs them

• existing interfaces

• inputs and outputs

What should be in your IM plan?

• organizational group responsible for each IM function

• detailed roles and responsibilities

• defined interfaces between functions

• defined event and incident criteria

• point of contact for reporting events and incidents

• timeframe for reporting and handling incidents

• workflows for handling incidents

• emergency situations

• response actions for specific types of incidents

• postmortems and feedback activities

Building Your Incident Management Plan

**003 Every CSIRT should have an

incident management plan for the

organization that they're part of or

their constituency. The whole idea of

this is to define all of these in

advance. Again, as has been said

before, don't wait until the first fire to

form the fire company. So you need

to decide all of these things in

advance: what groups are

responsible for each part of the

incident management function; what

are the roles and responsibilities of

the people that are involved with

those; what are the interfaces

between those functions--are they

paper, are they email, are they faxes,

are they on a wiki, whatever.

Defining an event and an incident.

Now it would seem as though there

are very common things that you

think would be defined, but it

sometimes can be an issue. It's

Page 4 of 7

important to understand what a

security event is and what a security

incident is. And again, you can find

definitions of these from other

organizations on FIRST.

Who is the point of contact for

reporting events and incidents?

Anybody within the organization, the

constituency that this CSIRT

supports, ought to know what to do

with incidents and events and who to

report them to.

Timeframe for reporting. Sometimes

the timeframe depends upon external

sources-- for example, compliance to

state, local, and federal government

levels. What are the workflows for

handling incidents? Where does the

information begin? Who does it go

to? What do they do with it?

Etcetera.

Emergency situations that show up--

off hours is one example-- and a

response plan for specific types of

incidents. If it's a virus, what do you

do? If it's a loss of intellectual

property, what do you do? If it's a

loss of personally identifiable

information what do you do? If it's a

loss of customer information?

And finally, post mortems and

feedback. The idea here is that

every point in time when you finish

an incident or an event, review

what's happened to make sure that

you've had the correct policies and

procedures in place, that people

knew what they were supposed to

do, and the right or the wrong things

Page 5 of 7

happened, and make the changes as

is appropriate.

What Supports Your IM Plan?



What Supports Your IM Plan?

Governance support of IM plan

Recognition of the importance of IM

Risk analysis and resulting output

Information classification scheme

Incident criteria

• definition of incident

• prioritization

• categorization

• escalation

Incident reporting policy, guidelines and reporting template

Critical systems and data inventories

Guidelines for handling Personally Identifiable Information (PII)

**004 Here's a list of items that

support your incident management

plan. For example, governance. You

may have governing bodies above

you dictating certain things that may

be in your plan. Recognition of the

importance of the incident

management plan throughout your

organization. Risk analysis. The

intent of risk analysis is to identify

the critical information assets and

business processes to keep the

business in working order, and by

understanding their importance you

can focus on what the most

important issues are, what the most

important assets are, and deal with

them sooner rather than later.

Some notion of information

classification. The traffic light

Page 6 of 7

protocol spoken about previously

comes into play here. Incident

criteria. What is an incident? What

are the priorities of an incident? How

are incidents categorized and how

are incidents escalated as they go on

when they become more important?

There needs to be an incident

reporting policy, guidelines and a

template. People are much more

able to fill out a template with

dropdowns, with any kind of an

interface, and provide the necessary

information needed to start an

incident if you have that kind of a

mechanism.

It's also important that people, at

least in the CSIRT and around the

organization, better understand what

the critical systems are and what the

critical data inventories are. Again,

you'd think that that would be

something that would be commonly

understood and known but that's not

always the case.

And finally, guidelines for handling

PII, personally identifiable

information. These days more and

more states are defining that a

breach that involves a loss of PII

requires different levels of notification

of the other people involved in that

company, and so you need to be

aware of that.

Page 7 of 7

Documents

Incident Management Processes Introduction