Oracle Label Security Concepts

Learning Objective

After completing this topic, you should be able to

recognize how Oracle Label Security works

1. Overview of access control

Access control defines the users right to read, insert, update, and delete information.
Oracle provides two access control models. They are
discretionary access control, also known as DAC and
Every object in Oracle Database is protected by DAC. DAC provides SELECT, INSERT,
UPDATE, and DELETE privileges on an object to a user. The user may be granted one or
more of these privileges. The limitation of DAC is that it gives access to all the data in a
table or allows access to none of the data in the table. There are more object privileges
than are mentioned here, and some privileges can be used to restrict access on a column
basis.
row-level security
Row-level security enables sophisticated access control rules beyond those of DAC by
using the data in the row. Virtual Private Database, also known as VPD, and Oracle Label
Security, abbreviated as OLS, are available to control row-level security.

Supplement
Selecting the link title opens the resource in a new browser window.

Learning Aid
Use the learning aid Style Considerations for more information on the style
considerations for the Oracle 11g Database used in this course.
Row-level access control depends first on the basic DAC policy. DAC and row-level
security
together dictate the criteria, controlling whether access to a row is permitted or denied.
Oracle Database Vault, commonly known as DV, security extends DAC in ways that rowlevel security cannot. DV enforces separation of duties, and restricts users including
those with the powerful ANY privilege from seeing or modifying data in protected realms.

Access to every table in the database is controlled by DAC. In this example, Joe issues a
SELECT statement against the emp table. Because Joe has received the SELECT
privileges on the emp table, he sees a result returned.
Because Freds access privilege is revoked, when he issues a SELECT statement against
the emp table, he sees the error message "Table or view does not exist."
The granularity of DAC is at the object level by privilege. There are four basic privileges
(SELECT,
INSERT, UPDATE, and DELETE) plus several more that depend on the object type. In
most databases, DAC is sufficient to handle the access control needs.

Graphic
The command to grant SELECT privileges on the emp table to Joe is the
following:
GRANT SELECT ON emp TO JOE;
The command to revoke access privilege from Fred on the emp table is the
following:
REVOKE SELECT ON emp FROM FRED;
If viewing certain columns is limited to certain individuals or job functions, you can use
DAC to limit viewing of certain columns to certain individuals or job functions. Place those
columns in a separate table and join on a key value, or hide the columns from all but
authorized users by defining a view of all but the sensitive columns.
Even in situations where DAC does not meet the needs for access control, there are
seldom more
than a few tables that require row-level access control. If the data in a row determines
who is allowed to access the row, DAC is inadequate. For these situations, row-level
access control is required.
OLS does not bypass DAC but supplements it. For all users making a SQL request, DAC
is applied first. DAC denies access to all users without the correct privileges.
After DAC is applied, Oracle Database checks whether an OLS policy is applied.
Additional predicates can easily be added to the policies to further refine access because
OLS is built on the same infrastructure as the VPD.
The objects in the database can have rows that are labeled. Access to rows is restricted
on the basis of OLS authorizations.

Graphic
In this example, the first two rows in the table are assigned the OLS labels
Sensitive and Highly sensitive. The third row is assigned the OLS label
Confidential. Based on DAC, the user is granted the Select object privilege. Based
on the OLS access mediation, the user can access only the row with the
Confidential OLS label.
There are however, a few conditions under which OLS is not enforced. It is not enforced
during the DIRECT path export and cannot be applied to objects in the SYS schema.
Also note that the SYS user and users with the special EXEMPT ACCESS POLICY
database privilege are exempt from both OLS and VPD enforcement. The EXEMPT
ACCESS POLICY privilege is a powerful database privilege and should be managed
carefully.
If your site requires that the SYS user and users with DBA type privileges are not allowed
to view
application data, DV has the facilities to meet this requirement. DV and OLS are designed
to work together.
To use the sensitivity labels, you perform the following actions:
specify data sensitivity
Labels are used to specify the sensitivity of data. These are known as data labels. Each
row has a data label. In the example, the row has a label of Secret::.
specify label authorizations, and
Labels are used to specify a users security clearance or label authorization. Each user is
assigned a set of labels that indicate the range of data labels that the user is allowed to
read and write. In this example, the user has a label of Top Secret::.
implement access mediation
The user label and the data labels are compared in a process known as access mediation
that uses a set of algorithms supplied by OLS. Users are allowed to view the row when
their label dominates the data label of that row. Otherwise, they are not able to see the
row.
In this example, the users label of Top Secret:: dominates the data label of Secret::
and access is allowed. Whether a particular label dominates another is determined by the
security administrator when the labels are created.

2. Installing and using OLS

To install OLS, perform the following steps:

use the Oracle Universal Installer, also known as OUI, Custom Install option
Use the Custom Install option of OUI to add the Label Security option to a base
installation.
use Database Configuration Assistant, commonly known as DBCA, to configure
OLS, and
Oracle highly recommends that you use DBCA to configure the Label Security option.
This configuration creates the LBACSYS user and LBAC_DBA role, and more than 200
objects. The database must be restarted after the configuration is complete.
use Enterprise Manager to manage the Label Security policies
Use Enterprise Manager to manage the Label Security policies. Enterprise Manager has
pages that enable you to create policies and manage labels and policies. These pages are
available in the Security section under the Server tab on the database home page of the
database control in Oracle 11g. The same pages can be seen in Grid Control 10g Release
4 by navigating to a target database, and clicking the Administration tab.
OLS is a packaged system that provides an easy-to-implement row-level security
solution, where access control is based on data sensitivity. Security requirements are
complicated by data restrictions generated by regulatory compliance.
For example, medical data can be viewed only by attending medical professionals and by
the person whose data it is. Nuclear weapon data is restricted to persons who have the
proper security clearance and compartment endorsement.
Different users need to see different data depending on their jobs, positions, or roles.
When this data can be separated into different tables, discretionary access control,
abbreviated as DAC, can provide the required granularity. When the data restrictions are
based on row and column values, the need for fine-grained access becomes obvious.
OLS is built on the fine-grained access control technology of Virtual Private Database,
also known as VPD. The major advantage of using OLS, rather than building the policies,
is that OLS is a complete system. It is a ready-to-use VPD.
OLS provides sophisticated functions and procedures for evaluating and comparing
sensitivity labels. It provides a sophisticated infrastructure for storing and managing
sensitivity labels and user security clearances.
The previous releases of OLS have relied on Oracle Database as the central repository
for policy and user label authorizations. This architecture took advantage of the scalability
and high availability of Oracle Database, but did not make use of the Oracle Identity
Management infrastructure, which includes Oracle Internet Directory, also known as OID.
This directory is part of the Oracle Identity Management platform. Integrating your

installation of OLS with OID allows label authorizations to be part of your standard
provisioning process.

Note
OLS integration with Oracle Identity Management was first available in Oracle
Database 11g Release 1.
For sites that use OID, databases retrieve the OLS policy information from the directory.
Administrators use the olsadmintool policy administration tool to operate directly on
the directory to insert, alter, or remove metadata as needed.
Because enterprise users can log in to multiple databases by using the credentials stored
in OID, it is logical to store their OLS policy authorizations and privileges there as well.
An administrator can then modify these authorizations and privileges simply by updating
metadata in the directory. Other aspects of managing enterprise users are performed
through the Oracle Identity Management Provisioning console.
For distributed databases, centralized policy management removes the need for
replicating policies because the appropriate policy information is available in the directory.
Policy changes in the directory are synchronized with policy information in the databases
by means of Directory Integration Platform and are effective without requiring further
effort.
The following OLS information is stored in the directory:

policy information, namely, policy name, column name, policy enforcement options, and audit
options

user profiles identifying their labels and privileges

policy label components levels, compartments, and groups, and

policy data labels

The database-specific metadata is not stored in the directory. Examples include

lists of schemas or tables, with associated policy information and

program units, with associated policy privileges

Question

Identify the features of OLS.

Options:
1.

It provides an easy-to-implement row-level security solution

2.

It relies on the database as the central repository for policy authorization

3.

It is built on the fine-grained access control technology of VPD

4.

It stores tables and their associated policy information in the directory

Answer
Option 1: This option is correct. OLS is a packaged system that provides an easyto-implement row-level security solution, where access control is based on data
sensitivity.
Option 2: This option is incorrect. Previous releases of OLS have relied on Oracle
Database as the central repository for policy and user label authorizations. Now
OLS is integrated with Oracle Identity Management.
Option 3: This option is correct. OLS relies on the fine-grained access control
technology of VPD, and an advantage of using OLS is that it is a complete system
and a ready-to-use VPD.
Option 4: This option is incorrect. Lists of schemas or tables with their associated
policy information, as well as program units and their associated policy privileges,
are not stored in the directory.
Correct answer(s):
1. It provides an easy-to-implement row-level security solution
3. It is built on the fine-grained access control technology of VPD
VPD provides an API for implementing row-level security by using application context.
The policy procedures, the application context, and the rules for control access to the
data must be created by developers.
To implement this, OLS provides a complete system comprising various components
such as
access rules
OLS comes with predefined access rules. These rules meet the requirements of many
applications without modification. These rules can be customized to meet special
circumstances.
common criteria

OLS has been evaluated under the International Common Criteria (ISO 15408) at
Evaluation Assurance Level, commonly known as EAL, 4. The Common Criteria standard
has superseded the DOD Orange Book standard and other European and Russian
standards.
complete data dictionary, and
The complete data dictionary is provided in the database to manage the aspects of OLS.
a complete user interface
Enterprise Manager provides a graphical interface that allows point-and-click control. The
SA_* packages provide a complete command-line interface.
OLS is built on the same technology as that used for the VPD. However, there are certain
differences in some features.
Access control
OLS does not depend on pre-existing data attributes as the basis for access control, but
depends on assigned data labels and user clearances.
Every application of VPD is custom built. VPD provides row-level access control by using
application context and a where clause that is added to every SQL statement.
Client requirements implementation
OLS provides the packages required to implement the customer requirements and so no
coding is required.
VPD implements customer requirements with user-programmed policies.
Table changes
OLS adds a column to every table protected. This column can be a hidden column.
In VPD, no columns are added.
New data classification
OLS classifies new data automatically.
VPD does not classify new data automatically.
Policy application
When new data is added to the protected table, OLS assigns data labels based on the
user clearance automatically.
If new values are placed in the columns used by VPD, the where clause in the policy may
need to be changed. The updated policy can then be automatically applied.

