Database security involves protecting data from unauthorized access, alteration, or deletion. It ensures only authorized users can view, change, or delete data according to their access privileges. Key aspects of database security include access controls, encryption, auditing, and monitoring for compliance with security standards to protect the confidentiality, integrity, and availability of the data.

1. Database Security
Security in a database involves mechanisms to protect the data and ensure that it is not accessed,
altered, or deleted without proper authorization.
In other words, Database Security is the mechanism that protects the database against intentional or
accidental threats.
Why need for Database Security?
 In case of shared data, multiple users try to access the data at the same time. In order to
maintain the consistency of the data in the database, database security is needed.
 Due to advancement of internet, data are accessed through World Wide Web, to protect the data
against hackers, database security is needed.
 The plastic money is more popular. The money transaction has to be safe. More specialized
software both to enter the system illegally, extract data is available.
Why is Database Security important?
 Databases often store data which is sensitive in nature
 Incorrect data or loss of data could negatively affect business operations
 Databases can be used as bases to attack other systems from

2. Security risks to database systems include, for example:
Unauthorized or unintended activity or misuse by authorized database users, database administrators,
or network/systems managers, or by unauthorized users or hackers (e.g. inappropriate access to sensitive
data, metadata or functions within databases, or inappropriate changes to the database programs,
structures or security configurations);
Malware infections causing incidents such as unauthorized access, leakage or disclosure of personal or
proprietary data, deletion of or damage to the data or programs, interruption or denial of authorized
access to the database, attacks on other systems and the unanticipated failure of database services;
Overloads, performance constraints and capacity issues resulting in the inability of authorized users to
use databases as intended;
Physical damage to database servers caused by computer room fires or floods, overheating, lightning,
accidental liquid spills, static discharge, electronic breakdowns/equipment failures and obsolescence;
Design flaws and programming bugs in databases and the associated programs and systems, creating
various security vulnerabilities (e.g. unauthorized privilege escalation), data loss/corruption, performance
degradation etc.;
Data corruption and/or loss caused by the entry of invalid data or commands, mistakes in database or
system administration processes, sabotage/criminal damage etc.
OUR ENVIRONMENT
DBA
A Database Administrator responsible for the design, implementation, maintenance and repair of an
organization’s database.
1. Maintaining database and ensuring its availability to users
2. Controlling privileges& permissions to database users
3. Monitoring database performance
4. Database backup and Recovery
5. Database security
We consider database security in relation tothe following situations:

3.  Theft and Fraud
 Loss of confidentiality
 Loss of privacy
 Loss of integrity
 Loss of availability
Database security concerns the use of a broad range of information security controls to protect databases
(potentially including the data, the database applications or stored functions, the database systems, the
database servers and the associated network links) against compromises of their confidentiality, integrity
and availability. It involves various types or categories of controls, such as technical,
procedural/administrative and physical. Database security is a specialist topic within the broader realms of
computer security, information security and risk management.
Many layers and types of information security control are appropriate to databases, including:
 Application security
 Access control
 Auditing
 Authentication
 Encryption
 Integrity controls
 Backups
Traditionally databases have been largely secured against hackers through network security measures
such as firewalls, and network-based intrusion detection systems. While network security controls remain
valuable in this regard, securing the database systems themselves, and the programs/functions and data
within them, has arguably become more critical as networks are increasingly opened to wider access, in
particular access from the Internet. Furthermore, system, program, function and data access controls,
along with the associated user identification, authentication and rights management functions, have
always been important to limit and in some cases log the activities of authorized users and administrators.
In other words, these are complementary approaches to database security, working from both the outside-
in and the inside-out as it were.
Many organizations develop their own "baseline" security standards and designs detailing basic security
control measures for their database systems. These may reflect general information security requirements
or obligations imposed by corporate information security policies and applicable laws and regulations (e.g.
concerning privacy, financial management and reporting systems), along with generally-accepted good
database security practices (such as appropriate hardening of the underlying systems) and perhaps
security recommendations from the relevant database system and software vendors. The security designs
for specific database systems typically specify further security administration and management functions
(such as administration and reporting of user access rights, log management and analysis, database
replication/synchronization and backups) along with various business-driven information security controls
within the database programs and functions (e.g. data entry validation and audit trails). Furthermore,
various security-related activities (manual controls) are normally incorporated into the procedures,
guidelines etc. relating to the design, development, configuration, use, management and maintenance of
databases.

