05. Threat modelling

Now we have a functioning bank! A very simple one, but a functional one. But it is also completely insecure! We put our complete trust in the tellers, the system administrators and directors at the bank. So let's start thinking of how we can secure our bank.

// bank.js

// teller.js

How to define threat models

One of the important rituals in engineering secure systems is threat modelling. It is more of a planning exercise than a practical one. It is all about defining who your opponents (called adversaries in crypto-lingo) are, what they stand to gain from breaking your system and how we can either eliminate the threat they pose or make it so costly to achieve their goals, that their threat becomes negligible in your model.

Threat modelling helps you focus on real threats instead of contrived ones. If you do not keep this laser focus on what is actually within your model, you will be stuck in "paralysis analysis". This is also why it is important to figure out what your adversary stands to gain, and how far they are willing to go to break your system, plus what you're willing to invest to mitigate the risk.

Our first threat model

So far we have have only briefly mentioned two security aspects; a transaction log which also serves as a simple audit trail and checking that the bank has sufficient funds. The latter you might not regards as a security feature, but being extremely cautious and only accepting well defined inputs is the first step towards securing the system. It is also important here to realise that it is the bank.js server that should be locked down, while any checking in the teller.js is just "nice" validation to save a network round-trip.

Validating inputs is, as such, not important to our tour of cryptography, so we will leave that as a bonus exercise. The transaction log, however, is at the core of our bank. As it stands now, anyone can reorder, add or remove transactions, without us being able to detect it. Securing our transaction log will be our first avenue into cryptography. A first threat model may look roughly like the following:

• Who: Anyone with physical access to the bank (disgruntled staff, corrupt directors, evil hackers)
• What: Transaction forgery
• How: Simply editing the transaction log

Testing

Unleash your inner hacker! (or script-kiddie.) Try reordering, adding and removing items from the log. Depending on your logic, you may even be able to put the bank into a deficit, despite that being something that should not be possible. We're in big trouble now.

Continue to problem 06