How do hackers gain access to your core data? Storage systems may be the weakest link

Part 2 in a series of 4: The what, why, and how of securing storage and backup

In part 1 of this series, we discussed the difference between securing data and securing storage or backup infrastructure. Here we analyze specific risks to storage systems. We overview how storage attacks can occur, and highlight the industry’s knowledge gaps. Most organizations do not secure their storage, as they’re not aware of the risks. 

Your organization’s data is a lucrative target for hackers. Whether cybercriminals exfiltrate sensitive information, demand a ransom, or commit fraud, a successful attack could do irreparable damage.

“You have to remind your board, that it can take 20 years to build a strong reputation in your industry. It can take five minutes of a cybersecurity event – and enough press – to tear it all down.”
Endré Jarraux Walls – CISO, Customers Bank

Unlike traditional data-centered attacks that target endpoints and servers, modern attacks move to focus on storage and backup infrastructure—which many organizations do not secure—to easily access the core data.

Can you blame the hackers? Storage systems are left neglected, hence they can get to your crown jewels. 

A successful compromise at those levels enables attackers to wreak havoc “under the radar” of detection by any of the security measures or monitoring systems. Here are the main risks of such attacks:

• Criminal hackers duplicate sensitive environments (e.g., Active Directory, protected databases, the source code repositories), investigate them for weaknesses, and do reconnaissance. They do it with stealth, leaving no Indicators of Compromise.
• Cybercriminals destroy the data and its backup copies to prevent recovery.
• Attackers commit fraud by manipulating the storage plane without compromising operating systems or database servers, leaving no trace.
• The ability to bypass the software supply chain (internal or external).

A new research report on the state of storage security (due out in July) paints a grim picture: the average storage device or service (e.g., a storage array, a Fiber Channel Switch, or Virtual SAN) has 15 security misconfigurations, with at least 3 that are highly to critically severe. The report outlines the two most prevalent issues and the less common though risky ones.

Storage attacks surface is broader and deeper than pros might suspect

It is tempting to think that you could solve your storage security concerns by patching clients (Host Operating Systems) and making sure there’s a backup solution in place. This thinking is obvious but totally misguided. Security hackers breach storage infrastructure in many creative not to say exotic ways:

• They do it via protocols that clients and storage devices use.
• They do it through management consoles.
• Attackers leverage local admin APIs or the control endpoints that each device provides (which organizations often have not hardened).
• They ravage weak storage security hygiene:
  • Not closing default device accounts; using local accounts instead of centrally managed ones
  • Not restricting access to sensitive data (you should enforce such restrictions end-to-end—at the storage device, on the network, and at the client level, using strong authentication)
  • Not securing admin sessions
  • Poorly configured (or overlooked) encryption
  • And so much more

NIST’s Special Publication (SP) 800-209 “Security Guidelines for Storage Infrastructure” is a great source to learn more about storage security.

Exploring through real-life examples:

Here are a few real-life examples of how hackers exploited poorly secured storage and backup environments:

• They discovered a Domain Controller or DNS server IP address through a weakness in the environment >> If you have not hardened your storage, attackers can abuse your APIs (or hijack insecure admin sessions, exploit unpatched storage CVEs) to find out what storage objects (e.g., LUNs, Shares) those services use. They can leverage the APIs to create copies, mount them on unmonitored development servers, or smuggle them out via OneDrive, public S3 buckets, or similar tools.

• They discovered how an enterprise backups the data and then they destroyed the backups>> if you have not segregated your administration plans hackers can destroy the backups (e.g., array-based snapshots, disk, and tape copies). Then they encrypt your data for ransom.

• An enterprise that did secure backups, but didn’t build enough isolation of duties, played to the field of cybercriminals that “poisoned” any future backup (e.g., change the backup job, remap the LUNs in the backups).

• Criminal hackers mapped volumes that critical servers use (for source code, databases, build environments) to other compromised servers. Then they read or altered the content (e.g., financial data, personal information) “out of band,” leaving no evidence.

• Hackers “killed” an entire storage array (including its snapshots), crippling hundreds of servers for days.

The above scenarios explain why so many CISOs are insisting on running an evaluation of their storage security IQ, processes, and controls.