Enterprise Miracle Management

Can't Enterprise Risk Management guarantee against failure?

It's like asking why there are still fires now that we've hired firefighters. ERM could use a good portion of expectation management. If someone believes that nothing could ever go wrong since we have an ERM function, they need a reality check.

Not all existing risk will be discovered.
Not all discovered risk will be mitigated.
Not all mitigated risk will be eliminated.

Be sure to equip your firefighters but don't go expecting miracles.

Read more about Risk Management Failures at Sonia Jaspal's RiskBoard.  

guided by risk

How is the risk paradigm relevant during a breach?

If the breach relates to risks previously documented, we know risk level, vulnerabilities and assets involved. Incident Management is also informed in another way. We will have to pick strategies for containment and recovery. Each strategy carries risk. How do we choose? By swiftly assessing risk. (The incident doesn't wait.)

So - just like incidents inform future risk management, impromptu risk assessments can guide ongoing incident handling.

a useless paradigm?

Some argue that risk is a useless paradigm when a breach has occurred. It is happening, probability 100%, why theorize further?

To me, this analysis is surprisingly shallow.

Being under attack is not a binary thing, it is not about an enterprise losing its virginity once and for all. Sure, we must deal urgently with the current incident. But there's a host of potential events awaiting tomorrow which need to be foreseen and prevented.

Today's incident enlightens us in assessing current risk.

creativity is key

Why all this fuss about creativity? From a systems perspective, creativity is important for two reasons.

Partly because of disruptive change. When change occurs, we need new ways to look upon ourselves. These can't be found in school books.

Partly because of complexity. Even if our environment was perfectly stable, we need to frame existing complexity - making it understandable, controllable.

So, creativity is key. That said, ideas are not enough. Someone will still have to be implementing them!

Read more about Creativity@Risk at Sonia Jaspal's RiskBoard. 

motivated we stand

In order to limit (hopefully avoid) InfoSec risk, we use controls. These can be technical or administrative.

Either way, they will involve humans who need to understand and accept the controls. In general, we may require people to wear seatbelts, pick complex passwords or quit smoking at work. Co-workers will find ways to circumvent controls that they’re not motivated to accept.

Any technocrat can pick the strongest control. A wise leader will consult and motivate his team before implementing it.

Read more about employee disengagement at Sonia Jaspal's RiskBoard.

learning from incidents

In Infosec, there are risks (what could happen) and incidents (what has happened).

We deal with risks proactively by asking questions. Identify, describe, quantify and so on. We treat the risks, hopefully avoid them.

Incidents call for a reactive posture. How can we recover?

A mature organization prefers to be proactive as opposed to reactive. One way is to interconnect the two approaches. Analyze your incident history so that recurring issues can be addressed. Don't forget that rear mirror.

Read more about distinguishing between risk and issue at The Innovation of Risk.

future in the rear mirror

Security risk is uncertainty about undesirable future events, a lack of control. To reduce uncertainty, we'd need a way to look into the future. And we can.

Having identified threat sources and vulnerabilities relevant to our assets, we construct risk by formulating realistic events. Neither objective nor scientific, it does provide a crystal ball of sorts.

Also, what has already happened? History is an indicator of what might happen. Spotting the future in the rear mirror could be our best option.

the risk you wouldn't want

There are different kinds of risk. Some are desirable. Doing business means taking risk to make money. The risk appetite will vary between companies and over time.

Other risks represent things going wrong in a company's everyday activities. We call them operational. You won't have an appetite for them. Instead, we talk of risk tolerance. When do you decide to close a factory, do things differently to avoid the potential cost? Operational risks are risks you don't want. Infosec risks among them.

meet your infosec risk

Consider your asset, something information-related worthwhile protecting. Mind your threat sources. Who or what could attack the asset, intentionally or not? Think vulnerabilities. Is there a weakness which could be used? Now: is there a combination where a relevant threat source can exploit a known vulnerability to compromise your asset? Just how bad is this potential harmful event? Quantify with respect to likelihood and impact. And there you have it. Meet your information security risk.

no such thing

If I could only... would that make me safe? Is there a recipe for removing or mitigating all risk? Not in life. Not in software. In practice, everyday software is infinitely complex. Foreseeing and countering everything that could go wrong - however desirable - is not realistic. That's why I prefer not to talk about "secure" software. A desirable goal indeed but not within our reach. That'd be promising something we can't deliver. Software security is not absolute. It's about gray-scales and risk.