Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Introduction to Incident Response

Incident response is the collection of actions taken after an alleged security incident is identified. In many organizations, a formal incident response team coordinates response. Its members are drawn from IT, audit, security, human resources, legal, senior management, and other areas of the company. In many cases, only a few of these people are assigned to any incident, and additional employees as well as outside specialists may be recruited during specific incidents. In other companies, incident response is less formal. Teaching you how to create a crack team and detailing how to respond to every possible security incident is not the purpose of this section. Instead, its purpose is to help you identify action points that can be taken in order to formulate a response to incidents. If you already have an incident response team or process in place for incident response, your first task should be to contact them to understand what your role should be in reporting or working as part of their extended team. If you do not have any process in place, or want to review the process you do have in hopes of improving it, use the following guidelines.

The classic incident response process consist of sseven elements:

Detect the incident.

Respond to the incident with some action.

Contain the incident; don't let it continue to grow or further compromise information systems.

Recover systems.

Resume normal operation.

Review the what, when, why, who, and how the event happened and how it was dealt with.

Improve by implementing steps to prevent future incidents and by developing a better response.

However, before you can follow this path, you must develop a plan. Here are some steps that can help:

List possible security incidents. Security incidents can be as devastating as malware storms in which massive infections threaten to destroy network operations to suspected misuse or sharing of logon credentials. In addition to the incidents you may hypothesize from your familiarity with current attack vectors, be sure to include the results of threat modeling that may have been done on your network operations and specific applications. Another good source of possible incidents is reviewing the event logs and other data collected as the result of tools described in this chapter. When you know what is normal, can you identify the data that might mean simple operational failure and thus need troubleshooting, from that which might point to possible attack? Add those events to your list.

Categorize incidents. You may want to use several types of categories. One good category is by type. For example, various malware infections may have similar vectors, as well as similar cleanup requirements, while directed attacks are very different. The advantage of categorizing is that you can estimate the number and type of individual who will be necessary for the response.

Plan operations that might reveal various incidents in progress or from the data trail they produce in various logs.

Determine the type of response for each type of incident. How many people will be needed? What needs to be done? Will specific department members need to be part of the team; for example, legal may need to advise you on what information needs to be shared with the public, when to call in law enforcement, or when and what to say to customers. Human relations may need to be informed in order to work with employees in countering rumors with fact or in helping employees to deal with the affects of the attack such as finding uncompromised data and work sources, or preventing reinfection.

Assign responsibility for starting and working the response process. Who takes the alleged incident, determines if it is a security incident, assigns a team, and monitors progress? Who keeps management and other team members not directly involved in the technical aspect of the response informed? Who documents activity?

Plan for a post mortem. After an incident, collect all information and meet with incident response team members, both those involved with this incident and others. A lot can be learned from reviewing how the event was handled. Kudos can be given, and errors can be discussed leading to improved procedures and team efforts in the future.