So when we talk about incidents here at Rapid7, we may be referring to something small, so common threat commodity malware impacting a system. It may be as large as a targeted attack going into a client environment for the purposes of financial gain, economic espionage, those sorts of things.
If we look at some of the statistics associated with breaches in 2014, we can see that the average time from a breach occurring to detection is 205 days. That's a substantial amount of time. And we're looking at 1,367 breaches according to Verizon. And I can tell you, that number is pretty low. In reality, that's likely a much, much higher number in notifications or breaches that have not been publicly released.
So we'll talk about how we identify incidents and how we determine whether or not we need to respond to them. So initially, we'll talk about detection and notification. We don't have an incident if we don't know about it. We can't respond to an incident if we don't know about it. So detection may come in from a client's security devices that exist within their environment, their anti-virus, their IPS, etc. It may come from an external notification. We're looking at approximately 69% of incidents being reported by third parties at this point. So it's usually going to be an outside notification. When we hear about these, we want to go in and to try to get some context about what we're looking at, what sort of intel we need to bring with us. And I'll walk through that.
So it's very important when we respond to an incident to have a very well-defined analysis methodology. Depending on the type of attack, we may need to shift how we perform our analysis, and I'll talk you through that. If we're looking at a common threat attack, something that is typically going to be picked up by anti-virus or is not necessarily targeted for an organization, we're going to look for the method that that malware used to get into the environment. Was this a drive-by attack where there was an exploit kit and someone opportunistically went to a site? Or was there a fishing campaign that impacted users and got somebody to go through and click on a link? Depends on how we are going to respond.
If we're looking at a targeted attack, we get a little more advanced. We're going to want to know who those attackers are as best we can determine and what mechanisms they're using to target the environment, how they're determining what users to target, or where to position their malware, and what they're aiming to do from there.
So it becomes very important as you're going through an incident and you're picking up these little pieces to try to determine whether or not you're looking at a targeted attack, or some automated malware, or common threat malware, to gather all of that intelligence into a centralized location. So that's going to be the type of malware that is used, the user accounts that are used, command and control infrastructure, as well as any exploits that you can determine, whether it be something like Flash or other browser-based extensions. And you're going to want to be able to take the intel that you gather from affected systems and use that to scope. You'll take that data, put it into your anti-virus systems, your IDS, go through your SIM and look for some of those indicators or compromises so that you can determine whether or not it's an isolated incident or if it's something much greater, something you need to bring in additional responders to review.
Once you have an understanding of the affected systems, you'll want to go into remediation. So when we perform remediation, we try to take a holistic approach. We want to go and grab all of those impacted systems at one time, whether or not we're looking at common threat malware or a targeted attack, to ensure that we're able to eradicate everything at the same time and avoid any possibility of that attack spreading. And it's important to make that distinction and ensure that you have all those systems when you're scoping and taking that intel and reapplying it.
And lastly, communicating what has occurred. If there is a large-scale remediation and you need to pull your company offline, or you need to rebuild a substantial amount of systems and critical business systems, you're going to need to communicate that to some of your employees or all of your employees. Use it as education to avoid these sorts of things happening again or increase, decrease response time, as well as public communication. If there was a PII involved or there were financial information involved, you may need to go through a regulatory agency to ensure that you're following all of the guidelines that you must follow.
And as we talk about this, there's a fairly simplified approach, but there's a lot of detail and a lot of meticulous practice that goes into performing incident response. So depending on the type of breach that you're responding to, you need to evaluate whether you have staff that have the appropriate skill sets, and training, budget, and these types of things you'll need in order to build out an incident response team who can respond to attacks ranging from something very simple to something very complex. Or evaluate whether or not you need to reach out to an independent consulting firm or a third party to come in and either perform that incident response or perform staff augmentation and training.
That is a brief overview of incident response and incident response methodology. Thank you for watching this week's Whiteboard Wednesday. Talk to you next week.
