The InfoSec Blog

System Integrity: Without Integrity you don’t have Security

March 24th, 2012

Surely compliance is binary?

Call me a dinosaur (that’s OK, since its the weekend and dressed down to work in the garden) but …

Surely COMPLIANCE is a binary measure, not a “level of” issue.
You are either in compliance or you are not.
As in you are either deal or alive.

Now it may be that some “standard” (such as ISO27001) has a number of clauses and its possible to be in compliance with some and not with others, and so fall into the delusion that you are “82% compliant” with the standard. This gets back to the silliness of exams where you are not expected to be able to answer all the questions and so the pass mark was 65%. In actuality its a recipe for disaster; if you’re only required to have 65% of the items complaint to “pass” then the standard is a joke.

It brings to mind the advert for the disinfectant that “kills 99% of all known germs“. OK, but that remaining 1% is highly deadly and highly infectious.. And then what about the Rumsfeld Class III germs?

No, really, would you let a military expedition or a group of mountaineers attempting to scale Mt Everest with only the “passing grade” – 65% – of the equipment (be if food, ammunition, ropes, insulated clothing, whatever) that they needed?

So there’s this marriage ceremony and the groom only manages to get 65% of the way to the church; is that a passing grade? Ask the bride what she thinks.

No, compliance is binary.

 

Compliance Bridge - Broad requirements so that...

Compliance Bridge - Broad requirements so that clients are Ready, Willing and Able to comply. (Photo credit: Wikipedia)

Enhanced by Zemanta
March 18th, 2012

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
August 24th, 2011

The real reasons for documentation – and how much

he documentation required and/or needed by ISO-2700x is a perenial source of dispute in the various forums I subscribe to.

Of course management has to define matters such as scope and applicability and the policies, but how much of the detail of getting there needs to be recorded?  How much of the justification for the decisions?

Yes, you could have reviews and summaries of all meetings and email exchanges ..

But that is not and has nothing to do with the standard or its requirements.

The standard does NOT require a management review meeting.
Read the rest of this entry »

July 2nd, 2011

Risk Models that hide important information

Some people seem to be making life difficult for themselves with risk models such as “Impact * Probability” and as such have lead themselves into all manner of imponderable … since this model hides essential details.

I discuss the CLASSICAL risk equation in my blog
http://infosecblog.antonaylward.com/2010/05/19/the-classical-risk-equation/

There is a good reason for, no make that MANY good reasons, for separating out the threat and the vulnerability and asset rather that just using “impact”.

Any asset is going to be affected by many

  • threats
  • vulnerabilities
  • controls

Any control will almost certainly address many assets and in all likelihood deal with many threats and vulnerabilities.

Any reasonable approach will try to optimise this: make the controls more effective and efficient by having them cover as many assets, threats or vulnerabilities as possible.

As such, the CLASSICAL risk equation can then be viewed as addressing residual risk – the probability AFTER applying the controls. Read the rest of this entry »

|