ウェルスナビ開発者ブログ

WealthNaviの開発に関する記事を書いてます。

脅威モデリングを参考に、社内全体のセキュリティリスク可視化を試みた話

サイバーセキュリティチームでマネージャーをしている岡地と申します。本記事では、いま話題(!?)の脅威モデリングを参考に実施した、社内のセキュリティリスク分析について紹介させて頂きます。

サイバーセキュリティチームについて

私は2022年12月にウェルスナビにジョインし、2023年はコーポレートIT部門でセキュリティ担当として従事してきました。2024年1月からサイバーセキュリティチームとして独立し、チーム戦略の策定から始めているのですが、その中で改めて感じたのが、自社のリスク認識の解像度が不十分だということです。別の表現でいうと、自社のセキュリティのカタチがいまいちわからない状態でした。

この段階でも、過去からの経緯で認識できている課題や昨今のトレンドを踏まえた計画の策定も可能ではあるのですが、より精度の高い戦略を立てるためには、自社環境に対する解像度を上げる必要があると感じました。

自社のセキュリティ対策状況について部分的に可視化されたものはいくつもあるのですが、それをつなぎ合わせて俯瞰したとき、どこにリスクがあり、そのうち何を優先的に対処すべきなのか。これをチームや関係者が理解しやすい形で可視化することができれば、今後のセキュリティ対策についてより地に足のついた議論ができ、おそらく精度の高い戦略策定ができるようになるはずです。

脅威モデリングに注目した理由

では、自社環境に対する解像度を上げるためにどうするか。こういった場合に思いつくアプローチの一つは、全体の俯瞰する絵を描くことです。私も過去に経験がありましたが、こういったものは以下の点に難点があります。

  • 全体像を描いたとして、リスクとしての認定やレベル判定が主観的になりやすい
  • このため、納得感が薄く第三者の理解を得られない
  • 有識者しか更新ができず、形骸化しがち

このような課題を回避すべく、以下のような基本方針で考え始めました。

  • 信頼できるフレームワークをベースにする
  • 評価の尺度・基準に明確なロジックがある
  • 外部コンサルに依頼せずに自分たちでアップデートできる

上記を実現するため、まずはベースとなるフレームワークを検討し、他社様の取り組みブログ等を拝見する中で、脅威モデリングが一番合致するように感じました。評価対象・モデルを表現し、想定される脅威を洗い出し、リスク分析をする、というプロセスはまさにこれからやろうとしていることそのものだったためです。

一方で、脅威モデリングについて公開されている情報を見ると、対象スコープを特定のシステムに絞っているケースが多く、社内全体を対象としているケースは見当たりませんでした。このため、脅威モデリングを参考にしつつ、今回はある程度やりやすいように柔軟にやってみたのでした。

※なお、本取り組みを進める途中で脅威モデリングワークショップの開催を知り、参加させて頂いたのも大変参考になりました。この場を借りて御礼申しげます、ありがとうございました!

ウェルスナビで実践した脅威モデリング・プロセス

ここからが本題、弊社で取り組んだ内容を具体的にご紹介します。下記のようなプロセスで実施しました。

❶ モデルの作成

まずはじめに、会社全体の環境について、やや抽象度を上げた全体像を描きました。

  • 既に社内にあった特定エリアに関する構成図等を集めて、粒度をあわせながら繋ぎ合わせる
  • 重要なデータの保管先が一目で分かるようにしたうえで、そこへアクセスしうる経路を表す
  • 重要データへのアクセス制御を可視化するうえで、区別すべきアクターを分けて表現する (一般従業員と特権保有者など)

このステップは先人たちが蓄積してくれていた知見を活用することで想定よりはスムーズに進めることが出来ましたが、細か過ぎず、されどリスク評価上の必要な要素を表現できる抽象度の調整という観点では頭を悩ませたところでした。

サンプルのモデルイメージ

❷ ベースライン評価

次に、作成したモデルへセキュリティ対策レベルを表現する2つの指標を追加しました。このステップは一般的な脅威モデリングではあまり登場しないかも知れませんが、客観的に理解しやすいアウトプットにする目的で実施しました。

1. アクセス経路のトラストレベル

外部のSaaSや社内システムへのアクセス方法について、どの程度信頼できるレベルで制御や検証がされているか、が重要な要素になると考えました。これを実現する方法として、ゼロトラスト・アーキテクチャにおけるポリシーエンジン(PE)とトラストアルゴリズムに注目しました。

  • ポリシーエンジン(PE):リソースへのアクセスを許可または拒否の決定をする論理コンポーネント
  • トラストアルゴリズム:PEの判定根拠になるロジック。リソースへのアクセスを複数の観点でチェックしてアクセス許可/拒否を判断する

