Security in Database

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.

Threats include:
 Unauthorised modification: Changing data values for reasons of sabotage, crime or
ignorance which may be enabled by inadequate security mechanisms, or sharing of
passwords or password guessing, for example.
 Unauthorised disclosure: When information that should not have been disclosed has been
disclosed. A general issue of crucial importance, which can be accidental or deliberate.
 Loss of availability: Sometimes called denial of service. When the database is not
available it incurs a loss (otherwise life is better without the system!). So any threat that
gives rise to time offline, even to check whether something has occurred, is to be avoided.

Two types of privileges are important relating to database security within the database
environment: system privileges and object privileges.

System Privileges
System privileges allow a user to perform administrative actions in a database.

Object Privileges
Object privileges allow for the use of certain operations on database objects as authorized by
another user. Examples include: usage, select, insert, update, and references.[2]

Security models
A security model establishes the external criteria for the examination of security issues in
general, and provides the context for database considerations, including implementation and
operation. Specific DBMSs have their own security models which are highly important in
systems design and operation.
Access control
The purpose of access control must always be clear. Access control is expensive in terms of
analysis, design and operational costs. It is applied to known situations, to known standards,
to achieve known purposes. Do not apply controls without all the above knowledge. Control
always has to be appropriate to the situation.
Authentication and authorisation

Access to IT resources generally requires a log-in process that is trusted to be secure.

Authentication
The client has to establish the identity of the server and the server has to establish the identity
of the client. This is done often by means of shared secrets (either a password/user-id
combination, or shared biographic and/or biometric data). It can also be achieved by a system
of higher authority which has previously established authentication. In client-server systems
where data (not necessarily the database) is distributed, the authentication may be acceptable
from a peer system. Note that authentication may be transmissible from system to system.
The result, as far as the DBMS is concerned, is an authorisation-identifier. Authentication
does not give any privileges for particular tasks. It only establishes that the DBMS trusts that
the user is who he/she claimed to be and that the user trusts that the DBMS is also the
intended system. Authentication is a prerequisite for authorisation.

Authorisation
Authorisation relates to the permissions granted to an authorised user to carry out particular
transactions, and hence to change the state of the database (writeitem transactions) and/or
receive data from the database (read-item transactions). The result of authorisation, which
needs to be on a transactional basis, is a vector: Authorisation (item, auth-id, operation). A
vector is a sequence of data values at a known location in the system.

At a logical level, the system structure needs an authorisation server, which needs to co-
operate with an auditing server. There is an issue of server-to-server security and a problem
with amplification as the authorisation is transmitted from system to system. Amplification
here means that the security issues become larger as a larger number of DBMS servers are
involved in the transaction. Audit requirements are frequently implemented poorly. To be
safe, you need to log all accesses and log all authorisation details with transaction identifiers.
There is a need to audit regularly and maintain an audit trail, often for a long period.

Access philosophies and management

Discretionary control is where specific privileges are assigned on the basis of specific assets,
which authorised users are allowed to use in a particular way. The security DBMS has to
construct an access matrix including objects like relations, records, views and operations for
each user - each entry separating create, read, insert and update privileges. This matrix
becomes very intricate as authorisations will vary from object to object. The matrix can also
become very large, hence its implementation frequently requires the kinds of physical
implementation associated with sparse matrices. It may not be possible to store the matrix in
the computer’s main memory. At its simplest, the matrix can be viewed as a two-dimensional
table:
Mandatory control is authorisation by level or role. A typical mandatory scheme is the four-
level government classification of open, secret, most secret and top secret. The related
concept is to apply security controls not to individuals but to roles - so the pay clerk has
privileges because of the job role and not because of personal factors. The database
implication is that each data item is assigned a classification for read, create, update and
delete (or a subset of these), with a similar classification attached to each authorised user. An
algorithm will allow access to objects on the basis of less than or equal to the assigned level
of clearance - so a user with clearance level 3 to read items will also have access to items of
level 0, 1 and 2.

Mandatory security schemes are relatively easy to understand and, therefore, relatively easy
to manage and audit. Discretionary security is difficult to control and therefore mistakes and
oversights are easy to make and difficult to detect. You can translate this difficulty into costs.
There are perhaps two other key principles in security. One is disclosure, which is often only
on a need-to-know basis. This fits in better with discretionary.

Database Security Strategy

A database security strategy focuses on proactively protecting data from internal and external
attacks, curtailing data exposure to privileged and authorized IT users, and safeguarding all
databases, including production and non-production.

Most organizations generally focus on a perimeter-centered network security, proposing the

