[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: Updating the MIB security guidelines
Bert,
http://www.ops.ietf.org/security.html still has the old
MIB security guidelines, which point to the now-obsoleted
RFC 2474 and RFC 2475. We need to get this replaced ASAP;
otherwise MIB authors are likely to put out-of-date stuff
in their documents. It would also be a very good idea to
announce the new security guidelines and boilerplate on
the IETF-Announce list as well as here.
With certain global editing changes (s/2570bis/3410/,
s/claise/clause/, s/inluding/including/) the template
that you posted previously (attached below) would be
OK; but there is one other change that I think would
improve it a lot. Juergen made the point earlier:
>>>>>> On Wed, 6 Nov 2002, Juergen Schoenwaelder wrote:
> > -- for all MIBs you must evaluate
> >
> > There are a number of managed objects in this MIB module with a
> > MAX-ACCESS claise of read-only and/or notify-only. Some of these
[ [ .... ] ]
>
> I think the evaluation which readable information is sensitive also
> applies to read-write and read-create objects since they are readable
> as well. So probably it is simpler to just say that the following
> evaluation has to be done for _all_ managed objects.
I agree with that. So may I suggest that you consider the following
language instead:
-- for all MIBs you must evaluate
Some of the readable objects in this MIB module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control even GET access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
<list the tables and objects and state why they are sensitive>
Note that "readable objects" covers read-write and read-create objects
as well as read-only objects, and so accomplishes Juergen's objective.
One last point: in many cases it's not possible to single out any
parrticular readable MIB objects as being especially sensitive, but
it is still the case that some users will not want the information
in the MIB module revealed indiscriminately. I hope that in such cases
it will be considered acceptable within the guidelines to say something
like this (the following example is intended for the Ethernet WIS MIB):
The readable objects in this MIB module may be considered sensitive
in some environments since, collectively, they provide information
about the performance of Ethernet interfaces and can reveal some
aspects of their configuration. In such environments it is important
to control even GET access to these objects and possibly to even
encrypt the values of these objects when sending them over the
network via SNMP.
Thanks,
Mike
---------- Original message ----------
Date: Tue, 5 Nov 2002 23:57:25 +0100
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: mibs@ops.ietf.org
Subject: FW: Updating the MIB security guidelines
So, I have been talking to some Security AD/IAB Security experts
I expect nmore input, but here is something that we can use as
a start.
It seems that RFC2669 actually has a very good security section
(using the old guidelines). Maybe something we need to point to
as an example? I did in a "comment" line.
The proposal below only references RFC2570bis.
What do people think of the below?
I would like to seem comments/responses/support/concerns
rather sooner than later.
Thanks.,
Bert
----------- draft new Security Guidelines for MIB documents ------
x. Security Considerations
-- if you have any read-write and/or read-create objects, please
-- describe their specific sensitivity or vulnerability.
-- RFC 2669 has a very good example.
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
<list the tables and objects and state why they are sensitive>
-- else if there are no read-write objects in your MIB module
There are no management objects defined in this MIB module that have
a MAX-ACCESS clause of read-write and/or read-create. So, if this
MIB module is implemented correctly, then there is no risk that an
intruder can alter or create any management objects of this MIB
module via direct SNMP SET operations.
-- for all MIBs you must evaluate
There are a number of managed objects in this MIB module with a
MAX-ACCESS claise of read-only and/or notify-only. Some of these
objects may be considered sensitive or vulnerable in some network
environments. It is thus important to control even GET access to
these objects and possibly to even encrypt the values of these
objects when sending them over the network via SNMP. These are
the tables and objects and their sensitivity/vulnerability:
<list the tables and objects and state why they are sensitive>
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network
is allowed to access and GET/SET (read/change/create/delete) the
objects in this MIB module.
It is RECOMMENDED that implementers consider the security features
as provided by the SNMPv3 framework (see [RFC3410], section 8),
inluding full support for the SNMPv3 cryptographic mechanisms
(for authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is a customer/operator
responsibility to ensure that the SNMP entity giving access to
an instance of this MIB module, is properly configured to give
access to the objects only to those principals (users) that have
legitimate rights to indeed GET or SET (change/create/delete) them.