The STRIDE Framework

Alice: Welcome back to Security for Legal SaaS. I’m Alice.

Dan: And I’m Dan. Last episode we introduced threat modelling — the four questions, the whiteboard, the thirty-minute exercise. Today we’re going deep on the framework that makes question two work. STRIDE.

Alice: Six categories of threat. One mnemonic. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Microsoft created it in 1999 — Loren Kohnfelder and Praerit Garg — and it’s still the most widely used threat classification in the industry twenty-seven years later.

Dan: Why has it lasted so long? Frameworks come and go in security.

Alice: Because it’s simple enough to remember in a meeting and comprehensive enough to catch real threats. Each letter maps to a specific security property being violated. Spoofing violates authentication. Tampering violates integrity. Repudiation violates non-repudiation. Information Disclosure violates confidentiality. Denial of Service violates availability. Elevation of Privilege violates authorization.

Dan: So it extends the classic CIA triad — Confidentiality, Integrity, Availability.

Alice: Exactly. CIA covers three of the six. STRIDE adds authentication, non-repudiation, and authorization. If your security review only asks “is it confidential, integral, and available” — you’re missing half the threat surface.

Dan: OK. Let’s make this concrete. Walk me through a STRIDE analysis of something a legal tech team would actually build.

Alice: A document review workflow. Four stages. A lawyer uploads a contract. An AI service analyses it — flags risky clauses, identifies parties, extracts dates. A human reviewer checks the AI’s work and makes privilege designations. Then the reviewed output gets exported to a client portal or opposing counsel.

Dan: And at each stage, you ask all six STRIDE questions?

Alice: Every single one. Let’s start at upload. Spoofing — can someone submit documents without authenticating? If your upload endpoint accepts files without a valid session, an attacker can pollute a matter’s document set. Tampering — can the file be modified between the lawyer’s browser and your server? Without TLS pinning or content verification, a man-in-the-middle could alter the document. Repudiation — if a document gets uploaded, can you prove who did it? If there’s no audit log tied to a verified identity, you cannot.

Dan: That’s only three letters and we’ve already found serious issues at a single stage.

Alice: And we’re not done. Information Disclosure — does the upload response leak metadata? Think filenames, matter IDs, other clients’ document counts in error messages. I’ve seen APIs return “matter M-2847 already has 312 documents” in a 409 conflict response. That tells an attacker which matters exist and how active they are. Denial of Service — can someone upload a 50-gigabyte file and exhaust your storage or tie up your parser for hours? Elevation of Privilege — does the upload endpoint check that the authenticated user actually has write access to that specific matter, or just that they’re logged in somewhere in the system?

Dan: Six questions, six potential threats, one workflow stage. Multiply that across all four stages and you get...

Alice: Twenty-four threat cells. Not all of them will be relevant — some you’ll mark as not applicable. But the discipline of asking forces you to consider threats you’d otherwise miss. The AI analysis stage is particularly interesting. Spoofing might not apply directly, but Elevation of Privilege absolutely does — if your AI service connects to the database with admin credentials instead of scoped, read-only access to the specific document being processed, that’s an elevation of privilege built into your architecture.

Dan: Now, you mentioned earlier that you wanted to talk about repudiation specifically. Why does it matter more in legal tech than in, say, e-commerce?

Alice: In e-commerce, repudiation means a customer disputes a charge. You eat the cost of a refund. Annoying. In legal tech, repudiation means a lawyer claims they never approved a privilege designation — and you can’t prove otherwise. An associate denies reviewing a document before it was produced to opposing counsel. A client says they never authorised disclosure of settlement terms.

Dan: Those are existential-level problems in a legal context. Not “we lost a customer” — more like “we caused a malpractice suit.”

Alice: Exactly. And the ABA has something to say about this.

Dan: Of course they do.

Alice: ABA Formal Opinion 477R requires lawyers to make “reasonable efforts” to prevent unauthorised disclosure. But here’s the thing — if your system cannot prove who did what and when, you’ve failed that standard even if no data actually leaked. The failure isn’t the breach. The failure is the inability to demonstrate what happened. That’s a repudiation failure.

Dan: Give me a real-world example.

Alice: Orrick, Herrington and Sutcliffe. 2023. Unauthorized access went undetected from November 2022 to March 2023 — four months. 637,000 individuals affected. Eight million dollar settlement. One of the core allegations? Inadequate logging and detection. They couldn’t prove the scope of the breach because they couldn’t prove who accessed what. That’s information disclosure compounded by repudiation failure.

Dan: So what does anti-repudiation actually look like in practice?

Alice: Five things. Immutable audit logs — append-only, cryptographically hash-chained, no admin can delete entries. Trusted timestamps — server clock isn’t sufficient; you need RFC 3161 or equivalent. Digital signatures on approvals — when a reviewer designates a document as privileged, they sign that action cryptographically. Segregation of log access — the people who run the system cannot modify the audit trail. And retention aligned to limitation periods — legal matters can litigate years later; your logs need to survive that long.

Dan: That’s a significant engineering investment.

Alice: It is. Which brings us to the practical question — you’ve done your STRIDE analysis, you’ve found twenty-four threats across your workflow. How do you turn that into a backlog your team can actually execute?

Dan: Prioritisation.

Alice: Two axes. Impact and likelihood. High impact, high likelihood — that’s Sprint Zero, fix it before you ship. High impact, low likelihood — schedule it this quarter. Low impact, high likelihood — next sprint. Low impact, low likelihood — document it, accept it consciously, move on.

Dan: And the Verizon data breach report has some relevant stats here.

Alice: The 2024 DBIR found that privilege misuse — which maps directly to Elevation of Privilege in STRIDE — rose to the second most common breach pattern. Internal actors represented 35 percent of breaches, up from 20 percent the prior year. So if your team has been deprioritising EoP findings because “our people are trusted” — the data says otherwise.

Dan: So to summarise — STRIDE gives you a repeatable lens. Six questions at every element of your data flow diagram. For legal tech, Repudiation deserves special attention because provability is as important as prevention. And the output isn’t a report that sits on a shelf — it’s backlog items ranked by impact and likelihood.

Alice: One workflow per sprint. Thirty minutes. Fifteen to twenty-five threats identified. Triage immediately. Three sprints in, you have systematic coverage of your highest-risk flows.

Dan: Next episode — Attack Surfaces in Legal Tech. Every endpoint, every dependency, every integration an adversary can touch.

Alice: Until then, I’m Alice.

Dan: And I’m Dan.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.