Protecting Our Stream of Data

Protecting the data our companies collect is important. Many of us go to great lengths to secure our databases, firewall connections, limit access, and more. However, we can’t secure the data before it gets to us, and that can be a problem. I ran across a link on Bruce Schneier’s blog that shows a criminal placing a skimmer on a credit card scanner in a convenience store. The original video is gone, but there are plenty more.

In general, the loss of data from the application (and physical hardware in this case), isn’t really a database issue. After all, the data is essentially split into two streams, with some going to the legitimate database and other processes while another stream goes to the skimmer. If this happens, and the skimmer isn’t discovered, however, it’s entirely possible that any data loss might be blamed on the database or IT infrastructure.

If someone suspected you were hacked because of data being lost, could you prove you weren’t hacked? Or that the data didn’t come from your database? This is impossible, since you can’t prove a negative, but would you have any evidence that could be used to bolster your claims? Is there auditing or other tracking of activity? Does your organization keep any logs that would show a lack of activity and are protected against tampering? Ideally you would find the source that lost the data, but if you can’t, it can be difficult to prove that the losses didn’t come from your systems.

For most of us, we might not have much in the way that would show our systems have only had legitimate access. Instead we’d depend on the limited SQL Server logging, as well as other infrastructure tracking, such as firewall activity logs. The strength of our presentation would likely determine whether security staff or management accepted our claims as valid.

Point of Sale systems are different than the applications that most of us use, but certainly we have database security concerns that we should address. I would hope that SQL Server would bolster its capabilities in this area, providing a way to set up a tamper proof log easily that accepts writes of activity from a database in some structured text file that uses minimal resources. I’m not even sure what I’d want here that I can’t get from XE, but I do think having something more robust and standardized would be nice. If nothing else, a local SQL Server could stream XE events out to a file target in a remote location that only supports writing. This wouldn’t necessarily prove anything if the connection were disrupted, but it would ensure that a business was aware of the breakdown between the instance and audit log.

I know the ways in which people attempt to access and steal data will continue to evolve and become more complex and creative. We can’t protect against many of them from the database side, but I’d like to think that we could protect the data we have. We should ensure it is safe from theft, loss, or inappropriate access and prove we have done so.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.2MB) podcast or subscribe to the feed at iTunes and Libsyn.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

1 Response to Protecting Our Stream of Data

  1. rsterbal says:

    When working retail I couldn’t prove that cash was valid until I brought it to the bank the next day. We videotaped the cash registers to help with any investigation of a fraudulent transaction.

    Credit card transactions were at the mercy of the clearinghouse, since they would wire whatever charges that they approved.

    I would estimate that less than 1% of the charges and cash we received over 4 years turned out to be invalid. Credit cards probably increased sales by more than 10%.


Comments are closed.