Home

In the News

Virus Report

Subscribe Now Online

Media Kit

Archives

Contacts

Calendar of Events

Articles

Article Submissions

Web Seminars

White Papers

Inside Current Issue

February 2006 Issue

Inside Current Issue: Cover Story

Protecting Identity Information at the Source
By Ron Ben Natan

Identity theft is not a new ailment of the global economy. Federal Trade Commission (FTC) data from Sept. 2003 shows that almost one in every eight U.S. adults has experienced identity theft, and the total cost of identity theft in 2002 was $50 billion. The Identity Theft Resource Center states each stolen identity results in an average of $17,000 in fraudulent charges or losses. Identity theft has become the fastest-growing type of fraud in the UK costing over £1.3 billion per year. Even more alarming is that identity theft is probably understated because many victims never report the crime.

Given that identity theft places such a burden on the economy, it is not surprising that companies invest in both physical and information technology security aimed at better protecting private, confidential and personal information. Unfortunately, the number of incidents involving data breaches shows the situation is only getting worse.

Identity 911
A great Web site for recent incidents, www.identitytheft911.com, highlights well-known examples including:

1 Jan 2005 -- A breach of T-Mobile’s customer database, in which the hacker had access to information about 16.3 million customers for more than a year before his arrest. The arrest was a result of a message he posted to an online marketplace frequented by identity thieves, not because the access itself was detected.
2 June 2005 -- The Federal Deposit Insurance Corporation notified approximately 6,000 current and former employees that files containing their personal information had been improperly accessed and fraudulent loans were obtained using some of this data.
3 June 2005 -- A hacker gained access to more than 40 million Visa and MasterCard credit card accounts at a third party payment card processor, including information on card holder names, card numbers and security codes.

A key reason for the increase in data theft is the imbalance between the level of comprehensiveness and sophistication with which we run our businesses versus the level of comprehensiveness and sophistication with which we protect the way we run our businesses.

One example involves database management systems (DBMS). Today’s DBMS can do almost anything. They run virtual machines (e.g. Java within the database), offer up Web services, link heterogeneous distributed repositories into one virtual store, create huge repositories of data on every person, and mine that information in any way the user desires. Database security has also advanced, but not at the same rate. Moreover, the introduction of so many features and services brings new vulnerabilities and potential for misuse.

Even more pronounced is the imbalance in knowledge, skills, manpower and processes. We all have operations groups that include DBAs, and care about data security, but ask yourself (and try to answer in all fairness):
1 What percentage of your average DBA’s time is devoted to data security?
2 What checks and balances do you have to protect data from the DBAs themselves?
3 How much does the average information security professional know about databases and can he address the complexity of modern data management and security?

Here Comes the Cavalry
This imbalance is not surprising; it is a natural byproduct of human nature. We like to create and produce, and make money in the process. Security does nothing of the sort. It seems intuitive that you prefer to invest a dollar in improving operations to generate more revenues rather than invest a dollar in improving security. This approach is naïve. Security is a cost of doing business and everything can be lost if not enough is invested in it.

Fear not … help is on the way in the form of regulation. Sure, regulation is a pain, but it forces executives to allocate funds to improve security and put in place process and technology. Drawing from the database world, we always knew we needed a good audit trail for DBA and privileged access database, but we’ve had databases for over 20 years and it wasn’t until Sarbanes Oxley that we started to implement these trails.

While there are several regulations relevant to identity theft, two are critical (and perhaps less well-known than HIPAA, GLBA and California SB1386). The first is the proposed Personal Data Privacy and Security Act of 2005. The second is the Payment Card Industry (PCI) Data Security Standard.

The Personal Data Privacy and Security Act of 2005
Senators Arlen Specter and Patrick Leahy introduced the Personal Data Privacy and Security Act of 2005 to help better protect the privacy of personal information. Motivated in part by serious data breaches at ChoicePoint and LexisNexis, Leahy commented: “Insecure databases have become low-hanging fruit for hackers looking to steal identities and commit fraud during a time when we are seeing a troubling rise in organized rings that target personal data to sell in online, virtual bazaars.”

Several sections of the Personal Data Privacy and Security Act address data breaches and database protection:
- Companies that have databases with personal information on more than 10,000 Americans must establish data privacy and security programs. The program must ensure security and confidentiality of personal electronic records and protect against unauthorized access and use of personally identifiable information.
- Companies must notify law enforcement, consumers and credit reporting agencies when digitized sensitive personal information has been compromised.
- The act defines tough monetary penalties for failing to provide privacy and security protection and notices of breaches. For example, businesses violating Section 402 are subject to penalties up to $5,000 per violation per day with a maximum of $35,000 per day while such violations persist, and penalties up to $5,000 per violation per day with a maximum of $55,000 per day for violations of Sections 421 through 425 (sections related to notices).

