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