SNMP Functionality of Vormetric Data Security Manager (DSM)

Key Takeaways

• DSM can act as an SNMP agent that answers GET requests on port 7025 (its default) or 161, returning values from a Vormetric-specific set of OIDs.
• DSM supports SNMPv1 and SNMPv2c only. It has no SNMPv3 support and does not support SNMP traps, so monitoring is poll-based, not push-based.
• The community string defaults to “public” and must be changed. The SNMP access control list (ACL) should be scoped to known monitoring hosts, never left empty.
• Vormetric DSM reached end of support from Thales on June 30, 2024. Current deployments run on CipherTrust Manager, DSM’s successor platform.
• Encryption Consulting built a shell script for a customer that automates querying these OIDs from a Linux or Unix host.

Published: September 2022. Updated: August 2026. Reviewed by Encryption Consulting’s key management operations team.

What Is SNMP, and Why Does Vormetric DSM Support It?

Simple Network Management Protocol (SNMP) is a networking protocol used on Internet Protocol networks to manage and monitor network-connected devices. It is an application-layer protocol in the OSI model, and it is embedded in routers, switches, servers, firewalls, and other IP-addressable devices, giving them a standard mechanism to report management information within single-vendor and multi-vendor LAN or WAN environments.

There are three versions of SNMP in use today: SNMPv1, SNMPv2c, and SNMPv3. Vormetric Data Security Manager (DSM), Thales’ encryption key and access-policy management platform for Vormetric Transparent Encryption agents, implements SNMP as an agent so an operations team can check basic health and status without building custom vendor-specific tooling. DSM itself supports SNMPv1 and SNMPv2c; it does not support SNMPv3. That distinction matters for how this platform should be hardened, and it is covered in detail below.

DSM is the legacy generation of this product line. The current generation, which most new deployments run today, is Thales CipherTrust Manager. Organizations still operating DSM, and those planning or completing an upgrade, both need to understand how its SNMP functionality behaves, which is the focus of this article.

What Are the Core Components of SNMP?

SNMP performs its basic tasks through four building blocks:

SNMP Agent

An SNMP agent is a software process that responds to SNMP queries with a network node’s status and statistics. It runs locally on the monitored device, collects and stores data, and transmits it to the requesting SNMP manager when queried.

SNMP Manager

The SNMP manager, sometimes called the SNMP server, is responsible for communicating with SNMP agents across the network. It queries agents, receives their responses, sets variables where the agent allows it, and acknowledges events reported back to it.

Management Information Base (MIB)

The Management Information Base (MIB) is a text file, typically with a .mib extension, that describes every data object a specific device exposes for query or control through SNMP. Each managed object inside the MIB is identified by an Object Identifier.

Object Identifier (OID)

An Object Identifier (OID) is a dotted list of integers that uniquely names a managed object. OIDs come in two forms, scalar and tabular, and MIBs organize every OID hierarchically, as a tree with an individual variable identifier for each object.

What Does DSM’s SNMP Functionality Actually Monitor?

DSM can be enabled as an SNMP agent and then monitored by an external SNMP server using the MIB objects it exposes. When DSM receives an SNMP GET request, sent to port 7025 or port 161, it locates the matching OID entry in its MIB and returns the corresponding value to the requesting SNMP server.

SNMP is enabled from the System > SNMP page on the Configuration tab. If the SNMP access control list (ACL) is left empty, DSM acknowledges SNMP requests from any IP address. If the ACL is populated with specific IP addresses or address blocks, DSM only acknowledges requests originating from those entries.

The community string ships with a factory default value of “public.” This string must match across every device participating in the same SNMP monitoring group, and it functions as the only credential SNMPv1 and SNMPv2c check before answering a query. For that reason, it should always be changed from the default to a custom value.

SNMP traps are not supported and cannot be configured on DSM. DSM is a poll-only SNMP agent: it answers requests but never initiates an unsolicited notification. The detection implications of that design choice are covered in the detection section below.

The table below lists the Vormetric-specific OIDs a monitoring server can query, all found under the Vormetric MIB. These OID values cannot be changed manually. Two System Group MIB objects, sysContact and sysLocation, are customizable and are not part of this Vormetric-specific set.

OID	Description
1.3.6.1.4.1.21513.1.0	Returns the version details of the DSM
1.3.6.1.4.1.21513.2.0	Returns the fingerprint of the current DSM deployment
1.3.6.1.4.1.21513.3.0	Returns the current date and time on the DSM
1.3.6.1.4.1.21513.5.0	Returns the agent type (FS or Key agent), the license installation state (true or false) for each agent type, and, for each installed license, the license expiration date
1.3.6.1.4.1.21513.6.0	Returns the name of each node in a DSM HA cluster configuration
1.3.6.1.4.1.21513.7.0	Returns disk usage information for each file system mounted on the DSM
1.3.6.1.4.1.21513.8.0	Returns DSM process, memory, paging, I/O, and CPU usage information

Which SNMP Versions Does DSM Support, and What Are the Security Tradeoffs?

