Making the case for incident response

2014-03-04

Tim Armstrong

Co3 Systems, USA
Editor: Helen Martin

Abstract

‘There is a shift occurring in the security space around incident response. It’s becoming clear that no organization is completely safe.' Tim Armstrong


Currently, there is a lot of talk of preventative security technologies being all but dead. I disagree, but their use might have changed. It would be a mistake to ignore the recommended best practice of installing anti virus, but it would be an even bigger mistake to stop there. The threat detection market is alive and well with a plethora of advanced technologies that do incredible things, from on-demand virtual sandboxes to advanced APT detection.

The problem is this: in some cases the bad guys will still get in, and the way in which you react once your defences have been breached can make the difference between a security event and a security disaster. It could mean the end of your job, or even the end of your company. A vast amount of time and money is dedicated to trying to keep the bad guys out, but very little is spent on planning for what to do when that defence fails.

Every day, I talk to organizations that have great intentions, but little to no preparation. Making the case for incident response to management can be trying at best. Unless your company has seen the result of a serious incident, both in terms of clean up costs and brand damage, it can be an uphill battle to convince budget holders of the value of incident response tools and techniques. While the continuing catalogue of high profile breaches in the news can only help your case, this is a problem that is not going to go away any time soon.

You can understand why, after so much time, effort and money has been spent on preventative tools, security professionals are hesitant to bring up the need for more tools or resources to deal with the situation when someone defeats their defences. While preventative tools are necessary, make no mistake, someone will get around them. Given enough time and resources on the part of the attacker, no system is 100% secure. We can see this is especially true in the case of state-sponsored malware – these attackers have almost endless resources.

What is not often discussed is how valuable defensive tools can be to the incident response process. Anti virus, IDS, SIEMs and other security tools are essential in recreating an incident timeline. They provide us with information about the attack vector, pathway through the network, and indicators of compromise. In fact, they allow us to make our defences stronger, once we know where to look.

There is a shift occurring in the security space around incident response. It’s becoming clear that no organization is completely safe. Whether you’re a retailer, a manufacturer, a hospital or insurance firm, you will need a plan. You will need a system of record. You will need a repeatable process, and the last thing you want is to be creating that process during the heat of an incident. In fact, you’ll want to tie that incident response process into every tool that helps.

A large part of the incident response process is made up of research, and having the output of quality tools available will shorten your response time. Look at any breach report and you’ll see that the response time is currently measured in months. As an industry, we need to bring that under control – it is the unfortunate truth that the bad guys currently have the upper hand. We are not winning at the gateway, we are not winning on the network, and we are not winning at the endpoint. We must win at incident response. Collecting data during incident response, sharing indicators of compromise, and making it as hard as possible for attackers is our best chance.

I believe that we need to accept that we will all deal with a breach at some point. But if we can act collectively to make attackers less effective, and get rid of the shame of disclosure, we can turn the tide of security to our favour.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.