IBM DB2 LUW Database Hardening with Data Classification and LBAC

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

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

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

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

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

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.


$> db2

$> db2

$> db2

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


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

Security Labels are created


$> 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


$> 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


$> 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:


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

State of Ohio paper on Data
Classification, Information
Security Classification Policy


See All Articles by Columnist

Rebecca Bond

Rebecca Bond
Rebecca Bond
Rebecca Bond, an IBM Information Champion, industry recognized independent consultant and author of the only published book specific to DB2 LUW security, "Understanding DB2 9 Security", enjoys sharing technical lessons learned from her experiences in government, healthcare and financial consulting roles. Rebecca holds numerous advanced IBM certifications covering all aspects of DB2 and is an expert at balancing the twin needs of robust security and accelerated performance. Her unique background provides a wealth of pertinent database and security puzzlers, which she delights in helping us understand and solve via articles, blog posts and presentations.

Latest Articles