Database Security: Research Project

Database Security
Research Project

Database Security Group – CS4235

Ryan Connelly
Robert Miller
Neeraj Kulkarni

1
Database Security: Research Project

ABSTRACT

Database Security is an ever growing concern for all users and companies, mainly

because it is data that an attacker is looking for, and the database is the final destination of the

data. At this point, there is currently no correct solution to solve this problem. We will give a

broad overview of database security and an in-depth review of database encryption and auditing.

Throughout the paper, we have listed possible solutions and defined issues that arise with

database security.

2
Database Security: Research Project

1. Overview

This paper will provide a perspective on database security and its significance to the

current information driven world. Database security is the last line of defense against intruders

when all other network intrusion detection systems fail. The central theme of database security is

to prevent unauthorized access by monitoring, encrypting, and user access control. Current

practices include role-based control policies, server side authentications, built-in and external

database auditing packages, and third party database encryption software with additional

authentication schemes.

There are three cornerstones of database security: prevention, detection, and visibility.

Accurate prevention is needed to stop malicious access or inadvertent changes to sensitive data.

There are different levels of encryption you can use when handling this issue which we will

discuss in our paper. When talking about detection, determining security events and abuse of the

database is the name of the game. Database auditing methods will help narrow down any

changes made to the database. Tracking down these changes can help determine if a database has

been breached. Visibility is looking at how the data is changing over time. Viewing the traffic

patterns and examining database history are help security professionals understand real-time

events and provide accountability for users. Auditing methods can also be helpful with visibility.

We will discuss in detail database encryption, auditing, and then finally open issues and research

to help explain the purpose behind these tools and how they fit into the key tenets of database

security.

3
Database Security: Research Project

2. Database Encryption - Prevention

Database Encryption has become a growing concern for everyone who wants to protect

sensitive data. Encryption has been around for a long time, but figuring out a way to efficiently

and effectively implement it on a mass-scale has become a relatively recent effort. Over the

years journals, magazines, and conferences have published volumes on encryption and the best

way to store secured data. In this report, database encryption is discussed and the implications of

using this technology.

Encrypting databases means protecting data at the source. This option is often seen as an

important security layer used to prevent direct disk access by unauthorized users, when regular

access controls are bypassed. Often, in the case of personal privacy issues, data must only be

viewed by authorized users and thus preventing direct database administrator access to raw data

is required. However, there are disadvantages to using encryption. Application performance may

deteriorate if an inefficient storage/encryption method is used. Encryption activities cause results

to take longer to return and require more processing power. With large data warehouses which

house terabytes of secure data, this can become a serious issue. The more data you have

encrypted, the longer it will take to return a result set. Another disadvantage is that with an

encrypted database, troubleshooting becomes a much more difficult job. With encrypted fields,

DBAs must first decrypt each column/field before a check on the query is possible. For this

reason, encryption is usually added just before data systems go into production mode. At all

times, correct permissions must be set correctly for access to be possible. More on this topic will

also be discussed in the next section.

4
Database Security: Research Project

2.1 Forms of Encryption

We researched on three forms of encryption: Application-Level, Database-Layer, and

Storage-Layer Encryption. We chose to discuss these areas to help convey the specific

advantages and disadvantages for each. There is no one best solution and a simple database-level

encryption module may not be the answer for a particular firm or institution’s problems.

Application-Level Encryption is more suitable for environments where data is being

processed, authorized, and manipulated. An example of this would be websites saving personal

information on its customers (i.e. Banks). This form provides the best flexibility in

encryption/decryption framework design. In other words, system engineers can have more control

of where and when the encryption and decryption occurs. Because the activity takes place in the

front-end of the software application, one can design an application to handle encryption and

decryption at any point in the process. It could occur right after a user hits a submit button, or it

could come after a page confirming the information is correct. Another advantage is that with

this form you can use the standard cryptographic APIs. With these APIs already in place,

developing secure applications becomes faster and more economical. It’s only a matter of

matching the right functionality with the proper purpose. Some disadvantages are that all the

applications in the software package must handle the processing for decryption and encryption.

