go see!

It was just another wild idea. Together with a friend I made several long rail journeys through Sweden. We were in our twenties and found train-riding to be the ultimate pastime. Solving philosophical problems with a soul-mate, a cup of tea in the restaurant car and this lovely land of ours passing by outside the window. It was just for a winter, then we went different ways but the idea was already forming in my head: go see Sweden! There's so much to enjoy, it's a huge country with very distinct seasons. Take a year, spend some money, do it right.

Eighteen years went by and my idea lay deep in the pile of dreams-never-to-be but somehow I couldn't let go. Finally in October 2003 the time was right. I was on a three-week trip through France and Italy and I was bored stiff. Having the Mediterranean glittering outside the first-class-compartment and a ticket for Sicily in my wallet was just fine, the train-tour had cost a small fortune but I was homesick.

By the time of Christmas I made the decision. I had been saving vacation time without any particular purpose. Now here was my purpose. On New Years Eve I went to Stockholm Central Station and purchased a twelve-month first-class rail-pass. The time had come to go see Sweden 2004.

(edited, previously posted 2005-03-03)

security without trust

The effect of investing in security depends on the actual level of security achieved in the system. It also depends on the degree of trust from my stakeholders.

Imagine a system with perfect security which - for whatever reason - isn't trusted by those who should depend on it. Their distrust might appear totally irrational to us. That doesn't matter. It's not our call. Our effort is a failure.

Putting all our money into "actual" security and ignoring the need for assurance is a recipe for failure.

on elusive security requirements

A system should have certain properties (but not others). It should do certain things (but not others). It should be handled (or interacted with) in certain ways by certain parties (who should not be allowed to do things differently) while an authoritative party enforces this state of affairs by means of policy.

All this is subject to change without notice due to changing factors such as regulations, architecture or risk.

Functional, non functional or derived - no wonder security requirements are elusive.

question the cook book

Security is a process. It keeps the bits and pieces together over time - risk, requirements and testing. Case closed? Maybe not.

Legacy systems, management priorities and sourcing are three examples of circumstances that challenge our theories and force us to question the cook book.

What do you do when the terrain simply doesn't match the map? Be flexible. Don't lose the process - you will be needing it more than ever! - but identify hurdles, prioritize which ones to confront, mitigate and adapt.

anything but harmless

Sometimes, security is portrayed as a technical matter. Choose this or that mechanism and be safe.

In reality, security is about taking a stand. There is nothing neutral about protecting something or someone from something or someone. The choice could be easy, like in safeguarding the confidentiality of patient information from unauthorized eavesdroppers. It could also be controversial, like in helping one party listen in on the lawful activities by another party.

Security is anything but harmless.

build security in

Like any aspect of quality, system security is not bolted-on, it is built-in. What does it mean to build security into a system? Think people, processes and technology - in that very order.

Find the right people to envision, design, implement, deploy, operate, evolve, maintain and decommission your system. Equip them properly. make sure they remain committed to upholding security.

Let these very people create, execute and maintain robust usable processes for the system life-cycle.

The rest is technology.

things will change

Information systems are often viewed from a static, technical perspective. What goes in, what comes out, what technical protective measures are in place? That's all good and fine. But things will change, in ways not foreseen.

Today's elegant static view will soon become obsolete. This is one reason why I'm more concerned about people and processes. When things change, how do we ensure that adequate security is being upheld? What administrative protective measures are in place? How do we manage risk?

wordless isn't worthless.

Formal communication tends to be verbal. Words, lots of words.

Not so between individuals. We send and receive at many 'frequencies'. Think body language. The performance Your Majesties illustrates what happens when a given set of words are spoken in radically new ways.

Risk communication is difficult. Sometimes, words fail us. How can we express risk, conveying a sense of urgency to another party? Do we have to make do with words alone? Could artistic expressions somehow help us?

Wordless isn't worthless.

accepted, how?

How does a risk get accepted?

Imagine the following conversation.
- why haven't we done anything about this issue?
- we decided to accept the risk.
- who did, when and why? where is this documented?

Risks are accepted every day when issues emerge in a conversation and we choose to move on, rather than do something about them. Such acceptance is informal and rarely traceable. Contrast this with formal risk assessments where acceptance is explicitly documented as the preferred treatment strategy.

accepted, by whom?

Acceptance is often a reasonable strategy for InfoRisk.

Who does the accepting?

If you have one omnipotent Risk Manager who calls the shots, the answer is simple.

But, to create a risk culture, Risk Management will have to take place on multiple levels.

Suppose the Network Dept assess a certain risk, can they accept it on behalf of the organization? If yes, how are they in a position to judge (and accept) the business impact? If no, how can Risk Mgmt be scalable unless responsibility is delegated?