Friday Mar 21, 2014

Countering Adversaries Webcast Series

We're kicking off a three part webcast series with (ISC)2 entitled "Countering Adversaries." These webcasts are for IT managers and directors, database and systems administrators, and all security professionals. Register and learn how to protect your organization.

Countering Adversaries Part 1: Espionage and Stolen Credentials

March 27, 2014, 10:00 am PT/1:00 pm ET. Register Here.

By profiling criminal activity, the Verizon Data Breach Investigations Report has been able to identify three distinct threat actors including espionage, organized crime, and activists. Organizations can take proactive steps to mitigate potential risks by understanding each threat actor’s methods and targets. In this three part series, (ISC)2 and Oracle will examine these three threat actors, the industries they target, and how to protect sensitive customer and organizational data. We begin with countering espionage threats and their preference for using stolen credentials.

Countering Adversaries Part 2: Organized Crime and Brute Force

April 24, 2014 10:00 am PT/1:00 pm ET Register Here.

Hailing from Eastern Europe and North America, organized criminals have a penchant for using brute-force hacking and multiple strands of malware to target financial and retail organizations for monetary gain, according to the Verizon DBIR. It is common for these cybercriminals to directly access databases and extract payment cards, credentials, and bank account information. Join (ISC)2 and Oracle as we discuss tactics employed by these cybercriminals and how organizations should implement a defense in depth database security strategy to help mitigate the threat.

Countering Adversaries Part 3: Hacktivists and SQL Injection Attacks

May 22, 2014, 10:00 am PT/1:00 pm ET Register here.

Activists break into organizational web applications and databases to find personal and organizational data in order to expose this private information. The Verizon Data Breach investigations report says “Hacktivists generally act out of ideological motivations, but sometimes just for the fun and epic lutz.” In this third webcast of a three part series, (ISC)2 and Oracle will examine their number one tool of choice: SQL injection attacks.  SQL injection attacks are both simple to perform and difficult to detect. We’ll discuss detecting and blocking SQL injection attacks in order to protect your most sensitive customer and organizational data from “epic lutz”. 

Wednesday Mar 19, 2014

Oracle Open World 2014 Call for Proposals (Papers)

Oracle Database Security Experts Wanted!

The 2014 Call for Proposals for Oracle OpenWorld is open. It’s worth the time to share your expertise with thousands of Oracle users.

If you’re an Oracle Database security expert, conference attendees want to hear it straight from you. So don’t wait-proposals must be submitted by April 15.

Share if you are planning to attend and/or present.  We look forward to meeting you.

Monday Mar 10, 2014

Part 4: Controlling Data Access and Restricting Privileged Data in Oracle Database

This is the fourth and final excerpt from Chapter 1 of Securing Oracle Database 12c: A Technical Primer ebook, Oracle Press. You can read the complete chapter on controlling data access and restricting privileged data by downloading your own copy. Thanks for reading.

Controlling Privileged Users

System privileges and powerful roles give significant control of the database, including the ability to view all data and make changes to the data. Some administrative users need these powerful privileges for maintenance, tuning, and backups, but they don’t need access to all of the data. Even though the administrative users are trusted, it is important to secure company data assets and personal information even from these privileged accounts in order to prevent unauthorized use by insiders or attackers.

Oracle Database Vault provides several kinds of operational controls within the database including realms, which enforce limits on access to specified objects such as tables and views. After creating a Database Vault realm, objects are added to the realm and database users can be designated as realm participants. This provides access only to the realm participants, and excludes other users, even if they have powerful system privileges like SELECT ANY TABLE that would otherwise allow them to access the objects in the realm.

The following illustration shows an example of two realms, protecting database schemas containing human resources (HR) and finance (FIN) data. Once enabled, the realms prevent privileged administrative users or other application owners from using their elevated privileges to access data. The privileged application owner HR is prevented from accessing data inside the FIN realm, and even an administrator with the DBA role is unable to access data in the HR and FIN realms.

Oracle Database Vault Realms

In addition to regular realms, Oracle Database 12c adds the ability to create mandatory realms. A regular realm will block the use of system privileges such as SELECT ANY TABLE if the user is not a realm participant, but it doesn’t block the schema owner or other users who gain access to the data using object privileges. Mandatory realms prevent access by anyone who is not a realm participant. One popular use for a mandatory realm is to continue to protect sensitive data during patching and upgrades, when an administrator needs to make changes to the application schema but should not have access to the data tables in that schema.

When Oracle Database Vault is configured, a couple of additional users are created. The first of these is the Database Vault owner, who can create and manage realms to control access to sensitive data. The second user is the Database Vault account manager, who has the responsibility for creating users in the database. While a single user could perform both functions, the ability to divide these duties among multiple users allows for separation of duty as described earlier. Furthermore, there is a DVOWNER role that can be granted to other users to delegate the ability to manage Database Vault realms. This role should be granted to administrators who are responsible for the security configuration of the database, rather than the general database administrator.

The following illustration shows the use of the Database Configuration Assistant for enabling Oracle Database Vault. Management of Database Vault requires the use of these specialized users and roles. The SYSDBA administrative privilege cannot be used for realm or user management when Database Vault is enabled.

Oracle Database Vault and Label Security

From the free ebook, Oracle Database 12c: A Technical Primer by Michelle Malcher, Paul Needham, and Scott Rotondo.


Who are we?

Follow us on

  • TwitterFacebookLinkedIn


« March 2014 »