Database Security

Introduction to Database Security

Issues
Types of Security
Legal and ethical issues:
the right to access certain information. Some information may be deemed to be private
and cannot be accessed legally by unauthorized persons

Policy issues
as to what kinds of information should not be made publicly
available-for example, credit ratings and personal medical
records

System-related issues
whether a security function should be handled at the physical
hardware level, the operating system level, or the DBMS level

The need to identify multiple security levels

identify multiple security levels and to categorize the data and
users based on these classifications-for example, top secret,
secret, confidential, and unclassified.

Threats to Databases

Loss of integrity
Improper modification of information.
Modification creation, insertion, modification, changing
the status of data, and deletion. by either intentional or
accidental acts.
If not corrected may contaminate system corrupt data
inaccuracy
Loss of availability
Objects unavailable to user with legitimate right.
Loss of confidentiality
unauthorized disclosure of confidential information
intentional, unanticipated, or unintentional could result
in loss of public confidence, embarrassment, or legal action

Countermeasures
To protect databases against these types
of threats four kinds of countermeasures
can be implemented:

Access control
Inference control
Flow control
Encryption

Countermeasures: Access Control

Security mechanism of a DBMS must include provisions
for restricting access to the database as a whole
Handled by creating user accounts and passwords to control
login process by the DBMS.

In a multiuser database system DBMS must ensure

that certain users or user groups to access selected
portions of a database without gaining access to the
rest of the database.
DBMS typically includes a database security and
authorization subsystem that is responsible for
ensuring the security portions of a database against
unauthorized access.

... Access Control

... Access Control

Discretionary security mechanisms:
Used to grant privileges to users access specific data
files, records, or fields in a specified mode (such as read,
insert, delete, or update).

Mandatory security mechanisms:

Used to enforce multilevel security by classifying the
data and users into various security classes (or levels)
then implementing the appropriate security policy.
For example User at Level 1 can see data in level 1 and
lower (level 0), but not higher (Level 2) An extension of
this is role-based security
Typical security classes are top secret (TS), secret (S),
confidential (C), and unclassified (U), where TS is the
highest level and U the lowest: TS S C U

Countermeasures: Inference
control
The security problem associated with databases is
that of controlling the access to a statistical
database, which is used to provide statistical
information or summaries of values based on various
criteria.
Must allow access to certain information needed but not all

and not detailed information on specific individuals.

Must not allow information to be inferred or deduced from
statistical query

The countermeasures to statistical database security

problem is called inference control measures.

Inference Control
The process of performing queries and deducing
unauthorized information from the legitimate
responses received

Example: Inference

Countermeasures: Perturbation

Example: Perturbation

14

Countermeasures: Flow control

Another security is that of flow control, which
prevents information from flowing in such a way
that it reaches unauthorized users.
Channels that are pathways for information to
flow implicitly in ways that violate the security
policy of an organization are called covert
channels.
A flow policy specifies the channels along which
information is allowed to move.

15

Countermeasures: Encryption
A final security issue is data encryption,
which is used to protect sensitive data
(such as credit card numbers) that is being
transmitted via some type communication
network.
The data is encoded using some
encoding algorithm.
An unauthorized user who access encoded
data will have difficulty deciphering it, but
authorized users are given decoding or
decrypting algorithms (or keys) to decipher
data.
16

Database Administrator (DBA )

The database administrator (DBA) is the
central authority for managing a database
system.
The DBAs responsibilities include
granting privileges to users who need to use the
system
classifying users and data in accordance with the
policy of the organization

The DBA is responsible for the overall

security of the database system.
17

 DBA
The DBA has a DBA account in the DBMS
Sometimes these are called a system or superuser
account
These accounts provide powerful capabilities such
as:

1.
2.
3.
4.

Account creation
Privilege granting
Privilege revocation
Security level assignment

Action 1 is access control, whereas 2 and 3 are to

control discretionary authorization and 4 is used to
control mandatory authorization
18

Database Audits
The database system must also keep
track of all operations on the database
that are applied by a certain user
throughout each login session.
To keep a record of all updates applied to the
database and of the particular user who
applied each update, we can modify system
log, which includes an entry for each operation
applied to the database that may be required
for recovery from a transaction failure or
system crash.
19

Animated DataBase
Courseware

http://adbc.kennesaw.edu/

20

 Database Audits
If any tampering with the database is
suspected, a database audit is performed
A database audit consists of reviewing the log
to examine all accesses and operations applied
to the database during a certain time period.

