An incident response procedure (IRP) defines how the organization will react when an information security incident occurs. Given that each incident will be different, the IRP should define who has the authority and what needs to be done, but not necessarily how things should be done. That should be left to the people working the incident.
Incident Handling Objectives
The IRP should specify the objectives of the organization when handling an incident. Some examples of IRP objectives include the following:
- Protecting organization systems
- Protecting organization information
- Restoring operations
- Prosecuting the offender
- Reducing bad publicity or limiting damage to the brand
These objectives are not all mutually exclusive and there is nothing wrong with having multiple objectives. The key to this part of the procedure is to identify the organization’s objectives before an incident occurs.
Event Identification
The identification of an incident is perhaps the most important and difficult part of an IRP. Some events are obvious (for example, your web site is defaced), while other events may indicate an intrusion or a user mistake (for example, some data files are missing). Before an incident is declared, some investigation should be undertaken by security and system administrators to determine whether an incident actually did occur. This part of the procedure can identify some events that are obviously incidents and also identify steps that should be taken by administrators if the event is not obviously an incident.
Escalation
The IRP should specify an escalation procedure as more information about the event is determined. For most organizations, this escalation procedure may involve activating an incident response team. Financial institutions might have two escalation levels depending on whether funds were involved in the event.
Each organization should define who is a member of the incident response team. Members of the team should be drawn from the following departments:
- Security
- System Administration
- Legal
- Human Resources
- Public Relations
Other members may be added as needed.
Information Control
As an incident unfolds, organizations should attempt to control what information about the incident is released. The amount of information to release depends upon the effect the incident will have on the organization and its customer base. Information should also be released in a way that reflects positively on the organization.
Response
The response an organization makes to an incident flows directly from the objectives of the IRP. For example, if protection of systems and information is the objective, it may be appropriate to remove the systems from the network and make the necessary repairs. In other cases, it may be more important to leave the system online to keep service up or to allow the intruder to return so that more information can be learned and perhaps the intruder can be identified. In any case, the type of response that is used by an organization should be discussed and worked out prior to an incident occurring.
Authority
An important part of the IRP is defining who within the organization and the incident response team has the authority to take action. This part of the procedure should define who has the authority to take a system offline and to contact customers, the press, and law enforcement. It is appropriate to identify an officer of the organization to make these decisions. This officer may be a part of the incident response team or may be available for consultation. In either case, the officer should be identified during the development of the
IRP, not after the attack occurs or during the incident response.
Documentation
The IRP should define how the incident response team should document its actions, including what data should be collected and saved. This is important for two reasons: it helps you understand what happened when the incident is over, and it may help in prosecution if law enforcement is called in to assist. It is often helpful for the incident response team to have a set of bound notebooks for use in documenting what occurs during an incident.
Testing of the Procedure
Incident response takes practice. Do not expect that the first time the IRP is used, everything will go perfectly. Instead, once the IRP is written, conduct several walkthroughs of the procedure with the team. Identify a situation and have the team talk through the actions that will be taken. Have each team member follow the procedure. This will identify obvious holes in the procedure that can be corrected.
This article is an excerpt from Network Security A Beginner’s Guide, Third Edition published by McGraw Hill. Visit Amazon to purchase the book.
All information in this article is copyrighted by McGraw Hill and is reprinted here by express permission of the publisher