2
Understanding Data Labels and User Labels

This chapter discusses the fundamental concepts of data labels and user labels, and introduces the terminology that will help you u nderstand Oracle Label Security.

The chapter includes:

• Introduction to Label-Based Security
• Label Components
• < a href="labels.htm#1006625">Label Syntax and Type
• How Data Labels and User Labels Work Together
• Administering Labels

Introduction to Label-Based Security

Lab el-based security provides a flexible way of controlling access to sensitive data. Oracle Label Security controls data access based o n the identity and label of the user, and the sensitivity and label of the data. Label security adds protections beyond the discretio nary access controls that determine the operations users can perform upon data in an object, such as a table or view.

An Oracle Label Security policy controls access to data in three dimensions:

Note that the discussion here concerns access to data. The particular type of access, such as reading or writing the data, is cove red in Chapter 3, "Understanding Access Controls and Privileges". Policy privileges are covere d in Chapter 7, "Administering User Labels and Privileges"

When an Oracle Label Security policy is applied to a database table, a column is added to the table to contain each row's labe l. The administrator can choose to display or hide this column.

Label Components

This section describes the three elements defined for use in labels.

• Label Component Definitions and Valid Characters
• Levels
• Compartments
• Groups
• Industry Examples of Levels, Compartments, and Groups

Label Com ponent Definitions and Valid Characters

A sensitivity label is a sin gle attribute with multiple components. All data labels must contain a level component, but the compartment and group components are optional. An administrator must define the label components before creating labels.

Table 2-1 Sensitivity Label Components





Valid characters for specifying all label component include alphanumeric char acters, underscores, and spaces. (Leading or trailing spaces are ignored.)

The following fi gure illustrates the three dimensions in which data can be logically classified, using levels, compartments, and groups.

Figure 2-1 Data Categorization with Levels, Compartments , Groups



Text description of the illustration olsag006.gif

Levels

A level is a ranking that denotes the sensitivity of the information it labels. The more sensitive the information, the higher its level. The less sensitive the information, the lower its level.

Every label must include one level. Oracle Label Security permits defining up to 10,000 levels in a policy. For each level, the Ora cle Label Security administrator defines a numeric form and character forms.

For example, y ou can define a set of levels like the following:

Table 2-2 Level Example

Component	Description	Examples
Level	A single speci fication of the labeled data's sensitivity within the ordered ranks established	< p class="TB">CONFIDENTIAL (1), SENSITIVE (2), HIGHLY SENSITIVE (3)
Compartments	Zer o or more categories associated with the labeled data	FINANCIAL, ST RATEGIC, NUCLEAR
Groups	Zero or more identifiers for organizations owning or access ing the data	EASTERN_REGION, WESTERN_REGION

Numeric Form	Long Form	Short Form
40	HIGHLY_SENSITIVE	HS
30	SENSITIVE	S
20 < /td>	CONFIDENTIAL	C
10	PUBLIC	P

Table 2-3 Forms of Specifying Levels  

Form	Explan ation
Numeric Form, also called "tag"	The numeric f orm of the level can range from 0 to 9999. Sensitivity is ranked by this numeric value, so you must assign higher numbers to levels t hat are more sensitive, and lower numbers to levels that are less sensitive. In Table 2-2, 40 ( HIGHLY_SENSITIVE) is a higher level than 30, 20, and 10. Administrators should avoid using s equential numbers for the numeric form of levels. A good strategy is to use even increments (such as 50 or 100) between levels. You c an then insert additional levels between two pre-existing levels, at a later date.
Long Form	The long form of the level name can contain up to 80 characters.
Short Form	The short form can contain up to 30 characters.

Although the a dministrator defines both long and short names for the level (and for each of the other label components), only the short form of the name is displayed upon retrieval. When users manipulate the labels, they use only the short form of the component names.

Other sets of labels that users commonly define include TOP_SECRET, SECRET, CONFIDENTIAL, and UNCLASSI FIED; or TRADE_SECRET, PROPRIETARY, COMPANY_CONFIDENTIAL, PUBLIC_DOMAIN.

