2025.03.18 脅威モデリングナイト #7 組織に持ち込む 脅威モデリング 

自己紹介 2 名前：ニキヌス（X:@nikinusu） 所属：金融JTCのシステム子会社 嫌いなもの：しいたけ 

目次 1. なぜ・どうやって脅威モデリングを組織に持ち込むのか 2. 社内向けワークショップやってみた 3. 結果・気づき 3 

Section1. なぜ・どうやって 脅威モデリングを組織に持ち込むのか 4 

なぜ脅威モデリングに興味があるのか 5 チェックリスト評価型統制ツラ杉 総項目数 約1000項目 総レビュー数 約180案件・260チェックリスト/年 総レビュー工数 約20人月/年 （当然、回答者も辛い） 

なぜ脅威モデリングに興味があるのか 6 脆弱性大杉 レベル別検出数 Level 件数 HIGH 4 MEDIUM 19 LOW 51 合計 74 種類別検出数 項番 指摘項目 CL記載 DAST 件数 1 詳細なエラーメッセージの表示 〇 〇 2 ログアウト機能の不備 〇 〇 3 クロスサイトスクリプティング 〇 〇 4 内部IPアドレスの表示 ー △ 5 HTTPSのCookieにSecure属性の指定なし 〇 〇 6 URLに重要な情報を格納 〇 〇 7 パラメータ改ざんによるシステムの不正利用 〇 ー 8 Cookieに重要な情報を格納 ー ー 9 エラー表示による利用者の存在確認が可能 〇 〇 10 ログアウト機能の未実装 〇 ー 11 強制ブラウジング ー ー 12 CookieにHttpOnly属性の指定なし 〇 〇 13 HTMLタグの実行が可能 〇 〇 14 SQLインジェクション 〇 〇 15 管理者用ページの閲覧が可能 ー 〇 16 権限変更昇格が可能 〇 〇 17 システム障害 〇 〇 18 内部パスの表示 〇 〇 19 メールの送信先を変更可能 〇 ー 合計 74 非 開 示 

なぜ脅威モデリングに興味があるのか 7 効果的なSSDLCを学びたい → どこにでも脅威モデリングが書かれている… ⚫ SAFECode:Fundamental Practices for Secure Software Development, Third Edition https://safecode.org/uncategorized/fundamental-practices-secure-software-development/ ⚫ OWASP SAMM Version2 https://drive.google.com/file/d/1cI3Qzfrly_X89z7StLWI 5p_Jfqs0-OZv/view 

なぜ脅威モデリングに興味があるのか 8 効果的なSSDLCを学びたい → どこにでも脅威モデリングが書かれている… ⚫ ESF:SECUREING THE SOFTWARE SUPPLY CHAIN RECOMMENDED PRACTICES GUIDE FOR DEVELOPERS https://www.cisa.gov/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS. PDF ⚫ NIST SP 800-218 Secure Software Development Framework (SSDF) Version 1.1 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf 

なぜ脅威モデリングに興味があるのか 9 独学→脅威モデリングナイト参加→TMC Tokyo × ZANSINで体験 目的、位置づけ、効果をおおむね理解（したつもり） 2024.12.18 結局、脅威モデリングとは何なのか（TMC Tokyo × ZANSIN感想） https://nikinusu.hatenablog.com/entry/2024/12/08/165032 

私が目指すゴール 10 開発部門が最小限の労力でセキュリティを実現できる組織、プロセス 

取り組み方 11 1. 「人にやらせるセキュリティ」を減らすためにプロセスやツールの最適化 2. やらせる部分は、やれる仕組みを作る 3. あわせて意識付け 方向性 CI/CDパイプラインへ のSAST組み込み ポスチャマネジメントに よる設定チェック セキュア開発の 伴走型支援モデル 脅威モデリング ワークショップ セキュリティ要件 虎の巻 •開発者自身がリスク 分析を考えられる •開発者自身が脅威と 対策を考えられる •脆弱性の早期発見 •脆弱性の是正 （具体的な箇所の 明示） •脆弱性の早期発見 •脆弱性の是正 （具体的な箇所の 明示） •危険な設計の早期 発見 •開発スピードとセキュリ ティの両立 そのための多層的な取り組みの一つとしての脅威モデリング 

