21.2 Definitions

A security event is a single, observable occurrence as reported by a security device or application or noticed by the appropriate personnel. Thus, both an IDS alert and a security- related help desk call qualify as a security event. A security incident is an occurrence of one or several security events that have a potential to cause undesired functioning of IT resources or other related problems. We'll limit our discussion to information security incidents, which cover computer and network security, intellectual property theft, and many other issues related to information systems.

An incident response is the process of identification, containment, eradication, and recovery from computer incidents, performed by a responsible security team. It is worthwhile to note that the security team might consist of just one person, who might be only a part-time incident responder (and not even by choice). Whoever takes part in dealing with the incident's consequences becomes part of the incident response team, even if the team does not exist as a defined unit within the organization. A security response is defined as an incident response taken in a broad context. Security extends far beyond the incident response process that is activated when a denial-of-service attack hits the web server or a malicious hacker breaches the perimeter. A large part of security is responding to daily security events, log entries, and alerts that might or might not develop into full-scale incidents. Thus, "security response" is the reaction of an organization to security events, ranging from a new line in a logfile to corporate espionage or major a DDoS attack.

An incident case is a collection of evidence and associated workflow related to a security incident. Thus, the case is a history of what happened and what was done, with supporting evidence. The incident case might include various documents such as reports , security event data, results of audio interviews, image files, and more. The incident report is a document prepared after an incident case investigation. An incident report might be cryptographically signed or have other assurances of its integrity. Most incident investigations result in a report that is submitted to appropriate authorities (either internal or outside the company), containing some or all data associated with the case. Note that the term evidence is used throughout this chapter to indicate any data discovered in the process of incident response, not only data collected that is admissible in the court of law.

Prevention-detection-response is the mantra of information security practitioners . Each component is crucial. We have looked prevention in Chapter 11, while Chapter 18 and Chapter 19 covered detection. This chapter completes the mantra: it shows what to do after you detect an attack. We also revisit certain aspects of detection; specifically , how to know that you were attacked .

All three points of the mantra are important to the security posture . Moreover, unlike detection and prevention, response is impossible to avoid. While it is common for organizations to have weak prevention and detection capabilities, response is mandatory ”your organization will likely be made to respond in some way after the incident has occurred. Even in cases where ignoring the incident or doing nothing and facing the consequences might be the chosen response option, an organization implicitly follows a response plan . Preparing for incident response is one of the most cost-effective security measures an organization can take.

Timely and effective incident response is directly related to decreasing incident-induced loss to the organization. It can also help to prevent expensive and hard-to-repair damage to your reputation, which often occurs following a security incident. Several industry security surveys have identified a trend: a public company's stock price may plunge because of a publicly disclosed incident. ^[2] Incidents that are known to wreak havoc upon organizations may involve hacking, virus outbreaks, economic espionage, intellectual property theft, network access abuse, theft of IT resources, and other policy violations. Many such incidents run counter not only to internal policies, but also counter to to federal, state, and local criminal laws.

^[2] If you think not disclosing is a measure against this effect, think again ”often the attacker will do it for you, just to embarrass your company. Also, new laws may require you to disclose incidents.

Even if a formal incident response plan is lacking, after the incident occurs the company's management might need to answer these questions:

• Can we put things back the way they were?

• Should we try to figure out who is responsible?

• How do we prevent recurrence ?

Answering these questions requires knowledge of your computing environment, company culture, and internal procedures. Effective incident response fuses technical and nontechnical resources with an incident response policy . Such a policy should be continuously refined and improved based on the organization's incident history, just like the main security policy.

This chapter shows how to detect network or local intrusions on your system. In addition, we review tools that can help you when your system tests positive for intrusions (from both malicious hackers and viruses). We also address the issues of virus incident response and briefly review computer forensics.

While many books exist that cover incident response for large organizations, relatively little information has been devoted to small- and medium- sized companies. We briefly touch on all of these categories.