Home > Articles > Operating Systems, Server > Solaris

Responding to Customer's Security Incidents—Part 2: Executing a Policy

  • Print
  • + Share This
This article is the second in a series that discusses a policy of security incident responses. The article describes the policy best practices and execution features — evaluation, containment, and eradication of and recovery from a security incident — for responding to a customer's incident within the policy scope.
Like this article? We recommend

: Executing a Policy

There have been several large-scale worm attacks on the Internet since 1988 and highly visible and coordinated denial-of-service attacks in the last few years causing billions of dollars in damage. These attacks indicate that responding to such incidents is increasingly more complex and requires technical knowledge, communication, and coordination among the staff responding to an incident, along with an adherence to applicable standards and policies.

A security incident response involves several aspects of preventive, detective, and recovery measures. A preventive measure primarily involves risk control that mitigates the effects or deters the occurrence of an undesirable event. Examples of preventive measures are passwords, keycards, badges, contingency plans, policies, firewalls, and encryption. A detective measure identifies the occurrence of an undesirable event. Examples of detective measures are visitor logs, audit trails, motion sensors, closed-circuit TV, and security reviews. Detective measures also provide a means for reporting the occurrence of events. A recovery measure is a risk control that will, in a traditional sense, include control policies, processes, or mechanisms that restore the integrity, availability, and confidentiality of information assets to their expected state. Examples of recovery measures are fault tolerance, backup, and disaster recovery plans.

Since the late eighties and early nineties, a substantial amount of information has been published on the topic of security incident response from the following organizations:

In 1990, NIST, in conjunction with CERT/CC, CIAC, NASA, and other agency response teams, organized a cooperative activity known as the Forum of Incident Response and Security Teams (FIRST) at: http://www.first.org

This coalition brings together a variety of computer incident response teams from governments, commercial organizations, and academic organizations. FIRST fosters cooperation and coordination in incident prevention, prompts rapid reaction to incidents, and promotes information sharing and learning among the members of its community.

": Executing a Policy" is the second of a series of articles that discuss a security incident response policy and execution. These articles are not intended to include all of the material from the above efforts. They are intended to capture the salient points of the security incident response process and to present them in the context of a business entity that serves its constituents (that is, its customers).

The first article, "Responding to a Customer's Security Incidents—Part 1: Establishing Teams and a Policy," contains definitions of security incidents, security incident response, teams that typically are involved in an incident response, the pros and cons of the teams, and the scope and goals of the security incident response policy. In addition, it describes policy essentials for the notification aspect of a security incident.

This second article describes the best practices and execution of key policy features of responding to a customer's incident within the policy scope described in the first article. These features mainly include evaluation, containment, and eradication of and recovery from a security incident. Subsequent articles will focus on incident follow-up, with a special emphasis on forensics, risk analysis, disaster recovery, and government and legal recourses, as well as proactive teamwork. The primary audience consists of computer security managers, security policy developers, system administrators, and other related staff, responsible for the creation or operation of a computer security incident response policy and service.

  • + Share This
  • 🔖 Save To Your Account