Monday, November 21, 2005
Unstoppable/Untrackable
Which is what the title of my last post becomes if you play Chinese Whispers for too long. The reason for this post, Howard has posted a follow up, to my follow up to Pete's followup to a post on pete's forum. Yep, Chinese whispers alright.
Anyway Howard as usual makes some excellent points. In particular
But I'm afraid I take the old-fashioned view that a breach of security in a database means the DBA wasn't doing their job properly. That's the DBA's fault, not the Corporation's for failing to ship the product in an idiot-proof configuration.
and
In other words, if a vaguely competent DBA knows what he or she is doing, the sort of lock-down that Niall and Pete are after is already achievable.
I remain however somewhat unconvinced. This sort of argument is, to me, all rather reminiscent of the defence Microsoft had at the time of the Slammer worm, that a fix was already available, that competent people would have applied it and anyway no sensible dba would have a database exposed to the net. All of these turned out to be bad assumptions, and unlike Howard I don't see any quality of organisations that run Oracle that is likely to make them not subject to the same issues that plagued Microsoft houses a couple of years ago.
Howard is absolutely correct that the security of Oracle databases is the province of the dba, in shops where however the dba may have hundreds of databases of varying degrees of importance, and multiple accounts and features to look after, any help is greatly to be welcomed. Shipping roles like CONNECT and RESOURCE well illustrate that security isn't (or hasn't) been a priority for Oracle Corp.
For me it is instructive to note that, as Howard suggests, a competent dba can require - for example - strong passwords by the use of profiles and has been able to since version 8. So for 8 years we have been able to require at least 4 character passwords, but even in 2005 Oracle doesn't require this for system accounts. 'SYSTEM/XE' or even more scarily 'SYS/XE AS SYSDBA' will be viable hacks for internet exposed systems for the forseeable future.
I, and I am sure Pete, do not argue that Oracle is insecure, merely that shipping it with insecure defaults that require a degree of manual intervention (and a level of knowledge beyond the 2-day dba) is a decision that may well harm Oracle themselves as Oracle databases start to get hacked.
I guess in the end I disagree with this paragraph from Howard's post most of all
I expect SQL Server to be supervised by people whose skillset in the security division is somewhat depleted (I'm not saying SQL Server DBAs are dumb, just that the nature of what they are administering makes it more likely than not that they won't have had to think about these sorts of things before being required to administer a production database). I don't think we should expect the same of Oracle DBAs.
DBAs do much the same job, regardless of product, they are responsible for corporate data and work in the same high pressure, relatively low pay environment (compared for example to the CFO who has similar responsibility for controls over finance). It doesn't cut it for me to say that Oracle people do security and SQL Server people don't. I'd strongly expect the range of Oracle installs to exhibit the same vulnerabilities as that of SQLServer installs.
2 Comments
Anyway Howard as usual makes some excellent points. In particular
But I'm afraid I take the old-fashioned view that a breach of security in a database means the DBA wasn't doing their job properly. That's the DBA's fault, not the Corporation's for failing to ship the product in an idiot-proof configuration.
and
In other words, if a vaguely competent DBA knows what he or she is doing, the sort of lock-down that Niall and Pete are after is already achievable.
I remain however somewhat unconvinced. This sort of argument is, to me, all rather reminiscent of the defence Microsoft had at the time of the Slammer worm, that a fix was already available, that competent people would have applied it and anyway no sensible dba would have a database exposed to the net. All of these turned out to be bad assumptions, and unlike Howard I don't see any quality of organisations that run Oracle that is likely to make them not subject to the same issues that plagued Microsoft houses a couple of years ago.
Howard is absolutely correct that the security of Oracle databases is the province of the dba, in shops where however the dba may have hundreds of databases of varying degrees of importance, and multiple accounts and features to look after, any help is greatly to be welcomed. Shipping roles like CONNECT and RESOURCE well illustrate that security isn't (or hasn't) been a priority for Oracle Corp.
For me it is instructive to note that, as Howard suggests, a competent dba can require - for example - strong passwords by the use of profiles and has been able to since version 8. So for 8 years we have been able to require at least 4 character passwords, but even in 2005 Oracle doesn't require this for system accounts. 'SYSTEM/XE' or even more scarily 'SYS/XE AS SYSDBA' will be viable hacks for internet exposed systems for the forseeable future.
I, and I am sure Pete, do not argue that Oracle is insecure, merely that shipping it with insecure defaults that require a degree of manual intervention (and a level of knowledge beyond the 2-day dba) is a decision that may well harm Oracle themselves as Oracle databases start to get hacked.
I guess in the end I disagree with this paragraph from Howard's post most of all
I expect SQL Server to be supervised by people whose skillset in the security division is somewhat depleted (I'm not saying SQL Server DBAs are dumb, just that the nature of what they are administering makes it more likely than not that they won't have had to think about these sorts of things before being required to administer a production database). I don't think we should expect the same of Oracle DBAs.
DBAs do much the same job, regardless of product, they are responsible for corporate data and work in the same high pressure, relatively low pay environment (compared for example to the CFO who has similar responsibility for controls over finance). It doesn't cut it for me to say that Oracle people do security and SQL Server people don't. I'd strongly expect the range of Oracle installs to exhibit the same vulnerabilities as that of SQLServer installs.
2 Comments:
Our Oracle DBA team have over 100 databases to look after – they need tools to make their lives easier, not because they are lazy but because they need to create time to do the fun stuff. They use as much automation as possible to keep up on the routine, security wizards would be a great addition to their toolkit
I also liked the comment about where responsibility to ship secure code and where responsibility for secure databases lies. I'm not really impressed with Oracle's track record on the first bit either but that is a different story.
I hope that I wasn't suggesting that Oracle shipped my idea of a secure db (though I think they should ship someones idea of a secure db - even as a secure option in dbca), rather that installs made dbas think about security. dbca now makes you think about memory usage, block sizing, and yes even backup; even if sometimes you do wonder where the dbca defaults came from. It doesn't seem a big leap to make it explicit on security. (Though I suppose use the same password for all accounts makes me consider it :( )
Post a Comment
I hope that I wasn't suggesting that Oracle shipped my idea of a secure db (though I think they should ship someones idea of a secure db - even as a secure option in dbca), rather that installs made dbas think about security. dbca now makes you think about memory usage, block sizing, and yes even backup; even if sometimes you do wonder where the dbca defaults came from. It doesn't seem a big leap to make it explicit on security. (Though I suppose use the same password for all accounts makes me consider it :( )
