Warning: include_once(/home/antonaylward/InfoSecBlog/public/wp-content/plugins/wordpress-support/wordpress-support.php): failed to open stream: Permission denied in /home/antonaylward/InfoSecBlog/public/wp-settings.php on line 304

Warning: include_once(): Failed opening '/home/antonaylward/InfoSecBlog/public/wp-content/plugins/wordpress-support/wordpress-support.php' for inclusion (include_path='.:/usr/local/lib/php:/usr/local/php5/lib/pear') in /home/antonaylward/InfoSecBlog/public/wp-settings.php on line 304
About ISO 27001 Risk Statement and Controls « The InfoSec Blog
The InfoSec Blog
18Mar/12

About ISO 27001 Risk Statement and Controls

On the ISO27000 Forum list, someone asked:

I'm looking for Risk statement for each ISO 27k control; meaning
"what is the risk of not implementing a control".

That's a very ingenious way of looking at it!

One way of formulating the risk statement is from the control
objective mentioned in the standard.
Is there any other way out ?

Ingenious aside, I'd be very careful with an approach like this.

Risks and controlsare not, should not, be 1:1.

The Risk Management Process for IT Systems acc...

The Risk Management Process for IT Systems according to ENISA, following ISO 27005 (Photo credit: Wikipedia)

Some controls are there to support other controls. And don't forget that some controls are detective and a control that 'detects' the functioning of another control is perfectly valid.

We've often spoken of "baseline controls", that is controls which should be in place "regardless". Well OK, context matters. The baseline for a bank and there baseline for a power plant will differ, but they will also have a lot in common. One common branch might be a yes response to 'are you connected to the Internet?'

A "Yes you are connected to the Internet" will produce a plethora of threats (note: *threats* not risks!) that will keep you busy all month working through to determine the risks, and for almost all of them the control will be "configure the firewall...".

You do have a firewall as part of your baseline, don't you?
(And you took it out of the box and installed it at a choke point, didn't you?)

Another issue that often come up on this forum is that of assets.
Now if it was me, I'd start with the assets. There are a number of reasons for that. First and foremost, this is all about protecting those assets. They are also a lot easier to identify than threats or vulnerabilities 🙂

So we get back to "what is the risk of not implementing a control".
The control objectives are, ultimately, to protect the assets, by various means. So you need to ask that question in terms of the assets.

Another way of looking at it is enumerate the assets and enumerate the controls and establish the relationships. Are there assets that don't have controls protecting them?

diagram showing threat agents, attack vectors,...

diagram showing threat agents, attack vectors, weakness, controls, IT asset and business impact (Photo credit: Wikipedia)

I admit there is more to it than that; controls may be inadequate or superfluous. There is a tendency to implement easy ones.

Donn Parker has written some excellent papers on selecting controls.
They were published in the ISSA Journal back in 2010.

http://www.google.ca/search?q=parker+%22Security+Control+Selection+Principles%22

 

Enhanced by Zemanta

Posted by Anton Aylward

Comments (0) Trackbacks (0)

No comments yet.


Leave a comment

No trackbacks yet.