Last Updated on June 24, 2024
Many organizations fail to appreciate the information security risks associated with their databases. Database environments have potentially very broad attack surfaces if proper controls are not in place.
What are the most significant threats to our databases that we might not even be aware of?
To get a database expert’s view on database security risks and what to do about them, a recent episode of The Virtual CISO Podcast features Robert Buda, President at Buda Consulting. The show’s host is John Verry, Pivot Point Security CISO and Managing Partner.
One: Sloppy user account management
Bob reports that many of the database vulnerabilities he sees most frequently relate to non-rigorous management of user accounts and login profiles.
“Privileged users, obsolete accounts, default passwords in use—things like that are very, very often neglected,” Bob notes. “And the impact of that is fairly obvious. You’re leaving the door open and if you do that people can get in and they can play.”
Two: Non-masked data in QA and dev environments
Another common database vulnerability is the use of non-masked data in dev/test scenarios.
“We see that all over the place,” remarks Bob. “And we see that the production environment is well secured, and the dev and QA environments are not well secured—yet they have the same data. So that’s an under-recognized problem.”
Depending on your regulatory environment and the nature of the non-masked data (e.g., if it’s individuals’ financial, medical or other personal data), just retaining that outside the production environment where it’s accessible to QA engineers and others who don’t have a legitimate reason to access it could be deemed a data breach.
“The code and data in those QA and dev environments sometimes are put onto developer’s local machines,” cautions Bob. “I think that’s [a risk] that’s kind of lying under the covers, and which is easily fixable. There are plenty of tools out there for masking or obfuscating data.”
John remembers an engagement (now a matter of public record) with the City of New York, where a developer dumped about 500,000 unmasked HR records from a critical PeopleSoft application onto a laptop. Then he took his laptop to lunch at a Korean restaurant and left the laptop in the restaurant.
“$23 million later they were done with the incident,” jokes John. “So there are 23 million good reasons to listen to Bob when he says, don’t allow prod data to leak into your dev and QA environments.”
Three: Database sprawl
Bob points out a well-known but often disregarded threat to database security: database sprawl. The more databases you have, the more likely that some will have untreated vulnerabilities that lead to compromise.
Database sprawl is bad enough on-premises, but it’s exponentially worse in the cloud where everything is virtualized.
“That’s getting worse and worse because it’s getting easier and easier to spin up databases,” says Bob.
Four: Pipeline leakage
A little-known database security concern that Bob is seeing more frequently is what he calls “pipeline leakage.”
“I am not a DevOps expert, but it seems to me that what I call ‘pipeline leakage’ has to be a very, very significant risk in the DevOps and CI/CD (continuous integration/continuous delivery) world or the data engineering world,” Bob contends. “We’re taking data out of this very well protected database. We’re creating XML or CSV or JSON files that hold all this data, and we’re putting it somewhere else. But now there are these temporary files or holding areas or spreadsheets just all over the place.”
“I think that’s probably a huge problem,” stresses Bob. “We need to have a strong focus not on securing that, but on cleaning that up.”
Five: Insider threats
Insider threats, both planned and accidental, are implicated as a root cause in something like 50% of data breaches. Whether resulting from revenge, greed or a user clicking the link in a phishing email, insider attacks often target databases because of all the valuable data they hold. But as Bob observes, many organizations underestimate the prevalence of insider threats and their potential impact.
To protect a database from insider threats, you need a way to log and detect activity against the database, both authorized and unauthorized (i.e., user activity monitoring). Then you need an efficient way to alert on problematic activity and investigate it. Then you need preventive controls like robust identity & access management policies, such as quickly deleting unused accounts and only authorizing access for those who really need it.
What’s next?
To hear the complete podcast episode with database expert Bob Buda, click here.
Interested in the emerging idea of attack surface management to protect your critical data? Check out this related podcast: EP#69 – Steve Ginty – Can You Benefit From Attack Surface Management?