How To Treat a Threat?

A threat is a possible cause of possible damage to your business. It may come from

a)      people, inside or outside of your organization, ether deliberately or through neglection/ignorance/carelessness;

b)      technology, working as expected or failing; or

c)       environment, like lightning, landslide, flood, emissions, contamination etc.

You might add "acts of God", but that cause adds no value to this discussion. Sorry. Let's stay with common logical causes for the moment. As long as they exist, we need no more.

However, no threats make damage if there are no vulnerabilities for the threats to use. So: No vulnerabilities means no damage, whatever the threats. In other words, and so far:

1.       eliminating a cause/threat eliminates damage through vulnerabilities used by that cause/threat.

2.       eliminating/reducing a vulnerability eliminates/reduces damage from all causes/threats using that vulnerability.

But however complete you manage to eliminate/reduce threats and vulnerabilities, I bet there still are both threats and vulnerabilities left, and still damage may occur. To deal with this, you need to be prepared to act wisely in unwanted or unexpected situations. We need to add a weapon to our arsenal:

3.       preparing for business continuity and disaster recovery – just in case…

One basis for your choice of actions, whether they aim at elimination/reduction of threats or vulnerabilities or preparedness for unwanted situations, is a threat and vulnerability analysis. But this is not enough. In order to understand the profitability of your possible actions, you also need to analyze the probability of the damage you want to avoid, and the total value – or cost – of that damage and your choice of mitigation.

Now we have what we need to decide on treatment of threats – a more or less complete Risk Analysis.

The JES Concept explained

JES = Just Enough Security. Why, and What?

The Just Enough Security Concept strives for a situation where the total consequences from damage and protection are as low as possible over time. JES accepts the fact that 100% Security is unattainable.

JES is almost as far from “Best Practice” as you may be. The only obvious strategy – besides JES – that by definition is further away from “Best Practice” is the “No Protection At All” strategy. But that strategy is probably even more expensive for your Organization than “Best Practice”.

Let me explain.

Risk is sometimes defined as the Consequences of an Event multiplied with its Probability. To know your organization's Risks, you must know – or, at least, be strongly convinced about – both Probability and size of the Consequences of all possible damaging Events. But if you don’t know - which are your best choices, in terms of risk mitigation strategy?



Genuine Uncertainty means no knowledge whatsoever of possible damaging Events. Your simplest choice is a "No Protection At All” strategy, where you just face the costs connected with unwanted Events. And you really do not see any reason to do anything else.

Common Uncertainty means some knowledge of possible Events with damaging Consequences but no usable knowledge of Probabilities for the Events. A reasonable strategy is to follow “Best Practice” for protection. You will face costs connected with protection you both need and do not need, and costs for damage you chose not to protect against, either from weaknesses in Best Practice or from lack of resources. And you cannot optimize your costs for protection and damage; you lack sufficient knowledge.

Knowing your Risks is one essential foundation for the ability to optimize total costs for protection and damage – “Just Enough Security”.



In the Cost/Protection diagram, “No Protection At All” will put you to the left. “Best Practice” will put you partly to the right and partly to the left, because some of the needed protection will be omitted for some reason or another.

Knowing your Risks allows “Just Enough Security”, which will move you close to the green arrow.

Where would you like to be?

Basics On Information Classification

Important note #1: Information Classification is about more than just IT. 

Through your Information Classification, you decide on (i.e. classify) the required level of protection for your specific (types of) information resources (not only for information as such) in terms of Confidentiality, Integrity, Availability and sometimes Traceability (CIA-T).

Important note #2: Information Classification has 2 dimensions.

