1. Technology
Database Security Issues: Inference
 Related Resources
• Database Security
• Starting a Career in Databases
• Certification Resources
 

Databases introduce a number of unique security requirements for their users and administrators. On one hand, databases are designed to promote open and flexible access to data. On the other hand, it’s this same open access that makes databases vulnerable to many kinds of malicious activity. This article is the first in a series that will look at a number of database-specific security concerns and guide you as you attempt to steer your databases clear of these obstacles.

One of the main issues faced by database security professionals is avoiding inference capabilities. Basically, inference occurs when users are able to piece together information at one security level to determine a fact that should be protected at a higher security level. It’s best explained through a practical example.

Imagine that you are the database administrator for a military transportation system. You have a table named cargo in your database that contains information on the various cargo holds available on each outbound airplane. Each row in the table represents a single shipment and lists the contents of that shipment and the flight identification number. The flight identification number may be cross-referenced with other tables to determine the origin, destination, flight time and similar data. The cargo table appears as follows:

Flight ID Cargo Hold Contents Classification
1254 A Boots Unclassified
1254 B Guns Unclassified
1254 C Atomic Bomb Top Secret
1254 D Butter Unclassified

Suppose that General Jones (who has a Top Secret security clearance) comes along and requests information on the cargo carried by flight 1254.  The general would (correctly) see all four shipments.  On the other hand, if Private Smith (who has no security clearance) requests the data, the private would see the following table:
 

Flight ID Cargo Hold Contents Classification
1254 A Boots Unclassified
1254 B Guns Unclassified
1254 D Butter Unclassified

This correctly implements the security rules that prohibit someone from seeing data classified above their security level.  However, assume that there is a unique constraint on flight ID and cargo hold (to prevent scheduling two shipments for the same hold).  When Private Jones sees that nothing is scheduled for hold C on flight 1254, he might attempt to insert a new record to transport some vegetables on that flight.  However, when he attempts to insert the record, his insert will fail due to the unique constraint.  At this point, Private Jones has all the data he needs to infer that there is a secret shipment on flight 1254.  He could then cross-reference the flight information table to find out the source and destination of the secret shipment and various other information.

This leads to a natural question -- what can you do about inference?  Basically, you have two options.  First, you can include the classification column in the unique constraint.  This technique, known as polyinstantiation, allows different records to exist in the same table at various security levels.  Private Jones would never learn of the Top Secret shipment.  On the other hand, he might wind up consequently double-booking the cargo hold, leaving a truckload of vegetables stranded at the airport.  The second option is to simply leave the tables as-is.  Private Jones will know that a classified shipment is taking place but won't have access to the contents of the shipment.  Neither solution is ideal, but both represent the types of trade-offs that must be made to balance security and practicality.

You can opt-out at any time. Please refer to our privacy policy for contact information.

Discuss in my forum

©2014 About.com. All rights reserved.