first line of defense, but the increasing complexity of an organization’s security environment
and sophisticated attack vectors require organizations to take a comprehensive view of data
security. Database security, which is the generally considered the last line of defense for
enterprise data, needs a much larger focus than other layers of the whole stack for the reason
that it holds an organization’s crown jewels.

A key to building any successful database security strategy encompasses:

 Understanding what type of data needs to be protected, such as personal identification
information (PII), credit card numbers, customer data, Social Security Numbers,
intellectual property, and health information, etc.
 Understanding applicable regulatory compliance requirements, such as payment card
industry (PCI), Health Insurance Portability and Accountability Act (HIPAA),
FISMA, etc.
 Performing an inventory of all databases, including nonproduction.
 Discovering and classifying databases based on the sensitivity of data.
 Establishing security policies for all databases in the environment, segregated across
zones.
 Having actions for each category of policies and deploying them across databases,
segregated across zones.
 Taking suitable security measures, such as data masking (redaction), monitoring,
auditing, encryption, and access control.
  Looking for an all-inclusive database security solution that can implement robust
database security at a low cost.

Key Pillars of Database Security Strategy

FOUNDATION PILLAR
This primarily includes discovery, classification, AAA (authentication, authorization, and
accounting), and patch management. Without understanding where and how the sensitive
data is used across the environment, securing data can be very sophisticated and challenging.

The “foundation pillar” stresses discovery and classification of sensitive data and devising a
vigorous authentication, authorization, and access control framework. In addition, all critical
databases must be patched periodically to remove known vulnerabilities.

Understanding which databases contain sensitive data is an important requirement for any
database security strategy and architecture. Organizations should take a comprehensive
inventory of all databases, including all environments across the enterprise (such as
production and non-production), and confirm that authentication, authorization, and access
control is enabled for all sensitive and critical databases. To establish a strong database
security foundation, enterprises should use:

 Database discovery and classification, which provides information on all databases to

focus upon
 AAA mechanisms for appropriate database access
 Patch management protecting against identified vulnerabilities

DETECTION PILLAR
This section encompasses monitoring, auditing, and vulnerability assessment. All changes to
sensitive data should be logged to provide the ability to justify and respond to auditing, where
the importance is “Who changed what data?”, “When was it changed?”, etc. Auditing and
monitoring also usually compromises for compensating controls when preventive measures
are not enabled. In addition, vulnerability assessment reports gaps in the database
environment, such as weak passwords or excessive access privileges.

To support regulatory compliance standards, such as PCI, HIPAA, FISMA, etc., and improve
data security, organizations should have records of all access and modifications to sensitive
data. Data and metadata within databases can be accessed, modified, or even deleted in
moments. The detection pillar emphasizes a comprehensive audit trail of database activities
and making details of vulnerabilities available. Detection layer security fundamentally
includes:
 Continuous auditing and alerting on data anomalies and access by privileged users
 Security monitoring and real-time intrusion prevention to defend the database against
potential threats
 Vulnerability assessment to check for database integrity and security configuration
across databases.

PREVENTIVE PILLAR
This category encompasses data encryption, data masking, and database firewall. This pillar
emphases preventing unauthorized access and protecting against potential attacks. Preventive
security measures include:
  Network and data-at-rest encryption
 Data masking (redaction) across all databases to prevent data exposure to all
categories of users, including, but not restricted to, developers, testers, and other non-
production users
 Database firewalls to prevent potential threats, such as SQL injection attacks or
privilege escalation from impacting databases
 Change management to enable a formal procedure to manage changes in production.
The goal is to prevent unauthorized access to and exposure of private data.

Preventive measures basically include:

 Data redaction/masking to protect data in nonproduction databases.
 Database and network encryption to defend databases and applications across all
network zones
 Database firewalls for real-time protection from multiple attack vectors and to ensure
that, if any unauthorized user gets access, it can protect the corresponding data by
blocking connection or relevant access in real time.

Conclusion

Database security has become critical for all enterprises to defend against growing attacks
and meeting various regulatory requirements. Below are some key recommendations:

 Prevention should be a topmost priority as per the architecture – Even though

database monitoring is vital to track data access, it doesn’t prevent cyber-criminals
and hackers from stealing data. Organizations must make the most of their focus by
implementing preventive controls to protect against real-time sophisticated threats.
 Focus on an organization-wide database security strategy – An all-inclusive database
security strategy makes sure that investments are not ad hoc and address the three key
pillars, which are foundation, detection, and prevention, across the critical databases.
Don’t just focus on one or two critical databases, but on all databases that store
sensitive data; in other words, all your databases.