It's a fine list but ultimately useless as you offer no advice as to how to minimize the negative impact of these misconceptions.
I would rather have seen this as a two-part article: with items one through five being disclosed and solutions discussed in the first one, and then items six through ten being treated in the second.
Pointing out an issue is one thing, helping your readers overcome it is another.
Regards,
Jon
Common misconceptions about database security
Summary
There seems to be a serious disconnect and knowledge gap between IT security and DBAs who are entrusted with the task of safeguarding databases, says Sentrigo CTO Slavik Markovich.
Topics
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 I’m 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 that’s happening in the database”--First off, it’s 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 it’s safe”--It’s 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 it’s 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.
Talkback Most Recent of 12 Talkback(s)
-
JonathonDoe5th May 2008 -
Good point
Hi Jon, thanks for your comment. A few things:
1. As is often the case with media spots, there?s only so much you can cover in one commentary
2. This is a great intro to a follow up article ? I?ll work on this. Thanks for the input
3. One overarching ?solution? to some of the misconceptions raised here ? DBAs on the one hand, and security pros on the other have different knowledge gaps on this topic but they complement each other. Many of the misconceptions mentioned would be eliminated if they spoke to each other more often and coordinated their efforts better.
slavikm5th May 2008 -
Are we hosed no matter what?
good article... but what are some solutions?
pcguy7777th May 2008 -
AKA reasons why cloud computing is a bad idea
This can easily be renamed "reasons why cloud computing is a bad idea."
People act as if "cloud computing" were some novel, new idea that would somehow bring us enormous benefits. Truth is, it's not. It's just client-server computing in a new, pretty package, and it's the same problems that thin clients etc had, except amplified.
. . . and with stealing database information becoming such a huge problem, whey should I trust these people with my data anyways? Even with "professional" protections, the data always seems to get stolen. This whole thing about "enterprise level" security is total BS. Even if it's 10,000 times better, it's never used, or it's never used properly. Wanna see how silly the whole "security" thing is? Look at how many sites use http instead of https for the login, and still claiming to be "secure." Even banks are doing a horrible job at it. I'm sorry, but right now security in the cloud is a joke.
And when data is successfully stolen from a central database, it's usually got every customer in it. Is it really "better" that there's a single point of failure? Seriously, why do people keep insisting that this is the future? There are zero benefits.
CobraA15th May 2008 -
I think the problem is companies just dont want to pay anyone to do it
...they just load these full time responsibilities on to the sys/net admins and dba's... instead of hiring a few good guys for 50k each minimum to do it.pcguy7777th May 2008 -
therefore, good security isnt free
i rest my casepcguy7777th May 2008 -
There is no central database in cloud computing...
... each database is a service that is rendered to the cloud. With the use of Master Data Management databases each service is mapped to a request by a user/service within the cloud.
Also as a DBA I agree that there are a lot of security issues (known and unknown) within the cloud model... but they exist as well in the client server models.
Finally, the only way you can have good security is if your DBAs, SAs, Network Admins, Security Admins, and IT management are constantly engaged and working towards a common goal. And in this case... good security does not mean no unauthorized user gets in. You'll *never* achieve that goal unless you isolate your network and only have one user. There are too many hackers out there with too much time on their hands. The best you are likely to achieve is the closing of the obvious holes and a hope that you've closed most of the not-so-obvious holes.
Jeff_998th May 2008 -
RE: Common misconceptions about database security
Of course, no matter how secure and locked down a database is, you will still get some admin being asked to burn the contents onto a couple of CD's and send them to another office by unregistered post... not that anything like that could ever happen
nigenet7th May 2008 -
Developers Issue - not always DBA
Certainly, systematic attacks like unpatched vulnerabilities are the DBA's issue, but most SQL Injection and other issues are not hte DBA's problem, they are the application developer's problem.
The statement: >>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.
lists the biggest issue in my mind with security: everyone thinks the DBA is a God.
The DBA doesn't have the slightest idea what is stored in the database - especially for anything other than a simple 7 table OLTP benchmark app. Most modern ERP systems are far too complex for the DBA to know anything about the data they contain.
== John ==
jgwinner7th May 2008 -
disable those usb keys and cd burners
Your article implies that the most serious threat is internal employees with any access at all.
that being the case.. just make sure they cant copy the data anywhere and limit use of internet and ftp and especially ssh without permission.
***Hey dood in finance... im watchin you! lulzpcguy7777th May 2008 -
http://www.basishost.com/hosting/
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.
http://www.basishost.com/hosting/
NikolasD11st Sep -
<a href="http://www.secure-bytes.com/" rel="nofollow">Security Tools</a>
An example of threat is cryptographic attacks or attempts to break the encryption code and the loss of a private key in a public key cryptography system, this why sometimes even when encryption is used, threats to confidentiality still exist.
josephdvd21st Sep
Talkback - Tell Us What You Think
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
Facebook Activity
