RE: guidelines section 3.6 (security considerations)

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

New proposed text is OK and appreciated by me.
Hope others don't see it as adding another CLR.
I know from experience that security ADs may and
will push back (unfortenately, not always consistently)
on the security cons section if not properly done.
And such happens (too) late in the process. Rather
have it checked earlier on.

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: donderdag 6 februari 2003 3:47
> To: Mreview (E-mail)
> Subject: Re: guidelines section 3.6 (security considerations)
> 
> 
> On Wed, 5 Feb 2003, Wijnen, Bert (Bert) wrote:
> > > > - sect 3.6
> > > >   The sensitivity of each (group of) object(s) needs to be
> > > >   explained and text needs to be there on how to address any
> > > >   security risks/concerns
> > > 
> > It is much better already. How about adding:
> > 
> >   If there are no risks/vulnerabilities at all in a specific
> >   category, then please do state that. Then at least we can
> >   see that you did think about it and that you claim that there
> >   are no risks/vulnerabilities. Just copying the text is not good.
> >   You should think and evaluate the risks/vulnerabilies and then
> >   state/document the result of your evaluation.
> 
> Agreed in principle, but I'd like to do a little wordsmithing.  Here
> is the new proposed text for 3.6, "Security Considerations Section":
> 
>    In order to comply with Section 4.9 of [RFC2223bis], each
>    specification that defines one or more MIB modules MUST contain a
>    section that discusses security considerations relevant to 
> those MIB
>    modules.  This section MUST be patterned after the latest approved
>    template available at 
> http://www.ops.ietf.org/mib-security.html.  In
>    particular, writeable MIB objects that could be especially 
> disruptive
>    if abused MUST be explicitly listed by name and the associated
>    security risks MUST be spelled out;  similarly, readable 
> MIB objects
>    that contain especially sensitive information MUST be explicitly
>    listed by name and the reasons for the special sensitivity MUST be
>    explained.  If there are no risks/vulnerabilities for a specific
>    category of MIB objects, then that fact MUST be explicitly stated.
>    Failure to mention a particular category of MIB objects will not be
>    equated to a claim of no risks/vulnerabilities in that category;
>    rather, it will be treated as an act of omission and will result in
>    the document being returned to the author for correction.  Remember
>    that the objective is not to blindly copy text from the 
> template, but
>    rather to think and evaluate the risks/vulnerabilies and then
>    state/document the result of this evaluation.
> 
> > I have seen too many people who just copied the guideline text
> > without even thinking about it.
> 
> Yes, if I recall correctly, Steve Bellovin said that too -- he wants
> people to think about security issues and not just blindly copy text.
> 
> //cmh
> 
>