Five Common Storage & Backup Security Misconfigurations

Managing an impeccable enterprise storage environment is a tough mission. Storage teams define configuration and security baselines – but lack the capability to continuously verify and enforce the baselines. This is hard for any storage environment, and even harder in a large-scale, heterogeneous, geographically dispersed storage environment. Our team at Continuity understands this challenge, and we created our StorageGuard solution to address it.

Out of the thousands of storage security configuration issues StorageGuard routinely checks for, we assembled here five common examples to share with our readers. We chose these five because almost all large organizations include them in their mandated security baselines for storage systems. However, inability to validate automatically (daily or post-change) that the storage configuration meets the baseline leads to hidden security gaps  – and indeed, when we work with enterprises to assess their Storage Security posture, we’d almost never fail to spot at least few of them.

Default accounts and passwords.

Storage systems are shipped with default administrative usernames and passwords that are known to all – aka factory settings.  Such powerful user accounts can be easily exploited by unauthorized employees and malicious actors to do some serious damage to your storage system, and to the data stored on it. Take particular care to get acquainted with the different storage subsystems and respective user accounts – it can get tricky as there are different accounts for the web client, CLI, controller, BIOS and so forth. Not all those accounts are necessarily visible, known to or used by your team, and could very well be active on your storage system, with the default password still in place, waiting for the right hacker.

If default accounts are not needed, disable them, and if they are, change the default password according to your organization’s password management standards.

Idle sessions not terminated.

It is highly important to terminate administrative sessions after a (not too long) period of inactivity. Open administrative sessions can potentially be hijacked by unauthorized personnel or intruders and used for malicious actions. Especially nowadays when many administrators are working from home, open administrative sessions to your storage system on home desktops can be a recipe for trouble.

Local users.

It is strongly advised to limit use of local user accounts to a minimal must-have set of accounts. That includes one local administrator account for an emergency situation when network services are not available; any default user accounts that the vendor unfortunately does not allow to remove or disable; accounts for services that may not support active directory – such as NDMP, SNMP. That’s it. Anything else should be carefully examined, and either removed or justified, and approved as an exception. Local users are notorious for reducing security in many ways: encouraging the use of “team” accounts that do not identify individuals, never-expiring and/or shared passwords, weak (and unmanaged) authentication policies, and more.

Incorrect zoning / masking (SAN).

Occasional zoning and masking mistakes often make LUNs accessible to unintended hosts. This also includes replicated copies and snapshots that are not always kept tightly secure, and can potentially be mounted by unauthorized clients. Zoning and masking misconfigurations can lead to additional issues such as mixing production and non-production data, spoofing risks and more. Review your zoning and masking configurations periodically and track configuration changes on an ongoing basis.

Incomplete audit logging configuration.

Many storage systems are not configured sufficiently for audit logging. This can come in many shapes and forms, from missing audit log content through not sending audit logs to central syslog servers, to using incorrect or even non-approved ones. Audit logs enable detection of brute force attacks and anomalies, allow investigation of incidents (forensics), can aid in recovery efforts and last but not least – are required for legal purposes.

And one more – Vulnerable Storage OS and Software.

While not as prominently as Host OS, Storage OS also suffers from common vulnerabilities and exposures (CVEs). Certain Storage OS versions have known vulnerabilities that can enable malicious actors to gain unauthorized access, to elevate permissions, to run arbitrary code and more. Take particular care to stay informed of new vulnerabilities in the storage domain and verify you are not running vulnerable storage software.  This may prove to be more complicated than anticipated, as modern storage systems have multiple underlying components and modules, each running a piece of versioned software. When reviewing, take into consideration embedded components (switches, controllers, board management), drivers, firmware, and – perhaps most important – storage management software, whether installed on the storage systems or on hosts in the datacenter. In case of the latter, take care to identify all hosts with storage management capabilities including host-installed storage CLI kits, storage management plugins and adapters and similar tools.

Learn more about StorageGuard