実務における脅威モデリングを考えよう

20240917 脅威モデリングナイト#3 発表資料

Transcript

1. 脅威モデリングナイト #3 in Tokyo 実務における脅威モデリングを 考えよう
2. 自己紹介（超短縮版） 2 名前：ニキヌス（X:@nikinusu） 所属：金融JTCのシステム子会社 嫌いなもの：しいたけ
3. （組織名は出せないが）組織紹介 ✓ 売上高：グループ全体で5.8兆円 ✓ 従業員数：グループ全体で40,000人以上 ✓ IT部門員：約1,600人（パートナー会社も加えると更に +数千） ✓ システム数：約1,000システム（私の守備範囲だけで） ✓ 開発プロジェクト数：1,000案件以上/年間（私の守備範囲だけで） 3 グループ全体の売上高的なもの 2社 約2.8兆円 沢山 約3兆円 私の守備範囲 （セキュリティ要員40～50人） ホールディングスの 守備範囲 （セキュリティ要員200人以上） とにかくデカい。 公開用に削除 公開用に削除 公開用に削除 公開用に削除
4. 今日話すこと・目指すこと （１）話すこと Section1. 脅威モデリングの概要と課題 Section2. 事業会社の実務における解決のアプローチ （２）目指すこと 「こんなやり方やレベル感の取り組み方もアリなんだ」と気軽に受け止めてもらうこと 4
5. Section1. 脅威モデリングの概要と課題
6. 脅威モデリングとの出会い 2022年のCSSLP(※)取得を通じて。 学んだ知識を自社のシステム開発プロセスに照らした際に強化領域（下図青字）として認識。 6 ※Certified Secure Software Lifecycle Professional 2022年時点で日本人取得者は13人しかいなかったマイナーぶり。でも良い資格ですよ。
7. 脅威モデリングとは （１）目的 システムを分析して設計上の問題に起因する弱点を探すこと （２）手法 セキュリティ目標の 特定 システムの分解 脅威の特定 対策の検討 脅威モデルの検証 開発するシステムに関連する法律、契約、自社セキュリティ標準から求められるセキュリティ目標の特定 DFDやシーケンス図を用いたシステムの抽象化 信頼境界の洗い出し STRIDEモデルなどを用いた脅威の特定 リスク対応方針の選択 アタックツリーモデルやDREADを用いて脅威を優先付け システム開発の各フェーズを通過する際に、脅威や対策が詳述されていることを確認 7
8. 脅威モデリングの特徴と課題 8 ✓ 設計レベルの脆弱性を早期に対策できる ✓ セキュリティ対策が説明可能になる ✓ コミュニケーションを強化できる ✓ 時間と手間がかかる 某ベンダ「1システムあたり数週間・数百万～かかります」 ✓ ドキュメントがあるとは限らない 「アジャイルなんでドキュメントはありません」 ✓ セキュリティの専門知識が必要 STRIDEモデルはあくまで分析の入口。 具体的な対策に落とし込むには、攻撃手法の知識が必要 Pros Cons ちゃんとした脅威モデリングをやる場合、体力的にできても年間5,6件。 年間1000案件走る組織では効果が限定的すぎる。 課題
9. 補足：STRIDEモデルはあくまで分析の入口 例えば、Spoofing（なりすまし）だけでも多種多様な手法がある。対策はもっとある。 9 Spoofing なりすまし Tampering 改ざん Repudiation 否認 Information disclosure 情報漏洩 DoS サービス妨害 Elevation of privileges 権限昇格 ➢ ブルートフォース ➢ リスト型アカウントハッキング ➢ SQLインジェクションなどによる認証情報の窃取 ➢ IDやパスワードの推測 ➢ 初期パスワードの悪用 ➢ パスワード変更機能の悪用 ➢ パスワードリセット機能の悪用 ➢ ショルダーハッキングや端末からの認証情報の窃取 ➢ セッションハイジャック ➢ Oauth/OIDCにおける攻撃（リプレイ攻撃やCSRFなど） ➢ ワンタイムURLの窃取 ➢ アカウント・プレハイジャック ➢ セッションIDの推測 ➢ セッションIDの窃取 ➢ セッション固定攻撃 ➢ セッションCookieの窃取 ➢ セッション汚染攻撃
10. 10 よし！AIだ！！！！！！！ こういう技術には期待しつつ、実用レベルになるまでに 今どうするか？ https://stridegpt.streamlit.app/ 脅威モデリングの特徴と課題
11. Section2. 事業会社の実務における解決のアプローチ
12. 目的に立ち返る 12 重要なのは「脅威モデリングが出来ること」ではなく「設計レベルの脆弱性が減ること」 指標っぽく言えば、脆弱性診断での指摘数が減ること。 DFDやSTRIDEなどのHowにこだわらずとも、同じ効果が得られれば良いのでは？
13. 力加減を変えてみる 分析対象の重要度やリスクにあわせて取り組み方を考えてみる。 13 対象 数（適当） 力加減 超重要案件 （基幹システムの構築・再構築など） 数える程度 セキュリティ担当が（時には外部のプロも）入り、 手間暇かけてしっかりやる 運用リスク 高案件 特に癖あり 200案件 セキュリティ担当が入り、短時間で大事な論点を洗い出す （1案件あたり目標30分） （基幹以外システムの再構築、Webアプ リの新規構築・修正など） 300案件 システム担当者がセルフで実施 運用リスク 低案件 （バッチの修正、Webアプリの文言修正 のみなど） 500案件 なし（セキュリティの論点がほぼない）
14. （１）短い時間で大事な論点を洗い出す 14 業務端末 インターネット回線 認証 セキュリティ監視 クラウド基盤 サーバ、DB 運用端末 マルウェア対策、脆弱性対策、内部不正対策 DDoS対策、盗聴対策 アカウントハッキング対策 脆弱性を狙った攻撃対策（WAFやIPS） IAMの保護、危険な設定への対策、クラウド管理者権限の保護 脆弱性対策、改ざん対策、保存データ暗号化 マルウェア対策、脆弱性対策、内部不正対策 組織内で共通化されたインフラを早々に切り分けて、システム特有の部分にフォーカスする。
15. 15 （１）短い時間で大事な論点を洗い出す 共通化されやすい14のインフラを示した「セキュリティ概観図」
16. （１）短い時間で大事な論点を洗い出す 4つの質問で14の観点を把握 （組織により右のツリーは異なります） 16 1 2 3 4 5 6 7 8 10 9 11 13 12 14
17. （２）システム担当者がセルフで実施 考えられる原因（仮説） ⚫ 要件の総数が多すぎる ⚫ 自分の開発するシステムに関係しない要件が多く含まれる ⚫ 優先度の高低が分かりづらい 17 そもそも「セキュリティ標準要件」は脅威＆対策を分析した成果物 これを活用しない手はないのに、何故そうなっていないのか？ 解決したら簡易脅威モデリングツールになるのでは？
18. （２）システム担当者がセルフで実施 • XXインターネット回線利用 • XX認証基盤利用 • XXクラウド基盤利用 検討優先度 の設定 システム特性的に 関係ない要件を除外 共通基盤で 満たされる要件を除外 START （要件全量） 約130項目 約900項目 高:約45項目 中:約35項目 低:約50項目 • インターネット公開有無 • メール送受信有無 • 個人情報取り扱い有無 • 手戻り度 • 危険度 セキュリティ標準要件を各開発プロジェクトの特性にフィッティングする仕組みを作り 「集中して考えるべきポイント」を機械的に抽出。（＝セキュリティ相談対応の再現） フィッティング ⚫ Webアプリ設計、コーディング、インフラ設計、運用プロ セス、クラウド、コンテナ、モバイルアプリなど ⚫ 業界規制要件、脆弱性診断ベンダ観点、OWASPガ イドの観点など幅広に取り込み、年2～3回改訂 18
19. 対象 数（適当） 力加減 超重要案件 （基幹システムの構築・再構築など） 数える程度 セキュリティ担当が（時には外部のプロも）入り、 手間暇かけてしっかりやる 運用リスク 高案件 特に癖あり 200案件 セキュリティ担当が入り、短時間で大事な論点を洗い出す （1案件あたり目標30分） （基幹以外システムの再構築、Webアプ リの新規構築・修正など） 300案件 システム担当者がセルフで実施 運用リスク 低案件 （バッチの修正、Webアプリの文言修正 のみなど） 500案件 なし（セキュリティの論点がほぼない） 概観図や標準要件を用いて、限られたリソースでも脅威モデリングと概ね同程度の効果を得られる ように。 19 力加減を変えてみる 「セキュリティ標準要件のフィッティング」を用い てシステム担当がセルフで論点を洗い出し 「セキュリティ概観図」「4つの質問」を用いて 論点を洗い出し
20. まとめ 20 ⚫ （まだ現状は）脅威モデリングは、かける手間に比例して精度が変わる泥臭い分析手法。 大規模な組織においてはスケール面の課題がある。 ⚫ 超重要案件向けの脅威モデリングは、手間をかけて（プロにも入ってもらって）ちゃんとやる。 ⚫ その他大多数の案件は、「概観図」や「フィッティング」により効率的に論点を洗い出す。 ⚫ まずはやり方にとらわれずに、同じような効果を得られれば「もどき」でOKとする。 今日目指すこと： 「こんなやり方やレベル感の取り組み方もアリなんだ」と気軽に受け止めてもらうこと
21. ありがとうございました。