Analogies are king

I've just been speaking at Computing's Enterprise Security & Risk Management Summit about analogies, and I thought I might note a few points here.

Firstly, good analogies are memorable. They stick to the experience which you have used in the analogy: if you use tooth hygiene as an analogy for vulnerability management, then people will tend to be reminded of vulnerability management when they brush their teeth. I think this is called anchoring.

Analogies also engage people, bringing them into a common set of referents which they have the confidence to manipulate and develop. Once they engage with an analogy, and make it their own, they can reuse it as a tool to enhance understanding in the future.

Be aware that analogies are not a perfect replica of the real world. They will often be simplified, incomplete or have elements which do not match the original subject. That's fine, as long as you bear it in mind: an overly literal approach should be avoided.

And a bonus analogy!

Here's the main concept:
Sandboxing can be helpful: but in order to remove delays, it is common practice to take a punt on the file, let it through and then test a copy of it in the sandbox.
Analogy:
Like having a strange creature turning up at the front door and wanting to be let in; let it in while you look it up on Google,and hope it doesn't eat your hamster in the interim.

Autumn topic - Log squirreling

Since it's heading inexorably towards autumn, as evidenced by the squally rain outside my window, I thought that I would choose a suitably seasonal topic.

There's a point of view which argues that there is no such thing as "too much data". Eventually it will be useful. Tools will be invented to trawl through the data automatically, and computers will get faster. Why not hang onto it? So people turn into squirrels and store more and more log files, potentially including personal data (there's an ongoing discussion as to whether IP addresses constitute personal data, which makes things more interesting).

I can immediately think of three reasons this is a bad argument:

1. Legal compliance: holding onto personal data "because it might come in handy" isn't exactly "keep for only as long as required for the purposes for which it was collected" which is a rough recast of Principle 5 of the UK Data Protection Act.
2. As speed of processing increases, the rate of data collection will also increase. It's likely that the one will never catch up with the other.
3. By the time you can trawl the data, you may not need it any more.

An information security product which really encourages squirreling - or at least the acquisition of incredibly large quantities of data - is a SIEM (security intrusion and event management system). It takes server log files and network traffic data (and anything else you can find) and correlates data to produce event/incident alerts.

But a SIEM isn't a magic box which solves all your problems. It needs someone to tell it what t look for - what an event is, and how to correlate data. If you go for "collect first, ask questions afterwards", you are very likely to have a tonne of data and nothing meaningful. Often, people confronted with this unpalatable truth go for a rather odd solution: collect more data. Upgrade the system to a bigger one. Get more log feeds from more systems, or from different types of sources, and eventually it will all make sense.

That's equivalent to collecting pieces of many jigsaw puzzles for years, storing them in a big box, and never actually putting them together. So you decide to collect more pieces, maybe from even more puzzles and buying a bigger box. How will this help you? Now imagine that some of these pieces are contaminated with plutonium. You REALLY don't need those around unless absolutely necessary. That's like doing this with personal data.

Yes, I hear you saying, but the lovely people who created my SIEM have pre-configured it to look for things I need to care about. They already thought of the incidents I need to be told about, and it's all fine. They are the experts.

Not necessarily. Those fine professionals might know their product inside out, but there is one thing they know pretty much nothing about, even if they have had ten meetings with you. Your business. They can look for generic events, like "someone keeps trying and failing to log in", but how useful is that to you?

To answer that question, I bet you started to think about business impact, maybe "If it was repeated login attempts on a system holding payment records, then I'd be worried". So knowledge of your business is key to useful incident notifications. CAVEAT: Some pre-configured alerts may be suitable if you are in a very regulated business and are very typical of that business.

Without understanding which events are of relevance, you get the second SIEM problem, overload. Hundreds or thousands of cries of "WOLF!" every second. Imagine if every failed login generated an alert. Or if it told you about every time someone connected to FaceBook (which might work for you, but some companies rely on FaceBook).

You'll also have spent a great deal of money for little return.

However, it's not all bad news, squirreling away logfiles isn't a brilliant plan; but tactical acquisition of a subset of that same ocean of data might just work.

If you have a SIEM, or are considering getting one, and are of the squirreling persuasion, stop and think:

