Protecting SQL Server Data : HONEYCOMBING A DATABASE - Implementing a Honeycomb Table, Creating a Server Audit

1. Implementing a Honeycomb Table

The process of honeycombing a database begins with the creation of a decoy table. The script in Listing 1 creates a honeycomb table in the default Database Object Schema of our HomeLending database. It has the mouthwatering name of Customer_Information and the column names, including First_Name, Social_Security_Number and Address_Street, are equally likely to attract the attention of the data thief.

Listing 1. The Customer_Information Honeycomb table.

One of the goals in honeycombing a database is to capture the casual exploration of data by users who have limited authorized access to the database. To open this decoy table to all levels of curiosity, we will grant SELECT, INSERT, UPDATE and DELETE permissions to the public database role, using the GRANT statement, as shown in Listing 2. All database users are members of the public database role by default.

Listing 2. Open season on the Honeycomb table.

Simply having an empty decoy table in your database will not be sufficient to draw activity its way. It must be filled with alluring, but bogus, data. The first rule in populating this decoy table is obviously never to use actual data.

Data scrambling techniques can be applied, or you can generate decoy data using a data generator, such as Red Gate's SQL Data Generator. It is recommended that you populate the decoy table with a number of rows that is consistent with the non-decoy tables. In our HomeLending database, SQL Data Generator was used to populate five thousand rows of data, a sample of which are shown in Figure 1.

Figure 1. Screenshot from Red Gate's SQL Data Generator.

2. Creating a Server Audit

In order to capture the activity of would-be data thieves on our honeycomb table, we need to implement the auditing feature of SQL Server 2008. The first step in this process is to create a ServerAudit object, which allows us to monitor a collection of actions that might occur on the target table, and record this activity in a file, typically the Windows Application log file.

The syntax of the CREATE SERVER AUDIT method is as follows:

CREATE SERVER AUDIT [Audit Name] TO [Output Location]

The arguments to this method are:

• Audit Name– the textual reference to the server audit.

• Output Location – the options for this argument are:

  • FILE: write to a binary file. The file path is required in parenthesis after "File" is specified.

  • APPLICATION_LOG: write to the Windows Application Log.

  • SECURITY_LOG: write to the Windows Security Log.

In Listing 3, we create in the Master database a Server Audit object called Honeycomb_Audit, which will write to the Windows Application Log.

Listing 3. Creating the Server Audit object.

Note that the Server Audit object is created at the instance level so the reference to the database in which the method was executed is not required.

When a Server Audit is created, it is disabled by default and will need to be enabled in order for it to begin collecting information. Listing 4 activates the Server Audit.

Listing 4. Activating the Honeycomb_Audit.