脆弱性とどのように向き合うか 総関西サイバーセキュリティLT大会 2022年08月10日 井上圭

- 2 - 目次 ◼ 自己紹介 1. どのように脆弱性と向き合うか 2. どのように対応したらよいのか 3. まとめ ※本発表は私個人の私見であり、所属会社とは無関係です。 キーワード • 事業へのリスクで判断 • SBOM • SSVC

- 3 - 自己紹介 ◼ 井上圭 ➢ Future株式会社 CyberSecurityInnovataionGroup(CSIG) ✓ オープンソースなVulsを基にした、脆弱性検知ツール FutureVuls の販売やサポート ✓ セキュリティコンサルティング サービス ✓ トレーニング等（サイバーコロッセオ：脆弱性診断実務、塩尻市主催勉強会登壇等） ◼ 趣味 ➢ 水風呂、バイク、四輪のレース ✓ （水風呂の人、と覚えて頂けるといいかと） ◼ 個人的な活動 ➢ SNS上のアカウントの方が知られているようだ ➢ 脆弱性に関する勉強会「脆弱性対応勉強会」の実施 ✓ 関東在住ですが、旅行/出張に合わせて関東外でも実施 ◆ 札幌、大阪（淀屋橋付近）など開催 ◆ 声かけてくれればどこでも行きます！（大阪行きたい！）

- 4 - 1. どのように脆弱性と向き合うか 日々発見される脆弱性は、対応しないと様々な影響を受ける。 対策のために脆弱性と向き合う為には、以下の活動が必要になる。 ◼ 「自身に関係のあるシステム」に対して ◼ 「どのような影響があるか」を確認し ◼ 「対応を行う事」

- 5 - 1-1. 自身に関係のあるシステム 対象となるシステムを明確にしておく必要がある。 ◼ どのような構成になっているのか ◼ どのようなサービスを提供しているのか ◼ どのようなソフトウェアを使っているのか ◼ どのような情報を持っているのか

- 6 - 1-2. どのような影響があるのか 脆弱性により、どのような影響があるかを明確にする ◼ 脆弱性それ自体の影響 ➢ CVSSや脆弱性情報を参照し、脆弱性自体の影響を確認する ◼ 保有するシステムでの影響 ➢ 脆弱性自体の影響度と、実際のシステム上での影響は異なる場合がある ◼ 事業に対する影響 ➢ 脆弱性を、事業に対するリスクとしてとらえる ✓ ソフトウェアにバグがあるから直さなければいけない、ではなく、事業インパクトがあるから対応しなければいけない、と いう考え

- 7 - 1-3. 対応を行う 事業に対する「リスク」にどう対応するかを決める。 リスクに対しては以下の対応が取れる。 ◼ 回避 ➢ 発生頻度が無くなるような対策をする ✓ アップデートを実施し、根本解決をする ◼ 転嫁 ➢ 影響や責任を他の対象に移す ✓ サービスの所有を、SaaSサービスに移管する ◼ 軽減 ➢ 発生頻度や影響度を減らす ✓ 不正なWEBアクセスを、WAFなどで防御する ✓ 仮想パッチを適用する、設定変更で機能を無効にする ◼ 受容 ➢ 影響を受け入れ、対策を行わない リスクマネージメント自体は NIST SP 800-37辺りが参考になるでしょう

- 8 - 2. どのように対応したらよいのか 運用としては、以下のようなフローが必要 記録 認知 判断 対応 構築情報 変更情報 判断記録 攻撃情報 脆弱性情報 構築情報 脆弱性情報 判断記録 判断情報 リスク 判断基準 対応情報 検証情報 技術的内容 変更情報

- 9 - 2-1. 認知 対象システムに脆弱性が発見されたことを認知する ◼ 対象システムへの理解 ➢ 現在のシステムの情報＝構築情報＋更新情報 ✓ どのようなネットワーク構成か、どのような機器が使われているか ✓ どのようなOS/アプリケーション/ミドルウェア/ライブラリが使われているか ◆ 利用しているものに対する脆弱性情報、を得る必要がある ◼ 脆弱性情報への理解 ➢ 脆弱性についての情報 ✓ 情報源により、速度や内容に差がある ✓ どこまでの情報が必要かは、組織の体力による ➢ 攻撃についての情報 ✓ どのような攻撃が流行っているか（キャンペーンなど） ✓ 意図して攻撃せずとも 無差別に攻撃がされている場合は、 被害を受ける場合があるので、無関心ではよろしくない

