Information Security 101 - the Rules of Thumb

[Brian Gladman]

----- Original Message ----- 
From: "Peter Fairbrother" <zenadsl6186 at zen.co.uk>
To: "UK Cryptography Policy Discussion Group" 
<ukcrypto at chiark.greenend.org.uk>
Sent: Tuesday, June 23, 2009 11:28 PM
Subject: Re: Information Security 101 - the Rules of Thumb

Some rapid, incomplete thoughts below.

     Brian Gladman

----------------------------

>I haven't finished writing/compiling the security design 101 rules yet,
> but so far:
>
> 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.  Hence I suggest 
'an "enemy" is an entity that seeks to interact with a system in a way that 
will have a detrimental impact on the intended purpose of the system'.

Similarly, ' a friend is an entity that is trusted to interact with a system 
in a way that does not have a detrimental impact on the purpose of the 
system.'

> Rule 1: Do not underestimate the enemy, they are cleverer, more numerous 
> and more determined than you think.
>
> Rule 2: Keep it simple, simplicity limits where an enemy can attack.

A system should not contain any internal or external capabilities that are 
not essential in providing the system's intended purpose.

A system design that seeks to provide security, functionality and scale at 
the same time will be insecure.

> Rule 3: Limit the people who can access secrets, only they can steal them.

>   Rule 3 alternative wording : Limit the people you trust, only they
> can betray you.

The trusted entities on which a system depends should be only those that are 
essential in the provision of the system's intended purpose

> Rule 4: Protect plaintext first, it's far more valuable to an enemy
> than ciphertext.
>
> Rule 5: Think out-of-the-box, an enemy will attack in ways you don't 
> expect.
>
> 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.

> Some more, unfinished and in no particular order:
>
> The best person to control access to a secret is a person who already
> knows it.

The best peron to control access to a secret is a person who will be 
detrimentally impacted by its compromise (whether they know it or not).

> Whether something should be considered secret or not depends on what it
> can be used for, not on what you want to use it for.
>
> Two or more pieces of information when put together may divulge a secret
> which is more than the sum of their parts.

> If a secret can be inserted, changed or deleted by an enemy, a friend
> can't rely on it's accuracy.
>
> The purposes of an enemy may be fulfilled by preventing a friend
> accessing a secret.
>
> The security of a secret is approximately proportional to the square of
> the number of people who can access it.

I agree the prinnciple 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.'

I am tempted to say 'a secret known to more than one person or entity is not 
a secret'.   :-)

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

> Limit everyone's ability to access secrets to that necessary, the
> ability to access a secret is the ability to steal it.
>
> Only tell friends the secrets they need to know, they don't need to know
> them all.
>
> Limit the information you store, information which isn't stored can't be
> stolen from the store.
>
> Limit the information you collect, information which isn't collected
> can't be stolen during collection.
>
> Knowing if or when someone has accessed a secret can be as revealing as
> knowing the secret itself.
>
> It is better to knowingly lose a secret than to have it stolen, deleted
> or modified.
>
> 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.

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.

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.

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


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4182 (20090624) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com