Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Cloud Ace

March 26, 2025
Tweet

More Decks by Cloud Ace

Other Decks in Technology

Transcript

  1. 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 名)
  2. 我々の立ち位置 
 個々の システム担当 セキュリティ コーポレート 開発・運用 SOC CSIRT 開発者

    セキュリ ティ担当 情シス 社内、顧客ともに 開発者が主な対面先 私の所属チームの 主な守備範囲
  3. 開発現場のセキュリティについての困りごと 
 セキュリティチェックリストやコンプライアンスへの準拠を対応に課題 
 対応方法に困っていて助けを求められるケースが多い 
 
 • 対応方法はわかるが、どの程度力を入れれば良いかわからない 


    • 要求事項が現場からすると抽象的で、どう対応していいかわからない 
 • 例)
 ◦ アプリケーション、インフラのログを監視せよ => 何をみる? 
 ◦ ネットワークの異常を検知せよ => IDS/IPS必須? 

  4. なぜこのような課題が出るか? 
 NISTなどの 公開情報 社内の セキュリティ ガイドライン 開発現場での 実装、運用 セキュリティ担

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

  5. 手法の選択:課題 
 Microsoftが提示しているSTRIDEを中心とした流れが一般的と思われるが、課題あり 
 いずれもリスクの理解という目的に対して障害 となるものだった
 
 • 細かい粒度の脅威が多く出やすい 


    ◦ 最終的な被害を想像しにくく、結果として脅威が発生した場合の影響の評価が 
 難しくなる
 
 • 脅威の連鎖が評価できない 
 ◦ 被害がどのように発生するかを考えにくいため、発生可能性の評価がしにくい 
 ◦ 例えば「権限昇格」は単発では発生せず、まず到達しないと悪さができない 

  6. 手法研究:解決案 
 EBIOS Risk Managerを参考にし、 ビジネスリスクに繋がる脅威を考える ような流れを
 採用することで対応 
 ①システムプロファイル作成

    ②攻撃パス検討 ③攻撃シナリオ検討 ・サービスのミッションの確認 ・業務プロセスや情報資産の洗い出し ・関連するシステムや構成要素洗い出し ・業務プロセス、サービスレベルで脅威の  洗い出しを行い、影響度の評価 ・対象システムのDFDを書く ・DFD上で①で出した脅威について、  攻撃パスを図示する ・②で出した攻撃パスが各要素において  どのような脅威が連鎖することで  発生するかを考える(ここで STRIDE) ・脅威の連鎖に対して 発生可能性を評価
  7. 脅威モデリングワークショップ実施 
 良かった点 今後の課題 ・参加者からは、具体的な攻撃イメージを 
  持つことができた、攻撃者目線は新鮮 
  だった、チェックシートや脆弱性診断 


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

  8. 脅威モデリングのアウトプットの利用例 
 一度実施しておけば、 アウトプットにはいろいろと使い道 がある
 
 • セキュリティ観点での監視を行いたい... 
 ◦

    具体的な脅威や、それがどのように発生するかをイメージできているので、検知するための観点 や、頻度などを考えやすい 
 
 • システムの構成変更を行うが、セキュリティ強度が劣化していないかが気になる... 
 ◦ 構成図、DFDを新しい構成で書き直してみて、明らかに信頼境界による保護が外れる箇所や、外 部に露出している箇所を中心に検討できる