Call: +44 (0)7759 277220 Call

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "CPU - April 12 is coming?"] [Next entry: "CPU April 12 - 2005 is released"]

Debu has an interesting pointer to an Oracle security paper

I was browsing orablogs and noticed a post by Debu Panda to his blog titled "Prevention is better than cure!" that mostly talks about flu and having a flu jab being the prevention. Debu relates this to Oracle security and talks about the fact that most developers take security as an after thought. He then points us at a paper called "Database Security: Beyond the Password" written by George Jucan. The paper talks about how a database can be made more secure even if an attacker or malicious or curious employee manages to get in via a compromised password. This is the classic least privilege principle. George gives some examples using Row Level Security. He also goes on to talk about encryption and manipulation of encrypted data. He even talks about wrapping PL/SQL and also about auditing.

The paper is not bad but I am concerned about the sentence "It is a good idea to create a separate schema, such as Sec_Manager, without any privileges—not even CONNECT" that seems to indicate that the author is used to simply granting the CONNECT role rather than the system privilege CREATE SESSION to allow a user to access the database. he goes on to say later that "Even if an intruder with the DBA privilege were to grant the CONNECT privilege to the security objects holder" in order for the intruder to connect as the security package owner and to then read the security authentication packages contents (These were wrapped to prevent this). This indicates a lack of detailed knowledge as again he assumes that CONNECT is a privilege and not a role and that it is necessary to access the database. He also says that an intruder with DBA would grant CONNECT to the security schema owner so that it can be connected as. This would be unnecessary in order to view package contents as they are available via DBA_SOURCE. Maybe the author is limited by trying to get the point across but it does seem like a better explanation of roles and privileges and even access to read package source is needed.