Preventing insider Oracle security threats Oracle Tips by Burleson Consulting

Preventing insider Oracle security threats

The Independent Oracle Users Group has just released their 2009 Oracle security survey, and it notes a disturbing trend where “insider security breaches” remain a major problem for Oracle shops.

In  July 2009, the Secret Service arrested two DBA's for using credit card details to steal millions of dollars. 

This arrest highlights the importance of vetting DBA's for personal integrity and honesty.  Arrested is Mr. Curley, a DBA working for Fedex.  There is also mention of a co-conspirator, possibly named Moe or Larry:

"Curley had not only worked as a computer database analyst for American Express, he was one of the few who "could have possibly downloaded all of their account holders information, including the PIN numbers used to access money from ATM machines at various banks," according to court records.

Curley had recently been released from that job"

Michael Thomas, another DBA, was also arrested for theft:

"Police said he too had more than 100 bogus gift cards and credit cards that had been re-encoded with information from valid American Express customers. Investigators also wrote they have surveillance video of Thomas using the bogus cards at ATMs."

There are many cases where a DBA has stolen from their employers, and it's agreed that all security mechanisms should prevent the DBA from having complete power over system security, especially the audit trails.

We are also seeing a huge backlash against Oracle outsourcing as companies discover that allowing people outside the USA to touch their data is not a good idea.  This Computerworld article titled Offshore Outsourcing Poses Privacy Perils, notes the risks, and there are Oracle shops that have been completely destroyed by offshore Oracle support companies who allowed their data to be stolen.  Here is one horror story that I was involved with.

 

How bad Oracle security can destroy your company

It’s sad, but there are trusted Oracle DBA’s who, given the opportunity, will abuse their privileged status and became criminals.  Make no mistake, a dishonest DBA can put your entire company out of business, and it amazes me how many Oracle shops will engage foreign support where they have virtually no resource for data theft.  In one notable case, I was engaged to fix performance problems on an Oracle shop that was in the business of collecting and re-selling real estate data.

When diagnosing the system I discovered sneaky code snippet which was vacuuming their data and e-mailing it to China!  When we asked them about it, they said that they had decided to save money by using a Canadian Oracle DBA provider, who had since gone out of business.

Upon inspection, the e-mail vacuum was very sophisticated and unobtrusive and had been stealing their data from right under their noses for several months!  It used a “root kit”, a method whereby standard Linux commands are replaced with an alias in order to disguise the data stealing program.  In this case, the process command “ps” was replaced with the command “ps|grep –i vacuum”, such that the process would not appear to anybody who was looking for a malicious program.

This company went out of business shortly thereafter, the victim of the “penny wise, pound foolish” approach of offshoring their Oracle DBA activities.  Sadly, you don’t have to be an expert to use a root kit.  They can be downloaded from the web.  I spoke with the FBI Cybercrime unit in Charlotte North Carolina and I was told that a USA shop has virtually no protection when somebody from outside the United States accesses their server.  So, if you cannot trust the DBA, who can you trust?

 

Can you trust the Oracle DBA?

In my experience as an Oracle forensics analyst, internal threats are a big issue, and there are many security Horror Stories. There are specialized Oracle auditing tools that audit the DBA and other privileged users, but these are expensive and difficult to manage.   

DBA's are people too, and many security exposures have been traced to dishonest DBA's.  It's critical to audit the DBA, and to do strict background and security checks for DBA's.  I won't even hire a DBA with parking tickets because it indicates disrespect for the law. 

I recommend that all Oracle shops rely on strict background checks (both criminal and credit checks) to ensure that they hire honest DBA's.  And it’s not just major crimes that signal a red flag, and many major corporations will not hire DBA's with a history of dishonesty, no matter how minor.

·         A credit history of slow payments shows moral turpitude and disrespect for obligations.

·         Even petty crimes like multiple parking tickets indicate disrespect for authority.

But background checks are expensive and time consuming, but regardless of the costs, it’s well worth the cost because the risks of exposure are astronomical.  To save money, some shops use remote DBA providers that offer DBA’s with US government security clearances, because anybody who is cleared to see top secret information can be trusted to be a DBA. 

