People Are Not IP Addresses…So Why Do Security Solutions Think They Are?

By Jason Garbis, Vice President of Products, Cryptzone

Attackers are erasing database contents and replacing them with a note demanding Bitcoin ransom payment for restoration. It also appears that victims who pay are often not getting their data back, and that multiple attackers are overwriting each other’s ransom demands. Seriously, these databases are of course important to their owners, and these attacks are clearly a headache for them. Hopefully they have backups. Let’s explore this situation a bit more, and then step back for some analysis. Here's What We Know There is no indication of a vulnerability in MongoDB; rather these systems are allowing administrative access from any IP address, and are (mis)configured for either no authentication or default credentials. There are a large number of such systems – Internet service search engines show approximately 100,000 exposed instances, and several independent security researchers have identified over 27,000 instances that have been hijacked as of January 8, a number that’s growing daily. Putting aside the mistaken configuration that enabled access with no/weak authentication, let’s look at this from a user access and network perspective. At the risk of being too obvious, these systems are Internet-facing either intentionally or unintentionally. If intentional, their admins clearly require remote access, and therefore these systems must expose some network service.

“People are not IP addresses!" — Jason Garbis, Vice President of Products at Cryptzone

The problem comes down to how access is restricted – and a realization that relying solely on authentication is not enough. Too many systems are either misconfigured (as appears to be the case with these MongoDB) or are subject to vulnerabilities – enterprises need to limit access at a network level. The issue is that network security tools are built around controlling access by IP address, yet the problem we need to solve is how people (identities) access these systems. And people are not IP addresses!

If these databases were unintentionally exposed to the Internet, then no remote access is required – either admins have local system access, or they’re relying on another security mechanism such as being on a LAN or accessing the network through a VPN. Yet, these systems are exposed directly to the Internet, and therefore not likely on an internal corporate network. Looking at the discovered instances on Shodan, it appears that many of them have IP addresses associated with cloud or hosting providers!

This is an interesting pattern. Because cloud network access is managed by IP addresses, users may be simply setting their cloud network security groups to permit access from anyone on the internet – much to their detriment, as this attack shows.

Clearly, misconfiguring a database to not require authentication is a problem, but there are many exploits that exist even in properly secured and properly configured systems. It’s time to realize that the bigger problem is in allowing unauthorized users to have network access to these systems in the first place. Why are there 100,000 instances of MongoDB available for a public scan? I suggest that most of these were not intended for public access.

The ability to access a service on the network is a privilege, and it must be treated as such. The principle of least privilege demands that we prevent unauthorized users from scanning, connecting to, or accessing our services. Following this principle will dramatically reduce the ability of attackers to exploit misconfigurations or vulnerabilities.

But there’s a problem. There is a disconnect between how we need to model users – as people – and our network security systems, which are centered on IP addresses. And, to repeat myself, people are not IP addresses.

Let's Bring This Together

Organizations need to secure network access in an identity-centric way, and in a way that’s driven by automated policies so that users – who are people – get appropriate access. Network security systems must be able to do this, and allow us to easily limit user access to the minimum necessary.

The good news is that this is achievable today. The Software-Defined Perimeter (SDP) – an open specification published by the Cloud Security Alliance – defines a model where network access is controlled in an identity-centric way. Every user obtains a dynamically adjusted network perimeter that’s individualized based on their specific requirements and entitlements. The Software-Defined Perimeter is well-suited to cloud environments; network services such as MongoDB can be easily protected by SDP network gateways.

With SDP, organizations can easily define policies that control which users get access to these database instances, and prevent all unauthorized users from scanning or accessing these services – even if they’re misconfigured and don’t require authentication. And, because this access is built around users, not IP addresses, authorized users can securely access these systems from anywhere, with strong authentication enforced at the network level.

We’ll never be completely safe in our hyper-connected world, but we’re unnecessarily making things harder for ourselves, as this latest attack shows. We need to take a new, identity-centric approach to network security, and the Software-Defined Perimeter model provides exactly this. Putting this in place will go a long way towards making our systems more secure while keeping our users productive.