開発現場とセキュリティ担当をつなぐ脅威モデリング

Transcript

1. ｜　(C) Cloud Ace, Inc. 開発現場とセキュリティ担当をつ なぐ脅威モデリング クラウドエース株式会社　松島良太郎
2. 松島 良太郎 
 クラウドエース株式会社　エキスパート 
 
 ・SIer、通信キャリアを経て、クラウドエースに入社 
 ・クラウドエースではSREとして活動する他、DevSecOpsの推進、 　SIEMやゼロトラスト製品導入支援などセキュリティ関連の案件に 　多く従事

3. Tokyo (HQ) Osaka, Nagoya, Fukuoka Taipei Shenzhen Hong Kong Bangkok Ho Chi Minh & Hanoi Singapore Jakarta Sao Paulo Delhi India ※2025 年 2 月時点 
 クラウドエース株式会社 代表取締役社⻑ ⻘⽊ 誠 設⽴ 2016 年 11 ⽉ 1 ⽇ 資本⾦ 1 億円 従業員数 395 名（グループ全体 529 名）
4. 目次
 • なぜSIerで脅威モデリング？ 
 • 実際にやってみてわかったこと 

5. なぜSIerで脅威モデリング？
6. 我々の立ち位置 
 個々の システム担当 セキュリティ コーポレート 開発・運用 SOC CSIRT 開発者 セキュリ ティ担当 情シス 社内、顧客ともに 開発者が主な対面先 私の所属チームの 主な守備範囲
7. 開発現場のセキュリティについての困りごと 
 セキュリティチェックリストやコンプライアンスへの準拠を対応に課題 
 対応方法に困っていて助けを求められるケースが多い 
 
 • 対応方法はわかるが、どの程度力を入れれば良いかわからない 
 • 要求事項が現場からすると抽象的で、どう対応していいかわからない 
 • 例）
 ◦ アプリケーション、インフラのログを監視せよ => 何をみる？ 
 ◦ ネットワークの異常を検知せよ => IDS/IPS必須？ 

8. 開発現場とセキュリティ担当のギャップ 
 なるべく少ない手間で 
 ベースラインに準拠したい 
 チェックシートを通じて 
 リスクを軽減してほしい 
 開発 セキュリティ担当 それぞれ目指しているところがずれている？ 

9. なぜこのような課題が出るか？ 
 NISTなどの 公開情報 社内の セキュリティ ガイドライン 開発現場での 実装、運用 セキュリティ担 当者 システム 開発 / 運用担当者 あまり認識されていない ・自社の状況 ・セキュリティの知 識、経験 ・対応しない場合の リスク ・担当システムの知識 ・セキュリティに関する 知識、経験 ・担当システムに潜む 具体的なリスク ・脅威がどう発生するか チェックシート化する過程 でこれが抜ける セキュリティ担当と開発現場で リスクへの感度、解像度に差がある ことが大きな要因の一つと考えた 

10. 脅威モデリングの効能 
 脅威モデリングは具体的なシステムに対して、どのような脅威がどのように発生するか を考える活動
 
 • 開発現場のリスクの感度、解像度をあげる 
 • ベースライン準拠に際して、適切な対応をしやすくなる 
 • ベースラインで対応できない個別ケースで発生するリスクの把握 

11. 実際にやってみて
12. 実際にやってみて 
 実際に当社で脅威モデリングを実施した経験をもとにポイントをお話 
 手法の選択 ワークショップ準備 ワークショップ実施 結果の活用
13. 手法の選択：課題 
 Microsoftが提示しているSTRIDEを中心とした流れが一般的と思われるが、課題あり 
 いずれもリスクの理解という目的に対して障害 となるものだった
 
 • 細かい粒度の脅威が多く出やすい 
 ◦ 最終的な被害を想像しにくく、結果として脅威が発生した場合の影響の評価が 
 難しくなる
 
 • 脅威の連鎖が評価できない 
 ◦ 被害がどのように発生するかを考えにくいため、発生可能性の評価がしにくい 
 ◦ 例えば「権限昇格」は単発では発生せず、まず到達しないと悪さができない 

14. 手法研究：解決案 
 EBIOS Risk Managerを参考にし、 ビジネスリスクに繋がる脅威を考える ような流れを
 採用することで対応 
 ①システムプロファイル作成 ②攻撃パス検討 ③攻撃シナリオ検討 ・サービスのミッションの確認 ・業務プロセスや情報資産の洗い出し ・関連するシステムや構成要素洗い出し ・業務プロセス、サービスレベルで脅威の 　洗い出しを行い、影響度の評価 ・対象システムのDFDを書く ・DFD上で①で出した脅威について、 　攻撃パスを図示する ・②で出した攻撃パスが各要素において 　どのような脅威が連鎖することで 　発生するかを考える（ここで STRIDE） ・脅威の連鎖に対して 発生可能性を評価
15. 手法研究：イメージ 
 攻撃パス 攻撃シナリオ ECサービスのユーザー情報漏洩の場合 

16. 脅威モデリングワークショップ準備 
 脅威モデリングワークショップにかけられる時間は限られているため、 
 できるだけ当日開発チームにも積極的に参加してもらう ための準備を行う
 
 • システムのプロファイリングは事前に開発チームやPdMなどにある程度実施しておいてもらい、ビジネ スや業務プロセス上のリスクの意識をあらかじめ持っておいてもらう 
 
 • 開発チーム側は脅威モデリングに馴染みがないため、概要資料とサンプルは事前配布しておき、具体 的なイメージを掴んでおいてもらう 

17. 脅威モデリングワークショップ実施 
 良かった点 今後の課題 ・参加者からは、具体的な攻撃イメージを 
 　持つことができた、攻撃者目線は新鮮 
 　だった、チェックシートや脆弱性診断 
 　結果の要求事項の意味がわかった、など 
 　ポジティブな感想
 ・開発者側から攻撃イメージが出にくいこと
 　が多いため、脅威のカタログや、
 　考え方のガイドラインを準備できると良い
 効率について ・脅威に対して詳細に分析を行うのは時間を 
 　要するため、重大なものに絞ることも有力
 
 ・完全に社内閉域のあまり重要でないシステム 
 　については実施対象外にするなど、 
 　仕分けルールを整備したほうが良さそう
 
 ・セキュリティチェックシートやベースライン 
 　系の方法の方が効率的なため、脅威モデリ 
 　ングにこれらを求めるならツールが必要 
 実施の結果、リスクについての認識を高める効果を得られた 

18. 脅威モデリングのアウトプットの利用例 
 一度実施しておけば、 アウトプットにはいろいろと使い道 がある
 
 • セキュリティ観点での監視を行いたい... 
 ◦ 具体的な脅威や、それがどのように発生するかをイメージできているので、検知するための観点 や、頻度などを考えやすい 
 
 • システムの構成変更を行うが、セキュリティ強度が劣化していないかが気になる... 
 ◦ 構成図、DFDを新しい構成で書き直してみて、明らかに信頼境界による保護が外れる箇所や、外 部に露出している箇所を中心に検討できる 

19. まとめ
20. まとめ
 • リスクについての理解が開発現場とセキュリティ担当のギャップを埋める大きい要素の一つ 
 
 • そのための活動として、脅威モデリングが有効 

21. Thank you.