29Security

On 21 February 2025 a large crypto exchange signed a transaction from one of its wallets that required several signatures. The signers approved what their screens showed them: a legitimate transaction. The web application that prepared it had been altered two days earlier to display legitimate transaction data while changing what was actually signed, and the signatures gave the attackers the wallet’s ether. The FBI attributed the theft of about $1.5 billion to North Korea. No cryptography was broken; the attackers changed what people were shown. Security in a trading firm is mostly about who and what is allowed to do things, and about making sure that what they see is what they sign. This chapter writes the firm’s access policy as data and checks it, keeps secrets and venue keys under rules, segments the network, and looks for the insider who copies a little too much every day.

29.1 What a trading firm protects, and from whom

A trading firm’s assets are unusual in two ways. Some are money that moves by itself on a signature — exchange balances, wallets (Book 3, chapter 24), payment instructions — so a stolen credential is a loss within minutes. Others are information whose value is its secrecy — strategy code, signals, parameters, positions — so a copy is a loss even when nothing is deleted. The adversaries follow: criminals and states for the first, competitors and departing employees for the second. The operational risk of Book 6, chapter 28, covers both; this chapter builds the controls.

29.2 Identity, access and least privilege

The chapter’s firm has twelve roles and a hundred people. Its policy is data (firm.accessctl): roles grant (resource, action) pairs, people hold roles, deny rules override grants, and five segregation-of-duties constraints (Book 6, chapter 28) name pairs of permissions no single person may hold.

P = lambda r, a: (r, a)                                    # noqa: E731 - a permission
SOD = [(P("orders", "submit"), P("trades", "amend")),     # no correcting one's own trades
       (P("params", "propose"), P("params", "approve")),  # chapter 16's four eyes
       (P("code", "merge"), P("prod", "deploy")),         # chapter 27: nobody ships alone
       (P("venue_keys", "create"), P("wallet", "withdraw")),  # key makers move no money
       (P("payments", "create"), P("payments", "release"))]

@dataclass
class Policy:
    roles: dict
    users: dict
    deny: set = field(default_factory=set)
    sod: list = field(default_factory=list)

    def permissions(self, user: str) -> set:
        perms = set().union(*(self.roles[r] for r in self.users.get(user, ())))
        return {p for p in perms if (user, *p) not in self.deny}

    def allowed(self, user: str, resource: str, action: str) -> bool:
        return (resource, action) in self.permissions(user)

    def toxic_roles(self) -> list[tuple]:
        """Roles that alone hold both halves of a segregation-of-duties constraint."""
        return sorted((r, a, b) for r, perms in self.roles.items() for a, b in self.sod
                      if a in perms and b in perms)

    def toxic_users(self) -> list[tuple]:
        """Users who hold both halves, through one role or by combining several."""
        return sorted((u, a, b) for u in self.users for a, b in self.sod
                      if a in self.permissions(u) and b in self.permissions(u))

Each toxic role was created for convenience and each is how a known kind of loss happens: a trader who amends his own bookings can hide losses (the rogue-trading cases of Book 6); a developer who deploys his own merge skips chapter 27’s review; a head of desk who approves his own parameters skips chapter 16’s four eyes. The check is a few lines of code over the policy data and belongs in the policy’s own continuous integration: a change that creates a toxic combination fails like a failing test.

29.3 Secrets and keys

Rotation bounds exposure: a secret that leaks at a random time and is rotated every 90 days stays valid 45 days on average; rotated weekly, three and a half. An HSM, or the multi-party computation of Book 3, chapter 24, removes the key from the host — but not the question the hook asks: the device signs whatever it is shown. The defence is to make what is signed verifiable independently of the screen that prepared it: a second channel that shows the transaction’s actual content, a policy engine that refuses a transaction type (a contract upgrade, a new destination) whatever the signers approve.

29.4 Exchange and wallet credentials

