Responding to Customer's Security Incidents—Part 2: Executing a Policy
- : Executing a Policy
- Security Incident Response
- Computer Security Incident Response Teams
- Preparing for Incident Response
- Management of Security by Teams
- Execution of an Incident Response
- Evaluation of a Security Incident
- Containing the Incident
- Eradicating the Incident
- Recovering From an Incident
- Article Series
- About the Author
- Acknowledgements
- References
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
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:
Australian Computer Emergency Response Team (AusCERT), http://www.auscert.org.au/
Brazil's Centro de Atendimento a Incidents de Segurança (CAIS), http://www.rnp.br/lang/cais_en/
Carnegie Mellon University's Software Engineering Institute's Computer Emergency Response Team/Coordination Center (CERT/CC), which was initiated by the Defense Advanced Research Projects Agency (DARPA), http://www.cert.org
European Institute for Computer Antivirus Research, http://www.eicar.org/
German Computer Emergency Response Team (DFN-CERT), http://www.cert.dfn.de/
Internet Engineering Task Force (IETF) in the form of RFCs, http://www.ietf.org/rfc.html
Purdue University's Computer Incident Advisory Capability (CIAC), which is funded by the Department of Energy, http://www.ciac.org/ciac
SysAdmin, Audit, Network, and Security, http://www.sans.org
U.S.'s National Institute of Standards and Technology (NIST), http://www.nist.gov
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.