Here’s an ironic data breach example: In early 2005, Bank of America reported it lost computer data tapes containing personal information on an estimated 1.2 million federal employees. The tapes contained data on customers and accounts of the federal government’s SmartPay charge card program which “disappeared during shipment to a backup data center.”They also included information regarding various senators – including Senator Leahy from the Personal Data Privacy and Security Act.

Payment Card Industry
As noted by the FTC, credit card and bank fraud accounted for almost 60 percent of all identity theft claims in 2002. The few examples listed earlier should further convince you that credit card data is a treasure coveted by criminals. PCI spearheads the payment card industry’s battle against these criminals.

The PCI Data Security Standard was jointly developed by leading credit card industry players including VISA, Mastercard and American Express. As a standard, PCI replaces the various vendor-specific programs such as VISA’s Cardholder Information Security Program (CISP) and Mastercard’s Site Data Protection (SDP) Program.

PCI is very comprehensive in terms of who it affects and what it requires. It applies to all members, merchants and service providers that store, process or transmit cardholder data. The security requirements apply to all “system components” defined as any network component, server, or application included in, or connected to, the cardholder data environment. For service providers and merchants required to undergo an annual onsite review, compliance validation must be performed on all components where cardholder data is processed, stored or transmitted, unless otherwise specified.

The Ultimate Treasure Chest
Addressing identity theft requires investment in many security disciplines. It can involve physical security, recycling documents and reports, and encrypting backup media. It requires investment in technology, process, training, etc. Above all, it requires an awareness that is now starting to form.

As part of a full data security program, database security and auditing must hold a prominent place. Databases concentrate private, confidential and personal information. Almost all data involving social security numbers, credit card numbers, names and addresses lives inside databases -- and usually within relational DBMS developed by vendors such as Oracle, IBM (DB2), Microsoft (SQL Server) and Sybase. Therefore, databases are the ultimate jackpot for hackers. Databases concentrate data, and therefore concentrate risk.

A database is a very complex piece of software. Relational databases all “talk” a language called the structured query language (SQL). Database security cannot be addressed at any level that does not include full understanding of SQL. Modern databases further extend SQL and support XML, Web services and interfaces to the operating system. In making databases more and more functional, vendors have created huge programs that have an extremely large number of options -- all of which need to be well understood and secured to avoid breaches. This complexity, along with the importance of the data residing within, should drive investment in database security as part of any security program.

While database security implementations include different activities, all should include the following:

1 Hardening -- To limit the entry points a hacker can use or various lax default configuration options.
2 Assessing -- Database should be continuously scanned and assessed to ensure that known vulnerabilities have been addressed and verify that the database and applications accessing the data conform to best practices and do not inherently employ a weak security model.
3 Classifying -- Databases usually include tens of schemas and hundreds if not thousands of tables (the structures that house the data) and procedures. Not all data is equivalent; you must classify data in terms of sensitivity level. You should also define classes of access. For example, users and applications that access data are different from applications that modify or delete data and these are different from privileged users that modify replication procedures and stored procedures (through which database Trojans can be injected). Good data classification will ensure you invest enough where it is important.
4 Monitoring -- Monitoring database access is often one of the most overlooked areas in data security. Many data breaches take weeks, months and sometimes even years to discover; and the discovery is often related to some lucky event caused by hacker greed or arrogance.
5 Auditing -- Database auditing is getting attention as part of SOX, but is becoming even more important for privacy. Separation of duties is crucial, meaning that the audit trails cannot be maintained within the database (because DBAs can modify these records) and the audit trails cannot rely on database definitions that the DBA can modify.
6 Enforcing -- Enforcing a good security policy and preventing rogue access is the end-game. Once you close unnecessary doors, monitor and fix misuse and classify data, you should implement an active security policy that prevents theft and misuse. A proactive strategy could also include deploying an SQL intelligent database firewall to prevent intrusive access that violates these security policies. This type of approach will allow you to automate most of the work and invest only in anomalies, thus requiring less work from your staff.
7 Encrypting -- You need to understand where your sensitive data resides and whether you should invest in encryption. Encryption of data-at-rest can involve encrypting the data inside database tables or data files on disk (or on backup tapes). Each protect from different things. For example, encrypting data files themselves protect you when someone steals the disk (or when you lose backup tapes), but will not help you when an insider misuses access to the database (although that can be addressed through good monitoring and anomaly detection).

While you will not always be comprehensive in all these classes you should be able to explain to yourself (and maybe to your auditors) why you choose not to invest in a certain category.

About the Author:
Ron Ben Natan is CTO at Guardium (www.guardium.com), a provider of database security and auditing.

Go Back

© IMPIRE Communications, LLC All Rights Reserved.  

Website designed & managed by Oculus Networks