Security Compliance in Simple English

STRIDE is a threat modeling checklist from Microsoft. Its name is the first letter of six threat types. For each part of your system you ask: "Could an attacker do this?"

Each letter breaks one security property: authentication, integrity, accountability, confidentiality, availability, authorization. That makes it easy to link each threat to a control.

You do not need special tools. A whiteboard and an hour are enough for the first round.

1. Draw a data flow diagram: users, services, databases, and the arrows between them.
2. Mark trust boundaries. A boundary is a line where the level of trust changes, such as the internet to your backend, or your backend to a vendor.
3. Apply STRIDE to each part. The table below shows which letters usually apply.
4. Rank each threat as high, medium or low.
5. Fix the threat with a control, or accept it and write down why.
6. Record the result and link it to tickets and tests.

Which letters apply to which part

A simple risk ranking

Imagine a web app called Inbox Summarizer. Users connect their Gmail, and the app uses AI to summarize their email. It needs a Gmail restricted scope, so it will need CASA. Business customers will also ask for SOC 2.

Step 1 and 2: draw it and mark the boundary

Step 3 to 5: threats, fixes and ranks

Look at how the table reads like a to-do list. Every row has a fix and a rank. That is exactly what an auditor wants: risks that are found, rated and followed to the end.

A team app where people upload files and share them with a link. The new risk here is untrusted files and links that leave your system.

The dashed line is the trust boundary. A person who opens a shared link is outside it, so if a setting is wrong, every file they can reach is exposed.

What is different from Example 1

• The big risks are information disclosure (a wrong link or bucket setting) and tampering (a bad file).
• One config setting (a public bucket) can break everything. Put the setting and a check for it in your evidence.
• For CASA, uploads fall under data validation: limit them to expected file types, and make sure uploaded content cannot run by itself.

Your app receives events from a payment provider, such as "invoice paid". The endpoint is public, and you must trust what arrives. This is a small system, but spoofing and replay are classic problems.

The red dashed arrow is an attacker pretending to be the payment provider. The only thing that tells the two senders apart is the signature, which the endpoint checks with the signing secret.

What is different from Example 1

• There are no user logins here. The proof of who is calling is a signature, so spoofing (S) is about the signature check.
• The rule of thumb: do not act on an event you did not verify.
• For SOC 2 this supports CC6 (access) and CC7 (monitoring). Failed signature checks are a good alert.
• CASA has no webhook-specific section, so follow your provider's own webhook guide.

A threat model is only useful if the fix is proven. Here is one row, T2 from Example 1, followed from the model to the evidence. In T2 a user changes an ID in the URL and reads another user's summary. Security people call this an IDOR (insecure direct object reference).

The fix

// Before: any signed-in user can read any summary by guessing the ID
app.get('/summaries/:id', auth, async (req, res) => {
  res.json(await db.summaries.findById(req.params.id));
});

// After: the query is limited to the signed-in user's own rows
app.get('/summaries/:id', auth, async (req, res) => {
  const row = await db.summaries.findOne({
    id: req.params.id,
    ownerId: req.user.id,
  });
  if (!row) return res.status(404).end();   // same answer for "missing" and "not yours"
  res.json(row);
});

The test

test('owner can read a summary, another user cannot', async () => {
  const summary = await createSummary(userA);

  const own = await api.as(userA).get(`/summaries/${summary.id}`);
  expect(own.status).toBe(200);
  expect(own.body.id).toBe(summary.id);

  const other = await api.as(userB).get(`/summaries/${summary.id}`);
  expect(other.status).toBe(404);
});

The code returns the same 404 for "not found" and "not yours", so an attacker cannot learn which IDs exist. The test has two halves on purpose: the first proves the endpoint works for the owner, so a route that returns 404 for everyone cannot pass.

Where this one threat counts

One small row gave you proof for three or four frameworks. Do this for every high-risk threat and your evidence folder fills up with real, dated records.

SOC 2 does not ask for STRIDE. It asks whether you identify and assess risks (CC3). In a Type II report, the auditor then tests whether your controls worked over the whole period. A threat model does not replace the company-wide risk assessment, which auditors usually expect as a risk register that management reviews every year. But it is the detailed input to that register, and every STRIDE letter points to controls you already need.

Where the threat model itself is evidence

Criteria numbers follow the 2017 Trust Services Criteria. Only the Security criteria (the common criteria, CC) are always in scope. The A1 (Availability) and C1 (Confidentiality) rows apply only if you chose those categories. Confirm the mapping with your auditor, because each firm tests slightly different things.

CASA does not ask for STRIDE either, and its own v2 specification has no threat-modeling requirement. (OWASP ASVS, which CASA builds on, does ask for threat modeling at its higher levels.) The lab tests your app against the CASA specification. The best way to pass is to find and fix those problems before the lab does, and a threat model is a good way to do that.

The table maps each STRIDE letter to the CASA areas. Notice that CASA is narrower than STRIDE: it says little about audit logging or denial of service, so Repudiation and Denial of service matter more for SOC 2 than for CASA.

How to use it for CASA

1. Run the STRIDE session for the app, with the Google data flow on the diagram.
2. Use the table above to turn each high-risk threat into a test.
3. Run your own scans and tests. Fix the findings.
4. Keep the reports. Under AL1 you hand your evidence to the lab. Under AL2 the lab tests the app itself. Keep everything for the renewal, which is at least every 12 months.

CASA is updated from time to time. Check the current spec and the assurance level Google gives your app before you plan.

A threat model on a shared drive proves little. Auditors want to see the whole chain: threat, ticket, fix, test, proof.

A folder layout that keeps evidence easy to find

security/
├── threat-models/
│   ├── inbox-summarizer-2026-10.md     (the model above)
│   └── diagrams/
│       └── inbox-summarizer-dfd.png
├── evidence/
│   ├── 2026-10-mfa-settings.png
│   ├── 2026-10-idor-test-report.pdf
│   └── 2026-11-casa-scan-report.pdf
└── reviews/
    └── review-log.md                   (dates of every re-check)

A template for the threat model file

# Threat model: Inbox Summarizer
Owner: <name>       Date: 2026-10-25       Next review: 2027-04-25
Scope: web app, API, database, Gmail API flow

## Diagram
(link to the data flow diagram, with trust boundaries)

## Threats
| ID | Part     | STRIDE | Threat                       | Fix                          | Risk | Ticket   | Status |
|----|----------|--------|------------------------------|------------------------------|------|----------|--------|
| T2 | Web API  | E      | User reads another's summary | Owner check on every request | High | SEC-114  | Done   |

## Accepted risks
- <risk>: <why we accept it>, approved by <name> on <date>

## Review log
- 2026-10-25: first version