Elastic NV has been frequently named in data breaches recently, ranging from marketing data to dating sites and even a national crisis. A simple search on SC Media news database throws up results that are predominantly about data breaches. However, this is not a crisis, assures James Spiteri, global solutions lead at Elastic. He attributes the situation to misconfiguration and the wide use of the service.
"Elasticsearch is so popular and everyone uses it. So the name is out there all the time. But this (breach) happens with other services like Amazon S3 buckets, it happens with Mongo DB, any service that you can really spin up with a few clicks," he told SC Media UK.
This happens due to several reasons: ignorance, which leads to misconfiguration; negligence, where users set up their clusters thinking ‘I’ll protect it later’ and then forget about it’; and malicious intent, where someone deliberately spins up an Elasticsearch cluster to get back at their organisation, put the data online, then wait for it to get leaked, he explained.
"But generally, it's pretty much always a mistake… people not being aware of what they're doing."
Security of clusters is now free, allowing customers to put username and password to protect their clusters and encrypt the data, leaving no excuse not to adopt basic security practices, he said. There are close to 40 free cloud services that host Elastic products, which offer their services without in-built security, but that is their business necessity, he added.
"If you go for our hosted cloud service, there's security by default. We don't even allow you to run and secure clusters. We're starting to make this trying to fix problem as much as we can, but at the end of the day, if users don't secure their clusters properly, there's not much we can do."
Automated tools that constantly scan the internet for exposed services make things even more difficult, he noted. Users who are cautious of what they put on the internet and aware of Elastic’s free tools for protecting their services can mitigate this issue to an extent, he said.
However, the company has a limited liability when it comes to legal ramifications of a data breach, clarified Spiteri.
"If we were hosting the service saying ‘you're going to have a secure service’ and we don’t secure it to the best of our ability, then there will be facing the legal ramifications. But if someone hosts this on any other surface, which we have no control over, there's nothing we can do."
This is the case of any software, where the host holds the key to security. People actively look out for exposed Elasticsearch clusters because they know that some users don't know how to secure their clusters, he explained.
"Everyone should be using cloud services as much as they can. Just be cautious of what you're doing. If you're not familiar with the cloud concept, go and learn. There are free training courses, loads of publications online, even cloud providers themselves offer material."
Security of your cloud database beings with choosing the service that is apt for the customer. When you do that, assess all the services that they offer, he said.
"Before we do anything (with them), especially for putting something in production, find out all the security features that the cloud provider has. For example, Amazon have security groups. Google has security at every stage of the operation. The cloud providers themselves have done a lot of work to ensure that surfaces are as secure as possible. But it's up to the user to do their research to find out what security product would work for the service."
So, is sticking to the old-fashioned method of hosting your own data servers still effective?
Spiteri was affirmative that it is a bad move, barring a few crucial services such as certain government agencies, where data sovereignty comes first. Physical data servers come with an enormous budget, a risk of overspending and the periodic and emergency overhaul of software and hardware, he explained.