Enforcing Separation of Duties
By Roxana Bradescu on Apr 02, 2008
Last week we did the second installment in our webcast series with Rich Mogull. As you might recall, we started the year by talking about Database Security Resolutions for Database and Security Administrators.
Last week we drilled down into one of the key resolutions or best practices: separation of duties. Separation of duties is a classic security principle that restricts the amount of power held by any one individual in order to prevent conflict of interest, the appearance of conflict of interest, fraud, and errors. Separation of duties is one of the fundamental principles of many regulatory mandates such as Sarbanes-Oxley (SOX) and the Gramm-Leach-Bliley Act (GLBA), and as a result IT organizations are placing greater emphasis on separation of duties across all IT functions, especially database administration.
Rich did a great job clarifying what separation of duties means in terms of database administration and how separation of duties relates to another very important security principle: least privilege. We mainly focused on preventive controls for separating various aspects of database administration (we will be talking about detective controls around separation of duties in our next webcast). Following Rich�s presentation, I talked about how enterprises can use Oracle Database Vault to put in place preventive controls to secure their Oracle databases without any changes to existing applications. Database Vault is a powerful real-time rules engine inside the Oracle database that can enforce security policies such as least privilege and separation of duties by restricting database access to any users, including privileged users.
We also did a couple of polls during the webcast. First question was could a privileged application user in your organization intentionally or unintentionally drop all your application tables? More than half of the respondents (55%) answered yes or that they were not sure. Second question was can DBAs in your organization read credit card or social security numbers stored in the database? Over 75% of the respondents answered yes or weren�t sure. I have to admit I was a little surprised at this last one given PCI and all the regulatory focus on protecting credit card numbers and personally identifiable information like social security numbers.
If you missed this webcast, definitely check out the replay and register for the next one. And check back here as we will be answering questions we didn�t have an opportunity to cover in the webcast. And if you are going to be at the RSA Conference next week, please stop by the Oracle Solution Showcase, booth 1117, for more info and demos.