RE: Subseven Scans; Standardized Reporting

["Brooke, O'neil (EXP)" <o'neil.brooke () lmco com>]

[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