- 10 - 補足：ソフトウェア特定とSBOM 「どのようなOS/アプリケーション/ミドルウェア/ライブラリが使われているか」 ◼ 実際の所、これの管理が難しい ➢ 例えば、「今利用しているWordPressのバージョンは？」というのに答えられても… ✓ 「WordPressで利用しているPluginのバージョンは？」 ✓ 「WordPressを動かしている、WebサーバやPHPのバージョンは？」 ✓ 「WordPressを動かしているサーバの、opensslのバージョンは？」 ✓ 「利用しているopensslに依存しているライブラリのバージョンは？」 ➢ 特に、ライブラリの依存関係がある物は分からなくなる ◼ これらのソフトウェアを示すために、SBOMというものが今後利用されていくと思われる ➢ SBOM:Software Bill Of Materials（ソフトウェア部品表） ✓ 特定製品に含まれるソフトウェア/ライセンス/依存関係を一覧化するもの ✓ 米国バイデン大統領が2021年05月に署名した、サイバーセキュリティ強化のための大統領令でサプライチェーンセキュリ ティ対策の一環として示された ✓ 2021年07月に、米国商務省電気通信情報局（NTIA）が、最小要素・自動化サポート・プラクティスとプロセス、につ いて定めた ➢ 現時点では必須ではないが、（少なくとも米国では）今後 連邦機関への対策として必須となっていくと思われ る（Known Exploited Vulnerability Catalogと同様に） Wordpress httpd2 openssl 依存ライブラリ 4.7.1! 2.4.x? 1.1.? ??? ワカラン

- 11 - 以下の内容が記載される ◼ ソフトウェア名称 ◼ バージョン ◼ ハッシュ ◼ etc… しかしながら、現状では 項目は決まっているが、その中身の表現 方法は結構バラバラ のように見える。 相互運用性の為の標準化が もう少し必要かもしれない

- 12 - 2-2. 判断 どのような影響を与えるのかを確認し、どのように対応するかを判断する。 ◼ 対象にどのようなリスクがもたらされるのかを基に、対応を決める ➢ 脆弱性それ自体の影響を理解する => CVSSのScoreなどを利用 ➢ 対象システムでは、どのような影響があるかを理解する ✓ 事業への影響がある物と、事業への影響がないものは、対応は異なる ✓ リスクとしてとらえる＝非常に危険だが発生頻度はほぼない場合、許容できるか、等 ◼ リスクで考え、対応を検討する ➢ 受容できるものは、（すぐには）対応しない ✓ 別の脆弱性対応をするときに一緒に解消されればよい ➢ リスクを許容できない場合、対応が必要 ✓ 直接リスクに対応する＝更新を行う ✓ 代替えの方法で対応する

- 13 - 判断基準はぶれがち ◼ 例えば「CVSS v3 BaseScoreが8.0以上は全て対応する」ポリシー ➢ 該当する脆弱性が多数で、対応工数がたりず、対応できない ➢ 「8.0以下にすればやらなくて済むのでは」という基準値改ざん ➢ 仮想パッチを当てたから更新は不要、という根本解決をしない状況 ◼ CVSS BaseScore等は、「脆弱性それ自体の影響」しか示さない ➢ 実装されている環境は考慮されないため、環境により「影響はない」こともある ◼ 最近は、SSVCという「決定木」に状況を入れて決めていく手法が出てきている ➢ SSVC:Stakeholder-Specific Vulnerability Categorization ➢ Exploitがあるか、攻撃が自動化できるか、等の情報を基に、対応を自動決定する ➢ 脆弱性の影響や環境情報を入力し、アクションがアウトプットされる ✓ defer(静観)、scheduled(計画対応)、out-of-cycle(計画外対応)、Immediate(緊急対応) ✓ CVSSの場合は、脆弱性それ自体の危険度しか出ず、どうすべきかは教えてくれないという違いがある https://democert.org/ssvc/

