Day 68 手法3 : STRIDE Method 3: STRIDE
[シリーズ構造] 柱D｜脅威の現実
本記事では、サイバー脅威の「現実」に正面から向き合い、防御を"起きうる攻撃の姿"に合わせて設計するための考え方を扱います。理想論ではなく、現実の攻撃者を前提に、優先順位と判断力に基づくセキュリティ設計に焦点を当てます。
▶ シリーズ概要： シリーズ全体マップ：人間のしなやかさ ― サイバー判断力のために
▶ 柱D｜脅威の現実 関連記事：
Day 68 手法3 : STRIDE
脅威モデリングを、標準プラクティスへ
攻撃者に、テーブルの席を与えた。すべてのユースケースの隣に、アビューズケースを置いた。手段・機会・動機という視点で、ひとつひとつの機能を検証してきた。
それでも、さらに何かが必要だ。より深い複雑さではない。より重いプロセスでもない。必要なのは、スケールする構造だ。セキュリティの専門家が現れるのを待たずに、チーム全員が使える、共通のレンズ。
アドバーサリアル思考を、散発的な実践ではなく、体系的な習慣へ。
そのために、STRIDE。
なぜ、今でもSTRIDEなのか
STRIDEはマイクロソフトの脅威モデリングフレームワークで、古いと言う人もいる。
その反応は理解できる。今は優れた代替手段がある。OWASP Threat Dragon、IriusRisk、Cairis、ThreatModeler。それぞれが洗練された機能を持っている。自動化された攻撃経路分析、アーキテクチャツールとの統合、継続的な脅威インテリジェンスの更新。多くの実務家がこれらを好む。特定の文脈により適したものもある。そして、その選択を尊重するし、私も使っている。
でも、長年の現場経験から学んだことはシンプルだった。
実行されない脅威モデルは、防御にならない。実際に実行される脅威モデルこそが、最良の脅威モデルである。
STRIDEは無料だ。STRIDEは、昼休みに学んで、その日の午後には実践できるほどシンプルだ。それがすべての状況で理想的か？
いいえ。
しかし、ほとんどの状況で現実的なのだ。
「身の丈にあったセキュリティ」
STRIDEの仕組みに入る前に、ひとつ、ずっと引っかかっていることを言わせてほしい。私が、STRIDEは多くのシステムにとって「十分」だと言うとき、それは、守りを放棄するという意味ではない。軽視するという意味でもない。
すべてのシステムは、セキュリティの検討に値する。すべての機能は、セキュリティを考慮して設計されるべきだ。ただし、すべてが、同じ高さである必要はない。
私はこれを、「身の丈にあったセキュリティ」と呼んでいる。過剰でも、過小でもない。つりあったセキュリティ。
すべてのシステムが、同じ脅威に直面しているわけではない。すべての攻撃者が、同じ能力を持っているわけでもない。公開ブログは、組織犯罪と向き合っていない。決済処理システムは、向き合っている。社内Wikiは、国家主体の攻撃者を想定しなくてよい。防衛請負業者の研究システムは、そうはいかない。
もし無限のリソースがあるなら、無限の予算、無限の専門家、無限の時間があるなら、
私はすべてを、最大の高さと厳密さで守るだろう。
しかし現実には、そんなリソースはない。多くの場合、攻撃者のほうが、私たちより多くのリソースを持っている。だから、選択をしなければならない。それが不都合でも、気持ち悪くても。
STRIDEは、すべてのシステムにベースラインの守りを与える。同時に、トリアージの仕組みとしても機能する。誰が攻撃してくるのか。なぜ攻撃するのか。その前提に立って、どのシステムが、より高い投資を必要としているのかを見極める。これは怠慢ではない。現実に基づいたセキュリティだ。
明日は、各システムに必要な保護レベルを、どうやって正確に決めるのか。セキュリティ投資を、実際の脅威状況にどう合わせるのか。何も放置することなく、どう身の丈にあった防御するのかを探っていく。だが今日は、その普遍的なベースラインとしてSTRIDEを機能させることに、焦点を当てよう。
攻撃者が通り抜ける6つの扉
STRIDEを、攻撃者の6つの扉だと考えてほしい。人間が敵対者のように考えずに設計したとき、システムが失敗する6つの方法だ。
Spoofing（なりすまし） 他人や他のものになりすます
「誰かがユーザー、サービス、またはデバイスになりすますことができるか？」
Tampering（改ざん） データやコードを変更する
「許可なしに、または検知されずに、何が変更されうるか？」
Repudiation（否認） 行動を否定し、痕跡を消す
「ここで悪意のあることをしたとして、どうやって隠すか？ログの盲点はどこにあるか？」
Information Disclosure（情報漏洩） 見るべきでないデータを見る
「機密データがどこで漏れうるか。URL、ログ、エラーメッセージ、ヘッダー、タイミング攻撃で？」
Denial of Service（サービス妨害）システムをオフラインにする
「どうやってこれを圧倒するか？リソースを使い果たしたら何が起こるか？」
Elevation of Privilege（特権昇格） より高い権限を得る
「持っているはずのないデータや権利にどうやって到達できるか？管理者への道はどこにあるか？」
6つの扉。15分かけてそれらを確認する。
15分でSTRIDEを実践する方法
誰も読まない300ページの脅威モデル文書を作るのではない。コードを書く人々の中に気づきを築くのだ。
ステップ1: システムを表す最もシンプルな図を描く。
[ユーザー] → [Webアプリ] → [APIサーバー] → [データベース] → [ファイルストレージ]
ホワイトボード。紙。iPad。手元にあるならナプキンの裏でもいい。図は完璧である必要はない。共有可能である必要がある。部屋にいるみんなが指を指して理解できるもの。
ステップ2: 1つのコンポーネントを選ぶ。STRIDEを実行する。
APIサーバーを指す。
「誰かがここでリクエストを偽装できるか？何がアイデンティティを検証するか？」
「データが転送中に改ざんされる可能性はあるか？何かに署名しているか？暗号化は？」
「誰かが自分の行動を否認できるか？ユーザーコンテキストを含むリクエストをログに記録しているか？」
「何かが漏れるか？APIレスポンス？エラーメッセージ？タイミングの違い？」
「誰かがブルートフォースしたら、これは詰まるか？レート制限は？」
「特権を昇格させる経路はあるか？通常のユーザーがパラメータを変更して管理者エンドポイントにアクセスできるか？」
それから次のコンポーネントへ移る。すべてを解決する必要はないが、すべてを見る必要がある。見つけたことを文書化する。決定を記録する。さらなる調査が必要なことに印をつける。
15分。 エネルギーが尽きたら止める。
ステップ3: 重要なことを書き留める。
正式な文書ではない。ただのメモ。
- 発見した脅威
- 下した決定
- まだ答えが出ていない疑問
これがあなたの共有メモリーになる。チームのセキュリティ意識が形になったもの。
ステップ4: システムが変わったら再検討する。
新機能？新しい統合？新しいデータフロー？
STRIDEを再度実行する。簡潔に。意図的に。これは一度きりの儀式ではない。構築方法に組み込まれた習慣だ。
例えば、 ファイルアップロード機能。
機能: ユーザーがプロフィール画像をアップロードできる。
15分のSTRIDEセッション:
Spoofing（なりすまし）:
「攻撃者が他人のプロフィール画像だと主張してファイルをアップロードできるか？」
→ 決定: アップロードを受け入れる前にユーザーセッションを検証する。
Tampering（改ざん）:
「誰かがファイルパスを変更してシステムファイルを上書きできるか？」
→ 決定: サーバー側でランダムなファイル名を生成し、クライアント入力を決して信頼しない。
Repudiation（否認）:
「誰かが違法なコンテンツをアップロードした場合、誰がやったか証明できるか？」
→ 決定: ユーザーIDとタイムスタンプでアップロードをログに記録する。
Information Disclosure（情報漏洩）:
「アップロードされたファイルが予測可能なURLを通して情報を漏らす可能性はあるか？」
→ 決定: 非連続のIDを使用し、ファイルを提供する前にアクセスコントロールを実装する。
Denial of Service（サービス妨害）:
「誰かが10GBのファイルをアップロードしたら何が起こる？または10,000ファイル？」
→ 決定: ファイルサイズ制限（5MB）、レート制限（1時間に10アップロード）。
Elevation of Privilege（特権昇格）:
「誰かが画像を装ったPHPシェルをアップロードできるか？」
→ 決定: ファイルタイプを内容で検証（拡張子ではなく）、実行不可能なディレクトリに保存、正しいContent-Typeヘッダーで提供。
経過時間: 12分。
捕捉された脆弱性: 6つの主要な攻撃手法。
コスト: 無料。
同じ機能。同じタイムライン。しかしセキュリティがパッチとして追加されるのではなく、設計に組み込まれて出荷される。
STRIDEをワークフローの一部にする
STRIDEが任意であれば、消える。フォーム上のチェックボックスであれば、形骸化する。人々は問題を見つけるためではなく、承認を得るために記入する。だから、既に存在する儀式にくっつける。
スプリントプランニング: 「このストーリーにコミットする前に、STRIDEのリスクは何か？」
コードレビュー: 「プランニングで特定したSTRIDEの発見事項に対処したか？」
アーキテクチャレビュー: 「15分のSTRIDEウォークスルーなしではサインオフはない。」
新しい儀式はいらない。魔法の言葉もいらない。
ただ一貫性。
最初の数回はぎこちなく感じる。何が「本当の」脅威としてカウントされるのか、人々は確信が持てない。明白なことに時間を無駄にしているのではないかと心配する。
それでいい。ただ続けていくだけ。数週間以内に、何かが変わる。
STRIDEが標準になると何が変わるか
異なる会話が聞こえ始める。
「待って。情報漏洩。URLに顧客IDを漏らしているのでは？ブラウザを持つ誰もがそれをインクリメントできる。」
「このAPIは誰が変更したかをログに記録していない。何か問題が起きたら、否認の問題を抱えることになる。」
「このエンドポイントでクレームを検証していない。これは特権昇格が起こるのを待っているようなものだ。」
これらを話しているのはセキュリティ専門家ではない。
開発者、プロダクトマネージャー、QAエンジニア、セキュリティが自分の仕事だとは思っていなかった人々だ。彼らが脅威を捕捉しているのは、一夜にしてセキュリティエンジニアになったからではない。
実際に使えるレンズを与えられたからだ。
STRIDEは深い専門知識を必要としない。6つの異なる角度からながめることができるレンズ。そして一度人々がこれらの質問をし始めると、セキュリティが現れて物事を捕捉するのを待つのをやめる。
彼ら自身が捕捉する。
STRIDEがより大きな何かを明らかにするとき
いくつかのSTRIDEセッション中に起こることがある。会話が1つのコンポーネントに戻り続ける。
「待って、これが壊れたら、何が...」
誰かが言う:「これは15分以上必要な気がする。」
システムを流れるデータが非常に機密性の高いものであることが判明する。
こう考える自分に気づく:「攻撃者は実際にこれを標的にするだろう。」
これらのシグナルを見たとき、あなたは重要な何かを発見した。
STRIDEが教えてくれたのだ。このシステムはベースライン保護以上のものを必要としている。
しかしどれだけ多く？何に基づいて？
それが明日探ることだ。
なぜなら、すべてのシステムが同じ脅威に直面しているわけではないからだ。すべての攻撃者が同じ能力を持っているわけでもない。
そして公開ブログを決済処理システムと同じように扱うことは、単に非効率なだけではない。最も重要なものを保護不足のままにする、限られたリソースの誤配分なのだ。
明日、各システムが実際に必要とする保護レベルを、誰が攻撃しようとしているのか、なぜ攻撃するのかに基づいて、どう決定するかについて話す。
どのシステムも見捨てない。各システムを適切に保護することを見ていく。
その為に明日、もうひとつ、ピースを追加する。
重要なのは、完璧なセキュリティではない。セキュリティは、少数の人だけが実践する特別な儀式であってはいけない。
必要なのは、
セキュリティが埋め込まれた組織。
セキュリティが根づいたチーム。
セキュリティを自分の判断として扱える人。
それは、専門知識ではない。多くの人が共有する、リテラシーだ。
それが、私が目指す転換。
今日はこの辺で、また明日。
―――
[Series Structure] Pillar D | Threat Reality
This article confronts the reality of cyber threats and examines how defenses must be aligned with how attacks actually occur--not how we wish they would. It focuses on judgment, prioritization, and designing security for real adversaries, not ideal conditions.
▶ Series overview: Series Overview -- Human Flexibility for Cyber Judgment
▶ Other posts in Pillar D (Threat Reality):
Method 3 ： STRIDE
Threat Modeling as Standard Practice
We've given the attacker a chair at the table.
We've placed abuse cases alongside every use case, examining each feature through means, opportunity, and motive.
Now we need something more.
Not deeper complexity. Not heavier process.
We need structure that scales. A lens the entire team can use without waiting for a security expert to show up.
A way to make adversarial thinking systematic instead of sporadic.
For that, I use STRIDE.
Why STRIDE, Still
STRIDE is Microsoft's threat modeling framework, old enough that some dismiss it as outdated.
I understand that reaction.
There are excellent alternatives now such as OWASP Threat Dragon, IriusRisk, Cairis, ThreatModeler. Each brings sophisticated capabilities such as automated attack path analysis, integration with architecture tools, continuous threat intelligence updates.
Many practitioners prefer these. Some are better suited for specific contexts. And I respect that choice completely.
But here's what I've learned after years of trying to embed security into teams that ship daily:
The best threat model is the one that actually gets done.
STRIDE is free. STRIDE is simple enough that a developer can learn it during lunch and apply it that afternoon.
Does that make it ideal for every situation?
No.
But it makes it real for most situations.
A Critical Point About Proportionality
Before we dive into STRIDE mechanics, I need to address something that's been weighing on me. When I say STRIDE is "good enough" for most systems, I'm not saying we abandon or under-protect any system. I'm not saying security doesn't matter for "ordinary" features.
Every system deserves security consideration. Every feature should be built with security in mind.
What I am saying is this:
Security must be proportionate.
Not all systems face the same threats. Not all attackers have the same capabilities.
A public blog doesn't face organized cybercrime. A payment processor does.
An internal wiki doesn't face nation-state actors. A defense contractor's research system does.
If I had unlimited resources, unlimited budget, unlimited security professionals, unlimited time, I would protect everything with maximum depth and rigor. But I don't. And attackers often have more resources than we do.
So I have to make choices. Uncomfortable choices.
STRIDE provides baseline protection for everything. And it also acts as a triage mechanism helping us identify which systems need deeper investment based on who's actually attacking them and why.
That's not negligence. That's reality-based security.
Tomorrow, we'll explore exactly how to determine what level of protection each system needs. How to match security investment to actual threat landscapes. How to defend proportionately without leaving anything unprotected.
But today, let's focus on making STRIDE work as that universal baseline.
The Six Doors Attackers Walk Through
Think of STRIDE as six ways systems fail when humans design them without thinking like adversaries.
Spoofing - pretending to be someone or something else
"How could someone impersonate a user, a service, or a device?"
Tampering - altering data or code
"What could be changed without permission or detection?"
Repudiation - denying actions or covering tracks
"If I did something malicious here, how would I hide it? Where are the blind spots in our logging?"
Information Disclosure - seeing data you shouldn't see
"Where could sensitive data leak--in URLs, logs, error messages, headers, timing attacks?"
Denial of Service - taking systems offline
"How would I overwhelm this? What happens if I exhaust the resources?"
Elevation of Privilege - gaining higher permissions
"How could I reach data or rights I'm not supposed to have? Where's the path to admin?"
Six doors.
We spend fifteen minutes checking them. That's usually enough to surface what matters.
How I Apply STRIDE in 15 Minutes
We're not building a 300-page threat model document that no one reads. We're building awareness in the people who write the code.
Here's how it works.
Step 1: Draw the simplest picture that represents the system.
[User] → [Web App] → [API Server] → [Database] → [File Storage]
Whiteboard. Paper. iPad. Back of a napkin if that's what you have.
The diagram doesn't need to be perfect.
It needs to be shareable, something everyone in the room can point at and understand.
Step 2: Pick one component. Run through STRIDE.
Point at the API server.
"Can someone spoof a request here? What validates identity?"
"Could data be tampered with in transit? Are we signing anything? Encrypting?"
"Could someone repudiate their actions? Do we log requests with user context?"
"Does anything leak? API responses? Error messages? Timing differences?"
"Could this choke if someone brute-forced it? What's our rate limit?"
"Any path to elevate privileges? Can a regular user hit admin endpoints by changing a parameter?"
Then move to the next component. You don't need to solve everything. You need to see everything. Document what you find. Capture decisions. Mark what needs more research.
Fifteen minutes. Stop when the energy runs out.
Step 3: Write down what matters.
Not a formal document. Just:
- The threats you discovered
- The decisions you made
- The open questions you still have
This becomes your shared memory. Your team's security consciousness made tangible.
Step 4: Revisit when the system changes.
New feature? New integration? New data flow?
Run STRIDE again. Briefly. Intentionally.
This isn't a one-time ritual. It's a habit embedded in how you build.
File Upload Feature
Let me show you what this looks like in practice.
The Feature: Users can upload profile pictures.
15-Minute STRIDE Session:
Spoofing: "Can an attacker upload a file claiming to be someone else's profile picture?"
→ Decision: Validate user session before accepting uploads.
Tampering: "Could someone modify the file path and overwrite system files?"
→ Decision: Generate random filenames server-side, never trust client input.
Repudiation: "If someone uploads illegal content, can we prove who did it?"
→ Decision: Log uploads with user ID and timestamp.
Information Disclosure: "Could uploaded files leak information through predictable URLs?"
→ Decision: Use non-sequential IDs, implement access controls before serving files.
Denial of Service: "What happens if someone uploads a 10GB file? Or 10,000 files?"
→ Decision: File size limits (5MB), rate limiting (10 uploads per hour).
Elevation of Privilege: "Can someone upload a PHP shell disguised as an image?"
→ Decision: Validate file types by content (not extension), store in non-executable directory, serve with correct Content-Type headers.
Time elapsed: 12 minutes.
Vulnerabilities caught: 6 major attack vectors.
Cost: Free.
Same feature. Same timeline. But now it ships with security designed in, not patched on.
Making STRIDE Part of the Workflow
If STRIDE is optional, it disappears. If it's a checkbox on a form, it becomes theater, people fill it out to get approval, not to find problems. So I anchor it into rituals that already exist:
Sprint Planning: "Before we commit to this story, what are the STRIDE risks?"
Code Review: "Did we address the STRIDE findings we identified in planning?"
Architecture Review: "No sign-off without a 15-minute STRIDE walkthrough."
No new ceremonies. No magic words.
Just consistency.
The first few times feel awkward. People aren't sure what counts as a "real" threat. They worry they're wasting time on obvious things.That's fine. Keep going.Within a few weeks, something shifts.
What Changes When STRIDE Becomes Standard
You start hearing different conversations.
"Wait--information disclosure. Are we leaking customer IDs in the URL? Anyone with a browser can increment that."
"This API doesn't log who made the change. If something goes wrong, we've got a repudiation problem."
"We're not validating claims on this endpoint. That's elevation of privilege waiting to happen."
These aren't security experts talking.
These are developers, product managers, QA engineers--people who never thought security was their job. They're not catching threats because they became security engineers overnight. They're catching threats because they were given a lens they can actually use. STRIDE doesn't require deep expertise.
It requires a willingness to ask questions from six different angles.
And once people start asking those questions, they stop waiting for security to show up and catch things. They catch them themselves.
When STRIDE Reveals Something Bigger
Here's what happens during some STRIDE sessions: The conversation keeps returning to a single component. "Wait, if this breaks, what happens to..."
Someone says: "This feels like it needs more than fifteen minutes."
The data flowing through the system turns out to be highly sensitive.
You find yourself thinking: "An attacker would actually target this."
When you see these signals, you've discovered something important.
STRIDE just told you: this system needs more than baseline protection.
But how much more? And based on what criteria?
That's what we'll explore tomorrow.
Because not every system faces the same threats. Not every attacker has the same capabilities.
And treating a public blog the same as a payment processor isn't just inefficient--it's a misallocation of limited resources that leaves the things that matter most under-protected.
Tomorrow, we'll talk about how to determine what level of protection each system actually needs, based on who's trying to attack it and why.
We're not abandoning any system. We're learning to protect each one appropriately.
What We've Built
- Day 66: The Red Chair--giving the attacker a permanent seat at the table
- Day 67: Abuse Cases with MOM--documenting how features can be misused
- Day 68: STRIDE--systematizing threat modeling as standard practice
Together, these give teams a way to think like attackers without needing to become attackers.
The Red Chair establishes the mindset.
Abuse Cases document the threats.
STRIDE provides the systematic lens.
Tomorrow, we add one more piece: knowing when to go deeper.
Because the point isn't perfect threat models. The point is a team that thinks like attackers without needing an attacker in the room. A team that doesn't ship information disclosure bugs because someone asked the question during code review. A team that knows when something matters enough to escalate.
Security stops being an exotic skill practiced by a few. It becomes literacy shared by many.
That's the shift I am after.
See you tomorrow.
--------
References will be added at the end of the series.
参考文献・出典は、このシリーズの最後に一覧としてまとめます。