[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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