I’m big on attribution in crimes. It is my personality and attitude, which you can probably tell from the things I write and say (and have done). With that, I completely understand that the “IR” in “DFIR” is not primarily about attribution, if it ever is. The IR (Incident Response) is a different job than the DF (Digital Forensics), but still related, like cousins.
In a pure digital forensics (ie. legal) matter, attribution is key. Attribution is the goal. Attribution is what you are working towards. Otherwise, it is not literally forensics, but only mechanically forensics, in that you may be performing the same mechanics as with forensic processes and methods, but if you aren’t looking to pin a crime on the suspect in a legal matter, it is not really forensics by definition.
With IR, pinning the crime/breach on the criminal or nation-state isn’t the primary mission unless you work at one of the alphabet-soup government agencies. But, IR is no less important than DF, even as the goals are generally different. With DF, the work is targeted to give justice to a victim through a legal process. With IR, the goal is usually to quell the panic of data spewing from the network like a busted fire hydrant in the middle of summer. Attribution is maybe an afterthought, at best. Stopping the pain is the priority.
But here I go splitting a hair with attribution in IR work….
When you do IR work (outside of the alphabet-soup government agencies), sometimes you should think about attribution in what you are doing. In fact, sometimes you must think about it because you might not be working a pure IR job. You might be deep into the legal arena!
Fairly recently, I was asked to “look at” an employee’s email account for "hacking". Sure enough, someone other than the account holder had been in the account. Emails had been sent out from the employee’s account and some emails posted online by way of screenshots. Without getting into the weeds of what was happening, it clearly looked like internal drama in the organization.
The client/CEO wanted it stopped, but did not care about who did it because, “Nothing you can do about it if China is doing it.” This was the advice from IT to the CEO. Hackers can’t get caught, so don’t waste money on it when you can just prevent it from happening again. However, just by looking at the content of the emails that were being sent out and posted online, it was clearly an insider job or someone related to the employee in some manner. Seriously. It was so blatantly obvious that the employee was targeted and that most likely, it was probably another employee just by a quick glance of how it was happening. I gave an estimate of a day to be able to find out who it was, and still, the solution was to stop it from happening and not worry about catching the culprit.
My point is that sometimes you can catch the person because maybe the suspect is not in Iran or China or Russia or Timbuktu. Maybe s/he is in the next cubicle. In this example, the suspect was in IT, which took me a half day to figure out, without even having to skip lunch. End result was that everyone happy (the in-house attorney, the employee and the CEO). Except the IT person. He was not happy. But everyone else was.
Most anyone working in IR can fairly accurately tell where the hacks* come from. Maybe not to a specific person or nation-state, but at least be able to gauge whether or not the suspect is in the same building or down the street or related to the organization (generally!). There is nothing wrong with advising a client that although you can certainly stop the pain of a hack* (see the below definition..), you may also be able to solve a problem that is just as important which may actually have a positive ROI beyond dollars spent.
This is just an example of when a pure IR engagement can turn into pure DF gig, simply because IR can see typically be able to determine that not only can you identify the suspect, but that you should because in a case like this, the victim will keep being victimized by someone that can be caught and brought to justice.
*hacks, as in whatever you want to call unauthorized computer access.