If only lev els are used, a level 40 user (in this example) can access or alter any data row whose level is 40 or less.

Compartments

Compartments identify areas that describe the sensitivi ty of the labeled data, providing a finer level of granularity within a level.

Compartments associate the data with one or more security areas. All data related to a particular project can be labeled with the same compartmen t. For example, you can define a set of compartments like the following:

< /a> Table 2-4 Compartment Example

Note: In this guide, all labels (including "TOP_SECRET," "SECRET," "CONFIDENTIAL," and so on) are used as illustrations only.

Numeric Form	< font face="Arial, Helvetica, sans-serif">Long Form	Short Form
85	FINANCIAL	FINCL
65	CHEMICAL	CHEM
45	OPERATIONAL	OP

Table 2-5 Forms of Specifying Compartments  

Form	Explanation
Numeric Form	The numeric form c an range from 0 to 9999; it is unrelated to the numbers used for the levels. The numeric form of the compartment does not indicate gr eater or less sensitivity. Instead, it controls the display order of the short form compartment name in the label character string. F or example, assume a label is created that has all three compartments listed in Table 2-4, and a level of SENSITIVE. When this label is displayed in string format, it looks like this: S :OP,CHEM,FINCL The display order follows the order of the numbers assigned to the compar tments: 45 is lower than 65, and 65 is lower than 85. By contrast, if the number assigned to the FINCL compartment were 5, the charac ter string format of the label would look like this: S:FINCL,OP,CHEM
Long Form	The compartment name's long form can have up to 80 characters.
Short Form	The short form can contain up to 30 characters.

Compartments are optional; a label can contain zero or more compartments. Oracle Label Security permits defining up t o 10,000 compartments.

Not all labels need to have compartments. For example, you can speci fy HIGHLY_SENSITIVE and CONFIDENTIAL levels with no compartments, and a SENSITIVE level that does contain compartments.

When you analyze your data's sensitivity, you may find that some compartments are only useful at specifi c levels. Figure 2-2 shows how compartments can be used to categorize data.

Figure 2-2 Label Matrix



Text description of the i llustration olsag005.gif

Here, compartments FINCL, CHEM, and OP are used with the level HIGHLY_SENSITIVE (40). The label HIGHLY_SENSITIVE:FINCL, CHEM indicates a level of 40 with the two named compartments. Compartment F INCL is not more sensitive than CHEM, nor is CHEM more sensitive than FINCL. Note also that some data in the protected table may not belong to any compartment.

If compartments are specified, then a user whose level would nor mally permit access to a row's data will nevertheless be prevented from such access unless the user's label also contains a ll the compartments appearing in that row's label.

Groups

Groups identify organizations owning or accessing the data, such as EASTERN_REGION, WESTERN_REGION, WR_SALES. All data pertaining to a certain depar tment can have that department's group in the label. Groups are useful for the controlled dissemination of data, and for timely react ion to organizational change. When a company reorganizes, data access can change right along with the reorganization.

Groups are hierarchical: you can label data based upon your organizational infrastructure. A group can thu s be associated with a parent group. For example, you can define a set of groups corresponding to the following organizational hierar chy:

Figure 2-3 Group Example

Text description of the illustration olsag009.gif

The WESTERN_REGION group includes thr ee subgroups: WR_SALES, WR_HUMAN_RESOURCES, and WR_FINANCE. The WR_FINANCE subgroup is further subdivided into WR_ACCOUNTS_RECEIVABLE and WR_ACCOUNTS_PAYABLE.

Table 2-6 shows how the org anizational structure in this example can be expressed in the form of Oracle Label Security groups. Notice that the numeric form assi gned to the groups affects display order only. The administrator specifies the hierarchy (that is, the parent-child relationships) se parately.

Table 2-6 Group Example  

