Security across the life cycle: secure SDLC, SQUARE, misuse cases

Security is not a phase

Most teams meet security late: build the product, hire someone to attack it a fortnight before release, patch whatever comes back. The ordering is the whole problem. Very little of what a penetration test finds is a coding slip; most of it is a missing requirement. Nobody ever wrote down that a locker collection token should expire, so no design accommodates expiry, no component owns it and no test looks for it — and a missing requirement cannot be patched, because fixing it changes the design. A secure software development life cycle answers this by attaching security work to every framework activity instead of appending a phase to the end: security requirements during communication and planning, threat modelling and attack-surface analysis during modelling and design, secure coding standards and static analysis during construction, and security testing, monitoring and incident response during deployment. The named touchpoint models — Microsoft's SDL is the best known — are essentially agreed lists of which activity attaches where and who signs it off.

SQUARE: engineering the security requirements

SQUARE is a nine-step process for producing security requirements, not security features. In order: agree on definitions; identify assets and security goals; develop the supporting artifacts; perform a security risk assessment; select an elicitation technique; elicit the security requirements; categorize them by level, separating genuine requirements from constraints; prioritize them; and inspect them. Two steps carry the process. Agree on definitions comes first because a room in which authentication means three different things cannot produce a requirement anyone can test. Identify assets and security goals comes second because a threat has no priority until you know what losing the asset costs you. For BorrowBox a stolen circular saw costs a replacement and an insurance claim; a leaked member address list costs the trust that a neighbourhood library runs on entirely. Both are bad, but they cannot both be high, and the ranking has to be argued before anyone writes a control.

A misuse case inverts the actor

The thinking move in this lesson is a single inversion, and it is worth more than any list of controls. A use case names an actor with a goal and tells the story from that actor's point of view. A misuse case does exactly the same for an actor whose goal is to defeat the system: it is written from the attacker's side, not the defender's. The attacker photographs the screen while standing behind the member is a misuse case. The system shall prevent screen capture is not — it is a wish. The difference is productive rather than stylistic: an attacker's sentence is a sequence of steps you can walk, and each step is somewhere you can intervene. Misuse cases are produced by brainstorming with security specialists alongside the people who know the domain, questioning every interface and every assumption of the form that can't happen; they are recorded as a table or a diagram and prioritized on cost against benefit like any other requirement. Each is paired with attack patterns — reusable descriptions of an exploit's technique, timing and required resources, together with its known mitigations — so a team is not obliged to reinvent every attack from first principles.

Worked example — replaying a BorrowBox collection token

BorrowBox shows a member a QR token on their phone; the locker bank scans it and opens a door. Write the misuse case. The actor is someone standing in the queue behind the member. The precondition is that the token is a static image displayed in public and that every locker in the bank will accept it. The steps are: photograph the screen over the member's shoulder, walk to the bank, present the photograph, take the tool. The asset at risk is the tool — and the member, who is billed for it and now has to argue.

The design response falls straight out of the steps. Bind the token to a single locker identifier, so the photograph only works at one door. Make it single-use with a server-side nonce, so the first successful scan destroys it. Give it a sixty-second validity window, so the attacker must be standing there already. None of those three controls appeared in the original requirements; all three are now testable requirements with acceptance criteria, and they exist because somebody wrote four sentences from the attacker's chair.