Venue API keys (Book 3, chapter 15) are the firm’s most exposed secrets: they sit on the trading servers and sign every order. The chapter’s keys carry scopes — a trading key can read and trade but not withdraw; a withdrawal key can only withdraw, to allow-listed addresses — and every request is signed with Book 13’s HMAC signer and stamped with its time. The venue’s checks decide what a stolen key can do (Table 29.2).

def verify(keys: dict, req: dict, at: float, max_age: float = 5.0) -> tuple[bool, str]:
    """What the venue checks: a known key, a valid signature, a fresh request, a scope that
    covers the action, and for withdrawals an address on the allow-list."""
    key = keys.get(req["key"])
    if key is None:
        return False, "unknown key"
    if Signer(key.secret).sign(req["body"]) != req["sig"]:
        return False, "bad signature"
    body = json.loads(req["body"])
    if not 0 <= at - body["at"] <= max_age:
        return False, "stale request"
    if body["action"] not in key.scopes:
        return False, "action outside the key's scope"
    if body["action"] == "withdraw" and body.get("address") not in key.allow_list:
        return False, "address not on the allow-list"
    return True, "ok"

29.5 Segmentation and insider risk

The best-known case in trading is also a warning about the law’s limits: in 2009 a programmer uploaded more than 500 000 lines of his employer’s high-frequency trading code to a server in Germany on his last day; his federal conviction was reversed on appeal in 2012, on the reach of the statutes rather than the facts. A firm cannot rely on the courts (Book 16, chapter 11, on trade secrets); it must see the copying. The difficult insider is not the one who takes everything on the last day but the one who takes a little more than usual every day.

The chapter’s model gives each of the hundred people a year of 250 trading days of access logs — the strategy-code files each reads a day, at each person’s own level, with a weekly rhythm and noise — and plants an insider who, from a random day, reads a stated share more than usual, every day. Four detectors score each person against their own baseline, the median and median absolute deviation of 30 days: a single-day threshold, or a CUSUM of the daily scores (Book 7, chapter 13), each with a baseline that trails today or one that ends 60 days earlier. All four are calibrated on clean people to one false alarm a month per hundred people.

def robust_scores(x: np.ndarray, window: int = 30, gap: int = 0) -> np.ndarray:
    """Each user-day against the user's own baseline: (x - median) / (1.4826 MAD) over the
    `window` days ending `gap` days before; a gap keeps a slow change out of its baseline.
    Days without a full baseline score 0."""
    n_users, n_days = x.shape
    z = np.zeros_like(x, dtype=float)
    for d in range(window + gap, n_days):
        past = x[:, d - gap - window:d - gap]
        med = np.median(past, axis=1)
        mad = 1.4826 * np.median(np.abs(past - med[:, None]), axis=1)
        z[:, d] = (x[:, d] - med) / np.maximum(mad, 1e-9)
    return z


def cusum(z: np.ndarray, k: float = 0.5) -> np.ndarray:
    """One-sided CUSUM per user: S_d = max(0, S_{d-1} + z_d - k)."""
    s = np.zeros_like(z, dtype=float)
    for d in range(1, z.shape[1]):
        s[:, d] = np.maximum(0.0, s[:, d - 1] + z[:, d] - k)
    return s

Two things matter, and Figure 29.3 separates them. A single day of reading 30% more than usual is well inside a person’s noise; only accumulation — the CUSUM — turns thirty such days into a signal. And a baseline that trails today learns the new habit: after thirty days the insider’s copying is the person’s normal, and the score returns to zero. Lagging the baseline by sixty days keeps the copying out of its own reference long enough to be seen. With both, an insider reading 30% more than usual is flagged in a median of 22 days (19 of 20), one reading 50% more in 12 (all 20); a single-day threshold on a trailing baseline flags one of twenty.

29.6 Tutorial: the slow copy

29.7 Build: access control

29.8 Exercises

29.9 Problem: The Slow Copy

29.10 Interview questions