• What are you really going to use the SIEM for? Business reasons, and make them SPECIFIC. Not that "to help us detect incidents" stuff.
• Think of specific, clearly defined use cases where correlation and alerting will help you (more on this in a later entry)
• Work out the minimum data you need for exactly those use cases 
• Work out where you can get it from and how (politics may happen here)
• Make sure the SIEM can understand it (format)
• Work out how it can be connected together to identify the specific incident you are trying to detect

And, for bonus points.:

• Agree with the relevant parties how the notification will be responded to (and how it will be verified, especially during early days where it might be a false positive).

The third major surprise resulting from turning on a SIEM, even when it is well configured, is that you suddenly get reports of incidents and they leap out at the incident response team. Yes, these things have been happening before the SIEM told you about them. But once they have been reported, you actually have to do something about them - even if it is only recording then and producing a nice little graph which you can attach to your new homework on "Why we need more budget/a different policy/more kit".

Once planned, put your plan into action. Basic project management stuff. Be ready to revise your plans to meet your overall goal. Take advantage of interesting benefits along the way, but don't lose sight of the objectives.

So, in summary, you don't need to squirrel, but you can use some of the data very profitably, if you know what you need it for. Be business-led, not data-driven.

Infosec baselines, Cyber Security Essentials and motorcycling

An "information security baseline" is like the CBT (compulsory basic training) that would-be motorcyclists take, to allow them to ride on the road. It’s not like passing the UK driving test, which is analogous to ISO/IEC 27001.

Nor is it like Cyber Security Essentials.

On the scale of “competence to drive”, Cyber Security Essentials rates approximately as high as the sight test (can you read a numberplate at X distance). If you can't pass it it, you DEFINITELY shouldn’t be on the road. 

Having passed it doesn’t tell anyone that you are a competent rider, but it tells them that you probably aren’t an unguided missile.

Encryption is always temporary

The basic concept behind encryption, to many people, is that it prevents the “bad guy” getting to your data. This is one of those cases where over-simplification is your enemy.

Encryption in any form is not a means of preventing access to your data by the wrong person. It is actually a means to delay access by the wrong person.

Why? Well, think about how you break into an encrypted file. You have several options:

1. Guess the password
2. Beat up the person with the password
3. Find somewhere where the data is not encrypted and get it from there (we’ll ignore that one as it’s not really about decryption)
4. Find a flaw in the encryption process and break in that way

Each of these options carries costs:

• ethical 
• financial
• time

In all cases, you can throw time at the encryption and you will definitely get through it. Or your descendants will, possibly in a much evolved form. 

What is good enough encryption? Think about how long the information will be confidential for. We have a tendency to assume that confidential doesn’t come with an expiry date, but even Government classified files are usually released after 30 years.

If it’s about a possible hiring of an employee, then maybe after they are hired the information could even be published - thus the encryption only needs to hold for a few weeks. If it’s scurrilous rumours about a chat show host, then maybe a century later the information will be of no interest to anyone. Research data is often very confidential before publication- and at publication, the aim shifts to getting everyone to read the paper, and providing the raw data to enable the published results to be verified.

You could argue that it will be deleted before then - but the attacker will probably take a copy, so you deleting your copy won’t help.

The future also contains changes which we can predict (computing power increasing, and thus brute force cracking getting easier), those which we can guess (flaws found in currently accepted algorithms), and even those which we can’t imagine (???) which will affect the protected lifespan of a given piece of encrypted data. But we can handle those in part by ensuring that when we encrypt we prevent copying to unsafe storage environments.

That is the take-home message here: don't assume that encryption will protect you from choosing a dodgy place to store your information. Take into account the "confidentiality lifespan" of the information, predictable changes to the encryption landscape, and always apply the principle of defence in depth. No single security measure should be your only protection from disaster- layer your protection.

From Data to Knowledge via Understanding - information philosophy

The philosophy of information seems to be handy when planning and designing quite a lot of things in information security. The standard model makes sense (see Wikipedia article on DIKW), but I'm choosing to express this slightly differently.

My idea is that there are four things:

- Data
- Information
- Knowledge
- Wisdom

They are often drawn in a pyramid:

Each concept builds upon the one below it. I think their relationship can be expressed in terms of how you get from one to the next. Thus to turn data to information, you add context, and so on.

This produces:

Information theory as an algorithm

Credit to my team for helping fill the gaps.