SNMPv1 and SNMPv2c authenticate every request with nothing more than the community string, and that string travels in plaintext on the wire. Anyone who can observe traffic on the same network segment, or who guesses a default value like “public,” can read or, in some configurations, write monitoring data with no further barrier. SNMPv2c added 64-bit counters and bulk-retrieval operations over SNMPv1, but it made no change to this authentication model.

SNMPv3, standardized in the IETF’s STD 62 document set (RFC 3411 through RFC 3418), replaces the community string with the User-based Security Model (USM, RFC 3414), which supports per-user authentication and message encryption, and the View-based Access Control Model (VACM, RFC 3415), which restricts each user to a defined subset of the MIB. Where a platform supports SNMPv3’s authPriv security level, queries are authenticated and encrypted end to end, closing the plaintext exposure that SNMPv1 and SNMPv2c carry by design.

DSM itself only implements SNMPv1 and SNMPv2c. There is no SNMPv3 option on DSM, which is exactly why the ACL and community-string hardening covered later in this article carry more weight on this platform than they would on a device where SNMPv3 is available and simply needs to be turned on.

Property	SNMPv1	SNMPv2c	SNMPv3
Authentication	Community string, plaintext	Community string, plaintext	Per-user credentials (USM)
Encryption in transit	None	None	Optional, via authPriv
Access control granularity	All-or-nothing per community	All-or-nothing per community	Per-user MIB views (VACM)
Bulk retrieval / 64-bit counters	Not supported	Supported	Supported
Supported on Vormetric DSM	Yes	Yes	No

What Is the Impact of a Misconfigured SNMP Deployment?

An empty ACL combined with the default “public” community string means any host that can reach port 7025 or 161 can pull DSM’s version, fingerprint, license state, HA cluster node names, and resource usage without authenticating as anything more than a guessed default value. Version and fingerprint data are exactly the kind of reconnaissance information an attacker wants before targeting a known vulnerability in a specific release, so exposing them to an unrestricted network is a real, not theoretical, risk.

Because SNMPv1 and SNMPv2c send the community string in plaintext, anyone positioned to sniff traffic on the same segment as an SNMP query can capture that string and reuse it to poll DSM at will, even after the ACL is tightened, if the string itself is never rotated. Combined with an open ACL, a misconfigured SNMP deployment turns a monitoring feature into an unauthenticated information-disclosure path, and, on any device where SNMP also supports SET operations, a potential configuration-tampering path as well.

How Do SNMP Alerts Support Detection of Operational and Security Issues?

Because DSM does not support SNMP traps, detection here is polling-based rather than push-based: an SNMP manager or monitoring platform queries the OIDs above on a set interval and flags values that cross a threshold or change unexpectedly. In practice that means:

• Disk usage OIDs approaching capacity signal a storage problem before it causes an outage.
• The license expiration data returned by the license-state OID gives advance warning of an agent license lapsing.
• The HA cluster node-name OID missing an expected node flags a cluster member that has dropped out.
• CPU, memory, paging, and I/O OIDs spiking outside baseline point to a performance issue or an unexpected process load worth investigating.
• A DSM node that stops answering SNMP GET requests at all is itself a signal, since polling failure is the closest thing to an alert this design produces.

Because there is no trap-based push notification, detection speed is bounded by the polling interval the monitoring server is configured with. A five-minute poll cycle means up to five minutes of blind spot after an event occurs. That tradeoff is worth naming explicitly in the limitations section below, and it is one more reason to pair SNMP polling with DSM’s own audit logging rather than treat SNMP as a complete monitoring solution on its own.

SNMP Hardening Checklist for Vormetric DSM

1. Replace the default “public” community string with a unique, non-dictionary value immediately after enabling SNMP.
2. Populate the SNMP ACL with only the IP addresses of your actual monitoring servers. Never leave it empty.
3. Restrict SNMP access at the network layer too, with a firewall rule limiting port 7025 and 161 to the monitoring subnet, rather than relying on the DSM ACL alone.
4. Wherever the platform you are running does support SNMPv3, always use it with authentication and privacy (authPriv) rather than SNMPv1 or SNMPv2c. Confirm the SNMP versions supported in the admin guide for your specific DSM or CipherTrust Manager release before assuming SNMPv3 is or is not available.
5. Treat OID output as sensitive. Version, fingerprint, and license data are useful reconnaissance for an attacker, so protect the monitoring path itself, not only the appliance being monitored.
6. Rotate the community string on a schedule and after any administrator turnover, the same way you would rotate any other shared credential.
7. Since DSM does not support traps, set a polling interval short enough to catch disk, license, and cluster problems before they escalate, and alert on a node that stops responding to SNMP GET requests.
8. Review SNMP query source IP addresses periodically to catch scanning activity or polling from a host that is not on the approved monitoring list.

Update Log: DSM’s Naming and End-of-Support Status

Vormetric Data Security Manager reached end of support from Thales on June 30, 2024. Organizations still running DSM in production are operating past that date on an unsupported platform, and Thales positions CipherTrust Manager, along with the CipherTrust Data Security Platform Connector family, as the migration path forward.

