Day 67 手法2: ユースケースの隣に、アビューズケースを置く Method 2: Abuse Cases Alongside Use Cases
[シリーズ構造] 柱D｜脅威の現実
本記事では、サイバー判断力を狙う脅威の現実を直視し、防御設計を現実に合わせるための問いと原則を紹介します。攻撃は「完璧さ」ではなく「優先順位」、網羅ではなく「判断力」を求めます。
▶ シリーズ概要： シリーズ全体マップ：人間のしなやかさ ― サイバー判断力のために
Day 67 手法2: ユースケースの隣に、アビューズケースを置く
機能を明確にする
私のキャリアの大半において、セキュリティレビューは、いつも同じ光景から始まっていました。
テーブルを囲み、あるときは国連の施設で、あるときは保険会社のバックオフィスで、またあるときは、スピード感のあるプロダクトチームの中で。私たちは「正しい」とされる問いを投げかけます。
「この機能は、何をするためのものか」
「誰のためのものか」
「ビジネスに、どう貢献するのか」
そして私たちは、ユースケースを書く。整っていて、論理的で、責任の所在も明確なものを。
それでも数年後、私は気づけば、まさにそのレビューを通過したはずのインシデントを調査しているのです。
機能に問題はなかった。
ポリシー違反もなかった。
チェックリストも、すべて通っていた。
問題は、もっとシンプルで、そして、もっとざらざらするものでした。
私たちは、善意しか想像していなかったのです。
まず、わかりやすい言葉で整理しておきましょう。
- ユースケースとは、すべてが順調に進んだときに、その機能が どのように使われることを想定しているか を示すものです。
- アビューズケースとは、誰かが意図的に害を及ぼそうとしたときに、同じ機能が どのように悪用され得るか を描いたものです。
では、なぜアビューズケースが重要なのでしょうか。その理由を説明するために、私はこれまで調査してきた ほぼすべてのインシデントで当てはまっていた、ひとつのシンプルなレンズを使います。
手段、機会、動機（MOM）を通して機能を見る
害が発生するためには、3つの要素が揃わなければならない：
- 手段（Means） - システムが可能にすること
- 機会（Opportunity） - 悪用が実行可能になる時や場所
- 動機（Motive） - なぜ誰かがそれを悪用するのか
このフレームワークは犯罪学に直接由来します。具体的には、Cohen & Felson（1979）によって開発された日常活動理論（Routine Activity Theory: RAT）です。RATは、犯罪が以下の条件で発生すると述べています。
- 動機づけられた犯罪者が存在する
- 適切な標的が利用可能である
- 有能な監視者が不在である
たとえば、万引きはこうして起こります。
- 盗む気のある人がいて
- 手に取りやすい商品が棚に並び
- 店員や防犯の目が届いていない
この三つがそろった瞬間、犯罪は「特別な出来事」ではなく、日常の中で自然に発生するものになります。
サイバーでも、構造は同じです。
- 侵入する気のある攻撃者がいて
- 狙いやすいアカウントや機能があり
- 検知や確認が働いていない
この三つがそろった瞬間、サイバーインシデントは高度なハッキングではなく、「起きて当然の出来事」になります。
デジタルシステムにおいては、機能そのものが、しばしばこの三つすべてを同時に提供してしまいます。ほとんどのセキュリティ障害は、何か一つが間違っていたから起こるのではありません。機能が、静かに手段・機会・動機を一度に差し出したとき、インシデントは起こるのです。
心理学的視点：なぜアビューズケースを見逃すのか
機能的固着（認知バイアス）
私たちは、物や機能を「意図された用途」の視点からしか見なくなる傾向があります。パスワードリセットは「ユーザーを助けるため」のもの。メールアドレス変更は「利便性のため」のもの。このように、機能を"善意の物語"の中だけで捉えてしまう。
機能が「何のために作られたか」は見える。しかし、「何に使われ得るか」は見えなくなる。だからこそ、敵対的思考は自然に生まれるものではなく、構造としてスクリプト化されなければならないのです。心理学では、これを 機能的固着（Functional Fixedness） と呼びます。
意図と行動のギャップ（実装科学）
多くのチームは、こう言います。
「ちゃんと攻撃者視点で考えようとしている」と。
それでも実際には、構造に促されない限り、人は行動しません。
ここで有効になるのが、Gollwitzerが提唱した 実装意図（Implementation Intention） という考えです。それは、次のような 事前の取り決め です。
「もし、私たちが機能Xを設計するなら、そのとき、MOMを使ってアビューズケースYを必ず文書化する」
この「もし〜なら、そのとき〜する」という約束は、機能設計を静かに支配している 楽観的な思い込みをすり抜けます。
「考えるつもりだった」を、「その場で考えざるを得ない」に変える。
それが、実装意図の力です。
発想の勧め
今日から、私は小さく、しかし強力な転換を提案します。
すべての機能は、これまで通りユースケースを持つ。しかし同時に、手段・機会・動機を通して検証されるアビューズケースも持つ。これは、恐怖を追加することではありません。明確さを追加することです。
そのためのフォーマットは、あえてシンプルなままにします。
攻撃者として、私は［悪意のある行動］をしたい。そうすれば、［有害な目標］を達成できる。
この一文が、次の三つの問いを否応なく突きつけます。
- この機能は、私に何をすることを許しているのか。（手段）
- それは、いつ・どんな状況で可能になるのか。（機会）
- なぜ、そうしたくなるのか。（動機）
この問いに向き合った瞬間、リスクはもはや抽象ではなくなります。
設計の言葉に、現実の輪郭が宿るのです。
例1：パスワードリセット
ユースケース
正当なユーザーとして、私は忘れたパスワードをリセットし、アカウントへのアクセスを回復したい。
アビューズケース
攻撃者として、私はパスワードリセットを繰り返し発動させ、有効なアカウントを特定したり、ユーザーをロックアウトしたり、偽の復旧メッセージを信頼するよう誘導したい。
MOMで読み解く
- 手段：リセットの仕組みそのもの。公開され、自動化され、誰でも触れられる。
- 機会：レート制限の欠如、予測しやすい挙動、狙いやすいタイミング。
- 動機：アカウントの洗い出し、サービス妨害、フィッシングの足がかり。
同じ機能。同じボタン。まったく異なる結果。パスワードリセットは、単なる利便性ではありません。信頼のインフラなのです。
例2：メールアドレス変更
ユースケース
ユーザーとして、私は登録されているメールアドレスを変更し、通知や復旧メッセージを引き続き受け取りたい。
アビューズケース（シンプルフォーマット）
攻撃者として、私は被害者のアカウントに登録されたメールアドレスを変更したい。
そうすれば、将来のすべての通知と復旧フローを自分にリダイレクトできる。
MOMで読み解く
- 手段：信頼メッセージが「どこに届くか」を決める権限。
- 機会：低リスクなプロフィール更新として扱われ、検証や確認が弱い。
- 動機：静かで、長期間気づかれにくいアカウント乗っ取り。
私は、被害者が 数週間後になって初めて異変に気づいた ケースを調査したことがあります。復旧メールが、もう届かなくなっていたときでした。メールアドレス変更は、
単なるプロフィールの衛生管理ではありません。アイデンティティの移転なのです。
例3：多要素認証（MFA）の登録
※ 多要素認証（MFA／2要素認証とも呼ばれる）とは、パスワードに加えて、SMSコード、認証アプリ、ハードウェアトークンなど複数の要素による確認を要求する仕組みです。適切に使われれば、アカウント乗っ取りのリスクを大幅に下げます。
ユースケース
ユーザーとして、私は多要素認証を登録し、アカウントをより安全にしたい。ベストプラクティスです。
アビューズケース（シンプルフォーマット）
攻撃者として、私は一度得たアクセスを使って自分のMFAデバイスを登録したい。そうすれば、パスワードが変更された後でも、本当のユーザーを永久に締め出すことができる。
MOMで読み解く
- 手段：新しい認証要素をアカウントに結び付ける権限。
- 機会：フィッシングやセッションハイジャックにより、一時的でも初期アクセスが得られた瞬間。
- 動機：永続的な支配、完全なコントロール、正当な所有者の排除。
これは、多くのチームを驚かせます。MFAは、確かに 保護です。しかし同時に、それは 所有権でもあります。登録が高リスクな操作として扱われないとき、セキュリティ対策そのものが、攻撃の道具になり得ます。
例4：承認フロー
ユースケース
マネージャーとして、私はビジネスオペレーションが遅くならないように、リクエストを効率的に承認したい。承認は仕事を可能にするために存在する。
アビューズケース
攻撃者として、私はリクエストをルーティンで緊急に見せかけて、精査なしに自動的に承認されるようにしたい。
MOMで読み解く
- 手段：ワークフローに埋め込まれた委任された権限
- 機会：高ボリューム、時間的プレッシャー、慣れが自動化を生む
- 動機：詐欺、権限昇格、金銭的利益
攻撃者はシステムを壊さない。システムに溶け込む。
承認システムは、人々が不注意だから失敗するのではなく、スピードと信頼のために最適化されているから失敗する。まさに攻撃者が悪用するものです。
これは社会工学理論とCialdini（1984）の影響力の原則、「権威」「緊急性（今すぐ）」、そして「まわりもやっている」という感覚、に通じるものです。
デジタルの仕組みは、ときに、こうした人を動かすきっかけを、そのまま画面の中に組み込みます。そして一度組み込まれると、それは人の判断に直接働きかける力として、
大量に、繰り返し、悪用できる形になってしまうのです。
なぜこれがセキュリティの会話を変えるのか
チームがユースケースだけを文書化するとき、彼らは 「善意の世界」 のために設計します。一方で、MOMを使ってアビューズケースを加えるとき、彼らは 「現場で本当に起きている現実」 のために設計します。
その瞬間、機能は「良い」「悪い」という評価から解放されます。機能は、能力として見られるようになる。手段・機会・動機がどう重なり合うかによって、人を助けることも、害を及ぼすこともできる能力として。
私がこれまで調査してきたインシデントのほとんどは、高度で巧妙なハッキングから始まったわけではありません。設計どおりに、正しく動いていた、ごく普通の機能から、始まっていました。
日常化する方法
アビューズケースを、「あとから付け足すもの」として扱ってはいけません。それを、仕事の流れそのものに溶かし込むのです。具体的には、いま使っている課題管理の仕組みに必須項目として組み込みます。（Jiraでも、Backlogでも、Linearでも、Asanaでも構いません）
最低限、次の項目をそろえます。
- ユーザーストーリー： 正当な利用者が何をしたいのか
- 受け入れ条件： それが「正しく動いている」と、どう判断するか
- アビューズケース： 攻撃者がそれをどう悪用し得るか ← 新たに追加
- セキュリティ対策： その悪用をどう防ぐか ← 新たに追加
ルールは一つ。アビューズケースのないストーリーは、承認しない。
最初は、きっとこう感じるでしょう。
「余計な手間だ」
「開発のスピードが落ちる」
実際、最初はそう見えます。
1〜2週目 ストーリー1本あたり、10〜15分ほど余計にかかる。エンジニアから不満が出る。
3〜4週目 よくある悪用の型が見えてくる。チームがひな型を作り始める。考える時間は5分程度に減る。
2か月後 最初のセキュリティ問題が、設計段階で止められる。本来なら、公開後に3週間かけて直していたはずの欠陥が、そもそも作られずに済む。ここで、効果が数字として見え始める。
4か月後 それは「考える作業」ではなく、体に染みついた動きになる新しく入った人も、初日から自然にアビューズケースを書く。セキュリティの借金が、増えなくなる。
この変化は、「遅い」から「速い」への転換ではありません。
「起きてから火を消す」やり方から、
「最初から見通しを持つ」やり方への転換です。
最初は、減速したように感じる。
次に、それはフィルターになる。
そして、いつの間にか、筋肉記憶になる。
これが、敵対的な考え方が「特別なセキュリティ活動」から、「ここで物を作るときの当たり前」へと変わっていく方法です。
なぜ、これが機能するのか
― 理論的な裏づけ ―
このやり方は、思いつきでも精神論でもありません。複数の分野で確立されてきた理論に、しっかりと支えられています。
- 日常活動理論（Cohen & Felson, 1979）
手段・機会・動機を分析するという発想は、犯罪学における日常活動理論に直接基づいています。この理論は、犯罪を「悪い人の問題」ではなく、時間と空間の条件がそろった結果として捉えます。アビューズケースを書くという行為は、次の問いを、設計の中に持ち込むことに他なりません。この機能は、害が起きやすい「時間」と「状況」の重なりを生み出していないだろうか？犯罪学の視点を、そのままデジタル設計に落とし込んでいるのです。
- 状況的犯罪予防（Clarke, 1980）
アビューズケースは、状況的犯罪予防を実践するための道具でもあります。この考え方は、「人を変える」のではなく、環境を変えることで行動を変えるというものです。
具体的には、次のような方向に環境を調整します。
- 手間を増やす
- 見つかる可能性を高める
- 得られる見返りを減らす
- 衝動や誘惑を弱める
- 「ついやってしまった」という言い訳を消す
各アビューズケースに対して対策を結びつける行為は、まさにこの理論を、設計の中で実行していることになります。
- 実装意図（Gollwitzer, 1999）
「もし機能を設計するなら、必ずアビューズケースを書く」
このルールは、敵対的に考えることを努力にしないための仕掛けです。心理学でいう実装意図は、「考えるつもりだった」を「その場で必ず行う」に変えます。
あらかじめ決められた「もし〜なら、そのとき〜する」という形が、攻撃者のように考えるための記憶負担を取り除き、思考を自動化します。
- 認知的な強制機能（医療安全の分野）
アビューズケースを必須にすることは、強制機能としても働きます。つまり、立ち止まって考えない限り、危険な設計をそのまま進めることができない。これは医療安全の分野で使われてきた発想です。危険な行為を「注意してください」と言うのではなく、考えずに進めない構造にしてしまう。アビューズケースは、設計におけるその役割を果たしています。
こうして見ると、この方法は一貫しています。
- 人の善意に頼らない
- 記憶や注意力に頼らない
- 後悔や反省に期待しない
現実の人間と、現実の現場を前提にした設計だからこそ、静かに、しかし確実に機能するのです。
文化的シフト
これが日常になると、静かに、しかし確かな変化が起こります。
- 開発者は、頼まれる前からアビューズケースを書き始める。
- 会議には、攻撃者の視点からの問いを持って現れる。
- セキュリティは、もはや門番ではない。共有されたレンズになるのです。それが、目指す姿です。
これまでに積み上げてきたもの
- Day 65：セキュリティの視点を理解するー 複数の層でリスクを見る
- Day 66：敵対的な考え方を身につけるー攻撃者のように考える
- Day 67：MOMを使ってアビューズケースを書くー 手段・機会・動機で攻撃者の論理を言語化する
これらは一つの、はっきりした習慣を形づくります。機能を設計するたびに、どう悪用され得るかを考え、その思考を手段・機会・動機で書き残す。
明日は、三つ目の手法に進みます。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
Method 2: Abuse Cases Alongside Use Cases
Turning Features Into Clarity
In most of my career, security reviews began the same way.
We gathered around a table--sometimes in a UN compound, sometimes in a global bank, sometimes inside a fast-moving product team--and asked the right questions:
"What is this feature supposed to do?" "Who is it for?" "How does it help the business?"
We wrote use cases. Clean ones. Logical ones. Responsible ones.
And yet, years later, I often found myself investigating incidents that had passed through those very same reviews.
Nothing was "wrong" with the feature. Nothing violated policy. Nothing failed a checklist.
The problem was simpler and more uncomfortable.
We had only imagined good intentions.
Let's Ground Ourselves in Plain English
- A use caseis how a feature is meant to be used when everything goes right.
- An abuse caseis how the same feature can be misused when someone intentionally tries to cause harm.
To understand why abuse cases matter, I rely on a simple lens that has held true across almost every incident I've investigated:
Seeing Features Through Means, Opportunity, and Motive (MOM)
For harm to occur, three elements must come together:
- Means- what the system makes possible
- Opportunity- when or where misuse becomes feasible
- Motive- why someone would exploit it
This framework comes directly from criminology--specifically Routine Activity Theory (RAT), developed by Cohen & Felson (1979). RAT states that crime occurs when:
- A motivated offender exists
- A suitable target is available
- Capable guardianship is absent
In digital systems, the feature itself often supplies all three. Most security failures don't happen because one thing went wrong. They happen when a feature quietly supplies means, opportunity, and motive, all at once.
The Psychological Architecture: Why We Miss Abuse Cases
Functional Fixedness (Cognitive Bias)
Psychologists call it functional fixedness: our tendency to see objects (or features) only in terms of their intended use. A password reset is "for helping users." An email change is "for convenience."
This cognitive tunnel vision is why adversarial thinking must be scripted, not assumed.
Intention-Behavior Gap (Implementation Science)
Even when teams intend to think adversarially, they don't unless prompted by structure. Gollwitzer's implementation intentions work here too:
"If [we design feature X], then we will [document abuse case Y using MOM]."
This precommitment bypasses the optimism bias that dominates feature design.
The Mental Flip
From today forward, I propose a small but powerful shift:
Every feature still gets use cases. But every feature also gets abuse cases, examined through Means, Opportunity, and Motive. This isn't about adding fear. It's about adding clarity. The format remains deliberately simple:
As an attacker, I want to [malicious action] so that I can [harmful goal].
This single sentence forces three questions:
- What does this feature allow me to do? (Means)
- When can I do it? (Opportunity)
- Why would I want to? (Motive)
That's where risk stops being abstract.
Example 1: Password Reset
Use Case
As a legitimate user, I want to reset my forgotten password so that I can regain access to my account.
Necessary. Expected. Essential.
Abuse Case
As an attacker, I want to trigger password resets repeatedly so that I can identify valid accounts, lock users out, or manipulate them into trusting fake recovery messages.
MOM Analysis:
- Means: The reset mechanism itself--public, automated, accessible
- Opportunity: No rate limiting, predictable patterns, timing windows
- Motive: Account enumeration, denial of service, phishing infrastructure
Same feature. Same button. Completely different outcome. Password reset isn't just convenience. It's trust infrastructure.
Example 2: Email Address Change
Use Case
As a user, I want to change my registered email address so that I can continue receiving notifications and recovery messages.
People change jobs. Domains expire. Life moves on.
Abuse Case
As an attacker, I want to change the email address on a victim's account so that all future alerts and recovery flows are redirected to me.
MOM Analysis:
- Means: Control over where trust messages go
- Opportunity: Treated as low-risk profile update, weak verification
- Motive: Quiet, durable account takeover
I've investigated cases where victims noticed weeks later when no recovery emails arrived. Email change isn't profile hygiene. It's identity transfer.
Example 3: Multi-Factor Authentication (MFA) Enrollment
Note: Multi-Factor Authentication (MFA) also called Two-Factor Authentication (2FA) requires users to provide two or more verification factors (password + SMS code, password + authenticator app, or password + hardware token) to gain access. MFA dramatically reduces account takeover risk.
Use Case
As a user, I want to enroll Multi-Factor Authentication so that my account becomes more secure. A best practice.
Abuse Case
As an attacker, after compromising credentials through phishing or session hijacking, I want to enroll my own MFA device so that I permanently lock the real user out even after they change their password.
MOM Analysis:
- Means: Ability to bind a new authentication factor
- Opportunity: Once initial access is gained (credential theft, session hijacking)
- Motive: Persistence, control, permanent exclusion of legitimate owner
This surprises many teams. MFA is protection. But it is also ownership. Security controls themselves can become attack tools when enrollment isn't treated as a high-risk action.
Example 4: Approval Flows
Use Case
As a manager, I want to approve requests efficiently so that business operations don't slow down. Approvals exist to enable work.
Abuse Case
As an attacker, I want to make requests look routine and urgent so that approvals happen automatically without scrutiny.
MOM Analysis:
- Means: Delegated authority embedded in workflows
- Opportunity: High volume, time pressure, familiarity breeds automation
- Motive: Fraud, privilege escalation, financial gain
Attackers don't break systems. They blend into them. Approval systems fail not because people are careless, but because they are optimized for speed and trust exactly what attackers exploit.
This connects to Social Engineering Theory and Cialdini's (1984) Principles of Influence (authority, scarcity/urgency, social proof). Digital systems often encode these persuasion triggers directly into UI/UX, making them exploitable at scale.
Why This Changes Security Conversations
When teams document only use cases, they design for intention. When they add abuse cases using MOM, they design for reality. Features stop being seen as "good" or "bad."
They are seen as capabilities--capabilities that can help or harm depending on how Means, Opportunity, and Motive align.
Most incidents I've investigated didn't start with sophisticated hacking. They started with ordinary features that worked exactly as designed.
How to Make It Routine
Don't treat abuse cases as "extra." Bake them into the way you plan work.
Add required fields in your issue tracker (Jira, Backlog, Linear, Asana whatever you use):
- User Story: what the legitimate user wants
- Acceptance Criteria: how we know it works
- Abuse Cases: how an attacker misuses it ← new
- Security Controls: how we prevent that misuse ← new
Rule: Stories without abuse cases don't get approved.
At first, this will feel like overhead. Teams may push back: "This slows down our velocity."
Here's what actually happens:
Weeks 1-2: Stories take 10-15 minutes longer. Engineers grumble.
Weeks 3-4: Patterns emerge. Teams create templates. Time drops to 5 minutes.
Month 2+: First security issue caught in design--before any code is written. A vulnerability that would have taken 3 weeks to fix post-deployment is prevented. ROI (Return of Investment) becomes visible.
Month 4+: It's muscle memory. New engineers learn abuse case thinking from day one. Security debt stops accumulating.
The shift isn't from "slow" to "fast." It's from "reactive firefighting" to "proactive clarity." At first, it feels like a slowdown. Then it becomes a filter. Then it becomes muscle memory.
This is how adversarial thinking shifts from "security activity" to "just the way we build things here."
Why This Works: The Theoretical Foundation
- Routine Activity Theory (Cohen & Felson, 1979)
By analyzing Means, Opportunity, and Motive, you're operationalizing criminological theory in digital design. You're asking: "Does this feature create a convergence in time and space where harm becomes likely?"
- Situational Crime Prevention (Clarke, 1980s)
Abuse cases enable situational crime prevention--modifying environments to increase the effort, increase the risk, reduce the rewards, reduce provocations, and remove excuses for offenders. Each abuse case → control mapping does exactly this.
- Implementation Intentions (Gollwitzer, 1999)
By mandating "if feature → then abuse case," you're creating an if-then plan that automates adversarial thinking. It removes the cognitive burden of remembering to think like an attacker.
- Cognitive Forcing Functions (Medical Safety Science)
Requiring abuse cases acts as a forcing function--a design element that prevents errors by making dangerous actions impossible to complete without deliberate reflection.
The Cultural Shift
When this becomes routine, something magical happens:
- Developers start writing abuse cases before you ask.
- They come to meetings pre-armed with attacker questions.
- Security isn't a gate.
It's a shared lens.
That's the goal.
What We've Built So Far
- Day 66: Developing an adversarial mindset learning to think like an attacker
- Day 67: Writing abuse cases with MOM documenting attacker logic through Means, Opportunity, and Motive
Together, these form a single, practical habit:
Every time I design a feature, I deliberately ask how it could be misused--and I document that thinking using Means, Opportunity, and Motive.
This is not an extra security exercise. It is a way of thinking that fits naturally into design and decision-making.
Tomorrow, we move to the third method: STRIDE without fear, without tables.
References will be added at the end of the series.
参考文献・出典は、このシリーズの最後に一覧としてまとめます。