When retrieving or sending encrypted information from page to page, an encryption layer will

provide this functionality yet may also exacerbate performance issues. Also, when sending data

to a stored procedure, this encrypted data could potentially break the stored procedure. Therefore,

the database must support the inserting of encrypted data.

Database-Layer Encryption is used to read and write data securely to a database. This

form protects against storage media theft, database-level attacks, and malicious database

5
Database Security: Research Project

administrators. Some advantages would be that this would eliminate the re-writing of the

application layer to handle encryption and decryption. If you already have an application in

place, going back and adding functionality to all the pages or modules could be very dangerous.

Someone may simply forget to add this functionality to a page or module that requires it.

Another advantage would be using stored procedures to handle access to the database. Stored

procedures reduce the likelihood of someone using SQL Injection to access your database

through a hardened type-checked interface. Disadvantages of using Database-Layer Encryption

are that all schemas in your database would have to change. If you have a complex, mission-

critical database already set up, then changing underlying designs would be a costly and

unreasonable exercise. The company would also have to re-work the application layer to use

stored procedures. As always, it is best to encrypt only the minimum required set of columns. A

poorly planned encryption schema may drastically reduce performance as complex queries often

span multiple tables and fields.

Storage-Layer Encryption is suitable for encrypting files, storage blocks, tape media and

directories. This form would encrypt the entire database, rather than a separate encrypted data

layer, and it takes place at the storage subsystem (file level or block level). An advantage would

be that you could secure data without using masking or zoning. Masking involves hiding parts of

the sensitive information from unauthorized users. A good example of this involves credit card

numbers. When a receipt is printed, all the numbers except for the last four digits are replaced by

“X” in the display. A disadvantage is that it protects against a narrow range of attacks. It doesn’t

protect against the database-level and application-level attacks, which are the most common

threats. This form currently only provides block-level encryption. This means that it cannot

encrypt data in the application layer or the database at the field level.

6
Database Security: Research Project

2.2. Issues

There are four main issues we will discuss in this section: user management, encryption

key management, complete accountability, and disk space. User management involves the

authentication of users when they access the database. Some examples of identification and

authentication are: password-based authentication, host-based authentication (based off of IP

Address), public key infrastructure based authentication (PKI), 3rd party based authentication, and

a smart card. Each one of these forms could be used to ensure the identity of the person. A single

administrator has the ability to change a user’s password without their permission. With this

being the case, the database administrator can retrieve user names and password and log into the

database as another person. If the database was designed correctly, it will be keeping a log of

who accessed the database and what information they were looking at. Therefore, the database

administrator can cover their tracks. There are two design issues at this point: what data to be

encrypted before storing it in the database and a way to specify a key for encryption. These

issues will be handled by the database design team. They will need to make sure that everyone

who has access can decrypt the information and vice versa. Therefore a security catalog will

need to be in place. This catalog keeps a record of what users and what permissions they have to

access the database. An authentication policy and strict authentication will need to be in place.

Encryption Key Management involves the using of keys to retrieve and save information.

Using this technique, the protection of your database lies on how good your keys are. There are

two factors you will need to consider when talking about the security of keys: where the keys

will be stored, and who will have access to them. This has been a problem with all topics in

encryption and decryption.

7
Database Security: Research Project

Complete Accountability introduces a new position to the security of the database. There

should be two people who have administrator rights to the database: Security Administrator

(SA), and the Database Administrator (DBA). The SA would be in charge of user permissions

and the adding and deleting of users. The DBA will be in charge of maintaining the database by

performing the usual tasks. The reason a SA would be introduced is to not allow the DBA access

to user names and passwords. Only the SA would have this information. This creates the DBA

to only handle maintenance for the database. Another way to ensure complete accountability is to

make each user is in charge of secrecy of their account. This way the SA would not be able to

log into the database using another person’s account. All the SA would be in charge of would be

to reset the password if a user forgets theirs.

The last issue we will discuss will be disk space. If encrypted data is to be used, the DBA

will need to make sure all data fields can handle this encrypted data. With encryption, the field