Column-level control
OLS is designed to work with column-level VPD and DV. A column-level policy can be
applied to further restrict column access, and user clearances can be used as factors in
DV to limit access to schemas and commands.
VPD uses only column-level VPD.
When analyzing the need for OLS, you need to first identify the application tables that
need OLS. Usually, only very few tables hold data that require the protection provided by
OLS.
Do not apply OLS where it is not needed. Use the appropriate security technology for
your problem. OLS has a performance cost. Identify the most resource-intensive
application queries and tune them for use in the OLS environment.
The following technologies typically meet most access control requirements:
DAC
DAC is always applied before the OLS policies. DAC specifies access control privileges at
the object level.
stored procedures and functions, and
Stored procedures and functions can be used to encapsulate objects, allowing the owner
to expose only certain methods of accessing the object. This technique can provide very
tight control over data integrity.
DV
Oracle Database Vault, commonly known as DV, can be used to extend DAC in ways that
OLS cannot.

Question
Which statements best describe evaluating the need for OLS?
Options:
1.

Few tables hold data that require the protection provided by OLS

2.

DAC is sufficient for all tables

3.

Stored procedures and functions can be used to encapsulate objects

4.

There is no performance cost associated with OLS

Answer

Option 1: This option is correct. You should identify the tables that need OLS,
because usually very few tables do. You should not apply OLS where it is not
needed.
Option 2: This option is incorrect. DAC is sufficient for most but not all tables. It is
always applied before the OLS policies and specifies access control privileges at
the object level.
Option 3: This option is correct. Stored procedures and functions can be used to
encapsulate objects, allowing the owner to expose only certain methods of
accessing the object.
Option 4: This option is incorrect. OLS has a performance cost. You should
identify the most resource-intensive application queries and tune them for use in
the OLS environment.
Correct answer(s):
1. Few tables hold data that require the protection provided by OLS
3. Stored procedures and functions can be used to encapsulate objects

Summary
In this topic, you've learned how Oracle Label Security works.

Creating Policies
Learning Objective

After completing this topic, you should be able to

recognize how to create a policy

1. Implementing the OLS policy

To implement Oracle Label Security, also known as OLS, policy, develop a strategy.
Before developing the strategy, talk to the right people. Identify those individuals in your
organization who really understand the business-security problem. Make sure that you
understand the problem before adding additional security to your application.
After developing the strategy, analyze the data to be protected. Ask questions such as

Where does the sensitive data reside in the application (which tables)?

Who needs access to this data?

Who owns the data?

Who should be able to read the data?

Who should be able to make updates?

The analysis includes a grouping of the user community by access needs such as

Does that grouping follow organizational lines?

Does it depend on the job function?

Note
This process is repeated for each set of data that is to be protected.
Next create the policies. Name the policies and define the default policy enforcement
options.
Also define the labels. When the OLS policy is applied to a table, a label column is added
to the table. The value in this label column is compared to the access permissions
assigned to the user to determine which users have access to that row.
The labels have three parts level, compartment, and group. Each of these can be
defined for your site. After the labels have been defined, the customer must assign the
data labels to the data rows. This is not automatic.
The data labels must be applied to the table. That means update the rows of the table
assigning the data label to every row, before the policy is applied. If the data label column
is null, that row will not be accessible.
Label definitions are global. Therefore, two policies in the same database cannot define
the same security label with different values. You need to consider this if you plan to run
multiple Oracle Label Security-enabled applications against the same database as label
collisions may occur.
After defining the labels, apply the policies. A policy must be applied to the table to be
enforced. Policies can be administered by users with appropriate privileges, such as a
security officer. Policies can be enforced, disabled, applied, or removed.
Each of these policies can be applied to different tables, and multiple policies can be
applied to a single table. To access data, a user must have label authorizations (or
clearances) for all policies protecting that data. To access any particular row, you must be
authorized by all policies protecting the table containing your desired rows.

The security officer must be given specific permissions to create and administer policies
and labels. These actions are performed by using the Oracle Policy Manager interface or
PL/SQL packaged procedures.
Finally, you perform these steps to complete the implementation of the OLS policy:
assign user authorizations and
A user authorization is the range of labels that a user can access. They are created and
assigned to the user on the basis of access requirements. Special privileges are included
in this set of authorizations.
After the policy has been applied, no user can access the data without a set of
authorizations. This step is independent of applying the policy; user authorizations can be
assigned before or after the policy is applied.
review and document your policy decisions
The policy decisions are reviewed and documented. This documentation provides a
reference point for future changes and audits. Implementing label security can be complex.
Many seemingly small decisions are made for ease of use or performance. When these
policies are called into question, the documentation saves many hours of reanalyzing the
application.

2. Creating policies
The first step in setting up Oracle Label Security, also known as OLS, is to create
policies. The named policy is a container for all the information that is associated with a
policy labels, tables, views, privileges, and procedures.
Use the CREATE_POLICY procedure to create a new OLS policy to define a policyspecific column name and specify a set of default policy options. The column is added to
every table associated with the policy. The policy can be created using Enterprise
Manager or PL/SQL using this syntax.

Syntax
PROCEDURE CREATE_POLICY ( policy_name IN VARCHAR2, column_name
IN VARCHAR2 DEFAULT NULL,
default_options IN VARCHAR2 DEFAULT NULL);
This example sets the policy name to FACILITY, the policy label column to FACLAB, and
the default access options.
The policy enforcement options can be set at the policy level as in the example or at the
schema or table level when the policy is applied.

Code
BEGIN
SA_SYSDBA.CREATE_POLICY(
POLICY_NAME =>'FACILITY',
COLUMN_NAME => 'FACLAB',
DEFAULT_OPTIONS =>
'READ_CONTROL,CHECK_CONTROL,LABEL_DEFAULT,HIDE');
END;
A basic policy with full enforcement would have three enforcement options enforced:

READ_CONTROL

WRITE_CONTROL, and

LABEL_DEFAULT
The interaction of these various enforcement options should be well understood for
effectively designing an OLS system.
Access-control enforcement controls read and write access to the data.
The policies can be set for each type of data manipulation language, abbreviated as
DML, with two options:
READ_CONTROL and
READ_CONTROL enforces the policy for all queries, controlling which data rows are
accessible for SELECT, UPDATE, and DELETE. If READ_CONTROL is OFF on a policy, for
any table protected by the policy, all rows are accessible to all users.
WRITE_CONTROL
WRITE_CONTROL determines the ability to insert, update, and delete data in a row. If this
option is active, it enforces INSERT_CONTROL, UPDATE_CONTROL, and
DELETE_CONTROL.
You can apply INSERT_CONTROL, UPDATE_CONTROL, and DELETE_CONTROL separately.
Label-management enforcement ensures that data labels written for inserted or updated
rows do not violate policies set for such labels with these three options:
LABEL_DEFAULT
LABEL_DEFAULT uses the sessions default row label value unless the user explicitly
specifies a label on INSERT.

LABEL_UPDATE, and
LABEL_UPDATE applies policy enforcement to the UPDATE operations that set or change
the value of a label attached to a row. The WRITEUP, WRITEDOWN, and WRITEACROSS
privileges are enforced only if the LABEL_UPDATE option is active. Note that any label
function that is in force overrides the LABEL_UPDATE option.
CHECK_CONTROL
CHECK_CONTROL applies the READ_CONTROL policy enforcement to the INSERT and
UPDATE statements to ensure that the new row label is read-accessible by the user that is
changing the label.
Options to override enforcement can suspend or apply all other enforcement options.
These options are
ALL_CONTROL and
ALL_CONTROL applies all enforcement options.
NO_CONTROL
NO_CONTROL applies no enforcement options. A labeling function or a SQL predicate can
still be applied. In the absence of a label function, data rows that are inserted do not have
a label.
If enforcement options are turned on later, the unlabeled rows are not visible unless the
user has the READ or FULL access authorization.
Set policy enforcement options at the policy level with the DEFAULT_OPTIONS parameter.
These options will be used unless other options are specified when the policy is applied
to the table or schema.

Note
Table-level options take precedence over the schema-level options.

Question
Which policy enforcement option applies the READ_CONTROL policy enforcement
to the INSERT and UPDATE statements to ensure that the new row label is readaccessible by the user that is changing the label?
Options:
1.

READ_CONTROL

2.

LABEL_UPDATE

3.

CHECK_CONTROL

4.

NO_CONTROL

Answer
Option 1: This option is incorrect. READ_CONTROL enforces the policy for all
queries, controlling which data rows are accessible to SELECT, UPDATE, and
DELETE.
Option 2: This option is incorrect. LABEL_UPDATE applies policy enforcement to
the UPDATE operations that set or change the value of a label attached to a row.
Option 3: This option is correct. CHECK_LABEL is considered a labelmanagement enforcement option. It applies the READ_CONTROL policy
enforcement to ensure the new row label is read-accessible to the user that is
changing it when using INSERT and UPDATE statements.
Option 4: This option is incorrect. NO_CONTROL applies no enforcement options.
Correct answer(s):
3. CHECK_CONTROL

3. Defining labels
Each data label can have three parts a level, one or more compartments, and one or
more groups. Every label must have a level, but the compartment and group portions of
the label are optional.
Each level, compartment, and group that will be used in a label must be created before it
can be used in a label.
Defining the needed levels, groups, and compartments follows the analysis of the datasecurity needs. Each part of the label is defined.
Every label must have a level defined, and by implication, every row protected by Oracle
Label Security, also known as OLS, must be assigned to a level.

Graphic
A level is a ranking that denotes the sensitivity of the information it labels. The
more sensitive the information, the higher its level. Every label must include one
level. Although both long and short names for the level (and for each of the other
label components) can be defined, only the short name is displayed upon retrieval.

Only the short names are used during label manipulation.

Levels can be assigned in the Levels page, which is currently opened. The page
contains a table with the columns Select, Long Name, Short Name, and Numeric
Tag and the Select All and Select None links.
Levels have many characteristics:

A level is an arbitrary name, such as SENSITIVE or CLASSIFIED. Higher and lower levels are
determined by the tag (the numeric form of the level). The numeric form can range from 0 through
9999. A user with a higher level can access lower levels. Levels have ranking determined by the
numeric tag.
The arbitrary names are listed in the Long Name column and the numeric tag in the Numeric Tag
column.

Assume that only levels are used. A user with a label of SENSITIVE can access data with a
SENSITIVE level or below.
Other levels listed are PUBLIC, CONFIDENTIAL, and HIGHLY SENSITIVE.

Each policy has its own set of levels, which are part of the label that is assigned to users and
data.

In this example, the SENSITIVE data level has a Short name of S and a Numeric tag of 300.
The PUBLIC level has the short name of P and a numeric tag of 100, the CONFIDENTIAL level
has the short name of C and a numeric tag of 200, and the HIGHLY SENSITIVE level has the short
name of HS and a numeric tag of 400.
To define levels, the database administrator, also known as DBA, or security administrator
uses the CREATE_LEVEL procedure of the SA_COMPONENTS package or Enterprise
Manager.
This is the syntax and an example of defining levels.

