Database Security with focus on Hyperion Database

University of Colorado at Colorado Springs

CS 691

Fadi Mohsen

Aug 1, 2009

ABSTRACT

The security of databases has been changed because of the invention of web. Before web,

databases were easy to protect using the basic access technique, but when the web systems came

out, it became tough task. The attacks increased, also the type of attacks changed. For example,

SQL injection is the most famous attack targeting the web-based database systems, and a lot of

research has been done to stop it. The security in general is all about managing the relationships

between three things, subjects, objects and access roles [2]. (i) Subjects are the active entities

(such as processes) and objects are the passive entities (such as files), (iii) access roles define

what subjects can do with the objects. Like the administrator (subject) can delete database table

(object).

In this paper I will present a set of research methods proposed to protect the databases from

being attacked, after that I will cover the security side in the Hyperion database.

1. INTRODUCTION

First of all let me bring an important point which is, the efficiency of any proposed security

related solution depends not just on the solution itself, but also on actually using it. In every

database system there are a huge number of security options ready to be set, but most of database

developers simply don’t use it, because of the time constraints or they don’t know about it. The

database guy has nothing to do with security, and at the same time the security guy has no idea

about database design.

Researchers adapted many approaches to secure the database system, but they did agree that the

complexity of securing web-based database system came from the huge no of users accessing the

web-application which is in charge of applying security, in the past the applications were run

from the users’ desktop. These users were known to the application and their number was fixed

or limited. Web applications on the other hand are different completely, since these applications

are run from the users’ browsers. The users of web applications can be casual users and their

number is not limited. The browser does not directly connect to the database, but instead transfer

a request to a web server [1]. So, the database can’t identify who is accessing it, since each time

the super-user (web server) make the request and take back the results. So, there is a need to let

the database knows who is requesting, so that role-based security can be implemented.

2 Researchers Approaches to Database Security

2.1 Fine-grained Access Control to Web Databases

It is a new method for protecting web-based databases; it utilizes the databases’ built-in access

control mechanisms enhanced with Parameterized Views and adapts them to work with web

applications. Their proposed access control mechanism is applicable for any existing databases

and is capable to prevent many kinds of attacks, thus significantly decreases the web databases’

attack surface. Views are the basic block of securing relational database, since it presets to the

user the only piece of the database that interests her. But again, since the database deals only

with a strong user (web server user), traditional views kind of restricted and needs to be revived

in order to best secure the web database. They come up with the parameterized view that is

capable of transferring the user’ identity to the database, after that based on it the view will show

relevant data. And that what they call fine-grained access control to the web databases. Actually,

the concept of parameterized view is an old one, many researchers talked about it in 1990’s, but

mainly in the context of object-oriented database. The results show that there is no performance

degradation when the number of concurrent users grows. It also seems that with comparison to

the traditional table-based application, the parameterized view-based web application does not

require additional definition of indexes or query normalizations/optimizations [1].

2.2 MANDATORY SECURITY IN OBJECT-ORIENTED DATABASE SYSTEMS

They considered only the ORION object-oriented data model which was developed at MCC

[BANE871]. It describes how we can incorporate security to this model. They called this model

SORION. Then, they came out with a security policy based on it. Two issues were discussed,

ployinstantiation and handling the inference problem. Finally they described how mandatory

security constraints, which are rules assigning security levels to data, may be handled [2].

In general, multilevel secure database management system (MLS/DBMS) users subjected

to different security levels access and share a database consisting of data at different sensitivity

levels. An effective security policy for MIS/DBMS should ensure that the principle of least

privileges security concept is met, which means a subject should be given only those privileges

that it needs to in order to complete its task. The earliest of security policies, the Bell and

LaPadula security model [BELL75], is stated below.

(i) Subjects are the active entities (such as processes) and

objects are the passive entities (such as files)

(ii) Subjects and objects are assigned security levels. The

set of security levels form a partially ordered lattice.(e.g.

Unclassified < Confidential c Secret < TopSecret).

(iii) simple security property: A subject has read access to

an object if the subject’s security level dominates the

security level of the object

(iv) *-property: A subject has write access to an object if

the subject’s security level is dominated by the security

level of the object.

As stated in [BANE87], all conceptual entities in ORION are modeled as objects. A class

is a group of objects that has the same characteristics. A class could be a system-defined class,

such as a class of integers or strings, or it could be a user-defined class such as a class of

