Implementing Database Security and Auditing
A guide for DBAs, information security administrators and auditors
By Ron Ben Natan
Copyright © 2005 Elsevier Inc.
All right reserved.
Chapter One Getting Started
This book is about database security and auditing. By reading it you will learn many methods and techniques that will be helpful in securing, monitoring, and auditing database environments. The book covers diverse topics that include all aspects of database security and auditing, including network security for databases, authentication and authorization issues, links and replication, database Trojans, and more. You will also learn of vulnerabilities and attacks that exist within various database environments or that have been used to attack databases (and that have since been fixed). These will often be explained to an "internals" level. Many sections outline the "anatomy of an attack" before delving into the details of how to combat such an attack. Equally important, you will learn about the database auditing landscape—both from a business and regulatory requirements perspective as well as from a technical implementation perspective.
This book is written in a way that will be useful to you—the database administrator and/or security administrator—regardless of the precise database vendor (or vendors) that you are using within your organization. This is not to say that the book is theoretical. It is a practical handbook that describes issues you should address when implementing database security and auditing. As such, it has many examples that pertain to Oracle, SQL Server, DB2, Sybase, and sometimes even MySQL. However, because detailing every single example for every database platform would have meant a 2,000-page book, many of the examples are given for a single database or a couple of them. The good news is that all techniques (or almost all of them) are relevant to all database platforms, and I urge you to read through all sections even if the example code snippets are taken from a database environment that you are not running. In all of these cases, it will be easy for you to identify the equivalent setting or procedure within your own environment.
More important, many of the techniques you will see in this book will never be described in a manual or a book that is devoted to a certain database product. As you'll learn throughout this book, good database security cannot always be implemented solely within the database, and many of the most serious security issues that you may face as the database owner (or the server owner) have to do with the way applications use a database and the way various interacting systems are configured. Addressing these complex issues must take into account more than just the database, and focusing on capabilities that are provided only by the database vendor is not always enough.
At this point you may be asking yourself a few questions:
* Doesn't the database have many security and auditing features? Isn't a database merely a file system with a set of value-added services such as transaction management and security? Isn't my database secure?
* Why now? The database has been part of the IT environment for many years (relational databases for at least 20 years); why should we suddenly be overly concerned with security and auditing?
The answer to the first set of questions is that while such features exist, they are not always used and are not always used correctly. Security issues are often a matter of misconfiguration, and the fact that the database implements a rich security model does not mean that it is being used or that it is being used correctly. If you are like 90% of database administrators or security administrators, you are probably aware that your database has big gaping holes—disasters waiting to happen. In fact, here are some examples that made the headlines (and rest assured that for every incident that makes headlines there are 100 that are kept quiet):
* In early 2000, the online music retailer CD Universe was compromised by a hacker known as "Maxus." The hacker stole credit card numbers from the retailer's database and tried to extort money from the retailer. When his demands were refused, he posted thousands of customers' credit card details to the Internet. (Go to http://data bases.about.com/gi/dynamic/offsite.htm?site=http:// www.pc%2Dradio.com/maxus.htm to see what Maxus' Web site looked like.)
* In December 2000, the online retailer Egghead.com announced that its customer database may have been compromised and warned that more than 3.5 million credit card numbers may have been stolen. Egghead.com later announced that the credit cards were not compromised but the investigation cost millions and few customers were willing to continue to do business with the retailer. The company went out of business shortly thereafter.
* In 2001, Bibliofind, a division of Amazon.com that specialized in rare and out-of-print books, was attacked and details for almost 100,000 credit cards were stolen. Even worse, the attackers maintained free access to the database for four months before being discovered! As a result, Bibliofind stopped offering buy/sell services and ended up as a matching service only (i.e., had to forgo a large portion of its revenues).
* In March 2001, the FBI reported that almost 50 bank and retail Web sites were attacked and compromised by Russian and Ukrainian hackers.
* In November 2001, Playboy.com was attacked and credit card information was stolen. In fact, the hackers sent e-mails to customers that displayed the credit card information.
* In the course of 2001, Indiana University was successfully attacked twice and private information, such as social security numbers and addresses, was stolen.
* A study conducted by Evans Data (a market research firm) in 2002 sampled 750 companies and reported that 10% of databases had a security incident in 2001! More than 40% of banking and financial services companies reported "incidents of unauthorized access and data corruption" and 18% of medical/healthcare firms reported similar types of incidents.
* In Oct. 2004 a hacker compromised a database containing sensitive information on more than 1.4 million California residents. The breach occurred on Aug 1 but was not detected until the end of the month. The database in question contained the names, addresses, Social Security numbers, and dates of birth of caregivers and care recipients participating in California's In-Home Supportive Services (IHSS) program since 2001. The data was being used in a UC Berkeley study of the effect of wages on in-home care and was obtained with authorization from the California Department of Social Services. The hacker had reportedly taken advantage of an unpatched system and while officials declined to state which vendor's database was the subject of the attack they did report that it was a "commercially available product with a known vulnerability that was exploited."
* In Jan 2005 the following was reported by Security Focus (http:// www.securityfocus.com/news/10271):
A sophisticated computer hacker had access to servers at wireless giant T-Mobile for at least a year, which he used to monitor U.S. Secret Service e-mail, obtain customers' passwords and Social Security numbers, and download candid photos taken by Sidekick users, including Hollywood celebrities, SecurityFocus has learned ... by late July [of 2004] the company had confirmed that the offer was genuine: a hacker had indeed breached their customer database
The answer to the second set of questions—why now?—is a convergence of several factors—almost a "perfect storm." True, the database has been around for a long time, but the following trends are dominating the last few years:
* E-commerce and e-business
* New and wonderful ways to use databases
* Increased awareness among the hacker community
* Widespread regulations that pertain to IT and to security
E-commerce and e-business have changed the way we live. We buy from online retailers, we pay our utility bills using online banking sites, and more. Businesses have optimized their supply chains and use Customer Relationship Management (CRM) software to manage relationships with their clients. In doing so, systems have become much "closer" to each other and much "closer" to the end users. Sure, we use firewalls to secure our networks and we don't connect databases directly to the Internet, but you'll see in Chapter 5 that there is more than one way to skin a cat and that databases are far more exposed than they used to be. Ten years ago the database was accessed by applications that were only available to internal employees. Now it is (indirectly through the application) accessed by anyone who has access to the Web site (i.e., everyone in the world).
While e-commerce has certainly added many indirect users on the database, e-business has had a much bigger impact on security (or the lack of it). Doing efficient business with suppliers, customers, and employees has created new and wonderful ways in which the database is used and innovative ways in which it is configured. Opening up the enterprise to improve processes and streamline business was done quickly and without too much analysis of security implications. Databases are deployed in many places (physically and logically) and often with no significant protective layers.
New technologies are constantly being released by the vendors. These technologies include Web services within the database, XML handling within the database, tight integration with application servers, and the ability to run any application logic directly within the database (to the extent of having an embedded Java virtual machine inside the database). This is great for developers and for increasing productivity, but it creates a security nightmare. More functionality means more (actually, many more) bugs that can be exploited by hackers, and many of the leading vendor databases have been plagued with bug-related vulnerabilities. Even if new functions have no vulnerability, these features are usually risky because they open up the database to more types of attacks. They increase not only the developer's productivity but also the hacker's productivity.
While we're discussing hacker skills and effectiveness, let's move on to hacker awareness. Hackers are always looking for new targets for their attacks and new methods they can use. In the same way that you realize that databases hold the crown jewels, so do the hackers. Furthermore, after mastering attacks on networks and operating systems, hackers have turned to applications and databases as new breeding ground. This is very visible in hacker forums. It is interesting, for example, to track hacker conferences such as BlackHat and Defcon. In 2001, both BlackHat and Defcon had one presentation each devoted to database hacking. In 2002, BlackHat had five such presentations and Defcon had four such presentations. In 2003, BlackHat already had a full track dedicated to database hacking.
Last, but by no means least, is regulation. Bad accounting practices, fraud, and various corporate scandals/crimes have prompted regulators to define and enforce new regulations that have a direct impact on IT auditing. Because financial, personal, and sensitive data is stored within databases, these requirements usually imply database auditing requirements. Because regulations such as Sarbanes-Oxley, GLBA, and HIPAA (all discussed in Chapter 11) have financial and criminal penalties associated with noncompliance, database security and auditing have suddenly come to the forefront.
Excerpted from Implementing Database Security and Auditing by Ron Ben Natan Copyright © 2005 by Elsevier Inc.. Excerpted by permission of DIGITAL PRESS. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.