Those who are familiar with setting up a secure server environment will recognize the term "honeypot server". This type of server is setup for the sole purpose of attracting, identifying and studying the behavior of those pesky hackers and snoops. It looks like a real server, smells like a real server, and if your appetite is such... tastes like a real server. In this instance it would not be the brightest thing to place real sensitive information in a honeypot server; Instead, the placement of artificial information that mimics sensitive information is the cheese that lay upon the mousetrap.

The term "honeycombing a database" first made its appearance in my line of vision a couple of years ago when I was reading the book "Cryptography in the Database: The Last Line of Defense" by Kevin Kenan. In this book, the concept is very briefly presented as a near cousin to the honeypot server. The idea is to place tables within a database that contain artificial sensitive data. This data would be left unprotected by encryption, hashing, masking or other obfuscation methods. This naked presentation of such data is irresistible by those who wish to get their grubby hands upon it. Once the database is successfully honeycombed, the decoy tables can be monitored for activity and the appropriate parties can be notified upon the execution of suspicious activity.

When this concept was born to my conscious I was intrigued by the concept. At that time SQL Server 2005 was the current version. To my dismay there was not a lot available natively in SQL Server to provide this sort of strategy. Triggers could marginally fill this purpose by capturing INSERT, UPDATE and DELETE calls; but the demise of the idea was the lack of capturing SELECT calls and various DDL statements.

When the features of SQL Server 2008 began to trickle from Redmond I was stoked about the possibilities that the auditing features of SQL Server provided for honeycombing. All of the desired DML statements were included as well as many other events. Upon installation of the RTM my first act was to experiment with this very concept. I eagerly typed away as the schema of my database unfolded upon the screen. The steps that I took to implement honeycombing were:

1. Create a table within the target database that contains columns that look tempting. For example: Social Security Number, Credit Card Number, Credit Card Expiration Date, etc.
2. Populate the table with artificial data. Red-Gate's SQL Generator fit that bill extremely well.
3. Build a new Server Audit object at the instance level. This also can be scripted using CREATE SERVER AUDIT. Make sure that the Server Audit object is enabled.
4. Build a new Database Audit Specification object at the user database level. This also can be scripted using CREATE DATABASE AUDIT SPECIFICATION. Make sure that the Database Audit Specification object is enabled.
5. Check your audit log and sit back and watch those nasty suckers get whapped.

In addition to these steps a SQL Server Agent Alert can be setup to provide a means of notification when an audit event occurs.

Honeycombing should be included in your security strategy when protecting a database. This practice not only allows you to identify the users and methods that are attempting to disclose and modify sensitive data, it also alerts you to the presence and frequency of such activity much earlier than with out it.