As a member of several information sharing groups, and as someone who has worked with many different enterprises in the security operations and incident response area, I'd like to discuss the concept of whack-a-mole. Allow me to explain. On any given day, an organization will detect or receive notification regarding multiple infected systems on the network. The organization will then perform incident response accordingly, as we might expect. For those of us that have worked in the field of incident response for a while, we recognize this as a routine part of our day -- just like drinking our morning coffee. As part of our incident response, we will improve our controls to prevent what happened today from happening tomorrow. Makes sense, right? Yes, absolutely -- except for the fact that tomorrow, the attackers will be onto something else that we probably don't have controls in place for. If we take a step back, we see that from this perspective, incident response can begin to feel a bit like the arcade game whack-a-mole. Kill 12 infected systems today and their associated infection vectors, and tomorrow, 15 more will pop up. I'm not suggesting that we abandon this -- incident response absolutely needs to be performed for systems we know are infected. Rather, I'm suggesting that we think about treating the cause of the infections, rather than the symptoms. If we can treat the cause of the infections, we will have far fewer symptoms to treat.
One thing I often see missing from discussions in information sharing groups or from within the enterprise incident response function is root cause identification. In other words, what specifically enabled or facilitated the infection? It's important to remember that root cause and infection vector are two different things. Identifying the infection vector allows us to know how the malicious payload was delivered. Identifying the root cause allows us to understand why the malicious payload succeeded in infecting the system. There is a subtle difference there. Consider the all-too-common example of a drive-by re-direct attack delivering an exploit to a vulnerable version of Java. The infection vector tells us that an unsuspecting user (the innocent bystander) was re-directed to a malicious site that delivered an exploit. If we block the malicious site, there will be another one (or another 1,000) tomorrow. The root cause, on the other hand, tells us that the version of Java on the infected system was vulnerable, and it is upon this that the attackers preyed.
So how can we identify the root cause of infection? In order to identify root cause, we need to re-construct exactly what transpired during the infection to fully understand the sequence of events. In order to fully understand the sequence of events, we need to precisely extract only the relevant network traffic. In order to precisely extract only the relevant traffic, we need to issue precise, targeted, and incisive queries across the network traffic data. In other words, we need to perform network forensics to re-construct and understand what occurred.
What can we do once we identify the root cause? We can work to address it. For example, if vulnerable versions of Java are the root cause of 80% of our malicious code infections, we can work with IT to understand why we are running a vulnerable version of Java and correct that. Think of the ramifications here: By performing network forensics to identify root cause and subsequently addressing the root cause, we could potentially achieve a five-fold decrease in malicious code infections. How do I know this? I've seen it happen with my own eyes inside an enterprise.
As an added benefit, when there are less commodity malicious code infections to respond to, we can focus on other questions that are often overlooked because of lack of time. For example, we might want to analyze our data looking for more sophisticated threats, or perhaps understand if we have particularly unusual traffic on our network that requires additional investigation. There is no shortage of good ways to invest newly liberated human resources.
Root cause analysis is a great thing, unless you like playing whack-a-mole that is.
One thing I often see missing from discussions in information sharing groups or from within the enterprise incident response function is root cause identification. In other words, what specifically enabled or facilitated the infection? It's important to remember that root cause and infection vector are two different things. Identifying the infection vector allows us to know how the malicious payload was delivered. Identifying the root cause allows us to understand why the malicious payload succeeded in infecting the system. There is a subtle difference there. Consider the all-too-common example of a drive-by re-direct attack delivering an exploit to a vulnerable version of Java. The infection vector tells us that an unsuspecting user (the innocent bystander) was re-directed to a malicious site that delivered an exploit. If we block the malicious site, there will be another one (or another 1,000) tomorrow. The root cause, on the other hand, tells us that the version of Java on the infected system was vulnerable, and it is upon this that the attackers preyed.
So how can we identify the root cause of infection? In order to identify root cause, we need to re-construct exactly what transpired during the infection to fully understand the sequence of events. In order to fully understand the sequence of events, we need to precisely extract only the relevant network traffic. In order to precisely extract only the relevant traffic, we need to issue precise, targeted, and incisive queries across the network traffic data. In other words, we need to perform network forensics to re-construct and understand what occurred.
What can we do once we identify the root cause? We can work to address it. For example, if vulnerable versions of Java are the root cause of 80% of our malicious code infections, we can work with IT to understand why we are running a vulnerable version of Java and correct that. Think of the ramifications here: By performing network forensics to identify root cause and subsequently addressing the root cause, we could potentially achieve a five-fold decrease in malicious code infections. How do I know this? I've seen it happen with my own eyes inside an enterprise.
As an added benefit, when there are less commodity malicious code infections to respond to, we can focus on other questions that are often overlooked because of lack of time. For example, we might want to analyze our data looking for more sophisticated threats, or perhaps understand if we have particularly unusual traffic on our network that requires additional investigation. There is no shortage of good ways to invest newly liberated human resources.
Root cause analysis is a great thing, unless you like playing whack-a-mole that is.
No comments:
Post a Comment