Correlation isn't the same thing as causation. Forensics professionals often seem to forget that when they deal with incident data. Just because an event occurred and malware was found on a machine that could have caused the event doesn't mean the malware caused the event. Is there a correlation? Sure. Is this enough to establish causation, nope.
I semi-regularly tweet images of spurious correlations to remind my fellow DFIR brethren that correlation is not the same as causation. These are so ridiculous that they paint a powerful picture that correlation and causation could not be the same thing.
But why do we ever assert that correlation and causation are the same? I think the root of this is a lack of knowledge. This in turn leads to logical fallacies in our thinking. We can fix this correlation/causation confusion by learning more about incident response. How do we get more data? What data is actually useful in investigating the incident? If I wanted to find out more, where should I look? What does normal look like in my environment?
One of my biggest suggestions for overcoming these issues in IR is to make sure you have access to a reverse engineer. Using black magic and ritual sacrifices*, reverse engineers can help alleviate confusion about what capabilities a piece of malware actually has. I frequently read in reports that "the malware is using code injection." Why, I ask? "Because we checked for normal persistence and didn't find anything." This is obviously not a strong connection. In fact, it's REALLY weak. Absence of one thing is not proof of another. Period.
* Often, reverse engineering involves neither of these things.
Reverse engineers can also benefit organizations by helping to fully decode malware C2. I can't tell you the number of reportable HIPAA incidents I've seen staved off by knowing specifically what an attacker did (and exfiltrated) from a network. Full packet capture is great, but it can't be fully used without good C2 analysis (which requires a reverse engineer).
I'll close my soapbox about reverse engineers and say that having a reverse engineer available is a game changer for many organizations. Reverse engineering answers questions that no other tool or capability can. If your team is growing and doesn't yet have enough work for a full time reverse engineer, you can always put one on retainer from a reputable firm. If you need help, talk to Rendition Infosec, we have reverse engineers that would be happy to maximize your return on investment and change "we think this is what happened" to "we know this is what happened."
I semi-regularly tweet images of spurious correlations to remind my fellow DFIR brethren that correlation is not the same as causation. These are so ridiculous that they paint a powerful picture that correlation and causation could not be the same thing.
But why do we ever assert that correlation and causation are the same? I think the root of this is a lack of knowledge. This in turn leads to logical fallacies in our thinking. We can fix this correlation/causation confusion by learning more about incident response. How do we get more data? What data is actually useful in investigating the incident? If I wanted to find out more, where should I look? What does normal look like in my environment?
One of my biggest suggestions for overcoming these issues in IR is to make sure you have access to a reverse engineer. Using black magic and ritual sacrifices*, reverse engineers can help alleviate confusion about what capabilities a piece of malware actually has. I frequently read in reports that "the malware is using code injection." Why, I ask? "Because we checked for normal persistence and didn't find anything." This is obviously not a strong connection. In fact, it's REALLY weak. Absence of one thing is not proof of another. Period.
* Often, reverse engineering involves neither of these things.
Reverse engineers can also benefit organizations by helping to fully decode malware C2. I can't tell you the number of reportable HIPAA incidents I've seen staved off by knowing specifically what an attacker did (and exfiltrated) from a network. Full packet capture is great, but it can't be fully used without good C2 analysis (which requires a reverse engineer).
I'll close my soapbox about reverse engineers and say that having a reverse engineer available is a game changer for many organizations. Reverse engineering answers questions that no other tool or capability can. If your team is growing and doesn't yet have enough work for a full time reverse engineer, you can always put one on retainer from a reputable firm. If you need help, talk to Rendition Infosec, we have reverse engineers that would be happy to maximize your return on investment and change "we think this is what happened" to "we know this is what happened."
No comments:
New comments are not allowed.