Publishing DFIR Materials, pt II
After posting on this topic previously and getting several comments, along with comments via other venues, I wanted to follow up with some further thoughts on opportunities for publishing DFIR materials.
When it comes to publishing DFIR materials, there are a number of ways to publish or provide information to the community, from tweets and commenting on blog posts, all the way up to writing books. As it turns out, this may be a good way to define the spectrum for publishing DFIR materials...starting with blog posts, and progressing through a number of media formats to book publishing.
Based on some previous thought and comments, I wanted to share some of the different publishing mechanisms within that spectrum, as well as what might be pros and cons of each of them.
Blogging
Blogging is a great way to make DFIR information (both technical and non-technical) available to the community. It can be quick, with some bloggers posting within minutes of an event or of finding information.
One of the best examples of DFIR blogging that I've seen, in which the content is consistently excellent, is Corey Harrell's Journey Into IR blog. Corey's posts are consistently well-written, insightful, and chock full of great technical information. Corey has taken the opportunity a number of times post not only his research set-up, but also provide a comprehensive write-up regarding the tools and techniques he used, as well as his findings.
Pros
Blogging is a great way to get information out on a particular topic, particularly if your goal is to get the initial information out to show the results of a tool or initial research. This is a great way to see if anyone else is interested in what you're working on, either investigating or developing, and to see if there's interest in taking the research further.
This is also a great way to quickly put out information regarding findings, particularly if it requires more than 140 characters, but isn't too voluminous or extensive.
Cons
There can be a number of 'cons' associated with this publishing mechanism...one of which is the simple fact that it can be very difficult to keep up with all of the possible blogs that are out there. Also, with blogs, it can be difficult to see the progression of information as (or 'if') it is updated.
Call me a spelling n@zi if you like, but another issue that I see with blogs is that pretty much anyone can create one, and if the author has little interest in such things as grammar and spelling, it can be difficult to read, if not find, such blogs. If you're searching for something via Google as part of your research, and someone posted a great blog post but opted to not spell certain terms properly, or opted to not use the generally accepted terminology (i.e., Registry key vs. value), you might have some difficulty finding that post.
If you're interested in purely technical DFIR information, blogs may or may not be the best resource. Some authors do not feel the need to research their information or provide things such as references, and some may not provide solely technical information via their blog, using it also as a personal diary or political platform. There's nothing wrong with this, mind you...it's just that it may be difficult to find something if it's mixed in with a lot of other stuff.
Some blogs and blog posts provide nothing more than a list of links, with no insight or commentary from the author. While this method of blogging can provide the information to a wider audience than would normally view the original blog post, it really doesn't do much to further the community as a whole. If someone posts about finding and using a tool, and feel as if they want to post a blog of their own, why not provide some insight into how you found the tool to be useful, or not, if that's the case? What if it's not a tool, but information...wouldn't it be useful to others within the community if you
Wiki
I like wikis, as they can provide a valuable means for maintaining updated, accurate information, particularly on very technical subjects. Most of the formats I've seen include the ability to add references and links to supporting information, which add credibility to the information being provided. Blogs provide this as well, but a wiki allows you to edit the information, providing the latest and most up-to-date information in one location.
Pros
Wikis can be extremely beneficial resources, in that they can provide a single, updated repository of information on DFIR topics.
Perhaps the best use of a wiki is as an internal resource, one in which members of your team are the only ones who can access it and update it.
Cons
One of the primary cons I would associate with the use of Wikis is that a lot of folks don't seem to use them. One of the wikis I frequent is the ForensicsWiki; while I find this to be a valuable resource and have even posted information there myself, my experience within the public lists and forums is that most folks don't seem to consider going to sites such as this, or using them as a resource. I know that schools and publishers, including my own, frown upon the use of wikis as references, but if the information is accurate (which you've determined through research and testing), what's really the issue?
PDFs
After I got involved in writing books, I started to see the value of providing up-to-date documents on specific analysis topics. Rather than writing a book, take a single analysis technique (say, file extension analysis), or a series of steps to perform a specific type of analysis (i.e., determining CD burning by a user, etc.), write it up into a 6-10 page PDF document and release it.
To see an example of this publishing mechanism, go to my Google Code book repository, download the "RR.zip" archive, and look in the DVD\stuff subdirectory. You'll find a number of PDF documents that I'd written up and provided as "bonus" material with the book. Since releasing this information, I haven't heard from anyone how useful it is, or if it's completely worthless. ;-)
Another excellent example of this sort of publishing is a newsletter such as the Into The Boxes e-zine. It's unfortunate that the community support wasn't there to keep Don's efforts going. Another excellent example of using this mechanism to publish DFIR information is the DFIR poster that the SANS folks made available recently.
Pros
This mechanism can be extremely valuable to analysts in a number of areas. While I was on the IBM team, we wanted to have a way to provide analysts with information that they could download and take with them when they were headed out on a response engagement. This was "just-in-time" familiarization and/or training that could get an analyst up to speed on a particular topic quickly, and could also be used as an on-site reference. Our thinking was that if we had someone who had to go on-site in order to acquire a MacBook, or a boot-from-SAN device, or try to conduct a live acquisition of a system that has only USB 1.0 connections, we could provide extremely useful reference information so that the analyst could act with confidence, which is paramount when you're in front of a customer. Many times, while we had other analysts who were just a phone call away, we would find ourselves either in a data center with no cell phone signal, or standing directly in front of a customer.
I talked to several LE analysts about this type of JIT training, and received some enthusiastic responses at the time. Having 6-10 page PDFs that can be printed out and included in a binder, with updated PDFs replacing older information, was seen as very valuable. I know that some folks have also expressed a desire to have something easily searchable.
Cons
This publishing mechanism depends on the expertise of the individual author, and their willingness to not only provide the information, but keep it up to date. If this is something that someone just decides to do, then you have similar issues as with blogging...spelling, grammar, completeness and accuracy of information. One way around this is to have a group available, either through volunteers or a publisher, that provides for reviews of submitted material, checking for clarity, consistency, and accuracy.
IOCs/Plugins
IOCs, or "indicators of compromise", should be included as a publishing mechanism, as it is intended for sharing information and/or intelligence, albeit following a specific structure or specification. Perhaps the most notable effort along these lines is OpenIOC.org, which uses a schema developed by the folks at Mandiant. The OpenIOC framework is intended to provide an extendable, customizable structure for sharing sophisticated indicators and intelligence in order to promote advanced threat detection.
I would also include plugins in this category, particularly (although not specifically) those associated with RegRipper. I know that other tools have taken up an approach similar to RegRipper's plugins, and this is a good place to include them, even if they don't follow as structured a format as IOCs.
Pros
IOCs and plugins can be a great publishing mechanism, providing for the retention of corporate knowledge, as well as being a force multiplier. Let's say someone finds something after 8 or 12 hrs of analysis, something that they hadn't seen before...then they write up an IOC or plugin, and share it with their 10 other team members. With a few minutes of time, they've just saved their team at least 10 x 12 hrs, or 120 hrs of work, where each team member (assuming equal skill level across the team) would have had to spend 12 hrs of their own time to find that same indicator. Now, each team member has 100% of the knowledge and capability for locating the indicator, while having to spend 0 time in attaining that knowledge.
IOCs and plugins put tools and capabilities in the hands of the analysts who need them, and using the appropriate mechanism for querying for the indicators provides for those indicators to be searched for every time, in an automated manner.
Cons
One 'con' I have seen so far with respect to IOCs is that there is either a limitation within the schema, or a self-imposed (by the IOC author) limitation of some kind. What I mean by this is, I've seen several malware-specific IOCs released online recently, and in some cases, there is no persistence mechanism listed within the IOC. I contacted the author, and was told that while the particular malware sample used the ubiquitous Run key within the Windows Registry for persistence, the value name used could be defined by the malware author and in essence, completely random. As such, the author found no easy means for codifying this information via the schema, and felt that the best thing to do was to simply leave it out. To me, this seems like a self-imposed blind spot and a gap in potential intelligence. I'm not familiar enough with the OpenIOC schema to know if it provides a means for identifying this sort of information or not, but I do think that by not providing something, that there is a significant blind spot.
Another 'con' associated with IOCs that I have heard others mention, particularly at the recent SANS Forensic Summit, is that no one is going to give away their "secret sauce", thereby giving up their competitive advantage. I would go so far as to say that this applies to other publishing mechanisms, as well, and is not a 'con' that is specific solely to IOCs. Like most, I am fully aware that while some sites (i.e., blogs, etc.) may provide DFIR information, not all of it is necessarily cutting edge. In fact, there are a number of sites where, when DFIR information does appear, it is understood to be 6 months or more old, for that particular provider, even though others may not have seen it before.
As with IOCs, RegRipper plugins can be difficult for folks to write, or write correctly, on their own. This can be particularly true if the potential author is new to either programming or to the response and analysis techniques that generally go hand-in-hand with, or precede, the ability to write IOCs and plugins.
Short Form
I recently had a discussion with a member of the Syngress publishing staff regarding a "new" publishing format that the publishing company is pursuing; specifically, rather than having authors write an entire book, have them instead write a "module", which is not so much a part or portion of a book, but more of a standalone publishing mechanism. The idea with this "short form" of publishing is that DFIR information will be available to the community quicker, as the short form is easier for the author to write, and for the publisher to review and publish.
A very good example of short form publishing is the IACIS Quick Reference from Lock and Code, which is an excellent reference, and available in both a free and a for-fee form.
In a lot of ways, this is very similar to the PDF publishing mechanism I mentioned earlier, albeit this mechanism can reach up to over 100 pages; while it's longer than a PDF, it is still shorter than a complete book.
Pros
Benefits of this publishing mechanism are that the information is more complete than a blog post or PDF, is reviewed by someone for technical accuracy, as well as spelling and grammar, is formatted, and is available quicker than a full book.
Another benefit of this mechanism is that folks can pick the modules that they're interested in, rather than purchasing a full book of 8 or more chapters, when they're only interested in about half of the content. Hopefully, this will also mean that folks who are interested in several modules and want a hard-copy version of the material can choose the modules that they want and have them printed to a soft-bound edition.
Cons
Even the short form publishing mechanism can take time to make it "to market" and be available to the community. For example, in my experience, it can take quite a while for someone to write something that is 100 pages long, even if they are experienced writers. Let's say that the author is focused, has some good guidance and motivation, and gets something through the authoring, review, and revision process in 90 days. How long will it take to then have that information available to the public? At this point, everything is dependent upon the publisher's schedule...who is available to review the module and get it into a printer-ready format? What about contracts with printers? Will an electronic version of the module be ready sooner than the hard-copy version?
Books
Books are great resources for DFIR information, whether the author is going through a publishing company, or following a self-publishing route.
Pros
One of the biggest 'pros' of publishing books containing DFIR material is that a publishing company has a structure already set up for publishing books, which includes having the book technically reviewed by someone known within the field, as well as reviewed for consistency, grammar, spelling, etc., prior to being sent to the printer.
Writing a book can be an arduous undertaking, and keeping track of everything that goes into it...paragraph formats, side bars, code listings, figures, etc...can be a daunting task. Working with a publisher means that you have a signed contract and schedule to meet, which can act as the "hot poker motivation" that is often needed to get an author to sit down and start writing. As chapters are written, they're sent off to someone to perform a technical review, which can be very beneficial because the author may loose sight of the forest for the trees, and having someone who's not so much "in the weeds" review the material is a great way to keep you on track. Finally, having someone review the finished product for grammar and spelling, and catching all of those little places where you put in the wrong word or left one out can be very helpful. Overall, this structure adds credibility to the finished product.
Cons
Publishing a book can take some time. My first book literally took me a year to write, and from there 3 - 3 1/2 months to go from an MS Word manuscript to the PDF proofs to a published book available for purchase. Due to the amount of time and effort it takes, some authors who start down the road of writing a book and even get to the point of having a signed contract never even get to the point where they have a published book. As I've progressed along in writing books, I've been able to reduce the total amount of time between the signed contract and the publication date, but the fact is that it can still take a year or more.
Another aspect of the book form is that different publishers may support different ebook formats. When my first book was published with Syngress, there was a PDF version of the book available, and for a while after the soft-bound book was available, those purchasing the book via Syngress would also receive a PDF copy of the book, as well. However, shortly thereafter, Syngress was purchased by Elsevier, a publishing company that does not support the PDF ebook format.
One of the benefits for some folks, believe it or not, of working with a publisher is that they have a schedule and the 'hot poker motivation' to get the work done. As such, one of the detriments of self-publishing is that without the necessary internal stimulus to keep the author to a schedule, the finished product may never materialize.
Overall Pros
Publishing DFIR information can potentially make us all stronger examiners. No single analyst knows everything that there is to know about DFIR analysis, but working together and sharing information and intel, we can all be much stronger analysts. It's the sharing of not only information and intelligence, but digesting that information, providing insights on it, and engaging in discussions of it that makes us all stronger analysts.
Some information changes quickly, while other information remains pretty consistent over a considerable length of time. Choosing the appropriate publishing mechanism can make the appropriate information available in a timely manner; for example, a blog post can raise awareness of an issue or indicator, which can lead to more research and the creation of a tool, an IOC, or a plugin.
Overall Cons
All publishing mechanisms rely on the interest and desire of the author(s) to provide information, to research it, and to keep it up to date. Sometimes due to work, life, or simply lack of interest, information isn't kept up to date. However, the 'pro' that can come out of this, the 'silver lining' if you will, is that perhaps all that is needed is to provide that initial information on a topic, and someone else may pick it up.
Another significant 'con' associated with publishing DFIR material to the community in general is a lack of support and feedback from the community. Well, to be honest, this is a 'con' only if it's something that you're looking for; I happen to be of a mind that no one knows everything, and no one of us is as smart as all of us. As such, I honestly believe that the way to improve overall is to provide insightful commentary and feedback to someone who has provided something to the community, be it a tool or utility, or something published using any of the above means. If someone provides DFIR information, I try to take the time to let them, or the community as a whole, know what was useful about it, from my perspective. Feedback from the community is what leads to improvement in and expansion of the material itself. Not everyone has the same perspective on the cases that they work, nor of the information that they look at on any particular case. You may have two examiners with the same system, but as they're from different organizations, the goals of their exam, as well as their individual perspectives, will be different.
Goals
Finally, something needs to be said about the goals of publishing DFIR information; often, this is highly personal, in that an author's goals or reasons for publishing may be something that they do not want to discuss...and there's nothing wrong with that.
Usually, if someone is publishing DFIR information, it's because they wanted, first and foremost, to make the information available and contribute something to the community at large. However, there can be other goals to publishing that motivate someone and direct them toward a particular publishing mechanism. For example, writing blog posts that are of a consistently high quality (with respect to both the information and the presentation) will lead to that author becoming recognized as an expert in their field. One follow-on to this that is often mentioned is that by being recognized as something of an expert, that author will be consulted for advice, or contracted with to perform work...I personally haven't encountered this, per se, but it is something that is mentioned by others.
Another goal for publishing information and choosing the appropriate mechanism is that the author(s) may want to be compensated for their time and work, and who can really blame them? I mean, really...is it such a bad thing to, after sacrificing evenings and weekends to produce something that others find of value, want to take your wife to dinner? How about to raise money to contribute to a charity? Or to pay for the tools that you purchased in order to conduct your research, or tools you'll need to further that research?
When it comes to publishing DFIR materials, there are a number of ways to publish or provide information to the community, from tweets and commenting on blog posts, all the way up to writing books. As it turns out, this may be a good way to define the spectrum for publishing DFIR materials...starting with blog posts, and progressing through a number of media formats to book publishing.
Based on some previous thought and comments, I wanted to share some of the different publishing mechanisms within that spectrum, as well as what might be pros and cons of each of them.
Blogging
Blogging is a great way to make DFIR information (both technical and non-technical) available to the community. It can be quick, with some bloggers posting within minutes of an event or of finding information.
One of the best examples of DFIR blogging that I've seen, in which the content is consistently excellent, is Corey Harrell's Journey Into IR blog. Corey's posts are consistently well-written, insightful, and chock full of great technical information. Corey has taken the opportunity a number of times post not only his research set-up, but also provide a comprehensive write-up regarding the tools and techniques he used, as well as his findings.
Pros
Blogging is a great way to get information out on a particular topic, particularly if your goal is to get the initial information out to show the results of a tool or initial research. This is a great way to see if anyone else is interested in what you're working on, either investigating or developing, and to see if there's interest in taking the research further.
This is also a great way to quickly put out information regarding findings, particularly if it requires more than 140 characters, but isn't too voluminous or extensive.
Cons
There can be a number of 'cons' associated with this publishing mechanism...one of which is the simple fact that it can be very difficult to keep up with all of the possible blogs that are out there. Also, with blogs, it can be difficult to see the progression of information as (or 'if') it is updated.
Call me a spelling n@zi if you like, but another issue that I see with blogs is that pretty much anyone can create one, and if the author has little interest in such things as grammar and spelling, it can be difficult to read, if not find, such blogs. If you're searching for something via Google as part of your research, and someone posted a great blog post but opted to not spell certain terms properly, or opted to not use the generally accepted terminology (i.e., Registry key vs. value), you might have some difficulty finding that post.
If you're interested in purely technical DFIR information, blogs may or may not be the best resource. Some authors do not feel the need to research their information or provide things such as references, and some may not provide solely technical information via their blog, using it also as a personal diary or political platform. There's nothing wrong with this, mind you...it's just that it may be difficult to find something if it's mixed in with a lot of other stuff.
Some blogs and blog posts provide nothing more than a list of links, with no insight or commentary from the author. While this method of blogging can provide the information to a wider audience than would normally view the original blog post, it really doesn't do much to further the community as a whole. If someone posts about finding and using a tool, and feel as if they want to post a blog of their own, why not provide some insight into how you found the tool to be useful, or not, if that's the case? What if it's not a tool, but information...wouldn't it be useful to others within the community if you
Wiki
I like wikis, as they can provide a valuable means for maintaining updated, accurate information, particularly on very technical subjects. Most of the formats I've seen include the ability to add references and links to supporting information, which add credibility to the information being provided. Blogs provide this as well, but a wiki allows you to edit the information, providing the latest and most up-to-date information in one location.
Pros
Wikis can be extremely beneficial resources, in that they can provide a single, updated repository of information on DFIR topics.
Perhaps the best use of a wiki is as an internal resource, one in which members of your team are the only ones who can access it and update it.
Cons
One of the primary cons I would associate with the use of Wikis is that a lot of folks don't seem to use them. One of the wikis I frequent is the ForensicsWiki; while I find this to be a valuable resource and have even posted information there myself, my experience within the public lists and forums is that most folks don't seem to consider going to sites such as this, or using them as a resource. I know that schools and publishers, including my own, frown upon the use of wikis as references, but if the information is accurate (which you've determined through research and testing), what's really the issue?
PDFs
After I got involved in writing books, I started to see the value of providing up-to-date documents on specific analysis topics. Rather than writing a book, take a single analysis technique (say, file extension analysis), or a series of steps to perform a specific type of analysis (i.e., determining CD burning by a user, etc.), write it up into a 6-10 page PDF document and release it.
To see an example of this publishing mechanism, go to my Google Code book repository, download the "RR.zip" archive, and look in the DVD\stuff subdirectory. You'll find a number of PDF documents that I'd written up and provided as "bonus" material with the book. Since releasing this information, I haven't heard from anyone how useful it is, or if it's completely worthless. ;-)
Another excellent example of this sort of publishing is a newsletter such as the Into The Boxes e-zine. It's unfortunate that the community support wasn't there to keep Don's efforts going. Another excellent example of using this mechanism to publish DFIR information is the DFIR poster that the SANS folks made available recently.
Pros
This mechanism can be extremely valuable to analysts in a number of areas. While I was on the IBM team, we wanted to have a way to provide analysts with information that they could download and take with them when they were headed out on a response engagement. This was "just-in-time" familiarization and/or training that could get an analyst up to speed on a particular topic quickly, and could also be used as an on-site reference. Our thinking was that if we had someone who had to go on-site in order to acquire a MacBook, or a boot-from-SAN device, or try to conduct a live acquisition of a system that has only USB 1.0 connections, we could provide extremely useful reference information so that the analyst could act with confidence, which is paramount when you're in front of a customer. Many times, while we had other analysts who were just a phone call away, we would find ourselves either in a data center with no cell phone signal, or standing directly in front of a customer.
I talked to several LE analysts about this type of JIT training, and received some enthusiastic responses at the time. Having 6-10 page PDFs that can be printed out and included in a binder, with updated PDFs replacing older information, was seen as very valuable. I know that some folks have also expressed a desire to have something easily searchable.
Cons
This publishing mechanism depends on the expertise of the individual author, and their willingness to not only provide the information, but keep it up to date. If this is something that someone just decides to do, then you have similar issues as with blogging...spelling, grammar, completeness and accuracy of information. One way around this is to have a group available, either through volunteers or a publisher, that provides for reviews of submitted material, checking for clarity, consistency, and accuracy.
IOCs/Plugins
IOCs, or "indicators of compromise", should be included as a publishing mechanism, as it is intended for sharing information and/or intelligence, albeit following a specific structure or specification. Perhaps the most notable effort along these lines is OpenIOC.org, which uses a schema developed by the folks at Mandiant. The OpenIOC framework is intended to provide an extendable, customizable structure for sharing sophisticated indicators and intelligence in order to promote advanced threat detection.
I would also include plugins in this category, particularly (although not specifically) those associated with RegRipper. I know that other tools have taken up an approach similar to RegRipper's plugins, and this is a good place to include them, even if they don't follow as structured a format as IOCs.
Pros
IOCs and plugins can be a great publishing mechanism, providing for the retention of corporate knowledge, as well as being a force multiplier. Let's say someone finds something after 8 or 12 hrs of analysis, something that they hadn't seen before...then they write up an IOC or plugin, and share it with their 10 other team members. With a few minutes of time, they've just saved their team at least 10 x 12 hrs, or 120 hrs of work, where each team member (assuming equal skill level across the team) would have had to spend 12 hrs of their own time to find that same indicator. Now, each team member has 100% of the knowledge and capability for locating the indicator, while having to spend 0 time in attaining that knowledge.
IOCs and plugins put tools and capabilities in the hands of the analysts who need them, and using the appropriate mechanism for querying for the indicators provides for those indicators to be searched for every time, in an automated manner.
Cons
One 'con' I have seen so far with respect to IOCs is that there is either a limitation within the schema, or a self-imposed (by the IOC author) limitation of some kind. What I mean by this is, I've seen several malware-specific IOCs released online recently, and in some cases, there is no persistence mechanism listed within the IOC. I contacted the author, and was told that while the particular malware sample used the ubiquitous Run key within the Windows Registry for persistence, the value name used could be defined by the malware author and in essence, completely random. As such, the author found no easy means for codifying this information via the schema, and felt that the best thing to do was to simply leave it out. To me, this seems like a self-imposed blind spot and a gap in potential intelligence. I'm not familiar enough with the OpenIOC schema to know if it provides a means for identifying this sort of information or not, but I do think that by not providing something, that there is a significant blind spot.
Another 'con' associated with IOCs that I have heard others mention, particularly at the recent SANS Forensic Summit, is that no one is going to give away their "secret sauce", thereby giving up their competitive advantage. I would go so far as to say that this applies to other publishing mechanisms, as well, and is not a 'con' that is specific solely to IOCs. Like most, I am fully aware that while some sites (i.e., blogs, etc.) may provide DFIR information, not all of it is necessarily cutting edge. In fact, there are a number of sites where, when DFIR information does appear, it is understood to be 6 months or more old, for that particular provider, even though others may not have seen it before.
As with IOCs, RegRipper plugins can be difficult for folks to write, or write correctly, on their own. This can be particularly true if the potential author is new to either programming or to the response and analysis techniques that generally go hand-in-hand with, or precede, the ability to write IOCs and plugins.
Short Form
I recently had a discussion with a member of the Syngress publishing staff regarding a "new" publishing format that the publishing company is pursuing; specifically, rather than having authors write an entire book, have them instead write a "module", which is not so much a part or portion of a book, but more of a standalone publishing mechanism. The idea with this "short form" of publishing is that DFIR information will be available to the community quicker, as the short form is easier for the author to write, and for the publisher to review and publish.
A very good example of short form publishing is the IACIS Quick Reference from Lock and Code, which is an excellent reference, and available in both a free and a for-fee form.
In a lot of ways, this is very similar to the PDF publishing mechanism I mentioned earlier, albeit this mechanism can reach up to over 100 pages; while it's longer than a PDF, it is still shorter than a complete book.
Pros
Benefits of this publishing mechanism are that the information is more complete than a blog post or PDF, is reviewed by someone for technical accuracy, as well as spelling and grammar, is formatted, and is available quicker than a full book.
Another benefit of this mechanism is that folks can pick the modules that they're interested in, rather than purchasing a full book of 8 or more chapters, when they're only interested in about half of the content. Hopefully, this will also mean that folks who are interested in several modules and want a hard-copy version of the material can choose the modules that they want and have them printed to a soft-bound edition.
Cons
Even the short form publishing mechanism can take time to make it "to market" and be available to the community. For example, in my experience, it can take quite a while for someone to write something that is 100 pages long, even if they are experienced writers. Let's say that the author is focused, has some good guidance and motivation, and gets something through the authoring, review, and revision process in 90 days. How long will it take to then have that information available to the public? At this point, everything is dependent upon the publisher's schedule...who is available to review the module and get it into a printer-ready format? What about contracts with printers? Will an electronic version of the module be ready sooner than the hard-copy version?
Books
Books are great resources for DFIR information, whether the author is going through a publishing company, or following a self-publishing route.
Pros
One of the biggest 'pros' of publishing books containing DFIR material is that a publishing company has a structure already set up for publishing books, which includes having the book technically reviewed by someone known within the field, as well as reviewed for consistency, grammar, spelling, etc., prior to being sent to the printer.
Writing a book can be an arduous undertaking, and keeping track of everything that goes into it...paragraph formats, side bars, code listings, figures, etc...can be a daunting task. Working with a publisher means that you have a signed contract and schedule to meet, which can act as the "hot poker motivation" that is often needed to get an author to sit down and start writing. As chapters are written, they're sent off to someone to perform a technical review, which can be very beneficial because the author may loose sight of the forest for the trees, and having someone who's not so much "in the weeds" review the material is a great way to keep you on track. Finally, having someone review the finished product for grammar and spelling, and catching all of those little places where you put in the wrong word or left one out can be very helpful. Overall, this structure adds credibility to the finished product.
Cons
Publishing a book can take some time. My first book literally took me a year to write, and from there 3 - 3 1/2 months to go from an MS Word manuscript to the PDF proofs to a published book available for purchase. Due to the amount of time and effort it takes, some authors who start down the road of writing a book and even get to the point of having a signed contract never even get to the point where they have a published book. As I've progressed along in writing books, I've been able to reduce the total amount of time between the signed contract and the publication date, but the fact is that it can still take a year or more.
Another aspect of the book form is that different publishers may support different ebook formats. When my first book was published with Syngress, there was a PDF version of the book available, and for a while after the soft-bound book was available, those purchasing the book via Syngress would also receive a PDF copy of the book, as well. However, shortly thereafter, Syngress was purchased by Elsevier, a publishing company that does not support the PDF ebook format.
One of the benefits for some folks, believe it or not, of working with a publisher is that they have a schedule and the 'hot poker motivation' to get the work done. As such, one of the detriments of self-publishing is that without the necessary internal stimulus to keep the author to a schedule, the finished product may never materialize.
Overall Pros
Publishing DFIR information can potentially make us all stronger examiners. No single analyst knows everything that there is to know about DFIR analysis, but working together and sharing information and intel, we can all be much stronger analysts. It's the sharing of not only information and intelligence, but digesting that information, providing insights on it, and engaging in discussions of it that makes us all stronger analysts.
Some information changes quickly, while other information remains pretty consistent over a considerable length of time. Choosing the appropriate publishing mechanism can make the appropriate information available in a timely manner; for example, a blog post can raise awareness of an issue or indicator, which can lead to more research and the creation of a tool, an IOC, or a plugin.
Overall Cons
All publishing mechanisms rely on the interest and desire of the author(s) to provide information, to research it, and to keep it up to date. Sometimes due to work, life, or simply lack of interest, information isn't kept up to date. However, the 'pro' that can come out of this, the 'silver lining' if you will, is that perhaps all that is needed is to provide that initial information on a topic, and someone else may pick it up.
Another significant 'con' associated with publishing DFIR material to the community in general is a lack of support and feedback from the community. Well, to be honest, this is a 'con' only if it's something that you're looking for; I happen to be of a mind that no one knows everything, and no one of us is as smart as all of us. As such, I honestly believe that the way to improve overall is to provide insightful commentary and feedback to someone who has provided something to the community, be it a tool or utility, or something published using any of the above means. If someone provides DFIR information, I try to take the time to let them, or the community as a whole, know what was useful about it, from my perspective. Feedback from the community is what leads to improvement in and expansion of the material itself. Not everyone has the same perspective on the cases that they work, nor of the information that they look at on any particular case. You may have two examiners with the same system, but as they're from different organizations, the goals of their exam, as well as their individual perspectives, will be different.
Goals
Finally, something needs to be said about the goals of publishing DFIR information; often, this is highly personal, in that an author's goals or reasons for publishing may be something that they do not want to discuss...and there's nothing wrong with that.
Usually, if someone is publishing DFIR information, it's because they wanted, first and foremost, to make the information available and contribute something to the community at large. However, there can be other goals to publishing that motivate someone and direct them toward a particular publishing mechanism. For example, writing blog posts that are of a consistently high quality (with respect to both the information and the presentation) will lead to that author becoming recognized as an expert in their field. One follow-on to this that is often mentioned is that by being recognized as something of an expert, that author will be consulted for advice, or contracted with to perform work...I personally haven't encountered this, per se, but it is something that is mentioned by others.
Another goal for publishing information and choosing the appropriate mechanism is that the author(s) may want to be compensated for their time and work, and who can really blame them? I mean, really...is it such a bad thing to, after sacrificing evenings and weekends to produce something that others find of value, want to take your wife to dinner? How about to raise money to contribute to a charity? Or to pay for the tools that you purchased in order to conduct your research, or tools you'll need to further that research?