Security Scope - Two Passwords Stored Everywhere

The core problem of Oracle security is that it was never designed for the purposes it is currently used for. You might not realize it, but no production database can use most of the security measures the way there were intended.
Go to page123All

History

To properly understand the security issues, it is important to understand a little bit of the history behind relational databases in general and the Oracle database in particular.
The Oracle database along with many other relational databases started in the late 70’s as a result of an IBM research project called System R. The purpose of relational databases was to allow researchers an efficient and convenient means of analyzing data. The SQL language that evolved from System R was, therefore, English like. An English like query language makes it much easier for people to interact with the database.
While the original concepts of relational databases remain at the heart of all modern database systems, the practical usage has changed significantly. Nowadays, databases are mostly used by programs called applications. Human beings rarely use the SQL language to query or modify data in a production database.
The Oracle database security model originates in those earlier times when researchers wrote queries directly to the database. A time when individuals stored data in their own accounts, and protecting data by granting users access to tables was an effective means of controlling who can see what. But that world has changed.
Today, most human interaction with the Oracle database is done through applications. If you’re using an Oracle database you have some sort of application to access it. There are many types of applications ranging from small home grown apps to vast applications like Oracle EBS, Siebel, PeopleSoft, SAP, etc. An application can run in a web server, use a thick client, be fully purchased, partially customized or completely home grown.

One Password

Applications brought on many changes, but the one we’re focusing on it that applications consolidate all the data of all their users. There are several problems this new model introduces:
  • All the data from all the users is in a single Oracle schema – that means that a single Oracle account with a single Oracle password protect all the data
  • Worse of all, data from different users is mixed into the same tables. Since Oracle doesn’t have row level security, there is no way to distinguish different user’s data
  • In most cases, the database is not even aware of the different application users – they all come in through the application account
  • In many applications, most of the users require access to most of the data
In other words, this means that the application has to enforce security, and the Oracle security model is mostly disabled. The only security that remains in Oracle is a single user and password that give complete access to all the data.

Second Password

Aside from the application account, the Oracle database also has DBA accounts and privileged accounts like SYS.
The problem in Oracle security is that DBA and privileged accounts have unrestricted access to all the data in the database.

The Problem

If security moved one level up from the Oracle database to the application, why do we need to have security in the Oracle database? The reason is that while the Oracle database security model is not in use, people can still connect to the database, run queries, change data, and more.
The only protection the Oracle database has is that you need a user and password to get you in. Unfortunately, once you’ve logged into the Oracle database you have full access to all the data. Either type of account will let you do anything, and no one will even know what you did.
Since the two passwords (application and DBA) give unlimited and un-monitored access, they should be kept extra safe.. but are they?

The Application Password

Lets make a short list of who has access to the application password:
  • Application administrators
  • Some of the developers
  • Development tools used by the developers often store passwords
  • At least one manager
  • Business analyst that need access
  • 24×7 support staff
  • Contractors, partners, or an outsourcing company helping to maintain the application
  • A spreadsheet used by the contractor/partner/outsourcing company to keep track of all the passwords they have
This password is also systematically stored in:
  • The application (on the application servers)
  • Maintenance scripts
  • ETL tools (ETL tools are also notorious for being lax on security)
  • Monitoring tools
Application passwords tend to change very infrequently (sometimes never). So once compromised, they remain so for a long time. That includes employees that left the company.

The DBA Password

Lets make a short list of where DBA passwords are stored:
  • The the head of the DBAs
  • In applications DBAs use to connect to the database (like Toad) often store passwords
  • In web broswers DBAs use to connect to the database
  • A contractor, partner, or outsourcing company performing administrative work
  • A spreadsheet used by the contractor/partner/outsourcing company to keep track of all the passwords they have
The SYS password is a little more tricky since it has to be known to all the DBAs. There’s a couple of options:
  • The SYS password is different in every database. This means the DBAs have a list (usually in a spreadsheet) to keep track of the passwords. We’ll come back to this list later.
  • The SYS password is the same in all the databases. This means DBAs can remember it, but once it’s compromised, all the databases are compromised. If it changes frequently, the DBAs will also have it written down somewhere.

Additional Personnel

While the list so far seems a little longer than you thought, these Oracle passwords are actually accessible to a lot more people. These passwords are stored in desktops in spreadsheets, development tools, DBA tools, and web browsers. These desktops are accessible to:
  • Windows domain administrators
  • Helpdesk personnel (e.g. via remote desktop control)
Backup administrators also have access both to the passwords and even the entire database files. This also means that whoever has access to the backup tapes has access to the information.
Passwords stored in spreadsheets are often stored on file servers and/or in the mail system. That means that the file server administrators and the mail server administrators have access to those passwords.

The Bigger Problem

The bottom line is that most of the IT staff, significant portions of the development staff, some ex-employees, and several contractors/partners can gain access to all the data in the database.
The more applications consolidate data, the bigger the security problem becomes. With a trend in modern ERP and data warehouse applications to consolidate ALL the data in the organization.

The Only Solution

We cannot change the Oracle security model, nor can we stop the train of data consolidation. The two Oracle passwords that are accessible to many of the employees is just a reality of modern IT. But something has to be done to mitigate this impossible security risk.
The solution is database auditing. It creates deterrence, alerts on security breaches, and provides forensic information if a breach occurs. Read more about the effectiveness of database auditing against the Internal Risk

What's next?

I want to know more about Core Audit!
Great! Here are a few options:
  • Read more about Core Audit features, reports, etc.
  • Try our Online Demo and play with Core Audit right now
  • Ask for a Personal Demo from one of our experts and get all your questions answered
  • Download a Free Trial and experience Core Audit on your systems
I only want more information, not a product
Not a problem, here is a list of relevant pages, and we are always available to answer any question
  • Fraud – Read
  • Hackers – Read
  • Rationalizing Oracle database auditing – Read
  • Oracle security checklist – Read
  • Oracle security – strengths & weaknesses – Read
  • How to prevent a database breach – Read
  • Oracle database security – Read