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
>