No organization large or small is immune to the effects of database intruders and

thieves.
10 steps to reduce risk, improve database security, and adhere to compliance
mandates - http://www.busmanagement.com/issue-20/10-steps-to-reducerisk-improve-database-security-and-adhere-to-compliance-mandates/

Day after day, we see how seemingly small actions and decisions create data-related
problems that ripple out through an organization, creating bigger problems in reports and
other information products, which create even bigger problems in the form of bad
decisions, inefficiencies, ineffective practices, noncompliance with laws and regulations,
and even security breaches.

The key to successfully preventing and responding to any cyber threat is the sound
identification, collection, preservation, and analysis of computer evidence. You must have
the necessary knowledge, skills, and tools to effectively respond to an incident,
forensically collect computer evidence, and analyze the appropriate logs and files. A
positive by-product for any organization is improving organizational processes from such
incidents or incorporating lessons learned from the authors before an incident occurs. An
ounce of prevention is always worth a pound of cure.
Todays attackers are much more efficient and aggressive at seeking economic gain than
they have been in the past. New regulations and standards are indirectly and directly
influencing an organizations capability to respond to computer security incidents.
During an investigation of a computer security incident, the untrained system
administrator, law enforcement officer, or computer security expert may accidentally
destroy valuable evidence or fail to discover critical clues of unlawful or unauthorized
activity. We have witnessed lack of education curtail too many efforts to apprehend
external and internal attackers.
Computers and networks are involved in virtually all activities today. We use them to
communicate, to create intellectual property, to shop, to perform business transactions,
to plan trips, and much more. Networks afford users the opportunity to continuously use
computersthrough cell phones, personal digital assistants (PDAs), wireless connectivity,
and the ubiquitous Internet. Any computer can be used for many purposesjust because
a computer is located in the workplace does not mean that the computer is used only for
work. The pervasive nature of computers and networks means that they are increasingly
connected to incidents and crimes.
Most organizations establish a team of individuals, often referred to as a Computer
Security Incident Response Team (CSIRT), to respond to any computer security incident.
The CSIRT is a multidisciplined team with the appropriate legal, technical, and other
expertise necessary to resolve an incident. Since the CSIRT members have special
expertise, and incident response is not required at all times, the CSIRT is normally a
dynamic team assembled when an organization requires its capabilities.
Computer security incidents are often complex, multifaceted problems. Just as with any
complex engineering problem, we use a black box approach. We divide the larger

problem of incident resolution into components and examine the inputs and outputs of
each component.
Detection of incidents Identify a potential computer security incident.
Initial response Perform an initial investigation, recording the basic details surrounding
the incident, assembling the incident response team, and notifying the individuals who
need to know about the incident.
Formulate response strategy Based on the results of all the known facts, determine the
best response and obtain management approval. Determine what civil, criminal,
administrative, or other actions are appropriate to take, based on the conclusions drawn
from the investigation.
Investigate the incident Perform a thorough collection of data. Review the data
collected to determine what happened, when it happened, who did it, and how it can be
prevented in the future.
Reporting Accurately report information about the investigation in a manner useful to
decision makers.
Resolution Employ security measures and procedural changes, record lessons learned,
and develop long-term fixes for any problems identified.
FIG 2-1 in book, good image!
Preparation leads to successful incident response. During this phase, your organization needs
to prepare both the organization itself as a whole and the CSIRT members, prior to responding
to a computer security incident.
We recognize that computer security incidents are beyond our control; as investigators, we
have no idea when the next incident will occur. Furthermore, as investigators, we often have
no control or access to the affected computers before an incident occurs. However, lack of
control does not mean we should not attempt to posture an organization to promote a rapid
and successful response to any incidents.
Incident response is reactive in nature. The pre-incident preparation phase comprises the only
proactive measures the CSIRT can initiate to ensure that an organizations assets
and information are protected.
Ideally, preparation will involve not just obtaining the tools and developing techniques to
respond to incidents, but also taking actions on the systems and networks that will be part of
any incident you need to investigate. If you are fortunate enough to have any level of control
over the hosts and networks that you will be asked to investigate, there are a variety of steps
you can take now to save time and effort later.

Preparing the Organization

