Steffo's Echolot

Security: Risk analysis

"Please continue shopping via our Security Server. It uses encryption to protect your data." Sentences like these always surprise me. I've never seen a bank advertising "Please open an account at our bank. We use armoured cars to transport your money."

One problem with IT security is that a lot of technical people tend to implement a plethora of mechanisms without doing a proper risk analysis before. The tems in risk analysis are not standardised. However, some terms like 'threat' and 'risk' are by no means identical. A threat is something like: Someone holding a gun enters the bank building saying 'I want your money'. This risk is an evaluation of the threat regarding two aspects:

1. likelihood that he gets the money and
2. the amount of money he gets.

So a risk is a point in a two dimensional matrix (x: likelihood that the event happens and y: potential amount of loss).

A risk analysis is a process:

1. Determine the threat. A threat is an event.
2. Determine the weaknesses that favour the threat (e.g. missing encryption, missing cameras, no bulletproof glass).
3. Set up an appropriate scale for the risk matrix: the likelihood can be qualitive (neglectible, low, middle high) whereas the potential loss might be (10^5 EUR, 10^7 EUR and 10^9 EUR). Try to capture the 'out of business' case as well which might occur either through
• Acting against legal requirements.
• A high loss (that's easy).
• Loss of image and customer confidence.
4. Determine the likehood that the threatening event occurs by relating (combinations of) weaknesses to threats.

Sounds too theoretical? Here's the classical example from Star Wars:

Threat. Death Star will be destroyed.
Weakeness. A small thermal exhaust port, right below the main port. The shaft leads directly to the reactor system.
Likelihood. Low (difficult to approach; approaches will be detected).
Potential amount of loss. Out of business

Now you can start of developing counter-measures. A lot of things can be done wrong here. Most notably: technical measures lacking proper organizational support (believe me, I've seen large banks where the whole network traffic must be encrypted, the operators however, being unable to set-up a procedure for changing the certificates or keys). In that case a security strategy might help: if you cannot go for the complicated mechanism right now, why not choosing a weaker mechanism plus an organizational mechanism (e.g. insurance) for a transitional period?

I agree, that sounds too simple and I haven't seen a company that uses an insurance to make up for such operational drawbacks. My only point is: don't always think too technical. Use a combination of technical and organizational things. And if you set up online banking, don't only tell your customers that you use SSL military grade encryption, but also that you set up processes and took an insurance, just in case.

Posted at 02:48AM Mar 11, 2007 by steffo in Identity Systems  |  Comments[1]