We are firmly entrenched in the digital economy. The bits and bytes that fuel it don’t just represent dollars or yen or pounds. They represent people. People who are actually impacted by these breaches in ways we may never know, because it doesn’t get reported.

How and Why is this Happening?

Why would someone intentionally compromise their security when configuring S3 buckets and cloud databases, making them public-facing? In our experience, the culprits are rarely on the operations side:

network engineers, database administrators, systems engineers, and security engineers would know better than to do this.

• Network engineers, typically responsible for managing access to systems over the network and determining which systems are pubic-facing, would not generally allow a database to be public-facing.
• Database administrators, typically responsible for managing database access and account permissions, would not allow databases to be accessed without requiring authentication. They would take on enterprise password policies with standard complexity requirements and not allow weak passwords.
• System engineers, typically responsible for managing applications to the defined hardening standards, would manage a web server in front of the public-facing database and would ensure its was properly secured with a web application firewall.
• Security engineers would normally conduct independent assessments of all systems and the network to ensure compliance with the security policy.

More often, the product development side might decide not to incorporate already-existing security features—in many cases because they don’t want to disrupt the revenue stream, either by pushing back the timeline or potentially introducing new bugs.

Moving to the cloud enables developers to circumvent traditional enterprise IT roles that are obviously needed, considering the growing number of cloud breaches. That sets up the perfect storm for devs to deploy systems with poorly-configured security features, not because they want to, but because they might not understand the consequences or they might assume that a breach is unlikely to happen.

What You Can Do to Avoid Cloud Breaches

How do we fix this problem? No one is suggesting we go back to long, extended delays in deploying systems (a common dev complaint). At the risk of doing time in Buzzword Jail for this, maybe as an industry we should start talking about DevSecOps as a discipline to infuse good security practices into development. All teams clearly need to be included in the conversation. Only limited security reporting is available in default cloud deployments: there are no trusted network engineering or systems engineering teams from which to request a list of subnets and ACLs, and no Active Directory groups and permissions. In most public clouds, organizations need to buy third-party cloud security auditing tools to produce the reports the security team would normally have gotten from their internal counterparts.

Yes, security is hard. Yes, security sometimes slows things down. But intentionally ignoring or degrading security because it’s more convenient or speeds up the process is simply unacceptable and quite possibly unethical. Real people can be impacted, and not just financially. That’s real people, not just the digital incarnations they entrust to companies on a daily basis.

It’s time to stop referring to these exposures as the result of misconfiguration and start calling them what they are: intentional and deliberate insecurity. More importantly, InfoSec professionals need to call out these poor practices more firmly. Perhaps with a reminder that poor security practices impact people and not just the processes they’re used to avoid or circumvent.