4. Vulnerability Assessments and Compliance
One technique for evaluating database security involves performing vulnerability assessments or
penetration tests against the database. Testers attempt to find security vulnerabilities that could be used
to defeat or bypass security controls, break into the database, compromise the system etc. Database
administrators or information security administrators may for example use automated vulnerability scans
to search out misconfiguration of controls within the layers mentioned above along with known
vulnerabilities within the database software. The results of such scans are used to harden the database
(improve the security controls) and close off the specific vulnerabilities identified, but unfortunately other
vulnerabilities typically remain unrecognized and unaddressed.
Vulnerability Severity Code Definitions
A program of continual monitoring for compliance with database security standards is another important
task for mission critical database environments. Two crucial aspects of database security compliance
include patch management and the review and management of permissions (especially public) granted to
objects within the database. Database objects may include table or other objects listed in the Table link.
The permissions granted for SQL language commands on objects are considered in this process. One
should note that compliance monitoring is similar to vulnerability assessment with the key difference that
the results of vulnerability assessments generally drive the security standards that lead to the continuous
monitoring program. Essentially, vulnerability assessment is a preliminary procedure to determine risk
where a compliance program is the process of on-going risk assessment.
The compliance program should take into consideration any dependencies at the application software
level as changes at the database level may have effects on the application software or the application
server. In direct relation to this topic is that of application security.

5. HARDENING DATABASES
Hardening databases – general strategies and tactics
 Principle of Least Privilege!
 Stay up-to-date on patches
 Remove/disable unneeded default accounts
 Firewalling/Access Control
 Running Database processes under dedicated non-privileged account.
 Password Security
 Disable unneeded components
 Stored Procedures and Triggers
Hardening databases –firewall/access control
 Throttling connections – make it harder for the bad guys to brute-force or guess passwords
 Use firewall software like IPTables
 Xinetd may be useful for throttling
 It’s possible that throttling could deny access to applications which make a large amount of
connections legitimately.
 Reducing the surface area of attack with firewall rules
 Don’t let the world connect to your database server.
Hardening databases –password security
 Strong passwords are a must
o Constant brute-force attacks are happening across campus. Esp. against SQL Server
 Default passwords are a problem
 MySQL: root@localhost:<blank>
 SQL Server: sa:<blank> (Old, but still seen sometimes)
 Oracle: …
 Built in password policy control seems rare
o How can we enforce password policy?
Hardening databases – stored procedures, triggers
 Stored Procedures and Triggers can lead to privilege escalation and compromise. Be sure to be
thinking about security implications when allowing the creation of, and creating these.
Hardening databases – disable unneeded components

6.  Just like disabling unneeded services for an operating system is a good idea disabling unneeded
components for databases is a good idea.
o XML FTP (Oracle)
o Named Pipes access (SQL Server)
HARDING ORACLE
TNS Listener
 “The TNS Listener is the hub of all communications in Oracle. […] When a client wishes to
access the database server, the client connects first to the Listener. […] In versions of Oracle
prior to 10g, the TNS Listener could be administered remotely what makes this particularly
dangerous is the fact that by default the Listener is installed without a password […]”–
The Database Hacker’s Handbook
 Set a password for TNS Listener Administration
o listener.ora file
 PASSWORDS_listenername = somepass
o Use the lsnrctl utility
 LSNRCTL>change_password
Default Accounts
 Decent amount of default accounts
o Be aware what they are
o Ensure the passwords do in fact get changedappropriately
 10g forces admin to set passwords for many default accounts on install and may lock or expire
them.
HARDENING SQL SERVER
Local Admins
 Removing Local BuiltinAdministrators group from sysadmins
o If they are an administrator on a system running SQL Server they can get to anything in
any database.
Authentication
 If configured to use Windows Authentication password policy can be enforced!
XP_CMDSHELL
 Do not enable this on install of SQL Server2k5 unless absolutely necessary
HARDING MYSQL
Disabling network access
 If your Database is only for being accessed by someone/something on the same machine
o disable network-based access with the --skip-networking option
o Firewall off the port MySQL is listening on(typically port 3306)
Account Types

7.  Identity is determined by username AND the location connected from - Coolness
 Scope Identities appropriately
o Allow bob to login from any uiowa.edu hostname
 GRANT […] ON somedb.sometable TOBOB@’%.uiowa.edu’;
o Allow bob to login from any campus IP address
 GRANT […] ON somedb.sometable TOBOB@’128.255.0.0/255.255.0.0’
