The 7 deadly sins of incident response

The seemingly endless barrage of attacks on government and enterprise networks has made it clear that organizations need to be much more proactive when it comes to security. Deploying perimeter defenses like firewalls and antivirus, and expecting them to keep attackers off of your network, has become just plain foolish in light of today’s increasingly complex threat landscape. Today it is not a matter of if, but when you will be attacked. Security success is no longer just about keeping threats out of your network, but instead about how quickly you can respond and thwart an attack when it happens.

Despite this scenario, many organizations still haven’t gotten it quite right when it comes to incident response. Here are “7 Deadly Sins” that Lancope often sees companies committing when attempting to build an incident response function.

1. Not understanding your environment due to a lack of visibility. As the saying goes, you can’t protect what you can’t see. Setting up an incident response plan without adequate network visibility is a fairly useless exercise. How can you determine whether a specific communication is suspicious or not when you aren’t aware that it happened? And when a breach happens, how will you be able to pinpoint where and how it occurred if you don’t know what traffic is moving throughout your environment?

For many companies, incident response consists of identifying the machine that first drew attention and taking it offline. But that’s simply not enough. If you have the right level of network visibility, you can determine whether or not ‘patient zero’ also infected others before it was disconnected. Especially when targeted attacks are a concern, the type of visibility needed to discover lateral movement is practically required to stop the spread of an infection before it leads to a data breach.

Obtaining high levels of network visibility, both internal and external, is a challenge – especially in large organizations subject to mergers and acquisitions. Disruptive technology trends like cloud computing and mobility are also skewing visibility. However, leveraging technologies such as NetFlow, web proxies and firewalls can provide the visibility needed if leveraged in the right way.

In order to be effective, the data from these technologies needs to be not only logged, but also collected, analyzed and stored long term to provide audit trails and allow for the development of actionable intelligence. You will need the right tools and responders to sift through all of the data and find the needle in the haystack, but it’s well worth the investment. Take advantage of the plethora of data already residing on your network to help swiftly detect and respond to attacks. Don’t rely on the media or the FBI – as others have – to tell you that you’ve been breached!

2. Not having the right staff. Unfortunately, being an expert in security does not necessarily mean that you’re an expert in incident response. Organizations need skilled incident responders to turn all of the data mentioned above into actionable intelligence. Additionally, having incident response team members who are intimately familiar with your particular network environment and risk tolerance level often yields more relevant, accurate information faster.

It is also important to have dedicated incident responders who are not also responsible for myriad other IT functions. According to a study by the Ponemon Institute, 45 percent of surveyed enterprises who stated they had a “fully functional” CSIRT said they had no staff solely dedicated to the CSIRT function. This needs to change if we want to turn the tides against our attackers and make large-scale breaches less of a regular occurrence.

Lastly, think beyond technical responders. For an incident response plan to truly be effective, it also needs to include additional departments such as Legal, HR and Public Relations, who should ideally all play a role in helping to plan for and respond to attacks. Bring these departments into the fold up front – do not wait until a breach occurs and have them scrambling to figure out the appropriate response.

3. Lacking the appropriate budget. In some cases, budgets are truly tight and there’s not enough to go around. In many cases, however, the budget is there and it’s just not allocated appropriately. Obtaining a sizable budget for incident response requires the ability to prove its value to the organization. Incident responders need to be able to translate technical needs into business relevance when addressing upper management. The management team also needs to be kept in the loop when it comes to incident response procedures and efficacy.

According to the Ponemon Institute report cited earlier, 50 percent of respondents said that less than 10 percent of their security budget goes to incident response. Additionally, 50 percent of respondents said that they did not use any meaningful operational metrics to measure the effectiveness of incident response activities. The survey also found that executives above the IT management level were not frequently briefed on what was going on within IT security. There’s a correlation to be drawn from these figures. If management has no idea what is going on with your incident response team, and you don’t have the data to inform them, then there’s little hope of them increasing your budget.

4. Becoming a headless chicken when breaches occur. In addition to the right staff, budget and tools, you also need a comprehensive plan for incident response. Not having a plan results in hasty, uninformed decisions when breaches occur, and that is never good for business. Organizations need to have a written incident response playbook that very clearly delineates defined roles and approved procedures for handling an incident. For example, is the incident response team permitted to take machines offline without additional approval to contain an attack? What about wiping computers or blocking access to specific services? Are those actions permitted when necessary? Additionally, what are the company’s legal, regulatory and contractual obligations when a breach occurs? It is critical to have these types of questions answered in writing before an incident happens.

5. Using generic processes not specific to your organization. While incident response procedures should be a focus for all organizations today, it’s important to recognize that ‘playbooks’ generally aren’t one size fits all. Context is really key when building an incident response program. You have to take into account the specific types of critical assets your organization possesses, where they are located, your risk tolerance, and how much leeway your CSIRT has to make major decisions and changes to your infrastructure. Ideally, your IR plan should strike a comfortable balance between having policies in place to ensure that the right decisions are made in a crisis, yet not having so many layers of approval that you hinder the efficacy of skilled responders.

6. Improper threat modeling. Along those same lines, the assets that you focus the most effort on protecting should be what is most valuable to your specific organization. Unfortunately, no CSIRT can protect everything all the time, so it is critical to know where your organization’s risk really lies. Know which assets would have the biggest impact on the success of your organization if taken down by an attacker and give thought to the scenarios in which those assets are put at risk.

7. Not considering your environment and capabilities when tuning devices. There are multiple tools out there that can significantly improve incident response processes. However, believing that you can get the maximum value out of them by leaving them as they are out of the box is generally a mistake. With today’s complex network infrastructures, devices need to be tuned according to your organization’s size and needs, and more often than not, need to be retuned as things change or as you become more used to the tool and more familiar with your needs and requirements.

Neglecting to tune or retune a device can lead to alert overload, which actually makes the job of an incident responder harder instead of easier. Worse still, some products that are not properly tuned end up back on the shelf not being used at all. Unfortunately, some companies that have recently been breached have found out later that one of the tools they had failed to implement correctly could have detected the attack before it was too late. You don’t want to end up in this position. When you purchase a new tool, be sure you take the time to learn how it works and how to make it work for you.

8. Bonus sin!!!!! – Not taking advantage of the fruits of an incident investigation. According to the previously mentioned Ponemon Report, 65 percent of respondents said that threat feeds were one of the most effective tools for helping to detect breaches. Yet 54 percent said they did not collect threat indicators from their own incidents for use in fighting future attacks. Organizations need to realize that the information they glean during an incident investigation is far more valuable than a third-party threat feed in determining which types of attacks their network might experience in the future and being better equipped to handle them.

Even skilled attackers have a tendency to reuse the same attack methods, exploits and even attack infrastructure, because if it ain’t broke, why fix it? Learning from an incident enables organizations to bolster defenses for the future and extract maximum value from their incident response teams.