RE: FW: Updating the MIB security guidelines

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

[Dave, sorry to switch to plain ASCII text all the time, but I guess
it will be accpeted better by most readers/participants]

Dave, thanks for taking up on this.
However, I think that what you bring up is a separate topic.
It is about:

  "Security Guidelines for designing MIBs in the context of VACM"

And as you say... it sounds simple, but to get consensus on it may take
more and to get it implemented will be even more difficult (or so I suspect)

The topic I wanted to get quick consensus/closure on is

  "Guidelines for the Security Section of MIB documents"

And I do now realize that my subject line was not precize enough.
If we assume that a lot of MIB documents are in the pipeline then
I think it would be good if we can quickly come up with a better and
more precize guideline for those MIBs. That is what I am after in
this thread.

Your topic is a good topic to discuss too, but maybe that is a 
topic that we could include in a new document that talks about
Guidlines for all security aspects for SNMP and MIB documents?

Thanks,
Bert 
-----Original Message-----
From: Harrington, David [mailto:dbh@enterasys.com]
Sent: dinsdag 12 november 2002 3:37
To: Wijnen, Bert (Bert)
Cc: mibs@ops.ietf.org
Subject: RE: FW: Updating the MIB security guidelines


Hi, 
I think we as a community need to rethink how mibs are written, to better accommodate the VACM view of things (no pun intended, but accurate). 
We should recommend some default VACM groups, and recommend a way to group the sensitive objects in a mib module, define default VACM view entries for each mib module, and define which default VACM groups should have access to which module-specific views.


VACM default groups: 
The NSA has published a Router Security Configuration Guide, and they identify three primary "roles" - operator, administrator, and security administrator. I recommend we adopt those three as a good set of default VACM groups, upon which administrators can build if desired.
VACM default Views: 
Most writable objects and a few readable objects are sensitive, since they can provide information that can be used to identify a person, alter the operating stability of the network, or alter/reveal the security configuration of a network. 
Currently writable objects can end up anywhere within a mib. To create a VACM view can require multiple include/exclude entries. It would be more efficient if mib writers separated their sensitive objects into subtrees of their mib, possibly in a hierarchy similar to 
sensitive :== { module-identity x } 
privacySensitive :== { sensitive 1 } // information privacy, not snmpv3 privacy 
stabilitySensitive :== { sensitive 2 } 
securitySensitive :== { sensitive 3 } 
Then, in the security section, define the VACM family view entries and VACM access entries for the sensitive objects. If binding to a particular access control mode is problematic, we could define a specification langauge similar to compliance groups to list the subtrees and their recommended level of sensitivity, that could be mapped to VACM easily.
This sounds simple, and I know it's not, but I think we could do better. 
dbh 
> -----Original Message----- 
> From: Wes Hardaker [mailto:wjhns1@hardakers.net] 
> Sent: Wednesday, November 06, 2002 7:37 PM 
> To: Wijnen, Bert (Bert) 
> Cc: mibs@ops.ietf.org 
> Subject: Re: FW: Updating the MIB security guidelines 
> 
> 
> >>>>> On Tue, 5 Nov 2002 23:56:32 +0100 , "Wijnen, Bert 
> (Bert)" <bwijnen@lucent.com> said: 
> 
> Bert> <list the tables and objects and state why they are sensitive> 
> 
> err...  I'm not really sure I like the notion of re-listing all the 
> objects (or even just the tables) in the mib file twice (once for 
> read-write and once for read-only) in the security section. 
> 
> Generally, a MIB piece houses a higher level notion of something, and 
> I think referring to that would be a better way to go than each 
> individual piece.  For example, if I was writing a security section 
> for the VACM MIB then I'd probably say "this MIB provides network 
> based configuration of the access control mechansims used by SNMP.  It 
> is critical the contents of this MIB be protected by authentication at 
> a minimum since illegitimate modifications to the objects within this 
> MIB will have a grave impact on ..."  IE, I wouldn't describe each 
> separate table of the MIB module since I don't think I don't really 
> think it would help and would only hinder understanding of it (since 
> you'd have to understand the data in the MIB to read the security 
> clause, which I'm not sure is the right thing to do). 
> 
> -- 
> "The trouble with having an open mind, of course, is that people will 
>  insist on coming along and trying to put things in it."   -- 
> Terry Pratchett 
>