Common misconceptions about database security
Commentary--You would think that enterprises realize by now that databases, which hold the crown jewels of sensitive information, need protecting. Unfortunately, there seems to be a serious disconnect and knowledge gap between IT security professionals and DBAs that are entrusted with the task of safeguarding databases.
Database-specific knowledge is crucial for successfully enforcing security policy as it relates to databases and that knowledge is most readily available with database administrators. Only serious dialog between IT security and the DBA department would create the knowledge necessary to develop and enforce an effective security policy for databases and prioritize it correctly among the other IT security items.
Common misconceptions IT security has about database security:
1. My databases are all behind firewalls and IDS/IPS so Im protected--Not so. Attacks can originate inside the organization, and even those originating from the outside can bypass firewalls and IDS/IPS. An SQL injection attack would use an open port via a web application, for instance, and if slightly altered from common SQL injection signatures it would easily evade IDS/IPS.
2. We have full auditing turned on, so we know everything thats happening in the database--First off, its unlikely that you have full DBMS auditing turned on. You may have told the DBA to do it, and maybe he did, but then 5 minutes later he turned it off. Why? Because it made the database crawl. Additionally, even with full audit turned on you will only know of an attack after it already happened. Additionally, many privileged users can turn audit off or delete/tamper with the audit trail and do things without leaving a trace.
3. I can protect the database without any DBA involvement--Not adequately. You have no idea where the sensitive data resides and even though some tools exist that try to identify sensitive data automatically, they are far from perfect, far more expensive and less thorough than if you simply ask the DBA.
4. I can protect the database using a network appliance--Wrong again, since you will miss a lot of the local access as well as attacks and misuse that originate inside the database (using views, triggers and stored procedures).
5. All of our databases are fully patched--Possible, but not likely. Most organizations skip vendor security patches and in fact cannot deploy them in any reasonable timeframe. Many reasons exist including the need to test all database applications, lack of certifications from 3rd party application vendors (SAP), inability to shutdown critical databases and the sheer amount of work to manually deploy the patches across hundreds if not thousands of databases.
Common misconceptions DBAs have about database security:
1. The data is encrypted so its safe--Its certainly safer, but not necessarily safe. Certain applications would have the encryption keys in order to access the data. Depending on where and how these encryption keys are stored, they can be compromised. This is only if you have column-based encryption implemented. Transparent database encryption helps to protect direct file access and backup access, but will not protect against developers, DBAs or anyone with privileged access to the database itself.
2. I regularly patch my DBMS with vendor security patches so its not vulnerable--If only. Of course patching is recommended, and it will protect you against exploits targeting the vulnerabilities fixed by the vendors if you are among the minority of DBAs who apply vendor patches regularly and quickly. However, vendors take time to issue the patches for the vulnerabilities they know about, and there are vulnerabilities they do not know about (and the bad guys do). Additionally, insider abuse may occur without exploiting any vulnerability, by simply abusing existing privileges.
3. We passed a Sarbanes Oxley/PCI-DSS/SAS-70 audit, our databases are secure--Standards and audits do not make the databases secure, not even the databases that are in scope. They are only there to ensure that controls are in place over the data that is relevant to the specific regulation/legislation or standard. Implementing compliance while taking in the big picture security requirements and policies is the only way to ensure that the database is both in compliance as well as secure.
4. We have tight access control so my database is safe--Having good access control on the database is necessary but it is definitely not sufficient. Many database vulnerabilities allow low-privilege users to elevate their privileges, and some databases can be compromised without having any credentials at all. Additionally, privileged users can abuse their rights and use authenticated sessions for illegitimate purposes.
5. We can create home grown solutions to cater for our security requirements--Unfortunately, it is not so easy. Home grown solutions are hard to maintain, hard to manage, virtually impossible to deploy across multiple databases, provide only a very partial solution and do not keep pace with emerging threats.
biography
Slavik Markovich is chief technology officer at Sentrigo.
Original: news.zdnet.com
No comments:
Post a Comment