Preparing the organization involves developing all of the corporate-wide strategies you need
to employ to better posture your organization for incident response. This includes the
following:
Implementing host-based security measures
Implementing network-based security measures
Training end users
Employing an intrusion detection system (IDS)
Creating strong access control
Performing timely vulnerability assessments
Ensuring backups are performed on a regular basis
If an organization cannot detect incidents effectively, it cannot succeed in responding to
incidents. Therefore, the detection of incidents phase is one of the most important aspects of

incident response. It is also one of the most decentralized phases, in which those with incident
response expertise have the least control. Suspected incidents may be detected in countless
ways. Computer security incidents are normally identified when someone suspects that an
unauthorized, unacceptable, or unlawful event has occurred involving an organizations
computer networks or data-processing equipment. Initially, the incident may be reported by
an end user, detected by a system administrator, identified by IDS alerts, or discovered by
many other means.
The initial steps of pre-incident preparation involve getting the big picture of your corporate
risk. What are your critical assets? What is their exposure? What is the threat? By identifying
risk, you can ensure that you spend resources preparing for the incidents most likely to affect
your business. Critical assets are the areas within your organization that are critical to the
continued success of the organization. The following are some examples of critical assets:
Corporate reputation Do consumers choose your products and services in part due to
their confidence in your organizations ability to keeptheir data safe?
Confidential business information Do you have critical marketing plans or a secret
product formula?
Nonpublic personally identifiable information Do your information assets house
private individual data?
Critical assets are the ones that produce the greatest liability, or potential loss, to your
organization. Liability occurs through exposures. Consider what exposures in your people,
processes, or technology result in or contribute to loss. Examples of exposures include
unpatched web servers, Internet-facing systems, untrained employees, and lack of logging.
Regular, complete system backups can be a useful reference during incident response.
Backups, like checksums, allow you to figure out what was modified, because they provide a
known-good copy of the file system. Backups can also help you to discover what was deleted
and what was added, which checksums alone cannot reveal. Additionally, some backups save
time/date information, which may be useful for checking the times files and directories were
last accessed, modified, or created.
Also, backups are only as good as the original from which they were created. If a system
compromise is suspected, how do you know that the backups were not made after the
compromise occurred? If the only backups in existence were made after a compromise, all of
the hackers backdoors and trojan programs will be present on the restored system. Given
these caveats, backups can still be incredibly useful. If the backups were created when the
system was in a known-good state, have correct time/date information,
and can be restored in a timely manner, they may very well be your best bet for comparing
system states.
You think that your organizations system has been attacked, or maybe an insider is emailing
your organizations trade secrets to a friend at a rival corporation. What should you do? The
single most helpful network-based incident response activity is to deploy computer systems
that do nothing but intercept or collect network communications. Capturing network
communications is a critical and necessary step when investigating alleged crimes or abuses.
Look at answers to questions section in appendix!
Mandia, Kevin, Prosise, Chris, Pope, Matt. Incident Response & Computer
Forensics, 2nd Edition. McGraw-Hill, 2003.

The insider threat against database management systems is a dangerous security problem.
Authorized users may abuse legitimate privileges to masquerade as other users or to maliciously
harvest data.

Ensuring the security and privacy of data assets is a crucial and very difficult problem in
our modern networked world. Relational database management systems (RDBMS) are

the fundamental means of data organization, storage and access in most organizations,
services, and applications. Naturally, the ubiquity of RDBMSs led to the prevalence of
security threats against these systems. An intruder from the outside, for example, may
be able to gain unauthorized access to data by sending carefully crafted queries to a
back-end database of a Web application. This class of so-called SQL injection attacks are
well-known and well-documented, yet still very dangerous. They can be mitigated by
adopting suitable safeguards, for example, by adopting defensive programming
techniques and by using prepared statements.
An insider attack against an RDBMS, however, is much more difficult to detect, and
potentially much more dangerous. For example, insiders to an organization such as
(former) employees or system administrators might abuse their already existing
privileges to conduct masquerading, data harvesting, or simply sabotage attacks.
By definition, detecting insider attacks by specifying explicit rules or policies is a moot
point: an insider is always defined relative to a set of policies. Consequently, we believe
that the most effective method to deal with the insider threat problem is to statistically
profile normal users (computing) behaviors and raise a flag when a user deviates from
his/her routine. Intuitively, a good statistical profiler should be able to detect non-stealthy
sabotage attacks, quick data harvesting attacks, or masquerading attacks, because the
computing footprints of those actions should be significantly different from day-to-day
activities, from a statistical point of view.
Our main idea and also our conviction is that the best way to distinguish normal vs.
abnormal (or good vs. malicious) access patterns is to look directly at what the user is
trying to access the result of the query itself rather than how he expresses it, i.e. the
SQL expressions. In other words, this data-centric approach values the semantics of the
queries more than their syntax. When a malicious insider tries to acquire new knowledge
about data points and their relationships, the data points accessed are necessarily
different from the old (i.e., previously) accessed points. This deviation occurs in the data
harvesting attacks as well as in the masquerading attacks (e.g., when an intruder gains
access to an insiders account by means of a compromised account).
Mathew, S., Petropoulos, M., Ngo, H. Q., & Upadhyaya, S. (2010, January). A
data-centric approach to insider attack detection in database systems.
InRecent Advances in Intrusion Detection (pp. 382-401). Springer Berlin
Heidelberg.

Database security is a growing concern evidenced by an increase in the number

of reported incidents of loss of or unauthorized exposure to sensitive data. As the
amount of data collected, retained and shared electronically expands, so does
the need to understand database security.
Database security should provide controlled, protected access to the contents of
a database as well as preserve the integrity, consistency, and overall quality of
the data. Students in the computing disciplines must develop an understanding
of the issues and challenges related to database security and must be able to
identify possible solutions.
At its core, database security strives to insure that only authenticated users
perform authorized activities at authorized times. While database security
incorporates a wide array of security topics, notwithstanding, physical security,
network security, encryption and authentication, this paper focuses on the
concepts and mechanisms particular to securing data. Within that context,
database security encompasses three constructs: confidentiality or protection of

data from unauthorized disclosure, integrity or prevention from unauthorized

data access, and availability or the identification of and recovery from hardware
and software errors or malicious activity resulting in the denial of data
availability.
Database technologies are a core component of many computing systems. They
allow data to be retained and shared electronically and the amount of data
contained in these systems continues to grow at an exponential rate. So does the
need to insure the integrity of the data and secure the data from unintended
access.
SQL injection vulnerabilities result from the dynamic creation of SQL queries in
application programs that access a database system. The SQL queries are built
incorporating user input and passed to the database system as a string variable.
SQL injections can be prevented by validating user input. Three approaches are
commonly used to address query string validation: using a black list, using a
white list, or implementing parameterized queries. The black list parses the input
string comparing each character to a predefined list of non-allowed characters.
The disadvantage to using a black list is that many special characters can be
legitimate but will be rejected using this approach. The common example is the
use of the apostrophe in a last name such as OHare. The white list approach is
similar except that each character is compared to a list of allowable characters.
The approach is preferred but special considerations have to be made when
validating the single quote. Parameterized queries use internally defined
parameters to fill in a previously prepared SQL statement. The importance of
input validation cannot be overstated. It is one of the primary defense
mechanisms for preventing database vulnerabilities including SQL injections.
Database auditing is used to track database access and user activity. Auditing
can be used to identify who accessed database objects, what actions were
performed, and what data was changed. Database auditing does not prevent
security breaches, but it does provide a way to identify if breaches have
occurred. Common categories of database auditing include monitoring database
access attempts, Data Control Language (DCL) activities, Data Definition
Language (DDL) activities, and Data Manipulation Language (DML) activities
(Yang, 2009). Monitoring access attempts includes retaining information on
successful and unsuccessful logon and logoff attempts. DCL audits record
changes to user and role privileges, user additions, and user deletions. DDL
audits record changes to the database schema such as changes to table
structure or attribute datatypes. DML audits record changes to data. In addition,
database errors should be monitored (Yang, 2009). Database auditing is
implemented via log files and audit tables. The real challenge of database
auditing is deciding what and how much data to retain and how long to keep it.
Several options exist. A basic audit trail usually captures user access, system
resources used, and changes made to the structure of a database. More
complete auditing captures data reads as well as data modifications. The ADbC
auditing sub-module provides step-by-step examples for creating audits of user
sessions, changes to database structure, and modifications to data.
An audit trail provides a more complete trace recording of not only user access
but also user actions. This type of facility is included with many database
management systems. The most common items that are audited include login
attempts, data read and data modifications operations, unsuccessful attempts to

access database tables, and attempts to insert data that violates specific
constraints.

Murray, M. (2010) Database Security: What Students Need to Know, Journal

of Information Technology and Education: Innovations in Practice, Vol. 9.
available at http://www.jite.org/documents/Vol9/JITEv9IIPp061077Murray804.pdf accessed on the 28/01/2013.

Global cyber security spending was expected to reach $60bn in

2011
It is forecast to grow 10% every year during the next three to five years
One surprising fact highlighted by the report is that more than half (52%) of data breaches occur because of
human error lost computer devices and rogue employees stealing data, and just 32% are down to cyber
criminals and hackers. As the statistics reveal, the risks are both internal and external, which makes it virtually
impossible for a company to protect its data from a breach. Instead, companies need to be prepared for a
breach, understand the risks and assess how the financial impact can be minimised.
Guide to : Cyber Risk Management. Chartis, 2012. (Pgs 1 34.)

The reason databases are targeted is quite simple; databases are at the heart of
any organization, storing customer records and other confidential business data.
But why are databases so vulnerable to breaches? One reason is that
organizations are not protecting these assets well enough. According to IDC, less
than 5% of the $27 billion spent on security products directly addressed data
center security.
When hackers and malicious insiders gain access to sensitive data, they can
quickly extract value, inflict damage, or impact business operations. In addition
to financial loss or reputation damage, breaches can result in regulatory
violations, fines, and legal fees. However, the good news is that the vast majority
of incidents more than 97% according to the Online Trust Alliance (OTA) in 2013
could have been prevented by implementing simple steps and following best
practices and internal controls.
Top 10 image from this paper may be useful.
By addressing these top ten threats, organizations can meet global compliance
requirements and industry best practices related to data protection and risk mitigation.
3

Top Ten Database Security Threats

1. Excessive and Unused Privileges

When someone is granted database privileges that exceed the requirements of their job
function, these privileges can be abused. For example, a bank employee whose job
requires the ability to change only accountholder contact information may take
advantage of excessive database privileges and increase the account balance of a
colleagues savings account. Further, when someone leaves an organization, often his or
her access rights to sensitive data do not change. And, if these workers depart on bad
terms, they can use their old privileges to steal high value data or inflict damage.

How do users end up with excessive privileges? Usually, its because privilege control
mechanisms for job roles have not been well defined or maintained. As a result, users
may be granted generic or default access privileges that far exceed their specific job
requirements. This creates unnecessary risk.

2. Privilege Abuse
Users will abuse legitimate database privileges for unauthorized purposes. Consider an
internal healthcare application used to view individual patient records via a custom Web
interface. The Web application normally limits users to viewing an individual patients
healthcare history multiple patient records cannot be viewed simultaneously and
electronic copies are not allowed. However, a rogue user might be able to circumvent
these restrictions by connecting to the database using an alternative client such as MSExcel. Using Excel and their legitimate login credentials, the user could retrieve and save
all patient records to their laptop. Once patient records reach a client machine, the data
then becomes susceptible to a wide variety of possible breach scenarios.

3. Input Injection (Formerly SQL Injection)

There are two major types of database injection attacks: 1) SQL Injection that targets
traditional database systems and 2) NoSQL Injection that targets Big Data platforms. SQL
Injection attacks usually involve inserting (or injecting) unauthorized or malicious
statements into the input fields of Web applications. On the other hand, NoSQL injection
attacks involve inserting malicious statements into Big Data components (e.g., Hive,
MapReduce, etc.). A successful Input Injection attack can give an attacker unrestricted
access to an entire database.
It is important to note that there are misconceptions about Big Data being impervious to
SQL Injection attacks. These misconceptions are partly true due to the fact that Big Data
does not leverage SQL-based technologies. However, as mentioned earlier, Big Datas
underlying components are still susceptible to Input Injection attacks.

4. Malware
Cybercriminals, state-sponsored hackers, and spies use advanced attacks that blend
multiple tactics such as spear phishing emails and malware to penetrate
organizations and steal sensitive data. Unaware that malware has infected their device,
legitimate users become a conduit for these groups to access your networks and
sensitive data.

5. Weak Audit Trail