Code
BEGIN
SA_COMPONENTS.CREATE_LEVEL(
POLICY_NAME =>'FACILITY',
LEVEL_NUMBER => '100',
SHORT_NAME => 'P',
LONG_NAME => 'PUBLIC');
END;

Syntax

PROCEDURE CREATE_LEVEL (
policy_name IN VARCHAR2,
level_num IN INTEGER,
short_name IN VARCHAR2,
long_name IN VARCHAR2);
A data label can have zero or more groups assigned to it. Groups are a means of making
a
hierarchical assignment. Data assigned to a group can be accessed by a user belonging
to that group or a parent of the group.
In this example, WESTERN REGION is the parent group to WR FINANCE and WR SALES. A
user belonging to the WESTERN REGION group can access data belonging to either the WR
FINANCE group or the WR SALES group. But a user belonging to the WR SALES group
cannot access data belonging to WR FINANCE or WESTERN REGION.
For the group WR FINANCE, WR_FIN will appear in the group field of the
level:compartment:group label.

Graphic
These Group details are displayed in the Groups page in a table with columns
Select, Long Name, Short Name, Numeric Tag and Parent Group. The page also
contains the Select All and Select None links.
A label can include multiple groups. A user having permission on any of the groups in the
data label is allowed access.
The numeric form does not indicate any type of ranking. It does not indicate a parent-child
relationship, or greater or less sensitivity. It controls only the display order of the short
form of the group name in the label character string.

Note
The group access is evaluated after the level is evaluated. All labels have a level.
So access is further restricted by standard groups. Group access does not give
access when access would be denied by the level.
To define groups, the DBA or security administrator uses the CREATE_GROUP procedure
of the SA_COMPONENTS package or Enterprise Manager. This is the syntax.
Also given is an example of the procedure being used to create groups.

Code

BEGIN
SA_COMPONENTS.CREATE_GROUP('FACILITY',1000,
'WR','WESTERN_REGION');
SA_COMPONENTS.CREATE_GROUP('FACILITY',1200,
'WR_FIN','WR_FINANCE','WR');
SA_COMPONENTS.CREATE_GROUP('FACILITY',1210,
'WR_AP','WR_ACCT_PAYABLE','WR_FIN');
END;

Syntax
PROCEDURE CREATE_GROUP (
policy_name IN VARCHAR2,
group_num IN INTEGER,
short_name IN VARCHAR2,
long_name IN VARCHAR2,
parent_name IN VARCHAR2 DEFAULT NULL);
Compartments provide a finer granularity to the level classification. To access rows with
compartments included in the data label, the user label must include the level and the
compartment.

Graphic
The Compartments page is opened. The details are listed in a table with columns
Select, Long Name, Short Name, and Numeric Tag.
The following are the characteristics of compartments:

compartments are independent classifications

a data label can have zero or more compartments assigned to it

for a user to access that row, the user authorization must first have the correct level and include
all the compartments, and
compartments can be used to separate the work of various projects
In this example, a data row has a label with two compartments OP and CH. To access
the row, the user must have a label with the same or higher level, and at least the two
compartments (OP and CH).
The numeric tags for compartments do not indicate a higher or lower classification. This
tag only provides a way to order the compartment-name strings in a label. For example,
FIN is not higher than OP, but in a label, OP appears before FIN:S:OP, FIN.

Optional compartments are OP, CH, and FIN. FIN could appear in the Compartment field
of the
level:compartment:group label.
To define compartments, the DBA or security administrator uses the
CREATE_COMPARTMENT procedure of the SA_COMPONENTS package or Enterprise
Manager.
This is the syntax and an example of the procedure being used to define a compartment.

Code
BEGIN
SA_COMPONENTS.CREATE_COMPARTMENT(
POLICY_NAME =>'FACILITY',
COMP_NUMBER => '85',
SHORT_NAME => 'FIN',
LONG_NAME => 'Financial');
END;

Syntax
PROCEDURE CREATE_COMPARTMENT (
policy_name IN VARCHAR2,
comp_num IN INTEGER,
short_name IN VARCHAR2,
long_name IN VARCHAR2);
After defining label components, the administrator creates data labels by combining
particular sets of levels, compartments, and groups.
Out of all the possible permutations of label components, the administrator specifies
those combinations that are actually used as valid data labels in the database.
The maximum length of the short form of the label is 4,000 characters. The short form is
used in the label_value parameter of the CREATE_LABEL procedure.

Code
LEVEL:COMPARMENT:GROUP
---------------------------------------------SENSITIVE:FINANCIAL,CHEMICAL:WESTERN_REGION
CONFIDENTIAL:FINANCIAL:WR_SALES
SENSITIVE::

HIGHLY_SENSITIVE:FINANCIAL:
SENSITIVE::WESTERN_REGION
When a valid data label is created, two actions occur:

Code
LEVEL:COMPARMENT:GROUP
---------------------------------------------SENSITIVE:FINANCIAL,CHEMICAL:WESTERN_REGION
CONFIDENTIAL:FINANCIAL:WR_SALES
SENSITIVE::
HIGHLY_SENSITIVE:FINANCIAL:
SENSITIVE::WESTERN_REGION
the label is automatically designated as a valid data label and
The label is automatically designated as a valid data label. This functionality limits the
labels that can be assigned to data. OLS can also create valid data labels dynamically at
run time from those components that are predefined in Oracle Internet Directory,
abbreviated as OID.
Most users, however, prefer to create the labels manually to limit data-label proliferation.
a numeric label tag is associated with the text string representing the label
A numeric label tag is associated with the text string representing the label. It is this
numeric label tag (not the text string) that is stored in the policy label column of the
protected table.
This tag must be unique across all policies in the database. It is a good practice for
performance reasons to set tags for labels of higher sensitivity to a higher numeric value
than tags for labels of lower sensitivity.

Question
What should be considered when identifying data labels?
Options:
1.

When a valid label is created, it must be designated as valid

2.

The text string that represents the label is stored in the policy label column

3.

The numeric label tag must be unique across all database policies

4.

The maximum length of the short form of the label is 4000 characters

Answer

Option 1: This option is incorrect. When a valid data label is created, it is

automatically designated as a valid data label. This functionality limits the labels
that can be assigned to data.
Option 2: This option is incorrect. It is the numeric label tag, and not the text
string that represents the label, that is stored in the policy label column of the
protected table.
Option 3: This option is correct. A numeric label tag is associated with the text
string that represents the label. This tag must be unique across all policies in the
database.
Option 4: This option is correct. The maximum length of the short form of the
label is 4000 characters. The short form is used in the LABEL_VALUE parameter
of the CREATE_LABEL procedure.
Correct answer(s):
3. The numeric label tag must be unique across all database policies
4. The maximum length of the short form of the label is 4000 characters

Summary
In this topic, you've learned how to create a policy.

Creating Data Labels

Learning Objective

After completing this topic, you should be able to

recognize how data labels are created

1. Creating and managing data labels

Before creating a label, a policy is created. In this example, the policy FACILITY is
created. When the FACILITY policy is created, a role named FACILITY_DBA is also
created with the EXECUTE privilege on several packages owned by LBACSYS.
The DBA or a user who is assigned the <policy>_DBA role can create labels by using
the CREATE_LABEL procedure in the SA_LABEL_ADMIN package or by using Enterprise
Manager, abbreviated as EM. The <policy>_DBA role is created when the policy is
created.

This is the syntax and example code for creating labels using the CREATE_LABEL
procedure in the SA_LABEL_ADMIN package.

Code
BEGIN
SA_LABEL_ADMIN.CREATE_LABEL('FACILITY',1000,'P');
SA_LABEL_ADMIN.CREATE_LABEL('FACILITY',2101,'S::US');
SA_LABEL_ADMIN.CREATE_LABEL('FACILITY',3101,'HS::US');
END;

Syntax
PROCEDURE CREATE_LABEL (
policy_name IN VARCHAR2,
label_tag IN INTEGER,
label_value IN VARCHAR2,
data_label IN BOOLEAN DEFAULT TRUE);
The process of comparing user authorization and data label to decide what access is
granted is
called access mediation.
There are two types of access mediation for protected tables. They are
read and
A user can read any data up to his or her maximum level.
write
Write access is a subset of read access. A user cannot write lower than his or her
minimum level. This controls the users ability to disseminate data by lowering its
sensitivity.
In addition to the two types of access mediation, there are separate lists of compartments
and groups for which the user is authorized that is, for which the user has at least read
access. An access flag indicates whether the user can also write to individual
compartments or groups.
The DBA can further customize user data access by granting policy privileges and setting
policy-enforcement options.
In this example, the user is assigned the Sensitive label S::. The user can read sensitive
and confidential information, but not highly sensitive information. The user label does not
dominate the Highly Sensitive label, and access is denied to this information.

Oracle Label Security, also known as OLS, provides administrative interfaces to define
and manage the labels used in a database. You can define labels in an Oracle database
by using OLS packages or EM.
Initially, administrators must define the levels, compartments, and groups that compose
the labels, and then they can define the set of valid data labels for the contents of the
database.
The administrator can apply a policy to individual tables in the database, or to the entire
application
schemas. Finally, the administrator assigns to each database user the label components
(and
privileges, if needed) that are appropriate for the person's job function.
The administrator sets the privileges that allow data labels to be changed by certain
users, if appropriate. Some sites may not allow anyone to change a label. Some
customers may have specific individuals who are responsible for reviewing and assigning
the appropriate labels.
Users are allowed to change their session label as well as row label, within the range of
their minimum and maximum labels by using the SET_LABEL and SET_ROW_LABEL
procedures of the SA_SESSION package.
The components of the labels have been created. The data labels have been created and
marked as valid. For access mediation to work properly, the individual rows must have a
label assigned.
To do this, the steps to perform are
define labels
The labels that are assigned to data rows must first be created. There are usually many
more permutations of the different components of the labels than are actually used. Most
sites require that the labels that are actually used be created by an administrator to control
the proliferation of labels.
have labels for all rows, and
When creating policies, the label column for existing rows is initially NULL. The NULL value
does not match any label, so the data is not accessible, except by users with the FULL
access privilege.
set labels by updating rows
For existing rows, a user who has FULL access privileges (typically, the security
administrator) updates the rows, setting the label column to the proper label value for that
row. For new rows, users or the application supply the label, either directly by a pick list, by
session label default values, or by a policy function.

