When I first started doing this, it was an informal thing involving a white board and shoulder surfing while I did stuff. By the time I left my last team I had much more structure around the orientation of these new team members. But I'd like to go back six years.
I was training a new teammate. He had no exposure to incident response or incident detection (Both of which I mentally lump together and call "Defense"). I had no formal training in defense, I relied on "just in time" training, sometimes called "On the job" training. Because of that, I was pretty lousy at explaining things.
I focused on the tools I used and how to use them.
I explained when and why I jumped from one tool to another.
Or at least I tried to. How do you explain your mental processes, your range of experience? Without good introspection and clarity you will have an extremely difficult time explaining "Why". The "What" and "How" on the other hand are easy and what inevitably the discussion turned to.
Too many times, the answer to the "Why" resulted in a one word response of "Because" with no elaboration. It was in my head but I couldn't express it intelligently.
But I now have a partial explanation on this. It was my assumption as a responder that my goal is to identify the scope of the incident. A fair assumption, as that is what any book or whitepaper will tell you.
And it's both wrong and right.
The goal is absolutely to identify the scope. Proper ID of the scope is an outcome of your investigation. But as a seasoned incident response analyst, it's not actually the process you follow. You consciously are asking "Is this out of scope? Is this just a symptom or the cause? What about this thing over here?"
This line of questioning and the reasons I knew when to switch tools or analytic techniques was not methodically identifying the scope of the breach. The line of questioning and techniques I was using was instead answering an implied question of
What can I find that proves the scope of this breach isn't larger than what I believe it to be?There's a bit of nuance there, but when it's practically applied it makes a large difference. My new teammate was not instinctively asking this question in his head and I was at a loss to convey the concept. He was biased in assuming the data he was presented with did indeed identify the scope of the breach. And he was right; however the data did not proof the breach was contained to what he was looking at.
Proving the scope of a breach is at a particular size doesn't actually prove anything other than it's existence. On the other hand, the ability to prove something is false (that is, the breach isn't bigger) is provable. This is a direct application of Popper's falsifiability concept.
