RE: Subseven Scans; Standardized Reporting

[Dial Joe <Joe.Dial () at siemens com>]

Hello,
As a dedicated reader and occasional poster, I agree with all you both say,
except for the quote copied below from Brooke.  MHO is that we encourage
the use of a template and lead by example, but never "require" a specific
format, or even content, as that will serve more to discourage than include
some whose input may be useful.  In any case, H C (currently) provides
excellent specific inquiries when the Original Poster may have left out
some detail.

Just my $0.02,
Joe Dial

|would have to be done in a specific template. This may make it 

|-----Original Message-----
|From: Brooke, O'neil (EXP) [mailto:o'neil.brooke () lmco com]
|Sent: Wednesday, August 14, 2002 4:59 PM
|To: 'H C'; Robert Buckley; 'Baribault, Gary'; grdnwsl; Rob Keown
|Cc: incidents () securityfocus com
|Subject: RE: Subseven Scans; Standardized Reporting
|
|
|[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 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