[SNIP] I am simply pointing out that on the lists, when an incident like this occurs, very often we take some steps, but don't go far enough. In the long wrong, going half way and speculating about the rest of the issue is actually more harmful to the community as a whole than simply ignoring the SYN packets in the first place. All I'm suggesting is that if you're going to investigate a situation, do so, but do so fully and completely. The reason I suggest this is b/c for the most part, we (as a community) aren't all that good at detecting and investigating incidents...let alone reporting them. [SNIP] Excellent point and a worthwhile objective HC. I have an idea (certainly not original) to achieve these results on a sustained basis. I picked up a book called Incident Response awhile ago and they had some rudimentary incident checklists which were a great starting point and I went on to develop my own template that was appropriate to my specific situation. What if we were to have a checklist for the incidents list? When submitting a 'Are you experiencing this too?' or 'What is this?' message, it would have to be done in a specific template. This may make it easier for both posters and readers of this list. When composing a message I'm sure people are thinking 'What information should be included?', 'How much detail should go into it?', 'Am I being to verbose?'. Readers are looking at this information on the other hand in piecemeal fashion. As the investigator gains additional detail, he'll post it, but not necessarily with the original information, so now you have to remember this particular case, what facts were already disclosed and the implication of this new information. Whereas with a standardized incident response form plain language in the header would explain the version change and the detail lines within the form would simply contain the new information; all available information would be available for subsequent reviews. We will never stop people from making assumptions based on limited information (nor should we in some cases in can be a critical skill) but this may give us a metric for evaluating any of the assumptions made. (simplistic example; only 10% of the template is filled out means speculation may be prone to wild inaccuracies.) I do not know if any generic incident response checklists exist in the public domain, do you? Anyone feel like getting together and working on one? O'Neil. ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Wed Aug 14 2002 - 15:48:57 PDT