You also need to understand and document (i.e. classify) the level of protection of Confidentiality, Integrity, Availability and sometimes Traceability (CIA-T) offered to your information resources by your information environment, i.e. your infrastructure, your information handling/storing tools, etc (which in turn are information resources, i.e. need to be classified both according to #1 and #2).

Important note #3: Your Information Classifications need to be quantified.

Forget about relative values like High/Medium/Low. What are you supposed to do with that data? Instead, quantify the consequences if Confidentiality, Integrity, Availability or Traceability is not kept on the required levels, e.g if your service is not available for your customers as agreed. What will that cost your customers – and what will that cost you? This is the kind of data to put into your plans for investments in information security!

Usually, today, I only see qualitative/relative classification of information as such in IT environments and in terms of Confidentiality, and no corresponding analysis of the protection offered by the information environment. Not good enough.

Can We Trust Biometry for Authentication?

Simple answer: No. Not alone. 

There are several obvious attack points in the biometrical authentication chain. And, unfortunately, the very face, eye, hand, or fingerprint, is not always as unique as we may think. As an example, fake fingers have fooled fingerprint readers from the beginning, and they still do.

And making those fake fingers is not rocket science. In her M.Sc. thesis, Marie Sandstrom of Linkoping University, Sweden, showed how she could fool every existing fingerprint reader with gelatin fingertip copies made quite simply from fingerprints picked up with common forensic techniques. The thin gelatin fingertip copies were put on her own fingertip, thereby bypassing those temperature and pulse controls.

Update: A similar technique was used to "hack" the fingerprint reader on the new iPhone.

Consequently, a mould rubber mask constructed from a 3D portrait photo might fool a face recognition system. A rubber copy of my hand put on your (smaller) hand might fool a hand reader. And soft eye lenses with printed patterns might fool an iris reader. I do not know whether this is tested, but I would not be surprised if such tests were successful. 

For me as a security professional, this is what I must consider, and it leads me to one conclusion: Never trust one security mechanism alone. If you need to be reeeaaalllly safe, you need more controls. Preferably simple, layered, and independent.

Why do we need Security at all?

Different kinds of threats may use different vulnerabilities to create damage, and if the risk for damage from such reasons is not under control, your organization has a too low security level. There are basically three main roads to reduce the risk for such damage, or, in other words, to establish the level of security you wish for yourself: 

• eliminate threats, 
• reduce vulnerabilities, or 
• react wisely when damage occurs. 

Or, which is usually the case; apply a combination of these three.

Security is about keeping you in business, i.e. not losing your market from operational reasons, and keeping your operational ability to deliver to that market, virtually whatever happens. Security focuses on managing Operational Risks for your business – all other risks, e.g. Business Risks, are for the Business people to manage by themselves.

One quite lively branch of Security is Information Security, i.e. Security applied on Information, regardless of environment, carriers, etc. This is very often mixed up with IT Security, which – at its best – is about eliminating vulnerabilities in IT environments. But, of course, IT Security is an essential tool for Information Security Management. The same goes for Physical Security, trying to reduce physical vulnerabilities and used as a tool both by Information Security Management and by overall Security Management.

All these colours are needed on the Security Palette; none is The Answer to The Question of how to keep us in business whatever happens. But, well played, they offer cards for Management to play in that everlasting Marketing Warfare Game.

Which Messages Reach the Top?

How do we reach Top Management with our Information Security issues? Why don't they act on our message? One of many obstacles is our presentation. We conceal our message in nerdy language.

In those days when I tried to speak the predecessors of "ISO/IEC 27000-ish" with Top Management, they sent me to the auditors - or, in fact, anywhere out of their sight. Of course they did not listen, why should they? I was showing them so clearly that I was what Scott Adams, the author (in chapter 26 of "The Dilbert Principle") calls "one level removed" from the essentials of the business, and that is not a position of great strength.

Today, I translate risk and (information) security management language into the language of those in power. They have a language fit to manage business, and that is what it is all about.

So, for the last 25 years, I've been informing about alternative action patterns (including doing nothing), the profitability of the possible action plans, distribution of accountability, the need and building of awareness and ability, and the way to follow up on results, and things usually - but not always! - go my way.

My conclusion: Specialists should make themselves understood by speaking Top Management language, not by teaching Top Management any odd Specialist language. And specialists, like myself, need help to manage that. 

The Three (or Four) Laws of Consultics (eng)

The three laws of robotics were created by Isaac Asimov, who also completed them with the “Zeroth Law”, so named to continue the pattern of lower-numbered laws superseding in importance the higher-numbered laws. 

Below, compared with the Asimov set of laws,“robot” is replaced by “Consultant”, “humanity” is replaced by “Markets”, “human being” is replaced by “Customer”, and “existence” is replaced by “integrity”. 

I hope it makes sense to you. It does to me.

0.              A Consultant may not harm Markets, or, by inaction, allow Markets to come to harm.

1.              A Consultant may not injure a Customer or, through inaction, allow a Customer to come to harm.

2.              A Consultant must obey orders given to it by Customers, except where such orders would conflict with the First Law.

3.              A Consultant must protect its own integrity as long as such protection does not conflict with the First or Second Law.