Segregation of Duties and making auditors happy

[stephenwales]

We are in the process at the moment of doing a very large segregation of duties among all stuff in our IT department.

As a part of this, our auditors want to restrict the DBA’s access to production databases.

For example (quoted from our Sarbanes Oxley Compliance Officer):

==============================

The Auditors will start screaming Segregation of Duties when they look at the DBA access. Here’s the basic premise (Stolen directly from the U of U):

-----------------------------------------------------------------------------

Segregation of duties is a basic, key internal control and one of the most difficult to achieve. It is used to ensure that errors or irregularities are prevented or detected on a timely basis by employees in the normal course of business. Segregation of duties provides two benefits: 1) a deliberate fraud is more difficult because it requires collusion of two or more persons, and 2) it is much more likely that innocent errors will be found. At the most basic level, it means that no single individual should have control over two or more phases of a transaction or operation. Management should assign responsibilities to ensure a crosscheck of duties.

If a single person can carry out and conceal errors and/or irregularities in the course of performing their day-to-day activities they have generally been assigned or allowed access to incompatible duties or responsibilities.

--------------------------------------------------------------------------------

Because DBA’s may access the database directly, all controls implemented by applications are automatically bypassed. Other controls are required to keep the Auditors happy. Typically, that means all updates by DBA’s must be reviewed by someone else.

A system that will probably create enough control to make auditors happy would be something like this:

1. The DBA’s have Read Only access for day to day operations. This gives them the ability to run queries, copy data to a development system when necessary, and do the required research to correct issues on Production.
2. All corrections, changes, modifications, etc are created on a development copy of the database, tested by QA.
3. Changes are approved for movement to production by someone other than the DBA. Maybe a customer requesting the change (must be a data owner) and an IT manager, still needs to be determined.
4. The scripts are run by some designated person. Minimally, this cannot be the DBA that created the scripts. Preferably, the scripts are run by someone without sufficient knowledge to fix the problems (there are reasons for this, just not space here)


In case of an emergency where the DBA needs to fix stuff or install patches, etc

1. An ID with full update privileges is checked out to the DBA. This ID should have sufficient logging turned on also.
2. The DBA does whatever needs to be done.
3. The ID is checked back into whoever maintains the ID. This might need to be the manager or someone else that knows the Database. This one can be tricky to implement, but can be done.
4. The log is reviewed by another DBA and signed as appropriate. The signed logs are kept for Audit purposes.


There is room for modification, but this seems to cover the basics. Perhaps if we contacted some other Oracle Users or Oracle and asked what capabilities Oracle has to implement Segregation of Duties at the DBA level, they have a better plan. After all, we can’t be the first to group to need this.

===============================

While I can see where they are coming from, I envisage some major restructuring efforts of our infrastructure to support this. Currently we have an HP Superdome which runs 30-odd database instances, a cross between about a dozen production and the rest dev/test/training. At present, you log in to oracle to start/stop a database and you have access to pretty much everything. I’m almost positive they’ll want us to configure another server and move all the non production instances to the other server.

Then we also have the “what happens” when you are granted access to log in to oracle to attend to the needs of one problem database (where you’re also able to access all other databases on the server).

I guess what I’m wanting to find out is what other people have done or had thrown at them in order to address this segregation of duties issue and how you’re dealing with restricted access to production instances, if you are at all? What tools are you using to grant/revoke access? If you’re able to get your auditors to agree to letting you keep access via a tight control and monitoring of DBA activities, what are you using for that?

I’d very much like to be able to capture this thread and show management and the SOX Compliance officer what other companies are doing.

Thanks for your thoughts on this issue.

Steve

 

[markrem]

Yes, there are several Oracle books on the market which suggest you separate the Database Administration from Security Administration. I think most of the time they refer to this new user or role as secmgr.

There's much more separation than you discussed. For example, when you say a DBA can start/stop the database and access all data, that's really not true. Only a subset of DBAs granted the SYSDBA privilege can start/stop the database or issue commands as SYS.