sizes will increase which would cause the database to increase in size. Another thing to

remember is that encrypted fields will be larger than unencrypted fields; therefore you will need

to make sure there is enough logical memory space.

2.3 Storage Formats of Encrypted Information

Searching through encrypted data will become challenging. When returning a result set

back, the DBA will need to make sure all data is encrypted using the same techniques. If they are

not, then there will need to be a way for the application to know what type of decryption key to

use. This in turn would cause it to be hard to scan multiple tables at once.

Some more disadvantages deal with primary and foreign keys. If the company decides to

use encryption, then the DBA would have to remove all primary keys and recreate them after the

data has been encrypted. This would cause a lot manipulation of the database schema. The

8
Database Security: Research Project

reason for this process is the fact that all fields in the databases will be encrypted including

primary keys necessary for searching. Leaving a key as cipher text primary key will make

searching slow and difficult. Another disadvantage is the issues of foreign keys. One will need

to make sure to go through all tables that have foreign keys and update their values in all tables.

It is not recommended to encrypt columns with foreign keys because a user can easily miss

something while changing data.

2.4 Examples

Throughout the research we have performed, there were mentions of some encryption

companies and databases that automatically encrypt information for the clients. A couple of

them are RSA Security and nCipher, which are good 3rd party software vendors providing

encryption products. This will handle the key issues and some of the user management issues. A

good database that handles encryption already is Oracle. Oracle stores keys in an encrypted table

in the database. It also provides a secure key generator and the DBA cannot see encrypted data.

2.5 Steps to Encryption

Below you will find steps to handle the encryption of your database. This information is

from the article “How to Use Encryption on Database Contents”1.

1. Determine what to encrypt

2. Decide where to handle encryption and decryption

3. Protect keys

4. Implement or get access to secure key-generation system

5. Know how much disk space needed for larger fields

1
MacVittie

9
Database Security: Research Project

6. Use encryption vendor’s tool to copy unencrypted data and then encrypt it. Place data

into new field you created.2

3. Database Auditing – Vision and Detection

Database auditing is defined by the act of monitoring and recording selected database

actions. These actions are usually broken into two categories of activity: investigating

suspicious activity and gathering usage for performance reasons. Because we have a database

security scope for this paper, we will only discuss the suspicious activity tracking. Auditing

tracks database transactions from authorized users (or unauthorized users masquerading as

authorized). By bringing accountability to actions, database perpetrators can be discovered and

tracked. Specific activity can be flagged and alarms sounded. Quality audit systems use a second

database which securely stores all activity (even event actions which are “reverted” or “not-

committed”). “Triggers,” or special database events, are used to describe specific system level

actives such as starting up, shutting down, and schema changes.

2
MacVittie

10
Database Security: Research Project

It is often said that databases are “the gold” or the “crown jewels” of an organization. Many

companies don’t use auditing techniques to track database activity and when confronted with the

plethora of options quickly become overwhelmed. For this reason, a solid auditing design is

simple and to the point. Auditing provides insights on activity and protection against internal and

external threats through proactively detecting unauthorized changes or unusual activities.

Auditing not only provides a trail of activity for detecting where suspicious external threat

activity comes from, but creates accountability for authorized personnel. With auditing tools,

executives can have a clear picture of the past and present state of proprietary data.

3.1 Auditing Principles

The general practice is to turn on a broad general set of activity tracking first, and when

inappropriate actions or an attack is suspected, more specific audit functions can be turned on.

The first step for monitoring actions is to define specific actions to look for. Some examples

would be changes to the schema, deletion/modification of users, and access to a table of sensitive

data. Once these actions are created reports can be designed to check for specific.

Auditing is relatively inexpensive, but if audit events occur often then there will be a

significant impact on performance and the size of the audit trail will become large and unwieldy.

It is important to evaluate the purpose for auditing. Because recording of audit information

occurs during the execution phase of a statement execution, performance will suffer. Transaction

heavy databases can quickly get bogged down if auditing is unintelligently used throughout a

database. After you have thoroughly analyzed the needs of the organization’s database activity,

