My Profile
Active Members
TodayLast 7 Days
more...
Awards & Gifts
Online Exams
Fresher Jobs
Our fresher job section is exclusively for fresh graduates! Find jobs for freshers in major Indian
cities including Bangalore, Chennai, Hyderabad, Pune or Kochi
Resources
Find educational articles, blogs, discussion threads and other resources.
Colleges
Find details about any college in India or search for courses.
|
Oracle Label Security -Best Practices for Government and Defense Applications
Posted Date:
Total Responses: 0
Posted By: adarsh kumar Member Level: Gold Points/Cash: 6
|
Oracle Label Security -
Best Practices for Government
and Defense Applications
Oracle Label Security Best Practices for Government and Defense Applications
Oracle Label Security - Best Practices for Government
and Defense Applications
INTRODUCTION
User Label
Authorizations
Oracle Label
Security
Access
Mediation
Confidential
Secret
Top Secret
Based on stringing security requirements found in high security organizations,
Oracle Label Security provides extensive and flexible label based access control
(LBAC) capabilities to support the deployment of multi-level security (MLS)
applications in government and defense environments. Oracle Label Security
overcomes the historic limitations of MLS systems with broad platform availability
and extensive policy controls
that can be finely tuned for
specific environments.
Available for Oracle8i
Enterprise Edition and higher,
Oracle Label Security can be
deployed with Oracle RAC
and Data Guard for scalability
and high availability. This
paper outlines best practices
that can be used to
incorporate Oracle Label
Security into an existing or
new application.
Fig 1. Oracle Label Security Overview
SENSITIVITY LABELS AND ACCESS MEDIATION
Oracle Label Security MLS access mediation works by comparing a sensitivity label
with label authorizations assigned to an application user.
Transparent
Access Mediation
Sensitivity Labels
User
Label
Authorizations
(Database or IdM)
Sensitivity Labels
Assigned To Application Data
Fig 2. Oracle Label Security Access Control Overview
Oracle Label Security Best Practices for Government and Defense Applications Page 3
Sensitivity labels are central to Oracle Label Security. Sensitivity labels provide
sophisticated controls and determine an application user's access to application
data. Sensitivity labels contain a level, optional compartments and optional groups.
Level -- The level is a hierarchical component that denotes the sensitivity of the
data. A typical government organization might define levels confidential, sensitive
and highly sensitive.
Compartment - The compartment component is optional and is sometimes
referred to as a category and is non hierarchical. Typically one or more
compartments are defined to segregate data. Compartments might be defined for
a specific highly sensitive knowledge area or project.
Group - Groups are similar to categories and are also optional. However,
groups can have a parent child relationship. In addition, Oracle Label Security
evaluates groups differently than compartments. Figure 3 outlines the read
mediation algorithm for sensitivity labels
The external representation of a label uses colons and commas to separate the
various components. The sensitivity label Sensitive: Alpha, Beta : UK contains the
level Sensitive, two compartments Alpha and Beta and one group UK. Internally,
Oracle Label Security users a numeric identifier called a label tag for each sensitivity
label. While sensitivity labels and label tags can be created dynamically at runtime,
Oracle recommends defining all sensitivity labels and associated label tags in
advance.
Read Algorithm for Access Mediation
Oracle Label Security mediates access by comparing user label authorizations with a
sensitivity label.
Data level =<
User level
Data has
Grps
User has at
least one
Grp
Data has
comps
User has all
comps
No
Access Access
Y
N
Y
N
Y
Y
N
N
N
Y
Fig 3. Oracle Label Security Read Algorithm
Oracle Label Security Best Practices for Government and Defense Applications Page 4
Incorporating Oracle Label Security
Important to the success of using Oracle Label Security is the analysis process.
Advanced row labeling requires determining how and where to apply Oracle Label
Security.
Step 1: Analyzing the Application Scheme
Analyzing the application means identifying the tables that need an Oracle Label
Security policy applied to them. This is best accomplished with the assistance of an
application administrator or developer who has intimate knowledge of the
application scheme. In most cases, a small percentage of the application tables will
require an Oracle Label Security policy. If the application has an entity relationship
(ER) diagram, it may be useful to annotate on the ER the levels for each entity.
Projects Assets
Step 2: Analyzing the Sensitivity Levels
Once the candidate tables have been identified, the data contained in the tables
needs to be evaluated. The assistance of a data analyst or someone with intimate
understanding of the data will be required. Data levels refer to the sensitivity level
of the data. Unclassified, Sensitive and Highly Sensitive are examples of sensitivity levels.
It’s recommended that application data that may be stored in the future be
considered as well. This will create a robust set of label definitions in Oracle Label
Security.
Unclassified
Secret
Secret
Top Secret
Projects Assets
Step 3: Analyzing the Data Groups
Groups useful for controlling access based on data ownership and for sharing data
across organizations. As with data levels, the assistance of someone with broad
familiarity with business operations can provide valuable assistance with this stage
of the analysis. Examples of groups include United States, United Kingdom, Europe,
Asia.
Secret : Alpha, Beta : US, UK
Top Secret : Alpha, Beta : UK
Oracle Label Security Best Practices for Government and Defense Applications Page 5
Step 4: Analyzing the Data Compartments
Data compartments are primarily used in government and defense environments.
A commercial application may find that data groups are sufficient to provide the
necessary level of access control. However, commercial organizations may find
that compartments are useful for labeling personally identifiable information (PII).
In government and defense environments, compartments are typically used to
restrict access to projects or specialized areas of knowledge.
Secret : Alpha, Beta : US, UK
Top Secret : Alpha, Beta : UK
Step 5: Analyzing the user population
This step requires gaining an understanding of the various roles and responsibilities
of the user population. For example, a user might be designated an analyst, highly
privileged user, or administrative user. This process may require the assistance of
managers and security administrators. After the user population has been separated
into one or more roles or functional areas, a comparison needs to be performed
between the data levels identified in step 2 and the label authorizations of the user
population.. These need to correspond correctly for each table identified during
scheme analysis in step 1. In addition, the organizational structure of the user
population needs to be compared with the data groups identified in step 3.
Step 6: Analyzing special authorizations
Oracle Label Security has several special authorizations that can be assigned to
users and stored procedures. In this step, examine the highly privileged and
administrative users and determine what if any of the Oracle Label Security special
authorizations should be assigned to the user. In general, very few users will
require special authorizations. Please refer to appendix A for a complete list of the
Oracle Label Security special authorizations.
Step 7: Review and Document
The final step before starting the implementation is to review and document the
information gathered. This step is crucial for continuity across the enterprise and
the resulting document should become part of the enterprise security policy.
Include tables, graphs and a narrative discussion to fully explain the results of the
analysis. For example, the document should include a list of scheme tables that
need to be protected and corresponding justification. This document may be
considered sensitive after it is produced.
Oracle Label Security Best Practices for Government and Defense Applications Page 6
ANALYSIS METHODOLOGY
During the analysis it can be useful to create a matrix that compares the
information collected in step 5 with information collected about the actual data.
This technique can help identify operational issues prior to the actual
implementation of Oracle Label Security. This type of analysis can help identify the
authorizations required for a specific job function.
Table
Assets
Projects
I S S:A:US S:A,B:US,UK
User
Data
I::UK
I::US
I
S:A:US
S:B:UK
NoAccess
No Acess
Acess
No Acess
No Acess
No Access
No Acess
Acess
Acess
No Acess
No Access
Acess
Acess
Acess
Acess
Acess
Acess
Acess
Acess
Acess
S:A,B,US
S
No Acess No Acess
No Acess No Acess
No Acess
No Acess
Acess
Acess
Table 1. Label Analysis Matrix
Oracle Label Security Best Practices for Government and Defense Applications Page 7
IMPLEMENTATION
The implementation can be performed using Oracle Enterprise Manager or the
Oracle Label Security command line interface.
1. Perform the analysis steps outlined above
2. Create the Oracle Label Security Policy
3. Define all valid data label components using levels, compartments and
groups using information gathered during analysis
4. Create valid data labels for the policy using the components defined in
step three
5. Assign user population label authorizations and appropriate Oracle
Label Security special authorizations using data gathered during analysis
6. Apply the policy to the application table. If legacy data exists in the
table, it may be necessary to apply the policy to the table with the no
control enforcement option initially. After the policy is applied to the
table, the sensitivity label will be empty and no data will be visible.
Please refer to the section on labeling legacy data. Optionally you can
grant the user or process updating the legacy data the FULL label
security authorization.
7. Update legacy data with appropriate data labels
8. If the policy was applied but disabled, enable the Oracle Label Security
policy and set appropriate policy enforcement options
Oracle Label Security Best Practices for Government and Defense Applications Page 8
LABELING LEGACY DATA
Once an Oracle Label Security policy is applied to an application table with read
control, no rows will be visible until valid data labels have been assigned to each
data row. Several methods exist for labeling data legacy data.
The first method for labeling legacy data simply uses an update statement against
the base table.
UPDATE SALES SET SECLAB =
char_to_label:(‘FINANCE’,’S’)
WHERE REGION_ID = 104;
This statement updates the SALES table and sets the policy label column SECLAB
equal to the internal label tag defined for SENSITIVE in the FINANCE policy and
SALES column REGION_ID is equal to 104.
The second method for labeling legacy data is to switch database connections
during the data load.
CONNECT US_SALES_MGR
INSERT INTO SALES (Col1, Col2, Col3) VALUES
(‘ACME’,......);
CONNECT EU_SALES_MGR
INSERT INTO SALES (Col1, Col2, Col3) VALUES
(‘WIDGET’,......);
If the policy applied to the SALES table includes the LABEL_DEFAULT
enforcement option, the users default ROWLABEL value will be used to set the
SECLAB column.
The third method is to write a labeling function using PL/SQL. Oracle Label
Security label functions are written in PL/SQL. An example of a labeling function
can be found in the Oracle Label Security administrator’s guide. The labeling
function can be added to a policy using an Oracle Label Security API.
The label function could also be written to return an Oracle Label Security label
tag. This type of function should not be added to an Oracle Label Security policy
because it doesn’t the correct data type. However, the function could be called in
the context of an update statement on the target application table.
UPDATE SALES SET SECLAB =
My_Function(sales.region_id);
The fourth method for labeling legacy data is to write a stored procedure that
updates the application table column associated with the Oracle Label Security
policy.
Oracle Label Security Best Practices for Government and Defense Applications Page 9
HIDING THE ORACLE LABEL SECURITY POLICY COLUMN
Oracle Label Security requires a column name to be specified when a policy is
created. When the policy is applied to an application table, the column name
specified during policy creation is appended to the application table. Oracle Label
Security has an option to hide the policy column when the policy is added to an
application table. Hiding the column causes the column to not be displayed during
a SQL Plus table describe operation. Hiding the column also allows SQL
statements which do not specify column names to continue functioning even
though a new column has been added to the application table specified in the SQL
statement.
It’s important to note that the Oracle Label Security policy column can pre-exist in
an application table prior to application of an Oracle Label Security policy. To take
advantage of this the application table column type must be number(10).
Applications can be designed with an Oracle Label Security column built-in.
ORACLE LABEL SECURITY ADMINISTRATION
The account LBACSYS is the primary administration account for Oracle Label
Security. However, other users can be given authorizations to create and manage
Oracle Label Security policies. When an Oracle Label Security policy is created, a
new database role is created. The name of the database role is policyname_DBA. In
the following code, the user LBACSYS creates a policy and gives the user
HR_INFOSEC authorizations to manage policy label components and label
authorizations.
CONNECT LBACSYS
EXECUTE SA_SYSDBA.CREATE_POLICY('HR_SECURITY', ‘HR_LABEL’);
GRANT HR_DBA TO HR_INFOSEC;
GRANT EXECUTE ON sa_components TO sub_admin;
GRANT EXECUTE ON sa_user_admin TO sub_admin;
GRANT EXECUTE ON sa_label_admin TO sub_admin;
GRANT EXECUTE ON sa_policy_admin TO sub_admin;
GRANT EXECUTE ON sa_audit_admin TO sub_admin;
ENFORCEMENT EXEMPTIONS
Oracle virtual private database fine grained access control policies and Oracle Label
Security policies are not enforced during DIRECT path export. Also, Virtual
private database policies and Oracle Label Security policies cannot be applied to
objects in schema SYS. As a consequence, the SYS user and users making a DBAprivileged
connection to the database (for example, CONNECT/AS SYSDBA) do
not have VPD or Oracle Label Security policies applied to their actions. Database
administrators need to be able to administer the database. It would not suffice to
export part of a table due to a VPD policy being applied. Database users who are
granted the Oracle EXEMPT ACCESS POLICY privilege, directly or through a
database role, are exempt from Virtual Private Database and Oracle Label Security
enforcement. The users are exempt from Virtual Private Database and Oracle
Oracle Label Security Best Practices for Government and Defense Applications Page 10
Label Security enforcement regardless of the export mode, application, or utility
used to extract data from the database. EXEMPT ACCESS POLICY privilege is a
powerful privilege and should be carefully managed. The EXEMPT ACCESS
POLICY privilege does not affect the enforcement of object privileges such as
SELECT, INSERT, UPDATE, and DELETE. These privileges are enforced even
if a user has been granted the EXEMPT ACCESS POLICY privilege.
PERFORMANCE TUNING
When creating data labels Oracle recommends defining the associated label tags so
that they fall within the range associated with the level of the data label. For
example, suppose the levels confidential and sensitive have been defined along with
two compartments, alpha and beta. The number associated with Confidential is
5000 and the number associated with Sensitive is 10000. When the valid data labels
are defined the associated label tags associated with confidential should be between
5000 and 10000. For example the data label confidential:alpha might have a label tag
of 5050 and the data label sensitive:alpha,beta might have a label tag of 10055.
Existing composite indexes may be modified to include the column added by
Oracle Label Security to the application table. This can substantially improve
performance for complex queries.
Depending on the application usage, consideration should be given to creating
bitmap indexes on the column added by Oracle Label Security to the application
table. The percentage of unique labels compared to the number of data rows is
usually low.
Oracle partitioning can be used to with Oracle Label Security to physically partition
data based on data sensitivity and provide query optimization through partition
elimination. In some cases, physically partitioning data by sensitivity label may also
be a security requirement.
CREATE TABLE EMPLOYEE
EMPNO NUMBER(10) CONSTRAINT PK_EMPLOYEE PRIMARY KEY,
ENAME VARCHAR2(10),
JOB VARCHAR2(9),
SEC_LABEL NUMBER(10))
TABLESPACE PERF_DATA
STORAGE (initial 2M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS unlimited)
PARTITION BY RANGE (sec_label)
(partition sx1 VALUES LESS THAN (2000) NOLOGGING,
partition sx2 VALUES LESS THAN (3000),
partition sx3 VALUES LESS THAN (4000) );
Oracle Label Security Best Practices for Government and Defense Applications Page 11
PROXY WITH SET_ACCESS_PROFILE COMMAND
Oracle Label Security provides the ability for an authorized user to assume an
Oracle Label Security label authorization profile. The PROFILE_ACCESS
authorization is required to execute the SET_ACCESS_PROFILE procedure. This
Oracle Label Security proxy capability is available so that application architectures
that use one big user models, enterprise user security or proxy authentication, can
use Oracle Label Security.
Oracle Label Security does not enforce a mapping between a physical database
account and the user name specified when establishing label authorizations. For
example, label authorization could be assigned to an IP address.
Applications can utilize one of the many Oracle SYS_CONTEXT variables to
determine which Oracle Label Security label authorization profile should be
specified in the SET_ACCESS_PROFILE command. For enterprise users the
EXTERNAL_NAME SYS_CONTEXT value could be passed to the
SET_ACCESS_PROFILE command.
SQL> execute sa_session.set_access_profile
(‘PRIVACY’,SYS_CONTEXT('userenv','EXTERNAL_NAME');
SQL> execute sa_session.set_access_profile
(‘PRIVACY’,SYS_CONTEXT('userenv',’PROXY_USER’);
SQL> execute sa_session.set_access_profile
(‘PRIVACY’,SYS_CONTEXT('userenv','CLIENT_IDENTIFIER');
Oracle Label Security Best Practices for Government and Defense Applications Page 12
APPENDIX A - ORACLE LABEL SECURITY SPECIAL USER
AUTHORIZATIONS
READ — The READ authorization allows a user to access all data protected by
Oracle Label Security, however, access mediation is still enforced on UPDATE,
INSERT and DELETE operations. Oracle Label Security makes no mediation
check on SELECT operations.
FULL — The FULL authorization turns off all Oracle Label Security access
mediation. A user with the FULL authorization can perform SELECT, UPATE,
INSERT and DELETE operations with no label authorizations. Note that Oracle
SYSTEM and OBJECT authorizations are still enforced. For example, a user must
still have SELECT on the application table. The FULL authorization turns off the
access mediation check at the individual row level.
WRITEDOWN — The WRITEDOWN authorization allows a user to modify the
level component of a label and lower the sensitivity of the label. For example,
application data which is labeled Top Secret: Alpha, Beta could be changed to Secret:
Alpha, Beta. This authorization is only applicable to policies which use the label
update enforcement option.
WRITEUP — The WRITEUP authorization allows a user to modify the level
component of a label and raise the sensitivity of the label. For example, application
data which is labeled Secret: Alpha, Beta could be changed to Top Secret: Alpha, Beta.
Note that the Maximum Level label authorization assigned to the user would limit
modification. This authorization is only applicable to policies which use the label
update enforcement option.
WRITEACROSS — The WRITEACROSS authorization allows a user to modify
the compartments and groups in a label to any valid compartment and group
defined in Oracle Label Security for the policy. For example, if application data
which is labeled Secret: Alpha, Beta could be modified to Secret: Alpha, Beta, Delta
even though the user was not authorized for the Delta compartment. This
authorization is only applicable to policies which use the label update enforcement
option.
PROFILE ACCESS — The PROFILE ACCESS authorization allows a user to
assume the Oracle Label Security authorizations of another user. For example, user
Scott who has access to compartments A,B, and C could assume the profile of user
Joe who has access to compartments A,B, C and D. This functionality might be
useful in an environment where an application uses a single application account for
all application users. The application account could use the PROFILE ACCESS
authorization to immediately assume a designated label security profile when an
application users connects to the system.
Oracle Label Security Best Practices for Government and Defense Applications Page 13
APPENDIX B - ORACLE LABEL SECURITY POLICY ENFORCEMENT
OPTIONS
Oracle Label Security policy enforcement options can be customized for each
policy. For example, a Human Resources policy and a Defense policy can exist in
the same Oracle database and provide different degrees of protection. The Human
Resources application might use the READ CONTROL option and the Defense
policy might use the READ CONTROL and WRITE CONTROL options.
READ CONTROL — Applies policy enforcement to all queries; only authorized
rows are accessible for SELECT, UPDATE, and DELETE operations.
INSERT CONTROL — Applies policy enforcement to INSERT operations,
according to the Oracle Label Security algorithm for write access.
UPDATE CONTROL — Applies policy enforcement to UPDATE operations on
the data columns within a row, according to the Oracle Label Security algorithm for
write access.
DELETE CONTROL — Applies policy enforcement to DELETE operations,
according to the Oracle Label Security algorithm for write access.
WRITE CONTROL — Determines the ability to INSERT, UPDATE, and
DELETE data in a row. If this option is set, it enforces INSERT_CONTROL,
UPDATE_CONTROL, and DELETE_CONTROL.
LABEL DEFAULT — If the user does not explicitly specify a label on INSERT,
the users default row label value is used. By default, the row label value is computed
internally by Oracle Label Security using the label authorization values specified for
the user. A user can set the row label independently, but only to:
A level which is less than or equal to the level of the session label, and greater than
or equal to the user’s minimum level.
Include a subset of the compartments and groups from the session label, for which
the user is authorized to have write access.
LABEL UPDATE — Applies policy enforcement to UPDATE operations that set
or change the value of a label attached to a row. The WRITEUP, WRITEDOWN,
and WRITEACROSS privileges are only enforced if the LABEL_UPDATE option
is set.
LABEL CHECK — Applies READ_CONTROL policy enforcement to INSERT
and UPDATE statements to assure that the new row label is read-accessible by the
user after and INSERT or UPDATE statement.
NO CONTROL — Applies no enforcement options. A labeling function or a SQL
predicate can nonetheless be applied.
Oracle Label Security Best Practices for Government and Defense Applications Page 14
APPENDIX C - ORACLE LABEL SECURITY USER AUTHORIZATIONS
Oracle Label Security user authorizations must be established by a security
administrator before an application user can access an application table protected
by Oracle Label Security. Oracle Label Security user label authorizations are
defined as follows:
Maximum Level — The maximum sensitivity level a user is authorized to access. In
a hosting environment only single level may exist. In government and defense
environments four or five levels might be defined.
Minimum Level — The minimum sensitivity level a user is authorized to write data.
For example, an administrator can prevent users from labeling data as Public or
Internet by assigning a minimum level of Company Confidential.
Default Level — The level used by default when a user connects to the database.
For example, a user can set his or her default level to Secret. When he or she
connects to the system, the default level will be initialized to Secret.
Row Level — The level used to label data inserted into the database by the user
through the application or directly through a tool such as SQL*Plus.
Read Compartments — The set of compartments assigned to the user and used
during READ access mediation. For example, if a user has compartments A,B and
C, he could view data which has compartments A and B but not data which has
compartments A,B,C and D. The read algorithm will be defined in the next section.
Write Compartments — The set of compartments assigned to the user and used
during WRITE access mediation. For example, a user could be given READ and
WRITE access to compartments A and B but READ-ONLY access to
compartment C. If an application record was labeled with compartments A,B and
C, the user would not be allowed to update the record because he or she does not
have WRITE access on compartment C.
Read Groups — The set of groups assigned to the user and used during READ
access mediation. For example, if a user had the group Manager, he could view data
which has the Manager group but not data which had the Senior VP group. The read
algorithm will be defined in the next section.
Write Groups — The set of groups assigned to the user and used during WRITE
access mediation. For example, a user could be given READ and WRITE access to
group Senior VP but READ-ONLY access to group Manager. If an application
record was labeled with a single group, Manager, the user would not be allowed to
update the record because he or she does not have WRITE access on the Manager
group.
|
Project Feedbacks
|
No feedbacks found. Be the first to respond and make money from revenue sharing program.
|
|
|
| Post Feedback |
|
|
You must Sign In to post a feedback.
|
|
|
|
|
Advertise Here
|