Mainframe DBAs look down their noses at everyone. The Oracle DBA looks down on everyone else. SQL Server DBAs just shake their heads at the rampant denial.
Last year when Oracle Alert #68 made big news, you would have been hard-pressed to find an Oracle DBA that was all that concerned. Had this been an issue with SQL Server, it would have been a front page story. Of course, the prevailing impression is that SQL Server is simply less secure than other databases.
Now, I have to admit I have never supported a SQL Server instance, and back when I was a hands-on technician, Microsoft didnt have a stable enough operating system to even consider SQL Server (or any other relational DBMS) on Windows as a viable alternative.
Of course, that was over eight years ago and much has changed. For the past four or five years, it would be hard to deny that the majority of database workloads could easily be supported by any of the commercial database systems, even some of the open-source databases.
I have spoken to many large companies running their entire businesses on SQL Serve, including applications such as SAP. I have spoken with organizations that have MySQL instances supporting multiple terabytes and hundreds of thousands of queries per day.
So its difficult to reconcile the prevailing perception of the relative strength of the various RDBMSes out there with the reality of what companies are doing. The only conclusion is that most databases are good enough for most things.
But we should ask ourselves, Does this translate to being as secure? Even if the database software could be proven to be the most secure, does that make it invulnerable? Whose responsibility is it, anyway, to make it secure? These are questions I have asked over the years. The answers, of course, are no, no, and everyones.
So why were Oracle DBAs seemingly unconcerned by alert #68? Well, most felt that their Oracle databases were sufficiently protected behind multiple firewall layers. When the Slammer virus attacked SQL Server instances, many of them were not as protected. Not to mention the use of derivatives like MSDE, which made the impact of Slammer even greater.
In a quick and certainly not exhaustive search of the US-CERT site, which lists reported security vulnerabilities, I found that for the period between Jan. 1, 2004 and Aug. 1, 2005, three databases had received four security alerts each: Oracle Database 10g, MySQL, and PostgreSQL. Microsoft SQL Server had one security alert, and DB2 had none.
Should those results lead us to conclude that DB2 is the most secure database or that Oracle is no better than MySQL or PostgreSQL? I think not. Certainly, the number of installations of a database impacts the potential for a vulnerability to be discovered.
The most important thing to note is that none of this information means anything to your company once your data has been compromised. So lets not any of us be in denial: Any database is vulnerable and the burden of keeping it secure doesnt just lie with our DBAs—its much broader than that. As managers we need to make sure that any security initiative is taken to a higher level within the organization.
Fundamentally, what makes any database secure is professional support grounded in well-defined and repeatable processes. What makes it even more secure is if the entire IT organization considers security a top priority.
That means having developers write strong code that prevents SQL injection attacks. It means that we treat development servers with the same caution that we do production servers. It means making networks as secure as they can be, and it means that the support organization has some sort of clearinghouse mechanism to remain current on and review implications of any and all vendor-supplied patches … because any database is vulnerable.
If you dont think so, you are simply taking a trip down denial.
Charles Garry is an independent industry analyst based in Simsbury, Conn. He is a former vice president with META Groups Technology Research Services.