an efficient auditing strategy can be performed. Administrators can intelligently audit by storing

only the minimum number of statements, users, or objects required in database audit logs. It is

11
Database Security: Research Project

important to gather sufficient security information but balance the amount with one’s ability to

store and process the content. The more focused and concise the data, the more likely it will be

analyzed and be of use to investigators and security database administrators. A quality auditing

design includes tracking of specific types of activity and contains reports only the necessary

information important for security.

3.2 Example Reports

Below are some common report types which are created to detect unusual activity.

Though these are by no means an exhaustive list of report policies, they describe some basic

examples of suspicious behavior. In addition to the essential screening described below, the

individual and unique design of databases should give DBAs insight into further reports. For

instance, at the application level, database audit reports should be created for access to all

encrypted fields and sensitive data tables. However, because every database design is different

from the others, the quality of auditing is largely a database security manager’s responsibility.

Each of these “reports” must first use the database’s built-in auditing functionality or

third-party auditing software to record the data , and then recall the data through a SQL

expression from the audit database.

3.2.1 Failed Log-On Attempts

By showing all failed log-on attempts, investigators can find perspective attackers.

Setting a good maximum log-in fail attempt can help discern simple typos versus an

unauthorized access attempt.

3.2.2 Invalid User Log-On Attempts

12
Database Security: Research Project

Determining whether a user is trying to access a database with an invalid username can be

a very strong sign of abuse. This report will produce fewer false alarms and reduce unnecessary

administrative investigations. Both of these reports should be checked daily.

3.2.3 Attempts to Access at Unusual Hours

Attempts to access outside of office hours should be tracked. However, this activity could

just be valid overtime or maintenance work. Any system or administrator activity during these

times should always be investigated. Reporting location access is also a must in this case. For

example, privileged access made from machines that are not in the administrator department is a

clear sign of suspicious activity.

3.2.4 Potential Account Sharing

Checking for users who sign on to an account from different locations (and even more

alarming at the same time) should be investigated.

4. Open Issues

4.1 Current database scenario

A decade ago, databases were physically secure. There were central database centers,

single site deployments, and all data access was mediated. As such, only those who should access

data, could access it. Database security was not much of a problem then.

Business needs changed gradually. The customer base increased, and customer support

was the mainstay of better prospects. Distributed sites and networking of systems warranted a

distributed nature of data access, and led to multiple accesses to scattered data. As a result, these

databases are externally accessible, not only to the employees of a firm, but over the Internet to

anyone who has a computer and a connection.

13
Database Security: Research Project

A typical database deployment can thus be described as follows. There is a representative

three tier architecture, in which the first layer is of the client application. This application sends

requests to the application server, which processes them, and if they concern the database, sends

to the database for further processing.

In an intranet, the client applications reside on the individual workstations, and keep

interacting with the application server. In the case of the internet, the clients vary from the web

browser, custom front ends and other such interfaces to different servers of the same department,

or web service. In the case of a single database server that services these requests, the application

layer can be closely integrated with the database software, or can be completely eliminated,

allowing the DBMS software to handle all requests. The database software typically runs on a

port on the server, and accepts requests and responds to them on that port.

4.1.1 Problems in the current scenario:

3
Diagram by Neeraj V. Kulkarni

14
Database Security: Research Project

The prevalent database systems provide basic authentication, auditing and authorization

features. However, these features are incomplete and inflexible. They are incomplete because

they lack the necessary user interface for their extensive use. Assigning rights involves a series of

commands, statements and graph analysis, and is a complex process overall. Thus, most

administrators end up with assigning the default sets of privilege levels, which are well known

among the attackers.

The database features are inflexible because there is no safe way of assigning a database

security function to the security group of a company, without elevating their privileges. This

leads to use of third party software for this purpose.

4.2 Open security issues in database architecture

The traditional view of database security has been to view the database system as being

controlled by the operating system. Hence, the general outlook of securing databases is to secure

the underlying operating system, and the server software through which it is accessed.

However, a database system is software, and like any software, it has its own bugs and

