Securing any system is a complex task, but the Oracle database poses special challenges. This series of posts aims to analyze the problem and come to conclusions about what can and should be done in real world environments.
The first step in security analysis is risk assessment, so part 1 will focus on:
Who poses a risk to information in the Oracle database?
This question has the regular list of usual suspects: internal threats, external threats, privileged users etc. However, in order to be able to move forward with our analysis, we will try to be a little more specific about this list.
Part 2 discussed How will the breach occur.
DBAs and Privileged users
Some view the DBAs as the highest risk to the Oracle database because they have the most opportunity. In reality, most DBAs are honest and are offended by the suggestion of embezzlement or theft. Monitoring DBA activity tends to provide sufficient deterrence so that even DBAs who are tempted to cross the line, would not do so.
Internal users with database access
The majority of database access is done via applications and as a result most individuals that have access to information do not have direct database access. There are, however, some cases where individuals have direct database access. Such access could be granted to use data mining tools, reporting tools, or to analysts that need the access to perform their job duties.
The problem is that while these individuals have more limited database access than DBAs, they tend to have just as much access to sensitive information. Overall, I would rate their risk to the Oracle database as higher than that of the DBAs because of two reasons:
- If there are individuals in the organization with direct access to the Oracle database, this group of individuals tends to be larger than the handful of DBAs.
- DBAs have had unlimited access to information throughout their career and are used to it. This might not be the case with other individuals that have direct database access.
Internal users with system access
There are system administrators, storage administrators, backup administrators, network administrators, operations personal, and sometimes just plain users with access to the operating system, storage, network, and backups used by the Oracle databases. Their credentials might give them direct access to database resources or just to the systems that those resources reside on. I group all these individuals together because they have this in common:
- They have certain access to systems that the Oracle database uses
- They might not have the Oracle knowledge to abuse their access
Users with application access
There are probably many individuals inside and outside the organization with indirect access to data. This access is done via an application that restricts what can be done by each individual. Unfortunately, this access can be abused by various means that we will discuss in the next posts in this series.
The risks posed by this group vary significantly based on the application and the user base. Some applications are internal to the organization and protected by the organizational firewall, while others are open to the internet with less restrictions. The ability to vet the users of the application also depends on the type of application.
While the motivation of this group as a whole to abuse access tends to be higher, the opportunity they have is more limited.
Users with code access
No application is written by itself, and as such there are technical people that build and maintain it. While some of these individuals might have direct access to the data as well, they all have indirect access to the data through the code they work on.
Internal users with or without computer access
There are many individuals inside the organization the have no official access to the application or the database. However, being inside the corporate firewall, there are fewer barriers between them and the data we wish to protect.
Some of these individuals have computer access and the time to try and abuse it, while others don’t even have a computer to work on. I still group all these individuals into a single group because they posses these qualities:
- They spend every day (or most days) in an environment that has network ports and computer terminals.
- The were not given access to sensitive information and need to go to certain lengths to try and obtain such access.
- They might be aware of the information that exist in the company databases.
- They have some knowledge of the corporate structure, know other individuals in the organization, and have access to the work environment of other employees.
- They tend to be under the radar when it comes to information security as they are not typically listed as a threat.
This is the infamous group of hackers that for whatever reason attempts to gain access to sensitive information. The unique thing about this group is that in most cases they don’t distinguish between your company and the one next door.
I have already devoted two blog entries to this group: Hackers and Hacker defense. I will touch on this subject a little more in future posts.