But it’s not just the Oracle DBA’s; all privileged users pose a security risk.  IT managers report that internal fraud is the most common type of threat and special auditing mechanisms must be used to audit all access by authorized employees.  Inside job threats include the following: 

o   Root kit attacks – In a root kit attack, the operating system is compromised.  I once fixed a client site with a root kit that had installed a daemon process that was constantly accessing confidential information and e-mailing it to a competitor.  This attack went undiscovered for more than a year and virtually all of the company’s proprietary information was lost.

o   Fire-me attacks – Internal IT personnel have been known to write routines that trigger a data extraction on the day when their user ID is removed from the computer system.  Because most IT procedures required pulling the user ID before notifying the employee, these hackers will return home to find all of the confidential information waiting for them in their in-box.
 

o   Trojan horse – Once an employee gets the internal IP address of another employee, they can map-out phony sign-on screens to their boss and get a privileged password.  These attacks are usually easy using tools such as X-Windows that allow screen images to be redirected onto other screens.

o   PC Privacy tools – Common tools such as PC Anywhere can be used to look-over the shoulder of a co-employee, snooping into their activities and passwords.

Inside jobs are the most difficult to detect, but complete audits will always reveal the “who” and “how” aspects of the attack.  For example, coded implants can be tracked using your source code control system software that is required by almost all Federal Regulations including SOX and HIPAA. 

Here are many documented cases of data disclosure by disgruntled employees, especially “privileged users” who were given unaudited access privileges.  Let’s look at some specific real-world horror stories.  These are not fictional stories. They actually happened, and they serve as examples of what can happen when a slack IT manager entrusts their access and auditing controls to a Systems Administrator or Database Administrator.

Auditing privileged users

While general security and auditing are passive activities, a comprehensive solution to auditing requires real-time reporting of active attempts to bypass security.  Remember, smart shops close all back-door data access (e.g. ODBC) and enforce data access via the application layer.  However, we must still create an alert mechanism for all data access attempts at all layers, whether malicious or benign.  For example, the Oracle Database Administrator (DBA) often needs to view database information as part of their administrative duties, and Federal laws mandate that this data access be tracked just as data access within the application layer.

This issue of “privilege user” access is a serious security exposure.  Because the auditing solution must audit the access of Systems Administrators and Oracle DBA’s, these employees must not have any control or responsibilities for the auditing mechanism.

This segregation of duties is critical because it is considered malfeasance to give the “Keys to the Kingdom” to anyone charged with maintaining the servers and databases.  In many cases disgruntled employees may view confidential information for personal gain and sometimes create mechanisms to disclose the information if they are terminated from employment.

Oracle security and Government regulations

Oracle shops falling under the scope of Federal privacy laws such as HIPPA are required to appoint a full-time employee, independent from the SA and DBA staff to control the auditing.  This job role has many names including the Security Privacy Auditing Manager (SPAM), Privacy Access Manager (PAM), Security Privacy Administrator (SPA)  and sundry other job titles.

Regardless of the job title, the security analyst must possess a combination of technical, application and management skills, unique to each organization.  For example, large health care companies normally employ a Medical Informatacist as the SPA, usually a highly trained Medical Doctor (MD) with skills in application design, systems architecture, systems administration and database administration. Financial institutions will employ a Certified Public Accountant (CPA) with a strong technical background.

In sum, the auditing collection, consolidation and reporting must be the responsibility of a separate IT entity, solely charged with managing all data privacy audits.  Any access outside the application layer, whether malicious or part of routine DBA duties, must set-off alarms for the security administrator.

In sum, you cannot trust anybody these days and Oracle managers must address the issue of allowing their privileged Oracle staff to have full access to the data which is the life blood of their business. 

As the 2009 Oracle security survey indicates, Oracle shops are either installing complex security tools to audit their privileged employees or using background checks or trusted remote DBA support providers to ensure proper security.

 

 

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts.  You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.