vulnerabilities. And once these are discovered, patches need to be applied in order to seal them

from the attackers.

4.2.1 SQL Injection

The most common issue of database vulnerability is SQL injection. Typically, if there is a

webpage with forms that serves as the front end of a database system over the internet, the user

can execute SQL queries from these forms and get the results. The general belief is that only

legal queries are generated. However, if an attacker generates an unusual query, and if type

15
Database Security: Research Project

checking is not performed before it is processed, the generated results can reveal a lot about the

database schema.

This is a type of problem that basically lies with how the database returns the results. The

database either returns record sets that are the result of a valid query, or returns error messages.

More often than not, these error messages indicate some part of the subschema. As such, in order

to hide their revelation from the end user, the calling code (for example, a PHP script) needs to

convert them to a more user level message.

The main point here is that the error messages generated by the database system should be

used only for the local purposes like logging and triggers for administrators, and not for

transmission to the external users. The database system needs to take care of this.

A similar vulnerability discovered was in the IBM DB2 database on Linux. This allowed

a hacker to launch a "buffer overflow" attack by sending a long command to a file in the DB2

database, which dictated access privileges. This gave the hacker root privileges, leaving the

system at his mercy. 4

4.2.2 Database Malware

A new set of threats that has emerged are the worms and viruses that infect the databases,

rather than the traditional operating systems and the web server holes. These are not sophisticated

programs. However, the lack of seriousness of database software security has led to their wide

propagation, and opened up a new area of database security.

Example 1: Spida worm

The most famous of these is the Spida worm (also called the SQL worm, SQLSnake,

DoubleTape, Spida.A.Worm or Digispid.B.worm). The worm infects itself by inserting itself into

MS SQL database servers with a blank SA (System Administrator) password. It then sends

4
LaMonica

16
Database Security: Research Project

information regarding the system to a certain email address, and propagates itself through the

different systems that the server is connected to.

Although it is not a very harmful worm it generates a lot of network traffic leading to

denial of service attacks. The surest way to stop its propagation is to assign a SA password.

However, more future worms imitating the Spida worm can attack systematically using

dictionary entries as passwords thus increasing the success rate and even more network payload.

Example 2: Voyager Alpha Force:

Another type of worm that infected the SQL server was the Voyager Alpha Force. It

exploited blank SQL Server SA passwords, according to a security notice from Microsoft. The

worm searched for servers running SQL Server by scanning for port 1433, which is the SQL

Server default port. It then logged on with a blank (NULL) SA password. If successful, the worm

would then broadcast the address of the unprotected SQL Server database on an IRC (Internet

Relay Chat) channel. It would then try and load an executable file from a site in the Philippines.

Future database worms:

The future database worms are likely to exhibit the following features:

1) The worms would evolve into multi headed worms that would infect not only a particular

system, say SQL server but also different systems like Oracle, Sybase, and MySQL. Thus,

multiple database platforms would be targeted at once.

2) More intelligent worms would attack a range of ports rather than the default ports that the

databases operate upon. In order to implement database anonymity, the administrators

generally change the database port from the default one giving them a false sense of

security. However, these worms would be able to scan them and pinpoint these ports

increasing its target range.

4.2.3 Writing to either the database or to the operating system

17
Database Security: Research Project

Auditing software usually has multiple options for writing to databases or operating

systems. In many ways, writing to the operating system is more secure. Writing to the same

database system which may be attacked can leave the audit data open to modification and thus an

attacker can erase signs of an incident. However, because there are multiple platforms available,

writing to an OS is platform dependent and requires additional development resources and time.

A secured platform independent database is usually the easiest solution.

4.3 Problems due to database access methods

Unlike the stand alone database intended for personal use, enterprise databases have a

number of access methods. Their architecture involves:

4.3.1 Multiple entry points

Web databases have many entry points like web servers, VPN access, Application Server

access, and access to database via web portal protocols. Thus, special care needs to be taken to

secure all these points and to expose the database without any threats.

4.3.2 Weakest Link Problem

The overall system security is only as weak as the weakest link in the association. Hence