When you apply a policy to a table or schema, the policy is automatically enabled. To
disable a policy is to turn off its protections, although it is still applied. To enable a policy
is to turn on and enforce its protections for a particular table or schema.
To remove a policy is to take it entirely away from the table or schema. Note, however,
that the policy label column and labels remain in the table unless you explicitly drop them.
Use the APPLY_TABLE_POLICY procedure or EM, to add the specified policy to a table.
A policy label column is added to the table if it does not exist, and it is set to NULL.
When a policy is applied, it is automatically enabled. The policy enforcement options are
specified with a comma-delimited list in the TABLE_OPTIONS parameter.
To change the table options, labeling function, or predicate, you must first remove the
policy, and then reapply it. This is the syntax and the example of the
APPLY_TABLE_POLICY procedure.

Code
BEGIN
SA_POLICY_ADMIN.APPLY_TABLE_POLICY (
POLICY_NAME => 'FACILITY',
SCHEMA_NAME => 'HR',
TABLE_NAME => 'LOCATIONS',
TABLE_OPTIONS => NULL,
LABEL_FUNCTION => NULL);
END;

Syntax
PROCEDURE APPLY_TABLE_POLICY (
policy_name
IN VARCHAR2,
schema_name
IN VARCHAR2,
table_name
IN VARCHAR2,
table_options
IN VARCHAR2 DEFAULT NULL,
label_function
IN VARCHAR2 DEFAULT NULL,
predicate
IN VARCHAR2 DEFAULT NULL);
Users can access data only within the range of their own label authorizations.
A user has

maximum and minimum labels

a set of authorized compartments, and

a set of authorized groups (and, implicitly, authorization for any subgroups)

Each user has a session label and a row label. The session label is the particular
combination of levels, compartments, and groups on which a user works at any given
time. Users can change the session label to any combination of components for which
they are authorized.
When a user writes data without specifying its label, a row label is assigned automatically,
using the users session label. However, users can set the label for the written row within
certain restrictions on the components of the label that they specify with the
SA_SESSION.SET_ROW_LABEL procedure.

Code
BEGIN
SA_USER_ADMIN.SET_USER_LABELS (
POLICY_NAME =>'FACILITY',
USER_NAME => 'MYCO_MGR',
MAX_READ_LABEL =>'S::US,EU,ASIA');
END;
The administrator specifies the users initial session label and an initial default row label
when setting up user authorizations.
These authorizations are kept in the OLS data dictionary tables for each user. To define
user authorizations, the DBA or security administrator uses the SA_USER_ADMIN
package as in this example or the EM interface.

Code
BEGIN
SA_USER_ADMIN.SET_USER_LABELS (
'FACILITY','MYCO_EMP','P');
SA_USER_ADMIN.SET_USER_LABELS (
'FACILITY','MYCO_MGR','S::US,EU,ASIA');
SA_USER_ADMIN.SET_USER_LABELS (
'FACILITY','MYCO_PLANNING','HS::GLOBAL');
END;
This is the syntax for the SA_USER_ADMIN package.

Syntax
PROCEDURE SET_USER_LABELS (
policy_name
IN VARCHAR2,

user_name
max_read_label
max_write_label
min_write_label
def_label
row_label

IN VARCHAR2,
IN VARCHAR2,
IN VARCHAR2 DEFAULT NULL,
IN VARCHAR2 DEFAULT NULL,
IN VARCHAR2 DEFAULT NULL,
IN VARCHAR2 DEFAULT NULL);

max_read_label specifies the label string to be used to initialize the users maximum
authorized read label. It is composed of the users maximum level. Compartments are
authorized for read access, and groups are authorized for read access.
max_write_label specifies the label string to be used to initialize the users maximum
authorized write label. It is composed of the users maximum level.
Compartments are authorized for write access, and groups are authorized for write
access. If max_write_label is not specified, it is set to max_read_label.
min_write_label specifies the label string to be used to initialize the users minimum
authorized write label. It contains only the level, with no compartments or groups.
If min_write_label is not specified, it is set to the lowest defined level for the policy,
with no compartments or groups.
def_label is the label string including level, compartments, and groups that determines
the initial session setting for what a user can see. It can be increased by the user up to
max_read_label. If def_label is not specified, it is set to max_read_label.
policy_name specifies the policy.
user_name specifies the username.
Users insert if they do not specify the data label as a field in the INSERT statement.
If row_label is not specified, it is set to def_label, with only the compartments and
groups authorized for write access.

Question
What should you consider when assigning user authorization labels?
Options:
1.

A user can access data only within the range of their own label authorizations

2.

Each user has a session label or a row label

3.

A session label is assigned automatically when a user writes data without specifying
its label

4.

The administrator specifies the users initial session label

Answer
Option 1: This option is correct. A user has maximum and minimum labels, a set
of authorized compartments, and a set of authorized groups. They can only
access data they have been authorized to access.
Option 2: This option is incorrect. Each user has both a session label and a row
label. The session label is the particular combination of levels, compartments, and
groups on which a user works at any given time.
Option 3: This option is incorrect. When a user writes data without specifying its
label, a row label is automatically assigned, using the users session label.
Option 4: This option is correct. The administrator specifies the users initial
session label and an initial default row label when setting up user authorizations.
Correct answer(s):
1. A user can access data only within the range of their own label authorizations
4. The administrator specifies the users initial session label

2. OLS special user privileges

The first set of Label Security privileges are set with the
SA_USER_ADMIN.SET_USER_PRIVS procedure.
These privileges are
READ
The READ privilege allows read access to all data protected by the policy.
FULL, and
The FULL privilege allows full read and write access to all data protected by the policy.
COMPACCESS
The COMPACCESS privilege allows a session access to data authorized by the rows
compartments, independent of the row groups.
The PROFILE_ACCESS privilege is set with the
SA_POLICY_ADMIN.SET_ACCESS_PROFILE
procedure.
The PROFILE_ACCESS allows a user to change the OLS authorizations and privileges of
the database session to those of the specified user.

In this example, the READ privilege enables the user to bypass the OLS policy entirely for
read access to data. Users with the READ privilege can read all data protected by the
policy, regardless of their authorizations or session label.
The user does not even need to have label authorizations. However, access mediation is
still enforced on the UPDATE, INSERT, and DELETE operations. Users with the READ
privilege can write only to data rows for which they have write access, based on any label
authorizations.
The application uses of the READ privilege are data export, report generation, and
executive management privilege.
In this example, the FULL privilege has the same effect and benefits as the READ
privilege, with one difference, a user with the FULL privilege can also write to all the data.
The ability to write effectively bypasses all OLS controls.
Oracle discretionary access controls still protect the underlying table. For example, if a
user does not have the UPDATE privilege on the underlying table and attempts to update
a table directly with an UPDATE SQL statement, the statement would fail.
This is a very powerful privilege and should be reserved only for users that require it. A
classifier (someone who reviews data to determine its security classification) would need
this privilege to be allowed to see the data and change the classification freely.
In this example, the COMPACCESS privilege allows a session to access rows on the basis
of the rows compartments, independent of the row groups. If a row has no
compartments, access is determined by the group authorizations.
However, when compartments exist, and access to them is authorized, the group
authorization is bypassed. Level authorizations are still enforced. If the row has a data
label of Confidential:Operations:Western_Region and the user label is
Confidential:Operations:Central_Region, the user can access the row on the
basis of the compartment. The group is ignored.
This privilege is required only in special situations. For example, where a compartment is
created for a project that crosses groups but does not include all members of each group.
The SA_SESSION.SET_ACCESS_PROFILE procedure sets the OLS authorizations and
privileges of the database session to those of the specified user. (Note that the originating
user retains the PROFILE_ACCESS privilege.)
The user executing the SA_SESSION.SET_ACCESS_PROFILE procedure must have the
PROFILE_ACCESS privilege. Note that the database user (the session user ID) who has
logged in does not change.

That user assumes only the authorizations and privileges of the specified user. By
contrast, the OLS username is changed.

Code
SQL>
SQL>
2
3

connect appuser/mypassword
begin
sa_session.set_access_profile('finance','manager');
end;

User accounts defined in Oracle Internet Directory, also known as OID, cannot be given
individual OLS authorizations. However, authorizations can be given to the shared
schema to which the directory users are mapped.
The OLS SET_ACCESS_PROFILE function can be used programmatically to set the label
authorization profile to use after a user has been authenticated and mapped to a shared
schema. OLS does not enforce a mapping between users who are given label
authorizations in OLS and actual database users.

Code
SQL>
SQL>
2
3

connect appuser/mypassword
begin
sa_session.set_access_profile('finance','manager');
end;

This administrative procedure is useful for various tasks:

Syntax
PROCEDURE SET_ACCESS_PROFILE (
policy_name IN VARCHAR2,
user_name IN VARCHAR2);

With SET_ACCESS_PROFILE, the administrator can see the result of the authorization and
privilege settings for a particular user.
Syntax
PROCEDURE SET_ACCESS_PROFILE (
policy_name IN VARCHAR2,
user_name IN VARCHAR2);

Applications that have proxy accounts connect as (and assume the identity of) application users
for purposes of accessing labeled data. With the SET_ACCESS_PROFILE privilege, the proxy
account can act on behalf of application users.
Syntax

PROCEDURE SET_ACCESS_PROFILE (
policy_name IN VARCHAR2,
user_name IN VARCHAR2);
A trusted stored program unit is a stored procedure, function, or package that has been
granted one or more OLS privileges. Trusted stored program units are typically used to
enable users to downgrade information in a controlled manner, or update data at several
labels.
This is the optimal way in which users can be enabled to access data beyond their
authorization. To grant privileges to a stored program unit, you must have the special
policy_DBA role (where policy is the name of a policy) and the EXECUTE permission on
the program unit.
Use either Enterprise Manager or the SA_USER_ADMIN package to grant privileges to a
program unit. The SA_USER_ADMIN.SET_PROG_PRIVS procedure sets policy-specific
privileges for program units.
In this example, the sum_purchases procedure has been granted the READ privilege.
When the sum_purchases procedure is called, it executes with the READ privilege as
well as the current users OLS privileges. This allows the total purchases to be calculated.

Code
SQL>
2>
3>
4>
5>

EXECUTE SA_USER_ADMIN.SET_PROG_PRIVS(POLICY_NAME=>'HR',SCHEMA_NAME=>'MYSCHEMA',PROGRAM_UNIT_NAME =>'SUM_PURCHASES',PRIVILEGE=>'READ');

Question
Identify the features of a trusted stored package unit.
Options:
1.

It is a program unit that has been granted OLS privileges

2.

It can be used to enable users to download information in a controlled manner

3.

To grant privileges to a stored program unit, only the EXECUTE permission is

required

4.

The SA_USER_ADMIN package must be used to grant privileges to a program unit

Answer

