This chapter is from the book
This chapter is from the book
This chapter is from the book
Detecting and Responding to Intrusions
Detection and response are the two most important of the four elements of the security process we discussed in Chapter 1. Since prevention eventually fails, organizations must maintain the capability to quickly determine how an intruder compromised a victim and what the intruder did after gaining unauthorized access. This response process is called scoping an incident. "Compromise" doesn't always mean "obtain root access." An intruder who leverages the privileges given to him or her by a flawed database is just as deadly as the attacker who obtains administrator access on a Windows host.
Anyone who has performed incident response on a regular basis quickly learns the priorities of decision makers. Managers, chief information officers, and legal staff don't care how an intruder penetrated their defenses. They typically ask the following questions.
-
What did the intruder do?
-
When did he or she do it?
-
Does the intruder still have access?
-
How bad could the compromise be?
Answers to these questions guide the decision makers' responses. If executives don't care how an intrusion was detected, it doesn't matter how the compromise is first discovered. No one asks, "Did our intrusion detection system catch this?" NSM analysts turn this fact to their advantage, using the full range of information sources available to detect intrusions. It doesn't matter if the hint came from a firewall log, a router utilization graph, an odd NetFlow record, or an IDS alarm. Smart analysts use all of these indicators to detect intrusions.
Although executives don't care about the method of intrusion, it means the world to the incident responders who must clean up the attacker's mess. Only by identifying the method of access and shutting it down can responders be confident in their remediation duties. Beyond disabling the means by which the intruder gained illegitimate access, incident responders must ensure their enterprise doesn't offer other easy paths to compromise. Why patch a weak IIS Web server if the same system runs a vulnerable version of Microsoft RPC services?
When determining a postincident course of action, the work of vulnerability assessment products becomes important. Assessment tools can identify "low-hanging fruit" and guide remediation actions once evidence necessary to "patch and proceed" or "pursue and prosecute" is gathered. [8] Over the course of my career I've noted a certain tension among those who try to prevent intrusions, those who detect them, and those who respond to them. All three groups should come together in the incident response process to devise the most efficient plan to help the organization recover and move forward.
The three parties can contribute expertise in the following manner. The prevention team should share the security posture of the organization with the detection and response teams. This knowledge helps guide the detection and response processes, which in return verifies the effectiveness of the prevention strategy. The detection team should guide the responders to likely candidates for in-depth, host-based analysis, while letting the preventers know which of their proactive measures failed. The response team should inform the detection folks of the new exploits or back doors not seen by the NSM operation. The response team can also guide the prevention strategy to reduce the risk of future incidents. Should any new policies or reviews be required, the assessment team should be kept in the loop as well.
Remember that intrusions are policy violations. Outsiders or insiders can be responsible for these transgressions. Although NSM data is helpful for identifying network misconfigurations, determining resource use, and tracking employee Web surfing habits, its legitimate focus is identifying intrusions.