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?


Stockholm Criminology Symposium

This week I attended the 9th Stockholm Criminology Symposium. Not being a practitioner in crime prevention and having taken just an introductory course, some of the research stuff is way beyond me. So, why go there?

Applied InfoSec can use input from more mature fields. Preventing bad things from happening. Motivating individuals to choose the narrow track. Governing change.

Also, I enjoy venturing out of the silo, meeting people more knowledgeable than myself with entirely different experiences and tools.


change is in the air

I've been an employee of the Swedish bank SEB since 1991, initially as a database specialist, then working with applied information security since 2006.

Having spent 23 good years in the financial sector, following this summer I will take up a position as consultant in the great team of Konsultbolag1 InfoSec AB.

As always in consulting, what I will be doing will be up to our customers, but I look forward to driving change within the field of security by means of teaching, coaching and mentoring.


Inter-Organizational Information Risk

Information handling can be outsourced. Accountability can not. When things go wrong, the image loss remains with the owner.

Risk is managed at multiple levels.

Organization: clarify boundaries of responsibility, align policies and practices, establish process
System: assign risk ownership - what if our assets are transmitted through your infrastructure?
Individual: which person carries which role?

When systems transcend boundaries of organizations, how do we make sure the ball is not dropped?


can Security Management be agile?

The waterfall approach to building systems has passed its prime.

How should Security Management deal with this?

Security is a quality of information. Structures for upholding quality must align with practices of the enterprise. If business calls for flexibility, Security Mgmt should enable robust systems through usable structures, in accordance with how the organization chooses to govern and manage itself.

Is this a challenge? You bet.

Can Security Mgmt be agile? To stay relevant, it must.


awareness is never enough

We talk a lot about user security awareness.

But awareness is never enough.

I might be aware that you forgot to close the window on a rainy night. This won't help unless I care to close it or remind you. I might be aware that my password could be misused by a malicious individual. This won't help unless I care to make an effort to protect it.

I must care enough to do the right thing when it would be easier not to. I must be committed. So, let’s stop parroting awareness as an end goal. It’s not.


applying principles for societal security

At a FoF seminar, The MSB today suggested 10 principles for societal security.
I interpreted eight of them for InfoSec Management.
  • earn and maintain trust among stakeholders
  • communication is an indicator of a safer organizational systems environment
  • readiness begins and ends with the individual coworker
  • incident prevention can be made more effective
  • critical services must remain available
  • information security is everybody's business
  • manage dependency on external suppliers
  • a system transcending trust boundaries can only be managed in a concerted effort


no silver bullet

There's an entire industry based on the assumption that Security Management is about fancy technology. The latest and greatest product, the silver bullet which will finally turn the tide and help us defeat adversaries once and for all.


To me, it's all about people. The folks who envision, design, build, deploy, operate, evolve, maintain and - when that day comes - decommission the system in a controlled fashion. Most importantly, the Owner who remains accountable throughout the system's life-cycle.


meanwhile, in a social channel

I've tested live-tweeting recent seminars, on BCM and Key Management.

Commenting as an event unfolds serves several purposes. It helps spread the word to absent friends. Taking notes publicly makes me concentrate on what might matter to others and gives me a chance to offer my value judgments.

Are there any cons? Nothing (even remotely) sensitive must get forwarded beyond the room. Then again, who would be sharing secrets in an open seminar?

Do you see other benefits or drawbacks with live-tweeting?


risk vs. compliance (2)

Policy is created to control risk exposure. Failing to establish coherent and adequate policy drives risk. Classify your assets, test your systems, educate your employees - says the policy. Risk reduction through compliance. 

And the other way round. Ensure that design decisions are explicitly risk-based, says the policy. Compliance through risk management.

Can you see other ways in which the risk (manage potential consequences) and compliance (do as we're told) perspectives are interrelated?


the rest is Risk

In the beginning there was Compliance.

Until our information systems grew complex and interconnected, the Compliance perspective served us fairly well. There was comfort in trusting that Knowledgeable Others had already foreseen what could possibly go wrong and devised clever rules to keep us safe. Do this or that and be secure.

Those were the days.

By now, we have more rules than ever and we still need to follow them. But complying is not enough anymore, we have to fend for ourselves.

The rest is Risk.