Numeric Form	Long Form	Short Form	Parent Group
1000	< p class="TB">WESTERN_REGION	WR
1100	WR_SALES	WR_SAL	WR
1200	WR_HUMAN_RESOURCES	WR_HR	WR
1300	WR_FINANCE	WR_FIN	WR
1310	WR_ACCOUNTS_PAYABLE	WR_AP	WR_FIN
1320	WR_ACCOUNT S_RECEIVABLE	WR_AR	WR_FIN

Table 2-7 Forms of Specifying Groups  

Form	Explanation
Numeri c Form	The numeric form of the group can range from 0 to 9999, and must be unique for each policy. The numeric form does not indicate any kind of ranking. It d oes not indicate a parent-child relationship, or greater or less sensitivity. It simply controls display order of the short form grou p name in the label character string. For example, assume that a label is created that has t he level SENSITIVE, the compartment CHEMICAL, and the groups WESTERN_REGION and WR_HUMAN_RESOURCES as listed in Table 2-6. When displayed in string format, the label looks like this: S: CHEM:WR,WR_HR WR is displayed before WR_HR because 1000 comes before 1200.
Long Form	The long form of the group name can contain up to 80 characters.
Short Form	The short form can contain up to 30 characters.

Groups are optional; a label can contain zero or more groups. Oracle Label Security permits defining up to 10, 000 groups.

All labels need not have groups. When you analyze your data's sensitivity, you may find that some groups are only used at specific levels. For example, you can specify HIGHLY_SENSITIVE and CONFIDENTIAL labels wit h no groups, and a SENSITIVE label that does contain groups.

See Also: Chapter 14 , "Releasability Using Inverse Groups"

Industry Examples of Levels, Compartments, and Groups

Table 2-8 illustrates the flexibility of Oracle Lab el Security levels, compartments, and groups, by listing typical ways in which they can be implemented in various industries.

< em>Table 2-8 Typical Levels, Compartments, and Groups, by Industry

Industry	Levels	Compartments	Groups
Defense	< a name="1006530"> TOP_SECRET SECRET CONFIDENTIAL UNCLASSIFIED	ALPHA DELTA SIGMA	< a name="1006539"> UK NATO SPAIN
Financial Services	ACQUISITIONS CORPORATE CLIENT OPERATIO NS	INSURANCE EQUITIES TRUSTS COMMERCIAL_LOANS CONSUMER_LOANS	CLIENT TRUSTEE BENEFICIARY MANAGEMENT STAFF
Judicial	NATIONAL_SECURITY SENSITIVE PUBLIC	CIVIL CRIMINAL	ADMINISTRATION DEFENSE PROSECUTION COURT
Health Care	PRIMARY_PHYSICIA N PATIENT_CONFIDENTIAL PATIENT_RELEASE	PHARMACEUTICAL INFECTIOUS_DISEASES	CDC RESEARCH NURSING_STAFF HOSPITAL_STAFF
Business to Business	TRADE_SECRET PROPRIETARY COMPANY_CONFIDENTIAL PUBLIC	MARKETING FINANCIAL SALES PERSONNEL	AJAX_CORP BILTWELL_CO ACME_INC ERSATZ_LTD

Label Syntax and Type

After defining t he label components, the administrator creates data labels by combining particular sets of level, compartments, and groups. Out of al l the possible permutations of label components, the administrator specifies those combinations that will actually be used as valid d ata labels in the database.

This can be done using the Oracle Policy Manager graphical user interface, or using a command line procedure. Character string representations of labels use the following syntax:

LEVEL:COMPARTMENT1,...,COMPARTMENTn:GROUP1,...,GROUPn

The text string specifying the label can have a maximum of 4,000 characters, including alphanumeric characters, spaces, a nd underscores. The labels are case-insensitive; you can enter them in uppercase, lowercase, or mixed case, but the string is stored in the data dictionary and displayed in uppercase. A colon is used as the delimiter between components. It is not necessary to enter trailing delimiters in this syntax.

For example, the administrator might create valid label s such as these:

SENSITIVE:FINANCIAL,CHEMICAL:EASTERN_REGION,WESTERN_REGION
CONFIDENTIAL:FINANCIAL:VP_GRP
SENSITIVE
HIGHLY_SENSITIVE:FINANCIAL 
SENSITIVE::WESTERN_REGION