Option 1: This option is correct. A trusted stored program unit is a stored

procedure, function, or package that has been granted one or more OLS
privileges.
Option 2: This option is correct. Trusted stored program units are typically used to
enable users to downgrade information in a controlled manner, or update data at
several labels. This is the optimal way in which users can be enabled to access
data beyond their authorization.
Option 3: This option is incorrect. To grant privileges to a stored program unit, you
must have the special policy_DBA role where policy is the name of a policy
and the EXECUTE permission on the program unit.
Option 4: This option is incorrect. You can use either Enterprise Manager or the
SA_USER_ADMIN package to grant privileges to a program unit. The
SA_USER_ADMIN.SET_PROG_PRIVS procedure sets policy-specific privileges for
program units.
Correct answer(s):
1. It is a program unit that has been granted OLS privileges
2. It can be used to enable users to download information in a controlled manner

3. Exporting and importing with OLS

Only rows with labels authorized for read access are exported. To export all the data, the
user must be granted the READ or FULL access. A user with the EXEMPT ACCESS
POLICY privilege can also export all the data.
The HIDE property is not exported. When protected tables are exported, the label
columns in those tables are also exported (as numeric values.) However, if a label column
is hidden, it is exported as a normal, unhidden column.
The LBACSYS schema cannot be exported due to the use of opaque types in OLS. An
export of the entire database (the FULL=Y parameter) with OLS installed can be
performed, except that the LBACSYS schema would not be exported. One option is to
maintain the policy on the production side from the beginning with scripts.
To use the import utility with OLS, you must prepare the import database and ensure that
the import user has proper authorizations.
To prepare the import database, you perform these steps:
1. Install Oracle Label Security, also known as OLS.

2. Create any OLS policies that protect the data to be imported. The policies must use the same column
names as in the export database.
3. Define in the import database all the label components and individual labels used in the tables being
imported. Tag values assigned to the policy labels in each database must be the same.
To successfully import data under OLS, the user running the import operation must be
authorized for all the labels required to insert the data and labels contained in the export
file.
The following requirements must be met:
requirement 1 and
The user must have the policy_DBA role for all policies with data being imported. After
each schema or table is imported, any policies from the export database are reapplied to
the imported objects.
requirement 2
The user must have the ability to write all rows that have been exported.
When implementing OLS, follow these performance tips:
limit policies to required tables
In most cases, only a small subset of the tables in a database requires row-level security.
Carefully identify these tables and limit the policies to these.
plan a label tag strategy
For optimal performance, you can plan a strategy for assigning values to label tags. In
general, it is best to assign higher numeric values to labels with higher sensitivity levels.
Usually, many more users can see data at comparatively low levels. Fewer users at higher
levels can see many levels of data. With READ_CONTROL set, OLS generates a predicate
that uses a BETWEEN clause to restrict the rows to be processed by the query. If the
higher-sensitivity labels do not have a higher label tag than the lower-sensitivity labels, the
query potentially examines a larger set of rows. This affects performance by requiring more
reads.
analyze the LBACSYS schema
Run the DBMS_STATS.GATHER_SCHEMA_STATS procedure on the LBACSYS schema, so
that the cost-based optimizer can improve execution plans on queries. Having the statistic
for the OLS data dictionary tables improves OLS performance.
index the policy label column, and
Create a bitmap index on the policy label column on the basis of the number of distinct
values.
partition on the basis of the label

If you are using a numeric ordering strategy with the numeric label tags that you have
applied to the labels, you can use this as a basis for data partitioning. Depending on the
application, partitioning data on the basis of label values may or may not be useful.
Also, allow time to tune your application after applying the OLS.

Question
Which actions may help to improve system performance when using OLS?
Options:
1.

Planning a label tag strategy

2.

Considering the use of a bitmap index on the label column

3.

Applying policies to all tables

4.

Removing label columns from existing indexes

Answer
Option 1: This option is correct. For optimal performance, you can plan a strategy
for assigning values to label tags. In general, it is best to assign higher numeric
values to labels with higher sensitivity levels.
Option 2: This option is correct. Creating a bitmap index on the policy label
column on the basis of the number of distinct values may help to improve
performance.
Option 3: This option is incorrect. In most cases, only a small subset of the tables
in a database require row-level security. The policies you add will directly affect
performance, so they should be used wisely.
Option 4: This option is incorrect. You should consider adding a label column to
existing indexes to improve performance.
Correct answer(s):
1. Planning a label tag strategy
2. Considering the use of a bitmap index on the label column

Summary
In this topic, you've learned how data labels are created.

Implementing Oracle Label Security

Learning Objectives

After completing this topic, you should be able to

create labels and policies in Oracle Database 11g

apply policies in Oracle Database 11g

test access control

Exercise overview
The data in the HR.LOCATIONS and HR.JOB_HISTORY tables has been analyzed and
can be placed in three sensitivity levels. Additional users MYCO_EMP, MYCO_MGR, and
MYCO_PLANNING have already been created and granted access to the required tables
and the LBACSYS user has been set up to use EM Database Control. The FACILITY
Oracle Label Security policy has already been created and now you want to create a
policy named PRIVACY. You also want to create levels and labels for the policy, set the
user authorizations, and apply and test the policy.
In this exercise, you're required to create and configure a policy, set user authorization,
and apply and test a policy.
This involves the following tasks:

creating a policy

creating levels and labels

setting user authorization

applying a policy

testing a policy

Task 1: Creating a policy

To take advantage of Oracle Label Security, you first want to create a policy. Create a
policy named "PRIVACY." Specify a hidden label column of "PRIVLAB." Apply policy
enforcements for all queries and for update and insert operations so that modified or new
rows are read accessible. Accept all other default selections.

Steps list
Instructions
1. Click Create
2. Type PRIVACY in the Name text box

Steps list
Instructions
3. Type PRIVLAB in the Label Column text box
4. Select the Hide Label Column checkbox
5. Select the Apply Policy Enforcements radio button
6. Select the For all queries (READ_CONTROL) checkbox
7. Select the For update and insert operations so that modified or new rows are read accessible
(CHECK_CONTROL) checkbox
8. Click OK

Task 2: Creating levels and labels

You now want to create the levels and labels for the PRIVACY policy. You have already
accessed the Label Components tab and added the first level. Add a second level with a
long name of "SENSITIVE", a short name of "S" and a numeric tag of "2000." Apply the
changes and return to the Label Security Policies page and add Data Labels for the
PRIVACY policy. Specify a numeric tab of "101000" and a level of "C" for the first label.
Specify a numeric tab of "102000" and a level of "S" for the second label.

Steps list
Instructions
1. In the second row of the Levels table, type SENSITIVE in the Long Name column, type S in the Short Name
column, type 2000 in the Numeric Tag column, and click the scroll bar down arrow
2. Click Apply
3. Click the Label Security Policies locator link
4. Select the PRIVACY radio button
5. Select Data Labels from the Actions drop-down list and click Go
6. Click Add
7. Type 101000 in the Numeric Tag text box, type C in the Level text box, and click OK
8. Click Add
9. Type 102000 in the Numeric Tag text box, type S in the Level text box, and click OK

Task 3: Setting user authorization

Next you want to set the user authorization for the HR user, who needs full read and write
access to the data and who must be able to change the session labels and session
privileges to those of another user for both the FACILITY and PRIVACY policies. You
have already configured authorizations for the FACILITY policy and selected the

PRIVACY policy. Add the HR user to the list of users who are authorized for the PRIVACY
policy. Search for the HR user, who appears in the second page of the results. Allows the
user to assume the profile of another user and bypass all Label Security checks. Accept
all default selections on the remaining screens and confirm the configuration.

Steps list
Instructions
1. Ensure Authorization is selected from the Actions drop-down menu and click Go
2. Click Add Users
3. Click Add
4. Click the Next 10 link
5. Select the HR checkbox and click Select
6. Click Next
7. Select the Assume profile of another user through set_access_profile (PROFILE_ACCESS) and Bypass all
Label Security checks (FULL) checkboxes and click Next
8. Click Next
9. Click Next
10. Click Finish

Task 4: Applying a policy

You now want to apply the PRIVACY policy to a table. Apply the PRIVACY policy to the
JOB_HISTORY table. Add the JOB_HISTORY table to the list of database tables to which
the policy has been applied. Search for the table by accessing the Search And Select:
Table page and searching the HR schema. Then confirm the configuration.

Steps list
Instructions
1. Select the PRIVACY radio button
2. Select Apply from the Actions drop-down list and click Go
3. Click Create
4. Click the Flashlight icon
5. Type HR in the Schema text box and click Go
6. Select the Select radio button for the JOB_HISTORY row and click Select
7. Click OK

Task 5: Testing a policy

Now that you have added policies to tables and users and have added labels to data, you
want to test the PRIVACY policy implementation. Execute the lab_14_01_15.sql script
using the @ command to test the policy. Press Enter to continue each time a pause in
the script is encountered.

Steps list
Instructions
1. Type @lab_14_01_15.sql and press Enter
2. Press Enter
3. Press Enter
4. Press Enter

Using the Data Masking Pack

Learning Objectives

After completing this topic, you should be able to

recognize how data masking works

create and use data masking

1. Implementing data masking

A number of regulations mandate that a company's confidential, sensitive, and personally
identifiable data must be protected and access to this data must be restricted.
There is often a need to provide production data, or realistic-looking data to in-house
developers and testing organizations during application development.
Data masking is a way to meet these two conflicting needs. Data masking is the act of
anonymizing customer, financial, or company confidential data to create new, legible
data, which retains the original datas properties, such as width, type, and format.
In this example, three columns of the HR.EMPLOYEES table have been masked so that
the data can be provided for testing or development without compromising the security of
the information.

Graphic
The columns of the HR.EMPLOYEES table are EMPLOYEE_ID, LAST_NAME,
DEPARTMENT_ID, and PHONE_NUMBER. The EMPLOYEE_IDs are specified

as 100, 105, and 110. The LAST_NAMEs are King, Austin, and Chen. The
DEPARTMENT_IDs are 90, 60, and 100. And the PHONE_NUMBERs are
515.123.4567, 590.423.4569, and 515.124.4269. In the masked table, the column
names are retained. However, the data is masked. The EMPLOYEE_IDs are 468,
975, and 396. The LAST_NAMEs are Jefferies, Smith, and Allen.
DEPARTMENT_IDs are the same as the original table. And the
PHONE_NUMBERs are 510.555.1256, 650.555.9753, and 925.555.3597.
The Data Masking Pack is a separately licensed Oracle Enterprise Manager
management pack available with Oracle Enterprise Manager Grid Control 10.2.0.4.

