vertical challenges

Riskkollegiet and Swedish Radiation Safety Authority (SSM) hosted a seminar on Risk Communication.

Informing is not communicating. Still, the prevailing perspective was that of authorities with their experts informing the public, motivating them to change behaviour.

I advocate local ownership of risk. We are the experts on our system, we own and manage its risk. But I must admit that there's a difference between horizontal communication within an enterprise and the challenges for government officials.


continuity through imagination

What does it mean to be planning for the unexpected? Something out of the blue which we failed to foresee, how could we be planning around this?

Firstly, the unexpected might not be unheard of. We don't expect all engines of a jet plane to fail at the same time, but we know this has happened.

Secondly, let's differentiate between cause and effect. Our office might suffer a power outage. We can think of possible causes for this effect, but we won't know them all. Still, if we can imagine the effect we can plan around it.


old rules for new stuff

Why do we need system-specific security requirements? Can't we just comply with instructions? Yes we can, and we must. But it's not enough.

A new system does new stuff (or familiar stuff in new ways) or we wouldn't bother constructing it. New stuff means new risk components (assets, threat sources, vulnerabilities) and consequently new risk. New risk means we cannot simply rely on old rules. We need to rethink how security is implemented for this very system. System-specific security requirements.


from policy to real change

When you want something to happen, you can write a policy. Then what? Is it realistic or does the policy assume components which are not in place? Is it easy to adhere or will compliance be an uphill battle? Now that it's easy, have you anchored the policy, ensuring that stakeholders understand it? Also - are people motivated to adhere? Always remember: awareness is not motivation.

Once again:

  • define "right"
  • make it possible to comply
  • make it easy
  • communicate your policy
  • help people understand
  • build motivation


implementing is not establishing

Implementing something is about solving a problem, finding a workable technical solution, showing that it can be done.

Establishing something is about making it happen in the real world. Communicating the implementation to stakeholders, gaining their acceptance, understanding and commitment to use it. Integrating it into their processes, making it part of their business-as-usual.

From firewalls to access control models - implementing is not establishing. Security folks should ponder the difference.


security is about timing

Beside the who, the how and the where - security is a lot about the "when".

In the best of worlds, you will be able to deter an adversary from even trying to compromise your system.
If not, can you prevent the attack from succeeding?
If not, can you detect the intrusion in a timely fashion?
Once detected, can you contain the attacker and prevent a wider compromise?
Finally, can you swiftly restore your system to agreed service levels?

Better get the chronology straight. Security is a lot about timing.


obligatory quality

I'm reflecting on Business Continuity Planning. The ability to withstand the unexpected and carry on, serving customers as best you can.

Two observations.

The field is compliance-driven. Before the advent of regulation, interest was lukewarm at best. Whatever happened to self-preservation? Haven't we learned anything from 9/11?

Terminology is confusing. Guidance refer to several categories of plans. Relating them and putting them in context is left as an exercise for the layman. A challenge for us educators!


still blogging, a decade down the line

Ten years ago I got an idea. It was rather trendy in those days, having your own blog. One purpose soon emerged though. I wanted to practice my English. The topics have been widely varying, so picking a generic blog title proved useful.

I used to be interested in politics, as became apparent in the first posts:

In recent years I have shifted focus. When I got started within the security realm, I chose to devote the blog to precisely that:

As for the next ten years, who knows? What will be my perspective?


assets and motives

How do they do it, asks the technician.

Why would they do it, asks the criminologist.

Considering motives is a great way to analyse potential abuse. What are the assets? What could make an adversary attempt to compromise the system?

If you run a bank, one answer is obvious. But people are not driven merely by financial gain. Revenge, power, politics, publicity, and let's not forget curiosity ("because I can"). The list goes on.

Get those assets and motives straightened out before calling the technician.


trusting a system

In the best of worlds, we could all trust each other not to compromise security qualities of information - neither intentionally nor accidentally.

In the real world there is not sufficient trust in this regard. Instead, we need to implement protective measures to uphold sufficient information security. When we cannot trust other parties as much as we like to, we need to establish trust in our protective measures instead.

What does it mean to trust a system? How do we create and maintain such trust?