Skip to main content

11.5. Access to the SNMP-USER-BASED-SM-MIB

11.5. Access to the SNMP-USER-BASED-SM-MIB​

This section provides recommendations for controlling access to the objects in the SNMP-USER-BASED-SM-MIB module.

Overview​

The SNMP-USER-BASED-SM-MIB contains sensitive security-related information, including:

  • User names and security parameters
  • Authentication and privacy protocol identifiers
  • Mechanisms for changing keys
  • Statistical counters

Inappropriate access to these objects could compromise the security of the entire SNMP management system.

Access Control Requirements​

Access to the SNMP-USER-BASED-SM-MIB MUST be controlled using the View-based Access Control Model (VACM) [RFC3415] or another access control mechanism of equivalent strength.

The following access control guidelines are recommended:

1. usmUserTable - User Configuration Table​

Read Access:

  • Users SHOULD be able to read their own entry in the usmUserTable
  • Administrators SHOULD be able to read all entries
  • General users SHOULD NOT be able to read other users' entries

Write Access:

  • Users SHOULD be able to modify certain objects in their own entry:
    • usmUserOwnAuthKeyChange - to change their own authentication key
    • usmUserOwnPrivKeyChange - to change their own privacy key
    • usmUserPublic - a general-purpose writable object
  • Administrators SHOULD be able to:
    • Create new users via usmUserCloneFrom and usmUserStatus
    • Modify usmUserAuthKeyChange and usmUserPrivKeyChange for all users
    • Delete users by setting usmUserStatus to destroy(6)
  • General users SHOULD NOT be able to modify other users' entries

2. usmUserSpinLock​

  • Read Access: All authenticated users
  • Write Access: Only administrators or users authorized to modify usmUserTable

The usmUserSpinLock is used to coordinate access to the usmUserTable when multiple managers attempt simultaneous modifications.

3. usmStats Group - Statistics Counters​

Read Access:

  • SHOULD be readable by administrators and monitoring applications
  • MAY be readable by general authenticated users for diagnostic purposes

Write Access:

  • SHOULD NOT be writable by any user (these are read-only counters)

The statistics counters provide valuable information for:

  • Security monitoring and intrusion detection
  • Troubleshooting authentication and time synchronization issues
  • Capacity planning

4. Key Management Objects​

The following objects require special protection:

  • usmUserAuthKeyChange and usmUserPrivKeyChange: These objects allow administrators to change any user's keys. Access should be strictly limited to trusted administrators.
  • usmUserOwnAuthKeyChange and usmUserOwnPrivKeyChange: These objects allow users to change their own keys. Each user should have write access to these objects in their own entry only.

Important: These objects use a special key change protocol (described in section 5 of the MIB module) to ensure that keys cannot be intercepted or disclosed during the change operation.

View Configuration Example​

A typical VACM configuration might include:

  1. Administrator View: Full read-write access to the entire usmUserTable and read access to usmStats

  2. User Self-Management View: Read access to own entry in usmUserTable, write access to usmUserOwnAuthKeyChange and usmUserOwnPrivKeyChange in own entry

  3. Monitoring View: Read-only access to usmStats group for security monitoring

  4. Restricted View: No access to usmUserTable, limited or no access to usmStats

Security Considerations for MIB Access​

  1. Prevent Enumeration: Restricting read access to usmUserTable prevents attackers from enumerating valid user names.

  2. Protect Key Change Operations: Even though keys themselves are never directly readable, the key change mechanism should be protected to prevent unauthorized key changes.

  3. Monitor Statistics: Regular monitoring of usmStats counters can help detect:

    • Brute-force authentication attempts (usmStatsWrongDigests)
    • Time synchronization problems (usmStatsNotInTimeWindows)
    • Attempted use of unknown users (usmStatsUnknownUserNames)

  4. Audit Log Integration: Consider integrating SNMP security events (derived from usmStats changes) into enterprise security information and event management (SIEM) systems.

Initial Configuration​

During initial configuration of an SNMP engine:

  1. At least one initial user with full administrative privileges MUST be configured.
  2. This initial user should be configured via a secure out-of-band mechanism (e.g., local console access).
  3. Once the initial user is configured, additional users can be created via SNMP using the usmUserCloneFrom mechanism.
  4. The initial user's credentials should be changed immediately after first use if the default credentials were used during bootstrapping.
Last updated on