Encrypting Traffic
MySQL supports encrypting traffic with SSL
o Consider using GRANT … REQUIRE SSL or similar for an account
 Useful for accounts that may be accessing sensitive data and/or data that is
required to be encrypted by some requirement.

8. PRINCIPLE OF LEAST PRIVILEGE
 If X service doesn’t need access to all tables in Y database… then don’t give it access to all
tables.
o Example: A web application that reads a list of people from a database and lists them
on a website. The database also contains sensitive information about those people. The
account used by the web application should not be allowed to read the table that
contains sensitive non-public information.
 Do not give accounts privileges that aren’t needed
o Unneeded privileges to accounts allow more opportunity for privilege escalation attacks.
Database activity monitoring (DAM)
Another security layer of a more sophisticated nature includes real-time database activity monitoring,
either by analyzing protocol traffic (SQL) over the network, or by observing local database activity on each
server using software agents, or both. Use of agents or native logging is required to capture activities
executed on the database server, which typically include the activities of the database administrator.
Agents allow this information to be captured in a fashion that cannot be disabled by the database
administrator, who has the ability to disable or modify native audit logs.
Analysis can be performed to identify known exploits or policy breaches, or baselines can be captured
over time to build a normal pattern used for detection of anomalous activity that could be indicative of
intrusion. These systems can provide a comprehensive Database audit trail in addition to the intrusion
detection mechanisms, and some systems can also provide protection by terminating user sessions
and/or quarantining users demonstrating suspicious behavior. Some systems are designed to support
separation of duties (SOD), which is a typical requirement of auditors. SOD requires that the database
administrators who are typically monitored as part of the DAM, not be able to disable or alter the DAM
functionality. This requires the DAM audit trail to be securely stored in a separate system not administered
by the database administration group.

9. Abstraction
Application level authentication and authorization mechanisms should be considered as an effective
means of providing abstraction from the database layer. The primary benefit of abstraction is that of a
single sign-on capability across multiple databases and database platforms. A Single sign-on system
should store the database user's credentials (login id and password), and authenticate to the database on
behalf of the user.
Native Audit
In addition to using external tools for monitoring or auditing, native database audit capabilities are also
available for many database platforms. The native audit trails are extracted on a regular basis and
transferred to a designated security system where the database administrators do not have access. This
ensures a certain level of segregation of duties that may provide evidence the native audit trails were not
modified by authenticated administrators. Turning on native impacts the performance of the server.
Generally, the native audit trails of databases do not provide sufficient controls to enforce separation of
duties; therefore, the network and/or kernel module level host based monitoring capabilities provides a
higher degree of confidence for forsenics and preservation of evidence.
Process and Procedures
A database security program should include the regular review of permissions granted to individually
owned accounts and accounts used by automated processes. The accounts used by automated
processes should have appropriate controls around password storage such as sufficient encryption and
access controls to reduce the risk of compromise. For individual accounts, a two-factor authentication
system should be considered in a database environment where the risk is commensurate with the
expenditure for such an authentication system.
In conjunction with a sound database security program, an appropriate disaster recovery program should
exist to ensure that service is not interrupted during a security incident or any other incident that results in
an outage of the primary database environment. An example is that of replication for the primary
databases to sites located in different geographical regions.
After an incident occurs, the usage of database forensics should be employed to determine the scope of
the breach, and to identify appropriate changes to systems and/or processes to prevent similar incidents
in the future.

10. Introduction to Database Security Issues
Types of Security
Legal and ethical issues:
Some information is considered private and thus cannot be accessed by unauthorized users. In
many countries there are laws regarding privacy.
Policy issues:
Government, institutions or corporate have their own policies regarding the privacy of
information. They decide what information should be made available to the public and what
information must be protected.
System-related issues
This is concerned with deciding the level at which the security should be implemented. The
security can be implemented at the system level or at the Operating system level or at the
database level
The need to identify multiple security levels :
This is concerned with deciding the different security levels like Top-secret, secret,
confidential and unclassified
Threats to databases
- Loss of integrity: the database must be protected from improper modification. Modification
includes insertion, modification and deletion of data. Integrity is lost if unauthorized changes
are made to the database
- Loss of availability: Availability is concerned with making the database objects available to
the authorized users.
- Loss of confidentiality: Confidentiality means protecting the unauthorized disclosure of data.
Unauthorized disclosure could result in loss of public confidence,, embarrassment and legal
action against the organization.
Control Measures
To protect databases against these types of threats four security measures can be
implemented :
access control, inference control, flow control, and encryption
.Access Control:

