Architecting for Data Security

Let' Face It: We design our systems to make it easy for users to access information. And we pay much more attention to simplifying access than to ensuring that only authorized users have it.

But companies are now waking up to the fact that the value of their business is inextricably tied to the information in their core systems. And that information can leak out of core systems in much the same way water can leak out of a water heater with a two-inch hole. That is to say, quickly and in large volumes.

An information security or IT administration employee, therefore, must protect the corporate information jewels while not inhibiting access. IT has always had to balance security with usability, but typically hasn't paid much attention to which authorized users could see what information. Yet, in most organizations, most users (authorized or unauthorized) see far more data than they should.So what can you do to protect sensitive data, ensuring that only authorized users can see it? A lot.

Encryption

First, encrypt selected fields--such as those containing credit-card information--in your databases. Yes, this will slow database performance somewhat, but modern encryption/decryption technologies are getting faster, and today's databases can take advantage of your multicore server CPUs to handle these tasks. With few exceptions your servers are running at between 0 percent and 15 percent CPU usage.

With that amount of processor headroom, one could assume there's enough capacity to encrypt the entire database, but we recommend against it since encryption eats up processor headroom very quickly. Encrypted data takes up more space in the database and requires more decryption/encryption work to extract or insert data.

When deciding to encrypt entire tables, there are several factors to consider. If you encrypt the entire database, the number of encryption keys per table should be exactly one--unless you reuse keys across tables, reducing the number of keys you must manage. This is setup appealing, since, depending upon how frequently you rotate keys and how long you have to keep data, your key repository could be massive. Unfortunately, though, reusing keys also reduces overall security, giving an attacker more opportunity to get the "golden key"--the one that grants access to all information in a database or even to all data stores.

You can also choose to encrypt just columns instead of an entire table. But there is still no silver bullet for indexing databases with encrypted columns that you want as index keys--and if you choose to encrypt columns, each one should have a unique key, which increases security but adds more key management. Some solutions will let you use encrypted columns as indices, but the decryption of primary columns to update the index is painfully slow, and that doesn't begin to touch on how difficult debugging can be when all the data in a dataset is encrypted. You can encrypt all data in every row, but the cost isn't worth the return--who cares if an attacker can see that the customer is male, for instance? Some vendors have concocted workarounds (such as those that compress data before encryping), but the number of indices will increase as the system is used over time, meaning it's likely that eventually you'll need an index based on an already encrypted column. At that point the workarounds we are aware of all fall apart.

Database Logging, Extrusion Prevention

One problem most organizations have--and one that too few know about--is that data exists all over the network, and some of it escapes the view of administrators. From rogue SQL Server installs to Excel spreadsheets full of customer data, your company's information is scattered across your enterprise.

At a minimum, database logging can help you track it all. By recording who has accessed what data, you can try to correlate when data is being extracted to find rogue systems or employees who are accessing data they don't need. Database logging is entry-level in the sense that such functionality is included in every database product, but it doesn't try to evaluate what is going on--it only gives you the raw facts, in large volumes.Beyond logging are third-party log-analysis tools that attempt to interpret some of the results to give you a picture of what co-related queries are being posed. There are also rogue-database-detection tools that provide a picture of all the databases using standard communications mechanisms within an organization. Finally come database-extrusion-detection tools, the king of this class of products, which let administrators set policies on who can do what and alert admins when abnormal behavior occurs with a given account.

Some products in this last group can even be configured to stop a query from returning data sets. These are not policies, such as "user X has rights to column Y." Rather, they let you drill down to the level of "user X has rights to column Y for all rows where column Z has value AA"--thereby restricting access to only the data a user should be seeing to do his job. Of course, you could set restrictions too high and keep him from getting his work done (maybe he has a new assignment and needs more information). If this concern is larger than the litigation risk of a data leak, you can always set the product to notify you of the breach instead having it stop the transaction.

The Power Of The Network

Security functionality is increasingly being built into network devices. And it makes sense that the products seeing your traffic can control some transmissions.

You can put your databases on a subnet or virtual LAN, allowing connections only from those on the same VLAN. You'll need to do some careful architecting to make your Web servers visible to the outside world on one side and on the VLAN on the other. Of course, taking these steps will lock things down tightly--so tight that you'll have to maintain constant vigilance to ensure continued access for all the users that must be able to modify the database or its environment.You also can use a network IPS (intrusion-prevention system) to detect malicious streams before they can gain entry to the network. Since other portions of your security architecture will benefit from an IPS, implementing one makes a lot of sense. Clearly, however, a network IPS won't directly protect your data, nor guard against a misguided or mischievous employee, but it will indirectly protect data by protecting the network of machines that have direct access to that data. While not as directly related, host IPS can offer protection to the machines connected to that same network--a different level of protection--and thus is worth considering also.