if even any one part of the database is left insecure, it allows access to the data. Ultimately, data

leads to information which is what an attacker is after. Access to that data defines the success of

the attack thus making the previous measures like secure transportation, firewalls, and

application authentication ineffective.

4.3.3 Web based database

These databases are exposed to the web, storing important data like the client

information, product information, and confidential information. For example, consider the simple

18
Database Security: Research Project

HTTP tunneling method. This makes use of the port 80, the HTTP port, to access the

applications on the other side of the firewall which are supposed to be blocked by it. Securing the

databases from such attacks is an important issue in this case.

4.4 Interesting Areas to Explore for Database Security

Even though databases have been around for a long time, database security is a new

emerging field. There is an ever increasing scope for discovering new ideas, implementing them,

and improving upon them. And since data is the core of any enterprise, this field has wide

industry support too. Here we examine some areas where the current research can start from.

4.4.1 Two phase protocol with security aspect

A two phase commit protocol for database updates involves first preparing all the

resources needed for the update and then committing the changes. Thus in the first phase, the

coordinator process inspects the resources required and gathers the commit rights for them. Once

these rights are obtained, the commit phase starts where the data is actually modified.

This is one point where the security can be integrated with the database. During the

preparation phase, the coordinator process can check the security constraints and whether the

actual changes will lead to an integrity loss in the database. This involves actually simulating the

change, observing the results, and then moving on to the commit phase if the results are in

accordance with the integrity rules. Otherwise, triggers can be generated and the update aborted.

This basically means simulating and analyzing the results before committing. Admittedly,

this is an overload for simple updates and can lead to slower performance. In order to counter

this, different degrees of security checks can be applied from minimal to a tight security, so that

only the most important updates are thoroughly checked.

19
Database Security: Research Project

4.4.2 Autonomic databases

A database is as susceptible to attacks as any other resource and hence should be given

full responsibility and authorization in order to protect itself from such attacks. This leads to the

evolution of autonomic databases that can take care of themselves, can self-heal, and can take

preventive and post-attack recovery measures in order to maintain their security.

An autonomous database thus must rely on its own closely integrated software to

implement security, and not on any third party, like the firewall, application server

authentication, or third party middleware like database encryption or audit software. The

database thus should have properties of self-healing, adjusting to the external environment,

configuring and reconfiguring in case of attacks, must be fully aware of the environment in

which it is deployed, and the different constraints in which it is forced to work.

4.4.3 Authority for Database authentication

In a general scenario, the web server or the application server authenticates a user over

the Internet and then executes the query on the database. The database thus relies on the web

server authentication for its own functioning.

However, the information that a web server possesses can be made available to the

database, or to all such other systems like file sharing servers, printing servers, and other such

services. Thus, the web server can make available the HTTP variables, the headers and the

cookies that it receives public for the domain enabling the database to more easily identify a user

and return the corresponding response.

4.4.4 Database Honeypots

Honeypots are programs that simulate network services on a computer's ports. To

attackers, honeypots are servers that appear to be vulnerable running services that the attackers

can use to break into your network. However, behind the curtains, honeypots log access attempts

20
Database Security: Research Project

to those ports—including an attacker's keystrokes. Such information can provide advance

warning about concerted attacks. Honeytokens, then, are the resources that are used to attract the

attention of the attacker. These resources can vary from a single file, to a database entry, a server

system, or a cluster.

Database honeypots can be used to profile the attackers and characterize their nature of

attacks. Databases containing phony information, credit card numbers, social security numbers,

and personal data can be stored with names indicative of their content. These can then be

deployed on the network, with intensive logging facilities thus enabling to track down the

attackers.

4.5 Current Research

4.5.1 Hippocratic databases

This research has been going on in the IBM Almaden Research Center, and the people

involved are Rakesh Agrawal, Jerry Kiernan, Ramakrishna Srikant and Yirong Xu, of the

Intelligent Information Systems Group. The research is based on the principle that future

database systems must be responsible for the privacy of data that they manage.

4.5.2 Distributed Architecture for Secure Database Services

