Why Databases Need Their Own Protection
Data Privacy and Security

Why Databases Need Their Own Protection

The recent news stories about the U.S. military network data breach, where hackers gained access to information located on Navy Department databases, highlighted security weaknesses in third party systems which led the attackers to their ultimate target. This story isn’t unique; several recent breaches appear to have originated in vendor or partner systems. But maybe it’s a sign that we’re starting to see the bigger picture – the one where the boundaries of our own safe, controlled networks become translucent as we interconnect with the world to accelerate the pace of business.

For many years I’ve preached the gospel of data security. Much of the time, the response I get when I ask a CSO about his/her company’s database security strategy is a description of network perimeter protections. Firewalls, intrusion prevention, anti-malware – the company has deployed just about every technology it could buy to protect its networks. What many do not realize is that while perimeter protection is a vital component of a security plan, perimeter protection alone is not enough.

As many in-house IT pros know, protecting the borders is tough, especially in an environment where web, cloud and mobile applications are increasingly used for work purposes. According to Trustwave’s 2014 Security Pressures Report, which details the findings of a survey asking more than 800 full-time IT professionals worldwide about the pressures they face surrounding security, respondents felt the most pressure to use cloud and mobile applications, despite feeling they both pose great security risks.  

While border protection is vital, and in many cases prevents potentially destructive data breaches, what if a criminal finds another way inside? For example, most businesses have employees who carry laptops, tablets and other mobile devices, exposing those devices to unprotected networks. This creates opportunities for attackers to plant malware on those devices, which will eventually connect to the corporate network, giving the bad guys an open window into the data center. Targeted malware is another very real threat – one that will bypass most traditional network defenses and anti-virus solutions. The 2014 Security Report also revealed targeted malware topped the list of security threats exerting pressure on organizations in 2013 followed by data breaches and then social engineering.

One thing there is no question about is what the cyber-criminals are after, and that’s data. Sensitive, valuable, saleable data. Our Trustwave team has performed thousands of penetration tests and forensic investigations during the past few years so we have seen firsthand which vectors criminals use to compromise systems and steal data. Some of the most common and impactful weaknesses we see pertain to the systems that store and process a treasure trove of sensitive and valuable data - databases.

All databases have an authentication system to control log-in access. There are various options but most of the time, databases are configured to allow username/password authentication (the least robust choice). Knock on the door, guess the right name and password and you’re in. Simple enough. But it gets simpler. Databases often come with built-in users. Those built-in users have default passwords. Lists of those default usernames/passwords are readily available online. It’s not just the database defaults that will bite you. When you install an application, it may be installing its own well-known default database accounts and passwords.

Next is the people problem. Many businesses give employees database accounts and hope they’ll use strong passwords. At Trustwave, we periodically get our hands on cybercriminal booty - huge caches of stolen passwords. Our analysis of those passwords is not encouraging. The data shows that as a society, we’ve become good at picking really bad passwords that still meet typical complexity requirements. According to the 2013 Trustwave Global Security Report, Welcome1, Store123 and Password1 were the top three passwords used last year.

Patching a database can also be challenging, especially the process of planning, coordinating and testing that must happen before a production application is changed. Consider a few of the issues. Database vendors don’t pre-release patches to application vendors. Everyone gets the patch at the same time. In most IT shops, there is no discussion of patching the database until the application team or vendor announces compatibility with the patch. This is where the window of exposure begins. Once the patch has been tested by the application vendor, it typically must be installed and thoroughly tested in a non-production environment. Then, application down time is scheduled and finally, the patch is applied in production.  

Based on our experience, the patching process takes about nine months.

For an attacker to find a working exploit on a database that’s nine months behind on patches requires only basic search engine skills and a simple cut and paste. Furthermore, the moment a database vendor patches a vulnerability, free exploit code becomes almost inevitable. Attackers know this and are taking full advantage of the situation.

One more weakness we see among databases pertains to the way databases are configured. Modern databases have a formidable set of security features and access controls. When deployed properly, those controls help prevent attacks, abuse and misuse. However, we often find that databases are misconfigured; security features are disabled; and access controls are out of control.

Part of the problem stems from the battle between ease-of-use and security. The more vendors ratchet up out-of-the-box security of their databases, the more difficult those databases are to use. Access controls work the same way. It’s much easier to set up and use a system with open access controls than it is to clearly define roles and privileges and then input and maintain those roles in each database individually.

Databases also contain security “options” that shouldn’t be optional. Features such as disabling authentication, allowing unlimited failed log-in attempts, and allowing blank passwords on administrator accounts have no place in the systems that store our most precious data, yet they are real options for some database products.

It’s time that businesses make database security a top priority in addition to securing their perimeters. The database is currently many businesses’ weakest link. If businesses take steps to protect their data in the databases where it lives, they may thwart a potentially damaging breach.

 

Josh Shaul is Director of Product Management at Trustwave

PREVIOUS ARTICLE

«NSA Aftershocks: Businesses in the Wake of Snowden

NEXT ARTICLE

Fostering Startup Mentorship on a Global Scale»
Josh Shaul

Josh Shaul is Director of Product Management at Trustwave

Add Your Comment

Most Recent Comments

Our Case Studies

IDG Connect delivers full creative solutions to meet all your demand generatlon needs. These cover the full scope of options, from customized content and lead delivery through to fully integrated campaigns.

images

Our Marketing Research

Our in-house analyst and editorial team create a range of insights for the global marketing community. These look at IT buying preferences, the latest soclal media trends and other zeitgeist topics.

images

Poll

Will Kotlin overtake Java as the most popular Android programming language in 2018?