Re: FW: Updating the MIB security guidelines

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Wijnen, Bert (Bert) writes:

Bert> The proposal below only references RFC2570bis.

Bert> What do people think of the below?  I would like to seem
Bert> comments/responses/support/concerns rather sooner than later.

Looks good. Some minor comments below.

> 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.

I think you should say "alter, create or delete" instead of just
"alter or create".

> -- 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.

>    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

     including

>    (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.


/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>