SANS DFIR Summit Follow-up
I attended a number of presentations while at the summit and I thought I'd share my thoughts and views about each of them, as well as the summit as a whole. Hopefully, others will do the same.
Det. Cindy Murphy's keynote was well thought-out and very well received. Cindy is a well-known figure within the DFIR community, and her presentation really addressed a lot of the aspects of sharing within the community that many of us have been talking about for sometime. One of the strengths of the community that Cindy mentioned was that we all have different perspectives, and we can use that fact to build up the community as a whole. However, one of the weaknesses of the community is that we don't share those perspectives.
At the same time, I also think that Chris Pogue hit the nail on the head when he made his comment about sharing IOCs...no individual or organization is going to share their 'secret sauce'. Within the community, there are a number of businesses, and the nature of a business is to make money. If you're giving away your competitive advantage, you're not making money. This is just one of the obstacles to sharing within the DFIR community, and hopefully by engaging more, we can discuss ways to overcome some of these obstacles.
Alissa Torres had an excellent point regarding not staying "in your lane" with respect to what you do. I completely agree with her sentiment, and anyone who attended her presentation could clearly see how learning pen testing techniques from her co-workers has benefited her.
Nick Harbour of CrowdStrike gave an interesting talk on anti-forensics. It was interesting to see some of the techniques that could be used discussed, and I spent most of the presentation thinking to myself, "how would we detect that?" For instance, one of the techniques Nick mentioned for communicating off of a system was to launch IE as a COM object, and send data out in that manner. This is nothing new...I remember the Setiri presentation at BH 2002 discussing a similar approach. But the fact is, it can still work to hide activity from a particular area of analysis.
I enjoyed seeing Chris Pogue back in action again with his Sniper Forensics 3: The Hunt presentation. You can find previous iterations of Chris's presentations here and here.
Elizabeth Schweinsberg took an interesting approach in her presentation on Registry analysis - she crawled an AV website to collect data on reported Registry modifications made by various malware, and presented that data as a means for targeting your response and investigations. This was very interesting, and discussing it with her afterward, I think it would be a great idea to do that with other AV vendors, as well. I agree that this is not the idea data set...after all, AV companies receive samples of malware out of context and over the years some of the Registry artifacts associated with malware have been self-inflicted (that is, a result of how the AV analyst launches the malware). But, it's the best data we have available. One of the interesting statistics that Elizabeth came up with was the continued wide-spread use of the Run key as a persistence mechanism. Even after returning from the conference, I still see malware that uses this key for persistence.
In her presentation, Elizabeth also provided something of a showdown between GRR, RegRipper, and Registry Decoder, using various criteria. In some ways, I think it was good to show the differences in the tools, but in others, I didn't follow the reasoning for holding up tools against a criteria for which they were neither designed nor written. After all, to say that tool X wasn't scalable, when it wasn't necessarily written to be scalable, isn't necessarily giving the tool a fair representation. RegRipper was designed from the beginning to provide the ability for the community to write plugins, and one of the criteria that it was measured against was the ability to extract data from the RunOnce key. Elizabeth was correct in that the plugin did not exist when she was testing the tool, but is that really a "con" (as opposed to a "pro") statement about the tool? Also, I found myself thinking on my flight home that if Elizabeth had contacted me during her testing, I could have provided that plugin or anything else she needed. After I got home, I reached to her and found out that she had, in fact, written her own module but not included that in the presentation. I look forward to future conferences where both Elizabeth and other members of the Google team will be presenting.
The last presentation of the conference was from Carbon Black's CEO, Mike Viscuso. In his presentation, Mike demonstrated the value of Cb without ever describing Cb in detail, and for the nature of the conference, I think it was very important that he not cross that line into a vendor presentation. Instead, Mike clearly illustrated the need for the concept behind Cb, which was to redefine the data set that we, as incident responders, want access to when responding. As a result, there were several excellent questions that came up, mostly from folks who had (understandably) never heard of nor looked at Cb. The first comment during the Q&A session included asking if, by identifying a new 'data set' that DFIR folks would like to have available would put our current IR folks out of work, and to be honest, nothing could be further from the truth. Cb, and tools like it, are changing the face of incident response, but not in a way that puts current IR staff out of work...rather, it requires a change in the business model that is currently in use. The emergency model of IR is not sustainable; this is true for the consulting company that provides the service, as well as their customers. Moving to a proactive, "security camera" approach does not remove the need for highly skilled responders, it simply changes the business model to one that is more advantageous, more sustainable, and much easier to manage from a budget perspective than the current model. And this is applies to both sides of the equation, both the consultants and their customers.
A final thought about the presentations, and the summit in general...this is a great opportunity for folks who attend the conferences to really network and engage, particularly with the authors and presenters. The SANS Summit is a small conference (when compared to others) and provides a fantastic opportunity, not just for networking in general, but also for attendees to engage in a direct and meaningful manner with the speakers. It doesn't matter whether you've got questions or just really liked what you heard, you can walk up to the presenter and say something. After all, if you're 20 feet from the presenter, why send an email or Tweet saying that you liked the presentation...why not just walk up to the presenter, introduce yourself, and tell them directly? The size of the summit really facilitates that kind of close, direct interaction.