Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Links Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS SQL
Oracle
DB2
MS Access
MySQL
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


follow us on Twitter
Database Journal |DBA Support |SQLCourse |SQLCourse2
 

Featured Database Articles

DB2

Posted Oct 14, 2010

IBM DB2 LUW Database Hardening with Data Classification and LBAC

By Rebecca Bond

IBM DB2 LUW Label Based Access Control (LBAC) provides a robust security protection that is too seldom used. Join Rebecca Bond as she provides some tips you can use to harden your databases with LBAC and Data Classification.

DB2's Label Based Access Control (LBAC) provides a flexible way to construct security labels to protect data at a highly granular level. Unfortunately, I seldom see organizations using LBAC but I think I know why. The common theme seems to be "it's just too hard to use LBAC to harden my databases".

I'd like to politely disagree with that assessment. LBAC setup is easy and once implemented it is a robust security protection. The question becomes, "why does it SEEM to be hard to setup LBAC?"

The Background

The trick with many security controls is to determine "what to protect", "the level of protection needed" and "who needs what level of access" to specific data. For a new environment, this might not be a significant challenge, but for others it could take some serious investigation. If the application is a Commercial Off-the-Shelf application, then the process of determining effective security controls could be even more interesting.

Since LBAC setup correlates with the security structure of the data to be protected, it follows that implementing LBAC is going to be an issue if you don't know what data "should" be protected with LBAC. Then, once you decide what data should be protected, you need to know who should have access and what type of access they'll need. For LBAC, you will need to decide whether to protect at the row, column or row+column level. How do you even get to a point where you can make the necessary decisions, let alone apply LBAC?

May I provide a clue? The answer lies in data classification. Data classification deals with protecting data based on the need for secrecy, sensitivity, or confidentiality. Since LBAC Security Labels are a way to protect the data objects based on the Data Classification Model being used, these two security concepts seem to be made for each other.

What do Data Classification Models look like? Well, it depends. Military models may use Top Secret, Secret, Confidential, Sensitive but Unclassified (SBU), and Unclassified. Corporate models may use Confidential, Private, Sensitive and Public. There are no solid "rules" on Data Classification Models. The ones listed here are frequently cited in Security Manuals, but if there is a better scheme for your organization, please use it instead. You know your business, the folks who write the security manuals write them for the majority of readers. If your organization is part of the minority (like many non-profits), then do what works for you.

Ideally, Data Classification models should be based on regulations, business drivers or business models; should be descriptive enough to convey the protection effort necessary; may be "time sensitive"; and will serve as the foundational documentation for enabling LBAC. Unfortunately, if your organization doesn't have any data classification scheme, then the hidden message to the DBA or SECADM who is setting up LBAC is "all data is the same to us". If all data is the same, and you try to implement LBAC, then the possibility of missing sensitive data that should be protected is high. The possibility of you doing a lot of work to protect data that is not sensitive is also high.

Data Classification methodologies and approaches may become evident if you have some foundational information, but the less you have to go on, the tougher your task becomes.

The primary foundational material that can help (in order of preference) is:

  1. Data Classification Model
  2. Data or Entity-Relationship Model
  3. Accurate, Meaningful Metadata
  4. Referential Integrity
  5. Documentation, Policies and/or Procedures that lend to the task

If you have none of the above, or if the material you have is out of date, then, you may need to "discover" your data classification model so that you can easily set up LBAC. The bad news here is that as a last resort, deriving enough information to design a data classification approach that could map to your LBAC setup may fall back on your shoulders. If so, SQL is your friend. The goal is to use available system information to assist you as you seek sensitive data. While you are looking for sensitive data, also look for patterns that can be matched to a recognizable Data Classification methodology.

There are several approaches to determining what columns are of possible interest. For example, you could create a view that just held a distinct list of all column names, such as:

$> db2 "create view locksmith.colnames as (select distinct colname from syscat.columns)"

The goal is to get a list of column names that seem important from a data classification standpoint. Then when you have a list of column names that appear to lend themselves to a possible data classification approach, find out what tables hold the columns you identified previously:

$> db2 "select tabname from syscat.columns where colname = '<column name>'"

