Jerome left me an interesting comment on what’s probably my most popular post ever, “Security versus Risk Management.”

Information Security was here before the term Information Risk Management. I still want to know what are the baselines, the metrics, and the guiding standards for Information Risk Management. IRM points to directly the security standards and baselines like ISO 27001.

If it sounds like a duck, quacks like a duck its Security. I believe IRM is a marketing scheme for non-security professional to dictate security controls through business models. Security does use risk management principles to identify threats and should we use counter measures (security) to protect this specific asset and then the security control is introduced and if the control will not be accepted by the company then the risk exception process should be initiated by security. This is the two places in the security model that risk review should be conducted.

Unfortunately, I think he’s confusing Compliance with Risk Management and giving more credit than is due to “Security.”.

While I’m sure some of you will extend and correct me, I’ll define Compliance as “the act of ensuring adherence to a defined set of standards and processes,” for the purposes of this post. Wikipedia has this to say:

In general, compliance means conforming to a specification or policy, standard or law that has been clearly defined.

Thus, Compliance is a mechanism for helping ensure an acceptable level of risk across the controlled entity, usually a company or organization. When done well, compliance is measured against a set of policies, procedures and standards which effectively define the organization’s acceptable level of risk. How that plays out in reality is often quite different, a failure that Jerome identifies.

Just as Security all-to-often ignores appropriateness of a solution to the scale of the problem, focusing on eliminating the risk rather than reducing it to an acceptable level, so Compliance emphasizes following rules without questioning if the rules are really appropriate to the size of the problem or effective at actually reducing the risk to the desired level.

Defining the desired/acceptable/tolerable level (generally used interchangably, but exact definitions of each term are out-of-scope here) of risk is the part of the exercise that is generally not performed, instead deferring to some third party’s published standards (e.g. ISO 27002, CObIT, NIST, etc.) combined with any applicable laws or regulations. This is an attitude I’ve never really understood. Sure, it may be cost-efficient on the front-end, but unless you don’t actually have the option of defining your risk tolerance (i.e. you’re in a regulated environment), then you’re missing out on a huge opportunity for competitive advantage since published standards are generally one-size-fits-all, which is just another way of saying, “fits everyone poorly.”

The stark contrast between the ideal (management determines an acceptable level risk) and the reality (security operations people make arbitrary decisions that effectively define IT Risk tolerance) is something that Alex Hutton has reminded me of in the past.

Sure, a published standard can provide a good baseline or taxonomy of items to be assessed, but should not be taken as gospel for all information, processes and systems across the board, nor should adopting a standard be confused with Risk Management.

Risk Management, as I attempt to practice it, is the act of ensuring that:
1) The scale and scope of the problem are understood;
2) The problem is actually worth having (i.e. should not simply be avoided) or just documented and tracked as an exception (i.e. accepted);
3) The scale and cost of the solution are appropriate; and
4) The proposed management approach actually produces an acceptable level of residual risk for an appropriate level of cost and effort.

The devil, of course, is in the details of how you get to #4.

Risk Management is, first and foremost, about determining how to respond to the risk: Mitigation, Acceptance, Transfer, or Avoidance. Automatically assuming that the solution to a problem or threat is to develop countermeasures (mitigation) is something of a giveaway that someone is not really managing risk.

Not trying to be antagonistic or snarky here, but:

“I still want to know what are the baselines, the metrics, and the guiding standards for Information Risk Management. IRM points to directly the security standards and baselines like ISO 27001.”

NO.

No, no, no, no, no, no, no, no, no. no.

Not even close.

“Baselines” like ISO 27001 or any other ISMS have very little to do with actual “management by and of, risk”. In other words:

1.) An ISMS is not an IRMS (Information Risk Management System - if such a thing exists - and please don’t point me to SABSA as an example).

2.) Much of what various ISMS frameworks call “Risk Management” is actually a heightened vulnerability management cycle.

3.) Managing discrete tactical issues is not, can not, be the sum total of what management by and of, risk, *is*.

Finally, the metrics of risk have to do with *expressing the value* of being at some state of “secure” - and not just the measurement of “how secure” itself.

It would appear that some would think I’m too kind in responding to my critics… ;-)

Yeah, it just hit me wrong. I get too much coffee, I’m in a bad mood, read something that I’m passionate about and BOOM I write something like that :)

Apologies for the dogmatic comments…

no worries. The criticism would be of the delivery, not the content, and I’ll be the first one to agree that sometimes, it just sneaks out.