|Database Security Issues: Inference|
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, its 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. Its 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:
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:
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.