Download Chap 6: DB Security File - e

Database Security
Fundamentals of Database system, 5th Edition, Ramez Elmasri and Shamkant B. Navathe
Introduction to Database Security Issues
2
 Types of Security

Legal and ethical issues:


Policy issues


as to what kinds of information should not be made publicly availablefor example, credit ratings and personal medical records
System-related issues


the right to access certain information. Some information may be deemed to
be private and cannot be accessed legally by unauthorized persons
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
3
 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
4
 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
5
 The 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.
Countermeasures : Access control
6
 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.
 A DBMS typically includes a database security and
authorization subsystem that is responsible for ensuring
the security portions of a database against unauthorized
access.
 Two types of database security mechanisms:


Discretionary security mechanisms
Mandatory security mechanisms
Countermeasures : Access control
7
 • 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
8
 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.
Countermeasures : Flow control
13
 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.
Countermeasures : Encryption
14
 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.
Database Administrator (DBA )
15
 The database administrator (DBA) is the central
authority for managing a database system.

The DBA’s 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.
Database Administrator (DBA )
16
 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. Account creation
 2. Privilege granting
 3. Privilege revocation
 4. 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
Database Audits
17
 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.
Database Audits
18
 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.
Application Security
19
Application Security
20
 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
21
 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


We encrypt the data on route


Firewall is good but it is not a complete solution by itself
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.
How Do You Build a Secure Web Application?
22
 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).
How Do You Build a Secure Web Application?
23
 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.
A holistic approach to security
24
"A vulnerability in a network will allow a malicious
user to exploit a host or an application.
A vulnerability in a host will allow a malicious user to
To build
Web applications,
exploit a network
orsecure
an application.
a holistic
approach to
application
A vulnerability
in an application
will
allow a
security
is required
and or
security
malicious user
to exploit
a network
a host."
mustLyons,
be applied
at all Security,
three layers
—
Carlos
Corporate
Microsoft
http://msdn.microsoft.com/en-us/library/ff648636.aspx
A holistic approach
to security
• protect from TCP/IP-based attacks
25 •implement countermeasures
•ensuring traffic integrity
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.
Anatomy of an Attack
26
 The basic approach used by attackers to target your Web application:

Survey and assess


Exploit and penetrate


They immediately attempt to escalate privileges  e.g. administration
privileges
Maintain access


Exploit vulnerabilities, get in  usually through normal entry (logon page,
common pages)
Escalate privileges


survey the potential target to identify and assess its characteristics, its
vulnerabilities, potential entry points
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.
Application Threats
27
Core Security Principles
28
 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.
Core Security Principles
29
 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
Core Security Principles
30
 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.
Core Security Principles
31
 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
Class Assignment
32
 In groups of 5 complete both parts of the
assignment.
 Part 1 : you must find information and write an
introduction to the following threats. It must be
simple and easy toReminder:
understand.
If you keep giving me cut cross-site scripting (XSS), SQL injection, buffer overflow
n-paste versions of
attacks
marks
 Part 2: Investigateassignments,
and write aboutyour
S-SDLC
(Secure
are going
to suffer.
Software Development
Life Cycle)
.