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):
- IDUG, The
Worldwide DB2 User Community - Susan
Visser’s excellent blog - PlanetDB2
- The CCCure Family
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.