Protecting databases is hardly an easy task, but it is often the attacks that go after the simplest vulnerabilities that are most successful.
The common thread in this list is that databases security and their configuration is not a fire-and-forget operation for database administrators. Organizations must continually assess packages to determine if they are really necessary and disable those they don't need to reduce attack surfaces. They need to be vigilant about keeping on the lookout for default or weak log-in credentials. They have to put sound privilege and authentication practices into play. And most important, they need to patch regularly.
1. Default, Blank, and Weak username/password
It might be a daunting task at an organization that has to keep track of hundreds or even thousands of databases. But removing default, blank and weak log-in credentials is an important first step to change your database default username/passwords. The bad guys are keeping track of default accounts, and they'll use them when they can.
2. SQL injections
When your database platform fails to sanitize inputs, attackers are able to execute SQL injections similar to the way they do in Web-based attacks, eventually allowing them to elevate privileges and gain access to a wide spectrum of functionality. A lot of vendors have released fixes to prevent these problems, but it won't do much good if your DBMS remains unpatched with latest updates.
3. Extensive User and Group Privileges
Organizations need to ensure privileges are not given to users who will eventually collect them like janitors collect keys on their key chains. Which can be managed collectively more easily than if users were assigned direct rights.
4. Unnecessarily Enabled Database Features
Every database installation comes with add-on packages of all shapes and sizes that are mostly going to go unused by any one organization. Since the name of the game in database security is to reduce attack surfaces, enterprises need to look for packages that don't use and disable or uninstall them. This not only reduces risks of attacks through these vectors, but it also simplifies patch management.
5. Broken Configuration Management
Similarly, databases have many different configuration choices and considerations available to DBAs to fine tune performance and enhanced functionalities. Organizations need to be on the lookout for unsafe configurations that could be enabled by default or turned on for convenience of DBAs or application developers.
6. Buffer overflows
Another hacker favorite, buffer overflow vulnerabilities, are exploited by flooding input sources with far more characters than an application was expecting say, by adding 100 characters into an input box asking for a SSN. Database vendors have worked hard to fix the glitches that allow these attacks to occur. This is yet another reason why patching is so critical.
7. Privilege Escalation
Similarly, databases frequently sport common vulnerabilities that allow attackers to escalate privileges within a little known and low privilege account and gain access to administrator rights. As these vulnerabilities are uncovered, administrators need to reign them in with timely updates and patching.
8. Denial of Service (DoS) Attack
SQL Slammer provided a very illuminating illustration of how attackers can use DBMS vulnerabilities to take down database servers through a flood of traffic.
9. Unpatched Databases
This could be repetitive, but it bears repeating. So many database administrators don't patch in a timely fashion because they're afraid a patch will break their databases. But the risk of getting hacked today is way higher than the risk of applying a patch that will go haywire. That might not have been true five years ago, but vendors have become much more rigorous with their testing.
10. Unencrypted Sensitive Data at rest and in motion
Perhaps it is a no brainer, but organizations should never store sensitive data in clear text within a database table. And all connections to the database should always use encryption.
The common thread in this list is that databases security and their configuration is not a fire-and-forget operation for database administrators. Organizations must continually assess packages to determine if they are really necessary and disable those they don't need to reduce attack surfaces. They need to be vigilant about keeping on the lookout for default or weak log-in credentials. They have to put sound privilege and authentication practices into play. And most important, they need to patch regularly.
1. Default, Blank, and Weak username/password
It might be a daunting task at an organization that has to keep track of hundreds or even thousands of databases. But removing default, blank and weak log-in credentials is an important first step to change your database default username/passwords. The bad guys are keeping track of default accounts, and they'll use them when they can.
2. SQL injections
When your database platform fails to sanitize inputs, attackers are able to execute SQL injections similar to the way they do in Web-based attacks, eventually allowing them to elevate privileges and gain access to a wide spectrum of functionality. A lot of vendors have released fixes to prevent these problems, but it won't do much good if your DBMS remains unpatched with latest updates.
3. Extensive User and Group Privileges
Organizations need to ensure privileges are not given to users who will eventually collect them like janitors collect keys on their key chains. Which can be managed collectively more easily than if users were assigned direct rights.
4. Unnecessarily Enabled Database Features
Every database installation comes with add-on packages of all shapes and sizes that are mostly going to go unused by any one organization. Since the name of the game in database security is to reduce attack surfaces, enterprises need to look for packages that don't use and disable or uninstall them. This not only reduces risks of attacks through these vectors, but it also simplifies patch management.
5. Broken Configuration Management
Similarly, databases have many different configuration choices and considerations available to DBAs to fine tune performance and enhanced functionalities. Organizations need to be on the lookout for unsafe configurations that could be enabled by default or turned on for convenience of DBAs or application developers.
6. Buffer overflows
Another hacker favorite, buffer overflow vulnerabilities, are exploited by flooding input sources with far more characters than an application was expecting say, by adding 100 characters into an input box asking for a SSN. Database vendors have worked hard to fix the glitches that allow these attacks to occur. This is yet another reason why patching is so critical.
7. Privilege Escalation
Similarly, databases frequently sport common vulnerabilities that allow attackers to escalate privileges within a little known and low privilege account and gain access to administrator rights. As these vulnerabilities are uncovered, administrators need to reign them in with timely updates and patching.
8. Denial of Service (DoS) Attack
SQL Slammer provided a very illuminating illustration of how attackers can use DBMS vulnerabilities to take down database servers through a flood of traffic.
9. Unpatched Databases
This could be repetitive, but it bears repeating. So many database administrators don't patch in a timely fashion because they're afraid a patch will break their databases. But the risk of getting hacked today is way higher than the risk of applying a patch that will go haywire. That might not have been true five years ago, but vendors have become much more rigorous with their testing.
10. Unencrypted Sensitive Data at rest and in motion
Perhaps it is a no brainer, but organizations should never store sensitive data in clear text within a database table. And all connections to the database should always use encryption.
