Re: Securing the database from the DBA

leedm777_at_hotmail.com (David M. Lee) wrote in message news:<8df1fe79.0403292233.7a991f15_at_posting.google.com>...
> I've been thinking a lot lately about the additional security
> requirements that the recent onslaught of legislations placed on
> databases (HIPAA, Sarbanes-Oxley, Gramm-Leach-Bliley, California SB
> 1386).
>
> Specifically, consider the requirements for keeping an audit trail of
> data accesses and modifications. Within Oracle, triggers can be used
> to track DDL, DML, logon, logoff, and a myriad of other interesting
> events. Fine Grain Auditing can be used to audit SQL queries, and can
> be coupled with Flashback so that you can see exactly what was seen by
> those queries.
>
> All of these methods, and many of Oracle's other security features,
> put the responsibility on the shoulders of the DBA. But doesn't this
> also give the DBA the powers to circumvent these measures? Can't he
> delete rows from the audit logs? Can't he disable triggers or FGA
> policies before doing something sneaky? When using the database's
> facilities as your audit trail tool, doesn't the DBA have the
> knowledge and ability to circumvent and cover up _anything_?
>
> What do you do if you want to protect the data from the DBA?
>
> Many companies now have separate security departments, as seen by the
> rise of the 'Chief Security Officer'. If they wanted to put the
> responsibilities of maintaining the database audit trail in the
> security department, would they hire a DBA in that department to watch
> the DBA in the IT department? Or should they use mechanisms outside
> of Oracle for securing the database, such as some third party tool?
>
> Maybe these concerns too far from the real world. Do most companies
> simply let the DBA handle the database security, and worry about
> whether he _should_ be the one handling security only after there is
> an incident?
>
> Thanks for your opinions!
> dave

We're in the same situation - trying to address the concerns of Sarbanes-Oxley and FDA 21CFR Part 11. Like you said, it's a catch-22, that you can't truly secure the database from the people who are responsible for maintaining it.

All parties involved have to realize that, but still make a serious effort at following good security practices, with the knowlege that nothing is perfect. One important thing that we are working on is separation of duties: the Security group will have 3rd party tools to monitor audit trails and security related database configuration. Account creation and granting of application access is handled by another group who insures that no access is granted without proper authorization, performing periodic user access reviews, etc. DBAs will use their own personal accounts for DBA work instead of SYS, SYSTEM, etc. Good change management procedures with an approval process should be followed so that no unauthorized changes are made to a system.

DBAs will always be able to do anything in the database of course, but you try to put certain practices in place so that with the right monitoring, something suspicious would be recognized as such. That alone could be a big deterrent.

With the right type of database auditing enabled, a DBA would have to be very careful to sneak something by: if they try to disable a trigger or modify a stored procedure in order to change data undetected, that type of DDL would be audited. If they try to delete that audit record from aud$, that deletion can be audited. Turning audit options on and off should be audited. A dba could try changing the init.ora parameter audit_trail to false but that needs a database shutdown, and when it comes back up the security group's tools should notice that audit_trail is set wrong. Shutdowns should not happen output of approved maintenance windows or change management, so any unexpected shutdowns should be investigated.

All of this is not perfect, and it is a lot of work, but in some environments you just have to try your best. Auditors always like to see some measure of control in place.

-- 
Joe
http://www.cafeshops.com/joekaz
http://www.joekaz.net