Percona CXO: a database security fix 'in one line of code’
Open source database company Percona has been on the (virtual) road these past few weeks, hosting its web-based Percona Live 2020 conference (in obvious need due to the Covid-19 pandemic) and delivering keynotes and various other analytics sessions that we might have seen in ‘breakouts’, had the physical event actually taken place.
To accompany Percona CEO Peter Zaitsev’s sessions, Percona chief experience officer Matt Yonkovit hosted a number of sessions and posted YouTube updates detailing how the whole 24-hour event was staged.
Following CEO Zaitsev’s opening address which saw him track the history of open source data and pose some predictions on where open databases will sit into the decade to come, Yonkovit looked into some of the data that his firm has been drawing from users.
Yonkovit has stated that company data indicates that misconfiguration (45%) and publishing errors (24%) are common miscues that have allowed data disclosure in database operations to occur.
He talks about cloud database ‘buckets’ that are meant to store lots of information, but if your bucket has a (figurative) hole in it, then it may run completely dry before you make it back home from the well and notice. Often, he says, these servers are brought online in haste and configured to be open to the public, while storing non-public data.
“As you can see from this year’s Verizon report, there’s still a massive issue around databases in the cloud being open rather than secure. This misconfiguration problem is something that can be solved quickly, but it takes attention to do so. The biggest step is a simple one. I can solve more than 50 percent of the data breaches that have taken place over the past year, and I can do it in one line of code: db.changeUserPassword (username, password). This is the Change Password command for MongoDB. Mongo and Elastic — currently the two most breached databases… and most of those breaches are because nobody set a password.
In terms of what else data-developers can do alongside this specific change, Yonkovit says that there are some simple steps that developers can take to improve security by ensuring that the latest version of any database is in place, as this should remove some of the potential vulnerabilities that might get exploited.
Percona has released a free and open source tool for checking implementations and more checks are being added to that tool to help developers ensure their deployments stay secure and are not subject to misconfigurations.
The Percona team says that DevOps approaches can help, as these encourage more collaboration between teams. For developers, making it easier to support those deployments as they move into production is a good move and that means working with other departments like security and IT operations. It’s a question of knowing what is in place and where any problems might come up over time.
What steps should companies take?
So what steps should companies be taking right now with their databases?
“I can say that – from a selfish point of view – I don’t want any more free credit checking services. I think I’m good for that up to about 2082, based on all the breaches that have taken place in the past. Instead, I would encourage everyone to pay more attention to security for their databases from the start. This initial work can make it far easier in the long run, compared to having to make things secure once they are in production and scaling up,” said Yonkovit.
The other issue Yonkovit sees coming up is how developers and IT teams are using things like DataBase-as-a-Service’ (DBaaS) and expect those services to automatically be secure and managed for them.
The message from Percona is… these services should be secure and the cloud providers will ensure that their infrastructure is protected, but that may not extend that level to your data.
You, the developer and the data engineer are still responsible for the data that you store. Don’t let any assumptions pass without a proper check, as this can also save a lot of time.