RE: Subseven Scans; Standardized Reporting

From: Brooke, O'neil (EXP) (o'neil.brookeat_private)
Date: Wed Aug 14 2002 - 13:58:37 PDT

  • Next message: Robert Buckley: "RE: Subseven Scans"

    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. 
    	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
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management 
    and tracking system please see:

    This archive was generated by hypermail 2b30 : Wed Aug 14 2002 - 15:48:57 PDT