When a valid data label is created, two additional thi ngs occur:

• The label is automatically designated as a valid da ta label. This functionality limits the labels that can be assigned to data. Oracle Label Security can also create valid data labels dynamically at runtime, from those that are pre-defined in Oracle Internet Directory. Most users, however, prefer to create the label s manually in order to limit data label proliferation.
• A numeric label tag is associated with the text string representing the label. It is this label tag--rather than the text string--that is stored in the poli cy label column of the protected table.

  Note: For Oracle Label Security installations that are not using Oracle Intern et Directory, dynamic creation of valid data labels uses the TO_DATA_LABEL function. Its usage should be tightly controlled. See Inserting Labels Using TO_DATA_LABEL within the section Inserting Labeled Data, which starts.

  See Also: Chapter 6, "Creating an O racle Label Security Policy" for instructions on creating label components and labels The Policy Label Column and Label Tags "Label Tags"

How Data Labels and User Labels Work Together

A user can only access data within the range of his or her own label authorizations. A user has:

• Maximum and minimum levels
• A set of authori zed compartments
• A set of authorized groups (and, implicitly, authorization fo r any subgroups)

For example, if a user is assigned a maximum level of SENSITIVE, the n the user potentially has access to SENSITIVE, CONFIDENTIAL, and UNCLASSIFIED data. The user has no access to HIGHLY_SENSITIVE data.

Figure 2-4 shows how data labels and user labels wor k together, to provide access control in Oracle Label Security. Whereas data labels are discrete, user labels are inclusive. Dependin g upon authorized compartments and groups, a user can potentially access data corresponding to all levels within his or her range.

Figure 2-4 Example: Data Labels and User Label s



Text description of the illustration olsag007.gif

As shown in the figu re, User 1 can access rows 2, 3, and 4 because her maximum level is HS; she has access to the FIN compartment; and her access to grou p WR hierarchically includes group WR_SAL. She cannot access row 1 because she does not have the CHEM compartment. (A user must have authorization for all compartments in a row's data label, to access that row.)

User 2 can access rows 3 and 4. His maximum level is S, which is less than HS in row 2. Although he has access to the FIN compartment, he only has authorization for group WR_SAL. He cannot, therefore, access row 1.

Figure 2-5 shows how data pertaining to an organizational hierarchy fits in to data levels a nd compartments.

Figure 2-5 How Label Compo nents Interrelate



Text description of the illustration olsag010.gif

For e xample, the UNITED_STATES group includes three subgroups: EASTERN_REGION, CENTRAL_REGION, and WESTERN_REGION. The WESTERN_REGION subg roup is further subdivided into CALIFORNIA and NEVADA. For each group and subgroup, there may be data belonging to some of the valid compartments and levels within the database. Thus there may be SENSITIVE data that is FINANCIAL, within the CALIFORNIA subgroup.

Note that data is generally labeled with a single group, whereas users' labels form a hierarchy . If users have a particular group, that group may implicitly include child groups. Thus a user associated with the WESTERN_REGION gr oup has access to all data; but a user associated with CALIFORNIA would only have access to data pertaining to that subgroup.

Administering La bels

Oracle Label Security provides administrative interfaces to def ine and manage the labels used in a database. You define labels in an Oracle database using Oracle Label Security packages, or using the Oracle Policy Manager. Initially, an administrator must define the levels, compartments, and groups that compose the labels, and then she or he can define the set of valid data labels for the contents of the database.

Th e administrator can apply a policy to individual tables in the database, or to entire application schemas. Finally, the administrator assigns to each database user the label components (and privileges, if needed) appropriate for the person's job function.

See Also: Chapter 9, "Applying Policies to Tables and Schemas" for information about the Oracle Label Security interfaces used to manage label components

---

Previous Next

Copyright © 2000, 2003 Oracle Corporation All Rights Reserved.

Home Book List Contents Index Master Index Feedback