Attack surfaces, attack trees, and security strategy

Two questions, not one

Once a design honours the thirteen principles there are still two separate questions to answer about a real system. Where can it be attacked? — that is the attack surface. And by which route would an attacker actually choose? — that is the attack tree. The first is an inventory; the second is a ranking. Confusing them is the most common error on this material, so it is worth fixing the distinction before either is defined properly.

The system throughout is Kettle & Co: six people, one warehouse, one web shop, roughly nine hundred orders a week.

Attack surface

An attack surface is the set of points at which a system is reachable and exploitable by an attacker. Its useful property is that it is a quantity that can be reduced: you can count the points, and you can remove them. It falls into three categories.

Network attack surface. Vulnerabilities reachable over the network — the enterprise LAN, a WAN, or the Internet. At Kettle & Co that is the HTTPS listener on port 443; an SSH port left open to the whole Internet on the application server; the payment provider's callback endpoint, which accepts POSTs from outside; the DNS records; a forgotten staging. subdomain still serving last year's code; and the fact that one web host answers every request, which is a denial-of-service exposure by itself.

Software attack surface. Vulnerabilities in application, utility or operating-system code. At Kettle & Co: the checkout logic; the image resizer that parses supplier-uploaded files; the CSV importer that reads stock files from three suppliers; a hundred and eighty third-party packages pulled in at build time; and the admin search box that builds its query by string concatenation.

Human attack surface. Vulnerabilities created by people — social engineering, human error, and the trusted insider. At Kettle & Co: the two staff who can issue refunds; a shared orders@ mailbox everybody in the company reads; and a standing habit of accepting delivery-address changes over the phone from anyone who can quote an order number.

Reducing it is then a concrete exercise. Close SSH to the Internet and reach it through a bastion. Delete the staging subdomain. Drop the CSV importer and take a signed feed instead. Remove refund rights from the account nobody uses. Each of those removes points. None of them makes the remaining points stronger — that is a different job, and it belongs to layering. Attack surface reduction narrows the target; defence in depth deepens what has to be traversed. They are orthogonal axes, and a serious design moves along both.

Attack trees

An attack tree is a branching hierarchical structure whose root is the attacker's goal, whose internal nodes are subgoals, and whose leaves are the concrete techniques that would initiate the attack. Every non-leaf node is either an OR-node (any one child achieves it) or an AND-node (all children are required). Branches can be labelled with cost, difficulty, or probability.

That labelling is the whole point, and it is what separates an attack tree from a threat list drawn with lines between the items. Attach a cost to every leaf and the tree evaluates: an OR-node costs the minimum of its children, because the attacker picks the cheapest way in; an AND-node costs the sum of its children, because the attacker has to do all of them. Evaluate upwards and the root tells you the cheapest path to the goal — which is to say, the tree ranks attack paths instead of merely listing them.

### Worked example — one card number

The goal at the root is obtain a customer's card number. Three branches, in units of relative effort:

• From the shop's database (AND). The attacker needs a shell on the application server and the ability to decrypt the stored card blob. The shell is itself an OR: SQL injection through the admin search box, cost 5, or buying a stolen SSH key, cost 9. So the shell costs $\min (5,9)=5$, decryption costs 12, and the branch costs 5 + 12 = 17.
• In transit (AND). Get onto the network path, cost 7, and break TLS, cost 25. The branch costs 7 + 25 = 32.
• Ask the customer for it (OR). Phish them with a cloned checkout page, cost 3, or telephone them pretending to be support, cost 6. The branch costs $\min (3,6)=3$.

The root is an OR, so the goal costs $\min (17,32,3)=3$, and the cheapest path is the phishing leaf. Now read what the tree just told the six people who run this shop. Their money does not go into a stronger cipher for the stored card blob — that sits behind the most expensive branch of the three. It goes into a checkout flow that phishing cannot imitate and into telling customers what the real one looks like. Without the costs, the same three branches are just a list of bad things, and the list would have suggested buying encryption.

Security strategy: three separable questions

A security strategy has three components, and they are best remembered as three questions asked in order.

Specification and policy — what is the scheme supposed to do? A security policy in the useful sense is a formal statement of the rules and practices by which an organisation protects its sensitive resources; the weak sense, an informal description of desired behaviour, is not something a control can enforce. Writing it means weighing the value of the assets, the system's vulnerabilities, and the threats and their likelihood — and then making two trade-offs explicitly. Ease of use against security: every password is memory the user has to supply, every firewall costs throughput. Cost of security against cost of failure and recovery, where the second term must be weighted by risk — the probability that the threat actually exploits the vulnerability with that harmful result. This is why the book insists a security policy is a business decision, sometimes constrained by law, and not a technical artefact.

Implementation and mechanisms — how does it do it? The controls that carry the policy out, and they sit on an axis worth naming: prevention (stop it happening), detection (notice that it happened), recovery (restore afterwards). At Kettle & Co, TLS on the checkout prevents; the alert on an unusual refund rate detects; the nightly offline backup recovers. The same technology can land in different places: a web application firewall in blocking mode is prevention, and the same firewall in log-only mode is detection.

Correctness and assurance — does it really work? Two words that get swapped in exams. Assurance is a degree of confidence that the security measures work as intended: a property of the system, covering both its design and its implementation, and explicitly not a formal proof — the state of the art cannot deliver one. Evaluation is the process of examining a product or system against defined criteria, by testing and sometimes by formal analysis. Assurance is the confidence you end up with; evaluation is what you did to get it.