This text may need changes if new RFCs are published. In general, if you think this text needs changes, please send an email message to the mibs@ops.ietf.org mailing list.
x. Security Considerations
-- if you have any read-write and/or read-create objects
There are a number of management objects defined in this MIB that
have 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.
-- else if there are no read-write objects in your MIB
There are no management objects defined in this MIB that have a MAX-
ACCESS clause of read-write and/or read-create. So, if this MIB is
implemented correctly, then there is no risk that an intruder can
alter or create any management objects of this MIB via direct SNMP
SET operations.
-- for all MIBs you must evaluate
There are a number of managed objects in this MIB that may contain
sensitive information. These are:
< list the objects and state why they are sensitive >
It is thus important to control even GET access to these objects and
possibly to even encrypt the values of these object when sending them
over the network via SNMP. Not all versions of SNMP provide features
for such a secure environment.
-- for all MIBS you must include:
SNMPv1 by itself is not a secure environment. 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.
It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2574 [RFC2574] and the View-
based Access Control Model RFC 2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, 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.
y. References
[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model for the Simple Network Management
Protocol (SNMP)", RFC 2575, April 1999.
.ad l
.in 0
.sp
x. Security Considerations
.sp
.in 3
.ti 0
-- if you have any read-write and/or read-create objects
.sp
There are a number of management objects defined in this MIB
that have 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.
.sp
.ti 0
-- else if there are no read-write objects in your MIB
.sp
There are no management objects defined in this MIB that have
a MAX-ACCESS clause of read-write and/or read-create. So, if
this MIB is implemented correctly, then there is no risk that
an intruder can alter or create any management objects of this
MIB via direct SNMP SET operations.
.sp
.ti 0
-- for all MIBs you must evaluate
.sp
There are a number of managed objects in this MIB that may
contain sensitive information. These are:
< list the objects and state why they are sensitive >
It is thus important to control even GET access to these objects
and possibly to even encrypt the values of these object when
sending them over the network via SNMP. Not all versions of
SNMP provide features for such a secure environment.
.sp
.ti 0
-- for all MIBS you must include:
.sp
SNMPv1 by itself is not a secure environment. 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.
.sp
It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the
use of the User-based Security Model RFC 2574 [RFC2574] and the
View-based Access Control Model RFC 2575 [RFC2575] is recommended.
.sp
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, 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.
.bp
.ti 0
y. References
.sp
.in 13
.ti 3
[RFC2574]
Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
.sp
.ti 3
[RFC2575]
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model for the Simple Network Management Protocol (SNMP)",
RFC 2575, April 1999.