documents or employees. The objects of a class are called its instances. Associated with each

class is a set of instance variables that describe the state of the instances of the class. Object-ID,

which uniquely identifies an object of the class is also an instance variable. For example, a class

of employees could have Object-Id, social security number, name, salary and department as its

instance variables [2].

So, the relationships between classes and objects should be reflected into the security

policy. For example, if Ali is an employee, but at the same time he is a Director, then he would

inherit the privileges from employee, and director classes. This terminology makes it easier to

the security designers.

2.3 Role-Based Databases Security, Object Oriented & Separation of Duty

The combined the object-oriented and role-based concepts to apply separation of duty. Roles

essentially partition database information into access contexts. Methods (O-O) associated with a

database object, also partition the object interface to provide windowed access to object

information. A set of privileges forms a Role, which can be assigned to a group of users.

Thinking in Role-based protection makes the task of managing large number of users easy and

trivial. So we have now, privileges and roles. The following are there definitions [4].

Definition I A privilege is a pair (z, m) where x represents (name, identifier, etc.) an

object (data item, resource, etc.) and m is a non-empty list of access modaltries for object z.

Definition 2 A role is a named collection of privileges. It is a pair (rname, plist} where

rname is the role name and plist is the privilege list.

There should some kind of mapping between roles and the information. Like, role1

related to the table1, file1, and printer 1. Etc. Now, when user has a role 1 then he will be able to

access table1 data.

In the O-O paradigm, methods, the only means of access to object information, provide a

windowing effect on this information. By authorizing different roles to execute different methods

of an object, we effectively distribute the object interface across roles and hence the individuals

authorized for the associated roles [4].

3 Hyperion Security Administration

In the previous section we covered some of the methods proposed by researchers to enforce

security and access. In this section I will cover the security policies that are adopted in Hyperion

database. I will first give an introduction to the Hyperion database technology, then I will cover

the security side.

3.1 Hyperion Database

Hyperion Enterprise is a database that contains data that can be used to develop and print

reports [6]. The component Retrieve is an Excel interface that responsible for pulling numbers

from the Hyperion database into the Excel. The scenario is as follows, if we have a company

with different branches, then the accounting information is entered into the Hyperion

Database at the central location (the head) and then used by the branches (branch 1, branch 2,

etc. ) to manage their accounts. Hyperion facilitates the process of viewing financial information

with different formats. Figure 1 shows The Enterprise Desktop which serves as main controller

for all operations performed in the Hyperion Enterprise system. The eleven large icons in the

lower three-fourths of the screen are Desktop icons [6].

Figure 1 Enterprise Desktop

Actual Hyperion Database data is seen in only the Data Entry and the Reports modules. The

Modules that are gray are used by the database administrators [6].

3.2 Security Components

Hyperion application security falls into two main categories, authentication and authorization.

And each one of the previously mentioned consists of several components.

3.2.1 User Authentication

User authentication enables single sign-on functionality across Hyperion products by validating

The login information of each user to determine authenticated users. User authentication, along

with product-specific authorization, grants the user access to Hyperion products. Authorization

is granted through provisioning [5].

Single sign-on (SSO) is a session and user authentication process that permits a Hyperion

Product user to enter credentials only once at the beginning of a session to access multiple

Hyperion products. SSO, which is requested at session initiation, eliminates the need to log in

separately to each Hyperion product to which the user has access [5].

User Authentication consists of three components, Security API, Native directory, and User

Directories. All of them used to support the SSO.

The Security Application Programming Interface (Security API) is the main interface to validate

users and interpret user access to Hyperion products. It is a Java API that enables Hyperion

products to authenticate users against user directories configured in Oracle's Hyperion® Shared

Services. It also allows integration with a security agents such as Netegrity SiteMinder, and

retrieval of users and groups based on names and identities. Each Hyperion application

implements the Security API to support user authentication [5].

Native directory (OpenLDAP), an open source Lightweight Directory Access Protocol (LDAP)-

enabled user directory, is bundled and configured with Shared Services.

Native Directory serves two functions:

- Used to maintain and manage the default Shared Services user accounts required by

Hyperion products

- Is the central storage for all Hyperion provisioning information because it stores the

relationships between users, groups, and roles.

User directories refer to any corporate user and identity management system compatible

with Shared Services. Hyperion products are supported on a large number of user directories.

These include LDAP-enabled user directories, such as Sun Java System Directory Server

