IBM DB2 DBAs intuitively deal with risk identification and management every day, yet they may still be impacted by risk management in ways that they may not recognize. Rebecca Bond discusses seven steps to help DB2 LUW DBAs better understand Risk Management.
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
The first step is to identify the "assets" we need to protect. From the DB2 DBA standpoint, that would be data.
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
- Sensitive data/data privacy
- Applying fixpacks or upgrading to a new release
- Ongoing configuration and protection
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
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.)
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 3rd 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.
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.
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.
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.