出典:「ゼロトラストの現状調査と事例分析に関する調査報告書」(金融庁) (https://www.fsa.go.jp/common/about/research/20210630.html

この仕組みを参考に、各アクセス経路のトラストレベルを試算するロジックを定義し、各アクセス経路の信頼性をスコアリングします。各要素がどのようになっているかを判別することはそれほど難しくないため、基本方針に記載した内容にも合致し、ある程度誰でも評価可能な仕組みが実現できているのでは、と考えています。

トラストレベル評価シートのイメージ

この最終的なトラストスコアを、①で作成したモデルに書き込みました

サンプルモデルにトラストレベルを書き込んだイメージ

2. セキュリティ防御レベル

各ポイントで施されているセキュリティ対策のチェック内容をもとに、防御レベルを表現しました。ここでも、伝わりやすいようにブロックする対策については同じFirewallのアイコンに数字を書き込むような表現にしています。

  • ネットワークレベルでの制限
  • パターンファイルのような既知の攻撃の防御
  • 振る舞い検知のような未知の攻撃の防御
  • 不審な挙動やマルウェアの検知(ブロックなし)

サンプルモデルにセキュリティ防御レベルを追記したイメージ

ここまでできると、重要データへアクセスするためのアクセス経路がどのようになっており、そこに行き着くまでどのレベルで検証がされているか(トラストレベル)、セキュリティ対策がどの防御レベルで実装されているか、が見える形になりました。サンプルではリソースを絞っているのでイメージしづらいかもしれませんが、例えば同じ属性の重要データへのアクセス経路が複数あり、かつトラストレベル・防御レベルに大きな差異があった場合、何らかのリスク対策の検討が必要、という気付きを得ることが出来ます。

❸ シナリオベース評価 (脅威の洗い出し・リスク分析)

前述までのプロセスを経て、モデルに必要な情報が可視化できている状態になりますので、ここからは具体的な脅威シナリオを想定した評価になります。脅威の洗い出し方法は、STRIDEも参考にしましたが、これに拘らず、前フェーズまでで可視化したモデルをもってセキュリティチーム以外の方にも声をかけて意見をもらいました。洗い出した脅威についても、やはりDREADを参照しながら、弊社なりに簡素化して以下の3要素でリスク評価をしました。

  • 影響度
    • 3 = 重要なデータの漏えい、事業継続へ影響
    • 2 = 社外秘情報が大量に漏えい、通常業務へ大きく影響
    • 1 = 社外秘情報が一部漏えい、通常業務の一部に影響する
  • 発見可能性
    • 3 = 公開されている情報から容易に攻撃口を発見し、ネットワークや端末の制限なく施行攻撃できる
    • 2= 攻撃口を確保するために、専門的なOSINTツールの利用が必要だが、ネットワークや端末の制限なく施行攻撃できる
    • 1= 攻撃口を確保するために、高度なソーシャルエンジニアリングマルウェア等による探索が必要、かつ特定のネットワークや端末への侵入が必要
  • 攻撃容易度
    • 3 = 良く知られた攻撃手法やツールにより、単一の弱点を悪用されることで突破される可能性がある
    • 2= ある程度訓練された攻撃者が複数の弱点を組み合わせることで突破される可能性がある
    • 1= 組織化された攻撃者グループの高度な攻撃を受けた際には突破される可能性がある

この定義は正直、まだ納得しきってはいません。基本方針に記載したことも念頭に、出来るだけシンプルにしたい気持ちがあるのですが、やりすぎると大事な要素が抜け落ちてしまいかねず、バランスが難しいと感じています。ここは引き続き検討しながら、分かりやすく評価しやすい指標を探っていく所存です。

まとめ

ウェルスナビで実施した、脅威モデリングを参考に、社内全体のセキュリティリスク可視化した取り組みの共有は以上になります。(本当はここからが本番で、上記で抽出した課題をもとに、短期的な改善計画や、中期的戦略を立てていくことになりますが、今回の記事では割愛させて頂きます。)

いかがでしょうか?
まだ始めたばかりの取り組みなので継続することで徐々に精度を上げていきたいと考えていますが、既に一定の成果は感じており、まずはやってよかったと思っています。

よかったこと

  • セキュリティチームとして、会社全体のセキュリティ状況について解像度を上げることが出来た
  • 可視化することで、関連チームと目線のあった議論が出来るようになった
  • 当初の重要事項と思っていた、継続性の観点でもある程度機械的な分析方法ができたので今後も続けられそうな予感を感じている

今後もこれを育てながらセキュリティ改善活動に邁進していきます!


💡 参考にさせて頂いたガイドラインや他社様のブログ記事
DS-201 政府情報システムにおけるセキュリティリスク分析ガイドライン ~ベースラインと事業被害の組み合わせアプローチ~(デジタル庁様)

tech.plaid.co.jp


📣ウェルスナビは一緒に働く仲間を募集しています📣

hrmos.co

著者プロフィール

システム基盤グループ サイバーセキュリティチーム セキュリティエンジニア、CISSP 岡地(おかち)