The InfoSec Blog

The fatal flaw in IT Risk management

Posted by antonaylward

Is interviewing is a much better method that self-certifications and a checklist, if time and resources allow.
Two points:

In the ISO-27001 forum, my friend and colleague Gary Hinson has repeatedly pointed out, and I fully support him in this, that downloading check-lists from the 'Net and adopting question lists from there is using a solution to someone else's
problem. If that.

Each business has both generic problems (governments, sunspots, meteor strikes, floods & other apocalyptic threats and Acts of God) and ones specific to it way of working and configuration. Acts of God are best covered by prayer and insurance.

Gary recommends "open ended questions" during the interview rather than ones that require a yes/no answer. That's good, but I see problems with that. I prefer to ask "Tell me about your job" rather than "Tell me how your job ... can be made more efficient".

My second point is that risk management will *ALWAYS* fail if the risk analysis is inadequate. How much of the RA should be done by interviewing people like the sysadmins I don't know, but I have my doubts. I look to the Challenger Disaster. I started in the aviation business and we refines FMEA - failure Mode Effect Analysis. Some people think of this in terms of "impact", but really its more than that, its also causal analysis. As Les Bell, a friend who is also a pilot and interested in aviation matters has pointed out to me, "Root Cause Analysis" no longer is adequate, failure comes about because of a number of circumstances, and it may not even be a single failure - the 'tree' fans both ways!

Yes, FMEA can't be dome blindly, but failure modes that pertain to the business - which is what really counts -- and the fan-in/out trees can be worked out even without the technical details. Rating the "risk": is what requires the drill-down.

Which gets back to Donn Parker's point in a number of his books, though he never states it this way. The FMEA tree can be heavily pruned using diligence as he says: standards, compliance, contracts, audits, good practices, available products. The only thing he leaves out are Policy and Training. Policy gives direction and is essential to any purpose, the choice of standards and products, and identifying what training is needed.

All in all, the article at https://blog.anitian.com/flawed-it-risk-management/ takes a lot of words to say a few simple concepts.

 

The real reasons for documentation – and how much

Posted by Anton Aylward

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.

“Impact” is not a Metric

Posted by Anton Aylward

I never like to see the term 'impact'.
Its not a metric.

I discuss how length, temperature, weight, are metrics whereas speed, acceleration, entropy are derived values. In the same sense, 'impact' is a derived value - "the cost of the harm to an asset". The value of an asset can be treated as a primary metric, but how much it is "impacted" is a derived value.

This is the same kind of sloppy thinking, the same failure to identify tangible metrics as we see when people treating 'risk' as if it were something tangible, never mind a metric!

Throwing in the towel

Posted by Anton Aylward

I was saddened to hear of an InfoSec colleague who met with overwhelming frustration at work:

After two years of dealing with such nonsense, I was forced to resign
within two months of discovering a serious security issue which possibly
jeopardized overseas operations. I have since found out that they are
selling the company and didn't want any who knew the problems around.

Hmm.
Thank you.
Speaking as an auditor who occasionally does "due diligence" with respect to take-overs, you've just shown another use for LinkedIn - contacting ex-employees to find out about such problems.

Certainly a lot of employees leaving or being fired in the couple of years before the pending acquisition is a red flags, eh?

The chief value of open source

Posted by Anton Aylward

Now this is interesting!

With code visibility, you and your vendors become partners in trying to make something work. The vendor can't over-promise, but you can't over-assume either. This may be one of main hidden reasons for IT failure, the two sides of the transaction not being on the same page.