RE: guidelines section 3.6 (security considerations)

["Harrington, David" <dbh@enterasys.com>]

Hi,

As representative of a vendor trying to write mibs and also to tie the sensitivity of mib objects to VACM views, I would like to see something more useful from the IETF than requiring mib writers to provide a list of objects in a security considerations section. 

I think we should:
1) develop quick guidelines for categorizing security sensitivity,
2) develop quick guidelines for categorizing network stability sensitivity,
3) have writers describe sensitivity in the mibs proper,
5) recommend a mib organization strategy to make mibs security-control-friendly, and
4) have writers categorize objects in a standardized machine-readable format.

1) security sensitivity

There are different types of sensitivities, and the IETF SNMP community has not done a good job of defining guidelines for determining how security-sensitive something is. Forcing mib writers to look at every object to determine whether and why it is sensitive adds a lot of work to developing a mib module; to require this without giving them any guidance about how to categorize the vulnerabilities makes it even harder.

This is exacerbated by the fact that security sensitivity is in the eye of the beholder. 
Obviously, passwords are sensitive. What about counters for authentication failures? are those sensitive? What about counters for unknown contexts? What about counters for bad SNMP packets (which might help an attacker identify which engines might be more susceptible to the ASN.1 and buffer overflow problems of last year)? The SNMPv3 very-secure posture was added explicitly to address the concerns of those who felt that EVERY mib object, even such innocuous objects as sysUpTime, could potentially be a security vulnerability. Should the system mib security considerations list sysUpTime?

How does a mib writer, not well versed in network management techniques or hacking techniques properly assess security sensitivity without any guidelines?

I recommend developing a quick-reference chart within the mib review document for this.
	high - passwords, writable security configuration objects
	medium - readable security configuration and status objects, security-related counters

2) network stability sensitivity

Some objects are sensitive because they can impact network stability. Since destablizing the network can be viewed as a denial of service, should objects that impact routing and switching be considered security sensitive? Should ifAdminStatus be considered a security-sensitive or a stability-sensitive object?

If we are going to make writers detail all the security-sensitive objects, why aren't we requiring the same for network stability sensitivity? And what guidelines should be provided to determine what is considered stability-sensitive?

I recommend developing a quick-reference chart within the mib review document for this.
	high - writable configuration objects that impact multiple devices such as spanning tree or routing behaviors, uplink configuration objects
	medium - table size constraints that could impact routing/switching scalability, port-specific configuration controls such as ifAdminStatus
	low - in/out byte counters, status objects such as ifOperStatus

3) Discussing sensitivity in the MIB itself

It is wonderful to write all these addendums to mibs, but it is common practice in the industry to distribute stripped mibs. Some applications that import mibs provide reference screens that ARE the stripped/imported mibs.

The problem is that the operators may never see all the discussion of the sensitive objects, and the impact they might have on the network, because that data is stripped out of the mib modules before operator use.

It would help if the discussion of security and network stability relative to specific objects was discussed in the text of the object itself, rather than in a separate section. This could also help mib writers design their mibs to consider the security and stability aspects during the design phase, rather than after the fact.

We should recommend mib writers document sensitivity in the table/entry/or object definitions.

4) Organize mibs to be access-control friendly

To take real advantage of SNMPv3 security, operators need to build VACM views according to the sensitivity of the objects in the mib. The mib design practices carried over from SNMPv1/v2c do not fit well with include/exclude VACM entries. Mixing sensitive and non-sensitive objects throughout the mib forces operators to create many instance-level VACM entries to include only the sensitive objects in views accessible by trusted staff, and creating many entries to exclude them from the views of other staff. This is very labor-intensive, and I doubt many operators will utilize VACM fully because of this.

VACM instance-level control can have real performance implications for SNMP engines, and for the devices on which they run, because views can have so many entries to parse. I'm not convinced many vendors will bother to support instance-level controls because they will have such a performance impact, and because operators are unlikely to bother configuring such labor-intensive controls.

We can reduce the labor costs of building VACM views and the performance hit by designing mibs to be access-control-friendly. 

The mib review document should recommend organizing the objects according to their sensitivity, putting sensitive objects and non-sensitive objects in separate subtrees within a mib module, so the OID prefix can be used to quickly identify the sensitivity of objects, and VACM searches can be based more on subtrees than instance-level masks. 

I suggest recommending that mib modules be broken into into subtrees that contain security-sensitive objects, stability-sensitive objects, and other. The security-sensitive subtree might simply include all security-related objects including security counters. Most stability-sensitive objects are the writable configuration objects, so the breakdown might also provide better guidance about what data needs to be persistent and what data needs to be included in a snapshot of the device configuration. Most status and statistic objects can probably go into the non-sensitive category, because the NM advantages of availability of the data outweigh the potential disadvantages of providing that information to hackers.

The mib review document should recommend organizing mibs for access control.

5) Provide machine-friendly security and network stability considerations.

It would be nice to have a standardized machine-parseable field per object that categorized the sensitivity of each object according to some standard assessment. This would permit the development of tools that could generate VACM views accordingly. This could be done by having mib writers include a special marker in the Description or other clause, such as "SECURITY=HIGH" or something.

An alternative would be to design a special format, comparable to compliance statements, that could categorize mibs into sensitivity groups. This would make it possible for tools to parse the security and the network stability sensitivity groups and generate corresponding VACM view entries. Such sensitivity statements could also be produced, in separate documents, for existing standard mibs. 

Making it possible to automate the generation of view entries could make the use of VACM (and better security practices) much more palatable to operators and mib developers.
--

If the SNMP community defines some guidelines about relative sensitivity and a recommended subtree organization within a mib module, then the consideration of security and network stability issues become a part of the mib development, not an afterthought. 

If we make these considerations part of the mib design and review, and permit the development of tools, then we can help operators develop and enforce good security practices. That should be our goal.

dbh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Thursday, February 06, 2003 6:27 AM
> To: C. M. Heard; Mreview (E-mail)
> Subject: RE: guidelines section 3.6 (security considerations)
> 
> 
> 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
> > 
> > 
> 
>