At Cyral, I spend a lot of time thinking, and talking, about the security challenges that modern-day databases present.
It doesn’t feel right to begin talking about the present without developing a shared context of what got us here in the first place. Context is everything. So please grab a cup of coffee, tea, or hot cocoa with peppermint schnapps (depending on the time of day), cozy up to the dim glow of your computer screen, and take a trip with me down memory lane.
A long time ago, in a galaxy far, far away, databases were born.
It was 1960, and “A Summer Place” by Percy Faith, topped the American music charts when Charles W. Bachman designed the first database. The first computer password was developed at MIT about a second later in 1961.
It’s unclear whether passwords were used directly on early databases like IBM’s SABRE (for flight booking), or if they were primarily at a “logging into the network” level. However, passwords were chosen for database security because they were simply easier to store – and back then, storage space was at a premium.
The internet, as we know it today, wouldn’t be invented until much later, and in fact it wasn’t until 1963 that the word “hackers” was even coined. War dialing (later shown in the movie “War Games”), was one of the early threats. This was where a hacker would scan a company’s known phone numbers, looking for one that hosted a fax modem, and then try to penetrate the files behind it. This quaint world where a company’s phone numbers all started with the same digits was an architecturally simple world. Computers stood alone. And this is the world into which databases were born.
The 1970’s brought us the relational database model and hashing. The 1980’s brought us the entity-relationship model (leading to the lovely Entity-Relationship-Diagram that many of us love to admire in our free time).
Now, let’s take a moment to pause on the 80’s. Just think about what computers were like. I was a kid back then, and I remember the Commodore 64 coming out. That 64, it was for 64 kilobytes. Woohoo! What a powerful machine!
At this thrillingly advanced point, databases had already been around for 20 years. If you were around in the 80’s, do you remember logging into your home computer? My guess is, no. But you probably do now log into your home computer. And in the 80’s, what about at school or work, did you log into anything there? Let’s give that one a resounding – “I don’t know, maybe?”
Whether you did or didn’t, for me, this drives home the point that early computers, and early databases were not highly secure. Although hacking was coined in the 60’s, it wasn’t really a thing until the 80’s. So early databases didn’t worry as much about security as we do today. They just didn’t have to. Their biggest worries around computer security were more along these lines:
1989 brought us that heart-warming first version of SQL Server, built on a 16-bit system. Back then, SQL Server did support adding users with passwords, but password policies didn’t appear until SQL Server 2005, when a default 7-character minimum was introduced.
By the 90’s and 2000’s, everyone was running their company’s own computers on site. This was painful. They had to purchase portable air conditioning units in case a building’s AC failed. They ran their own networking backbones when moving into a new building, carefully ensured an Uninterruptible Power Supply (UPS) was on site in case of power failure, and then watched in horror when their UPS batteries failed with the power still on and yet took down their servers. (Okay, I’m talking about myself here.)
Still, having the servers onsite had some upsides. It meant that in some cases, the onsite servers didn’t have to be connected to the wild west also known as “the internet”. If they did, they might be connected through a bastion, diminishing some of their risk. This created a “walled garden” where the network was thought to be rather secure. If you could get in, you could go anywhere. The reasoning was that in a walled garden, having users with secret passwords should be enough to protect sensitive data, because only nice, ethical people were allowed in.
Then of course, the cloud became a place where you could buy commoditized computers, and you no longer needed to deal with the pains of the home-grown server farm. Yet virtual networks still allowed the “walled garden” concept to exist, and so passwords still seemed like enough. Well, that was until…
The Death of the Password
The password is on the way out, my friend, and it’s for real reasons. When it was announced, I don’t think this was news to anybody. By the time NIST stopped recommending tough passwords in 2017, I already knew that one of my family members generally had Scooby Doo themed passwords, another one made them up based on what they were purchasing from a website (like for a cell website, it was just “phones”, so very tricky), and yet another family member reused the same password everywhere.
Passwords no longer really made sense for databases, even with generous max password lengths of 128 characters. Mainly because passwords don’t really make sense for humans, those pesky, imprecise operators of computers.
Aside from password reuse and memorability problems, there were a lot of other reasons passwords were disappearing. The longer a password lived, the more likely that it had been leaked or shared. Also, with containerization and Kubernetes, networks were becoming more ephemeral and more difficult to reason about. I mean, if many companies were to paint all of their computer instances appearing and disappearing in a 24-hour period, they would get something like this:
Hey, where’d that walled garden go?
On top of that, there is now a proliferation of ways to authenticate to databases. For example, you could use your AWS IAM credentials (or GCP or Azure’s equivalents). But with this proliferation comes problems. If you had ten compromised web workers, how could you tie their requests to their database queries to learn what had been leaked?
To solve this, traces and audit logs became more central, but they continued to feel rather hodgepodge and like afterthoughts. They were often not available by default, and were difficult to tie in to other applications.
And here’s the other problem – they’re only for after the fact. If you can even learn that a data leak happened at all.
In 2019, the average number of days to discover a data breach was 206. This is actually, perhaps, an optimistic number, when we wonder about how many data breaches were never discovered or never reported, and consider how that might change the numbers. And to that, I say – yikes.
And Finally, Today
In the modern day, machine learning and data science provide hope that we might be able to prevent and detect data breaches in progress. Passwords are still the de facto standard in many databases, but wrapping them with security-enhancing layers can provide the easy visibility we wish they had.
This is our core mission at Cyral, to help teams proactively protect their data across all structured and semi-structured data stores. As companies around the world embrace the Data Cloud, it is even more critical to have an easy way to get complete visibility into all their data activity and govern access. Being at the forefront of this change, we are learning some new interesting technological and market insights that we regularly hope to share on this blog channel.
In the meantime, to end with another heavy-handed Star Wars reference: “You can’t stop the change, any more than you can stop the suns from setting.” And thus, we will look onwards to the present and see where these winds will take us.
