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 Sep 9, 2010

IBM DB2 LUW Security Helps DBAs Beat the Odds

By Rebecca Bond

IBM DB2 DBAs fight many security battles, but they don't have to fight them alone. Rebecca Bond, the IBM DB2 Locksmith, shares five tips to help DB2 LUW DBAs beat the database security odds.

I'm going to be presenting a session on IBM DB2 LUW Security at IBM Information on Demand 2010 In Las Vegas in October. I guess the whole Vegas theme is getting to me. I have been thinking a lot about "odds" recently. I don't just mean "odds" like the ones at the gaming tables, although that is part of it. Strange, not normal or not expected events are also odd. Whether it's odd as in 'strange anomalies' or odds as in 'Las Vegas gaming', we can learn a lot about DB2 LUW Security by learning about the odds.

DB2Locksmith's Take on Improving the Odds:

Fixpacks

Keeping your IBM DB2 databases at the current release increases the odds that you have the most robust security posture available. Admittedly, applying a fixpack involves planning and testing cycles, which may take some time. That's why many organizations don't keep their database environments up to date. However, the effort to apply a fixpack is minimal when compared to the havoc that can follow a data breach.

You can use the db2level command to show the current fixpack level if you don't already know it. The db2level command is described in the IBM DB2 Database for Linux, UNIX, and Windows Information Center.  IBM provides a list of recommended DB2 LUW fixpacks and download links.

Classify and Prioritize

Play the odds when it comes to classifying and prioritizing security tasks. Database security can look like a vast empty wasteland when you are the DB2 Security Administrator (SECADM) who is tasked with initial setup work. The only hope you have of surviving is to take it a step at a time. Play the odds and apply the Pareto 80-20 rule (which roughly means 80% of the benefit comes from 20% of the effort) by choosing to work the tasks that will provide the biggest bang for your security approach.

For example, if you are implementing Label Based Access Controls (LBAC), pick the objects that hold the most sensitive data and set up LBAC for them first. If you have a set of tables that hold Personally Identifiable Information (PII) data such as Social Security Numbers, Dates of Birth or information that deals with financial details; those may qualify for your attention before tables that hold less sensitive information.

Some helpful information on LBAC can be found at Label-based access control (LBAC) overview. If you want to know more, check Channel DB2's IOD videos,IOD - LBAC with Roger Sanders.

Analyze the Clues

Look for odd things. Anomalies provide clues regarding security. If you are a network security junkie, you know that most network intrusion detection systems are designed to specifically identify and alert about events that are different from known activities. The reason this is such a successful security benefit is that many times a security problem can be detected early simply by observation of a non-normal event.

When thinking about anomalies and intrusion detection possibilities at the database layer, consider the example of something as mundane as a database snapshot for all applications. If you find an application listed that is not one you recognize, that odd event might indicate a current or future security issue. Further investigation may verify that this was an approved application. At the other extreme, the outcome of this research could indicate something more serious, such as unapproved or escalated access to the database and that one odd event could lead to a full-scale forensics examination. Odd things (anomalies) are the clues that can help DBAs sort the malicious from the normal and decrease the odds of data exposure.

If you want to learn more about DB2 Snapshots or the Snapshot Monitor SQL Administrative Views and all the interesting information they can provide, try these resources:

From the DB2 Information Center:

The DB2 9.7 Database Monitoring Guide and Reference

Audit

A great way to find odd things is through auditing. If you aren't using DB2 Auditing because you have concerns about performance, you might want to reconsider now. I know that some shops enabled DB2 auditing on past releases of DB2 and unfortunately experienced performance issues that left DBAs with little choice but to sacrifice security for performance. The lack of granular auditing settings was another concern when using native DB2 auditing with older versions of DB2. Since DB2 9.5, those concerns have been addressed, so don't avoid using DB2's native auditing capabilities until you give it another try.

If you don't have time to create and maintain a native DB2 auditing solution, there are several third party database auditing applications that can offer a robust auditing approach. If you are fortunate enough to have funding, purchasing a third party application to meet your auditing requirements is definitely an attractive option for busy DBAs. There are numerous auditing applications on the market today that support DB2 LUW while providing greatly enhanced functionality and ease of use options that can well justify the purchase price.

Regardless of the auditing solution you choose, native or purchased, the information captured in the audit trails will be invaluable. The output should be reviewed, analyzed and saved for an appropriate amount of time. Audit trail output can be used to better understand what normal activity looks like. It is also one of the first things to look at in a forensic investigation if a breach should occur.

If you want to read more about native DB2 Auditing, the DB2 9.7 Database Security Guide is a good document to review.

Educate

The more you know about DB2, the better the odds that you can protect and defend the database. Sometimes we need to defend against hackers, but always we need to defend against unintended consequences. Either way, knowledge is the key to that defense. The more we learn about security and DB2 in combination, the better the odds that we can prevent data loss whether it occurs due to a breach or just due to some unexpected event.

Continuous learning is so much a part of the security landscape that most security certifications require continuing education hours annually to ensure that the professionals who hold these certifications maintain relevant knowledge. Stale knowledge and security are not a good combination.

There are literally thousands of opportunities for free education. Plug the terms "DB2 Security" in to a search engine and you will get thousands of hits. Some of those will be more valuable than others, so remember that "free" is worth exactly what you paid for it, use the results with caution and validate what you find to prove to yourself that the information is valid.

If you're serious about security you should also expand your education to include security concepts in general. I am a big fan of the CISSP certification for DBAs because preparing for the exam forces you to look at the whole of security while also understanding the security approaches for individual pieces of the technical architecture.

Here are some of my favorite free resources (some do require registration):

Final Thoughts About Odds

While there is no "guaranteed" security, there is much that can be done to switch the odds in our favor.

If you'd like to know more about DB2 LUW security odds, join me on the DB2Night Show in October. Free registration is available at The DB2Night Show Episode #30- Applying the Vegas approach to Win Big with DB2 Security, Rebecca Bond.

» See All Articles by Columnist Rebecca Bond



DB2 Archives

Comment and Contribute

 


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