According to a study ordered by IBM Security, the full cost of a full-scale data breach can be as high as $350 million. Even relatively small breaches could cost upwards of $3.86 million according to Big Blue's numbers, so there's no reason your company shouldn't be focused on locking down its database servers.
We took a moment to put together some of the top tips administrators can use to plug holes in their servers in just a few minutes.
Disable Public Network Access
Even sites that deploy database resources through a web-based interface generally don't have to allow users direct access to the database itself. They can retrieve information and then present it to an end-user. If you're leveraging a database to run any kind of cloud business application, then there's no reason not to block all public network access to the server.
About the only reason you'd want to allow public access is if you were a hosting provider. Configure gateway servers via an SSH tunnel or some other secured protocol for your remote administrators to connect. Standard database security practices phased out the use of telnet years ago. If you still have someone handling remote database management this way, then it needs to be patched quickly.
Change the Administrator's Credentials
If an attacker knew what kind of database you were running, then they might be able to guess the administrator login name. For instance, if you were using MySQL the admin username is root by default just like it is in Unix. You can change the name to something more complex that only your IT department's administrator would know to prevent even the name from being guessed. Don't forget to flush privileges afterward or the changes might not be take effect right away.
This only provides an additional layer of protection if you've already made sure to set a decent password. Some administrators are now adding non-keyboard Unicode characters to their passwords to make them more difficult to guess. When database software hashes out passwords, it bases the hash on individual bytes rather than what characters you've chosen. Thus a four byte Unicode character may provide the same level of security as four additional lowercase letters.
Encrypt Your Database Backups
An average discussion about encryption usually involves tracing endpoints and making sure that end-users have a secure connection to any resources they're accessing. These are vital areas that need to be protected. However, any copies you make of your database need to be encrypted as well.
Never forget about configuration files either. These are normally stored as plain text documents since most developers don't view them as a significant security threat. However, if a cracker were able to access a configuration file through some kind of application vulnerability it wouldn't be a stretch to assume that they'd be able to get into your database next.
Unless you're running your database server on bare metal for some reason, you should be encrypting each virtual disk image you're booting system software off of.
Keep Your Doors Closed
An overwhelming majority of developers use the default SQL server port number after they have their database up and running. Changing it will at least make attackers have to guess a bit more when they're trying to find a door to enter your system through. Windows Server users may want to disable the SQL Server Browser service.
Those who use a Secure Service Container deployed in an IBM Linux software environment are safer in this respect, because they're protected by Unix's locked privilege system. Linux administrators will still want to make sure they're not making the sadly common mistake of running their database as root.
Keeping Your Server Secured
Pay attention to any alerts you might receive, even if they don't look important. System logging apps usually let you filter out things that aren't important. Anything else may need your attention. If you make sure to tackle any security risk today, then your database server should be secured for the long-haul. Vigilance is the secret to avoiding the kind of high-cost data breaches the IT world has seen in the last several years.
The developerWorks Connections platform will be sunset on December 31, 2019. On January 1, 2020, this community and its apps will no longer be available. More details available on our FAQ.
The Tech Park
Matching: databse X