(formerly SunONE Directory Server) and Microsoft Active Directory, Windows NT LAN

Manager (NTLM); SAP Provider; and custom-built user directories that support LDAP version

3.In addition to Native Directory, which is automatically configured for your environment, one

or more user directories can be configured as the user information provider for Hyperion

products. User directories used with Hyperion products must contain an account for each user

who accesses Hyperion products. These users may be assigned to groups to facilitate

provisioning [5].

I will present two scenarios for the user authentication process, in the first one is signing

on directly to the Hyperion products, the other on is signing on from external systems. Figure 2

shows the user authentication main components; we will use it to explain the first scenario.

Figure 2 User Authentication main components.

First scenario, user signs in directly to the Hyperion products.

Direct authentication connects Hyperion products to available user directories to verify the user

name and password (credentials) entered on the Login screen.

1. Using a browser, users access the Hyperion product login screen. They enter user names

and passwords. The Security API implemented on the Hyperion product queries the configured

user directories (including Native Directory) to verify user credentials. A search order is used to

establish the search sequence. On finding a matching user account in a user directory, the

search is terminated and the user's information is returned to the Hyperion product.

Access to Hyperion product is denied if a user account is not found in any of the user

directories.

2. Using the retrieved user information, the Hyperion product queries Shared Services to

obtain provisioning details for the user. Provisioning details are stored in Native Directory.

On receiving provisioning information from Shared Services, the appropriate Hyperion product

is made available to the user. At this point, SSO is enabled for all Hyperion products for which

that user is provisioned. Access permissions within Hyperion products are determined by the

provisioning information.

Second scenario, user signs in to the Hyperion products from external systems.

Hyperion products can be configured to accept pre-authenticated users from external sources,

such as Netegrity SiteMinder and SAP Enterprise Portal, to enable SSO. In this scenario,

Hyperion products use the user information provided by a trusted external source to determine

access permissions of users.

SSO with SAP is supported by accepting an SAP logon ticket. In this scenario, users defined in

an SAP user directory can navigate between the SAP Portal and Hyperion products. If an SAP

provider is configured, users can also directly log on to Hyperion products using the user ID

and password stored in the SAP system. The SAP provider creates the SAP logon ticket to

enableSSO with SAP systems.

Figure 3 Signing in from external systems.

1. Using a browser, users access the login screen of a web identity management solution (for

example, SiteMinder) or SAP Enterprise Portal. They enter user names and passwords,

which are validated against configured user directories to verify user authenticity. Hyperion

products are also configured to work with these user directories.

When users navigate to a Hyperion product, information about the authenticated user is

passed to Hyperion product, which accepts the information as valid.

If the user logged on to SAP Portal, an SAP logon ticket is passed to Hyperion product. The

Security API implemented on Hyperion product decrypts the SAP logon ticket using a

specified SAP certificate.

If the user logged on to a web identity management solution, a custom HYPLOGIN HTTP

header is passed to Hyperion product.

2. To verify user credentials, Hyperion product tries to locate the user in one of the user

directories based on the search order. If a matching user account is found, user information

is returned to Hyperion product.

3. Using the retrieved user information, Hyperion product queries Shared Services to obtain

provisioning details for the user.

On receiving user provisioning information from Shared Services, the Hyperion product is

made available to the user. SSO is then enabled for all Hyperion products for which that

user is provisioned.

3.2.2 Provisioning (Role-Based Authorization)

Hyperion application security determines user access to products using the concept of roles. A

role is a set of permissions that determines user access to product functions.

Each Hyperion product provides several default roles tailored to suit various business needs.

Predefined roles from each Hyperion application registered with Shared Services are available

from User Management Console. These roles are used for provisioning. You may also create

additional roles that aggregate the default roles to suit specific requirements. The process of

granting users and groups specific access permissions to Hyperion resources is called

provisioning.

Native Directory and configured user directories are sources for user and group information for

the provisioning (authorization) process. You can browse and provision users and groups from

all configured user directories from User Management Console. Provisioning data is stored in

Native Directory. You can also use application-specific aggregated roles created in Native

Directory in the provisioning process.

This illustration depicts a broad overview of the authorization process:

1. After a user is authenticated, Hyperion product queries the user directories to determine

the user's groups.

2. Hyperion product uses the group and user information to retrieve the user's provisioning

data from Shared Services. The product uses this data to determine resources that a user can

access.

Product-specific provisioning tasks, such as setting product-specific access control, are