11. :The security mechanism of a DBMS must include provisions for restricting access to the
database as a whole.
This access control is handled by creating user accounts and passwords.
Inference Control
Statistical databases are used mainly to produce statistics on various populations.
The database may contain confidential data on individuals, which should be protected from
user access.
Users are permitted to retrieve statistical information on the populations, such as averages,
sums, counts, maximums, minimums, and standard deviations.
The statistical database provide statistical information or summaries of values based on
various criteria. To protect the statistical database inference control measures should be
provided.
Flow Control
Flow control regulates the distribution or flow of information among objects. A flow between
object X and object Y occurs when a program reads values from X and writes values into Y.
Flow controls check that information contained in some objects does not flow explicitly or
implicitly into less protected objects.
A flow policy specifies the channels along which information is allowed to move. The simplest
flow policy specifies just two classes confidential (C) and non-confidential (N), and allows all
flows except those from class C to class N.
A covert channel allows information to pass from a higher classification level to a lower
classification level through improper means.
Encryption
Data encryption , is used to protect sensitive data(such as credit card numbers) that is
transmitted via some type communication network.
The data is encoded using some coding algorithm. An unauthorized user who access encoded
data will have difficulty decoding it, but authorized users are given decoding or decrypting
algorithms(or keys) to decode data.
Encryption consists of applying an encryption algorithm to data using some encryption key
the resulting data has to be decrypted using a decryption key to recover the original data.

12. 1.2 Database Security and the DBA
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 and
classifying users and data in accordance with the policy of the organization. The DBA has a
DBA account in the DBMS, sometimes called a system or superuseraccount , which provides
powerful capabilities :
The DBA is responsible for the overall security of the database system. This includes
1. Account creation
2. Privilege granting
3.Privilege revocation
4.Security level assignment
1.3 Access Protection, User Accounts, and Database Audits
Whenever a person or group of persons need to access adatabase system, the individual or
group must first apply for a user account. The DBA will then create a newaccount
numberandpasswordfor the user if there is alegitimate need to access the database. The user
mustlog into the DBMS by entering account number and password whenever database access
is needed.
Discretionary Access Control Based on Granting and Revoking Privileges
There are two types of database security mechanisms:
Discretionary security mechanisms
Mandatory security mechanisms
The method of enforcing discretionary access control in a database system is based on the
granting and revoking privileges .
2.1Types of Discretionary Privileges
The account level : At this level, the DBA specifies the particular privileges that each account
holds independently of the relations in the database.
The relation (or table level):At this level, the DBA can control the privilege to access each
individual relation or view in the database.

13. 2.1Types of Discretionary Privileges(5)
In SQL the following types of privileges can be granted on each individual relation R:
SELECT (retrieval or read) privilege on R: Gives the account retrieval privilege. In SQL this gives
the account the privilege to use the SELECT statement to retrieve tuples from R.
MODIFY privileges on R: This gives the account the capability to modify tuples of R. In SQL this
privilege is further divided into UPDATE, DELETE, and INSERT privileges to apply the
corresponding SQL command to R. In addition, both the INSERT and UPDATE privileges can
specify that only certain attributes can be updated by the account.
REFERENCES privilege on R: This gives the account the capability to reference relation R at the
time of specifying integrity constraints.
Data Control Language Grant&Revoke
To control the granting and revoking of relation privileges, Each relation R in a database is
assigned anowner account. The person who creates an object is considered as the owner of
that object. The owner of a relation is given all privileges on that relation.
In SQL2, the DBA can assign an owner to a whole schema using the CREATE SCHEMA
command. The owner account holder can pass privileges on any of the owned relation to
other users by granting privileges to their accounts.
2.2 View and Security
The mechanism of viewsis an important discretionary authorization mechanism in its own
right.
For example, if the owner A of a relation R wants another account B to be able to retrieve
only some fields of R, then A can create a view V of R that includes only those attributes and
then grant SELECT on V to B. The same applies to limiting B to retrieving only certain tuples of
R;a view V’ can be created by defining the view by means of a query that selects only those
tuples from R that A wants to allow B to access.
2.4 Propagation of Privileges using the GRANT OPTION
Whenever the owner A of a relation R grants a privilege on Rto another account B, privilege
can be given to Bwithorwithout the GRANT OPTION. If the GRANT OPTION is given, this means
that B can also grant that privilege on R to other accounts. Suppose that Bis given the GRANT
OPTION by A and that B then grants the privilege on R to a third account C, also with
GRANTOPTION. In this way, privileges on R canpropagate to other accounts without the
knowledge of the owner of R.If the owner account A now revokes the privilege granted toB, all
the privileges that B propagated based on that privilege should automatically be revoked by
the system.
2.5 An Example