A database log that is used mainly for

security purposes is sometimes called an
audit trail.

21

Application Security

22

Application Security
Application Security, the protection of an application against
security threats.
The current state of Application Security security has
been an afterthought.
Rather than focus on application focus on surrounding
environment

Focus not on application security

Focus on protection of data in transit and storage
e.g. using cryptography
But the threats to applications have evolved
This lack of security foresight has cost billions in lost
revenue and now threatens the information technology
infrastructure
23

 Application Security
In developing an application, you must look at all
possible threats
Attacker only needs to focus on 1

Misconceptions:
I have firewall I am safe
Firewall is good but it is not a complete solution by itself

We encrypt the data on route

Are you using ANY encryption? Following a standard? Aware of
current weaknesses of encryption?

We adopt SSL (Secure Socket Layers)

SSL is great at encrypting traffic over the network but it
does not validate your application's input or protect you from a
poorly configured server.
24

How Do You Build

a Secure Web Application?
It is not possible to design and build a secure Web
application until you know your threats.
Recommendation: Add threat modeling into your
application's design phase.
The purpose of threat modeling analyze
your application's architecture and design and
identify potentially vulnerable areas that may
compromise your system's security
(unintentionally or maliciously).

25

 How Do You Build

a Secure Web Application?
After you know your threats, design with security
in mind by applying proven security principles.
Follow secure coding techniques to develop
secure, robust, and hack-resilient solutions.
The design and development of application
layer software must be supported by a secure
network, host, and application configuration on
the servers where the application software is to
be deployed.

26

A holistic approach to
security
"A vulnerability in a network will allow a
malicious user to exploit a host or an
application.
Avulnerability in a host will allow a
malicious user to exploit a network or an
application.
Avulnerability in an application will allow a
malicious user to exploit a network or a
host."
27
Carlos Lyons, Corporate Security,
Microsoft

A holistic approach
to
protect from TCP/IP-based
attacks
implement countermeasures
security
ensuring traffic integrity

http://msdn.microsoft.com/en-us/library/ff648636.aspx

Apply secure
configuration settings
e.g. Patches, updates,
registry, etc

Because the categories

represent the areas
where security
mistakes are most
frequently made

Make use of Application

Vulnerability Categories as a
guide for developing
application and evaluating the
security of a Web application.

28

Anatomy of an Attack
The basic approach used by attackers to target your Web application:
Survey and assess
survey the potential target to identify and assess its characteristics,
its vulnerabilities, potential entry points
Exploit and penetrate
Exploit vulnerabilities, get in usually through normal entry (logon
page, common pages)
Escalate privileges
They immediately attempt to escalate privileges e.g.
administration privileges
Maintain access
Having gained access to a system, an attacker takes steps to make
future access easier and to cover his or her tracks backdoor, take
over weak accounts
Deny service
Attackers who cannot gain access often mount a denial of service attack to
prevent others from using the application .
29

Application Threats

30

Core Security Principles

Compartmentalize
Reduce the surface area of attack.
What resources can an attacker get to?
Firewalls, least privileged accounts, and least
privileged code are examples of
compartmentalizing.

Use least privilege

By running processes using accounts with minimal
privileges and access rights, you significantly
reduce the capabilities of an attacker if the attacker
manages to compromise security and run code.
31

Core Security Principles

Apply defense in depth
Use multiple gatekeepers to keep attackers at
bay.
Do not rely on a single layer of security always
consider that one of the layers may be bypassed
or compromised.

Do not trust user input

Your application's user input is the attacker's
primary weapon when targeting your application.
Assume all input is malicious until proven
otherwise apply input validation strategy
32

Core Security Principles

Check at the gate
Authenticate and authorize early at the first gate.

Fail securely
If an application fails, do not leave sensitive data
accessible.
Do not include details that may help an attacker exploit
vulnerabilities in your application.

Secure the weakest link

Is there a vulnerability at the network layer that an attacker
can exploit? What about the host? Is your application
secure?
Any weak link in the chain is an opportunity for breached
security.
33

Core Security Principles

Create secure defaults
Is the default account set up with least privilege? Is
the default account disabled by default and then
explicitly enabled when required?

Reduce your attack surface

Reduce the surface area of attack by disabling or
removing unused services, protocols, and
functionality.
Does your server need all those services and ports?
Does your application need all those features?
If you do not use it, remove it or disable it
34