Graphic
The Database Instance: p1orcl.us.oracle.com page in ORACLE Enterprise
Manager 10g Grid Control is opened. It contains the Home, Performance,
Administration, and Maintenance tabs. The Administration tab is selected. The
Administration page lists the links BI & OLAP and Data Masking. The BI & OLAP
link contains the links Dimensions, Cubes, OLAP Dimensions, and Measure
Folders. And the Data Masking link contains the links Definitions and Format
Library.

Note
Although management packs may be included in product CDs or downloads, or
described in the documentation that you receive, this does not authorize you to
use them without the appropriate licenses.
The Data Masking Pack can help organizations comply with privacy and confidentiality
laws by masking sensitive or confidential data in development, testing, and staging
environments.
The Data Masking Pack uses an irreversible process to replace sensitive data with
realistic-looking, scrubbed data based on masking rules and ensures that the original
data cannot be retrieved, recovered, or restored.
By using the Data Masking Packs central definition for common data masking formats,
you can apply data privacy rules consistently to all production data and ensure
compliance with regulations.
As a best practice, create predefined mask formats for all common regulated information
so that they can be applied to sensitive data regardless of which database the data
resides in to ensure that sensitive data is consistently masked across the organization.
To implement data masking, in this example, the production database is first cloned to a
staging database and then masked for use in a testing environment.

During this implementation, different types of administrators perform various functions.

Security administrator
The security administrator reviews the application database and identifies the sensitive
data.
Application database administrator
The application database administrator defines the mask formats for sensitive data and
creates a masking definition to associate table columns to the defined mask formats.
Database administrator
The database administrator clones the production database to a staging database, creates
a masking definition if this task is not performed by the application database administrator,
and executes the masking job.
The security administrator performs two tasks:

verify that the masked data meets the information security requirements and

refine the masking definition as necessary

If the masking definition is changed, the database administrator restores the altered
tables and reapplies the masking definition until the optimal masking definitions are
identified.
The application database administrator, business analyst, and users test the application.
And the database administrator exports the masking definition for future use and clones
the staging database to a test database.

2. Masking data
The security administrator would typically direct the process of identifying sensitive data
for masking by identifying what types of information must be masked to comply with
various regulations.
The application database administrator can use this technique to identify specific columns
in database tables that should be masked. The application database administrator
determines specific columns and flags columns with column comment. This technique will
enable the database administrator to easily identify columns that are to be masked when
creating masking definitions with the Data Masking Pack.

Code

COMMENT ON COLUMN hr.employees.employee_id IS 'MASK

candidate: HR Benefits Policy';
COMMENT ON COLUMN hr.employees.first_name IS 'MASK
candidate: HR Privacy Policy';
COMMENT ON COLUMN hr.employees.last_name IS 'MASK
candidate: HR Privacy Policy';
COMMENT ON COLUMN hr.employees.salary IS 'MASK
candidate: HR Compensation Policy';
The Data Masking Pack format library contains predefined masking formats that are used
to
create a masking definition. A masking definition associates a masking format with a
column in a database table.
There are built-in data masking primitives in the format library and you can define
additional format masks.
The format library can be saved to an XML file so that it can be reused or shared with
another installation of Enterprise Manager Grid Control that uses a different repository.
The Data Masking Pack includes built-in masking primitives for various types of data. The
built-in data masking primitives are described in this table.
In addition to the built-in masking primitives, you can use built-in masking routines, such
as shuffling. This routine is useful when the range of values in a column is not known and
you determine that the shuffling of values in the same table provides a sufficient degree
of privacy and protection.

Graphic
The Types of Built-in Masking Primitives and Routines table contains two columns
Type and Definition. The Type column lists the different types of built-in masking
primitives and routines, and their corresponding definitions are listed in the
Definition column. The different types of primitives and routines and their
corresponding definitions listed in the table are Array List List of values that will
be selected randomly; Fixed Number Number that will be used; Fixed String
Literal string that will be used; Random Dates Range of dates that will be used
randomly; Random Digits Random digits in the specified range; Random
Numbers Range of numbers that will be used randomly; Random Strings
Literals in the specified range; Shuffle Shuffling of original data; Substring
Literal with the specified start position and length; and Table Column The
specified column that is used randomly.

Question

Which data masking primitive or routine is best suited to mask data with a literal
string?
Options:
1.

Array List

2.

Fixed String

3.

Random Digits

4.

Substring

Answer
Option 1: This option is incorrect. The Array List primitive is used to mask data
using a list of values that will be selected randomly.
Option 2: This option is correct. The Fixed String primitive is used to mask data
using a literal string. For example, you can use this to specify where a hyphen
should appear in a telephone number.
Option 3: This option is incorrect. The Random Digits primitive is used to mask
data with random digits in a specified range.
Option 4: This option is incorrect. The Substring routine is used to mask data
using a literal with the specified start position and length.
Correct answer(s):
2. Fixed String
The Data Masking Pack also contains built-in masking primitives that can be used directly
to mask column data. You can also use the built-in masking routines to directly mask the
column data.
The built-in masking primitives and routines can also be used to build a more
sophisticated masking format. If the built-in masking primitives and routines do not satisfy
your data masking requirements, you can create a PL/SQL function to use for masking.
This is an example of data masking of the EMPLOYEES table.
EMPLOYEE_ID
Masking of the EMPLOYEE_ID column is accomplished by using one of the built-in
masking primitives Random Number.
The original values in the EMPLOYEE_ID column of the EMPLOYEES table are 100, 105,
and 110. And the masked values are 468, 975, and 396.
LAST_NAME

The mask for the LAST_NAME column is constructed by referencing another column in the
database Anglo-American last name.
The original values in the LAST_NAME column of the EMPLOYEES table are King, Austin,
and Chen. And the masked values are Jefferies, Smith, and Allen.
PHONE_NUMBER
The PHONE_NUMBER column data mask is built from the masking primitives Bay Area
phone number.
The original values in the PHONE_NUMBER column of the EMPLOYEES table are
515.123.4567, 590.423.4569, and 515.124.4269. And the masked values are
510.555.1256, 650.555.9753, and 925.555.3597.

3. Creating data mask formats

To create a data mask format by using built-in format primitives, perform the following
steps:

Graphic
The Create Format page is opened.

navigate to the Create Format page and specify a name and, optionally, a description for the data
mask format and
These details are entered in the * Name and Description fields. In this example the name entered
is SSN and description given is Social Security Number.

select the data mask primitive (referred to as a format entry in Enterprise Manager) and click Go
The format entry is selected from the Add drop-down list that contains items such as Array List,
Fixed Number, Fixed String, Random Digits, and User Defined Function.
You can also create a data mask format by using multiple built-in data mask primitives. In
this example, a data mask format is created for telephone numbers.
The format was defined as follows:

Graphic
The format entry type and the values for each are listed in a table in the columns
Type and Description respectively. The table also contains the Edit and Remove
columns with the Edit and Remove icons in each cell under these columns.

Array List was specified as the format entry type. A list of values was specified to provide the first
part of the data mask.
The list of values specified are (408), (506), (650), and (925).

555 was specified as the value for the Fixed String mask primitive.
The description given is String Value: 555-

Random Digits was specified with a length of 4.

The description given is Digits Length Range: 4 - 4

Note
Sample values for this format are provided so that you can verify your
specifications.
A PL/SQL function of your own design can be used to mask data. This function is used to
generate a mask for the e-mail address. This code is executed on the target database.

Code
CREATE OR REPLACE FUNCTION hr.email_mask
(orig_value VARCHAR2) RETURN VARCHAR2
IS
emailadd varchar2(100);
BEGIN
SELECT first_name || '.' || employee_id || '.' ||
last_name || '@not_realco.com' INTO emailadd
FROM hr.employees
WHERE email = orig_value;
RETURN emailadd;
END;
Notice that this function does not hide the users real name, but uses the actual first and
last names, and the actual employee ID, in the masked e-mail address.
The masking functions must be reviewed, and results checked, so that the functions
actually provide the level of protection required.
If a reversible function is required, it can be implemented as a user-defined function. You
must assume that if an obfuscation or encryption algorithm is reversible, it will be
reversed. That is, if the original data can be extracted from the masked or encrypted data,
someone will extract the original data.

Code
CREATE OR REPLACE FUNCTION hr.email_mask
(orig_value VARCHAR2) RETURN VARCHAR2
IS
emailadd varchar2(100);

BEGIN
SELECT first_name || '.' || employee_id || '.' ||
last_name || '@not_realco.com' INTO emailadd
FROM hr.employees
WHERE email = orig_value;
RETURN emailadd;
END;
After creating the PL/SQL function that you intend to use for masking, you can specify it
in a data mask format.
In this example, you specify User Defined Function as the format entry type and specify
the previously created function.

Graphic
You specify the function name as hr.email_mask in the User Defined Function
field.
The user-defined function created is applied and the sample masked data is listed in the
Masking Definition: Define Format page.

Graphic
In this example, the database is p2orcl.us.oracle.com, the user has logged in as
system, the owner is HR, the table is EMPLOYEES, the column is EMAIL, and the
data type is VARCHAR2(100). The user-defined function details appear in a table
under the Format Entries section. The function type appears as User Defined
Function under the Type column of the table, and the description under the
Description column as Function Name: HR.EMAIL_MASK.
The following results of the sample masked data are listed under the Sample
Masked Data section:
Den.114.Raphaely@not_realco.com
Winston.180.Taylor@not_realco.com
Elizabeth.172.Bates@not_realco.com
William.171.Smith@not_realco.com
Christopher.153.Olsen@not_realco.com
These samples are generated using different formats. You can use the Refresh
button on this page to regenerate samples.

Note

The domain name used in this example is in an illegal format. The "_" character is
not allowed in domain names.
A predefined PL/SQL function can be specified as a postprocessing function. This
function will execute against the data after it is masked.
This function is created in the Enterprise Manager repository.

Graphic
You specify this function in the Post Processing Function field in the Masking
Definition: Define Format page.
You can create a PL/SQL function such as the checksum function. This function is
executed after the data is masked.
The pbuff parameter is the masked data (new value). Notice in this function that the
calculated checksum is concatenated to the p_buff parameter.
This could be combined with other format functions to provide another piece of a mask
definition.

Code
CREATE OR REPLACE FUNCTION checksum
(rid rowid, columnName varchar2, p_buff in varchar2 )
RETURN varchar2
IS
l_sum number default 0;
l_n number;
BEGIN
FOR i in 1 .. trunc(length(p_buff||'x')/2)
LOOP
l_n := ASCII(substr(p_buff||'x', 1+(i-1)*2, 1))*256
+
ASCII(substr(p_buff||'x', 2+(i-1)*2, 1));
l_sum := mod(l_sum+l_n,4294967296);
END LOOP;
WHILE (l_sum > 65536)
LOOP
l_sum := bitand(l_sum, 65535) + trunc(l_sum/65536);
END LOOP;
RETURN p_buff || lpad(l_sum, 5, 0);
END checksum;

