Consistency

I’ve worked a lot of places over the years, all for varying lengths of time. While this worked against me in the early days, with potential employers wondering why I didn’t stay longer at my previous employer, and wondering how long I’d potentially stay with them, this became less of an issue later in my career. 

During my career in the private sector, I’ve run vulnerability assessments, and spent over 26 yrs in digital forensics and incident response, some in FTE roles, and much more in consultant roles. 

In 2006, I started in a DFIR consulting role at ISS, which evolved 6 months later when the company purchase by IBM was completed. I then became a “plank owner” of the IBM ISS X-Force ERS team, one of the original members of the team, even before we expanded. When I started, I was provided with a complete outfitting of equipment, including (but not limited to) write-blockers, cabling, laptops, and dongles for EnCase 4.22, EnCase 6.19, and FTK. As our team grew in size, everyone received similar (albeit updated, in some cases) equipment. When I started at ISS, I was one of 4 responders, and we each did our own thing when it came to analysis. There was little in the way of cross-pollination, sharing of experiences, etc. As the new team began to grow, it was a bit before some of us saw the need for consistency across the team.

In 2007, members of our team became certified to conduct PCI forensic investigations, which were subject to very stringent (and somewhat arbitrary) timelines. As part of this, Chris and I developed a process that we shared with all of the team members, using EnCase to conduct all of the searches required by Visa (driving the whole PCI effort at the time), not just the mandatory the credit card number searches. The idea was, in part, to remove the need for individual analysts to have to try to figure out what to do, by giving them a common, documented step-by-step process for completing all of the required activities in a consistent manner. This way, if issues arose, they were easier to troubleshoot. More importantly, having a consistent process meant that there was less room for guesswork, and we had confidence that as long as the process was followed, we’d be able to meet our obligations regarding timeliness. This also left more time for analysts to uncover things like initial access, and other pertinent information, because the guesswork of “what to do next” in order to meet Visa’s requirements was no longer something analysts needed to concern themselves with.

In 2013, I started at <company>, on a team that was already well-established. This team was responsible for developing and actively employing the EDR technology used by the company, and this was used to drastically reduce the scoping of “targeted threat actor” incidents, at which point, triage or full forensics of specific systems could take place. For example, one incident involved 15,000 endpoints in a global infrastructure, and we found that the threat actor had “touched” 8 of the systems, and “been on” only 2. Few members of the team, at the time, had actual hands-on experience with truly in-depth DF work, and there was very little in the way of sharing of tools, techniques, and processes between analysts. There was no documentation, little cross-pollination, and some issues with consistency in the use of the analysis framework. Every now and then, someone might share a tidbit here and there, but different analysts had different ways of using the framework. For example, one analyst might tag something they hadn’t seen before as “unknown”, where another would tag it as definitely “malicious”, with the thought of going back and researching those items a bit more…and often, they didn’t. They remained marked the way they were, so when those same indicators showed up on another engagement for another analyst, it was pretty much guaranteed that you’d see a mix of “unknown”, “malicious”, and “benign” from previous engagements.

In 2020, I started at a DF/IR consulting company, and spent my first week on-boarding at headquarters. During that time, I made an effort to start engaging with D

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.