Tip:
Highlight text to annotate it
X
[ MUSIC ]
POWERS: Hi.
I'm Calvin Powers, managing editor for security at IBM developerWorks.
Today on developerWorks Interviews, we have Randy Stone.
He is an engagement leader for IBM Global Emergency Response Services.
He's based out of Wichita, Kansas, and he was one of the principals behind the section
of IBM X-Force 2012 year-end report that covers risk modeling,
risk assessment and risk management.
Randy, welcome to developerWorks Interviews.
Tell us a little bit about what you do for IBM.
STONE: Hi, I'm glad to be here.
My name's Randy Stone.
I'm an engagement lead with the IBM Emergency Response Service.
We primarily specialize in incident response, intrusion investigations
and malware investigations for IBM and a variety of some of the different clients.
POWERS: Randy, what's the problem with risk assessment methods today?
STONE: I don't know if there's so much a problem, but there's such a huge variety
of different ways you can do risk assessment.
And so much of it isn't really actionable.
There needs to be some method of being able to hand to somebody a threat assessment
and say, do something to solve this.
And so what I was looking for was a simple, easy-to-use method of being able
to develop a framework and just go from ground zero to the very end and be able
to do have something actionable, something that has concrete steps they can do and be able
to evaluate and measure the output from that.
POWERS: The IBM X-Force 2012 Year End Report lays out an alternative vision
for risk assessment and mitigation.
Can you briefly summarize its recommended approach for us?
STONE: Basically it looks at breaking down the risk assessment/risk mitigation process
into four steps -- and it easy to remember because they all start with the letter T.
So the first thing, one of the first steps you could do would be to treat your threats.
Whatever threat that you identify, you develop different mitigation mechanisms or strategies
in order to treat the threat to reduce whatever remaining threat
to a level that's acceptable to the organization.
Another method you could try or you could use is the transfer the threat,
which basically you take the threat and you transfer it
to another entity for them to manage it.
You see this quite frequently in anything from antivirus management
to managed security services, firewall, IDS monitoring.
Basically what you do is you take the threat itself and you offload that to somebody else
and then have them manage that for you.
So after you've evaluated whether you can treat or transfer the threat,
at some point you may get to the decision, it's a business decision
on whether you can tolerate the threat or not.
This may come as a result of treating the threat or transferring the threat,
and you're left over with a residual amount of threat that you then have
to decide whether you're going to tolerate that remaining threat.
If at some point you decide that you're not able to tolerate that,
then your remaining would then be to terminate the threat, whatever the threat might be
or whatever the technology mechanisms that's creating the threat.
It could be something as simple as the threat posed by issuing the employees cell phones,
smartphones with the data that's on it.
And you're concerned about a loss or exposure of data, so you may not be able to adequately treat
or transfer or tolerate the threat.
And so you decide at some point, we're just going to terminate that
and not issue the cell phones, or whatever the case may be
to terminate whatever the basis for that threat is.
POWERS: One of the things I really like about this simplified approach is
that it can be easily summarized.
And in the report there's a great table that kind of walks
through an example of these four Ts.
Can you walk us through Table 3 from that report?
STONE: Sure.
I developed the tables in example, to give an example of different ways you can look
at threats and apply some of the different mitigation processes.
So, for example, in the first line we have the potential threat
of a compromise of root account credentials.
We evaluate the threat, and that evaluation process is going to look at the frequency
with which it's likely to occur and how the impact would be as if it did occur.
So in this case, we evaluate it as high based on being a low frequency,
but root credential exposure could have catastrophic impact.
So from that initial evaluated threat level, we then start looking at what kind
of mitigation process and procedures can we put in place.
And there's a variety of them.
I've listed several of them here such as two-factor authentication,
role-based access controls, network segmenting
so that way different credentials would not be usable outside of a specific network segment.
So, once you've identified some of your mitigation processes, the next step you have
to then look at is implementing, monitoring, and resourcing the mitigation processes.
What we see happen a lot of times is an organization will develop the mitigation
processes, resource it to the minimum level necessary in order to then implement it.
But then as time goes by and because of successful mitigation,
the threat has not been produced, therefore they argue that, well,
we no longer need these mitigation processes in place because the threat is not materialized.
So there needs to be a long-term resource in support
of the threat...of the mitigation process.
Eventually when you go through the entire process you've entered,
you get down to an evaluation of how much residual threat do you have left
after you have implemented your mitigation process.
In this particular example, I came with a low residual risk
because it's still the same low frequency, but because the mitigation processes were going
to have a medium impact instead of a catastrophic impact.
At that point, then management will have to make the management decision of,
is this level of risk acceptable to the organization?
And, if so, then you would proceed with the mitigation of the implementation.
POWERS: That's a great explanation, Randy, and I know on Page 72 of the report you go
into a little bit more detail of this example.
Can you kind of walk us through that a little bit more?
STONE: Sure.
Some of the primary goals here when you identify and implement your mitigation processes,
because you're evaluating your risk based on the frequency of a compromise,
how often it is to occur, and then also based on how bad it is if it occurs...
When you start looking at your mitigation processes, you should look at them
from the perspective of reducing one or both of those --
either reduce the frequency of occurrence of the risk
or reduce how bad it would be if it did occur.
Or, ideally, if you can reduce both, you're going to get a better reduction in risk.
So, using the same example for an access into a system using root credentials,
you might look at some of the different mitigation processes you could use
to reduce the likelihood of the frequency of occurrence.
Examples of that could be some kind of a mechanism, two-factor authentication.
You could implement a jump-box process in front of your server area in order to...you have
to work...go through your jump-box in order to get to the actual server,
so not everybody on the network can touch the servers from everywhere, it has to be routed
through the jump-box and only authorized accounts can do that.
You can also at the same time implement network segmentation with firewalls in order
to prevent anybody from being able to touch those systems
with exception of authorized individuals.
So, during that process you're reducing the frequency with which someone is going
to have contact with those systems and the frequency
with which you're going to encounter that threat.
The other side of that would be to reduce the potential impact of what would happen
if that threat did actually occur.
There's a variety of ways you can do that.
One example for this compromise
of root credentials would be some version of role-based access control...
Which you can take the role and the capabilities of that user account and divide
that up among several smaller accounts, such as you see with like an AIX system,
where you're able to break that root user role into several subroles
and then actually disable the root accounts.
That way, if you did have to get credentials on one of those three accounts,
you're kind of compartmentalizing to exactly what you can do.
And there's a check and balance between one account
that can create user accounts, another one has to approve it.
So to get very far you have to compromise multiple pieces of those different roles.
So, that would be a way, an example of how to reduce the impact
of the exposure or compromise of a root account.
POWERS: Thanks for that great explanation, Randy.
It's great to hear that risk assessment is not such a black art and it's actually something
that can be easily put into practice and turned, as you say, into actionable things.
Don't forget that you can read more about this risk assessment method
in the IBM X-Force 2012 Year End Report at http:ibm.co/xforce12.
That's ibm.co/xforce12.