Critical Aspects of DCIM Security

Encryption and architecture must be applied together to achieve a truly secure DCIM solution. Encryption protects data during transmission (or at rest for database encryption). Architecture is a careful design and data flow engineered to remove risks, typically by limiting points of access to the system.

Let’s look at the top five aspects of DCIM security and how encryption and architecture are applied:

1. Local data collection from devices reduces risk

Data collected from devices should be collected “at the edge” and encrypted in transport.  This data should be collected and encrypted as close to the target device as possible as a best security practice.

If you access a device from another location (including VPN) to collect monitoring data, the risk is much higher than an architecture that collects the same data across segments of the network. When possible, data should be collected physically and logically (network) as close to the asset as possible – on the same subnet, at the same location.

Your DCIM solution should be able collect data at the edge, reducing the exposure of the device itself. Direct access to the device does not have to be exposed to the internet, or even across external subnets if you collect the data from within the device’s local subnet.

2. Encryption and DCIM data transmissions

The data from a device (such as power load on a PDU or power strip) is not particularly sensitive, but the transactions can contain sensitive data – like the IP address of the device. This information can be used to target the device in a network attack.

Some protocols do not support security, like Modbus and SNMP v1. When possible, encrypted protocols should be used, such as SNMP v3, to ensure the device’s login credentials are not exposed.  If this is not possible, the concept of collecting “close to the device” becomes critical to protecting the data exchange.  Modbus queries should not span networks or subnets without encryption. When accessed remotely these connections should be across a secure connection like a VPN.

It is critical that your DCIM solution encrypts data, regardless of the data protocol, or where the data is collected. This ensures that the information is protected, regardless of whether it is transmitted across a local network, secure VPN, or any other connection.

3. Data storage

Once the data is collected, the transmission from the collector to the main application should be encrypted and secure as well – to protect details and device addresses within the data.

For the highest security requirements, data should be encrypted at rest.  To achieve this, the database solution must support full database encryption.

A secure DCIM solution should be built on a database, like Microsoft SQL Server, that can be encrypted in the data store and accessed via a secure connection.

4. Data sharing – SLA transparency requirements

Hyperscalers now have data transparency requirements when renting space from colocation providers.  These requirements include access to raw telemetry data from the most critical power distribution assets. Many of these assets use protocols like Modbus, which introduces significant risk if the devices are exposed directly to the customer.

This data must be provided without adding risk – and a next generation DCIM solution can fill this role. Using the read-once-use-many approach, the data can be shared to the external customer via the DCIM, without adding risk by exposing direct access to the hardware (if your DCIM solution supports an API and point publishing).

5. Application access

Network applications must have secure access. This includes encrypted web services, logins, and support for MFA (multi-factor authentication). Any API or other service must provide a secure, strongly protected interface. Your DCIM solution should support security and authentication across these services.

A DCIM solution should provide high granularity access control to limit the devices and data available to any given user.  This provides compliance with the Principle of Least Privilege (PoLP) to minimize risk. This principle is required for many government service contracts and certifications like CMMC.

The Principle of Least Privilege includes the ability to limit which devices an operator can access, and which rights (read, acknowledge alarms, close alarms, etc.) that have on each device across your infrastructure.