SCSI MIB - proposed security text

[Black_David@emc.com]

In response to Bert Wijnen's observation on lack of scope/coverage
in the SCSI MIB draft's security considerations text, here's proposed
new text for the Security Considerations section (with many thanks
to Keith McCloghrie for producing the text on short notice).  If
there are issues, please raise them here (Bert's comment is already
considered to be an IETF Last Call comment).  In the absence of
further comment, this text (without the edit tags in the left-hand
margin) will be put into the next (post-IETF-Last-Call) version
of the SCSI MIB draft.

Thanks,
--David (IPS WG chair)

This is a complete replacement for section 12 of the SCSI MIB draft;
the left-hand margin indicates "|" for modified, "+" for added.

  12.  Security Considerations
  
     There are a number of management objects defined in this MIB module
     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.  These are:
  
+    o  scsiInstAlias, scsiInstScsiNotificationsEnable, scsiInstStorageType
+       and scsiDeviceAlias: these objects can be manipulated to affect
+       the management of a SCSI instance and its devices; specifically,
+       the SCSI instance's administrative alias, whether it generates
+       notifications, whether its non-default parameter settings are
+       retained over restarts, and the administrative alias for each of
+       its devices.

     o  scsiIntrDevTgtAccessMode: this object can be manipulated to allow
        immediate access by local SCSI initiator devices to discovered
        SCSI target devices without waiting for administrator approval,
        where such approval might not be forthcoming.
  
     o  scsiDscTgtTable: the objects in this table can be manipulated to
        remove administrator-specified controls on access by local SCSI
        initiator devices to discovered SCSI target devices.
  
     o  scsiAuthorizedIntrTable: the objects in this table can be
        manipulated to remove administrator-specified controls on access
        by remote SCSI initiator devices to local SCSI target devices.
  
     o  scsiLunMapTable: the objects in this table can be manipulated to
        provide access by a remote SCSI initiator device to logical units
        which an administrator has configured as not accessible to said
        initiator.
  
|    In each of the last four cases above, the objects in the tables can
also be
     manipulated to cause a Denial-of-Service attack, by preventing
     administrator-authorized access.
  
     Some of the readable objects in this MIB module (i.e., objects with a
     MAX-ACCESS other than not-accessible) may be considered sensitive or
     vulnerable in some network environments.  It is thus important to
     control even GET and/or NOTIFY access to these objects and possibly
     to even encrypt the values of these objects when sending them over
|    the network via SNMP.  All seventeen of the tables in this MIB module
|    contain information which might be considered sensitive to read access
|    in some environments, e.g.,

|      - the settings of all read-write/read-create paremeter objects
|        mentioned above,
|
|      - scsiInstSoftwareIndex, scsiInstVendorVersion
|         -- which version of which software is running;

+      - scsiDeviceRole, scsiPortRole, scsiTransportType,
scsiTransportPointer,
+        scsiTransportDevName, scsiDscLunIdCodeSet, scsiDscLunIdAssociation,
+        scsiDscLunIdType, scsiDscLunIdValue plus information in several
+        tables: scsiTgtDevTable, scsiLuTable, scsiLuIdTable,
scsiLunMapTable
+         -- topology information indicating which devices/ports are
targets,
+            about the transport protocols they use, and more specific
+            information about such targets, including detailed information
+            about the LUNs they expose and how they are mapped onto Logical
+            Units;
 
+      - scsiIntrPortOutCommands, scsiIntrPortWrittenMegaBytes,
+        scsiIntrPortReadMegaBytes, scsiIntrPortHSOutCommands
+        scsiDscTgtInCommands, scsiDscTgtWrittenMegaBytes,
+        scsiDscTgtReadMegaBytes, scsiDscTgtHSInCommands, 
+        scsiTgtPortInCommands, scsiTgtPortWrittenMegaBytes,
+        scsiTgtPortReadMegaBytes, scsiTgtPortHSInCommands,
+        scsiAuthIntrAttachedTimes, scsiAuthIntrOutCommands,
+        scsiAuthIntrReadMegaBytes, scsiAuthIntrWrittenMegaBytes,
+        scsiAuthIntrHSOutCommands, scsiLuInCommands, scsiLuReadMegaBytes,
+        scsiLuWrittenMegaBytes, scsiLuHSInCommands 
+         -- statistics which could be used for traffic analysis.
 
+      - scsiAttTgtPortTable
+         -- information on which initiators are connected to which targets
+            which could be used for traffic analysis.
 
|      - scsiAuthorizedIntrTable and scsiAttIntrPortTable tables
|         -- information about which initiators are authorized to connect
|            to which targets. 

     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),
     including 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 then 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.



_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips