Re: Privileges by session

  • From: Jared Still <jkstill@xxxxxxxxx>
  • To: Andre van Winssen <dreveewee@xxxxxxxxx>
  • Date: Fri, 8 Jan 2010 08:16:28 -0800

On Fri, Jan 8, 2010 at 3:23 AM, Andre van Winssen <dreveewee@xxxxxxxxx>wrote:

>
> have you seen auditors actually use tooling to perform password sanity
> checks on databases subject to SarbanesOxley, HIPAA, PCI or any number of
> other legislated security policies ?
>
>

No, I haven't.  I have seen penetration tests do that, but never SOX
auditors.



> I have seen big shops where fancy database compliancy reports, created by
> the dbas, were just about enough to let the auditors say "Ok, compliant!"
> Motto: business comes first, security second.
>

Reports here are created by the DBA's.  Same for Sysops, and application
Admins.

Really though, it would be quite difficult for the auditors to accomplish
this.

At least in my limited SOX experience, it isn't quite as simple as "Here's
my
report, sign it off please".

I generate reports for databases that must comply with Sarbanes Oxley.
These reports are reviewed with the Security admin for the app.
(how timely, did this just yesterday)

In this particular case, the reports are shown to verify SOD (separation of
duties)
so that no one has DBA privileges unless they are warranted.

The auditors must rely on DBA's to provide the information.  There are many
ways
that a user can have DBA privileges - roles, legitimate roles that have been
granted
extra privilges, roles that appear to be system roles but are created to
provide
extraordinary privileges, direct grants, execution on packages, ...

You can't really expect an auditor to be able to do all that.
Sorry, this goes a bit off topic, as it is more than just checking for
password complexity.


Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Oracle Blog: http://jkstill.blogspot.com
Home Page: http://jaredstill.com

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 01-2010