CSC 5301 - Paper - DB & DW Security

7/29/2019 CSC 5301 - Paper - DB & DW Security

1/17

School of Science And Engineering

CSC 5301 Advanced Database Systems and Data Warehousing

Fall 2012

Mohamed Ennahdi El Idrissi

Database & Data warehouse Security

Due Date: 25th

November 2012

Supervised by: Dr. Assem
http://www.aui.ma/en/sse.htmlhttp://www.aui.ma/en/sse.htmlhttp://www.aui.ma/en/shss/course-descriptions-graduate/csc.html#5301http://www.aui.ma/en/shss/course-descriptions-graduate/csc.html#5301http://www.aui.ma/http://www.aui.ma/en/shss/course-descriptions-graduate/csc.html#5301http://www.aui.ma/en/sse.html


2/17

Fall 2012's Paper Database & Data warehouse Security

2

Table of ContentsI. Introduction ..................................................................................................................................... 3

II. Software Security Engineering ........................................................................................................ 3

III. Database Security Management ................................................................................................. 4

a. Access Control (SQL's DCL) .............................................................................................................. 5

i. Mandatory Access Control (MAC) ................................................................................................... 5

ii. Discretionary Access Control (DAC): ............................................................................................... 6

iii. Role-Based Access Control (RBAC) .................................................................................................. 6

b. Encryption ....................................................................................................................................... 6

c. Database Auditing ........................................................................................................................... 7

a. Database Vulnerabilities .................................................................................................................. 7

i. SQL Injections .................................................................................................................................. 7

ii. Denial of Service .............................................................................................................................. 8

iii. Default, blank, and weak username & password ............................................................................ 9

iv. Privilege Escalation .......................................................................................................................... 9

v. Improper access controls and misconfigurations ........................................................................... 9

vi. Database Inference ......................................................................................................................... 9

IV. Data warehouse Security........................................................................................................... 10

a. Access Control ............................................................................................................................... 10b. Metadata Based Security .............................................................................................................. 10

c. Data Warehouse Striping Technique ............................................................................................. 13

V. Conclusion ..................................................................................................................................... 15

VI. References ................................................................................................................................. 17


3/17


3

I. IntroductionLiterally speaking, the Latin word Secure described by Landwehr (2001) can undergo an anatomy as

the following: se means "without", and "cure" means "to care for", or "to be concerned about" [1].

The premise of this statement refers to the fact that we should enterprise actions to void reasons

behind annoyances (purchase a strongbox where to store valuable belongings ...), or, simply, attain

an acceptable peace of mind level.

In information technology, however, security is an independent field by itself. It is a set of activities

and measures undertaken with the aim of ensuring three characteristics: Confidentiality, Integrity

and Availability [2.1]. Specifically in Software Engineering, security refers to an essential system

attribute of any dependable software, and a dependable software is usually the most crucial system

property in a computer system [3]. Thus, security in this context, is the ability of the system to

protect itself against accidental or deliberate intrusion [4].

Databases, indeed, are managed by a collection of programs [2.2], namely Database Management

Systems, which eventually include modules in charge of securing the computer structure that stores

a set of end-user data as well as its respective meta-data [2.2]. Therefore, such systems are forcibly

equipped with mechanisms preliminarily designed to improve data security.

When databases have become popular, and part of the mundane operational activity, the urge of

conceiving a new kind of data repository and data management (OLAP) emerged: relieving the

operational databases, and building strategic decision making based on historical data: the data

warehouse is born. A data warehouse is supposed to be an open accessible system, and any security

aspect is to compromise its design, and consequently affect unsuitably its purpose.

II. Software Security Engineering [4.2]First, no one can attack a software system when it is isolated from any network, and, second, a

software system cannot be abused when it is exploited by a unique user. Since the widespread use of

the internet in the 1990s, new types of threats and/or vulnerabilities had to be taken emphasized.

When considering security issues, the infrastructure along with the software (application) itself have

to be studied. As a result, security may be compromised at any layer shown in figure 1:


4/17


4

Application

Reusable Components and Libraries In

frastructure

MiddlewareDatabase Management

Generic, Shared Applications

(Browsers, E-mail, Etc.)

Operating System

Figure II.1: Application & Infrastructure Layers (Sommerville)

There is an important distinction between application security and infrastructure security. The

former is a design issue, regarded as ensuring the system to be able to resist attacks, while the latter

is of management nature and orbits around the configuration of the system for the same goal

(resisting attacks). Accordingly, due to their perpetual availability, infrastructure components (such

as database servers) can be probed by attackers for weaknesses, to eventually gain unauthorized

access to the system and its data.

The discipline ofsystem security management, that is responsible of securing infrastructurecomponents, is characterized by the following three activities:

1. User permission management (privileges)2. System deployment & maintenance (vulnerability avoidance, security repair patches)3. Attack monitoring, detection and recovery (detecting suspicious behavior, backup)

Let's put forth the aforementioned activities in a more practical context: database securitymanagement.

III. Database Security ManagementWe have seen during the previous section that database management is part of the infrastructure of

a given system; another affirmation ascertains that "Databases and database management systems

provide the infrastructure on which other organizational information systems are built" [6].

Therefore, securing a database requires configuration (management) of its DBMS to fulfill the aim ofowning a safe database environment.


5/17


5

As a matter of fact, the traditional focus of database security was to strive to insure that only

authenticated users perform authorized activities at authorized times (privileges). Paradoxically, such

a measure alone proved to be inadequate or insufficient, because of the raising the number of

database encroaching [7].

We know that the risk of thread increases when the system accepts several users, but this asset isn't

the only source of weakness for the system. That's why, to identify potential risks within a system,

the following table summarizes database security essentials [2.3]:

Data Protected Reconstructable Auditable

Users Identifiable Authorized Monitored

A matching between database security essentials and the database security characteristics can be

depicted as the following:

Confidentiality Integrity Availability

Data Protected Reconstructable Auditable

User Identifiable, Monitored Authorized

To reach the above mentioned attributes, we should consider the security methods pertaining to the

field of security:

Access Control Database Inference Encryption Database Auditing Database Vulnerabilities

a.Access Control (SQL's DCL)i. Mandatory Access Control (MAC)

Mandatory Access Control is the strictest access control [9], and users (or user

groups) and data are classified based on Security Classes [8.2]. MAC rules are system

applied and considered static and more secure [7.3].

It is a multilevel security access control which considers columns and rows as dataobjects and eventually classifies them. It is a measure entitledpolicyor label. Typical

object security classes are [8.3]:

Top Secret >= Secret >= Confidential >= Unclassified

Highest Level Lowest

A matching between a user's credentials and an object's label yields access grant [9].

Pitfall: a lot of planning ahead of MAC implementation, and high system

management overhead when new data and new users added.


6/17


6

ii. DiscretionaryAccess Control (DAC):Discretionary Access Control is the main security mechanism for Relational Databases

[8.3]. Its purpose is to grant/revoke users (or user groups) privileges [8.2], and It is

considered dynamic and content focused [7.3].

DAC owns two levels of privileges [8.3]:

Account Level:Acts on the database and system privileges (independent from database

content).

e.g.: GRANT alter TO Alice

Relation (Table) Level:Acts on the content of the database content.

e.g.: GRANT select ON Deposit TO Ibrahim,

GRANT delete, update (Cname, City) ON Customer TO Ali;

The pattern is as follow:

GRANT privilege_name ON object_name TO level_name;

Pitfall: dispersed access control policy (users choose privileges), which potentially

compromises the global policies consistency [9].

iii. Role-Based Access Control (RBAC)Role-Based Access Control emerged in the 1990s as an efficient technology for

managing large-scale enterprisewide systems [8.5], and they are especially effective

for database systems [7.3]. In fact, it is the most widely used control mechanism [9].

It is, indeed, a viable alternative to traditional DAC & MAC. Privileges are provided to

users based on their tasks/role performed on the database [9].

Pitfall: No user, according to their role, can't change permissions provided to them.

b. Encryption [16]Encryption can provide strong security for data at rest, but developing a database

encryption strategy must take many factors into consideration the encryption level:

storage layer:advantage: transparent, no changes needed at the level of the DB level

drawback: insensitive to user privileges

database:advantage: data are totally secured, encryption is part of the DB design.

user privileges may be taken into account.

drawback: major DBMS performances degradation (indexes become useless)

application where the data has been produced:advantage: separated keys from encrypted stored data (DB)

drawback: application (DB client) has to be modified.

performance overhead


7/17


7

Figure III.d.1 illustrates the three encryption levels:

Figure III.d.1:the storage level, database level and application level encryption (Bouganim, Guo)

c. Database AuditingAuditing the changes to a database is critical for identifying malicious behavior,

maintaining data quality, and improving system performance. But an accurate audit log is

a historical record of the past that can also pose a serious threat to privacy [3].

Indeed, database auditing (also called Data Access Auditing, Data Monitoring, Data

Activity Monitoring (DAM)) is the examination of audit or transaction logs for the

purpose of tracking changes with data or database structure [12]. It is utilized to identify

who accessed the database objects, what actions were performed, and what data was

changed. It doesn't prevent security breaches, but allows identifying breaches after they

take place [7.6].

There exists two types of Database Auditing:

The first technique: trace-based auditing, which is usually built directly into thenative DBMS. Nonetheless, its overhead is expensive when audit tracing is enabled.

The second technique: scanning and parsing the database transaction logs (AllDBMSs support them for recovery purposes).

Drawbacks Serious threat to confidentiality.

Doesn't prevent security breaches.

a. Database VulnerabilitiesDatabase vulnerabilities have been part of the field of security, and being aware of them

is as important as being aware of the previous covered techniques.

i. SQL InjectionsSQL injections are the most renowned database security issues, and they susceptible

to occur when SQL statements are dynamically created [7.4]. The main reason why

injections happen, is due to SQL syntax, basically the double contiguous dashes "--"


8/17


8

which cause an ignorance of what comes after them . A deliberate attempt is to do

the following:

SELECT CUS_CODE, CUS_LNAME, CUS_FNAME

FROM CUSTOMER

WHERE CUS_CODE = I.CUS_CODEAND CUS_LOGIN =

AND CUS_PASSWORD = ;

A user with good intensions would enter the value he is supposed to:


FROM CUSTOMER

WHERE CUS_LOGIN = 'Mohamed'

AND CUS_PASSWORD = 'Morocco';Nothing would prevent a malicious user to provide a value that is subject to corrupt

the confidentiality of the data:

The value provided by this malicious user could be:

= ' OR 1 = 1 --

The request therefore becomes:


FROM CUSTOMER

WHERE CUS_LOGIN = '' OR 1 = 1 --'

ANDCUS_PASSWORD

='';

This request returns TRUE, since the injected 'OR' breaks the control on the field and

the double contiguous dashes allow to ignore the rest of the code that is beyond the,

and unfortunately the malicious user would easily get an unauthorized access.

Using stored procedures or stringifying the parameters of the query are enough to

overcome this weakness.

ii. Denial of ServiceDoS is an attempt to make a computer resource unavailable to its intended users[10]. DoS attacks are centered around the concept that by overloading a targets

resources, the system will ultimately crash [11]. DoS is generally used with regards

to computer networks, but is not limited to this field.

Databases can undergo database connection submerging by crafting CPU-intensive

SQL queries [10].

The solution is to control the traffic between clients and the database server.


9/17


9

iii. Default, blank, and weak username & password [15]Database vendors deliver their products with defaults passwords for renowned user

names. Leaving the defaults in place is analogous to leaving the barn door wide open,

since defaults account are well known for IT professionals, and especially hackers

(Oracle's Scott/Tiger), without neglecting the fact that a plethora of informationabout default accounts for specific DBMS products are available online. Easily

guessed passwords represent a vulnerability to the database as well: not all DBMS

have an account lockout mechanisms that detects the number of failed logins to stall

the malicious attempts. Hence, applying a brute force algorithm would easily grant

unlawful access to an immoral user.

iv. Privilege Escalation [15]A user who is not skillful enough to handle the SQL's DDL, or s/he is not trustworthy

enough to wander around specific data. Access controls such DAC are characterized

with this kind of weaknesses, that may ultimately cause serious problems and requirethe database to be rebuilt.

v. Improper access controls and misconfigurations [15]Multi-user management is a cumbersome task in distributed systems. Failing to

attribute the right privileges for a specific user endangers the confidentiality and

integrity of the database. Misconfigured databases, irregular maintenance, and

process breakdowns are a huge security risk to any organization that unavoidably

harms its business. The occurrence of those defectiveness are as we may describe it

as a "good opportunity" for intruders looks for holes to exploit.Accordingly, remediation statements into a SQL script file, the organizations can

quickly resolve database security issues. This significantly reduces the cost and

research required to comprehend a vulnerability or misconfiguration, and the need

to author the appropriate fixes.

vi. Database Inference[7.5]Database Inference vulnerability is the ability to infer unknown information from

retrieved information, and, for the time being, there's no incisive solutions to the

problem. Inference happens when the actual intent for users to generate or view

aggregate values when they have not been given access to individual data items.

Let's consider the example of salaries within a company: a salary by definition is a

confidential information, but a worker who has access to the database shouldn't be able

to reach this information (RBAC). Meanwhile, the company's financial analyst may have

to handle salaries in an aggregated way. S/he may easily guess salaries of each

employee, although he is not supposed to, via applying the regular equations in an

intuitive manner, and may infer everyone's salary.


10/17


10

IV. Data warehouse SecurityThe aforementioned database security requirements apply symbiotically to a data warehouse as

well: The environment must prevent unauthorized users from accessing or modifying data, nor

the data should be stolen by violators, the data must be available to the right users at the right

time, and the system must keep a record of activities performed by its users. Perhaps, those

security requirements are more crucial in a data warehouse due to the fact that, by definition, a

data warehouse contains data collected from multiple sources, and thus from the perspective of

a malicious individual trying to steal information a data warehouse can be one of the most

lucrative and fateful targets in an enterprise [17]. For the Data warehouse, we are going to

discuss three security models: Access Control in a Data Warehouse, Metadata Based

Security, and the Data Warehouse Striping Technique.

a.Access ControlBoth databases and data warehouses are repositories of data, but they differ in term of

design, and consequently the aim: Databases store data uniquely for transactional

operations, whereas data warehouses afford redundancy for analytical activities.

Albeit both databases and data warehouses are different, the underlying data structure

doesn't necessarily differ. Furthermore, what we call a Table in OLTP is called a Dimension (or

Fact Table) in OLAP: Both are SQL tables being managed by a DBMS.

Access Control concept, which was examined in the Database Security section, is valid in a

Data Warehouse context.

b. Metadata Based Security [12]Metadata are an important part of the data warehouse, it contains all the information

related to structural as well as access related aspects of the data warehouse. It is stored as a

normal data in files known as metadata repositories [9].

Without metadata, it'd be a demoralizing task when attempting to locate a file (imagine you

are to try to find somebody's phone number without a telephone directory). They might

describe each fact contained within the warehouse in terms of when it was last updated, the

source of the fact and how it is derived from an organization's operational systems.

In the meantime, we know that a data warehouse can be constituted of a number of

databases that have common elements but serve different functions. In this case, metadata's

role is redefined: providing data about distributed information resources, and, consequently,

relieve users from the complex accessing of distributed information resources. Failing to

implement the aforementioned, users are potentially going to be confronted with precisely

the problems that were intended to be resolved by the data warehouse in the first place.

Actually, metadata influence all levels of a data warehouse, but exist and act as the rest of

the warehouse data. Developers metadata are used for management & control (Structural

metadata) reasons, that's why they are kept outside (metadata repository) of the data

warehouse itself. Users metadata (Access metadata) of the data warehouse, nevertheless,

are part of the data warehouse itself.


11/17


11

Structural metadata: describe the structure and the content of the data warehouse. Access metadata: dynamic relationship between end-user applications and the data

warehouse. They describe facts of the enterprise, user-defined names and aliases,

the data warehouse server, data marts (databases), and tables.

That being said, metadata can describe security mechanisms in a data warehouse

environment. Indeed, security rules are stored as metadata. A security model prototype,

based on metadata, was developed within the framework entitled WWW-EIS-DWH project:

When a user accesses data of the data warehouse, the Secure Query Management Layer

(SQML) verifies their credentials through the corresponding access authorizations by

analyzing security metadata (Access metadata).

Figure IV.b.1 depicts what a data warehouse meta data security file looks like. Such a file may

thoroughly describe a data warehouse. Indeed, this solution allows different user groups of

the same data warehouse to be flexibly able to see different data of the data warehouse:

Figure IV.b.1Sample Example of The structure of Metadata Files

(Katic, Quirchmayr, Schiefer, Stolba, Tjoa)

In Figure IV.b.2 protrays the structure of the discussed prototype. It is composed of three

layers:

Extraction Layer: ETL R-OLAP Layer:

description of the DW content (post ETL) physical database -> data warehouse

Presentation Layer: access rights decoding encoded queries encoding query results that are not cached registration, definition, and administration of users and user groups


12/17


12

Figure IV.b.2 Structure of the WWW-EIS-DWH project


The previous layers of the WWW-EIS-DWH project can be represented using the so called

M-Viewstructure (see Figure IV.b.3).

The main components of an M-View model are:

The Security ManagerPermits to view user groups administrations, definition, description - Which data are

authorized to be accessed, by which user groups.

Users, of the same group, view the same dimensions, facts, and attributes of

the data warehouse.

Access restrictions of a user group are stored in the form of an MQLstatement.

Figure IV.b.3: The M-View Structure



13/17


13

The Security Query Management Layer (SQML):(1) SQML runs on an information server component. (2) It affects metadata layer to

the information server component. (3) Syntactic analysis of the received queries. (4)

assigns query to predefined user groups after evaluating them based on their

login/password.

Group Evaluation

User query submitted in the domain within

the scope of allowed data area?

(inspection phase)

+

Access Restriction Assignment

(5) Access rules, that are user group dependent metadata, and filtered metadata, will

be assigned on the fly (MQL). (6) MQL describes structurally the fact tables,

dimensions, aggregation, and attributes of a specific user. (7) WWW-EIS-DWH's M-

View takes advantage of the star scheme to represent the data.

Mentioning the different stages a user query undergoes obliges us to describe its outcome.

Essentially, OLAP engine takes care of the query rendering:

For the user to consume the result of the query s/he submitted, query passesthrough OLAP Engine, and the latter analyses the user's domain (reduced view), and sends

the result to the client's browser; the result may be cached while the result is transiting to

the client, so that OLAP calculations would rather be immediately returned than to be

recalculated every now and then.

c. Data Warehouse Striping Technique [13]Data warehouses are repositories that usually contain high volumes of data integrated from

several different operational sources. In order to properly handle high volumes of data,

allowing performing complex data manipulation operations, enterprises normally use high

performance systems to host the DW. The most common choice is systems that offer

massive parallel processing capabilities, as Massive Parallel Processing (MPP1) systems or

Symmetric MultiProcessing (SMP1) systems. Due to the high price of this type of systems,

some less expensive alternatives have already been proposed and implemented. One of

these alternatives is the Data Warehouse Stripping (DWS) technique.

In a simplified view, the DWS technique consists in the distribution of the data of a data

warehouse over a cluster of low-cost computers, providing near linear speedup and scale up

when adding new nodes to the cluster.

To achieve low-cost, the data warehouse cluster is based on open-source software and the

computers can be shared with other applications (whose typically do not exploit all

computational resources of the machines). However, open-source software (and Database

Management Systems (DBMS) in particular) normally does not provide the full security

capabilities needed to protect critical business data. Furthermore, sharing the computers

with other applications increases the risk of security attacks as several users can have

administrative access to the machines.

1: For more details about SMP and MPP, refer to William Stalling's Computer Archit ecture & Organization 8th

edition, Chapter 17th


14/17


14

One of the main problems faced by system administrators is the protection of the data

against unauthorized access or corruption due to malicious actions. Hence, the three

characteristics of security emerge again here as the following:

Data confidentiality is achieved by encrypting the dimensions data. Facts data are not

encrypted due to performance issues (encryption in large tables is a heavy process thattypically ruins the system performance). Nevertheless, to improve confidentiality, facts data

are obfuscated by adding spuriousrecords to the fact tables in order to mislead the attacker.

Data integrity are guaranteed by using signatures in all records in the data warehouse and

concurrent detection of malicious data modifications.

Finally, data availability is achieved using replication.

Each star schema of the same DW is distributed over an arbitrary number of nodes having

the same star schema. Data of each dimension table are replicated in each node of a given

cluster, except that the data of fact tables are distributed over the fact tables of the several

nodes using strict row-by-row ROUND-ROBIN partitioning or hashing partitioning.

It is not problematic to replicate dimension tables since the they occupy between 1% to 5%

of the total space occupied by the DW repository. As a result, it is possible to execute OLAP

queries on a DWS cluster parallelly by all the available nodes, and results are merged by a

DWS middleware.

Figure IV.c.1: Data Warehouse Striping Approach

(Vieira, Vieira, Madeira)


15/17


15

Data Integrity with DWS:

Signatures can be used to guarantee data integrity in all records of a data warehouse. Each

record in each table must have an associated signature that allows DWS, through it

middleware, to distinguish original data from tampered data (spurious data).

Considering a Record-Based signature might need to read all columns from a record with the

aim of yielding a signature might impact negatively the general performances of the data

warehouse. Additionally, this solution poses space storage predicaments that also affect

performances.

Data Confidentiality with DWS:

Encryption for data storage is a heavy process that is subject to ruin queries response time.

That's why, through experience, data encryption should be applied only to small size tables:

encrypting dimension tables merely, but facts data cannot be encrypted. Besides, we know

that in DWS, fact tables are distributed as previously state, and their associated dimension

tables are encrypted, trespassers who get admittance to one or more nodes would only

access to portions of data that are normally meaningless. Notwithstanding, risk potentiality is

still present, but confidentiality may be improved: obfuscating facts data by appending

spurious records to fact tables in order to mislead malicious users (data signature is useful

here).

Data Availability with DWS:

According to their conceiver, a DWS cluster isn't necessarily based on expensive nodes. Yet,the more inexpensive nodes, the higher the risk of node failure. DWS includes a redundancy

mechanism baptized Redundant Array of Inexpensive Nodes. It tolerates failures of cluster

nodes. It exists in two versions (RAIN-0) and (RAIN-S). The former consists of replicating facts

data from each node to other nodes of the cluster, and the latter (Striped Redundancy) is

built on the top of the former, and where facts data are randomly distributed in N-1 sub-

partitions (where N is the number of nodes), and each sub-partition is replicated in at least

one of the other nodes.

Detecting wicked behavior through data signature, must automatically disable nodes, and

RAIN mechanism interposes to redirect queries to the available replicas.

V. ConclusionDatabase and Data warehouse security is an import discipline that has been more and more evolving,

knowing that vulnerabilities and threats or even risks can never be thoroughly covered. But patches

and corrections, in addition to the communication between DBA about securities issues is a major

asset toward database and data warehouse security.

Confidentiality, Integrity and Availability are the three characteristics that striven to be reached once

a repository is built to service a purpose.


16/17


16

We have seen how database security is a stable and old discipline that is widely covered, while the

security of data warehouses is a recent field still under research and testing, but data warehouse

security for sure is built on top of the sturdy results obtained from database security.

However, to secure a data warehouse, there exists several models and techniques. We have covered

the Metadata Based Model and the DW Striping Technique. The former takes advantage of accessmetadata to reduce the view of the data, so that any security measure wouldn't impact the

navigation of the data contained in the data warehouse, while the latter is based signatures to

ensure integrity, encryption to ensure confidentiality, and replication to ensure availability.


17/17


17

VI. References[1] Weippl E. (2010), Security in Data Warehouses;

[2] Coronel C., Morris S., & Rob P. (2011), Database Principles - Fundamentals of Design,

Implementation and Management, 9th edition

[2.1] page 609;[2.2] page 7;

[2.3] page 611;

[3] Maxim B., Software Dependability, Lecture 9, CIS 376 - Fall 2008, University of Michigan-Dearborn;

[4] Sommerville I. (2011), Software Engineering, 9th edition

[4.1] Page 293;

[4.2] Page 368-9;

[5] Gupta S.L., Sonali M., & Palak M. (2012), Data Warehouse Vulnerability and Security;

[6] Courtney J., Paradice D., Brewer K., Graham J. (2002), Database Systems for Management,

3rd edition, page 7;

[7] Murray M., Database Security: What students need to know, Volume 9, 2010;

[7.1] page IIP-62;

[7.2] page IIP-63;

[7.3] page IIP-64;

[7.4] page IIP-68;

[7.5] page IIP-71;

[7.6] page IIP-73;

[8] Elmasry R., Navathe S. (2004), Fundamentals of Database Systems 4th

edition

[8.1] page 735;

[8.3] page 736;

[8.3] page 740;

[8.4] page 741;[8.4] page 744;

[9] Gupta S., Mathur S., Modi P. (2012), Data Warehouse Vulnerability and Security;

[10] Tawfik M., "Denial-of-service attack",

http://securedb.blogspot.com/2010/07/denial-of-service-attack.html;

[11] AppliCure Techonologies, "Prevent Denial of Service (DoS) Attacks",

http://www.applicure.com/solutions/prevent-denial-of-service-attacks;

[12] Katic N., Quirchmayr G., Schiefer J., Stolba M., Tjoa M. (1998), A Prototype Model for Data

Warehouse Security Based on Metadata;

[13] Vieira M., Vieira J., Madeira H. (2008), Towards Data Security in Affordable Data

Warehouses;

[14] Raut S. (2011), A Literature Surve on Data Warehouse Security Aspects;[15] APPLICATION SECURITY (APPSECINC), INC. (2009), "Addressing The Top 5 Database

Vulnerabilities Plaguing Federal Agencies";

[16] Bouganim L., Guo Y. (2011), Database Encryption;

[17] Oracle (2005), "Security and the Data Warehouse" [White Paper].
http://securedb.blogspot.com/2010/07/denial-of-service-attack.htmlhttp://securedb.blogspot.com/2010/07/denial-of-service-attack.htmlhttp://www.applicure.com/solutions/prevent-denial-of-service-attackshttp://www.applicure.com/solutions/prevent-denial-of-service-attackshttp://www.applicure.com/solutions/prevent-denial-of-service-attackshttp://securedb.blogspot.com/2010/07/denial-of-service-attack.html

Documents

CSC 5301 - Paper - DB & DW Security