Developing A System For Identifying And Prioritizing Risk
Discussing COBIT 5 for Risk guide with ISACA
October 7, 2013
Last week, ISACA released a new guide for IT risk professionals that acts as a simple blueprint for organizations -- whether they're looking to comply with COBIT or not -- to identify and prioritize technology risks in order to determine which risks to accept and which risks to mitigate under a reasonable time frame. Detailing well more than 100 risk scenarios in 20 categories of cyber, privacy, and operational IT risks, the COBIT 5 for Risk may provide a useful tool for organizations that haven't already adopted some sort of framework. Dark Reading caught up with Robert Stroud, vice president of international vice president of ISACA, to get the skinny on the new guide, which he refers to as Risk IT.
Dark Reading: One of the big components of COBIT 5 for Risk is its detailed risk scenarios that act as examples for IT risk professionals. Can you walk me through a few of these and how they're used?
Stroud: The risk scenarios typically will be based around some sort of loss-type event. So, for instance, you might have external competitors that might look to cause some way of accessing your business information, or understanding your business, or gaining some sort of competitive advantage.
That might be through just normal, general good business practices, or it could be through other processes. So as you look at that, what you're going to do is take a good assessment of that risk, threat, and opportunity, you're going to understand what it's like, what the impact is, and that will give you a series of processes that you can then put in place to mitigate or accept the risk.
One scenario that we all like to talk about at the moment is cybersecurity, of course. If you think through cybersecurity as a risk exposure, with much of your business on the Internet, you're going to have a situation where you're going to need to determine what the relevant threats are to the business.
It could be productivity, it could be theft of information, denial of service, or it could be the fact that your trade secrets are going to go out the door without you knowing about it from a foreign force. Interestingly enough, the general rule says that you must put strong controls in place, but what Risk IT will do for you is it will go through and take you through the process to understand what the security or the risk threat is.
[Your organization's been breached. Now what? See Establishing The New Normal After A Breach.]
You can then determine what is the probability and what is the outcome, and then reinforce that with you how to put the appropriate processes in place so that you can counter that risk type based on your business type.
So, for instance, if you're a financial organization doing a lot of your transactions over the Web, you're going to want to provide multifactor authentication to your customers, whether they know it or not, so that they can identify themselves to your organization and that you've got valid people accessing accounts.
So it's everything from large threats down to small scenarios you're looking at, and what we're trying to do is have organizations then document all these and quickly put them down in a list. Personally, I use the old Post-it note methodology and brainstorm, put them on the wall, then work with prioritizing an appropriate risk and impact for each of these to the organization. Then we take action. Risk IT gives you a framework and format to go through that whole process, plus some guidance as well.
Dark Reading: Based on your experience, especially as you were working to shepherd the process of framing this new document, what would you say are some of the biggest mistakes organizations are making with regard to IT risk today?
Stroud: There are a couple of easy ones. The first one is the perception that IT will mitigate every risk. And what do I mean by that? Typically, the decision-makers in IT are risk-adverse. They'll put extensive process procedures and controls in place to mitigate everything. I think that's a trap that many IT organizations are overcoming,, which is good. But that is a real trap.
Dark Reading: One of the parts of understanding risk is to measure it, but IT has generally had a hard time measuring security risks. Do you have any advice on how to get those metrics locked in so you can make better risk models?
Stroud: With Risk IT, what we've absolutely done is develop this whole notion that the risk framework is built on a value and benefits realization. Therefore, what you're doing is working through the cascade. You've got your risk factors that you've identified, and you can look at the potential impact to the organization, and then you can link it back to the value of the organization. So what we've actually done in providing this model to balance your risk.
The first thing you're going to do is identify your risk and look at what the impact of that risk to the organization. And how can we actually measure that risk? I have a strong belief if you actually don't understand the impact of the risk in terms of business impacts, how will you consider whether it is a risk that's mandatory for the business to mitigate or to accept?
You might not have truly documented hard numbers for every hour of downtime costs or whatever. But you can come up with measures that are usable across the organization. So that's part of what we take you through in the Risk IT scenarios. You do a risk analysis, you understand your appetite, you understand what the impact is, and the exposure and the cost. And then you can make a determination on how you have to react to that risk.
And then going back, risk is not a one-time event. You then go back on a regular basis, whether that's yearly, six-monthly, or after a risk exposure, and reassess your risk and the cost of it to see if your decision and determination metrics are true.
Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.
About the Author
You May Also Like