Rambling on about risk assessment

I was reading with interest a two-part blog posting from Chris Hayes on his Risktical Ramblings site. It’s a detailed and thorough run through of a risk assessment process. I actually think it’s very instructive and those of you who want to learn about how many information security professionals approach assessing risk should read through it. That’s not supposed to be complementary. Sorry.

The problem is that it’s completely impractical. I’ll take a recent, and fairly typical situation as an example. I was taking issue with the manner in which remote access was being provisioned for a third party vendor to connect to a system hosted by one of our European business units. To cut a long story short, it was not only a breach of policy but highly insecure. I wanted the access to be disconnected, the business unit director wanted my risk assessment. And he didn’t want to wait for it.

To quote Chris Hayes, spending time on working out the expected

effectiveness of controls, over a given timeframe, as measured against

a baseline level of force was not going to pacify an angry Italian fearful that my decision was going to cost him money. He wanted my explanation of the risk and more importantly, what I was going to offer as a solution to keep his business functioning.

Information security risk assessment does not require detailed and scientific analysis. This is not rocket science, it’s business. If you have a problem then you need to be able to explain the reasons why in a language that even somebody in the marketing department can understand. Risk models have their place, it’s useful to understand the components that create risk but most of what I read that’s aimed at the information security market is less than useless for working with on a daily basis.

When I need to document a risk assessment I use a very simple form: list the threats, state the level of vulnerability, list the associated operational costs and potential revenue hits. High, medium, or low risk? Describe the controls and options. Write up who needs to do what, and how much of their time it’s going to take. Job done.

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

Stuart, I guess since you haven't had an opportunity to be trained in and use the risk analysis method that Chris describes, you should be given a pass on your criticism regarding impracticality. Likewise, you haven't had an opportunity to leverage the method in dealing with management on tough issues like the one you describe. Speaking from personal experience, being able to use a well-refined model to describe exactly how you derived the level of risk and what control options are likely to be most cost-effective, can change your relationship with the "angry Italians" (or Norwegians, Brits, etc.) in your organization. They gain a whole new appreciation for the rationality, business focus, and rigor of how we do our jobs. Perhaps someday you'll have an opportunity (and the interest) to learn about it, try it, and then decide if it's practical. In the meantime, best of luck with your current approach. Cheers, Jack
Cancel

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close