In this example, the checksum function is applied to the masked data. The results are
listed in the sample masked data.

Graphic
The results listed under the Sample Masked Data section are the following:
Susan.203.Mavris@not_realco.com59610
Eleni.149.Zlotkey@not_realco.com58578
Gerald.148.Cambrault@not_realco.com27089
Lisa.168.Ozer@not_realco.com63241
Bruce.104.Ernst@not_realco.com25193

4. Creating data masking definitions

You create data masking definitions because a data masking definition associates a data
masking format with a specified column in the database. If you select a column with
referential integrity constraints defined on it, the Data Masking Pack automatically applies
the same masking rule to the associated tables and columns.
If the referential integrity of the data is maintained in the application instead of the
database, you can add the associated tables and columns via the Related Application
Column capability. This ensures that the data remains consistent whether the referential
integrity of the application is maintained in the database or in the application.
Application-enforced constraints can be defined as related columns for automatic
masking. Data masking definitions can be saved to XML files. The Create like feature can
be used for similar database structures. And you invoke the Mask Wizard in Enterprise
Manager Grid Control.
In this example, the data masking definition associates the built-in Random Numbers
data masking primitive with the EMPLOYEES.EMPLOYEE_ID column.

Graphic
The database in this example is orcl2, the user has logged in as sys, the owner is
HR, the table is EMPLOYEES, the column is EMPLOYEE_ID, and the data type is
NUMBER(6). The user-defined function details appear in a table under the Format
Entries section. You cannot add more than one entry to this table. You can either
edit the existing one using the Edit column or remove using the Remove column.
The function type appears as Random Numbers under the Type column of the
table, and the Number Range: 100000 - 999999 (both inclusive) under the
Description column.
The following are the results of the sample masked data of the Random Numbers

in the EMPLOYEES.EMPLOYEE_ID column which is listed under the Sample

Masked Data section:
895900
491401
The following are the initial steps to create the masking definition:

Graphic
The Database Instance: orcl2 page is opened.
1. on the Administration tabbed page, select Definitions in the Data Masking region
The Data Masking region also contains one other link Format Library.
2. on the Masking Definitions page, click Mask
The Masking Definitions page contains a Search drop-down list, a text field, and the Go and Import
buttons. It also contains a table with the columns Select, Masking Definition, Database, Description,
Columns, and Most Recent Job Ended.
3. specify a name for the mask and the database name, and
These details are entered in the fields Name and Database. In this example, the name entered for the
mask is MASKING_DEF_1 and the database name is orcl2.
4. click Add in the Columns section to select the table and column
A table with columns Select, Owner, Table, Column, Data Type, Format, Foreign Key Columns, and
Dependent Columns is also present in the Columns section. The Dependent Columns column is further
subdivided into two columns Count and Add.
The following are the remaining steps to create the masking definition:

Graphic
The Masking Definition: Add Columns page is opened.

specify the schema, table name, and column name, and click Define Format And Add
You enter these details in the fields Schema, Column Name, and Table Name. In this example,
the schema name is given as HR, table name as EMPLOYEES, and column name as
EMPLOYEE_ID. In addition to the Define Format And Add button, there are also the Cancel and
Add buttons.

select Random Numbers from the Add drop-down list

Other options in the Add drop-down list are Array List, Fixed Number, Shuffle, Table Column, and
User Defined Function.

click Go, and

enter a start value of 100000 and an end value of 999999 and click OK
These values are entered in the Start Value and End Value fields respectively in the Random
Numbers section of the Masking Definition: Add Format Entry page.
The Data Masking Pack automatically identifies all columns related to the selected
column based on referential integrity constraints defined in the data dictionary.
The masking rule defined for the primary key column is also automatically applied to the
associated columns as listed in this example.

Graphic
These details are listed in two tables. The first table contains the columns
Select, Owner, Table, Column, Data Type, Format, Foreign Key Columns, and
Dependent Columns. The Dependent Columns is further subdivided into two
columns Count and Add. In this example, the owner is mentioned as HR, the
table is mentioned as EMPLOYEES, column is mentioned as EMPLOYEE_ID,
data type is mentioned as NUMBER(6), and the foreign key column is mentioned
as 5.
The second table Foreign Key Columns contains the columns Owner, Table,
Column, Parent Owner, Parent Table, and Parent Column. In this example, this
table contains three rows. The owner specified in all the three rows is HR, the
table names specified in each row is DEPARTMENTS, EMPLOYEES, AND
JOB_HISTORY, the column specified in each row is MANAGER_ID,
MANAGER_ID, and EMPLOYEE_ID, the parent owner, parent table, and parent
column specified in all the three rows is HR, EMPLOYEES, and EMPLOYEE_ID
respectively.
If the relationships between tables are defined in the application, you can use the
Dependent Column feature to add associated columns.

Graphic
The Masking Definition: Add Columns page is opened. You can search and add
dependent columns that do not have foreign key constraints defined in this page.
To do this, you specify the schema, table, and column name and click Search.
You can also create a masking definition for a column by using a previously defined data
masking format.
To do this, perform the following steps:

Graphic

The Masking Definition: Define Format page is opened.

after selecting the table and column for masking, click Import From Library to import the
masking definitions from the library and
In this example, the database is orcl2, the user has logged in as sys, the Owner is HR, the table is
EMPLOYEES, the column is PHONE_NUMBER, and the data type is VARCHAR2(20).

select the masking definition that you want to use and click Import
This is done by selecting the option button in the Select column of the table in the Masking
Definition: Import Format Entries From Library page. The selected masking definition contains Bay
Area Phone Number in the Format column, Character in the Data Type column, (408)555-2303 in
the Sample column, and Masking format for San Francisco Bay Area phone numbers in the
Description column.
The data masking format is imported from the library and associated with the specified
column.
Note that the sample masked data is presented so that you can verify your data masking
format selection.

Graphic
The following sample masked data is listed under the Sample Masked Data
section:
(510)555-0900
(650)555-6101
(925)555-2002
(408)555-9103
(510)555-0804

Question
What should be considered when creating a masking definition?
Options:
1.

You can create a masking definition using a previously defined format

2.

You must manually specify related columns

3.

You can use a PL/SQL function you design to mask data

4.

You can use only a single data mask primitive at a time

Answer

Option 1: This option is correct. You can create a masking definition for a column
by using a previously defined data masking format. To do this, you use the Import
From Library feature.
Option 2: This option is incorrect. The Data Masking Pack automatically identifies
all columns related to the selected column based on referential integrity
constraints defined in the data dictionary.
Option 3: This option is correct. A PL/SQL function of your own design can be
used to mask data. You should review the masking functions and their results to
ensure that the function actually provides the level of protection required.
Option 4: This option is incorrect. You can create a data mask format by using
multiple built-in data mask primitives. For example, you could use Array List, Fixed
String, and Random Digits to mask telephone numbers.
Correct answer(s):
1. You can create a masking definition using a previously defined format
3. You can use a PL/SQL function you design to mask data

5. Using the Mask Wizard

The Mask Wizard generates a masking script and produces an impact report that you can
review before submitting the data masking job. The Mask Wizard checks whether there is
sufficient space for the masking operation. If error-level messages result during this step,
masking cannot continue. You must correct any errors before proceeding.
The Mask Wizard also ensures that uniqueness can be maintained and that data mask
formats match column data types. It warns about check constraints and checks for the
presence of default partitions.

Graphic
The Processing: Generating Data Masking Script page is opened. It lists the
database details. The database is p2orcl.us.oracle.com, the user is logged in as
sys, the number of tables is 6, and columns are 12. It also displays the message
The masking script is being generated. This process may take up to 15 minutes to
complete.
The impact report alerts you to many possible error conditions that may occur before
running the data masking definition script. In particular, it checks the space available to
the various user schemas that are involved in the masking process.

The original table, the new table plus mapping tables, and indexes on both original and
new tables exist at the same time during the masking process.

Graphic
These details are displayed in the Mask: Impact Report, which is currently
opened. In addition to the database details, this page also lists the script
generation summary and information.
Under the Script Generation Summary section, information about the Most
Serious Message Severity and date and time when the generation started and
completed is listed. In this example, the Most Serious Message Severity is listed
as INFORMATION.
Under the Script Generation Information section, a table provides information
about the objects and resources examined during script generation and lists
details of any warnings or errors detected. The table contains the columns
Object Name, Object Type, Message Severity, Message Type, and Message.
The script generation step of the wizard produces a script that you can review and save.

Graphic
The script is listed under the Script section. You can opt to view the full script or
the script summary by selecting the radio buttons Script Summary and Full
Script. The Script Summary option is selected in this example. The script
summary is a list of the database commands that will be used to mask the
selected columns. The full script is a PL/SQL script that includes functions,
procedures, and other commands needed during the masking operation. The full
script will be created when you submit the job and will be executed by the job to
perform the masking operation.
The data masking job performs bulk operations to rapidly replace the table containing
sensitive data with an identical table containing masked data while retaining the original
database constraints, referential integrity and associated access structures, such as
indexes, partitions, and access permissions, such as grants.
The script takes advantage of the built-in optimizations in the database. It disables
database logging and runs in parallel to quickly create a masked replacement for the
original table. The original table containing sensitive data is dropped from the database
completely and is no longer accessible.
These are the steps in the masking process:

1. build a mapping table for each column to be masked; the mapping table contains
(original_value, mask_value)
2. drop constraints and revoke grants
3. rename the table
4. create a new table using mapping tables joined to the original table
5. create indexes on the new table
6. collect statistics
7. replace constraints and grants
8. drop indexes on the original table and drop the original table with the purge option, and
9. drop mapping tables

Question
What are the characteristics of the data masking process?
Options:
1.

It runs in parallel with database logging enabled

2.

It performs bulk operations to create a table containing masked data

3.

The new table and the original table exist in the database when complete

4.

The mapping table contains the original value and masked value

Answer
Option 1: This option is incorrect. The data masking definitions script takes
advantage of the built-in optimizations in the database. It disables database
logging and runs in parallel to quickly create a masked replacement for the original
table.
Option 2: This option is correct. The data masking job performs bulk operations to
rapidly replace the table containing sensitive data with an identical table
containing masked data. While retaining the original database constraints,
referential integrity and associated access structures, such as indexes, partitions,
and access permissions, such as grants.
Option 3: This option is incorrect. During the mapping process, the original table
containing sensitive data is dropped from the database completely and is no
longer accessible.