14. Supposethat the DBA creates four accounts --A1, A2, A3, and A4-- and wants only A1 to be
able to create base relations; then the DBA must issue the following GRANT command in
SQL:GRANT CREATETAB TO A1;User account A1 can create tables under the schema called
EXAMPLE. Suppose that A1 creates the two base relations EMPLOYEE and DEPARTMENT; A1 is
thenownerof these two relations and hence
all the relation privilegeson each of them. Suppose that A1 wants to grant A2 the privilege to
insert and delete tuples in both of these relations, but A1 does not want A2 to be able to
propagate these privileges to additional accounts: GRANT INSERT, DELETE ON EMPLOYEE,
DEPARTMENT TO A2;
2.5 An Example(7)
Finally, suppose that A1 wants to allow A4 to update only the SALARY attribute of
EMPLOYEE;A1 can issue: GRANT UPDATE ON EMPLOYEE (SALARY) TO A4;(The UPDATE or
INSERT privilege can specify particular attributes that may be updated or inserted in a relation.
Other privileges (SELECT, DELETE) are not attribute specific.)
2.3 Revoking Privileges
In some cases it is desirable to grant a privilege to a user temporarily.For example, the owner
of a relation may want to grant the SELECT privilege to a user for a specific task and then
revoke that privilege once the task is completed. Hence, there is need forrevoking privileges.
In SQL, a REVOKE command is included for the purpose of canceling privileges.
2.5 An Example(5)
Suppose that A1 decides to revoke the SELECT privilege on the EMPLOYEE relation from A3; A1
can issue: REVOKE SELECT ON EMPLOYEE FROM A3;(The DBMS must now automatically
revoke the SELECT privilege on EMPLOYEE from A4, too, because A3granted that privilege to
A4 and A3 does not have the privilege any more.)
Mandatory Access Control for Multilevel Security
Security classesare top secret (TS), secret (S), confidential(C), and unclassified (U), where TS is
the highest level andU the lowest: TS≥ S ≥ C ≥ U
Tworestrictions are enforced on data access based on the subject/object classifications:
1.A subject S is not allowed read access to an object Ounless class(S) ≥ class(O). This is known
as the
simple security property.
2.A subject S is not allowed to write an object O unlessclass(S) ≤ class(O). This known as
thestar property(or* property).

15. Mandatory Access Control
To incorporate multilevel security It is necessary to consider attribute values and tuples as
dataobjects. Hence, each attribute A is has aclassification attribute C in the schema. In
addition, in some models, a
tuple classificationTC is added to the relation attributes to provide a classification for the
whole tuple. Hence, amultilevel relationschemaR with n attributes would be represented
asR(A1,C1,A2,C2, …, An,Cn,TC)
where each Cirepresents the classification attribute associated with attribute Ai.
3.1 Comparing Discretionary Access Control and Mandatory Access Control
Discretionary Access Control (DAC) policies are characterized by ahigh degree of flexibility,
which makes them suitable for a large variety of application domains.
The main drawback of DAC models is their vulnerability to malicious attacks, such as Trojan
horses embedded in application programs.
By contrast, mandatory policies ensure a high degree of protection in a way, they prevent any
illegal flow of information.
Mandatory policies have the drawback of being too rigid and they are only applicable in
limited environments.
In many practical situations, discretionary policies are preferred because they offer a better
trade-off between security and applicability.
3.2 Role-Based Access Control
Role-based access control (RBAC) has emerged rapidly in the recent years for managing and
enforcing security in large-scale enterprises. Here permissions are associated with roles, and
users are assigned to appropriate roles. Roles can be created using the CREATE ROLE and
DESTROY ROLE commands. The GRANT and REVOKE commands discussed under DACcan then
be used to assign and revoke privileges from roles.
3.2 Role-Based Access Control(2)
RBAC appears to be a viable alternative to traditional discretionary and mandatory access
controls; it ensures that only authorized users are given access to certain data or resources.
Many DBMSs have allowed the concept of roles, where privileges can be assigned to roles.
Role hierarchy in RBAC is a natural way of organizingroles to reflect the organization’s lines of
authority andresponsibility.