[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