Preparing for the Worst: Why an Incident Response Plan is just as important as a Prevention Plan

The advantage is firmly in the hands of the attackers right now. The number of easy to use tools available and the speed that new vulnerabilities are incorporated into these tools greatly outpaces the speed that most organizations can stay on top of the threats. No matter how many precautions you have taken, a breach, or incident will occur. Although there are many things you can do to minimize the risk of a breach, you should operate under the assumed breach mentality — you have already been breached, you might just not know it. What are you going to do now?

Data centers are particularly juicy targets for attackers because there are so many different systems consolidated in a single place. This makes it easy for attackers to pivot from a breach of one system to another. Fortunately, the physical security of data centers is usually much better than a standard corporate network. Unfortunately, when you evaluate the digital security of data centers, we are far behind. We need to do a better job of recognizing the difference between how to secure the digital environment from the physical.

We can’t simply apply the same principles of perimeter defense to the systems in a data center. However, one lesson we can take from physical security principles is response. If someone were to physically attempt a breach, there are typically well-established procedures to call for reinforcements, contain the attacker, and escalate to local law enforcement. Can you say the same for how you respond after detecting a cyber-incident? With that in mind, the basics of a cyber-response include knowing your technical response and knowing your communication plan.

The Technical Response

For the technical response, one of the biggest questions is: do you shut down the attacker or monitor their activity? There are pros and cons for both approaches, but your organization needs to have a clear plan before the incident.

Let’s say you notice a large amount of traffic exiting your data center from a server that shouldn’t be sending data out of the network. You detect an unauthorized FTP service is running on that server. Are you going to just disable the service immediately? If you do, will you be able to determine the full extent that you are compromised? If you assume it’s just the one machine and purge it, the attacker may still have full reign of your infrastructure. This will also cause the attacker to go underground for a while, which may trick you into thinking you have remediated the threat. If your policy is to monitor the attacker, how long do you do that and how can you wall off the attacker from gaining access to other systems?

These are fundamental questions that you need to have business buy-in for and a solid plan around before you are breached. Also, assume that knowledge of your response plan wouldn’t undermine its effectiveness. Assume the attacker has your plan, are you still able to effectively manage the breach?

Federal incident notification guidelines have been established by DHS/US-CERT, and there use is mandated by FISMA. US-CERT will work with agency IT personnel to analyze threats, exchange critical information with trusted partners, and engage cyber defense resources, as appropriate. Agencies also need to follow their departmental policies and involve their Public Affairs offices with public disclosures and announcements.

Breaches bring IT front and center to agency executives and have an immediate and often long lasting impact to agency operations. If you don’t have a plan to respond when breached, you’ve devalued the effort you’ve dedicated to prevention. When a security breach occurs, how you respond can make all the difference. If you have a well-structured incident response plan, you can mitigate much of the damage of an attack.

A comprehensive incident response plan needs to address the different types of incidents an agency could encounter, as responses will vary by incident type. Roles and responsibilities of the response team need to be assigned and communicated, and back-ups need to be identified. Other important parts of your plan include establishing a communication decision tree, as well as incident response procedures.

Your incident response plan should also be regularly tested and updated. You cannot afford for it to be a document that gets created and forgotten about. This is probably more detrimental than not having a plan at all since it will create a false sense of security. If it’s out of date, it will also slow down your response as specific contacts and systems may no longer be valid, requiring you to hunt down new information. You should run quarterly tabletop exercises to make sure staff know how to respond and find flaws in the plan. Ideally, you are doing this continuously as part of your larger change control process. At a minimum you should meet as a team once a month to review and discuss the plan to make sure your response is evolving with the changing threat landscape.

Investment in prevention is necessary, but insufficient. If you are only focused on trying to prevent attacks, it will make it difficult to detect and respond appropriately when you are breached. It’s very easy to feel secure by spending time and resources securing your environment. If you don’t have a well-defined incident response plan in addition to those prevention solutions, then you aren’t doing enough to secure your data centers and critical facilities.

By Mav Turner, Director of Product Strategy for Security, SolarWinds