For instance, in July 2009 the Secret Service arrested two DBAs for using credit card details to steal millions of dollars. This arrest highlights the importance of vetting DBAs for personal integrity and honesty.
According to court records, one of the men arrested worked as a computer database analyst for American Express and was one of only a few people there who could have "possibly downloaded all of their account holders' information including the PIN numbers use to access money from ATM machines at various banks." The other man arrested had over 100 bogus gift cards and credit cards that had been re-encoded with information from valid American Express customers.
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, to protect against internal database security threats.
There has also been a huge backlash against Oracle outsourcing as companies discover that allowing people outside the USA to touch their data is not a good idea. A recent story on the perils posed by offshore outsourcing notes the risks detailing how Oracle shops were completely destroyed by offshore support companies that allowed their data to be stolen.
How bad Oracle security can destroy your company.
It's sad, but there are trusted Oracle DBA's who will abuse their position by perpetrating criminals acts that can put your company out of business. It continues to amaze me how many Oracle shops engage offshore support organizations that have virtually no resources to protect against data theft.
In one notable case, I was contracted to fix performance problems at an Oracle shop that was in the business of collecting and re-selling real estate data. When diagnosing the system I discovered a sneaky code snippet which was vacuuming their data and e-mailing it to China. When I 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 right out from under them for several months. The vacuum used a "root kit," which is a method where standard Linux commands are replaced with an alias in order to disguise the program stealing the data. In this case the process command "ps" was replaced with the command "ps|grep –i vacuum", so 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 off-shoring their Oracle DBA activities. Unfortunately, you don't have to be an expert to use a root kit, and worse, they can be easily downloaded from the Internet. I spoke with the FBI Cybercrime unit in Charlotte, N.C. and was told that an American shop has virtually no protection when somebody from outside the country 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 database security threats are a big issue, and I have collected many security horror stories. It's critical to audit your DBAs, and to do strict background and security checks on them.
I recommend that all Oracle shops rely on strict background checks -- both criminal and credit -- to ensure that they hire honest DBA's. And it's not just major crimes that signal a red flag. Many major corporations will not hire DBA's with a history of dishonesty, no matter how minor. I won't even hire a DBA with parking tickets because it indicates disrespect for the law.
Background checks can be expensive and time consuming, but they are well worth the cost because the risks of exposure are astronomical. To save money some IT shops use remote DBA providers that have US government security clearance.
But it's not just the Oracle DBA's that pose a threat, it extends to all privileged users. IT managers report that internal fraud is the most common type of threat and so special auditing mechanisms must be used to audit all access by authorized employees. Inside job threats include the following:
- 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.
- 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.
- 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 privileged passwords. These attacks are usually easy to fix using tools such as X-Windows that allow screen images to be redirected onto other screens.
- 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. There 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.
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, an Oracle 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 is tracked within the application layer.
This issue of "privileged user" access represents 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.
There are specialized Oracle auditing tools available that will audit the DBA and other privileged users, but they can be expensive and difficult to manage.
Oracle security and government regulations
Oracle shops falling under the scope of Federal privacy laws such as HIPAA are required to appoint a full-time employee, who is independent from the SA and DBA staff, to control the auditing of an Oracle security analyst.
The Oracle security analyst must possess a combination of technical, application and management skills that are 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 short 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 the routine DBA duties, must set-off alarms for the security administrator.
It is sad commentary, but today you just can't trust anybody, 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 IOUG 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 protection from internal database security threats.
Don Burleson is the author of more than 30 Oracle books and manages BC Remote DBA, America's largest independent Oracle remote DBA support provider.