2014-11-24

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.

2014-11-03

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.

2014-10-13

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.

2014-09-22

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.

2014-09-01

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?

2014-08-11

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.

2014-07-21

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.

2014-06-30

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?

2014-06-14

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.

2014-06-13

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