組織に持ち込むための戦術 12 想定ハードル 1. 新たなタスクが増えることに対する現場からの反発 2. 直感的な効果の見えづらさによる仲間の集めにくさ 脅威モデリングを体験してみて思った「これはいいものだ…」 裏を返すと「やってみないと良さが伝わりにくい」スルメ感 

いきなりルール化するよりも、ジワジワ浸透 それっぽく言えば、チェンジマネジメントのフレームワーク「ADKARモデル」 変革の必要性の認知 なぜ？何が問題なのか？ 変革に関わりたいという欲求 何がメリットか？ 変革の方法に関する知識 何をどうすれば良いか？ 知識を活かした実践 小さくやってみる 変革の維持と定着 広げて根付かせる A wareness D esire K nowlodge A bility R einforcement 13 組織に持ち込むための戦術 

A wareness 脆弱性や手戻りの多さの周知 D esire チェックリスト評価型統制、リリース前の脆弱性対応への疲弊 K nowlodge ワークショップで脅威モデリングという手法を知ってもらう A bility 実際の案件でいくつか試行する／出来る人を増やす（未来） R einforcement 広がったところで正式にプロセスへ組み込み（未来） 今日の話 14 いきなりルール化するよりも、ジワジワ浸透 それっぽく言えば、チェンジマネジメントのフレームワーク「ADKARモデル」 組織に持ち込むための戦術 

Section2. 社内向けワークショップやってみた 15 

概要 ⚫ 各開発部、インフラ部からの代表約30名向けに開催 ⚫ 約2時間での開催のため、脅威と緩和策の洗い出しのみの短縮版 16 章立て 所要時間 内容 1. 概要説明 10min • ワークショップの目的 • 脅威モデリングの概要 • 分析対象システムの概要 2. 脅威の洗い出しワークショップ 40min • STRIDEモデルの紹介など • ワークショップ • いじりタイム 10min 25min 5min 3. リスク緩和策の洗い出しワークショップ 35min • 緩和策の概要説明など • ワークショップ • いじりタイム • リスク分析の説明（DREADモデル） 10min 15min 5min 5min 4. 振り返り 15min • もやもやポイントの解説 • 脅威モデリングのポイントの振り返り 合計 100min 

分析対象システム あえて超シンプルな架空のものを用意 （１）システムの概要 お客様向けの個人情報管理Webアプリ （２）機能概要 • 認証機能 • 個人情報の登録 • 個人情報の参照 • 個人情報登録時のメール発信 （３）システム利用者 一般のお客様 （４）システム構成 クラウド基盤（IaaS）上で稼働 認証サーバ、WEB/APサーバ、DBサーバ、メール サーバで構成 （５）アクセス経路 お客様：インターネットごしにHTTPS システム管理者：社内ネットワークから踏み台サー バごしにSSH 17 

システム構成とDFDどちらも提供。どっちに付箋を貼ってもよいルール 分析対象システム 18 

分析対象システム 19 システム構成とDFDどちらも提供。どっちに付箋を貼ってもよいルール ※一部抜粋 

ワークショップの様子 20 

ワークショップ前の講義 21 Spoofing なりすまし フィッシング攻撃 弱いパスワードの悪用 Tampering 改ざん SQLインジェクション ウェブサイト改ざん Repudiation 否認 ログの消去や改ざん Information disclosure 情報漏洩 画面ののぞき見 マルウェア感染 DoS サービス妨害 大量のNWトラフィックや HTTPリクエスト送信 Elevation of privileges 権限昇格 脆弱性の悪用 緩いセッション管理の悪用 攻撃例 脅威モデリングの流れ、STRIDEモデル、DREADなど基礎知識の解説（以下は一部抜粋） 

