OLS Ancestry

Data classification, labels, and clearances (or user authorizations) are the foundation of OLS. The translation from idea to implementation occurred over several years: the concept of digitally labeling data within the database preceded the OLS product creation by at least six years.

In the early 1990s, the U.S. intelligence agencies and the DoD began asking the computing industry for products that could be used to securely and intuitively manage classified information. The government wanted to use systems that understood the notion of classified data—or data that had been categorized as confidential, secret, top secret, and so on. There was even a strong implication that if the products were built and were proven correct through an established formal process run by the National Security Agency (NSA), the government entities would purchase many of the products.

Consequently, several of the major computer companies, such as Sun, Hewlett-Packard, Digital Equipment Corporation (remember them?), and Oracle, obliged by investing millions of research dollars into implementing these secure products that were able to understand and discriminate between the different levels of classified information.

To handle classified information, these secure systems, sometimes referred to as trusted systems, applied classification labels to the information and to the digital processes that operated on the information. This was the digital equivalent of the physical label on the folder holding your game plans.

The label-based security implementations were effective because the users were already familiar with the concepts of data sensitivity and classifications from managing classified data in physical formats, such as documents, folders, and reports. The other part that made it effective was in how the labels were enforced.

Labels and Mandatory Access Control

A common solution was put forth by the vendors building trusted systems. The solution was based on two things: mandatory access controls and data labeling.

Access Controls: Discretionary and Mandatory

In Chapter 7, you read about how the Oracle database will enforce access controls based on privileges. The privileges were either directly associated with an object (called object privileges) or were functionally specific and applied to all objects across the database (called system privileges). This type of access control is called Discretionary Access Control (DAC).

The “discretionary” part of DAC refers to the ability of the user to maintain control over the access to the data. As an example, let’s assume the user SCOTT has created a document (perhaps it’s the plans for the upcoming game). If SCOTT wishes to allow another user, say the user BLAKE, to view the document, he can simply grant access to BLAKE. In the database, this is the equivalent of allowing SCOTT to grant the select privilege on the EMP table to the user BLAKE (assume the document is synonymous with a database table). If SCOTT wants any user to access the EMP data, then SCOTT can, at his discretion, grant access to that user. SCOTT, as owner of the table, has discretionary access control.

There are reasons this access control is simply not sufficient for handling very sensitive data. If the document created by SCOTT contains very sensitive data, allowing SCOTT to release it to anyone he chooses may not be a good idea. SCOTT may intentionally or inadvertently grant access to someone who shouldn’t have it. What if BLAKE, without SCOTT’s knowledge, had a relationship with someone from the other team and was planning to divulge SCOTT’s game plans? Allowing BLAKE to read the document could be disastrous.

If the document is labeled, access to the document can be further restricted. Before users are allowed access, they have to be cleared to the same level as the document. That is, if SCOTT has a top secret document, BLAKE will not be able to access the document unless he also has a top secret clearance, even if SCOTT grants BLAKE access. In the game competition example, the coaching staff would have top secret clearances, the players would have secret clearances, and the support staff would have confidential clearances. Unless BLAKE is a member of the coaching staff, he won’t able to access the game plans.

Mandatory Access Control (MAC) describes the ability of the trusted computing platform (database, operating system, etc.) to protect classified and labeled data from being inappropriately accessed and disseminated. The MAC enforcements prevent unauthorized users—users with insufficient clearances—from being able to view or disseminate the protected information. The computing platform will not only prevent a user with only secret clearances from accessing top secret data, but it also will prevent a top secret user from passing off the top secret data to a secret user. In the SCOTT-BLAKE relationship, MAC would ensure that BLAKE would be unable to access the game plans unless he were authorized at top secret, which means he is part of the coaching staff. This would be true even if SCOTT granted BLAKE permission to read the plans.

Overall, access is enforced by both DAC and MAC. This defense in depth approach is sometimes confused with what many in the industry refer to as multilevel security. Multilevel security actually describes multiple levels of classified data, as opposed to multiple rings of security protecting the data. The DAC allows users to grant and revoke privileges at their discretion. DAC in the database is represented by the privileges (execute, select, delete, etc.) users can grant other users on their (data) objects. MAC restricts access to objects based on the security policies defined in the computing platform. MAC mediates access to data based on matching the user’s authorizations to the labels attached to the data. The important point is that DAC can’t override MAC—that is, the user can’t say, “only give the secret guys the top secret data; I said it’s okay.” The computing platform will prevent that from occurring.

MAC was introduced not only to prevent malicious users from giving away important classified information but also to prevent users from accidentally releasing sensitive information. For example, the trusted operating systems that implemented MAC prevented users from copying in a top secret window and pasting into a secret window. This ensured the users were making a conscious decision about moving the data between windows, which meant they were moving data between classifications.

Trusted Oracle

Oracle’s product for supporting MAC, called Trusted Oracle, was a separate port of the Oracle database and required the use of special (MAC-aware) operating systems. The operating systems were also special versions produced by their respective company.

Trusted Oracle was evaluated by the NSA as meeting B1-level security. B1 security defines label-based security protections and defines what a system has to do to be compliant with MAC. The B1 evaluation was an official recognition by an independent authority that Oracle’s implementation of MAC was sufficient and complete. This made it suitable for handling classified data.

MAC was strictly enforced by the operating system. The database used the operating system as a guide to enforcing the database MAC security. A security policy was implemented as a set of labels defined and enforced by the operating system. A restriction that later proved to be difficult to handle was that there was only one set of labels available for use by all applications and data.

With Trusted Oracle, every aspect of the database carried a security label—the database processes (SMON, PMON, the listener process, and so on), the database files, database users, and every object within the database had a security label. The database’s security labels were directly linked to the operating systems’ labels. When processes and users accessed the database, the OS and/or the database compared the security labels to ensure that access was permitted.

Trusted Oracle had many interesting properties. Row-level security was implemented for every table in the database. Every row in every table contained a label. This included not only user and application data tables but also the database dictionary. What this meant was that an administrator could create an object, such as a table or procedure at the top secret level, and only users connected at top secret would know the object existed!

The database tables contained a pseudocolumn called rowlabel. The rowlabel, as the name implies, was the security label for the row. An interesting property of the label was that it was hidden from view. A SELECT * or DESCRIBE on the table wouldn’t return the rowlabel. However, the user or application could directly ask for the rowlabel if for some reason they wanted to see it (somewhat analogous to the rowid pseudocolumn still in use today).

While trusted databases and operating systems were readily available for several years, today only a few still exist. Most of the major OS and database vendors abandoned their trusted platforms as they were expensive to maintain, difficult to manage (the administrators had to have special knowledge because the systems didn’t behave like their nontrusted siblings) and were frequently a few versions behind in nonsecurity features. Additionally, while MAC security was required or desired for some applications, it wasn’t desired for all applications. Unfortunately, MAC couldn’t be selectively enabled or disabled. MAC, by definition, was an all-or-nothing technology.

With Trusted Oracle, there were drawbacks as well. The database, like trusted operating systems, required administrators with special MAC knowledge. Operations performed at the wrong security level could have unintended negative consequences. The labeling was inflexible because it was based on the OS labels. The Trusted Oracle database also fell behind functionally because it wasn’t released with each new update of the standard Oracle database. As the availability of trusted operating systems diminished, Oracle released its last version of Trusted Oracle, Trusted Oracle version 7.2.3.