With this separation in mind think about things like Oracle's audit trail. Actions performed by SYSDBA users are written to a location that the SYSDBA cannot access, so after doing bad things they cannot cover their tracks. For example, SYSDBA actions are written to the Event Log on Windows. Of course, it needs to be setup correctly, but that's always a given.

Same for Row Level Security (RLS) policies. One user group owns then, everyone else is a consumer. DBAs should not have ability to alter RLS policies. As you noted SYSDBA users are except from access policies by default, but there should only be 2 sysdba users anyways, not a whole team of DBAs.

You also discussed issues with DBAs writing and implementing code. A user should not be connected with DBA credentials to write application code, or implementing application code. That's a Configuration Management Deployer (CMD) or Database Operator (DBO) task, and it's up to you to create a role with just the right permissions.

Just a few thoughts. Don't really want to spend all day on this.



MarkRem
Author, Oracle Database 10g: From Nuts to Soup

http://www.remidata.com/book_nuts2soup.htm

 

[stephenwales]

Well, I'd appreciate any pointers to other reference material.

We are a small shop, 2 Oracle DBA's total, running on HPUX. So Windows Event Logs don't help me here. I have system level auditing turned on to track what a SYSDBA does.

Perhaps we need to be defining our setup a little different so that my base user is defined as SYSDBA and prevent us from logging in as the oracle account so that stuff written to the filesystem audit logs isn't accessible.

Anyone else have further input?

 

[dbtoo2001]

Let me guess. The compliance officer works in finance.

'They' are subverting the intent of Sarbanes-Oxley. Sox is to protect the little guys from the bean counters who chose to count their beans any way they want to, and try to hide it in paperwork, spreadsheets, databases, pda's, aunt gennies pocketbook, what have you...! "An Act - To protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws, and for other purposes." The compliance officer needs to know what the Act states (ask them if they have read the act!

http://news.findlaw.com/hdocs/docs/gwbush/sarbanesoxley072302.pdf)

Section 404 (

http://www.law.uc.edu/CCL/SOact/sec404.html

) is generally what is used to defend the argument that there must be segregation of duties. What does 404 call for? It calls for a report from the auditing company that will:
"
1. state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting; and
2. contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.
"

The broader application which (which is forced onto IT) is to ensure that there are Automated checks and balances throughout an organization, for all processes. Is there a process? Is it verifiable? Is it Documented? Is it repeatable? (Hmmm sounds like SEI, and before that ISO.)

Does finance have a process that identifies when/if someone has changed the data in your financial databases? The answer had better be yes.
Are there checks and balances to identify sources that have too much authority over financial applications? Again, the answer had better be yes.

The problem is not keeping people from seeing or even accessing financial data, the problem is that there is no process to identify changes by those who wish to alter the numbers.

"3. The ID is checked back into whoever maintains the ID" - Who maintains the maintainer? The CFO? Wrongo! You'd be better off with "Herb down in maintenance." "Herb, spillage in the mauve database, cleanup on tablespace 24." Who's to say the DBA and the 'maintainer' aren't in it together, to rape and pillage the invester?

If the auditors are screaming about DBA access, Fire the auditors. Find a company that is looking for a defined and verifiable process that can identify (not prevent) inappropriate actions on the part of the finance department (CIO, CFO, CEO, and whoever, etc.)

But, that's just my opinion and is not to be taken as anything in defense of a SOX defined IT segregation of duties. IT's just the rantings of a demented old man!

 

[stephenwales]

I don't disagree with anything you've said.

(And, for the record, the SOX officer used to be an auditor, he was hired to think like an auditor so that we can pass our audits by running things past him first)

However, I'm being told what I have to do - I'm very annoyed at the whole thing, but that doesn't change what I've been mandated to do by management.... *sigh*

 

[dbtoo2001]

Ask for written requirements which will satisfy the audit's findings.
Then, Ask management what your budget will be to implement a solution that 'might' satisfy the requirements.

 

[LKBrwnDBA]

2 DBA's???? And segregate duties????
What if one goes on vacation?

No wonder you are annoyed, how is it possible to segregate duties between 2 individuals when each is "backup" of the other?



----------------------------------------------------------------------------
The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb