Knowledge Retention & Sharing in DF/IR

I had an opportunity a bit ago to engage with three other folks within the industry, all at the same time, and all of us from varied backgrounds. We had some similarities in our backgrounds, and some overlaps or near-misses in our experiences and employment, but we were all very different folks in the same industry. In a lot of ways, this is what made this a very powerful meeting and discussion. 

We had the meeting because these guys had graciously taken the time out of their day to provide me with a demo of an upcoming product, and following the demo, our conversation leaned toward how this product provided various "skills" that would elevate analysts, providing new, junior, less experienced analysts with the ability to really produce very quickly, while also ideally providing a greatly accelerated growth path. As a result of the conversation, or more accurately, where we left off, I'd like to share some thoughts…

When I started in DF/IR, there was little in the way of publicly available training. Yes, there were vendor certification courses; I availed myself of the EnCase 3.0 Intro course in 1999, provided thru Guidance Software. However, these courses were "how to use the tool" courses, not "what happens under the hood" nor "why you should do certain things" courses. There was no real "why" for the "how"; they'd show us the "how" for something, but there was not real "why" associated with it. "Why would I want to perform that action?" was a question that wasn't really addressed. Even the instructor, who had used the application extensively, had a lot of stories behind the work he'd done, but across the 5 days of the course, there was nothing about, "…this is why you would want to take this action, and here's what you do with the output…". 

There was nothing shared in the way of investigative processes. 

When I started doing DF/IR consulting with ISS in 2006, I was provided with a bunch of equipment…laptops, write-blockers, dongles…and software, with the expectation that I'd "hit the ground running". Like most folks, I had my hiccups along the way, but I figured it out…I had to, as there was no one else on the team providing direction. Yes, we had processes and procedures, and my manager did a lot to engage quite often and assist, but when I was on-site, and even afterward when I'd returned to the office and was doing analysis, I was pretty much on my own. There was no repository of tips, tricks, or lessons learned from the more seasoned members of the team, and there was no internal process on the "team" for recording these sorts of things. 

There was nothing shared in the way of investigative processes. 

And I continued to see this throughout my career, and I worked to change it. After IBM purchased ISS, and our team (then referred to as the "IBM ISS X-Force ERS team") began performing PCI forensic investigations, the PCI Council (re: Visa) required us to perform a series of searches for every case, providing the indicators in a PDF document. Chris Pogue and I wanted to push these investigations (because of the timeframes imposed) toward consistency, so we created condition files for the other certified analysts on our team, which, along with the standard procedure for searching acquired images for credit card numbers (CCNs), as well as the reporting template that Chris put together (he was our team's PCI Council liaison at the time…), we worked hard to provide as much automation to the process as we could. 

We were sharing investigative processes, in the best manner that we could. While we documented these processes, and operationalized them where we could, all of this still required some intentional actions to be taken by the analysts. 

During this time, we ran into another issue. We had to search acquired images for CCNs, and the EnScript we were using relied on the built-in function isValidCreditCard(). For the most part, this worked great, until we ran into a case where JCB and Discover credit cards were processed; the built-in function did not recognize either of these brands as "valid". Chris and I worked together, along with Lance Mueller, to put together an EnScript that overwrote the built-in function and covered all of the valid brands. We did extensive testing, and then provided the updated script along with a tutorial session as to "why" we had to do this.

During the time we were on the team together, Chris and I, and several others, continued this kind of work…learning something, testing it, and then sharing it to not only expand the knowledge of the team, but to also get the process or tool (or combination) tested against scenarios we hadn't yet thought of or experienced.

We were taking individual knowledge and skills, and transitioning them through "tribal" knowledge, and moving beyond "corporate" knowledge into operationalizing the skills as much as we could. The unfortunate reality is that throughout my time in the industry, in the vast majority of instances, we don't move

Read the original article: