This book will help the DBA to assess their current level of risk as well as their existing security posture. It will then provide practical, applicable knowledge to appropriately secure the Oracle database.
Practical Oracle Security
By Josh Shaul, Aaron Ingram
Published by Elsevier
Published: Nov. 12, 2007
Dimensions 7 1/2 X 9 1/4 in
Buy this book
Your Unauthorized Guide to Relational Database Security
This book will help the DBA to assess their current level of risk as well as their existing security posture. It will then provide practical, applicable knowledge to appropriately secure the Oracle database.
Solutions in this Chapter:
- A Brief History of Security Features
- The Regulatory Environment Driving Database Security
- Major Data Theft Incidents
- A Step-by-step Approach to Securing Oracle
A senior database manager
at one of the worlds largest banks once told me that the best way to secure
Oracle is to unplug it from the wall
and he is probably right. In fact, this
holds true for nearly every networked application. Unfortunately, for many of
us turning off the database is not an option; we must find another way to
secure our systems. New technologies and services drive revenue for businesses,
particularly those that provide a tailored experience to customers. These
systems frequently require storing, processing, and offering access to personal
information. No different are the systems that store corporate secrets or
financial information. Much of the data they store is extremely sensitive, but
it all needs to be readily and easily accessible nonetheless. This creates a
significant data security challenge, one we will address in detail throughout
This book is designed to
help you establish a practical security program for Oracle databases. We will
create a means for measuring and assessing the security of your databases, and
give you tools to create a security scorecard for each of your Oracle
databases. This is not a Database Administrator (DBA) handbookfar from it.
Instead, we are writing to the entire database security community, which
includes DBAs, but also includes Information Technology (IT) security staff,
auditors, and even the Chief Information Security Officer (CISO).
Oracle is by far the most
widely deployed database in the world. It is a central component of critical
systems across nearly every major industry that thrives today. In the financial,
medical, telecom, infrastructure, government, and even the military, the
databases and the data within them are the business. Over the last several
years, databases have become a frequent target of cyber attacks. At first,
these attacks were primarily intended to cause disruptions in business and gain
notoriety among the hacker community. This has changed dramatically with
database attacks increasingly focused on extracting the sensitive and valuable
information from systems in an attempt at monetary gains by the attacker.
Stealing personal information for use in identity theft, stealing credit card
numbers to make purchases at will, stealing corporate secrets to take back the
competitors edge, these are todays drivers behind attacks on databases.
Because of Oracles dominance in the marketplace, many of these attacks have
been focused on Oracle systems. Oracle has been an unwilling conspirator in
these attacks, having built a system riddled with vulnerabilities for the
attackers to go after. At the same time, Oracle has built the most complete
suite of security features in any commercial database. This book will show you
how to properly use these features to ensure your databases remain available
and secure in a diverse and rapidly changing environment.
A Brief History of Security Features in Oracle
The Oracle database was born out of a US intelligence community project,
called Project Oracle, run by the Central Intelligence Agency. Given the
initial customer, security was a serious concern from day one. If you go back
to the initial release of Oracle from 1979 (actually dubbed version 2) the
beginnings of todays security system were already present. Those were the days
when databases were housed in physically protected secure rooms, with no
outside or network access. At the time, there was no means to access Oracle
without being on the server itself. The concern about an outside attacker
breaching the system was hardly even considered; however, the threat from an
insider was a present concern. It is quite likely that this threat brought
about some components of the often confusing and misleading error message
system that remains in use today. For example, try selecting from a table or
view that exists in Oracle that you do not have permissions to access. Oracle
will respond with the following:
SQL*Plus: Release 10.2.0.1.0 - Production on Sat Sep 15 13:18:52 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> select * from sys.user$;
select * from sys.user$;
ERROR at line 1:
ORA-00942: table or view does not exist
Why tell the user that the object they requested does not
exist, rather then provide a message telling them they do not have the proper
permissions? Its simple. If a user does not have rights on an object, that
user has no reason to know that the object exists. Handing out any more
information than is absolutely necessary has never been good for security,
regardless of what is being secured.
Passwords were present in version 2 as well, but the password
management system was extremely basic. Overall, there was a minimal need for
security when Oracle first got started, but underpinnings were put in place. As
the technology world began to change, and the protections offered by physically
securing the servers were no longer sufficient, Oracle changed as well and
began to implement a complex array of increasingly sophisticated security
At first, controls on user rights and privileges were nearly
non-existent. Within a few years, Oracle introduced the concept of roles. Three
roles were rigidly defined: CONNECT, RESOURCE, and DBA. Users could be assigned roles, but these roles could not be
modified, nor could custom roles be created. All privileges were assigned
directly to the roles, never to users. This continued until version 6 of the
database was released, when Oracle introduced the capability to grant
privileges to users. This was a significant improvement in the security system,
allowing administrators to have much more granular control in giving out access
to data on an as-needed basis. The CONNECT, RESOURCE, and DBA roles remained
statically defined until version 7 of Oracle was released and the concept of
user-defined roles was introduced. User-defined roles revolutionized the
privilege control system in Oracle, allowing for efficient and flexible
management of permissions by allowing them to be grouped together and assigned
or removed in bulk. The Oracle7 role system remains in use today and will
likely not be changed with the future release of Oracle11g. Well cover using
roles and privileges in detail in Chapter 4.
One more major development in the privilege control system came
in Oracle8i: invoker rights procedures.
Stored procedures have been around for quite some time, and were commonly used
as they are today, to group complex functionality into a single procedure and
then offer easy access through a simple interface. For a long time, all
procedures were run with definer rights.
This means that when a procedure is called, it runs at the privilege level of
the definer (the user who owns the procedure), often the DBA. Invoker rights procedures are different.
They run at the privilege level of the invoker (the user who ran the
procedure). This offers flexibility to database developers who can now create
procedures that access data and database functions without the worry of a user
getting access to data they should never see.
Until version 5 of the database, Oracle offered no networking
features. Database access was only permitted by directly connecting from the
host operating system (OS). This required users to be able to access the server
on which Oracle ran, making it impossible to implement any kind of distributed
computing system. In version 5, SQL*Net 1.0 was introduced and with it came a
dramatic change in how Oracle was used and how it was secured. It was no longer
necessary to access the host OS to log in to the database; all that was needed
was a network connection and some client software and the database could be
accessed remotely. The introduction of SQL*Net had an important side effect.
Users could now interact directly and exclusively with Oracles immature user
authentication system and could completely bypass the mature authentication
features offered by the database host OS.
Oracle Advanced Networking Option
The Oracle Advanced Networking Option (ANO) was released with
version 7.3 of the database in 1996. ANO was the first Oracle product to offer
strong security for a networked database; its two primary features were network
security and single sign-on.
In Oracles terms, network security means both confidentiality
and integrity protection. The confidentiality part ensures that nobody can read
the data as it crosses the network, while the integrity protection part ensures
that nobody can change the data as it moves. Confidentiality was implemented
using the symmetric key encryption algorithms Rons Code 4 (RC4) and Data
Encryption Standard (DES). The integrity protection was implemented with a
cryptographic hash or message digest function called Message Digest 5 (MD5).
Oracle chose strong algorithms and made attacks against the data as it
traverses the network very difficult to execute.
ANO was released in
1996 during the dark days when the US government held tightly to
export controls on encryption products. This forced Oracle to offer two
versions of ANO, one for US
domestic use only and another for export. The export version was limited to the
use of 40-bit encryption keys for both RC4 and DES, significantly watering down
the strength of each encryption algorithm. Domestic versions used 56-bit DES
and allowed for up to 128-bit RC4. In the years since, these export controls
have been largely removed and Oracle now offers only one version of the network
security product, now called the Advanced Security Option.
In an attempt to simplify password management for
organizations, Oracle began to integrate with third-party providers of single
sign-on (SSO) authentication systems. The intention was to integrate Oracle
databases into enterprise SSO systems, allowing users to set a single strong
password in one place, and then use the same account to access all systems.
This allowed users to remember only one password, and it allowed administrators
to force the use of strong passwords on their users. Furthermore, SSO makes
user provisioning and password management simple, as all credentials are
managed centrally. In the initial release, Oracle offered support for a number
of SSO systems, including Kerberos, CyberSAFE, SecurID, Biometric, and DCE
The i in Oracle8i
Oracle ushered in the Internet era with the release of
Oracle8i in early 1999. Targeted at the eCommerce marketplace in the heat of
the .com boom, Oracle had the right product at the right time to claim an
enormous share of the online retail market. Touted as a platform for developing
Internet applications, Oracle8i was built to face the Internet and store
sensitive data. This represented a shift in how and where databases were used.
Hackers started finding databases directly accessible from the Internet. Oracle
hacking went mainstream.
Network security continued to be a strong suit for Oracle. They
renamed SQL*Net as Net8 and renamed the Advanced Networking Option to Oracle
Advanced Security (OAS). Major enhancements were made to both the network
security and single sign-on components of OAS. Oracle added support for Secure
Sockets Layer (SSL) (network authentication, encryption, and integrity
protection) and Remote Authentication Dial-in User Service (RADIUS)
(centralized user authentication). Both are standards-based systems that had
been publicly reviewed, offering assurance to companies who didnt want to rely
on Oracle alone to attest to the effectiveness of their security protocols. In
the releases since 8i, Oracle has continued to offer enhancements and upgrades
to the OAS product.
Oracle has offered auditing features in the database since
very early on. Capabilities were provided to audit log-ins, object access, and
database actions (defined as anything that makes a change to a database object,
such as CREATE TABLE or ALTER DATABASE). Each event would be captured and
labeled as successful or failed. Early versions of Oracle auditing were
somewhat limited. Database actions could only be audited by role (CONNECT,
RESOURCE, and DBA), not by individual user. SYSDBA activities could not be
audited at all. Audit data was stored inside the database in the SYS.AUD$
table, and needed to be periodically truncated by the DBA. However, Oracle has
supported auditing of access to SYS.AUD$ from the beginning.
With the Oracle7 release, database triggers were introduced.
This new functionality was useful in many areas, audit in particular. The
built-in Oracle auditing system records only those events that have occurred;
it does not record before and after values for data changes. Triggers could be
used to do just that, triggering on an update or delete to capture the old
value before replacing or removing it. While a trigger-based audit system had
to be implemented manually, it was a useful and powerful addition to the native
auditing capabilities of the database.
Oracle7 also brought about the capability to write audit data
directly to a flat file instead of into the database. This provided administrators
with needed flexibility and allowed for tighter access controls on the audit
data. The restrictions on database action auditing were lifted, allowing
auditing by an individual user instead of by role.
Oracle8 came with its own set of improvements to the audit
system. Things got much more granular with the capability to enable auditing at
the object, schema, and system level. Oracle also added several views to allow
for simpler review and analysis of the stored audit data.
Fine Grained Auditing
Fine Grained Auditing (FGA) was first introduced with
Oracle9i. A major improvement in Oracles auditing capability, the first
release of FGA focused on auditing of SELECT statements. Previously, Oracle
auditing could record that a user had read from a table or view with a SELECT
statement. While it was possible to know that a SELECT statement was issued and
who issued it, it was not possible to determine what data was selected. FGA was
designed to collect this information. Each event logged by FGA detailed the
user, date/time, schema, table, columns accessed, the exact SQL statement
issued including bind variables, and a system change number. This was a level
of detail never before seen in a database auditing system, allowing for
complete recreation of each audited event. By logging the exact SQL statement
executed and the system change number, it was possible to determine exactly
what data had been returned by the query. A DBA could use a flashback query to
effectively restore the database to the point in time when the query was first
executed and then run it again. The results would be the same, proving what
data had been read from the system.
Oracle took this a step further by allowing administrators to
audit access to individual rows by evaluating the row against a set of
conditions supplied when auditing was configured. This allowed for auditing
access to sensitive data only. The DVA could set up a column to indicate
sensitivity, and then configure the audit system to capture access only to the
rows labeled sensitive. This powerful feature had only one major shortcoming;
it worked for SELECT only. There was no granular auditing of the Data
Manipulation Language (DML) commands INSERT, UPDATE, or DELETE.
With the release of Oracle10g came another round of major
improvements to the built-in auditing systems. FGA was enhanced with the
capability to audit DML statements, providing the same level of detail for
INSERT, UPDATE, and DELETE statements as had previously been supplied only for
SELECT. The improvements in 10g were not limited to FGA, in fact, the entire
audit system was overhauled to make all audit capabilities more granular and
FGA-like. By setting the audit_trail
parameter to db_extended, standard
Oracle audit will capture both the exact SQL text executed, along with the
values for any bind variables used for any query run against the database.
Oracle DBAs now have a powerful mechanism to track exactly what their users are
doing in the database.
Oracle has included its own authentication and password
management system since the very beginning. At first, the system was barebones.
Each user got a password; the password was assigned and set by the DBA. Users
had no means to change their own password, and Oracle had no automated controls
for password management. Passwords never expired, never needed to be changed,
and could be as simple or as complex as the DBA chose. Initially, the problem
with this system was password distribution. Since the DBA had to set each
users password, they would also have to distribute the password to each user.
This could be a challenge in a large organization with dozens or even hundreds
of database users. Hand written notes, phone calls, and personal visits were
commonly used to distribute the passwords, but that took time and users had to
wait their turn to get their new password before being allowed into the
database. At the time, it was not entirely uncommon for a DBA to simply give
each user the same password. This made it easy to distribute the passwords, but
created new security nightmares. Anyone with access could essentially log in
with anybody elses account and privilege level. Things needed to change.
Before long, Oracle gave users the ability to alter their own
password. This was a big improvement. The distribution problem was almost
solved. DBAs still needed to set each users initial password, and the same
problems apply to distributing those initial passwords. However, the scope of
the issue was drastically reduced. DBAs would instruct each user to change
their initial password the first time they logged in to the database. They
could even use the auditing system to ensure that a password change had been
made. However, Oracles password controls were still well behind those offered
by the popular OSes of the time, which started to become a legitimate concern
when Oracle databases began to accept connections from across the network.
True password management features were first offered in the
database in Oracle8, with a system called Profiles. Profiles provide a means
for setting controls on passwords, and then applying those controls to users in
groups (in a manner very similar to how roles allow permissions to be managed
in groups). DBAs could create custom profiles for each group of users, with
controls tailored to each groups needs. A DEFAULT profile was provided as a
catchall. Any users not explicitly assigned to a profile would be assigned the
DEFAULT profile, ensuring that the password management features apply to
everyone. This profile system remains in use today and has been largely
unchanged since its initial release. Oracle now had password management on par
with most operating systems.
FAILED_LOGIN_ATTEMPTS This feature, often referred to as account
lockout, is designed to effectively thwart any password guessing attempts
against the database. Without this control in place, an attacker can literally
spend eternity attempting to break into Oracle by repeatedly guessing passwords
and attempting to log in. No matter how strong or complex the passwords, given
enough time, an attacker could brute-force the system and gain access. The
account lockout feature prevents this attack by enforcing a threshold of failed
login attempts before an account is disabled or locked, meaning it is no longer
permitted access to the database, even if the correct password is supplied. By
setting this parameter to a reasonable value, 5 for example, DBAs can ensure
that brute-force password-guessing attempts will almost always fail, while
giving users a few opportunities to make a mistake typing in their password
before their account is locked. Once an account has been locked, a DBA must
manually unlock it, unless the database is configured to do so automatically.
Even the strongest passwords need to be
changed periodically, and relying on the DBA to remember when that time comes
for each user leaves a big opportunity for forgetfulness. The
PASSWORD_LIFE_TIME setting enforces password changes automatically after the
lifetime, set in number of days, has expired. Once a users password life time
has passed, the database forces the user to change their password on the next
login, denying access to the database until the password has been changed. Alternately,
a DBA can set a grace period after a users password has expired, during which
the password will still work to gain access to the database. However, a warning
message will be displayed, informing the user that their password has expired
and must be changed soon.
In order to prevent users from trying to
trick the password management system into letting them keep their existing
password once it has expired, Oracle tracks password history and can enforce a
minimum length of time before a password can be reused. Without this feature,
when a users password expires, they could easily change the password to some
new value, allowing the database to log them in, then change the password right
back to the old value. The password reuse time setting enforces a number of
days before a password can be reused. This value can be set to UNLIMITED to
ensure that a user can never use the same password twice.
Similar to PASSWORD_REUSE_TIME, the
reuse max value controls how many times a user can reuse the same password
before it is permanently banned.
As mentioned earlier, Oracle can be
configured to automatically unlock accounts that were locked by the
FAILED_LOGIN_ATTEMPTS control. The password lock time controls if and when
those accounts are automatically unlocked. This parameter is configured with a
number of days for automatic unlock, or set to UNLIMITED to force the DBA to
unlock accounts manually.
Once a users password life time has expired, they may be given a grace period
during which they are asked, but not forced, to change their password. The
duration of this grace period is controlled by the PASSWORD_GRACE_TIME parameter,
set in days. Once the grace period has expired, a user must change their
password in order to successfully log in to the database.
Probably the most powerful and flexible
of all password management features is the PASSWORD_VERIFY_FUNCTION. This
setting points Oracle to a user-defined function, typically written in C, that
can enforce any complexity rules desired on a new password. Want to enforce a
minimum length? Require users to include a digit? Special character? The password
verify function can be as simple or complex as desired, the only limitation is
your programming ability. Oracle comes with a default password verify function
which enforces several controls. We will cover the password verify function in
detail in Chapter 8.
In the database world, compartmentalization of data is
something that is uniquely offered by Oracle. The concept involves classifying
data elements, and then controlling access to those elements based on the
classification and a users access or security level. By assigning a security
level and compartment to each row of data in the database, access can be
tightly controlled on a row-by-row basis, even when permissions have been
granted on the entire table. When queries are issued, the system compares the
security level and compartments on the data being accessed with the security
authorizations of the user executing the query. Only the rows that match the
users authorizations are accessible, enforcing mandatory access control.
Data compartmentalization features first appeared in an add-on
product to Oracle7, called Trusted Oracle7, primarily driven by Oracles
clientele in the US
military. Based on the Bell-LaPadula security model, Trusted Oracle7 came
pre-configured with three security levels: Confidential,
Secret, and Top Secret. By combining these levels with a set of compartments,
say one for each project that uses the database, it was possible to create a
hierarchical set of controls that limited each user to accessing only the data
from their project(s) at their security level. At the top of the hierarchy,
users could see data from any compartment with any security level. At the
bottom, a user could be restricted to seeing only Confidential data (not Secret
or Top Secret) for their one compartment (or project).
Trusted Oracle7 offered some significant benefits, but came
with a significant amount of baggage, as the complexity of configuring and
implementing the system could be quite daunting, particularly in a system
hosting a dozen or more projects with millions of rows of data stored in the
database. The system was deployed in some military and even a few commercial
applications, but it was widely viewed as too burdensome and complex for broad
market acceptance. Even after enhancing the product to allow for the
utilization of user-defined roles to define compartments, the commercial world
continued not to accept the product, and eventually it was redesigned and
model was invented by David Elliot Bell and Len LaPadula in 1973, in an effort
to define a multi-level security policy for the US Department of Defense. The
model defines a set of security labels, ranging from Top Secret down to
Unclassified (or Public) that can be used to enforce controls on access to
data. Bell-LaPadula is defined as a state
machine with a clearly defined set of states and functions to transition
from one state to the next. When implemented properly, a system can be proven
to satisfy its security design requirements.
Beyond basic access
controls, Bell-LaPadula enforces two main rules, called the simple security property and the *-property. The simple security property
ensures that a user cannot read data that is classified above their security
level (no read up). This means that a user assigned the Secret classification
can read both Secret and Confidential data, but cannot read anything labeled
Top Secret. The *-property (read as star-policy) ensures that a user cannot
write data that is classified below their security level (no write down). A
user with the Secret classification can write Secret and Top Secret data, but
cannot input any data that is classified as Confidential. A modification to the
*-property, called the strong *-property
restricts users to writing data at their own level only, never above or below.
Virtual Private Database
While Trusted Oracle7 proved too rigid and difficult to
implement, it provided a feature that the market clearly desired: a mechanism
to allow multiple users within the same schema to see only the data that
applied to them. Consider an online retail system, where customers can log in
and view the status of their pending orders. Its likely that the orders for
all customers are stored in the same table and its important that each user
cannot view the orders that belong to others. Some means of access control is
required. Before the release of Virtual Private Database (VPD), organizations
generally implemented this access control in the application. A simple approach
was taken. Construct a query that includes a WHERE clause that ensures only the
current users data is returned. This works great until the user finds a way to
connect to the database directly, then all bets are off. Once connected
directly, there is nothing to limit the data that a user can see. If they have
rights on the Orders table, they have rights on all of the data in that table.
VPD was introduced to eliminate this concern and enforce security within the
database, so that no matter what application is used to connect, each user can
only see their data.
VPD uses a simple mechanism to enforce this access control. By
transparently appending a WHERE clause to every query a user runs, VPD can
effectively limit access to data by matching each user to a set of labels
stored with the data. Users are granted access to data with specified labels,
the VPD is configured, and then Oracle does the rest.
Oracle Label Security
With the release of Oracle8i came the new version of Trusted
Oracle7, now dubbed Oracle Label Security. Based on the same classification
levels as were used in Trusted Oracle7, Oracle Label Security was essentially a
pre-configured VPD for military applications. Oracle Label Security came with
several innovations, particularly around the capability to create custom
configurations with user-defined labels and compartments. The tool also came
with an intuitive graphical user interface (GUI) for configuration called
Oracle Policy Manager. The Policy Manager product allowed DBAs to set up
policies, define labels and their functions, and control user authorization.
Once the set up is complete, Oracle will create a VPD designed to enforce the
desired policies and authorizations.
Label Security can be applied at either the schema or
individual table level, offering complete flexibility. Most applications
require only a small percentage of the data they store to be secured by Label,
by allowing Label Security to be implemented on the few tables that require it.
Configuration and management of the database is vastly simplified over what was
offered in Trusted Oracle7. Organizations now had a set of powerful tools to
create a highly compartmentalized database, with effective access controls in
place to ensure that users can only access the data they need to get their job
Oracle10g and Beyond
Oracle10g represents the state-of-the-art in database
security. With more effective security features packed into the product than
ever before, 10g and the upcoming Oracle11g offer an unprecedented level of
control over who can get into your database and what they can access while they
are there, while ensuring that an audit trail is kept that can log everything
that goes on. It is likely that Oracle databases offer more security features
than any other piece of software that has ever been created.
While this all sounds great, with all these features comes
tremendous complexity. Therein lies the problem. Complexity is bad for
security. The more features and options you have, the more potential for
misconfigurations. Even worse, the more complex the code, the more
opportunities there are for making mistakes, the kind of mistakes that can void
all of the fancy security features. Oracle is not immune to making coding
mistakes. In fact, so many vulnerabilities have been found that Oracle has been
forced to implement a quarterly patch release schedule, solely for fixing
security holes in their products. Each quarter, more devastating
vulnerabilities are announced and fixed, and with each release, more
researchers and hackers jump into the fray, finding more and more
vulnerabilities for the software giant to fix. Several of the vulnerabilities
found thus far have been extremely disastrous. In more than 10 cases,
vulnerabilities have been discovered that allow an unauthenticated user to
connect to the database and assume the role of SYSDBA, taking complete control
over the database and everything in it, regardless of the security features
that are enabled at the time. This is a fascinating dichotomy, as Oracle is
likely both the most secure and the most vulnerable database in existence
The Regulatory Environment Driving Database Security
Over the last several years, things have changed dramatically
in the IT Security world. Data security has become a major focus area for both
government and industry regulations, real regulations with real consequences
for non-compliance. At the heart of any data security program must be a
database security program, as most of the worlds sensitive data spends 95+
percent of its time in a database, most commonly an Oracle database. We have
all heard of Sarbanes-Oxley (SOX) , the US Federal regulation enforcing strict
control financial reporting practices for publicly traded companies, but there
are a host of other regulations that govern data security in a similar way.
Financial institutions must comply with the Gramm-Leach-Bliley Financial
Services Modernization Act (GLBA), requiring protection of personally
identifiable information. Health care institutions must comply with the Health
Insurance Portability and Accountability Act (HIPAA), requiring protection of
patient health information. Retailers and credit card processors must comply
with the Payment Card Industry Data Security Standard (PCI-DSS), requiring
strong protection of cardholder information. US Federal government departments
must comply with the Federal Information Security Management Act (FISMA),
requiring proper safeguards to protect all sensitive data stored in Federal
systems. The list goes on and on, with a large backlog of pending legislation
dealing with data security currently working its way through both the state and
Federal legislation process.
The world of the DBA has permanently changed. While security in
the database was often ignored, or more commonly was left for the firewall and
network team to handle, todays regulatory environment has changed all that.
Inadequate security controls at the database level can now lead to fines,
penalties, loss of business, and in extreme cases even jail time. Organizations
are no longer left to their own devices to ensure the security of their
systems. Today, third-party audit firms police data security under the auspices
of auditing regulatory compliance. There is no longer a choice but to draft and
enforce an effective security program around protecting the confidentiality and
integrity of sensitive data. Database security has entered the limelight.
Lets examine some of the regulations that you are likely to
run into which mandate that you secure your databases.
The Sarbanes-Oxley Act
Sarbanes-Oxley (SOX) is probably the most widely known
regulation governing the protection of corporate data. Also known as the Public
Company Accounting Reform and Investor Protection Act of 2002, SOX requires
that all public companies implement effective internal controls around
financial reporting, and mandates review of those controls by independent
auditors. SOX was passed amidst a storm of corporate disclosure of illegal and
irresponsible accounting practices led by Enron, WorldCom, and Tyco. The fury
over re-establishing investor confidence was overwhelming, and when put to a
vote the bill passed in the Senate 99 to 0 and in the House 423 to 3.
SOX includes several requirements that directly relate to data
security, primarily focused around ensuring the integrity of financial
information that will be reported to the public. SOX makes corporate Chief
Executive Officers (CEOs) and Chief Financial Officers (CFOs) accountable for
the accuracy of financial reports, requiring them to provide personal certification
of each report released. Jail time is stipulated for those executives who
purposefully misstate financial performance. Computer systems that store,
process, and manage financial data are recognized as tightly coupled with the
overall financial reporting process, and are therefore required to be secured.
Typically, organizations implement strong access controls, auditing of access
to financial reporting systems, strict segregation of duties, and a thorough
vulnerability management process in order to comply with SOX and eliminate the
potential for a mistake or attack sending an executive off to the big house.
The Gramm-Leach-Bliley Act
The Gramm-Leach-Bliley Financial Services Modernization Act
(GLBA) passed in November 1999 in an effort to reform rules governing the
financial institutions. The bill repeals the Glass-Steagall Act, allowing banks
to offer investment, commercial banking, and insurance services. GLBA paved the
way for mega-mergers in the financial services industry, including the combination
of Citibank and Travelers Group, forming Citigroup, the largest financial
institution in America.
GLBA includes two key rules which govern the collection,
storage, protection, and disclosure of customers personal financial
information by financial institutions: the Financial
Privacy Rule and the Safeguards Rule. The Safeguards Rule mandates
financial institutions to develop and document an information security plan to
protect clients personal data stored within their systems. The plan must
include a process for performing risk analysis on existing systems and
controls, a process to monitor access to personal information, and a program to
test the effectiveness of the security controls in place. Since nearly all
personal data stored by financial institutions is kept within a database, GLBA
has direct implications on database security.
California Senate Bill 1386
Leading what has become a national charge, in 2003, California passed a bill
requiring companies to disclose any incident where the unencrypted personal
information was, or is, reasonably believed to have been acquired by an
unauthorized person. Since the bill passed, several other states have enacted
similar legislation, and it is only a matter of time before the Federal
government passes a breach disclose bill as well (at the time of this writing,
more than a dozen such Federal bills have been proposed).
The motivations behind California Senate Bill 1386 are clearly
stipulated in the text of the law; privacy and financial security are at risk
because of a significant increase in the incidences of identity theft. The bill
notes a 108 percent year over year increase in identify theft cases in Los Angeles County in 2000. Before the passage of
this bill, it was commonplace for organizations that experienced some kind of
breach to keep it a secret, not even reporting the theft to law enforcement.
Senate Bill 1386 changed all that, leading to what have become regular
disclosures of major data breaches that have made headlines embarrassing
companies and devastating consumer confidence. The threat of disclosure alone
has been enough to force many companies into establishing real programs for
data security, often grounded within the database infrastructure.
The Health Insurance Portability and Accountability Act
Passed in 1996, the Health Insurance Portability and
Accountability Act (HIPAA) is designed to protect workers and their families
from losing their health insurance when they change or lose their jobs. HIPAA
also establishes a set of Administrative Simplification provisions which serve
several functions including creating national standards for electronic health
care transactions and ensuring the security and privacy of Protected Health
Information (PHI). PHI is interpreted as any data about medical records or
health care payment history that can be linked to an individual.
HIPAA compliance requires that organizations implement
administrative, physical, and technical safeguards to ensure the protection of
PHI. Administrative safeguards are a documented set of procedures that
demonstrate the mechanisms by which an organization will comply with the act.
Physical safeguards are a set of controls designed to protect against an
unauthorized person gaining physical access to protected data (for example, by
taking a server or hard disk). Technical safeguards are access controls
intended to ensure that only authorized individuals can gain logical access in
order to view, modify, or delete protected data. This includes protecting data
at rest while stored in a database, as well as data in transit while traversing
The Payment Card Industry Data Security Standard
Before the Payment Card Industry issued their first Data
Security Standard (PCI-DSS) in January 2005, each one of the major credit card companies
had created their own set of standards for how their merchants, issuers, and
acquirers should protect cardholder information. Visa CISP, MasterCard SDP,
Discover DISC, Amex DSOPit was an alphabet soup of standards that were similar
to one another but never the same. For large merchants that accept each type of
card, compliance to the letter of each standard was nearly impossible. In an
effort to simplify compliance and achieve broad acceptance of a single,
well-considered set of standards, the PCI Security Standards Council was
founded by American Express, Discover, JCB, MasterCard, and Visa. This group
has worked together to produce two revisions of the PCI-DSS. The latest
version, 1.1, was approved in September 2006.
The PCI standard is significantly different than the government
standards we have covered so far. PCI-DSS provides specific details on what
steps must be taken in order to properly secure cardholder data. At the top
level there are six categories of controls that must be implemented:
- Build and Maintain a Secure Network
- Protect Cardholder Data
- Maintain a Vulnerability Management Program
- Implement Strong Access Control Measures
- Regularly Monitor and Test Networks
- Maintain an Information Security Policy
The PCI DSS is a multifaceted
security standard that includes requirements for security management, policies,
procedures, network architecture, software design, and other critical
protective measures. This comprehensive standard is intended to help
organizations proactively protect customer account data.
The Federal Information Security Management Act
The Federal Information Security Management Act (FISMA) was
enacted in 2002 as part of the E-Government Act, designed to modernize the
inner workings of the US Federal government. Before FISMA came along,
information security was largely neglected in the government, particularly by
the civilian agencies. The situation was clear; there was little motivation or
budget allocated to cyber security, so Congress intervened in an attempt to
make implementing security controls a mandatory responsibility of government IT
FISMA requires that
any information system used or operated by a US Federal agency, including those
run by contractors and others on behalf of the government, follow a set of
prescribed security processes. These processes are not defined within the FISMA
regulations, but rather FISMA makes reference to other pertinent standards and
legislation, including Federal Information Processing Standards (FIPS)
documents, National Institute of Standard and Technology (NIST) special
publications, HIPAA, and the Privacy Act of 1974.
FISMA mandates that
all Federal information systems be reviewed to determine the types of data
contained within the system, and then categorized based on the damage that
could be caused if the systems confidentiality, integrity, or availability
were to become compromised. There is significant debate as to the effectiveness
of FISMA; however, few will argue the fact that FISMA and its web of related standards
is extremely complex. Minimum security requirements for Federal agencies are
outlined in FIPS 200, which refers to security controls described in NIST SP
800-53 (Recommended Security Controls for Federal Information Systems). NIST
800-53 is further broken down into categories for various types of information
systems, and describes both operations and technical safeguards that must be
implemented for each. It should be no surprise that NIST has created documents
in the 800-53 series that directly address databases and database security.
FISMA is generally evaluated on a departmental level by the Office of the
Inspector General (OIG). This process is referred to as certification and
accreditation (C&A) and includes a review of the controls and processes in
place, and then signoff that the controls and processes meet Federal standards.
Typically, each system must pass the C&A process at least once every three
years or whenever a major change is made to the system, whichever comes first.
Major Data Theft Incidents
Despite the myriad of regulations governing data security, and
a clear increase in focus on security issues in general, there have been a
deluge of successful thefts of data on a vast scale. There have been so many
incidents made public that the Privacy Rights Clearinghouse was established as
a publicly available chronology of data breaches, and a count of the number of
personal records that have been disclosed since February 2005. At the time of
this writing in May 2007, over 150,000,000 records containing sensitive
personal information have been compromised in several hundred incidents. Check
out the latest chronology at www.privacyrights.org/ar/ChronDataBreaches.htm.
The problem is not entirely limited to theft. There have been a
significant number of cases where information was disclosed inadvertently,
often because of an innocent or silly mistake that seemingly lies outside the
realm of data security. There have been far too many cases to cover them all
here, too many even to cover just the really interesting ones, so we have
chosen four incidents to describe in some detail. These examples are intended
to paint a picture of the various ways in which sensitive data has become
compromised in the recent past.
CardSystems Solutions--June 2005
In the spring of 2005, a hacker was able to exploit
vulnerabilities at CardSystems Solutions in order to gain access to their
internal network and retrieve detailed data on approximately 40 million credit
card transactions that the company had stored in a database. CardSystems was an
Atlanta-based credit card processing company, responsible for handling $15
billion dollars in annual transactions on behalf of more then 100,000 small- to
medium-sized businesses. The attack was detected first by a MasterCard fraud
detection system when several likely fraudulent transactions were detected.
MasterCard was able to trace the cardholder information used back to
CardSystems, whom they immediately notified of a possible breach. A short
investigation by CardSystems confirmed that their systems had been hacked.
While the exact details of the attack remain the secret of the credit card
companies, several clues have been disclosed that allow us to piece together
the most likely scenario for how the attack worked.
During September 2004, a hacker found vulnerabilities in an
Internet-facing application that CardSystems customers used to access data. The
attacker was able to gain access to the Web application, likely through an
easily guessed password, and then begin the process of looking for ways to
access the underlying servers and databases directly. The most common method
for using a Web application to gain access to internal databases and other
systems is via Structured Query Language (SQL) injection. The attacker was able
to locate points in the application where weak input validation allowed him to
inject SQL into some forms, and interact directly with the database that housed
the application data. From there, the attacker gained access to the database
servers operating system, likely using database functions to do so, such as xp_cmdshell on MS SQL Server and Sybase.
Since databases generally run with full administrative access on their host
servers, once the attacker could access the OS, they assumed full control. From
there, a script was created on a server in the CardSystems internal network.
The script was designed to search the network for a particular type of file
that contains Credit Card Track Data (the data on the magnetic strip on the
back of your credit cards), and then send that data to the attacker via File
Transfer Protocol (FTP).
In clear violation of the credit card companies data security
rules, CardSystems had been storing files that contained complete track data
for failed transactions. These files were the ones targeted and stolen by the
script. The files contained a complete set of information on each transaction,
including the cardholders name, card number, expiration date, and CVV code.
With this data, the attacker was able to initiate the fraudulent transactions
that led to the attack being detected. Within 60 days of discovering the hack,
Visa declared that they would revoke CardSystems authority to process their transactions.
American Express quickly followed. CardSystems was to pay the ultimate price
for their negligence; they were out of business.
The attack against ChoicePoint was more of a brilliantly
executed con than what most of us think of as a hack. ChoicePoint is a data
aggregator and information broker, collecting, mining, and selling information
on the backgrounds and spending patterns of, well, of everyone. This data is
then sold to insurance companies, loan officers, media companies, law
enforcement, or really any business looking for background checks on potential
employees or customers. The attackers took advantage of ChoicePoints business
model and poor customer screening processes to essentially convince them to
hand over the data.
Attackers set up approximately 50 fake companies, giving them
legitimate names and phone numbers, dreaming up business models, and even
establishing false Tax IDs. They used these companies to open accounts with
ChoicePoint, who were only too happy to sign up a few more customers and start
feeding them data. Over a period of months, these companies requested and
received data on 145,000 adults from ChoicePoint, acting and operating in much
the same way as any of their legit customers. But these folks were not legit
and not interested in targeted marketing campaigns. They were interested in
identity theft, in destroying the finances of others for their own personal
gains. The breach was eventually uncovered, but the exact data collected could
not be determined. This is when things got ugly for ChoicePoint.
Making the mistake of allowing these accounts to be set up was
shameful, and punitive action was certainly unavoidable, but when the
prosecuting attorneys realized that ChoicePoint had no way to determine what
records had been accessed, they went out for blood. ChoicePoint executives were
subpoenaed to testify before Congress, where many difficult questions were
asked about the lack of tracking and user auditing within the sensitive
information systems that the company maintained. The incident cost ChoicePoint
a fortune, kicked off a flurry of legislation governing data mining companies
that collect and sell personal information, and made crystal clear to the
business world that if you are going to store personal information, youd
better take steps to protect it and ensure that you properly track access to
it, and retain the audit logs.
Currently on record as the largest single incident of data
theft of all time, information on nearly 50 million credit card transactions
was disclosed to what appears to be a group of professional computer criminals.
The attack was technically complex, devastatingly effective, and was in place
providing data to the attackers for nearly two years before it was noticed. In
a 2006 research study by the Ponemon Institute, 31 companies that had
experienced a data breach were analyzed, and the cost to the company of each
compromised record was estimated at $182.00. Using that number as a guideline,
TJX could be forced to pay out nearly $9,000,000,000. This staggering figure
does not include the less tangible costs such as loss of business, loss of
productivity, brand damage, or loss of market capitalization. With risks on
this scale, it is hard to believe that companies dont do more to secure their
data. Hopefully, by following the steps in this book, you can help your
organization avoid this ultimate nightmare scenario.
Details of the attack remain somewhat sketchy, but we have a
general timeline of events and a sound theory of what went on. TJX first found
evidence of unauthorized software on their systems on December 18, 2006. They
immediately hired two major consulting firms to perform a detailed analysis of
the incident and provide guidance on how to respond. Within a few days, it was
becoming clear that the software was indeed malicious and that the intruder
responsible continued to have access to critical financial systems within TJXs
network, access that dated back to July 2005. The attack was multi-faceted,
including elements of stealing files, intercepting communications, and breaking
encryption on protected data.
Files stolen contained historical information about payment
card transactions. TJX has not been able to completely identify which files were
stolen, primarily because they periodically delete these files during the
normal course of business. Some of the files that were likely accessed dated
back to 2003, when security rules about protecting cardholder information were
far more lax than they are today. These older files generally contained
clear-text (unencrypted) data, giving the attacker easy access to the credit
Taking the attack to the next level, the attacker was able to
gain access to the network used during the payment card transaction approval
process. During this process, cardholder information, including names, card
numbers, expirations dates, and CVV2 numbers are transmitted to the payment
card issuer without encryption. The intruder was able to watch this approval process
in action, collecting the credit card data as it traversed the network.
The final blow to TJX was the discovery that the attacker had
likely gained access to the software and decryption keys needed to decipher the
card data that had been stored, properly encrypted, in their databases. Even
when the company believed that it had strong security in place to protect their
sensitive data, the attacker was able to find holes in the system and gain full
The methods used to initially penetrate the TJX network have
not been disclosed, however many experts agree that it likely began with the
attacker gaining access to an unprotected wireless network at one of TJXs
retail stores. Sitting in a parked car in the parking lot, the attacker could
have connected to the wireless network and attacked the system used to manage
the stores cash registers. Once that system was breached (probably using a
freeware hacker tool downloaded from the Internet), it became a simple manner
to connect to the central processing systems in TJX headquarters. Corporate
security is often compared to a Tootsie-Pop; hard and crunchy on the outside,
soft and chewy in the middle. The analogy refers to strong security at the
network perimeter, but little to no security inside the network. Once the
hacker found his or her way past TJXs network perimeter, it was game over;
weak internal security controls allowed them to steal everything but the
Department of Veterans Affairs--May 2006
The breach at Veterans Affairs (VA) was an interesting one,
as it demonstrates how a seemingly innocent (but poorly thought through) act
can lead to the biggest inadvertent disclosure of sensitive information in the
history of the US
government. This case involved a break-in and a theft, but not in the way that
you would expect. On May 3, 2006, a VA data analyst who had legitimate access
to the VA information systems took an extract of Veterans names, dates of
birth, and social security numbers. Approximately 27 million records were
written to an external hard disk drive, and left attached to the analysts
laptop. At the end of the day, the laptop left the building, going home with
its rightful owner, with the external disk still attached. This was a clear
violation of VA policies, but no technical controls had been implemented to
either detect or stop this type of behavior.
That evening, the analysts house was broken into by a petty
burglar looking to steal electronics and other small household valuables.
Included among the thiefs booty was a laptop, the very same laptop that came
home from work that day, along with that very important hard disk. The next
morning, the break-in was noticed and the missing laptop reported to the VA.
The data on the laptop was never an issue, but the hard disk was a big deal and
while it seemed clear that the data was never the target of the theft, there
was no way to know what had happened with the data once it was in criminal
hands. A mad FBI search for the laptop began, lasting for about eight weeks
before the missing machine and the all important external disk was found. But
it was too late; the data was out there and there was no way to prove it had
not been accessed or transferred to others (although the FBI did perform a
forensic analysis and found no evidence that the data had been touched).
Everyone affected needed to be informed, credit monitoring
services were contracted to watch for potential identity theft, and the
government took action first requiring the tracking of all data extracts from
systems containing sensitive data, and soon thereafter mandating hard drive
encryption on all mobile PCs. VA also implemented more training and education
programs on data handling policies, but apparently not enough. It was not even
three months later before the VA experienced a similar breach, this time
involving 18,000 records stolen with a laptop that a contractor for Unisys had
taken home for the night.
A Step-by-step Approach to Securing Oracle
This book focuses on a practical, step-by-step approach to
securing Oracle databases. Well define three levels of Oracle security and
provide you guidance on how to determine what level is appropriate for each of
your systems, then explain exactly how to get yourself from where you are today
to the right level for you. Well take things a step or two beyond just helping
you secure your Oracle databases. We will build a mechanism for tracking your
progress, establishing a plan and then demonstrating continuous improvement. We
will also create a system to measure and prove the security of your systems to
both internal and external compliance officers and auditors, giving you the
option of using a checklist and a set of scripts, or automating the process
with commercially available tools. Your journey to secure Oracle databases
Tools & Traps...
One Size Fits All Doesnt Fit Most
Weve seen quite a few companies try to start a comprehensive
database security program only to end up nowhere but frustrated. The most
common reason for their failure: establishing a one size fits all approach to
securing their systems. The database environment within a typical enterprise is
extremely diverse, and different systems have different needs. This makes it
next to impossible to create one overarching set of standards to which every
system must comply. The one size fits all approach can fail in several
different ways, but the end result is always the same: no real database
security program, and an easy target for any hacker who cares to attack.
The first step in the security program is to establish a plan
and a set of guidelines, which is a common point of failure. Some companies
will establish a working group in order to build a set of security and
configuration guidelines. Problems often arise when the members of the working
group, who often represent different functional business areas, are unable to
come to agreement on common standards. In the most severe cases, this leads to
the database security effort being abandoned before it really begins, leaving
each administrator to decide on their own if and how they will protect their
data. More commonly, working groups establish a watered down set of standards,
leaving plenty of room for the exceptions required by each business area, but
also leaving a knowledgeable attacker with open doors into the systems.
Once a set of standards have been established, they are often
passed to the database administration teams with little or no guidance on how
to implement the requirements. The issue is not that the DBAs dont know how to
configure the security settings; they know the databases better then anyone
else. The problem lies in prioritization and workload. In organizations with
dozens, hundreds, or thousands of databases, the task of implementing a
security standard enterprise-wide can easily be overwhelming. When open
questions are left about which systems to secure first, or how far to go with
each system before moving on, efforts often fizzle out after tightly locking
down a small handful of randomly chosen databases. Hackers will use automated
tools to search for weaknesses across any database they can access; securing
only a few is almost like securing none at all.
With a set of security configuration standards that explain how
to secure each database based on business value and risk, and a clear plan that
sets out a priority order in which to secure the databases, an enterprise can
be extremely successful in implementing database security across the
organization. This book will help you build that plan for your Oracle
databases, but the lessons learned can easily be translated to secure any
Appropriate Security For Each Class of Database System
To get started, you will need to assign each of the databases
you are responsible for a priority rating based primarily on its business
value. This activity should not be performed in a vacuum. Rather you should get
together with other stakeholders within your organization, folks such as the
database administrators, IT security engineers, application owners, business
line managers, and internal auditors to review and assign each system a
business value rating. It is often easiest to use a set of categories rather
than come up with an absolute priority list. Try using three categories, such
- Business Critical
- Databases that must be running in order for a business to
run. For example, databases running online retail shops, stock trading systems,
or critical infrastructure systems.
- Databases that contain data that if stolen could cause
irreparable harm to the business. For example, databases containing credit card
transaction data, corporate secrets, or sensitive personal information on
customers or employees.
- Databases that require protection in order to achieve
regulatory compliance. For example, databases containing financial reporting
data for SOX, personal health information for HIPAA, or credit card numbers for
- Business Impact
- Databases supporting business operations. For example,
databases hosting HR systems, inventory management systems, or customer support
- Databases supporting business intelligence and long-term
decision-making. For example, databases containing historical financial data or
- Everything Else
- Databases that do not contain sensitive data.
- Databases that are not required to support day-to-day
- Development, QA, and test databases (not backup or
disaster recovery systems; those belong in the same category as the primary
systems they safeguard).
Once your databases have been assigned to categories, you can
make smart decisions about which to secure first and how far to go in securing
each one. Your most critical systems will get the highest level of security,
while the least critical systems get the lowest level. This way, each database
gets only the security features that it requires, eliminating the excess
workload caused by forcing every database to be secured to the same standard of
protection. Like a system of building blocks, each category takes over where
the last leaves off, building a foundation of security and then expanding it to
the needs of the system it is protecting. This allows you to quickly establish
a baseline level of security on every database, preventing the vast majority of
simple attacks and lowering business risk, then moving on to conquer more
complex issues with more rigorous security standards on only the most sensitive
It is not enough to secure your databases; you have to prove
it. Achieving compliance with anything from government regulations to internal
security standards means providing evidence that you have taken the proper
steps to secure your system. To enable you to demonstrate and communicate your
Oracle security to whomever you must report to, each level includes a systematic
approach to maintaining and assessing compliance. This includes references to
checklists, scripts, and tools you can use to automate the assessment and
With a solid understanding of the history and evolution of
security features in Oracle, we hope that you can understand how the many
different security controls came to be and why they were added to the system.
Government and Industry regulations have been established to govern the
handling of sensitive personal and financial information, forcing companies to
comply or face significant punitive actions. Even with increasing pressure to
secure systems, major organizations have experienced high profile breaches,
with costs as high as going out of business. Hacking is a type of theft that
companies must target with real investments in people, process, and technology.
This book gives you a prescription to secure a single database,
or to build an enterprise-wide strategy to lock down your critical Oracle
database systems and tightly integrate your database security strategy with
your corporate security infrastructure. By establishing a strong Oracle
security program, you can play a lead role in ensuring your business meets
regulatory requirements, properly protects corporate secrets, and acts as a
good custodian of the sensitive personal and financial information that you
Solutions Fast Track
A Brief History of Security Features in Oracle
- At first, Oracle had
only the most basic security features. However, security was a consideration
from day one.
- Over time, Oracle evolved to add a
slew of basic protections. These included authentication and password
management, authorization and access controls, networking, and network
- Recently, Oracle has added a number
of security products to apply to the database to achieve levels of security
The Regulatory Environment Driving Database Security
- After several incidents of misuse of
personal information and of companies misleading investors with falsified financial
information, governments have taken a stand and enacted legislation requiring
companies to protect sensitive data that they collect and store.
- The commercial marketplace has taken
steps on its own to regulate and protect sensitive data. Leading the charge is
the PCI-DSS, demanding that merchants and banks take seriously the
responsibility to protect credit card information
- Organizations that do not comply
with the regulations that govern them are severely penalized. The risk of major
fines and even jail time is enough to force organizations into compliance.
Major Data Theft Incidents
- Data theft has become a serious
problem, with professional criminal rings turning to hacking as the next front
for their enterprises.
- Large and prestigious institutions
have been hacked, leaking tremendous amounts of data about customers, patients,
employees, students, and everyone else. Mandatory disclosure of these incidents
has led to great embarrassment and loss of business.
- CardSystems, ChoicePoint, TJX, and
Veterans Affairs all experienced major data theft incidents. Each one was
different, from sophisticated computer crime at TJX to a dumb mistake and a
house burglar at VA. The methods are less important than the results. Companies
that dont protect their data can and do lose their data.
A Step-by-step Guide to Securing Oracle
- Oracle security can be defined in
various levels, with appropriate levels of security defined for each class of
systems. Databases are classified based on business value and then security
controls are mapped on to suit the business need.
- Build a security plan from the
ground up, applying a base set of security controls to every database, and then
expanding on those controls for the more sensitive and business critical
- A system of measurements provides
proof that each system has been secured and meets the requirements put forth by
anything from government regulations to internal security configuration
guidelines and standards.
Frequently Asked Questions
Q: What is the top
Oracle security issue you see out there today?
A: By far, it is
default accounts with default passwords enabled in the database. Read more
about that in Chapter 4.
Q: Ive been a DBA for 20 years. Why am I only
now being asked to secure my databases?
A: The world has changed. The bad guys have
pulled off some pretty significant crimes, so the good guys have put controls
in place to try and stop the attackers. Today, your business is faced with
increasing regulatory pressure to secure your critical data, while at the same
time there are more hackers than ever trying to get at it.
Q: My database is behind a firewall in a secure
network, am I protected?
A: Not a chance. Today, most of the bad guys
operate from inside your network. More then 70 percent of attacks involve an
insider. Also, that firewall is full of holes, designed to allow applications
to function. Attackers have found ways to exploit vulnerable applications to
gain direct access to the databases.
How much work is involved in securing an Oracle database?
A: Every database is different. Depending on the
sensitivity of the data, the environment it operates in, and several other
factors, the answer can be anything from an hour to a couple of weeks. The
important thing is to take the task step-by-step, eliminating the most critical
issues first and making real progress from the beginning. Security is never
complete and no system is unbreakable, however, we can build significant
defenses so that the effort to break in far outweighs any potential payoff to
Practical Oracle Security
By Josh Shaul, Aaron Ingram
Published by Elsevier
Published: Nov. 12, 2007
Dimensions 7 1/2 X 9 1/4 in
Buy this book