This research has been going on in Stanford University; some f the people involved being

G. Aggarwal, Y. Xu, and M. Bawa. The aim of this project is to formulate a distributed

architecture for the databases, which can help maintain privacy in a way that one server does not

know the contents of the other server, and the relation between the two (or more) parts of the data

can be used to reconstruct the original data, or to check its integrity.

4.5.3 Security Modeling and Query Processing in Heterogeneous Databases

21
Database Security: Research Project

This is a project being carried out under the Database Research Group at the College of

Computing at Georgia Tech. The project defines a common representation of security models at

various levels like the ER level and the formal level. Also, methods for indexing the database

and query processing are being investigated.

4.5.4 Improving Performance of Database Encryption

An open issue with encryption technology with databases is the unnecessary degradation

of performance. Current encryption techniques don’t maintain indices used in database b-trees

therefore an entire table must be searched in time O(n) rather than a more efficient search O

(logn). Agrawal, Kiernan, Srikant, and Xu present an encryption technique called OPES (Order

Preserving Encryption Scheme) which allows comparison operations to be directly applied on

encryption data (without first decrypting). This approach produces no false positives and no

dropped rows. OPES also “updates gracefully” by allowing columns to be inserted or modified

“without changing the encryption of other values.”5 Best of all this encryption system can be

integrated with an existing database system while maintaining total transparency to other

applications. The group also confirms, from their research (appendix), “that the time and space

overhead of OPES are reasonable for it to be deployed in real systems.”6 The extra overhead will

be offset enough by the time saved with searches using the OPES.

4.6 Database Security Legislation

4.6.1 HIPAA – Health Insurance Portability and Accountability Act (1996)

5
Agrawal, Kiernan, Srikant, Xu
6
Agrawal, Kiernan, Srikant, Xu

22
Database Security: Research Project

The Health Insurance Portability and Accountability Act of 1996 was created to improve the

portability and continuity of health insurance coverage in the group and individual markets, to

combat waste, fraud, and abuse, and to simplify administrative services (Kramer). This act

governs privacy, security, and transactions and has profoundly affected the database market.

There are two main rules to this legislation: Privacy and Security. The privacy rule concerns the

patient’s rights to control access to personal information. Security is more concerned with the

database, application, and network technologies which embody the new electronic system

required by the legislation.

The legislation has been implemented in phases since 1997 and was finalized in April 14,

2001. Though the final deadline has been extended several times, the majority of healthcare

institutions should be compliant by 2005. Under this new law, patients have significant rights to

control and understand who accesses their personal information. Institutions in the healthcare

industry are required to provide proof compliance with HIPAA. HIPAA only states what must be

done to comply and not how. For this reason, database consulting companies have turned out a

multitude of database security products to meet the health care industries needs.

With new regulations protecting privacy across the board, strict auditing of information is

in some cases no longer a choice but a requirement. For instance, databases containing sensitive

health information must now be specifically audited according to HIPAA. Additionally, access

control/security policies must be designed to maintain data integrity and allow control to all

databases. Data integrity is also a requirement. This legislation has affected all aspects of

database security and created spurred market growth for efficient database encryption, better

access control systems, and intelligent auditing to protect consumer privacy.

HIPAA Requirement Deadline Timeline

23
Database Security: Research Project

Oct. 16, 2002 Original deadline for the electronic transaction and code set rule. Congress then passed a one-
year reprieve.

April 14, 2003 Deadline for the privacy rule.

Oct. 16, 2003

Revised electronic transaction and code set rule deadline resulting from ASCA. The
government then implemented a contingency plan allowing physicians to still get paid for
noncompliant Medicare claims.

July 1, 2004
Upcoming electronic transaction rule deadline that must be met to prevent a two-week delay in
Medicare payment.

April 21, 2005 Deadline for the health information security rule.

4.6.1 Gramm-Leach-Bliley Act (GLBA)

This act was passed in November 1999, requiring federal banking agencies, the National

Credit Union Administration, the Securities and Exchange Commission, and the Federal Trade

Commission to establish appropriate standards for safeguards of the customer records and

