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.
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.
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.
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?
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?
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.
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.
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.