The use of database systems to manage financial information is a common practice in today's accounting profession. Using database systems is an efficient and effective way to manage and store all sorts of information, from birth dates to sales figures to account balances.While the benefits of using a database system are numerous, people rightly wonder about the potential risk of using such systems to contain sensitive financial information. In the same way that a database can make your job more efficient, it can also make an attacker's job easier - by providing a wealth of sensitive information in one place.

LOSING CONTROL

In the past, a compromised system might put groups of transactions or narrow sets of data at risk. Today, however, our globally interconnected systems can give an attacker access to millions of records that contain a goldmine of information. Considering the amount and value of information held within financial databases, such as Social Security and account numbers, attackers can do serious damage if they are able to tap into this resource.

While there are a variety of environmental factors that drive information security, such as contractual obligations, regulation requirements and even risk to the brand, there are proactive measures that organizations should take to protect such sensitive information.

The first step in protecting information - or any asset, for that matter - is developing an understanding of how a compromise takes place. Fundamentally, it occurs when a vulnerability in the system is exploited. A vulnerability is nothing more than an "unintended feature," one that allows some behavior contrary to the intention of the system or the data owner.

Here's a look at three common mistakes in security, and how the database comes into play, particularly how system design allows for the undesirable, and ways that organizations can change the database to effectively disable a feature that makes the system vulnerable to attack.

DIRECT DATABASE ATTACKS

Many database systems are network-enabled, allowing remote servers to connect to them. To protect the information sitting in the database from unauthorized use, a username and password are typically assigned and required to access the system. This session authentication is an important control, and can generally prevent one user from impersonating another or random outsiders from logging into the database.

Nevertheless, this control itself isn't sufficient to keep the data safe against attacks against the authentication mechanism itself. Attackers can write programs that try every word in the dictionary as a password, along with every common username, in "brute force" attacks. Theoretically, at least, it's only a matter of time before those accounts are compromised and the attacker has access to the database.

Another possible attack would exploit a vulnerability already present in the database server software before successful authentication has taken place. The 2003 SQL Slammer worm, which denied Internet hosts and severely slowed Internet traffic, is a very successful example of such an attack.

Generally speaking, such database systems will take queries from a set of known and trusted hosts. A network firewall - whether as a separate device, as I generally recommend, or a layer of software on the protected system - will remotely control access and allow only known and authorized machines to connect to the network and log in to the system.

LOST MEDIA

News reports of companies and government agencies losing personal information have become commonplace. It's hard to go for any significant length of time without hearing that some new loss has taken place. While most of the reports come from a loss of control over data on laptops, some come from back-up media that have been lost, typically in transit to secured off-site storage facilities.

The problem arises when we consider what happens if someone finds the lost media. Any tapes or optical media being used for the back-up will be relatively easy to read. Thus, unless your organization is using one-of-a-kind hardware for data storage (almost certainly a bad idea for other reasons), the remaining option is to make the data unusable to an illegitimate user even if it's read.

Encryption of the data is the best mechanism to handle this situation. Encryption is the process of combining data ("plaintext," also sometimes called "cleartext") with a small set of secret data ("key") with an algorithm to produce ciphertext (or, colloquially, "encrypted data"). In this way, data written to a disk, tape or other medium can be stored without fear that it will be compromised, even if the medium is intercepted. This assumes, of course, that a good algorithm and key size are chosen, and that the key itself has not been compromised.

Database back-ups are typically made with dumps (as opposed to extracts). Since the database itself is storing ciphertext, the database dumps will also include ciphertext, and are therefore unreadable to an attacker. Any "back-up" made by extracting the data through the application in such a way that plaintext is presented will, of course, still be readable by an attacker and therefore not properly secured.

So applications sitting atop databases are also very important to consider.

APPLICATION BUGS

In many cases, software using the data will naturally need to handle the plaintext versions of whatever sensitive information is being managed. A common strategy for tying applications to databases is simply to require a username and a password for the application to authenticate itself to the database before use.

This type of defense offers protection when the attacker connects directly to the database server and uses raw SQL code to select all of the desired data out of the database. Simply put, the code won't run unless the attacker provides a valid username and password combination.

In this sort of environment, the application itself is exclusively responsible for policy enforcement. Just as a database server directly exposed to the Internet is one bug away from disaster, an application solely responsible for the protection of the database from the outside world is dangerous. At the very least, the application should have an understanding of how to separate user-supplied data from its own to avoid an attacker making clever use of input to have the application execute the attack against the database server.

The use of databases has changed the economics of attacks: For roughly the same work needed to break into any system, an attacker can get a large cache of data with potentially sensitive information. For this reason, attackers looking to obtain information have concentrated on databases and the applications that sit atop them. Databases containing financial information are particularly attractive for attackers, considering the power that this information can provide.

The most effective defenses will use various available methods, such as a database server behind a firewall, encryption of sensitive data, or granular access to the data from the application based on the rights of the user logged into the application. By understanding the mechanisms of common attacks, information architects and database administrators can build in the appropriate defenses to ensure that the data in their trust remain safe.

Matt Curtin is the founder of Interhack Corp, a professional services firm with practices in information assurance and forensic computing, and the author of Brute Force: Cracking the Data Encryption Standard (Copernicus Books, 2005).

Register or login for access to this item and much more

All Accounting Today content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access