I had an interesting discussion with a highly educated and self-proclaimed computer-literate professional on the process to dedupe emails.  The interesting part is that I couldn’t believe what I was hearing about his process on how to dedupe files.

https://www.merriam-webster.com/dictionary/self-taught

I’ll sanitize this story to protect the guilty.  So, here is the scenario.

Step 1: Find exact duplicates in a batch of 3,000 emails (.msg format)

That’s it. No step 2 or 3 or 4. Simply find the duplicate emails from a folder of emails.

I know what you are thinking; that you would just drop the files into an app like HashMyFiles (https://www.nirsoft.net/utils/hash_my_files.html), or maybe even get fancy by creating a case in your favorite forensic suite and adding the emails as evidence items, and output a formal report which would add maybe 5 or 10 minutes to the process.

Either way, the total processing time to find the exact duplicates would take about a minute.  Here is where it gets a little interesting. The process that was described to me was way more elaborate. It went something like this:

1. Import the emails into MS Outlook.
2. Print the inbox.
3. Compare the titles of the printed inbox against emails in a folder.
4. Export the emails to a spreadsheet.
5. Use Excel to remove duplicates.
6. Visually compare each email in the spreadsheet against the emails in a folder.

The time spent deduping emails this way took 60 hours, and strangely, the IT pro was bragging about how long it took.

Speed test!

This is what it looks like when compared to using a free file hashing utility.

This would be fine if there were no resources available to know otherwise, you had no training or education in technology, you were physically unable to ask anyone for advice, and you had never been exposed to file hashing before. However, in this instance, not a single resource was used. The IT professional didn’t use anything that was taught formally in either the BS or MS degrees, nor from any of the  CompTia courses completed, didn’t ask anyone how to do this, and didn’t even search the Internet to see how to find duplicate files. That might normally be ok, but not here.

The problem is that this IT pro intentionally didn’t ask for help or search online for a process and boasted that “this is the way we do it in this field do it; by being self-taught.” With that statement, I figured that if one person thinks this is the right way, maybe others do too, therefore, this post needs to be written.

There are many right ways to self-learn. This was not one of them.

I am a big believer in self-learning. We learn better when we learn information on our own. It is as if we discovered the information, therefore we “own” it and can be proud of it. But there is a line between self-learning and simply doing it wrong, and worse, doing it wrong on purpose.

Being self-taught means that you first look for the answers (or the processes) that others have discovered.  You can modify and improve upon processes that exist, but you use these as a starting point of self-teaching.

An analogy

I once built a motorcycle from the frame up. I had no idea of what I was getting into.  This was years before the Internet, so my only resources included a friend that knew a lot about motorcycles and my local library. It took me a summer to build the bike, but I could not have done it without help from someone who knew what he was doing and the books that I checked out of the library.

Had I not asked for help or researched in a stack of manuals, I would have ended up with boxes of parts for a garage sale. Instead, I had a bike that I fully built myself.

Self-taught means that you learned outside a classroom. It means that you used resources available to learn, such as books, Internet searches, and asking others to show you.  Of course, being self-taught includes practice and experimentation, but even that requires some resources as a baseline of where to start.

Excel

It might not be a stretch to say that practically everyone in DFIR is competent with spreadsheets. Excel is a flexible and necessary tool in DFIR to view, analyze, and display data.  But just because you dump data in Excel does not mean that you are using it correctly.

In the example of dumping emails into a spreadsheet to find duplicates when there are probably dozens of applications (free, open-source, and commercial) that can do this task easier and without error, using a spreadsheet because it seemed like the best way goes directly against the meaning of being self-taught.  This would be the same as me buying every nut, bolt, and part of a motorcycle and trying to put it together blindly in order for me to be self-taught in building a motorcycle.

So now, when I hear that someone is self-taught, I have to dig a little deeper to get the details. If I hear that self-taught involved deep research, replicating what others have done, and improving upon what others have done, only then will I believe that the person was self-taught. To do otherwise is to waste time and do the direct opposite of learning.

Self-teaching advocate

Once you become competent in any field, self-learning is what you do for the rest of your career. You will always “self-learn” a process new to you by seeing someone else do it or write about it. Then you replicate it. Eventually, you improve upon it. And if you share it, it will further be improved upon by others.  If you are lucky, you have co-workers who share what they learned with each other, which takes team competence to much higher levels.

For managers, be aware of those who rather learn absolutely everything on their own without some sort of process (research > ask > replicate > improve). Blindly trying anything is likely wasting time and making things worse. It will be a net negative and can border intentional incompetence.

For practitioners, “trying something new” is all well and good, but before spending 60 hours on something, spend 6 minutes to see if what you want to do has already been done before. If it has, then you can replicate it. Use that 59 hours and 54 minutes of time you just saved to improve upon your replicated process.

Leaps and bounds

Do you ever wonder why some in DFIR jump so fast and far ahead of others? It is not usually because they have a higher IQ.  They are smarter tho. They are smarter in the fact that they know to RTFM (aka: research first). With a firm foundation, their experimentation starts at a higher level and propels them ahead as if having booster rockets.

Those who start from scratch and intentionally choose not to do even the barest minimal research not only have no foundation of which to build, but will learn the wrong way to do DFIR things.  This is not only not moving forward, it is moving backward.

The deduping emails story

The end result of the story of this deduping emails is that the IT pro was proud of the time spent as it was an “exhaustive effort”.  Yet, the emails were not deduped because admittedly, the IT pro admitted that he was unsure of some emails being exact duplicates or not, so they were produced anyway (no email was even hashed).  All of this wasted time could have been avoided with a phone call, an ask of someone else in the IT shop, or just one Internet search. Instead, we have self-taught incompetence that wasted weeks of work with a defective work product.

If you want to be entertained, block out 5 minutes of your time at 9am (PDT) on Friday, June 11^th, to see how something so simple as asking for public records turned into a major cluster. I’ll be giving comments in an Open Public Meeting about a lawsuit in which I asked for some public records, they were all not provided, and some have been destroyed.

https://www.norcom.org/event/governing-board-meeting-2-2021-06-11/2021-06-11/

So this team of lawyers has been hammering away at me…

I’ll get into the details of the records in my public comments, but some of the records include a workplace so bad that one employee committed suicide over it, another contemplated suicide, another suffers from PTSD from it, and an independent evaluation determined this workplace to be so bad that he described it as  “workplace violence”.   Then there are the non-disclosure agreements of up to $150,000 of hush money to public employees so that they don't disclose how bad it is! It is as whacky as it sounds.

For simply requesting public records, which anyone in any city, county, or state in the US can legally do, I somehow ended up with a team of attorneys against me causing nothing but obstruction.

Forensics?

What does this have to do with forensics or anything related? That’s a good question, and the answer is quite a bit.  The lessons that I have learned in this case can benefit you in forensics, ediscovery, or even if you want to request public records yourself if there is something of public interest that you are aware of. I’ll talk about that later, but for now, you might want to tune in to enjoy the fireworks in the virtual public meeting this Friday at 9am (PDT)!

Schedule:

0900 Meeting starts.

0902 I speak.

0905 I'm done.

The technical piece of DFIR is not difficult. If you know what you are looking for, and you know how to find it, the work is actually easy. I do not say this to mean that anyone off the street can do this work without training or education. I mean this as in once you are technically competent, the actual work allows you to excel even more so, technically, because it becomes easier.  But this is where a bottleneck holds up progress in the DFIR cycle. The presentation phase of DFIR work is the only piece that turns the most competently proficient forensicator into a little kitten.

The Too Long: Didn’t Read version of this post

If you can’t effectively tell the story of your DFIR work, your DFIR work doesn’t matter, no matter how good you are.

Now for the important details

Since I am a visual learner, colorful infographics and flowcharts make it easy for me to understand a concept. In DFIR, we have lots of these, for which I am grateful. Cycles of this, that, and the other, all showing easy-to-follow workflows.

One problem with an infographic is that the information is generally very minimal. For DFIR, we have many visuals that broadly display a “Cycle of DFIR” as:

1. Create a plan of the work
2. Do the work
3. Evaluate the work
4. Repeat

This is good. Practically every infographic related to DFIR, or the Intelligence/investigative cycles give varying visuals of Wash > Rinse > Repeat.  The one-piece that I see little on is that of the importance of being just competent in the presentation as in technical. And eventually, the presentation is the end of an investigation or response. No case is never-ending. Some are longer than others, but eventually, there is an end of some sort.

Who should be chosen as the best person to present a finding or case?

Every person on your team must be proficient to some extent in the presentation of their interpretation of data. Data can be a single artifact or the entirety of an incident/investigation, and everything in between. Not being able to effectively present evidence nearly negates doing any work at all. Let me say that again: If you can’t tell the story of what you did, then nothing you did matters.

You may have done the most awesomeness of DFIR work in the world, but if you can’t relay the story of that work, it was for naught. This applies to any work. If a police officer makes an arrest of the most violent felon in the community but cannot effectively present the facts of the investigation to a court, then the violent offender might not be convicted and go free. If a forensic analyst finds the key artifact on a storage device but is not able to describe the why and how of that artifact, then that artifact is meaningless along with the effort to find it.

The reason that ‘we’ do not take presentation seriously is that ‘we’ understand what we did. We understand what happened. And we expect everyone else to know exactly what we did without us having to explain ourselves. This is partly due to ego (see my post on ego in DFIR).

Presentation Training

Where are the courses in presentation? How about courses in court testimony? Sure, I have seen one or two over the past decade, but nothing as compared to the technical courses available. Not even close. Yet, every technical training course in the world is useless if the presentation is not up to the same level of competence. It is one thing for a policy to state, “Evaluate the actions taken” and quite another to train and give someone the experience in relaying technical information to another.

The newest and most junior person on a team must be able to present their work to their supervisor or trainer. Expect the presentations to be better over time, and this is up to the seniors to critique the juniors.  An attorney-friend of mine always preferences his questions to me with, “Forgive me, but to make sure I understand what you are going to say, pretend that I am a fifth-grader.” My friend-the-attorney is on the genius level of IQ and knowledge, but he has his ego under control enough to make sure he is going to understand what is coming.

Report writing is presentation?

I’ve not met anyone who loved writing reports. I have seen some do more work to get out of writing a report than the time it would have taken to quickly knock out a sheet of paper with words on it. Report writing is a presentation and should be taken just as seriously as speaking in front of 500 people or the CEO of your organization.

Report writing is also a fantastic training opportunity for junior DFIRers. If someone can effectively get the words on paper, they most likely will be able to get the spoken words out as well. Both of these take practice. It will never be perfect. But it will improve over time. And it will keep improving as long as the practice and experience continue.

Are you in charge?

Train your team to present! You will benefit your team more than you can imagine with just a few minutes at a time. Have a team member write up a half-page of an artifact (or anything) and explain it to everyone. Be sure that every person is verbally engaged in debriefs and evaluations. Encourage and require every person to present their work, their opinion, and their suggestions in both a written and spoken format.

Your team will grow by leaps and bounds when every person can articulate their reasoning, their opinions, their findings, and their conclusions. If there is one person that cannot do this, you have a weak link that will minimize the work of the team, regardless of how technically competent that person may be.

Motivating your team

Sometimes you may have a team member that does not see the importance of being able to explain effectively. Expect it. They simply don’t care that someone else doesn’t get it. This is your weak link and one way to motivate someone who doesn’t want to present their story (ie, their work), is to require it. I’ve not met good senior leadership who wouldn’t take a few minutes out of their day to help their organization, specifically helping someone in the organization that may need it. With this, I have had juniors who just didn’t get the importance, ultimately get the importance when being told to explain their work to the ‘big boss’ and that the ‘big boss’ better be able to understand the story in less than 2 minutes. Motivation achieved!

Becoming a better storyteller

Speak in front of others. Speak some more. Then when you think you got the hang of it. Keep speaking. If you happen to throw up occasionally, you are on the right track. (see my post on Puking in DFIR). I am speaking at a few events in April, May, and later this year. All are virtual, but the experiences of presenting are just as important to me as the information that I hope to convey to others. There is no point in your career where you don’t have to practice presentation skills because you obtained competence. Competence is like a sinking boat. Once you stop scooping out the water of a sinking boat, it will sink. Same with presenting DFIR information: once you stop doing it, your competence will wane.

When does presentation happen?

Ultimately, at least with a legal or internal investigation, there is a final presentation. This is the last chance to fully tell the story of your analysis. The final presentation should be a culmination of all the other presentations that should have occurred during the investigation to team members.

There are intermediate points in any analysis where periodic updates are given, questions asked, course directions changed, and leads followed. Use each of these opportunities as experience in storytelling as you adjust the story to the varying audiences you have. The same story told to your team will need to be told much differently when told to decision-makers who are outside of your technical world. These are valuable experiences that teach you how to change the pace, flow, and language based on your audience when telling the same story. This is a skill that can’t be bought and more importantly, can’t be faked.

About that motivation

If you are like me, whenever you get a task assigned, or volunteer to do something, tension starts. You want to do a perfect job. You don’t want to make any mistakes. And you over prepare to expect the worst.  This is what happens when you agree to present on a topic. Hours to prepare over weeks for a short presentation. Then checking your presentation. Then research again to make sure nothing changed since the last time you checked your information.

In addition to re-learning the topic, however, is that the experience of presenting will make sure that your next presentation will be even better. So, every presentation that you see someone do, keep in mind that that presentation was probably better than the last one, but won’t be as good as the next one.

I'll be at @NCCC_MA's cyber crime conference (virtually) on April 27.https://t.co/AEmFaRyMEb #DFIR pic.twitter.com/0D7ya0jFuI

— Brett Shavers 🙄 (@Brett_Shavers) April 16, 2021

Come join me and many others this year at the @MagnetForensics
Virtual Summit #MVS2021 #DFIR.

Registration can be found below & YES it's FREE!https://t.co/zECTwOkAp9 pic.twitter.com/IOOXdKWtRV

— Brett Shavers 🙄 (@Brett_Shavers) April 10, 2021

To those who helped me

I will openly admit that I have held some serious grudges in the past with team leaders. I distinctly remember one of my squad leaders in the Marines who ordered me to describe a field mission to my section leader because I didn't put the effort to explain it well enough to my squad as asked.  To be honest, I put no effort in it to my squad as I thought it was a waste of time.  After all, we had been planning that thing all day together....we all knew what we were going to do. That was a painful lesson to learn, but was needed. I used the same lesson many years into my law enforcement career. For those who helped me comprehend the importance of telling a story, I hope to repay that patience of dealing with me with my continuing to help others learn the same lesson.

Tell the story of your work so that it is understood. Decisions are made from it. Your competence is judged by it. And depending upon your job, you could have someone's life, liberty, or livihood hanging on the balance of your spoken words.