Oracle
Label Security

Successful Multi-Level Security Implementation

Much like any sophisticated security product, planning your deployment of Oracle Label Security is very important and will help avoid potential problems. The steps below provide a basic guideline for deploying Oracle Label Security. The implementation can be performed using Oracle Enterprise Manager or the Oracle Label Security API / command line interface. It may be useful to work with a sample demonstration table first to get a firm understanding of how data labels mediate access control as well as the various enforcement options available in Oracle Label Security.

 

Most likely only a small number of tables hold information that requires labeling. Prime candidates are tables holding "Personally Identifiable Information" (PII), trade secrets, research results, any kind of financial information. Or, after a consolidation project, where physically separated information silos have been put into one database, labeling would maintain the same level of security as if they were still separated, but controlled information exchange between them is now much easier.

 

Oracle Label Security provides three components for Labels:

  • Level (at least one): Determines the sensitivity level of data rows or the clearance level of users. Examples are: "Public", "Internal", "Secret", "Confidential", "Proprietary"

  • Compartment (optional; determines 'need-to-know'): Allows compartmentalization of levels; non-hierarchical; users need to have at least all compartments of the data row in order to get access to it; examples are: "Marketing", "Finance", "Mergers and Acquisitions", "Project X", "SaaS Customer Y"

  • Group (optional; determines data ownership): Hierarchical; users need to have at least one of the groups of the data row in order to gain access. Example: "EMEA" is the parent group of the sub-groups "Italy", "France", "Northern Europe"

 

Senior Management and security personal should determine which user groups or individual users should have access to the information previously labeled. For administrative users, Oracle Label Security provides a number of special privileges, that allow delegated maintenance of policies, assuming of regular users' labels and more. These extra privileges should be granted only after careful consideration.

 

Not all permutations of the label components found in step two are used; for example, "Mergers and Acquisitions" are always "Top Secret" and are never decided on a country level, so the Group is "EMEA". The label for this example would be:

Top Secret:Mergers and Acquisitions:EMEA

 

Oracle Label Security maintains all information gathered in the previous steps in a "Policy". The policy can be created either using Oracle Enterprise Manager Cloud Control or a complete, flexible API.

 

When an OLS policy is applied to a table, it appends a hidden column to that table, which will store the row ("classification") label. Initially, the values in this column are NULL, and, when READ_CONTROL is activated, no-one has access to this table anymore, except those administrative users with the READ or FULL privilege. Either find the label for each row manually or determine them by a where clause:

SQL> update <table_name> set OLS_COLUMN =
char_to_label ('<policy_name>','<valid_label>')
where <condition>

When new rows are added to the table, the labels are either determined by the user's write label, or a labeling function, which determines the label from other columns in this row or other tables.