A Guide to Better Risk Management for DB2 LUW DBAs

Overview

When thinking about Governance, Risk Management and Compliance (GRC)
initiatives, given my "security junkie" mindset, I am most interested
in the "R", for risk and its management. Risk is, of course, a broad
topic that impacts many layers of every enterprise, but DB2 DBAs may be
impacted by risk management in ways that they may not recognize.

When you really analyze it, it seems that DB2 DBAs intuitively deal with
risk identification and management every day. An example would be deciding
whether to change a configuration parameter in production that could
potentially make current query performance much better or, perhaps, much worse.
I call the type of risk analysis that the DBA performs to reach a conclusion
the "seesaw" effect. The seesaw board may swing from ground to sky,
but the goal is to always bring it back to the center.

This is similar to our approaches to identify and manage risk for GRC
initiatives. As DB2 DBAs, it is our job to find that balance. Just as it is
important to recognize and mitigate vulnerabilities, it is also important not
to consume resources beyond those required to appropriately manage the
vulnerability. A balance should be achieved, with appropriate controls, which
ensure acceptable levels of protection using acceptable levels of resources for
the given vulnerability.

The reality is that we don’t have the ability to see the future so, while we
benefit from knowledge gained with past experience, we have no absolute
guarantee that our action is the best for the given situation. Without the
ability to predict the future, what tools do we have that allow us to make good
decisions? In the scenario above regarding the production change, if I was the
DBA, I would do a mental "benefit versus risk" analysis based on my
unique understanding of the production environment. I would try to bring the
seesaw board back to center. My past knowledge would be highly beneficial to
the task. The mental steps I would take to reach a decision are similar to ones
that are necessary to identify and manage risk at the database layer. When it
comes to risk management in general, DBAs are pros. We are able to weigh the
risks and rewards quickly and make decisions. Yay us, right?

Hold on a minute before you start patting yourself on the back. There is
more, much more, to risk management than the hundreds of mental decisions we
have to make daily in order to do our jobs as DBAs. Because DBAs are so close
to the data, and since data is integral to all organizations, risk management,
as it relates to that data, is a significant consideration that has only grown
more crucial as new regulations have been implemented. How do you approach risk
management in your organization? Do you have documentation about risk
management that you follow? Are there regulations that spell out how your
organization must manage risk at the data layer?

It is obvious that risk management controls should be considered to protect
data from the possibility of loss (availability), corruption (integrity) or
inappropriate release (confidentiality). For example, the enterprise needs to
be assured that data will be available after a disaster. The flip side of this
is that too much protection comes at a monetary price that your enterprise
might not be able to pay. If your disaster recovery solution recommendation is
to acquire a multi-million dollar new "hot standby" facility, the
funds might not be available to support that solution, even though it would
mitigate the vulnerability.

Risk management obviously comes at a cost, so good analysis of the risk will
weigh the vulnerability, the likelihood of the vulnerability being exploited,
and the cost of protecting against that vulnerability. Again, we’re looking for
the center of the seesaw and, during the analysis, we will make excellent use
of all that unique knowledge you have regarding your enterprise as we attempt
to equalize the equation.

When thinking about risk management, I like this quote from Shon Harris,
"The crux of risk management is that a company has an infinite amount of
vulnerabilities, but a finite amount of resources available to deal with
them." While we would like to 100% mitigate any and all security
vulnerabilities, the cost of doing so is probably too great for any
organization to fund, but fortunately, we have highly intelligent DBAs who can
tackle the effort.

So now that we have the general definition of risk management, let’s pull it
down to the level of a DB2 LUW DBA. How do you proceed to bring the seesaw into
balance? Here’s a clue. First, you have to find the seesaw.

A Hypothetical Example

Step 1

The first step is to identify the "assets" we need to protect.
From the DB2 DBA standpoint, that would be data.

Step 2

Next, we consider the possibilities for identification of risk management
opportunities based on the asset. For data, these would minimally include the
general topics of:

• Backup and restore
• Continuity and disaster recovery
• Privileges and authorization
• Connectivity
• Sensitive data/data privacy
• Applying fixpacks or upgrading to a new release
• Ongoing configuration and protection
• Auditing

Step 3

To begin the process of identifying specific threats, we can further divide
each of these into sub categories. Using the "privileges and
authorization" category as an example, we could consider:

• Privilege escalation
• Privilege abuse
• Segregation of duties
• Ongoing management of privileges and authorizations

Step 4

Taking it another step, let’s consider the category "Segregation of
Duties". At this point, we can begin to analyze the threat. There are a
variety of ways to approach this. For our hypothetical situation, we can take a
qualitative (scenario based) risk approach similar to:

Threat: High level privileges are assigned when not necessary as
defined by job responsibilities

Attack Vector: Users have ability to gain access to data
inappropriately

Vulnerability: Sensitive data is stored in database

Control: Implement DB2 9.7 Separation of Duties

Cost of Control: Minimal

Impact Potential: High (due to possible inadvertent or intentional
sensitive data exposure)

Business Impact Potential: High (Due to loss of customer
confidence. Possible litigation. Costs for remediation.)

Step 5

Now, with a threat to our asset identified and an acknowledgement of the
potential impact if the threat was realized, we can start to decide what to do.
As we consider the options, we might:

• Reduce the risk
• Ex: Use DB2 9.7 Separation of Duties features
• Assign the risk
• Ex: Transfer the risk to a 3^rd party (buy an
  insurance policy)
• Accept the risk
• Sometimes the cost of a counter measure is cost prohibitive
  and an organization simply chooses to accept the risk.

Based on our analysis, what would you recommend? (Keep in mind that a
security auditor, like the DB2 Locksmith, might use similar analysis to
determine whether appropriate security controls are in place.)

Taking the Best Approach

One word of caution, using qualitative risk analysis as we have done here,
is often less effective than using quantitative (cost based) analysis.
Qualitative risk analysis becomes useful when it is difficult or impossible to
assign a monetary value to the asset, as is often the case. Quantitative
analysis involves specific algorithms that address the monetary value of the
asset and determine the cost/benefit ratio for the proposed control.
Quantitative analysis, while effective and highly valuable, is typically not
performed by DBAs. Of course, there are also hybrid methodologies that combine
features from both quantitative and qualitative approaches. The best approach
is simply the one that works for your organization.

Step 6

When the controls have been identified and recommended for implementation,
it is time for action. The number of tasks can often appear overwhelming.
Obviously, not everything can be completed at once. One approach to risk
management is to create a plan of action and milestones (POA&M). Similar to
a project plan, a POA&M assigns responsibilities and completion dates and
can help assure the work is completed in an appropriate timeframe.

Step 7

Decide upon a review cycle based upon any relevant regulations. If
regulations don’t apply, consider factors such as the amount of change (ex:
software, hardware, new users) within a given period to arrive at an
appropriate review cycle.

Additional Thoughts

You may notice that I haven’t mentioned application vulnerabilities. Of
course, we will have application vulnerabilities that must be recognized and
mitigated. The problem is that depending on the application and its use, there
are so many avenues to introduce vulnerabilities that we can’t even begin to
cover them here. It is, however, very important from the DB2 DBA standpoint to
get a list of all applications planned for use and to research known
vulnerabilities (prior to allowing them into your environment). While
researching this information by using the application vendor’s website is a
good start, you should also explore user community boards or security sites to
gain additional knowledge about possible vulnerabilities. The important thing
to remember is that vulnerabilities and potential risk can be managed when they
are known.

Some resources for more information:

IBM Data Server Security Blueprint

CISSP All-in-One Exam Guide, Fifth Edition

Risk Management Guide for
Information Technology Systems

»


See All Articles by Columnist
Rebecca Bond