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.