News
Next steps
Request a demo
Contact me
Sales
+1 (408) 970-3305
OR +44 (0)2076 499959
Download Now
14 Day Eval Versions
Sentrigo's CTO Explains How to Safeguard Databases Against Malicious Attacks
August 18, 2009
By Slavik Markovich, CTO and founder, Sentrigo
Read the original article in eWeek
Database security, whether as a topic of discussion or a set of tools, has been around for at least seven or eight years now. It is only in the last couple of years, however, that it is beginning to draw more attention from industry analysts and security and database professionals. The combination of worsening and highly publicized data breaches on the one hand, and stricter regulatory compliance demands on the other hand are pushing database security to the foreground. There is a still a halo of “black art” around this topic, since many database
professionals are not familiar with security aspects of database management. Slavik Markovich, CTO and principal founder of Sentrigo, a database security company shares some common practices that security professionals can deploy to secure their databases.
I. Think Security in Everything You Do
Constantly examine your actions with security goggles. Starting with application development, through everyday tasks like user management and data management. Do not think of security as something you do once a month, and educate your users to do the same. Most security gaps are there due to ignorance and lack of awareness, more than any other reason.
II. Use the Least Privilege Principle
The least privilege principle calls for users and applications to have the minimal privileges they require to function properly. This entails not only applying restrictions when first granting users access to the database, but also remembering to review those access privileges periodically and changing them. Many organizations grant deep privileges to consultants and developers who work for them on a temporary basis, but then forget to remove or change those privileges when the work is done. Note that even seemingly innocent privileges can be used by some attack vectors to gain access privileges through vulnerabilities – carefully consider granting every kind of privilege.
III. Minimize the Attack Surface
It is more difficult to secure a large house with many windows than a small house with few windows. Database systems are the same – the more complex they are, the larger the attack surface. Strive to reduce the attack surface by eliminating components that are not in use, and avoid installing them in the first place.
IV. Manage Passwords
One of the easiest and first targets a hacker will attack is known accounts with default or weak passwords. Lists of default accounts and passwords are freely available on the web and many tools exist to help the hacker do brute force / dictionary / rainbow tables and authentication attacks. Be sure to use the same tools to periodically check for weak and default passwords in your database.
V. Encrypt, but Not as a Panacea
Encryption is often the first thing that comes to mind when thinking of securing data and is certainly recommended for sensitive data. However, it can be both expensive and difficult to use, and certainly difficult to manage in a way that is secure. Encrypt only sensitive data that requires it. Be careful how you manage the encryption/decryption keys, and change them on a regular basis.
It is important to combine encryption with other means and procedures, such as database activity monitoring, databse audits, periodic vulnerability assessments and user authentication.
VI. Development, Testing and Staging Environments
Many organizations invest efforts in securing their production databases, but neglect to do so in development, testing and staging environments. As the staging environment code is often copied into production when it is ready, it should obviously be as secure as the production version. Beyond that, it is often the case that real production data is used in non-production environments without any masking, and this poses a serious security risk. It is recommended to treat nonproduction environments with the same tools and procedures one applies to the production environment.
VII. Apply Patches
Much has been said and written about how DBMS vendors cope with vulnerabilities and how quickly they should patch them. The reality over the past few years shows that the number of reported vulnerabilities is rising, and while vendors are doubling their efforts to patch them, so do the security researchers and hackers.
Additionally, it usually takes the vendor several months or more to distribute a patch, and it takes an additional several months for customer to install the patches, which usually require testing and database downtime. Many customers do not apply the patches at all, and their databases remain vulnerable to severe attacks. Apply patches as soon as they are made available.