Monday, November 21, 2005
Unbreakable/Unhackable
Pete Finnigan has posted an interesting article on his security related blog. In it he makes the following suggestions to Oracle Corp.
Come on Oracle, lets have a secured installation option - (how about a secure wizard option?).
* set all parameters that could cause insecurities to safe values
* force all installed users passwords to be set - and not to any dictionary word
* install profiles by default to enforce password complexity
* close all un-needed ports - if they are needed then open manually - e.g. iSQL*Plus
* force a listener password to be set - again force complexity and also non-dictionary
* get rid of 99% of the PUBLIC privileges that are granted by default
* many more....
I think that this is an excellent basis for discussion, though I disagree with some of the suggestions and think others too vague.
The suggestions I'd like to see implemented are
force all installed users passwords to be set as strong passwords
install profiles by default to enforce password complexity
close all un-needed ports
force a strong listener password to be set
In addition I'd like to see a tool that can be run against installed databases that provides the following information.
Which features are installed and enabled
Which ports are in use and by what
Any user accounts that do not have a strong password
I'd also like the default installations from DBCA not to include any extra features at all (i.e SYSAUX would contain only SYSTEM).
These two suggestions would ensure that DBAs who after all have to make the security configuration decisions (and often the policy though I think that that is wrong) would have to explicitly choose everything that they install, and would be able to report and document what was installed.
I guess what I am thinking about is something along the lines of the strangely named Surface Area Configuration Tool for Microsoft SQL Server 2005
The suggestions that I think need more thought are
set all parameters that could cause insecurities to safe values A list of all such parameters and a discussion about what was or was not safe would be an interesting exercise; I very much doubt sensible defaults could be decided in all cases.
get rid of 99% of the PUBLIC privileges that are granted by default This is highly desirable in theory, but I rather suspect that it would break a large number of installed applications and itself cause real harm to customers. A committment for Oracle not to grant PUBLIC access to new functionality and to reduce the existing exposure over time would be very welcome though.
1 Comments
Come on Oracle, lets have a secured installation option - (how about a secure wizard option?).
* set all parameters that could cause insecurities to safe values
* force all installed users passwords to be set - and not to any dictionary word
* install profiles by default to enforce password complexity
* close all un-needed ports - if they are needed then open manually - e.g. iSQL*Plus
* force a listener password to be set - again force complexity and also non-dictionary
* get rid of 99% of the PUBLIC privileges that are granted by default
* many more....
I think that this is an excellent basis for discussion, though I disagree with some of the suggestions and think others too vague.
The suggestions I'd like to see implemented are
In addition I'd like to see a tool that can be run against installed databases that provides the following information.
I'd also like the default installations from DBCA not to include any extra features at all (i.e SYSAUX would contain only SYSTEM).
These two suggestions would ensure that DBAs who after all have to make the security configuration decisions (and often the policy though I think that that is wrong) would have to explicitly choose everything that they install, and would be able to report and document what was installed.
I guess what I am thinking about is something along the lines of the strangely named Surface Area Configuration Tool for Microsoft SQL Server 2005
The suggestions that I think need more thought are
1 Comments:
I might be inclined to suggest some level of audit of successful/unsuccessful connections as a default. Probably with a pre-configured job to clear sys.aud$
Maybe its a bit intrusive for a default - what do you think?
Post a Comment
Maybe its a bit intrusive for a default - what do you think?
