On Response

Blogger: Eric Maiwald

Prevention is hard. If we want to protect something important, we put it in a locked room. But a thief with a lock pick can defeat the lock. So we change the lock to something hard to pick. That works until the thief shows up with tools and takes the door off. We escalate to a safe with heavy steel construction that is anchored to the floor. The thief shows up with tools to drill the safe and given enough time, the thief will win again.

The same is true about preventing hackers and other criminals from breaking into our computer systems. As Dan Blum noted in last week’s blog "Can't Win the Core Wars," the war of preventative measures versus attack methods escalated at Black Hat 2008 with the publication of techniques to get around Microsoft’s latest protective measures. Prevention is hard.

What else can we do to control negative consequences (and manage risk)?

We can examine how we detect and respond when preventative measures fail. This is not a call to remove preventative controls – they certainly have their place – but we must understand that we will not win a continuing war of escalation. Deploying a greater variety of preventative controls does not reduce our overall risk in the long term (sure – it might in the short term but only until the criminals come up with a new attack technique or find a new vulnerability).

Just about every enterprise already uses response to help manage risk. Think about disaster recovery plans, business continuity plans, backup tapes, etc. All of these security controls are built to help an enterprise respond to an event that cannot be prevented. We cannot prevent hurricanes, floods, earthquakes, and tornados so we build plans and capabilities to respond to the event and limit the negative consequences to the business.

We can do the same things around other events. For example, we can detect a malware infected desktop by monitoring the traffic that is sends on the network. If we see inappropriate traffic originating from a desktop, we can take it off the network and send a team to repair it. (Think about a team in black jumpsuits arriving at an office, “step away from the computer and leave your mouse where we can see it!”) The same type of thing can be done to detect and respond to other types of attacks. We can identify a compromised web server by monitoring it for unauthorized changes. If we see some files change, we can replace them with the correct files or take the server off-line to be reloaded.

Of course, the response must be appropriate to the risk the event poses to the enterprise (don’ forget about the consequences of negative publicity!) and we cannot respond to an event in such a way that we cause more damage than would have occurred had we not responded. Here (yet again), we may be able to better manage risk by understanding the business implications of security events. If we understand when negative consequences begin to occur and how they affect the business, we can create response plans appropriate to the event. We can also weigh preventative measures vs. response plans and determine which is most appropriate to the business risk (there are some risks where prevention is still the most appropriate security posture).

So in the end, don’t always think of prevention as the only way to deal with risk. Detection and response can be an appropriate posture for certain types of risk. In some cases, using response can be more cost effective than installing the latest and greatest preventative tool.