Re: Security experts and auditing...

From: Nuno Souto <dbvision_at_iinet.net.au>
Date: Thu, 16 Jan 2014 20:07:13 +1100
Message-ID: <52D7A141.301_at_iinet.net.au>

Excellent feedback, Don. Thanks heaps for pitching in with your background and experience.
The same goes for "the other David", by the way. Thanks a lot to both of you for your feedback.
Definitely a lot to think about here, and I'm sure it will provide a lot of ideas to our ever improving database security guidelines.

-- 
Cheers
Nuno Souto
dbvision_at_iinet.net.au




On 16/01/2014 7:56 AM, Don Granaman wrote:


>

> "Our auditors haven't got a clue, so we just ignore ANY of their 

> recommendations on the subject.  They are the kind that "tut-tut" at 

> select access on ALL_TABLES given to PUBLIC. Mostly because they trust 

> blindly the output of "security check" scripts they have been sold by 

> "experts" who hadn't a clue in the first place..."

> - Nuno Souto

>

> Unfortunately, the main gist of this is true.  Few auditors have a 

> clue, so they follow some generally accepted set of "best practices", 

> which are likely not well-considered.  Oracle security is in its 

> infancy compared to most other aspects of database administration.  In 

> my opinion, database security is at about (or somewhat behind) where 

> performance analysis was in the mid-1990s when the BCHR and other 

> global statistics seemed the holy grail.  A lot of people, including 

> some "experts", who knew little else and evidently lacked critical 

> reasoning skills propagated a lot of very poor "best practices".  Now 

> we see a lot of the same sort of blind acceptance of bad practice with 

> Oracle security.

>

> I do not profess to be an expert on the more general subject of Oracle 

> security, but was a charter member of the CIS Oracle security 

> benchmark team over a decade ago and have done exhaustive research on 

> Oracle auditing for years - from 8i through 12c.  For the last year 

> and a half or so before I retired three months ago, researching and 

> documenting Oracle auditing was my full-time job.  I have seen all 

> sorts of laughably bad auditing "recommendations" from "authoritative 

> sources" on the subject.  Many still prevail.  Most revolve around the 

> basic differences between auditing "actions/statements" and auditing 

> "the use of privileges". Few, including the majority of "Oracle 

> security experts", truly understand the difference, so they almost 

> universally recommend the auditing of a boatload of "sensitive 

> privileges" - and often 1ittle else.  To compound the problem, most 

> sets of "authoritative" auditing recommendations have "evolved" from a 

> few original sources, sometime to the point of even copying the errors 

> and typos! The usual concern is that if Joe recommends something that 

> Tom doesn't, then Tom missed something and his recommendations are 

> inferior.  So, when  Tom publishes his recommendations, he publishes a 

> superset of Joe's recommendations.  It is almost as if there is some 

> misguided perception that the longest list must surely be the product 

> of the best minds and result in the most secure system. This alone has 

> propagated a ton of auditing myths.

>

> 12c looks to be better, but a lot of the mistakes, myths and 

> misunderstandings of traditional auditing have been carried over to 

> unified auditing also.   As a very simple example, this is the summary 

> of a much more detailed write-up I did for CIS on 12c's ORA_SECURECONFIG:

>

> /GRANT ANY PRIVILEGE, GRANT ANY OBJECT PRIVILEGE and GRANT ANY ROLE in 

> the privileges section does not reliably audit role and privilege 

> grants - they audit only the use of those specific system privileges 

> by users that have them.  For example, "grant ALTER ANY USER to SCOTT" 

> by a connection as sysdba does not get audited via the default 

> ORA_SECURECONFIG since the SYSTEM_PRIVILEGE_USED is 'SYSDBA', not 

> 'GRANT ANY SYSTEM PRIVILEGE'.  If a role is granted to a user with the 

> admin option and that user grants it on to another, no audit record is 

> created - since the audited system privilege is not needed. Similarly, 

> if a user is granted an object privilege with the grant option, then 

> grants the privilege on to another, no audit record is created by 

> auditing the system privilege GRANT ANY OBJECT PRIVILEGE - it is not 

> needed. However, GRANT and REVOKE in the actions clause does reliably 

> audit all grants and revokes of system privileges, object privileges 

> and roles.  Auditing the use of the system privilege AUDIT SYSTEM 

> literally does nothing -- as all system audit and noaudit statements 

> are automatically audited in unified auditing.  However, adding AUDIT 

> and NOAUDIT to the actions clause does audit all changes to object 

> auditing - which is not automatic. Placing ALTER DATABASE and ALTER 

> SYSTEM in the privileges clause illustrates another failure in 

> understanding.  In the privileges clause, they will not audit any 

> attempts to alter the system or database that fail for lack of the 

> audited privilege.  In the actions clause, they will reliably audit 

> ALL attempts./

>

> Don Granaman - recently retired OraSaurus

>



--
http://www.freelists.org/webpage/oracle-l

Received on Thu Jan 16 2014 - 10:07:13 CET