There are many ways to do this, all of them much more elegant than what I provide here, but regardless of your approach, recognize that the output could provide information that could cause a breach. Protect it like you would protect any sensitive information. Only allow access to a small number of individuals who are working on the task.

The Easy Part

The advantage of having the data classification step completed is that now, finally, you are able to intelligently set up LBAC. When you work through the steps, it becomes clear that with a data classification model or methodology in hand, the actual LBAC tasks are simple.

LBAC setup work is performed by the SECADM. The basic workflow is:

Security Label Components are created

There are three types of Security Label Components: ARRAY, TREE and SET.

ARRAY is an ordered set that is hierarchical in nature. Order of the elements is significant. The first element in the list has the highest rank, and the last element has the lowest rank.

TREE is just like it sounds. A TREE is complex with multiple nodes and/or branches.

A SET is not concerned about order. It is simply a collection of elements (which are character string values). You can switch the order of the elements and it would not make a difference.

Examples:

$> db2 "CREATE SECURITY LABEL COMPONENT LEVEL ARRAY ['Top Secret', 'Secret', 'Classified', 'Unclassified']"

$> db2 "CREATE SECURITY LABEL COMPONENT CLAIM_ADJUST TREE ('DEPT_HEAD' ROOT,'TEAMLEAD1' UNDER 'DEPT_HEAD','TEAMLEAD2' UNDER 'DEPT_HEAD','C1LEVEL' UNDER 'TEAMLEAD1','C2LEVEL' UNDER 'TEAMLEAD2') "

$> db2 "CREATE SECURITY LABEL COMPONENT Branch1 SET {'DEVELOPMENT', 'SALES', 'SUPPORT'}"

The LBAC Security Policy is created based on the LBAC Security Label Component

Example:

$> db2 "create security policy BR1 components Branch1 with DB2LBACRULES restrict not authorized write security label"

Security Labels are created

Examples:

$> db2 "create security label BR1.NOLA_SALES component Branch1 'SALES' "

$> db2 "create security label BR1.NOLA_DEV component Branch1 'DEVELOPMENT' "

$> db2 "create security label BR1.NOLA_SUPPORT component Branch1 'SUPPORT' "

LBAC Protected Tables are created or existing tables are altered

Example:

$> db2 "CREATE TABLE Branch1.sales (OrderNum BIGINT NOT NULL,DatePlaced date not null default current date,CustNum Integer not null,Terms smallint not null,GrossAmt decimal(14,2) not null, NetAmt decimal(14,2) not null,SalesRepID integer not null,sec_label DB2SECURITYLABEL) Security Policy BR1"

Security Labels are granted to users, groups or roles

Example:

$> db2 "grant security label BR1.NOLA_Sales to user keesa for READ ACCESS"

Final Thoughts

Now that we've walked through the Data Classification and LBAC explanations, do you think LBAC is difficult, or do you agree with me that LBAC is easy if you have a valid data classification model? I believe that LBAC has gotten a bad rap as being difficult when in reality it isn't difficult at all, as long as you have the benefit of the data classification preparation work.

As you read this article, you may think that I am encouraging you to tackle the task of data classification by yourself. I do not believe this is the role of a DBA or a SECADM. I see it as the responsibility of a Corporate Information Security Officer or a Security Group who can assign the task to the representative Data Owners, oversee the outcomes, and then provide the SECADM with necessary information to truly harden the DB2 databases. That's great in theory, but I also know that often CISOs are not available in every organization and that sometimes DBAs end up doing tasks well beyond their job responsibilities. If you are one of those DBAs, perhaps the information here will help.

Learning Opportunities

Obviously, LBAC is robust and there is a lot more to LBAC setup and configuration options than we have discussed in this brief overview. I'd like to encourage you to learn more about Data Classification and LBAC. Some great free resources include:

LBAC

Channel DB2 IOD Video

Database Magazine, Understanding Label-Based Access Control, Part 1

Database Magazine, Distributed DBA: Label-Based Access Control, Part 2

Data Classification

AntiOnline Spotlight: Data Classification

State of Ohio paper on Data Classification

Datasecuritypolicies.com, Information Security Classification Policy

» See All Articles by Columnist Rebecca Bond



DB2 Archives

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.