From the headlines (“MongoDB ransacked: Now 27,000 databases hit in mass ransom attacks“), it would be easy to conclude that MongoDB is weak on security. It would also be wrong. Though ransomware attacks on the popular NoSQL database are mounting, the fault lies less with the database itself and more with those who deploy it.

Before we start blaming IT for this mess, Gartner analyst Nick Heudecker has warned that it’s worth considering that IT may never have known about the exposed databases in the first place, revealing the downside to the “developers are the new kingmakers” mantra that fuels so much technology adoption today. Unless DevOps-style developers start to think as much about “ops” as they do about “dev,” big data and the data infrastructure that fuels it will be at risk for big problems.

What, me worry about security?

One of the reasons that MongoDB has quickly risen to become one of the world’s most popular databases is its positive impact on developer productivity. With a flexible schema and the ability to code in the language of one’s choice, MongoDB makes it much easier for developers to harness big data.

SEE: How public cloud providers are making security a non-issue for app developers

Unfortunately, that ease of use may have negative consequences. As Ovum analyst Tony Baer suggested, “[I] have always wondered if we [might not] make sophisticated systems too easy to the point where the inmates run the asylum.” For enterprises running MongoDB, those inmates just resulted in a doubling of compromised systems (from roughly 12,000 to 27,633) in just one day, with hackers demanding payment to release pilfered data.

The reason almost certainly comes down to an absence of IT security practices. As Heudecker told me, “‘IT’ may not have known about these [MongoDB]instances. Dev[elopers] just download & deploy with no thought to security or management.”

Unfortunately, it’s not likely to get better. One answer might be to engineer security into public cloud services, thereby forcing developers to embrace security (with the cloud provider basically becoming “loco parentis,” as Baer noted). But, as former MongoDB executive Kelly Stirman countered, “if your market is developers, who clearly don’t prioritize security for these instances, would [baked-in security] be of value?”

In short, MongoDB will wrongly get accused of being weak on security, when really the problem is the developers who use it. However, MongoDB isn’t alone.

Big data, but no big security

Back in 2014, Gartner analyst Merv Adrian slammed the “nearly non-existent response” to Hadoop’s “security issue,” dubbing the neglect “shocking.” Two years later, things are better, but not dramatically so. As Bolke de Bruin, head of research and development for ING Bank, posited, the Hadoop world has gotten better at ensuring security within Hadoop clusters, but continues to fail at ensuring data integrity (i.e., “maintaining and assuring the accuracy and completeness of data over its entire lifecycle”).

SEE: MongoDB ransacked: Now 27,000 databases hit in mass ransom attacks (ZDNet)

This is a failure of both IT operations and developers as both rush to embrace big data without ensuring a commensurate level of big security.

One would think that this problem would resolve itself as the software gets hardened over time. Yet, given the pace at which big data infrastructure is changing, shifting from Hadoop to Spark to [insert funky name of your favorite new big data project], security isn’t catching up with the volume, velocity, and variety of data.

Today it’s MongoDB getting the black eye for our unwillingness to take the time and effort to secure sensitive data. Tomorrow it will be some other data infrastructure. The problem isn’t the tools. It’s us.