As a follow-on to my previous post with this title, I wanted to keep the story going; in fact, there are likely to be several more posts in this series, so stay tuned.
And hey, I’m not the only one sharing my journey! Check out Josh’s blog, particularly his recent post about how he broke into cybersecurity! I might have been drawn to Josh’s post because, like me, he’s a former Marine, although I can say that I was in the Corps back before computers were in common usage, back when we used radios that were 1950s tech, built in the 1970s. We didn’t cross paths…I was off of active duty 12 yrs before Josh went to boot camp, but even so, there’s some commonality in shared traditions and experiences.
Okay…back to it!
Programming
Programming is talked about a great deal within the industry, particularly within DFIR. Some folks will say that you absolutely need to be able to program, and even have very strong feelings about the language of choice, and others will do just fine with basic shell scripting and batch files. I’ve met some folks who are really great programmers, coming up with either individual projects, or more team or community based ones, like Volatility. A lot of the programming very often seems specialized, like HindSight, while other projects and contributions might be a bit more general. Even so, some of the absolute best DFIR analysts I’ve ever worked with have had minimal programming capabilities, not going much beyond shell scripting and regexes.
As a result, when it comes to programming, your mileage may vary. I will say this, though…the experience of programming, in whichever language or framework you opt for, has the benefit of helping you understand how to break things down into manageable “chunks”. Whether you’re writing some code to manage logs, or you’re leading an IR engagement, you’ll realize that to get from A to Z, you first have to get from A to B, then to C, and then to D, and so on. Accomplishing a task by writing code forces you to approach the problem in that manner, and as such, has benefits outside of just getting the coding task completed.
I started programming BASIC on a MacIIe in the early ’80s, and then did some small programming tasks on a Timex-Sinclair 1000; “small” because saving programs to or loading them from a tape recorder, or copying them out of a magazine, was a whole new level of hell. In high school, I took AP Computer Science the first year that it was offered; the course used Pascal as the language of choice, and when I got to college, it was back to BASIC on TRS-80 systems. When I got to graduate school (mid-’90s), it was MatLab, a small amount of C and some M68000 assembly, and then Java. At one point, just as I was leaving active duty, I had a small consulting gig teaching Java programming to a team at a business.
After I moved to the private sector, I taught myself Perl, initially because the network engineers were looking for someone to join their team with that skillset. I later ran across Dave Roth’s work, and found some really fantastic use for his modules, bought his book, and even got in touch with him directly. I continued to stick with Perl, as at the time, it was the only language that had a functioning module for accessing offline Registry hives. I’d started writing my own module for this, but ran across James Macfarlane’s module and figure, why not?
The Roles
My first role out of the military was at a small defense contracting firm, and that really didn’t work out. After a short stay, I moved on to Trident Data Systems; these folks were another defense contractor, with offices in San Antonio, TX, and LA. As it turned out, I ended up on the commercial team, which was great. We did vulnerability assessments, and because we had a really good sales guy, that’s what we did, and as a team, we got really good at it. Every now and then, something a bit different would come along, like a pen test, but for the most part, we had a lot of work in vuln assessments.
My boss in this jo was a retired Army Colonel; right off the bat, he told me that we were using ISS’s Internet Scanner product, and that it would probably take about 2 – 3 years of running the tool regularly to really understand what it was doing. I thought he was right…there was a pretty, and pretty complicated GUI, and if you didn’t turn off some of the defaults, like the check of the net send “vulnerability”, you’d end up sending a message to every desktop, creating a headache for the local admin.
As it turned out, within about 6 months, I started using those Perl skills I’d developed, along with Dave Roth’s modules, to begin writing a replacement for Internet Scanner commercial product. The ISS product was a black box…you pushed a button, and it gave you answers back. Only we didn’t know what the product was “looking at”, nor how it was determining that something was “vulnerable”. As we began to look closer and with a lot of digging into the MS KnowledgeBase, we began to figure out what the product was checking, and we started to see that some of the answers were wrong; one of the biggest issues we ran into was when the tool told us that the AutoAdminLogon functionality was “enabled” on 21 systems in one particular office, and it turned out that it was only truly enabled on one system. To make things worse, the customer knew that only one system had the functionality enabled; it had previously been enabled on the other 20 systems, but the customer had knowingly and painstakingly disabled it. So, it was a good thing that we were running the ISS product side-by-side with the new tool we were developing, and checking the work.
This was one of the first moments in my private sector career that really illustrated the need to understand, to really know, what your tools were doing and how they were doing it. This led to other moments throughout the ensuing 25+ years, as this lesson was continually revisited, again and again.
Source: Read MoreÂ