tag:blogger.com,1999:blog-9518042.post6454272702969341422..comments2024-03-19T07:46:20.437-05:00Comments on Windows Incident Response: Timeline Analysis...do we need a standard?Unknownnoreply@blogger.comBlogger14125tag:blogger.com,1999:blog-9518042.post-11908957167796895412010-02-16T06:44:01.801-05:002010-02-16T06:44:01.801-05:00Anonymous,
...there are not good tools to do it.
...Anonymous,<br /><br /><i>...there are not good tools to do it.</i><br /><br />I posted a set of tools and a document to the Win4n6 group, and there's <a href="http://log2timeline.net/" rel="nofollow">log2timeline</a>, as well.<br /><br /><i>So if you want this to work you need to come up with a tool.</i><br /><br />I've already been using the stuff I wrote, quite effectively. While it's still a pretty manual process at the moment, the benefit is well worth the cost.H. Carveyhttps://www.blogger.com/profile/08966595734678290320noreply@blogger.comtag:blogger.com,1999:blog-9518042.post-81894448779136134282010-02-16T05:20:15.815-05:002010-02-16T05:20:15.815-05:00Hey Harlan and everyone else, this sounds like a g...Hey Harlan and everyone else, this sounds like a great idea. From the LE perspective timelines are often a really important aspect of evidence presentation. I would disagree with "something as little used as timeline analysis" the reason why it is little used is because there are not good tools to do it. (if you know of any _good_ tools please let me know)<br /><br />However this is a chicken and egg problem. Do you have a standard first and then develop the tools or develop the tool first and create a demand for the standard. Having being invovled in developing ISO standards I cannot think of a better way of killing of a standard effort than getting involved with a standards body. Think about tcpdump, in that case a great tool was created and the format is now the defacto standard for packet captures. The same has happened with the EWF format potential religious argument starting however like it or not the EWF format is the defacto standard because the tools support it. Andy Rosen has developed his sparse file format (which I think is a great idea), and the electronic evidence bag also has potential but until they are supported by the tools no one will use them. <br />So if you want this to work you need to come up with a tool. That you can plug a bunch of data into and generate lots of pretty pictures your average jury can understand. <br />hmm this sounds like a great product maybe I should start coding......Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9518042.post-8317774502645239792010-02-15T20:41:41.515-05:002010-02-15T20:41:41.515-05:00...Getting Big Player #1 to fall in line...
Not s...<i>...Getting Big Player #1 to fall in line...</i><br /><br />Not sure who you're referring to, but I doubt that any commercial vendor is going to "fall in line", particularly with something as little used at timeline analysis.<br /><br /><i>Hopefully the exposure will educate the community that there's more to look at than SIA timestamps.</i><br /><br />I hope to be able to get that concept out there, too...particularly that there are timestamps less mutable and perhaps more reliable than SIA timestamps. <br /><br />In addition, I'd like to get the idea that the use of multiple data sources can increase confidence beyond what can be provided by individual sources (thanks to Cory for pointing the way to that one...)H. Carveyhttps://www.blogger.com/profile/08966595734678290320noreply@blogger.comtag:blogger.com,1999:blog-9518042.post-3790105805287839042010-02-15T20:08:14.721-05:002010-02-15T20:08:14.721-05:00Gentlemen, good luck in your endeavor. Getting Bi...Gentlemen, good luck in your endeavor. Getting Big Player #1 to fall in line with the scripts they build internally will be difficult, but it's a worthwhile pursuit. Hopefully the exposure will educate the community that there's more to look at than SIA timestamps.Geoffnoreply@blogger.comtag:blogger.com,1999:blog-9518042.post-86899349082031436072010-02-08T11:33:28.533-05:002010-02-08T11:33:28.533-05:00ok, this sounds like a good idea ;) this is better...ok, this sounds like a good idea ;) this is better than to toss it around in comments ;)Kristinnhttp://log2timeline.netnoreply@blogger.comtag:blogger.com,1999:blog-9518042.post-68487320121035849412010-02-08T11:12:27.380-05:002010-02-08T11:12:27.380-05:00Here's what I suggest...send me an email (keyd...Here's what I suggest...send me an email (keydet89 at yahoo dot com) from the email address that you'd like to use for this, and include suggestions for who you think should be included...please contact them first and see if they even want to be involved.<br /><br />I will compile the information and put together a text file that outlines what we have so far, and send it around.H. Carveyhttps://www.blogger.com/profile/08966595734678290320noreply@blogger.comtag:blogger.com,1999:blog-9518042.post-19811539631295269242010-02-08T11:09:20.125-05:002010-02-08T11:09:20.125-05:00Okay, I forgot about RFCs.
I think that the dev...Okay, I forgot about RFCs. <br /><br />I think that the development of this needs to be maintained as a separate page on one of our sites instead of across blog posts. People will need a single point of reference rather than trying to guess the latest. I offer a page on my site but I am flexible. I say we take this to email and invite/include any of the "key players" you guys propose. I will start this later today if one of you doesn't beat me to the punch.<br /><br />Don C. WeberDon C. Weberhttps://www.blogger.com/profile/01956221513602711522noreply@blogger.comtag:blogger.com,1999:blog-9518042.post-20142064229735914832010-02-08T10:46:51.433-05:002010-02-08T10:46:51.433-05:00it would be better to figure the format out, ident...<i>it would be better to figure the format out, identifying required and optional fields first, and get as far along to the first version as we can before submitting something. That way, we avoid a lot of changes and versions in a short period of time (no pun intended).</i><br /><br />Couldn't agree more...Kristinnhttp://log2timeline.netnoreply@blogger.comtag:blogger.com,1999:blog-9518042.post-65485168240560611262010-02-08T10:38:30.160-05:002010-02-08T10:38:30.160-05:00Krisinn,
Maybe a good idea would be to figure out...Krisinn,<br /><br />Maybe a good idea would be to figure out what the fields should be first. I think having some sort of versioning in place is a good idea, but IMHO, it would be better to figure the format out, identifying required and optional fields first, and get as far along to the first version as we can before submitting something. That way, we avoid a lot of changes and versions in a short period of time (no pun intended).H. Carveyhttps://www.blogger.com/profile/08966595734678290320noreply@blogger.comtag:blogger.com,1999:blog-9518042.post-64483761342521626592010-02-08T10:35:03.822-05:002010-02-08T10:35:03.822-05:00I have to agree with Harlan here, I don't thin...I have to agree with Harlan here, I don't think this standard needs to be adopted by IEEE, at least not at this point in time. I think that would really be an overkill. <br /><br />I think Harlan is right that at least for this moment it would be sufficient for some of the key players to settle with a standard and then move on from there. If the people that are currently developing tools for timeline analysis settle on a standard and continue to develop tools using it I think that would push others to adapt it as well.<br /><br />And in the future, if we see that this is getting out of hands, then perhaps it would be wise to reconsider and go over the procedure to get the standard official. This is a process that can take quite some time and effort, so it is not something to do without a clear need to actually go forward with it.<br /><br />For now, I think we can settle on a single standard, whether that by a temporary one or a permanent. The standard has to be flexible enough so that it can be changed if in the future we see a need to do so (something that can be quite difficult to do if it is an IEEE standard).<br /><br />And speaking of flexible... is there a need to maintain a version number of the standard within it? That is to have a version field denoting the TLN versioning number or is that something that is obvious (5 fields is version 0.1 6 fields is version 0.2 or something like that).Kristinnhttp://log2timeline.netnoreply@blogger.comtag:blogger.com,1999:blog-9518042.post-64226041519847601612010-02-08T10:31:05.681-05:002010-02-08T10:31:05.681-05:00Keeping the discussion at this point in blogs and ...Keeping the discussion at this point in blogs and on lists allows for the kinks to be worked out. You and Kristinn have commented to the blog posts; right now, we're trying to reach consensus. Why would anyone want to spend the effort and resources to submit a standard that no one agreed to?<br /><br />As to key players...there're RFCs that include key players, definitions that are thought of as standards, etc.<br /><br />We need to figure out if we can reach agreement first.<br /><br />I don't see commercial tools picking this up for a while. Also, when/if they do, I would hope that there are enough examples of standards divergence that have led to serious issues that this would be considered and taken into account.<br /><br />But again, for right now, none of this matters until the "key players" figure out if we can come up with a common structure or not.H. Carveyhttps://www.blogger.com/profile/08966595734678290320noreply@blogger.comtag:blogger.com,1999:blog-9518042.post-31360288714462869212010-02-08T10:25:39.200-05:002010-02-08T10:25:39.200-05:00Well, by using IEEE or Open Source it means that t...Well, by using IEEE or Open Source it means that the standard is public and not just maintained across several blog posts. Also, it means that the "key players" are known officially rather than across several blog post and agreements in comments, emails, or the halls of conferences.<br /><br />I understand what you mean by scripting, but eventually the momentum of timeline analysis will peak the interest of the commercial tool developers. Then, lacking a well defined, maintained, and public standard, they will implement their own (although the scripting feature should still be in place and usable). This means divergence which I believe is what you are attempting to avoid by broaching this subject.<br /><br />Don C. WeberDon C. Weberhttps://www.blogger.com/profile/01956221513602711522noreply@blogger.comtag:blogger.com,1999:blog-9518042.post-30009196700156282172010-02-08T09:55:42.279-05:002010-02-08T09:55:42.279-05:00I honestly don't see where any of this is requ...I honestly don't see where any of this is required. Seriously, it's all really a matter of adoption.<br /><br />For example, what directs the commercial tools? Given my experience with two of them, it seems that the big push comes from customers; if enough customers, and big enough customers, want and push for something, the commercial tools will follow suit.<br /><br />But is that really necessary? You've indicated in your blog that there are EnScripts that you use to export data; I've written ProDiscover ProScripts. So providing a scripting capability provides the means; it's up to the users to develop the specific capabilities and functionality.<br /><br />I think that all it really needs is agreement between some key players to get some momentum.H. Carveyhttps://www.blogger.com/profile/08966595734678290320noreply@blogger.comtag:blogger.com,1999:blog-9518042.post-39265787146559222862010-02-08T09:50:28.884-05:002010-02-08T09:50:28.884-05:00There seem to be two ways to do this officially. ...There seem to be two ways to do this officially. One is via IEEE and requires a membership which appears to be ~$200US. (This is better than the ~$3000US I thought it was going to be. Unless I am missing something.) The IEEE Standards Initiative, which is how standards are proposed and reviewed, can be found <a href="http://standards.ieee.org/resources/development/initiate/index.html" rel="nofollow">hear</a>.<br /><br />The other option is the Open Source Initiative which has a standards development section <a href="http://www.opensource.org/osr-intro" rel="nofollow">here</a>. I did not see any dues requirements.<br /><br />There may be others but I stopped at two.<br /><br />Not sure as to the benefit of one over the other. I imagine that an IEEE Standard will be harder to modify once implemented but the Open Source Standard would be less likely to be implemented in commercial software.<br /><br />As to a need, well, there is obviously a need. The real question is whether anybody would really care enough to implement the standard since the majority of the commercial tools that provide data analysis capabilities have their own directions. I would imagine that to get something wide reaching we would need to have at least one if not several of these companies on-board and actively participating in development as well as implementation. That, in my opinion, would require that the standard provides them some type of cost benefit as I don't see them doing it out of the kindness of their hearts. Non-commercial tool development I think would utilize the standard initially as it would help developers by already providing an initial framework to begin development. However, once projects start taking off and these developers see other needs or requirements I see them deviating from the standard rather than trying to help it grow and advance.<br /><br />So, I guess the real question to you is: is it worth your time and effort to champion an effort such as a Timeline Analysis Format Standard? Only you can answer that question. I say if you get at least four people talking to you about it and saying they will devote some time then it might be worth it. I would also say, as I mentioned before, you will need an organization to help champion it as well. A commercial data analysis software company would be nice. Endorsements from some of the security organizations would help as well. Would the standard benefit the community enough to justify the extra effort?<br /><br />Go forth and do good things,<br />Don C. WeberDon C. Weberhttps://www.blogger.com/profile/01956221513602711522noreply@blogger.com