This article keeps the “Vormetric DSM” name because that is the deployed reality for organizations still running legacy instances, and because that is how readers search for this exact SNMP behavior. Where a platform has already been upgraded, the same SNMP concepts, agent, MIB, OID, ACL, community string, apply to CipherTrust Manager’s own SNMP configuration page, and version-specific details, including whether SNMPv3 is available in your installed release, should be verified directly against the admin guide for that release rather than assumed from this article. Encryption Consulting’s guide to upgrading from Vormetric DSM and migrating to CipherTrust Manager covers that broader transition.

What Are the Limitations of SNMP Monitoring on DSM?

• This article reflects publicly documented DSM administration guidance. It is not a substitute for the SNMP configuration page in your specific DSM or CipherTrust Manager release, since exact OIDs, default ports, and supported versions can change between releases.
• We could not confirm from public Thales documentation whether current CipherTrust Manager releases add SNMPv3 support beyond what DSM offers. Treat that as something to verify in your version’s admin guide rather than assume either way.
• DSM’s SNMP implementation is read-only monitoring. It is not a substitute for centralized log management, SIEM integration, or DSM’s own audit logging for security-relevant events such as key access or policy changes.
• Detection through SNMP polling is only as fast as the configured poll interval, since DSM has no trap-based push notification.
• The OID table above reflects the Vormetric-specific MIB documented in the Thales administration guide. It is not exhaustive of every System Group MIB object DSM exposes.

Shell Script

Encryption Consulting recently developed a shell script for one of its customers, leveraging DSM’s SNMP functionality to automate the process of pulling the parameters covered above. It can be run remotely from a Linux or Unix host and includes the commands needed to query DSM using the OIDs listed in the table.

What Would Encryption Consulting Recommend?

SNMP polling gives you a useful, low-effort signal on DSM or CipherTrust Manager uptime, disk, license, and cluster health, but it is not a complete operations program by itself, and it is not designed to catch every security-relevant event on its own. We would treat it as one input alongside DSM’s own audit logs and, where the platform supports it, SIEM integration, rather than the only monitoring layer protecting a key management platform.

For teams still running DSM past its June 2024 end-of-support date, or managing a CipherTrust Manager environment across multiple clusters and clouds, that operational discipline is usually easier to sustain with dedicated support than with a single admin’s custom scripts. Encryption Consulting’s Encryption Advisory Services and HSM-as-a-Service both cover key management platform operations, including hardening, monitoring, and migration planning for Vormetric DSM and CipherTrust Manager environments; see also our writeup on the operational reasons teams seek dedicated CipherTrust Manager support. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified, and our advisory work sits alongside the same key management infrastructure this article describes.

Frequently Asked Questions

Does Vormetric DSM support SNMPv3? No. DSM supports only SNMPv1 and SNMPv2c, both of which authenticate requests with a plaintext community string. There is no SNMPv3 option on DSM, so hardening relies on a tight ACL, a non-default community string, and network-layer restrictions instead.

What port does DSM listen on for SNMP requests? DSM answers SNMP GET requests on port 7025 by default, or on the standard SNMP port 161, depending on configuration.

Does DSM support SNMP traps? No. DSM only answers SNMP requests; it cannot send unsolicited trap notifications. Monitoring is polling-based, so the polling interval determines how quickly a change is detected.

Is Vormetric DSM still supported by Thales? No. Vormetric DSM and its agents reached end of support on June 30, 2024. Thales positions CipherTrust Manager and the CipherTrust Data Security Platform Connector family as the migration path for organizations still running DSM.

What is the default DSM SNMP community string, and why must it be changed? The factory default is “public.” Because SNMPv1 and SNMPv2c treat the community string as their only credential, and send it in plaintext, leaving it at the default effectively removes authentication for anyone who can reach the SNMP port, which is why it should be changed to a unique value as soon as SNMP is enabled.

Conclusion

Configuring SNMP on Vormetric DSM gives an SNMP server useful visibility into contact information, physical location, version, fingerprint, server time, license and HA configuration, and disk and system usage, all through a small set of Vormetric-specific OIDs. But DSM’s SNMP implementation only supports the older, plaintext SNMPv1 and SNMPv2c versions and has no trap support, so the functionality has to be enabled deliberately, behind a scoped ACL and a non-default community string, rather than turned on with factory defaults. With DSM itself past its June 2024 end-of-support date, treat this SNMP behavior as a bridge for legacy environments and plan the underlying migration to CipherTrust Manager alongside it.

References

• Thales Vormetric DSM Administration Guide, thalesdocs.com
• Vormetric Data Security Manager product and end-of-support page, Thales Group
• RFC 1157: A Simple Network Management Protocol (SNMP), IETF
• RFC 3411: An Architecture for Describing SNMP Management Frameworks, IETF
• RFC 3414: User-based Security Model (USM) for SNMPv3, IETF
• RFC 3415: View-based Access Control Model (VACM) for SNMP, IETF