Chapter 02
脅威モデリングと攻撃者の分類
この章がなぜ必要なのか——「全部守る」は不可能であり、無駄でもある.
セキュリティ機能はコストである。RAM を食い、CPU を食い、電池を食い、 開発工数を食い、そして BOM コストを上げる。
だから「誰から、何を、いくらまで守るか」を先に決めなければならない。 それを体系的にやる作業が脅威モデリングである。
これをやらずに機能を並べると、必ず「守るべきものが守られていない」状態になる。
1. 脅威モデリングの 4 つの質問
Adam Shostack の定式化が最も使いやすい。この 4 つに順に答える。
| # | 質問 | 成果物 |
|---|---|---|
| 1 | 何を作っているのか | システム構成図、データフロー図、信頼境界 |
| 2 | 何がうまくいかないか | 脅威の一覧（STRIDE などで洗い出す） |
| 3 | それにどう対処するか | 対策の一覧（緩和・移転・受容・回避） |
| 4 | ちゃんとやれたか | 検証（テスト・レビュー・第三者評価） |
重要なのは、1 を飛ばさないこと。 「何を作っているか」を図にせずに脅威を挙げると、必ず漏れる。
2. 信頼境界を引く
脅威は信頼境界（trust boundary）をまたぐところで発生する。
| 境界 | またぐもの | 主な脅威 | 章 |
|---|---|---|---|
| A: クラウド ⇄ 機器 | ネットワーク | 中間者攻撃、なりすまし、リプレイ | 16 |
| B: スマホ ⇄ 機器 | BLE / Wi-Fi | ペアリング攻撃、盗聴、コマンド注入 | 16 |
| C: MCU ⇄ 外付けフラッシュ | 基板上の配線 | バス盗聴、フラッシュ差し替え、内容の読み出し | 06, 11 |
| D: Secure ⇄ Non-secure | SoC 内部 | 権限昇格、メモリ越境 | 07 |
| E: デバッグポート | 物理接点 | ファームウェア抽出、実行制御 | 11 |
| F: 筐体（物理） | 分解 | チップ剥がし、プロービング、故障注入 | 09, 10 |
境界を数えると、対策の抜けが見える.
「TLS を入れたから安全」と言う人は、境界 A しか見ていない。 境界 C（外付けフラッシュ）が無防備なら、TLS の秘密鍵は SPI バスを覗くだけで取れる。
実際、多くの IoT 機器で最も脆弱なのは境界 C と E である。
3. STRIDE — 脅威の分類
Microsoft が広めた分類。信頼境界ごとに、この 6 つを機械的に当てはめる。
STRIDE で脅威を洗い出す
境界とコンポーネントを選ぶと、当てはまる脅威と対策が表示される。
| 頭字 | 脅威 | 破られる性質 | IoT での例 |
|---|---|---|---|
| S — Spoofing | なりすまし | 認証 (Authentication) | 偽のデバイスがクラウドに接続する／偽のサーバに機器が接続する |
| T — Tampering | 改ざん | 完全性 (Integrity) | ファームウェアの書き換え、設定値の改変、センサ値の偽装 |
| R — Repudiation | 否認 | 否認防止 (Non-repudiation) | 「その操作はしていない」と主張される。ログの改ざん |
| I — Information Disclosure | 情報漏洩 | 機密性 (Confidentiality) | 秘密鍵の抽出、ユーザデータの読み出し、通信の盗聴 |
| D — Denial of Service | サービス妨害 | 可用性 (Availability) | 電池切れ攻撃、フラッシュ書き潰し、通信妨害 |
| E — Elevation of Privilege | 権限昇格 | 認可 (Authorization) | Non-secure から Secure への越境、一般ユーザから管理者へ |
IoT で特に重要な 3 つ
上の 6 つは等価ではない。IoT では S・T・I が支配的である。
| 脅威 | なぜ重要か | 主な対策 |
|---|---|---|
| Spoofing | 機器の ID がなりすまされると、クラウド側の全データが汚染される | 機器固有の秘密鍵と証明書（12 章） |
| Tampering | ファームウェアを書き換えられたら、他の全対策が無意味 | セキュアブート（05 章） |
| Information Disclosure | 秘密鍵が漏れたら、S も T も一気に成立する | 鍵の保管（06 章） |
この 3 つが繋がっていることに注目してほしい.
秘密鍵が漏れる（I）→ なりすませる（S）→ 偽のファームウェアを送り込める（T）
逆に言えば、「鍵をハードウェアから出さない」という 1 つの対策が、 3 つの脅威に同時に効く。だから 06 章が全体の要になる。
D（DoS）の特殊性
IoT では DoS が独特の形をとる。
| 形 | 内容 |
|---|---|
| 電池枯渇攻撃 | 無意味な通信を送り続けて、電池駆動機器の寿命を数年から数日に縮める |
| フラッシュ書き潰し | 書き換え回数の上限（10 万回程度）を狙って書き込みを誘発する |
| ブートループ誘発 | 起動できない状態にして物理的に回収させる |
| 証明書期限切れ | 攻撃ではないが、時刻同期が壊れると全機器が同時に通信不能になる |
最後の 1 つは事故として実際に起きている。 攻撃だけでなく、 設計ミスによる可用性の喪失も脅威モデルに含めるべきである。
4. 攻撃者を分類する
「攻撃者」を一括りにすると設計できない。能力と動機で分ける。
攻撃者のクラスと予算
攻撃者クラスを選ぶと、その相手にどこまで対策が要るかが表示される。
| クラス | 動機 | 能力 | 予算 | 典型的な攻撃 |
|---|---|---|---|---|
| 1. 好奇心 | 遊び、学習 | ネット上の情報とツール | ~1 万円 | デフォルトパスワード、既知 CVE、UART |
| 2. 愛好家／改造者 | 機能解放、自作 | 電子工作、逆アセンブル | ~10 万円 | SWD 吸い出し、フラッシュ読み出し、簡単なグリッチ |
| 3. 犯罪者（金銭目的） | 金 | 手法を買う・雇う。規模を求める | ~100 万円 | 大量デバイスの乗っ取り、認証情報の窃取、ランサム |
| 4. 競合他社 | 模倣、IP 窃取 | 専門ラボに委託できる | ~1000 万円 | ファームウェア解析、鍵抽出、リバースエンジニアリング |
| 5. 国家・大規模組織 | 諜報、破壊工作 | ほぼ無制限。ゼロデイを持つ | 無制限 | サプライチェーン攻撃、FIB、専用の解析設備 |
クラス 3 の性質を理解することが最も重要である.
犯罪者は規模を求める。1 台を苦労して破っても金にならない。 「1 台破ると全台破れる」構造があるときに、初めて経済的に成立する。
だから最も効果的な対策は——
「機器ごとに違う鍵を使う」（12 章）
これだけで、クラス 3 の攻撃の経済性が崩壊する。 高価なハードウェアより先に、この設計をすること。
どこまで守るか — 現実的な線引き
| 製品カテゴリ | 想定すべき最大クラス | 根拠 |
|---|---|---|
| 一般消費者向け IoT（照明、家電） | クラス 2 | 1 台破っても得るものが少ない |
| スマートロック、防犯カメラ | クラス 3 | 侵入・プライバシーで金になる |
| 決済端末、電力メータ | クラス 4 | 直接的な金銭価値がある |
| 自動車、医療機器 | クラス 4〜5 | 人命に関わる。規制も厳しい |
| 重要インフラ、防衛 | クラス 5 | 国家レベルの攻撃を想定 |
5. DREAD と、リスクの優先順位づけ
脅威を洗い出したら、対処の順番を決める必要がある。 すべてに対処する予算はないからである。
素朴には、リスクを次のように定義する。
より細かく評価するなら DREAD がある。
| 項目 | 意味 |
|---|---|
| Damage | 成功したときの被害の大きさ |
| Reproducibility | 再現の容易さ |
| Exploitability | 攻撃の実行しやすさ |
| Affected users | 影響を受けるユーザ数 |
| Discoverability | 脆弱性の発見しやすさ |
DREAD の点数化は主観的で、数値を信じすぎてはいけない.
実務では、「高／中／低」の 3 段階で十分なことが多い。 大事なのは精密な点数ではなく、 「これは対処する」「これは受容する」を明示的に決めて記録することである。
記録が重要なのは、規制対応（03 章）で「リスク評価を実施した証拠」を求められるからである。 EU CRA は「サイバーセキュリティリスクアセスメント」の実施と文書化を要求している。
4 つの対処方法
| 対処 | 内容 | 例 |
|---|---|---|
| 緩和 (Mitigate) | 技術的対策で発生確率か影響を下げる | セキュアブートを入れる |
| 移転 (Transfer) | 他者に責任を移す | 保険、セキュアエレメントのベンダ保証 |
| 受容 (Accept) | リスクを認識したうえで対処しない | 「クラス 5 の攻撃には対応しない」 |
| 回避 (Avoid) | 機能自体をなくす | 「リモートからのファームウェア書き込み機能を持たない」 |
「回避」が最も強力で、最も見落とされる.
使わない機能は攻撃面にならない。
- デバッグ用の UART コマンドを、量産ファームウェアからはコンパイル時に除去する
- 使わないネットワークサービス（Telnet、FTP、SNMP）を入れない
- 使わない外部インタフェース（USB、SD カード）を基板から落とす
機能を減らすことは、最も安価で最も確実なセキュリティ対策である。
6. 攻撃ツリー
STRIDE が「網羅的に洗い出す」ための道具なのに対し、 攻撃ツリーは「特定の目標に対する経路を掘り下げる」ための道具である。
攻撃ツリーの価値は「最も弱い枝」が見えることである.
どんなに (d) のサイドチャネル対策を固めても、 (c) でフラッシュを外して読めるなら、そちらから取られる。
攻撃者は最も安い経路を選ぶ。 一番弱い枝の強度が、システム全体の強度である。 だから「全体をバランスよく」が原則になる。
7. 実務での進め方
| 段階 | やること | 成果物 |
|---|---|---|
| 企画時 | 保護資産と攻撃者クラスを決める | セキュリティ目標（1 ページ） |
| アーキ設計時 | 信頼境界を引き、STRIDE を回す | 脅威一覧と対策一覧 |
| SoC 選定時 | 必要な HW 機能を洗い出す | 必須機能リスト（23 章） |
| 詳細設計時 | 攻撃ツリーで弱い枝を潰す | 設計判断の記録 |
| 実装時 | チェックリストでレビュー | レビュー記録（23 章） |
| 検証時 | ペネトレーションテスト、第三者評価 | 試験報告書 |
| 運用時 | 脆弱性情報の追跡と更新 | 脆弱性対応記録（15 章） |
全部を最初に完璧にやろうとしないこと.
現実的には、企画時に 1 ページのセキュリティ目標を書くだけでも大きな前進である。
脅威モデリングの成果物はこの 5 行。これが後の設計判断すべての根拠になる これが決まっていれば、以降の全判断に基準ができる。
8. この章のまとめ
| ポイント | 内容 |
|---|---|
| 4 つの質問 | 何を作る／何がうまくいかない／どう対処する／ちゃんとやれたか |
| 信頼境界 | 脅威は境界をまたぐところで発生する。境界を数えると抜けが見える |
| STRIDE | 6 分類。IoT では S・T・I が支配的で、しかも連鎖する |
| 攻撃者クラス | 1（好奇心）〜5（国家）。製品カテゴリごとに線を引く |
| クラス 3 対策の核心 | 機器ごとに違う鍵。これで大量攻撃の経済性が崩れる |
| リスク対処 | 緩和・移転・受容・回避。「回避」が最も安価で確実 |
| 攻撃ツリー | 最も弱い枝の強度が、システム全体の強度 |
| 記録の意味 | 規制対応でリスク評価の文書化が要求される |
次章では、その規制——世界各地で施行されつつある IoT セキュリティ法規と、 認証制度の地図を描く。