ワークショップ前の講義 22 × 〇 脅威モデリングさえやればセキュリティ対策は万全 開発前の心と頭の準備体操 コミュニケーションすること、意識することが中心 セキュリティ担当が主導するもの 開発者が主導するもの セキュリティ有識者がいないと意味がない セキュリティ有識者がいた方がよいが、 本来は誰でも出来るもの 脅威を網羅的に洗い出す必要がある 網羅的でなくとも良い 各自の立場から主要なものを思い浮かべるだけでも 価値がある 複雑なシステムは膨大な時間とコストをかけて取り 組む 10分で書ける程度の抽象的な図で、あるいは範囲 を絞って取り組む ひとりで黙々と取り組む 関係者でコミュニケーションする 脅威モデリングの向き合い方を繰り返し強調 

生成AIの活用 23 脅威の洗い出しが難航することを想定し、ワークショップの途中でプロンプトを提供 （洗い出しは進むがコミュニケーションが止まる面も） 現在脅威モデリングのワークショップをしています。 あなたはサイバー攻撃の手法に詳しいセキュリティ担当として参加しており、他の参加メンバとともに脅威の洗い出しをしています。 以下の１～５の前提条件を踏まえて、６～８に指定される条件で想定される脅威を10個あげて下さい。 １．対象システムの概要 お客様の個人情報を管理するWebアプリケーションです。 ２．システムの機能 システムは以下の機能を持ちます a.アカウント管理機能 - アカウント作成 - パスワード変更 b.個人情報管理機能 - 個人情報の登録 - 個人情報の参照 - 個人情報登録時のユーザへのメール通知 c.認証機能 -ログイン ３．システムのユーザ 利用者は一般のお客様のみです。別途、サービス提供会社の運用部門が当該システムへのインフラ保守のためにアクセスします。 ４．システムの構成 システムは認証サーバ、Web・APサーバ、DBサーバ、メールサーバ、踏み台サーバで構成されます。 当該サーバはクラウド事業者が提供するIaaS上にLinuxディスリビューションで構築されております。 ５．システムへのアクセス経路 以下のアクセス経路があります。 ・お客様は、インターネットごしにHTTPS通信でWebアプリケーションにアクセスします。 ・システム運用者は、オフィスからRDPで踏み台サーバにログインし、踏み台サーバからSSHで各サーバにアクセスします ・IaaSの管理コンソールについては、システム運用者のオフィス端末からHTTPS通信でアクセスします。 ６．脅威モデリングの対象 認証処理に関連する脅威を洗い出して下さい。 ７．脅威モデリングの観点 STRIDEモデルのSpoofingに関わる脅威を洗い出して下さい。 ８．アウトプットの形式 想定される脅威ごとに以下の形式で出力して下さい。 ①ユーザ ②アクセス経路 ③想定される脅威 

チェックリストと脅威モデリング 24 ベースラインであるチェックリスト要件を守ってきた人達は、脅威モデリングの位置づけに戸惑う だから関係性を丁寧めに解説 

チェックリストと脅威モデリング 25 ベースラインであるチェックリスト要件を守ってきた人達は、脅威モデリングの位置づけに戸惑う だから関係性を丁寧めに解説 

Section3. 結果・気づき 26 

結果・気づき（アンケートより） 27 ネガティブフィードバック大歓迎！！と誘導した割に、総じて好感触（ﾐﾝﾅｵﾄﾅ） セキュリティチェックリストだと誰か一人が黙々とやる事が 多いが、脅威モデリングによって他のメンバーと協働がで き、チーム全体の理解が高められると思いました。 アジャイル的にも良い取り組みかと思います。 特に一番最後の講義については全社員に見せてもいい と思えるくらい大切な内容でした。 わかりやすかった。他メンバーでもぜひ考え方を拡げたい SDEのメンバーだけでなく、実務で使う可能性のある方 は、積極的に参加された方がいい 当部は新しいサービスを新規で活用・構築することが多 く、ベンダーも含めて早期に実施することが良いと感じた 

