|
How to Mitigate the Most Significant Database Vulnerabilities
The enterprise database infrastructure is subject to an
overwhelming range of threats. This document is intended to help
organizations deal with the most critical of those threats by providing a
list of the top ten as identified by Imperva’s
Application Defense Center. Background information, general
risk mitigation strategies, and Imperva’s SecureSphere Database Security
Gateway protections are provided for each threats.
Top
Ten Database Security Threats
1.
Excessive Privilege Abuse
2.
Legitimate Privilege Abuse
3.
Privilege Elevation
4.
Database Platform Vulnerabilities
5.
SQL Injection
6.
Weak Audit
7.
Denial k of Service
8.
Database Protocol Vulnerabilities
9.
Weak Authentication
10.
Backup Data Exposure
Threat
1 – Excessive privilege Abuse
When
users (or applications) are granted database access privileges that exceed
the requirements of their job function, these privileges may be abused for
malicious purpose. For example, a university administrator whose job
requires only the ability to change student contact information may take
advantage of excessive database update privileges to change grades.
A given
database user ends up with excessive privileges for the simple reason that
database administrators do not have the time to define and update granular
access privilege control mechanisms for each user. As a result, all users
or large groups of users are granted generic default access privileges
that far exceed specific job requirements.
Preventing Excessive privilege Abuse – Query Level Access
Control
The
solution to excessive privileges is query-level access control.
Query-level access control refers to a mechanism that restricts database
privileges to minimum-required SQL operations (SELECT, UPDATE, etc.) and
data. The granularity of data access control must extend beyond the table
to specific rows and columns within a table.
Query-level access control is useful not only for detecting
excessive privilege abuse by malicious employees, but also for preventing
most of the other top ten threats described herein.
Most
database software implementations integrate some level of query-level
access control (triggers, row-level security, etc), but the manual nature
of these “built-in” features make them impractical for all but the
most limited deployments. The process of manually defining a querylevel
access control policy for all users across database rows, columns and
operations is simply too time consuming.
SecureSphere Dynamic Profiling –
Automated Query Level Access Control
The
SecureSphere Database Security Gateway provides an automated mechanism for
defining and enforcing query-level access control policies.
SecureSphere’s Dynamic
Profiling technology applies automated learning algorithms to create
query-level usage profiles for each user and application accessing the
database.
Threat
2 - Legitimate Privilege Abuse
Users
may also abuse legitimate database privileges for unauthorized purposes.
Consider a hypothetical rogue healthcare worker with privileges to view
individual patient records via a custom Web application. The structure of
the Web application normally limits users to viewing an individual
patient’s healthcare history – multiple records cannot be viewed
simultaneously and electronic copies are not allowed. However, the rogue
worker may circumvent these limitations by connecting to the database
using an alternative client such as MS-Excel. Using MS-Excel and his
legitimate login credentials, the worker may retrieve and save all patient
records.
It is
unlikely that such personal copies of patient record databases comply with
any healthcare organization’s patient data protection policies. There
are two risks to consider. The first is the rogue worker who is willing to
trade patient records for money. The second (and perhaps more common) is
the negligent employee that retrieves and stores large amounts of
information to their client machine for legitimate work purposes. Once the
data exists on an endpoint machine, it becomes vulnerable to, Trojans,
laptop theft, etc.
Threat
3 Privilege Elevation
Attackers
may take advantage of database platform software vulnerabilities to
convert access privileges from those of an ordinary user to those of an
administrator. Vulnerabilities may be found in stored procedures, built-in
functions, protocol implementations, and even SQL statements. For example,
a software developer at a financial institution might take advantage of a
vulnerable function to gain the database administrative privilege. With
administrative privilege, the rogue developer may turn off audit
mechanisms, create bogus accounts, transfer funds, etc.
Preventing
Privilege Elevation – IPS and Query Level Access Control
Privilege
elevation exploits can be prevented with a combination of traditional
intrusion prevention systems (IPS) and query-level access control (see
Excessive Privileges above).
SecureSphere
Privilege Elevation – Integrated IPS and Dynamic Profiling
SecureSphere
integrates advanced IPS and Dynamic Profiling for query access control
(see Excessive Privileges above). Together, these technologies provide
extremely accurate privilege elevation protection.
SecureSphere
IPS delivers protection against attacks targeting known vulnerabilities
with Snort®-compatible signature dictionaries for all protocols. In
addition, Imperva’s international security research organization, the
Application Defense Center, provides proprietary SQL-specific protections
to ensure that SecureSphere represents the world’s leading database IPS
security. The SecureSphere Security Update Service automatically updates
all signature dictionaries to ensure that the most current protections are
continuously enforced.
Threat
4 - Platform Vulnerabilities
Vulnerabilities
in underlying operating systems (Windows 2000, UNIX, etc.) and additional
services installed on a database server may lead to unauthorized access,
data corruption, or denial of service. The Blaster Worm, for example, took
advantage of a Windows 2000 vulnerability to create denial of service
conditions.
Threat
5 - SQL Injection
SQL
injection is among the most common attack technique applied by the
international criminal computer attackers to access databases information
from outside perimeter network defenses. In a SQL injection attack, the
perpetrator typically inserts unauthorized database queries into
vulnerable Web application input forms. These queries are then passed to
the database where they are executed with the privileges of the
application. Internal users (inside the perimeter firewall) may also use
SQL Injection by inserting unauthorized queries into internal applications
or database stored procedures. Using SQL injection, attackers may gain
unrestricted access to anentire database.
Threat
6 - Weak Audit
Automated
recording of all sensitive and/or unusual database transactions should be
part of the foundation underlying any database deployment. Weak database
audit policy represents a serious organizational risk on many levels.
-
Deterrence
– Like video cameras recording the faces of individuals entering
a bank, database audit mechanisms serves to deter attackers who know
that database audit tracking provide investigators with forensics link
intruders to a crime.
-
Vulnerability
to Privilege Abuse – Users with administrative access
(either legitimately or maliciously obtained – see privilege
elevation) can simply turn off auditing to hide an attack.
-
Limited
Granularity – Many native audit mechanisms do not record
details necessary to support attack detection, forensics and recovery.
For example, database client application, source IP addresses, and
failed queries (an important attack reconnaissance indicator) are not
recorded by many native mechanisms.
Threat
7 - Denial of Service
Denial
of Service (DOS) is a general attack category in which access to network
applications or data is denied to intended users. Denial of service (DOS)
conditions may be created via many techniques - many of which are related
to previously mentioned vulnerabilities. For example, DOS may be achieved
by taking advantage of a database platform vulnerability to crash a
server.
Other
common DOS techniques include data corruption, network flooding, and
server resource overload (memory, CPU, etc.). Resource overload is
particularly common in database environments.
Threat
8 - Database Protocol Vulnerabilities
Vulnerabilities
in database protocols may allow unauthorized data access, corruption, or
denial of service. For example, the SQLSlammer3 worm took advantage of a flaw in the Microsoft SQL
Server protocol to force denial of service conditions.
Threat
9 - Weak Authentication
Weak
authentication schemes allow attackers to assume the identity of
legitimate database users by stealing or otherwise obtaining login
credentials. An attacker may employ any number of strategies to obtain
credentials.
-
Brute
Force - The attacker repeatedly enters username/password
combinations until he finds one that works. The brute force process
may involve simple guesswork or systematic enumeration of all possible
username/password combinations. Often an attacker will use automated
programs to accelerate the brute force process.
-
Social
Engineering – A scheme in which the attacker takes advantage
the natural human tendency to trust to convince others to provide
their login credentials. For example, an attacker may present himself
via phone as an IT manager and request login credentials for “system
maintenance” purposes.
-
Direct
Credential Theft – An attacker may steal login credentials
by copying post-it notes, password files, etc.
Threat
10 - Backup Data Exposure
Backup
database storage media is often completely unprotected from attack. As a
result, several high profile security breaches have involved theft of
database backup tapes and hard disks.
Preventing
Backup Data Exposure
All
database backups should be encrypted. In fact, some vendors have suggested
that future DBMS products may not support the creation of unencrypted
backups. Encryption of on-line production database information is often
suggested, but performance and cryptographic key management drawbacks
often make this impractical and are generally acknowledged to be a poor
substitute for granular privilege controls described above.
Ref.:
www.imperva.com
|