Option 4: This option is correct. The first step in the masking process is to build a
mapping table for each column to be masked. The mapping table contains the
original value and the masked value.
Correct answer(s):
2. It performs bulk operations to create a table containing masked data
4. The mapping table contains the original value and masked value
After you have completed the masking definition, you can save the definition in a portable
XML format called Application Masking Template. This enables you to restore the
masking definition if needed and to share the masking definition with another Enterprise
Manager Grid Control installation.
Application Masking Template is created by using the Export Mask Definition feature.

Graphic
To use this feature, you click the Export button in the Masking Definitions page,
which is currently opened.
You can import a previously exported masking definition that is stored in an XML file into
the Enterprise Manager Grid Control repository. This enables you to use the masking
definition for new masking definitions.

Graphic
You do this using the Import Masking Definition: Select File page, which is
opened. You use this page to import a masking definition that was previously
exported from the Data Masking page. Select the exported file and continue to
import the masking definition into a repository. You can select the file by clicking
the Browse button beside the File field. The page also contains the Cancel and
Continue buttons.
Create custom reports by using Enterprise Manager Grid Control Reports. The 10.2.0.4
version of Data Masking allows you to create custom reports to monitor and audit data
masking operations.
Auditors need to review the following types of information with respect to data masking:

number of masking sessions

columns that were masked

masking formats used, and

dependent columns that were masked (that were not identified by existing constraints)
Although there are no predefined data masking reports in Enterprise Manager Grid
Control, you
can create data masking reports by using the Reports Definition capability.
To create data masking reports, perform these initial steps:

Graphic
The Home tabbed page of Enterprise Manager Grid Control is opened. The other
tabs in the Grid Control are Targets, Deployments, Alerts, Compliance, Jobs, and
Reports.
1. click the Reports tab in Enterprise Manager Grid Control
2. click Create in the Report Definitions page
This page contains the Search section that comprises the fields Title, Owner, Target Type, and Target
Name, and the buttons Delete, Create Like, Edit, and Create. It also displays a table with the various
reports. The table contains the columns Select, Title, Description, Date Generated, and Owner.
3. specify a report title such as, Data Masking Report in the Create Report Definition page
The page has four tabs General, Elements, Schedule, and Access. The Title field is available in the
General tabbed page. Other fields are the drop-down lists Category and Subcategory, and the
Description box. It also contains the buttons Add Category and Add Subcategory.
4. select Security from the Category drop-down list, or create another category such as Custom, and
Other options in the Category drop-down list are Deployment and Configuration, EMR, Enterprise
Manager Setup, Monitoring, and Storage. To create a new category, you click the Add Category button.
5. select Security Policy Overview from the Subcategory drop-down list or create a new
subcategory such as, Data Masking
Other options in the Subcategory drop-down list include Alerts and Policy Violations, Oracle Application
Server Software, Oracle Database Configuration, Oracle Database Software, Oracle Database Space
Issues, Oracle Database Space Usage, Oracle Home Patch Advisories, Policy Groups, and Root Cause
Analysis.
These are the remaining steps to create data masking reports:

Graphic
The Create Report Definition page is opened.
1. click the Elements tab

2. on the Elements tabbed page, click Add

The page contains a table with columns Type, Header, Targets, Set Parameter, and Remove. It also
contains the Layout button, which is currently disabled.
3. select an element type Table from SQL
Various element types are displayed in the table. The element type is selected by selecting the radio
button against the element type.
4. click Continue
5. click Set Parameters
This is done by selecting the icon in the Set Parameters column.
6. enter a header and SQL statement, and then click Continue in the Set Parameters page, and
The header is entered in the Header field as Data Masking Report. And the SQL statement is entered in
the Statement field. The SQL statement enables creating a customized table to return the result set to be
displayed.
7. click OK
Other buttons present are Preview and Cancel.
This is an example of the elements of a Data Masking Auditors report. Note that the
SELECT privilege on the tables named in these queries must be granted to the
MGMT_VIEW user. The ??EMIP_BIND_TARGET_GUID?? string in the query is a named
parameter in the Enterprise Manager reporting framework.

Code
select d.source_name "Database", d.ss_name "Mask
Definition",
d.ss_owner "Author", e.submission_ts "Mask Run Date",
j.job_owner "Mask Run Submitter",
(s.end_time-s.start_time)*24*60*60||' seconds'
"Mask Run Duration" from sysman.mgmt_dm_scopespecs d,
sysman.mgmt_dm_job_executions e,sysman.mgmt_job j,
sysman.mgmt_job_exec_summary s where d.ss_guid = e.ss_guid
and j.job_id = s.job_id and e.execution_id = s.execution_id
and d.source_id = ??EMIP_BIND_TARGET_GUID??

Supplement
Selecting the link title opens the resource in a new browser window.

Learning Aid

Use the learning aid Sample Data Masking Auditors Report to view other
examples of the elements of a sample Data Masking Auditors report.

Summary
In this topic, you've learned how to use data masking.

Sample Data Masking Auditors Report

Purpose: Use this learning aid to view the elements of a sample Data Masking Auditors report.

SELECT privilege
on the tables named in these queries must be granted to the MGMT_VIEW user. The ??
EMIP_BIND_TARGET_GUID?? string in the query is a named parameter in the Enterprise Manager
This is an example of the elements of a Data Masking Auditors report. Note that the

reporting framework.

select s.ss_name "Mask Definition", c.table_schema "Schema",

c.table_name
"Table", c.column_name "Column",e.entry_order "Sequence",
decode(e.rule_type,'RN','Random Number','CC', 'Table
Column','DT','Random
Date','AL','Array List','FN','Fixed Number','FS','Fixed String',
'RD','Random Digits','RS', 'Random String','SH','Shuffling',
'UF','User Defined Function','UT','Post-Processing User
Defined')
"Format Entry",
decode(e.rule_type,
'RN', 'Start Length: '||rule_low||' End Length: '||rule_high,
'CC', 'Schema owner: '||e.table_schema||' Source table and
column:
'||e.table_name||'.'||e.column_name,
'AL',a.arraylist_item,
'FS',fixed_string,
'RD','Start Digits: '||rule_low||' End Digits: '||rule_high,
null) "Format Entry Parameters"
from sysman.mgmt_dm_ruleentry e, sysman.mgmt_dm_scopespecs s,
sysman.mgmt_dm_ss_columns c,
sysman.mgmt_dm_alitems a, sysman.mgmt_dm_job_executions j
where e.rule_guid = c.rule_guid
and e.rule_guid = a.rule_guid (+)
and e.entry_order = a.entry_order (+)

and s.ss_guid = j.ss_guid

and s.ss_guid = c.ss_guid
and s.source_id = ??EMIP_BIND_TARGET_GUID??
order by s.ss_name, c.table_schema, c.table_name, c.column_name,
e.entry_order
select c.parent_schema "Primary Schema", c.parent_table "Primary
Table",
parent_column "Primary Column", c.table_schema "Dependant
Schema",
c.table_name "Dependant Table", c.column_name "Dependant Column"
from sysman.mgmt_dm_infcons_columns c, sysman.mgmt_dm_scopespecs
d
where d.ss_guid = c.ss_guid
and d.source_id = ??EMIP_BIND_TARGET_GUID??

Implementing Data Masking

Learning Objective

After completing this topic, you should be able to

use the Data Masking Pack

Exercise overview
You want to apply data masking to the HR_TEST schema. You have identified the
columns with sensitive data, and want to create a phone number mask for North
American phone numbers. You also want to base a format mask on an existing function,
create a masking definition for the EMPLOYEE_ID column of the
HR_TEST.EMPLOYEES table, and generate the data-masking job.
In this exercise, you're required to create a masking format, a user-defined mask, and a
masking definition, and also generate a data-masking job.
This involves the following tasks:

creating a masking format

creating a user-defined mask

creating a masking definition

generating a data-masking job

Task 1: Creating a masking format

You have started the creation of a masking format named NA_Phone_Number. You have
added an array list with the values two through nine, random numbers 01 through 99, and
a fixed string of "-." Complete the creation of the masking format. Add random numbers
100 though 999, another fixed string of "-", and random numbers 0000 through 9999
respectively. View the sample masked data and confirm the configuration.

Steps list
Instructions
1. Select Random Numbers from the Add drop-down list and click Go
2. Type 100 in the Start Value text box, type 999 in the End Value text box, and click OK
3. Select Fixed String from the Add drop-down list and click Go
4. Type - in the Fixed String text box and click OK
5. Select Random Numbers from the Add drop-down list and click Go
6. Type 0000 in the Start Value text box, type 9999 in the End Value text box, and click OK
7. Click OK

Task 2: Creating a user-defined mask

You want to create a user-defined format mask that preserves the original value. You
have already created the PRESERVE function. Create a new format mask named
"Preserve" that uses this function. Specify a description of "Retain the original value" and
add a user defined function format entry type. Enter hr_test.preserve as the name of the
user defined function, confirm the information message that appears, and confirm the
configuration.

Steps list
Instructions
1. Click Create
2. Type Preserve in the Name text box
3. Type Retain the original value in the Description text box
4. Select User Defined Function from the Add drop-down list and click Go
5. Type hr_test.preserve in the User Defined Function text box and click OK
6. Click OK

Task 3: Creating a masking definition

You now want to create a masking definition for a specific column in the EMPLOYEES
table. Create a masking definition for the EMPLOYEE_ID column of the
HR_TEST.EMPLOYEES table. Specify a name of HR_MASK and a description of "HR
Masking Policy." To return the list of columns, search for the EMPLOYEES table using the
HR_TEST schema. Define and add the format for the EMPLOYEE_ID column, specifying
a random number entry from 10000 to 99999. Then confirm and save the masking
definition. Accept all other default selections.

Steps list
Instructions
1. Click Mask
2. Type HR_MASK in the Name text box
3. Type HR Masking Policy in the Description text box and click Add
4. Type hr_test in the Schema text box, type employees in the Table Name text box, and click Search
5. Select the Select checkbox for the EMPLOYEE_ID row
6. Click Define Format And Add
7. Select Random Numbers from the Add drop-down list and click Go
8. Type 10000 in the Start Value text box, type 99999 in the End Value text box, and click OK
9. Click OK
10. Click Save

Task 4: Generating a data-masking job

You now want to generate the data-masking job. Generate the job by moving through the
next screens in the process. View the impact report and continue to the next screen.
Accept the default job name and specify "oracle" as the host username and password.
Submit the job and then view the job details. Accept all other default selections.

Steps list
Instructions
1. Click Next
2. Click Next
3. Type oracle in the Username text box
4. Type oracle in the Password text box and click Next
5. Click Submit
6. Click View Job Details