So let's say we've restricted access to a particular table--"customer"--to only the users who have a valid reason to see such data. There's still the question of what rights they have and how you manage for abuse. If the sales manager has access to the entire customer database and someone learns his login, how do you stop that person from taking all the data out of the database? There are tools available to minimize potential damage, but there's no tool on the market mature enough to stop this type of attack entirely. And though vendors are hard at work developing solutions--such as limiting the number of rows a query can return, or profiling a given user's "normal" behavior and disallowing anything egregiously outside the bounds of normal--a solid solution to this problem is a ways off. We need to be able to set policies of acceptable use and, in the end, employees must have nearly unfettered access to the data that lets them do their jobs.

So the problem isn't so much data protection as it is a combination of possible problems in two other areas--human resources and intrusion prevention. In short, an employee could be siphoning off data for personal gain. This potential exposure must be addressed by human resources before an employee or outside contractor is given access to sensitive data. An IPS and an antivirus solution will help you guarantee that a person accessing data with an employee's account is the employee and only the employee.

Finally, there is the world of ILP (information leak prevention), which encompasses tools to determine what data is going beyond the perimeter of the network and for stopping what's not supposed to leave.

ILP products attempt to keep critical data from leaving the network. How they go about it varies quite a bit as these products are relatively new. Generally, they reside on the network and monitor user actions and try to determine if someone is passing intellectual property or customer data out of the network. In detection mode they notify administrators of what users are sending and where; in prevention mode they stop the communication, then send the notification to administrators. Of course, these systems don't guard only against user malfeasance; they don't care what the source of the leak is, just that there is a leak. This makes them at least minimally effective against Trojans that target customer or IP data. Such systems are less useful against attempts to share passwords over the network--because there is no hard-and-fast rule for identifying password data--though some do detect user names.Tale Of The Tape

Your backup tapes contain a copy of all the data on a given machine or even the network and are a huge vulnerability. Data leaks from a firewall may be more often targeted, but the loss of a backup copy of a customer database is more likely to be catastrophic. And the number of "lost" tapes is huge.

Luckily, there are options to help you protect that data once it leaves your building. First, you should use replication to back up to a remote site--no tapes needed, so no tapes can get lost in the process. Replicated data tends to be more up-to-date than backup data since replication is faster and thus can be done more frequently. Of course, since the information must leave your network while being replicated, you must protect it--encrypt the replication stream or the replicated data itself. Fortunately, standard methodologies exist for such encryption.

The biggest problem with replication is archival storage. If the data must be stored for more than a few months, you'll need long-term backup--which again brings us to tapes that can be lost or stolen.Encryption is the best way to protect that tape data. Interestingly, options for tape encryption range from backup software that handles the encryption, to appliances on the network handling the encryption, to the tape drive itself handling the encryption. The biggest concern when evaluating encryption options should not be where the encryption takes place, but how the keys are handled. It is difficult to maintain hardware to access the archived data on old tapes, and it's even more difficult to find a key that may have been changed hundreds of times since the tape was written.

There are, however, plenty of options for key management, ranging from storing the keys on the physical tape--not on our list of suggested solutions--to centralized repositories that handle the storage, issuing and replacement of keys. If encryption is performed in several parts of your network, consider a product such as RSA's Key Manager or VeriSign's Key Management Services.

Storing keys on tape is extremely risky, and perhaps actually helpful to malicious hackers. Even encrypted keys stored on tape provide information that could be exploited by attackers to expose all the data on the tape.

In the end, by keeping abreast of available technologies and knowing what data is most critical, you can protect it. Today's tools are increasingly focusing on protecting important data first, so to take advantage of that approach, you need to actually know what data is most important. Regulations will certainly force more data into the "important" bucket than was there in the past, but if your architecture is well-thought-out, moving data from "highly protected" to "protected" or vice versa isn't a big deal. n

Don MacVittie is a senior technology editor at Network Computing. Write to him at dmacvittie@ nwc.com. The cost of information leakage is inestimable, especially if your company does business in California or is in another state with mandating reporting. The damage to your name and brands alone can last a long time and have a large impact on your company's bottom line. Lawsuits by those whose data was leaked can make this problem even worse. For these reasons, it is time to rethink how you've architected for data security and possibly look at new ways to better protect critical information.

Knowing how and where to protect your data is half the battle. We examine a variety of solutions that can work together to build a secure architecture for internal data threats and explain what tools are available to ensure that access to data is controlled and compliance requirements are met.