[Cryptography] It's list time again ...

[Peter Fairbrother]

As ever, suggestions are very welcome. Actually, they are requested (:


Peter Fairbrother



I call these laws because they are always true.

The Laws of secure system design are:

0 It's all about control

1 Someone is after your stuff

2 Someone else is after your stuff

3 Stuff you don't have can't be stolen from you

4 Everywhere is subject to attack

5 Attack methods are many, varied, ever-changing and eternal

6 Complex systems provide more places to attack

7 Only those you trust can betray you

8 Holes for good guys are holes for bad guys too

9 A system which is hard to use will be abused or unused





Principles of secure system design:

1 Single points of failure are failures of system design

2 It is easier for insiders to steal information. evil maids included

3 Design for known threats - Design for future threats - Design for 
unknown threats

4 In a monoculture the target becomes more attractive and more brittle

5 Methods and mechanisms persist - in code, nothing ever really goes away

6 Economy of mechanism – A simple design is easier to test and validate.

7 You do not control what a system is to be used for or the resources 
which will be pitted against it. Or against whatever will be developed 
from your system.

8 Fall back to insecure mode - ? is continuous operability/ avoiding a 
temporary loss of operability more important than security?  Especially 
considering the probable loss of operability if security is breached. 
Also, insecure mode is both an attack method and vector. Is someone 
waiting for you to fall back to insecure mode so they can take advantage 
of it? Are they forcing a fallback in order to breach security? If you 
fall back a lot, do not expect security.
Solution: do not _have_ an insecure mode

9 System Designer's fees are cheaper than failure costs: system designer 
vs project manager: best if both in one person, but in general system 
designer _must_ be able to override project manager.

10 Once they become publicly linkable, two items cannot (securely) 
become publicly unlinkable.

11 Least common mechanism



Techniques of secure system design:

0 Chain of Control

1 Defense in depth - layered security

2 Attack modelling, including unknown unknown attackers

3 Minimize total secrets

4 Schneier's law applies to everything, including these laws.

5 Red/black separation

6 Open design - security by obscurity is too brittle for system design. 
low security closed apps like special forces insider talk maybe, system 
design no.

7 Kerckhoffs's Principle

8 Least privilege

9 Separation of privilege - eg TFA, two persons needed to open bank vault.

10 Complete mediation

11 Principle of least astonishment. Ease of understanding and use.

12 Being there. Users' mental models should match actual system behaviour.

13 Work factor for attackers - “weakest link” and “easiest penetration” 
principles

14 Attack recording, including compromise recording

15 Transaction recording to ensure accountability

16 Unique identities to ensure accountability

17 Continuous Improvement

18 Confidentiality integrity availability triad

19 Fail-safe defaults - Deny by Default

20 Mechanisms to remove old code are sometimes necessary. These may 
involve deliberately creating incompatibility with earlier systems

21 Avoiding transitive trust







bubbling under:

Security is a Boolean

People offering the impossible are lying


it _is_ a battle