結果・気づき（アンケートより） 28 ちょうど 良い 62% 難しかっ た 38% ワークショップの難易度 難易度は、参加者の38%が「難しかった」 知識がない中で脅威の洗い出しに苦労したのが主な理由（これは想定内） 1. 脅威洗い出しの後に具体化の時間を設けた方がよい 2. 脅威をイメージしやすいように事前に攻撃手法の例をレクチャーしておくと良さそう。 STRIDEモデルはやはり大括りなので、MITRE ATT&CKから具体例を挙げるなど ⚫ 今回の様にシンプルなシステムで まずは一度やってみるのが有効。 ⚫ ①概要理解、②時間をかけてより 具体的に、など2段階でも良い。 ⚫ なかなか脅威や対応策が浮かんでこ ないので事前学習できれば。 ⚫ 脅威の洗い出しの後に、具体化をす る時間が欲しかった。 

結果・気づき（アンケートより） 29 とか思ってたら#6.5で同じ話が登場。グローバルの実践者もMITRE ATT&CKを脅威モデリング に活用されている様子（あと、STRIDEｰLMが良いというのも気づき） Donavan Cheah氏 Special Talk on Threat Modellingより引用 

結果・気づき（アンケートより） 30 とか思ってたら#6.5で同じ話が登場。グローバルの実践者もMITRE ATT&CKを脅威モデリング に活用されている様子（あと、STRIDEｰLMが良いというのも気づき） Donavan Cheah氏 Special Talk on Threat Modellingより引用 

No 14% Yes 86% 脅威モデリングを実務に活用できそう か？ 結果・気づき（アンケートより） 31 ⚫ 既存のシステム構成図と改修部分の データフロー図を使ってどこに脅威がある か検討するきっかけにできそう ⚫ マイナンバーを扱う開発案件で脅威モ デリングを活用したい ⚫ クラウド移行時に構成の変更点に特化 して脅威モデリングできそう ⚫ 共通的な基盤がやってくれる対策/やっ てくれない対策の理解に役立ちそう ⚫ 担当的にシステムの開発案件がない ので活かしにくい ⚫ 新規開発、大規模な機能追加を開 発する場面でしか活用する機会が無 いのでは 実務への活用は、参加者の86%が「手ごたえアリ」 思いもよらぬ活用方法を考える声も、担当業務によってはイメージがつきづらそうな声も 

32 結果・気づき（その他） （１）データフロー図、やっぱり大事 • 脅威洗い出しの際、多くの参加者が構成図から取り掛かりがち • でも、DFDから取り組んだチームの方が具体的かつ数多くの脅威を洗い出せた • 洗い出せた脅威の具体度は、その後の緩和策の洗い出しや実装箇所の腹落ち感にも直結 → システム構成は説明に留め、データフロー図に絞ってやってみてもよいかも 

• 複数の参加者から「当社全体で出来ている対策を知りたい」の声 • それが無いと、自分のシステムでどこから脅威と対策を考えれば良いのか？の悩みに繋がる 33 結果・気づき（その他） ➢ エンプラレベルの脅威・対策の知識 ➢ 脅威の知識（MITRE ATT&CK、OWASP Top10など） ➢ 評価対象システムの知識 セキュリティ担当から開発者に事前に伝えておきたい 開発者が詳しい （２）実務で行う場合のインプット 

⚫ 次はADKARモデルにおけるAbility（実際の案件でいくつか試行する／出来る人を増やす） 4月以降に実案件での試行を予定 ⚫ インセンティブ設計も恐らく必要 できればチェックリスト評価を一部割愛など、分かりやすいメリットと連動させたい ⚫ 試行と並行して体制づくりも必要 × 外部ベンダにやってもらう脅威モデリング 〇 リソース不足を外部ベンダで補いながら一緒に脅威モデリング 次のステップ 34 

⚫ 開発部門が最小限の労力でセキュリティを実現できる組織、プロセスのためのツールとして の脅威モデリング ⚫ いきなりルール化するのではなくジワジワ浸透させる取り組みとして社内向けワークショップ ⚫ 意外と好感触だったが、実務活用に向けては事前知識の習得やインセンティブ設計など 「ハードルを下げる工夫」も必要そう ⚫ 引き続き、現場と対話しながら試行錯誤 まとめ 35 

ありがとうございました