information that they maintain. The purpose of the GLBA is to insure security and confidentiality

of customer data, protection against threats and unauthorized access. the institutions that fall

under the purview of the act are the banks, the mortgage brokers, mortgage lenders, credit

unions, insurance companies, real estate agents, appraisers, thrifts, securities firms, financial

planners and credit card companies.

4.6.2 California’s Database Security Breach Notification Act (Senate Bill 1386)

This act came into effect in July 2003, with an immediate impact on all organizations

doing business with California residents, irrespective of the business’ location. This law mainly

24
Database Security: Research Project

involves all the businesses that have had security breaches to notify the affected public, in order

to protect them from identity theft. It recommends encryption of data and special measures to see

that it remains unbroken for this purpose.

5 Conclusion
We discussed some broad topics in database security. Our exploration of encryption and

auditing explored pros and cons of implementing security policies on data. We described current

open issues and problems that must be solved in the future. We explained how Honeypot

databases could be used to determine threats and use our findings to protect production

environments. We also discussed current research including Hippocratic databases, secure

distributed architectures, and security modeling and their importance to the future to the database

security field. However, we should not limit the reader to only these topics because there are

many other important topics in the broad topic of database security. Also important is access

control which authorizes and restricts individuals to specific data domains often in a complex

corporate environment. Database security alone can’t protect the information, but must be used in

conjunction with other layers of security including network security and application security.

Even while government legislation and increased awareness of risks posed to companies have

improved certain industries such as healthcare, many databases applications are still vulnerable to

Malware and SQL Injection. Combining database security with application security is the only

solution to these problems.

25
Database Security: Research Project

6 Appendix
Improving Database Encryption

Source: Agrawal, Kiernan,Srikant, Xu [1]

26
Database Security: Research Project

7. Works Cited

1. Agrawal, Kiernan, Srikant, and Xu. “Order Preserving Encryption for Numeric Data”. ACM
Press. New York. 2004.

2. Finkelstein, Joel B. American Medical News. “Two-week payment penalty threatens as

HIPAA claims deadline looms.” May 17, 2004. Amednews.com
<http://aspe.hhs.gov/admnsimp/pl104191.htm>.

3. Kramer, Mike. HIPAA: Requirements, Measures, and Recommended Solutions. E-Security

Inc. <http://www.dlt.com/security/pdf/WP-ese-HIPAArequirements.pdf>.

4. Mattsson, Ulf T. “A Database Encryption Solution That Is Protecting Against External And
Internal Threats, And Meeting Regulatory Requirements.” ITSecurity.com. 8 Jul. 2004.
ITSecurity.com. 15 Oct. 2004. <http://www.itsecurity.com/papers/protegrity3.htm>.

5. MacVittie, Don. “How to Use Encryption on Database Contents.” Security Pipeline. 5 Dec.
2003. SecurityPipeline.com. 15 Oct. 2004.
<http://www.securitypipeline.com/showArticle.jhtml?articleId=16600160>.

6. Navathe, Sham. “Database Research Group.” Georgia Institute of Technology. 28 Oct. 2004.
http://www.cc.gatech.edu/computing/Database/faculty/sham/2_DB_flyer.html

7. Newman, Aaron. “Protecting Databases”. Application Security Inc. 2003. AppSecInc.com.

30 Oct. 2004.<http://www.appsecinc.com/presentations/ProtectingDatabases.pdf>.

8. Rahmel, Dan. “Database Security.” Internet Systems. Apr. 1997. Dbmsmag.com. 30 Oct.
2004. <http://www.dbmsmag.com/9704i03.html>.

9. Still, Jared. “Encryption in Oracle Databases”. Cybcon.com. 15 Oct. 2004.

<http://www.cybcon.com/~jkstill/util/encryption/data_obfuscation_and_encryption.html>.

10. LaMonica, Martin. “IBM posts fix for DB2 Linux security flaw”. CNet. 17 Sep. 2003.
news.com. 3 Nov. 2004. <http://news.com.com/2100-1002_3-5078155.html>.

27