Reading
I wanted to share some of the interesting items I've read over the passed couple of weeks, and in doing so, I think that it's important to share not just that it was read, but to also share any insights gleaned from the material. It's one thing to provide a bunch of links...it's another thing entirely to share the impact that the material had on your thinking, and what insights you might have had. I see this a good deal, not just in the DFIR community...someone posts links to material that they have read, as if to say, "hey, click on this and read it...", but don't share their insights as to why someone should do that. If something is of value, I think that a quick synopsis of why it's of value would be useful to folks.
I look at it this way...have you ever looked up a restaurant on Yelp to read the reviews, and used what you saw to decide whether you wanted to go or not? Or have you ever look at reviews of movies in order to decide if you wanted to spend the money to see it in the theater now, or just wait until it hits the cable system, where you can see it for $5? That's the approach I'm taking with this post...
Anyway, onward...
The Needs of the Many - this is an excellent blog post that presents and discusses the characteristics of servant security leader.
This is an excellent read, not just for those seeking to understand how to be a servant leader, but also for the any Star Trek fan, as Andrew uses not just quotes from the series and movies, but also uses scenes as metaphors for the topic. It's one thing to write a paragraph and add a Wikipedia link for reference, but it's another thing entirely to use iconic movie characters and scenes to illustrate a point, such as three-dimensional thinking, giving the reader that, "oh, yeah" moment.
Survivorship Bias - this blog post was an excellent read that really opened my eyes to how we tend to view our efforts in tool testing, as well as in analysis.
A quote from the article that really caught my attention is:
Failure to look for what is missing is a common shortcoming, not just within yourself but also within the institutions that surround you.
This is very true in a lot of ways, especially within the DFIR community, which is the "institution" in the quote. Training courses (vendor-specific and otherwise) tend to talk a lot about tools, and as such, many analysts focus on tools, rather than the analysis process. Some analysts will use tools endorsed by others, never asking if the tools have been tested or validated, and simply trusting that they have been. In other cases, analysts will use one tool to validate the output of another tool, without ever understanding the underlying data structures being parsed...this is what I refer to as the tool validation "myth-odology".
This focus on tools is taking analysts away from where they need to be focused...which should be on the analysis process. I've seen analysts say that the tools allow non-experts to be useful, but how useful are they if there is no understanding of what the tool is parsing, or how the tools does what it does? A non-expert finding a piece of "evidence" at a physical crime scene will not know to provide the context of that evidence, and the same is true in the digital realm, as well. Tools should not be viewed as "making non-experts useful". Again, this is part of the "institution".
What I've seen this lead to is the repeated endorsement and use of tools that do not completely parse data structures, and do not provide any indication that they have not parsed those structures. As the tools are endorsed by "experts", and analysts find just those things that they are looking for (that "survivorship bias", where failures are not considered) the tools continue to be used, and this is something that appears to be institutional rather than an isolated, individual problem.
If you have the time, I highly recommend reading through other posts at the YouAreNotSoSmart blog. There are some really good posts there that are definitely worth your time to not just read, but consider and ingest. I'm a firm believer that anyone who wants to progress in a field needs to regularly seek knowledge outside of that field, and this is a good place to spend some time doing just that.
Paul Melson: GrrCON 2012 Forensic Challenge Write-up - Folks seem to really like stories about how others accomplished something...Paul provides how he answered the GrrCON 2012 Forensic Challenge. This is actually from the end of last year, but that's fine...everything he did still holds. Paul walks through the entire process used, describing the tools used, providing command lines, and illustrating the output. If you attempted this challenge, compare what you did to what Paul provided.
Within the DFIR community especially, I've found that analysts really tend to enjoy reading about or hearing how others have gone about solving problems. However, one of the shortcomings of the community is that not a lot of folks within it like to share how they've gone about solving problems. I know that last year, a friend of mine tried to set up a web site where folks could share those stories, but it never got off the ground. It's unfortunate...none of us alone is as smart as all of us together, and there is a lot of great information sitting out there, untapped and unused, because we aren't willing or able to share it.
Digital Forensics Stream: Amazon Cloud Drive Forensics, pt I - Similar to Paul's post, this DFStream blog post wasn't about a challenge, but it did provide an end-to-end walk through of an important aspect of analysis...testing. With the rise of cloud services, and an increased discussion of their use, one of the aspects that analysts will have to contend with is the use of desktop applications for accessing these services. Access to these services are being built into platforms, and their use is going to become more transparent (to the user) over time. As such, analysts are going to need to have an understanding of the effect of these applications on the systems being analyzed, and many analysts are in fact already asking those questions...and this post provides some answers.
GSN: Computer forensics experts discover how to determine how many times a hard drive had been turned on, and for how many hours it had run. Very interesting find within the SMART info of some drives, this can definitely be useful.
I look at it this way...have you ever looked up a restaurant on Yelp to read the reviews, and used what you saw to decide whether you wanted to go or not? Or have you ever look at reviews of movies in order to decide if you wanted to spend the money to see it in the theater now, or just wait until it hits the cable system, where you can see it for $5? That's the approach I'm taking with this post...
Anyway, onward...
The Needs of the Many - this is an excellent blog post that presents and discusses the characteristics of servant security leader.
This is an excellent read, not just for those seeking to understand how to be a servant leader, but also for the any Star Trek fan, as Andrew uses not just quotes from the series and movies, but also uses scenes as metaphors for the topic. It's one thing to write a paragraph and add a Wikipedia link for reference, but it's another thing entirely to use iconic movie characters and scenes to illustrate a point, such as three-dimensional thinking, giving the reader that, "oh, yeah" moment.
Survivorship Bias - this blog post was an excellent read that really opened my eyes to how we tend to view our efforts in tool testing, as well as in analysis.
A quote from the article that really caught my attention is:
Failure to look for what is missing is a common shortcoming, not just within yourself but also within the institutions that surround you.
This is very true in a lot of ways, especially within the DFIR community, which is the "institution" in the quote. Training courses (vendor-specific and otherwise) tend to talk a lot about tools, and as such, many analysts focus on tools, rather than the analysis process. Some analysts will use tools endorsed by others, never asking if the tools have been tested or validated, and simply trusting that they have been. In other cases, analysts will use one tool to validate the output of another tool, without ever understanding the underlying data structures being parsed...this is what I refer to as the tool validation "myth-odology".
This focus on tools is taking analysts away from where they need to be focused...which should be on the analysis process. I've seen analysts say that the tools allow non-experts to be useful, but how useful are they if there is no understanding of what the tool is parsing, or how the tools does what it does? A non-expert finding a piece of "evidence" at a physical crime scene will not know to provide the context of that evidence, and the same is true in the digital realm, as well. Tools should not be viewed as "making non-experts useful". Again, this is part of the "institution".
What I've seen this lead to is the repeated endorsement and use of tools that do not completely parse data structures, and do not provide any indication that they have not parsed those structures. As the tools are endorsed by "experts", and analysts find just those things that they are looking for (that "survivorship bias", where failures are not considered) the tools continue to be used, and this is something that appears to be institutional rather than an isolated, individual problem.
If you have the time, I highly recommend reading through other posts at the YouAreNotSoSmart blog. There are some really good posts there that are definitely worth your time to not just read, but consider and ingest. I'm a firm believer that anyone who wants to progress in a field needs to regularly seek knowledge outside of that field, and this is a good place to spend some time doing just that.
Paul Melson: GrrCON 2012 Forensic Challenge Write-up - Folks seem to really like stories about how others accomplished something...Paul provides how he answered the GrrCON 2012 Forensic Challenge. This is actually from the end of last year, but that's fine...everything he did still holds. Paul walks through the entire process used, describing the tools used, providing command lines, and illustrating the output. If you attempted this challenge, compare what you did to what Paul provided.
Within the DFIR community especially, I've found that analysts really tend to enjoy reading about or hearing how others have gone about solving problems. However, one of the shortcomings of the community is that not a lot of folks within it like to share how they've gone about solving problems. I know that last year, a friend of mine tried to set up a web site where folks could share those stories, but it never got off the ground. It's unfortunate...none of us alone is as smart as all of us together, and there is a lot of great information sitting out there, untapped and unused, because we aren't willing or able to share it.
Digital Forensics Stream: Amazon Cloud Drive Forensics, pt I - Similar to Paul's post, this DFStream blog post wasn't about a challenge, but it did provide an end-to-end walk through of an important aspect of analysis...testing. With the rise of cloud services, and an increased discussion of their use, one of the aspects that analysts will have to contend with is the use of desktop applications for accessing these services. Access to these services are being built into platforms, and their use is going to become more transparent (to the user) over time. As such, analysts are going to need to have an understanding of the effect of these applications on the systems being analyzed, and many analysts are in fact already asking those questions...and this post provides some answers.
GSN: Computer forensics experts discover how to determine how many times a hard drive had been turned on, and for how many hours it had run. Very interesting find within the SMART info of some drives, this can definitely be useful.