Security experts and auditing...
Date: Wed, 15 Jan 2014 14:56:57 -0600
Message-ID: <000c01cf1234$54b39b90$fe1ad2b0$_at_cox.net>
"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-lReceived on Wed Jan 15 2014 - 21:56:57 CET