セキュリティリスク管理：脅威モデリングからリスク受容まで

全体の流れ

資産の特定 → 脅威の洗い出し（STRIDE） → リスクの数値化（CVSS） → リスク受容基準で判断 → 対応策の決定

Step 1: 資産の特定

「何を守るか」を明確にする。ここが曖昧だと脅威モデリングの対象が絞れない。

資産の分類例

種類	例
データ	個人情報、決済情報、認証情報、ビジネスロジック
システム	サーバー、DB、APIエンドポイント、管理画面
外部依存	OSSライブラリ、SaaS、クラウドサービス

優先度をつける基準

機密性: 漏れたらどれくらいまずいか
可用性: 止まったらビジネスへの影響はどれくらいか
規制対象か: 個人情報保護法・PCI DSS など法的義務があるか

実務の落とし穴: Step 1を省いていきなりSTRIDEから始めるケースが多い。守るべきものが曖昧なまま進むと、重要でないコンポーネントに時間をかけすぎる原因になる。

Step 2: STRIDE で脅威を列挙する

データフロー図（DFD）を書きながら各コンポーネントにSTRIDEを当てる。

[ブラウザ] → [API Gateway] → [認証サービス] → [DBサービス]

対象	脅威カテゴリ	具体的な脅威
APIログイン endpoint	Spoofing	他人のアカウントでログインされる（credential stuffing）
DBサービス	Tampering	SQLインジェクションでデータ改ざん
認証トークン	Information Disclosure	JWTが平文でlocalStorageに保存されている
API全体	DoS	レート制限なしで大量リクエストを受ける

Step 3: CVSS でリスクをスコアリングする

リスク = 発生確率 × 影響度

CVSSは「攻撃のしやすさ」×「影響の大きさ」でスコアを出す。

例: SQLインジェクション（スコア: 9.8 / Critical）

要素	値	理由
Attack Vector	Network	インターネット越しに攻撃可能
Attack Complexity	Low	ツールで自動化できる
Privileges Required	None	認証不要
Confidentiality Impact	High	全DBが読める
Integrity Impact	High	データ改ざん可能

例: JWT の localStorage 保存（スコア: 6.5 / Medium）

要素	値
Attack Vector	Network
Attack Complexity	High（XSSが前提）
Confidentiality Impact	High

Step 3b: 発生確率の判断方法

セキュリティの発生確率は正確な数値は出せない。攻撃者の行動は予測困難なため、実務では定性的なレベル分けで代替する。

方法1: CVSSの攻撃可能性要素を使う（一番簡単）

CVSSの中にすでに確率要素が含まれている。

CVSS要素	確率への影響
Attack Vector: Network	高（誰でも攻撃できる）
Attack Complexity: High	低（条件が難しい）
Privileges Required: None	高（認証不要）
Exploitability: POC存在	高（攻撃コードが公開済み）

→ CVSSスコアが高い = 発生確率も高い、と近似するのが現実的。

方法2: 脅威インテリジェンスを参照する

OWASP Top 10 — 実際に多く起きている攻撃のランキング
CVE/NVD — 同じライブラリの脆弱性が実際に悪用されているか
自社の過去インシデント — 一番信頼できるデータ

方法3: 環境条件で補正する

同じ脆弱性でも... 公開API + 認証なし → 確率: 高社内システム + VPN必須 → 確率: 低

確率の3段階定義（合意しておく）

レベル	定義
高	OWASP Top 10 に該当 or 攻撃ツールが公開済み
中	技術的に可能だが攻撃に専門知識が必要
低	攻撃経路が限定的（社内のみ、物理アクセス必要など）

Step 4: リスク受容基準を決める（どこまで許容するか）

「脅威が大きければ対策する、小さければ許容する」という判断を明示的に文書化して合意するのがポイント。

CVSSスコアによる対応ルールの例

CVSSスコア	リスクレベル	対応ルール
9.0〜10.0	Critical	即時対応（72時間以内）
7.0〜8.9	High	次スプリント内に対処
4.0〜6.9	Medium	四半期内にバックログ対応
0〜3.9	Low	Accept（記録して許容）

「許容」ではなく「決定」にする理由

何もしないのと「Accept と明示的に決める」のは別物。

誰が判断したか記録が残る
後でリスクが顕在化したとき「知らなかった」にならない
ISO 27001 はこの記録（リスク受容の証跡）を監査で求めてくる

Step 5: 対応策を決める（4択）

対応	内容
Mitigate（軽減）	対策を打つ
Accept（受容）	コストと照らし合わせて許容する
Transfer（転嫁）	保険・外部委託（例: CloudflareのDDoS保護）
Avoid（回避）	その機能自体をやめる

判断サンプル:

脅威	スコア	対応	理由
公開APIへのSQLi	9.8	Mitigate	ORMに切り替え＋入力検証
JWT localStorage	6.5	Mitigate	httpOnly Cookie に変更
レート制限なし	5.3	Transfer	Cloudflare の DDoS 保護を使う
社内ツールの軽微な脆弱性（CVSS 2.1）	2.1	Accept	攻撃経路が限定的、記録して許容

規格・フレームワークとの対応

ステップ	対応する規格
脅威の洗い出し	STRIDE
リスクの数値化	CVSS
受容基準の文書化・合意	ISO/IEC 27001
全体の枠組み	NIST CSF（Identify→Protect→Detect→Respond→Recover）

まとめ

STRIDE → 「何が脅威か」を漏れなく洗い出す道具 CVSS → 「どれくらい危ないか」を客観的に数値化する道具 ISO 27001/NIST → 「どこまで許容するか」をルール化・文書化する枠組み発生確率 → 正確な数値は出せない。CVSSとOWASP Top 10を根拠に3段階で分類する