completed from each product. This data is combined with provisioning data to determine

the product access for users.

Role-based provisioning of Hyperion products uses these concepts [5].

Roles

A role is a construct (similar to access control list) that defines the access permissions granted

to users and groups to perform functions on Hyperion resources. It is a combination of resource

or resource types (what users can access; for example, a report) and actions that users can

perform on the resource (for example, view and edit).

Access to Hyperion application resources is restricted; users can access them only after a role

that provides access is assigned to the user or to the group to which the user belongs. Access

restrictions based on roles enable administrators to control and manage application access [5].

Hyperion database has three kinds of roles. Global roles, predefined roles, and aggregated

roles. Global roles are Shared Services roles that enable users to perform certain tasks within the

User Management Console. (e.g. Administrator, Directory manager, Project manager, and LCM

manager). Predefined roles are built-in roles in Hyperion products. You cannot delete these roles

from the product. Predefined roles are registered with Shared Services during the application

registration process. Aggregated roles are custom roles that aggregate multiple product roles

within a Hyperion product. An aggregated role consists of multiple roles, including other

aggregated roles. For example, a Shared Services Administrator or Provisioning Manager can

create a role for Planning that combines the Planner and View User roles into an aggregated role.

Aggregating roles can simplify the administration of products that have a large number of

granular roles. You cannot create an aggregated role that spans products, and you cannot include

global Shared Services roles in aggregated roles. Aggregated roles are also known as custom

roles.

Users

User directories store information about the users who can access Hyperion products. Both the

Authentication and the authorization processes utilize user information. You can only create

and manage Native Directory users from User Management Console.

Users from all configured user directories are visible from User Management Console. These

users can be individually provisioned to grant access rights on the Hyperion products registered

with Shared Services. Hyperion does not recommend the provisioning of individual users.

Groups

Groups are containers for users or other groups. You can create and manage Native Directory

groups from User Management Console. Groups from all configured user directories are

displayed in User Management Console. You can provision these groups to grant permissions

for Hyperion products registered with Shared Services.

4 Security VS Performance

It became a trivial fact that the more your application or system is secure the less performance

you will get. Windows for instance, each time a new version of windows released, users start

complaining about the performance, since the new version has more options, graphics, and

security. So, we have to choose between a high unsecure systems or slow secure systems. For

some users’ performance is a high demand, especially if they have nothing to secure, in other

hand, other agents and companies, security is on the top, so they prefer the second choice. A

friend of mine working as a Hyperion Database administrator for Verizon told me a true story

regarding the above argument. He told me that when they moved the security from individual

application to the central security (SSO) the performance got affected. He gave me an example,

which is applying the security to a Hyperion database used to take 5 minutes, but after that

started to take 30 minutes.

5 Conclusion

To fully utilize the security capabilities that exist within our application, the gab between

security guys and database developer, administrators should be reduced. Educating the employee

also plays a great role in approaching security. Everyone should be aware of the importance of

applying security. Applying all of the security options included within our applications and

systems is critical to our success and safety, even though that might affect the performance.

5 References

[1] Fine-grained Access Control to Web Databases, Alex Roichman Ehud Gudes Department of Computer Science, Department of Computer Science, The Open University, Raanana, Israel The Open University, Raanana, Israel, and Alexaro1@012.net.il Department of Computer Science, Ben-Gurion University, Beer-Sheva, IsraelEhud@cs.bgu.ac.il

[2] MANDATORY SECURITY IN OBJECT-ORIENTED DATABASE SYSTEMS M.B.Thuraisingham The MITRE Corporation, Bedford, MA, 01730

[3] Database Security, Teresa F. Lunt 1 Computer Science Laboratory SRI International Menlo Park, California 94025, Eduardo B. Fernandez Dept. of Computer Engineering Florida Atlantic University Boca Raton, Florida 33431

[4] Role-Based Databases Security, Object Oriented & Separation of Duty, Matunda Nyanchama & Sylvia Osborn * email : {matunda, sylvia}~csd, uwo. Ca October 11, 1993

[5] Hyperion Security Administration Guide, Hyperion Release 9.3.1, http://download.oracle.com/docs/cd/E10530_01/doc/epm.931/hyp_security_guide.pdf

[6] An Introduction to Hyperion Database, Controller's Department 3607 inistrative Services Building, http://www.controller.iastate.edu/controller/hypdoc.pdf