Automated recording of database transactions involving sensitive data should be part of
any database deployment. Failure to collect detailed audit records of database activity
represents a serious organizational risk on many levels.
Organizations with weak (or sometimes non-existent) database audit mechanisms will
increasingly find that they are at odds with industry and government regulatory
requirements. For example, Sarbanes-Oxley (SOX), which protects against accounting
errors and fraudulent practices, and the Healthcare Information Portability and
Accountability Act (HIPAA) in the healthcare sector, are just two examples of regulations
with clear database audit requirements.
Many enterprises will turn to native audit tools provided by their database vendors or rely
on ad-hoc and manual solutions. These approaches do not record details necessary to
support auditing, attack detection, and forensics. Furthermore, native database audit
mechanisms are notorious for consuming CPU and disk resources forcing many
organizations to scale back or eliminate auditing altogether. Finally, most native audit
mechanisms are unique to a database server platform. For example, Oracle logs are
different from MS-SQL, and MS-SQL logs are different form DB2. For organizations with
heterogeneous database environments, this imposes a significant obstacle to
implementing uniform, scalable audit processes. When users access the database via
enterprise Web applications (such as SAP, Oracle E-Business Suite, or PeopleSoft) it can
be challenging to understand what database access activity relates to a specific user.
Most audit mechanisms have no awareness of who the end user is because all activity is

associated with the Web application account name. Reporting, visibility, and forensic
analysis are hampered because there is no link to the responsible user.
Finally, users with administrative access to the database, either legitimately or
maliciously obtained, can turn off native database auditing to hide fraudulent activity.
Audit duties should ideally be separate from both database administrators and the
database server platform to ensure strong separation of duties policies.

6. Storage Media Exposure

Backup storage media is often completely unprotected from attack. As a result,
numerous security breaches have involved the theft of database backup disks and tapes.
Furthermore, failure to audit and monitor the activities of administrators who have lowlevel access to sensitive information can put your data at risk. Taking the appropriate
measures to protect backup copies of sensitive data and monitor your most highly
privileged users is not only a data security best practice, but also mandated by many
regulations.

7. Exploitation of Vulnerable, Misconfigured

Databases
It is common to find vulnerable and un-patched databases, or discover databases that
still have default accounts and configuration parameters. Attackers know how to exploit
these vulnerabilities to launch attacks against your organization. Unfortunately,
organizations often struggle to stay on-top of maintaining database configurations even
when patches are available. It generally takes organizations months to patch databases
once a patch is available. During the time your databases are un-patched, they remain
vulnerable.
According to the 2012 Independent Oracle User Group (IOUG), 28 percent of Oracle users
have never applied a Critical Patch Update or dont know whether theyve done so.
Another 10 percent take a year or longer to apply their patches.2

8. Unmanaged Sensitive Data

Many companies struggle to maintain an accurate inventory of their databases and the
critical data objects contained within them. Forgotten databases may contain sensitive
information, and new databases can emerge e.g., in application testing environments
without visibility to the security team. Sensitive data in these databases will be exposed
to threats if the required controls and permissions are not implemented.

9. 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. DoS conditions can be created via many
techniques. The most common technique used in database environments is to overload
server resources such as memory and CPU by flooding the network with database
queries that ultimately cause the server to crash. The motivations behind DoS attacks
are often linked to extortion scams in which a remote attacker will repeatedly crash
servers until the victim meets their demands. Whatever the source, DoS represents a
serious threat for many organizations.

10. Limited Security Expertise and Education

Internal security controls are not keeping pace with data growth and many organizations
are ill-equipped to deal with a security breach. Often this is due to the lack of expertise
required to implement security controls, policies, and training.
According to PWCs 2012 Information Security Breaches Survey, 75% of the organizations
surveyed experienced staff-related breaches when a security policy was poorly
understood and 54% of small businesses did not have a program for educating their staff
about security risks.

Failing to safeguard databases that store sensitive data can cripple your operations,
result in regulatory violations, and destroy your brand. Understanding the top database
threats and implementing the solutions outlined in this paper will enable you to recognize
when youre vulnerable or being attacked, maintain security best practices, and ensure
that your most valuable assets are protected.
Imperva. (2013). Top Ten Database Threats The Most Significant Risks and How
to Mitigate Them