- 14 - 2-3. 対応 プログラム更新等を行い、「リスクの影響を最小化する」作業。 ◼ どのような手段で対応するか、は前述の「判断」でどこまで決めるか次第 ➢ やり方はいろいろある ✓ 「判断」でリスクは許容できない事/対応を行う事を決め、「対応」で手段を決める ◆ 運用担当者に任せることになるので、CSIRTや情シスは ✓ 「判断」でどのような手段で対応するかまで決め、「対応」は実施計画/実行の管理とする ◆ 運用担当者判断等は少なくなるが、CSIRTや情シスなどの指示側の負担は高い ➢ 現実問題、更新するように作られていないシステムの更新、は難しい（慎重な計画が必要） ◼ 手段 ➢ 更新プログラムの適用、設定の変更、他機器での保護 ✓ 但し、更新以外は潜在的なリスクは残る（脆弱性を隠しただけ） ➢ 脆弱性情報から、どのようにすれば影響を受けないのかを正しく読取り、実装 ◼ 対応後の検証 ➢ 適用後、正しく適用されていることを確認する ✓ 反映には再起動が必要、設定変更が成功していない、などのミスをなくす ✓ 事前計画が重要で、汎用的な手順を用意しておくのがよさそう

- 15 - 2-4. 記録 比較的忘れられがちな、記録 ◼ 判断・対応の記録 ➢ どのように判断し、どのように対応したか ◼ 対応による変更の記録 ➢ 更新をした場合、更新後のバージョンなどの記録が必要 ➢ 設定変更で対応した場合、特に注意が必要 ✓ 後日、何故その設定なのか分からないからデフォルト値に変更する=>設定変更で回避、が終了する 理想的には、チケット管理のような仕組みがあるとよい。 ◼ 人力で記録を取るのは合理的ではない ◼ 更新後、例えばSBOMのスキャンをする、などで記録する

- 16 - 全体補足 IPA等も同様なフローを時々出している ◼ 「脆弱性対策の効果的な進め方（ツール活用編）」 ➢ https://www.ipa.go.jp/files/000071584.pdf ➢ 右下に例示したフローでは、適用について多少踏み込んでいる ✓ 今回の私が説明したフローでは、個々のアクションについては詳細には踏み込んでいない ✓ その為、実際にフローを回す段階で検討する事項はまだある ◼ どの場合も、以下の三項目の必要性を説いている ➢ 検知 ✓ 脆弱性情報の収集、自組織構成要素への影響 ➢ 判断 ✓ 対応緊急度、対応要否 ➢ 対応 ✓ 実施計画、適用 ✓ リスクを最小化した状態になる、のが目的

- 17 - 3. まとめ 脆弱性対応は、今後もなくならない作業と思われます。 対応を簡単にするには… ◼ 更新ができるような環境を作る（シフトレフト） ➢ コンテナ化などを用いて、更新が簡単にできるようなシステムを最初に作る ➢ 更新ができないシステムは、設計時から更新することを考慮されていないから ✓ 設計時の不備を、運用側に押し付けられている、ともいえる ◼ 利用している環境を理解する ➢ 利用しているソフトウェア/ライブラリなどが何かを、知る必要がある ✓ 設計時にそれを考慮して作る、SBOMのスキャナなどを利用する、などして自動化をしたい ◼ 要求に合った、脆弱性情報収集などを行う ➢ まずは「脆弱性があること」を認知しないと何もできない ➢ 利用しているソフトウェアを把握していれば、それだけを見ればよいので、見る対象を減らせる ◼ 対応をフレームワーク化する ➢ 毎回どうするべきかをその場で考えるのではなく、判断基準を作ってそれで対応方針を決める方が良い 脆弱性対応は日々続いていくので大変ですが、自動化やフレームワーク化して対応負荷を下げていきましょう。 （いろいろ考えるのは大変なので、更新できる環境で構築し、日々更新していくと楽かもしれませんね。）

- 18 - ご紹介 オープンソースな脆弱性管理ツール Vuls のイベントをやります ◼ Vuls祭り #6 （https://vuls-jp.connpass.com/event/253558/） ➢ 2022/08/26（Fri）19:00- ➢ online / offline (Hybrid) ➢ 特段vulsにこだわっておらず、脆弱性対応をする人に有意義な内容を紹介する、が目的 ➢ 何で宣伝してるの？->私が主催のhogehugaです… ✓ NICTさんから「脆弱性管理の重要性」、私からは「SSVC」について話をします。 ※これは弊社CMではありません