Information Security 101 - the Rules of Thumb

[Peter Fairbrother]

Brian Gladman wrote:
[...]:
>>
>> In these rules an "enemy" is someone who wants to steal some secret
>> information an honest system designer doesn't want him to steal, or to 
>> prevent authorised access to it, or to mislead a friend about its 
>> authenticity.
> 
> This does not cover things like denial of service attacks.  

I put "prevent authorised access" in to cover DoS, but maybe it's not 
clear enough.

And yes, I have read Ross, S+S etc. :), though I came up many of these 
rules before I did that, the rules are mostly fairly obvious IF you have 
thought about information security for a while.

The problem when non-security people, especially Government departments 
and Ministers, design systems which are intended to be secure - and 
system design has already begun long before the moment someone decides 
to commission it, simply saying "let's have a system to do xyz" is part 
of the system design, and in most cases it's the *biggest* part of the 
design [1] - is that they simply haven't thought about secure systems 
for long enough - or even at all.

Then the honest secure system designer either has to tell the 
commissioner that their design requirements are insecure and should be 
changed - which the commissioner is usually unwilling to do, especially 
if it's been announced politically - or try his best to add bolt-on 
security, which never works as well.


[1] Ask any system designer, even a non-secure system designer, getting 
an exact idea of what the system is supposed to do is the hardest part, 
writing the software is usually pretty straightforward after that.


>> Rule 6: Make it cheap and easy to use, a security system which isn't
>> used isn't useful.
> 
> I don't like this rule since it implies that a secure system can be cheap.
> 
> In my experience cheap systems are rarely secure. Morover attempts to 
> cut design costs are often a major cause of security design flaws.

I meant cheap in terms of resources used, but I take your points.


>> The security of a secret is approximately proportional to the square of
>> the number of people who can access it.
> 
> I agree the principle you are aiming at here but I don't see the 
> relationship as being necessarily quadratic.
> 
> Perhaps simply 'the more people who know a secret the less likely that 
> it is, or will remain, a secret."

Agreed the relationship isn't necessarily quadratic - but it isn't 
linear either. That's the point I'm trying to make here, and hence the 
"approximately".

If a secret is widely known then each person who knows it is less likely 
to take it's keeping seriously, "everybody knows that" - people who wish 
to reveal it for malicious purposes are more likely to, as they think 
they are less likely to get caught - and people may reveal it 
unwittingly, in the belief that the person they are talking to already 
knows, or is entitled to know, the secret.

The more people "in the know", the more these factors come into play - 
and the chance that each of them will reveal the secret is roughly 
proportional to the number of people who know it.

Multiply that chance by the number of people, to get the overall chance 
of compromise, and you get approximately the square of the number of people.

There are mathematical approximations involved too, but it's a rule of 
thumb, not a law.


> 
> The ability to keep something seccret decreases with the length of time 
> over which it must remain secret.

Good one.


>> Security by obscurity is worse than no security at all.
> 
> This is quite a difficult one, especially so because 'security by 
> obscurity' is a poorly defined concept.

Indeed. I included it at Jim Murray's suggestion, and there is a very 
valid point in there (it's much worse if you don't know when your 
security has been compromised, as you'll continue trusting it, and 
relying on obscurity makes this much more likely), but perhaps it's not 
clear.

> 
> Whether actually revealing a system design will enhance or degrade its 
> security is an issue that Prof. Ross Anderson has researched and it is 
> not clear cut.  The answer depends on the size of the hostile and 
> friendly communities and the extent of their motivation in exposing 
> security flaws. What is pretty clear is that the hostile community is 
> often far more motivated  than the friendly one and will hence find and 
> exploit flaws revealed by design publication long before the friendly 
> community finds them.
> 
> As a publisher of cryptographic algorithm software what has surprised me 
> is just how long design flaws can exist in published software before 
> they are found by the friendly community.

Debian, RNGs ... ouch!
> 
> Hence _depending_ on design secrecy as a way of achieving system 
> security is a bad principle but this does not necessarily mean that it 
> is beneficial to publically reveal a system's design.

Agreed.
> 
> However the situation in respect of government systems hollding citizen 
> owned information is different since, in my view, the owner of 
> information (the citizen) must be able to determine to their own 
> satisfaction that any system on which their information is to be held is 
> secure.  Hence such systems have to have published designs (there cannot 
> be any doubt that 'security therough obscurity' as applied in UK 
> government civil IT systems has been a complete failure).

Agreed, even more so!


-- Peter Fairbrother