Posted by Solutions Center on Fri, Jul 10, 2009
I read an article recently about IT security and desired targets for intrusions to steal data. Unsurprisingly, it was reported that databases that are the prime targets, go figure. What was surprising was the report that administrators managing the database are making the same common mistakes which enhance the chances of the intrusion in succeeding. These mistakes are not malicious, but from lack of knowledge. I check out some other sites about this topic and found several lists of common security lapses on databases. Most of these are common sense action items. I have found it is good to review the basics periodically as we all tend to develop habits which may blind us to the obvious.
Passwords:
The weak point in any security is the passwords used. This is true across all realms of the IT world. Be it the default password was never changed, the password is not complex enough, or the passwords for higher level access are known by too many people. Password management and complexity are key to this security issue. Change the password and make it complex. Maybe even use a passphrase, easy to remember and harder to crack.
User privileges and training:
Make sure the people who are accessing the database are doing it with the correct privileges and roles. People who have too much access can do greater damage unintentionally then they would have with just enough access. Training the people who interface with the database is another important step. This isn't just the find-this-data-here type of training, but preventive training. Take the time to educate the staff on best practices in use of the data and in data security.
Critical patch updates:
Patch updates to both the database code and the OS for the server the database is sitting on are key. Having set up a development environment to test the patch deployment on a dev database server is even better.
Antivirus:
Keeping your antivirus updates are as important as the critical updates for the database and OS. Keep the definitions up to date = keep the viruses off the server. Also make sure that the Anti-virus applications are scanning the right areas on the server. I have gone into servers and found some directories purposely skipped by the system scans to reduce errors in the event log, not good at all.
The database should be a stand alone server:
Ideally you want your database to be its own server. This is good practice for both performance and security. When you host other applications on the same server as the database, you are sharing that applications security flaws and issues with the database. This will increase the success of a malicious attack against your database. This is a common issue with the push to save money and space in server rooms today both from pressures to be green and the slashing of IT budgets.
Enforcing and reviewing security policies:
Setting up the security policy is easy. It is the enforcing and auditing the policy that gets to be hard. You have to keep the policy current and review its use both on the system and what the users do. By reviewing the policy you will find issues before they become bigger issues.
Audit the server:
Be aware of what is happening to the database server, review the event logs, check the database logs, and the anti-virus logs. The biggest issues on a server can start from a simple and fixable issue. Seeing a username repeatedly getting a failed log in event will tell you someone is running a dictionary attack against your database server. It is better to find the issue early on and address it before data loss or down time.
As I said in the beginning, most of these are all common sense action items. I suspect any lapses on the above could be from "I will fix that later" and later keeps getting pushed back. By addressing these simple issues you can save yourself bigger issues later.