2つ目のシナリオでは、最初のシナリオに続くある会社の風景が映し出された。
この会社では、1つ目のシナリオで発覚した脆弱性を踏まえ、影響を受けるシステムを特定し、できるところから早急にパッチを適用することで対応方針を立てた。しかし一部には、動作確認などの必要があるためすぐには適用が難しいシステムもあった。しかもそのうち1つは、社長の肝いりで進められているプロジェクトを担うもので、明日にリリースを控えている状況だ。社長に相談しても「リリースを遅らせるわけにはいかないので、パッチ適用以外に方法はないか?」と返されてしまった――。
このような場面ではどう動くべきか。ここでも宮内氏は5つの選択肢を用意した。
リアルタイム投票の結果、最も多かったのは「D」で回答者の4分の3がこの段階でのリリースを選択した。次に多かったのはCで、7割程度の回答を集めた。リリース延期などが可能かどうかを検討するというBも半数近くあり、さらに、Aを選択した回答者も4分の1程度あった。
宮内氏は「Dが一番多かったのは個人的には意外でしたが、影響範囲の及ばない機能だけリリースし、後からフルリリースするのはありだと思います」とした。ただ、この場合、機能的にどのような影響が生じるかを関係者に情報共有する必要がある。従ってDを選択するにしても、まずはBの情報共有を実施した上で決めることが重要だとした。
Bの情報共有は非常に重要なポイントだ。何か起きたときには、関係者に対して速やかに情報共有し、連携して意思決定していくことになる。「ただし、何か起きた時に駆け込んだところで、話がうまくいくかというと、なかなかそうはならないケースもあります。緊急時に速やかに対応を始めるには、平時からそういった土壌、関係性を作っておくことが非常に重要です」(宮内氏)。
宮内氏は2つ目のシナリオを踏まえて脆弱性対応におけるポイントを説明した。
脆弱性対応には、パッチやセキュリティ修正プログラムを適用したりプログラムのソースコードを修正したりして脆弱性を解消する「恒久対応」と、先ほどの選択肢のCに当たる、セキュリティ機器などで脆弱性を突く攻撃をブロックする「暫定対応」の2つがある。
暫定対応はもちろん重要だが、サイバー攻撃の動向に応じてアップデートする必要があり、最終的には恒久対応を目指すべきだ。だが今回の動画で示した通り、全てのケースで恒久対応がすぐに実行できるわけではない。従って「こういった2つの選択肢を用意しながら、恒久対応を目指しつつ、暫定対応でできることはないのかを考えていくことが、何かあったときの脆弱性対応の流れではないかと思います」と宮内氏は説明した。
この際に重要なポイントとなるのが、どのように「優先順位」を付けるかだ。今や、連日数十件というレベルで大量の脆弱性が公開されている。対応に当たるコストやリソースを考えると、その全てに対し、速やかにパッチを当てて恒久対応できるかどうかは疑問が残る。そのため「その脆弱性は危険度はどの程度なのか」「自社の資産にどのような影響を与えるのか」といった事柄を考慮しながら、影響が大きい脆弱性から優先的に対応することになる。
宮内氏は優先順位を決定する材料の一つとして、脆弱性の深刻度を表す共通の評価指標である共通脆弱性評価システム(CVSS)を挙げた。この数値を見ることで「どのくらい重大な脆弱性なのか」を大まかに把握できる。
ただしCVSSには3つの評価基準がある。よく使われているのが、8つのパラメータからなる「基本評価基準」だが、他にも脆弱性情報がどれぐらい信頼できるものか、対策の有無や攻撃を受ける可能性に基づく「現状評価基準」と、対象システムのセキュリティ要求レベルや緩和策が取れるかどうかといった事柄を踏まえた「環境評価基準」があり、こうした情報も参照しながら、さまざまな角度から総合的に評価することが重要だとした。
もう一つのポイントはPoC(概念実証)だ。脆弱性の中には、まだ研究段階にすぎないものもあれば、すでに悪用が始まっているものある。PoCが公開されると、本来の意図は脆弱性の有無を検証するための善意であっても、攻撃プログラムに転用され、実際に攻撃が始まってしまうケースもあるため、PoC公開の有無についても注意深く見ることが重要だ。
「状況は時々刻々変わっていきますが、その状況を見ながら、どう対応していくか、それに応じて優先度を変えていくのが重要です」(宮内氏)
宮内氏はもう一つ留意すべきポイントとして、ソフトウェア部品の管理と評価に触れた。今や、われわれが利用するソフトウェアやハードウェアは、複数のソフトウェア部品やハードウェア部品から構成されている。このため「あるソフトウェアで脆弱性の有無を判断するには、最終的な製品だけではなく、それを構成する部品についても判断しなければなりません」。それを管理するための手段が最近注目されている「SBOM」(Software Bill of Materials)であり、ソフトウェアサプライチェーンの文脈からも注目されているとした。
最後の動画は、某社システム部ではさまざまな議論を交わしたものの、社長からは「セキュリティをしっかりした上で、明日リリースせよ」と命じられ、最後に頼みとなるのは現場の火事場の底力か、あるいは皆で神頼みか――という場面で終わってしまった。
宮内氏は「果たしてシステム部に明日は訪れるのか」と述べ、あらためて一人一人の頭で、こうした場面のどこに問題があり、どうすべきかを考えてほしいと呼びかけた。それこそが自分たちの環境での再発防止策や次の改善につながるはずだという。
最後に宮内氏はあらためて2つのポイントを挙げた。
1つ目のポイントは、平時から脆弱性管理に取り組んでいくことの重要性だ。資産の把握と、普段からの情報を通じた脆弱性の検出、優先順位を付けた上での対応という3つのステップで管理を進めることで、インシデント発生を抑止したり、仮に発生しても影響を極小化したり、初動対応を迅速化したりできる。
2つ目のポイントは、「セキュリティは組織全体の問題である」という認識を持つことだ。今回の動画を通して示された通り、脆弱性対応はシステム部だけで解決できる問題ではなく、事業部門や経営層にも影響してくる。「放っておくとどんどん悪化していくのがサイバーインシデントです。何かあったときにはできるだけ早く関係者を巻き込むことが重要ですし、そのためにも平時からコミュニケーションを取っていくことが重要でしょう」と宮内氏は述べた。
同氏は、今回紹介した動画を見ての「頭の体操」を通してさまざまな気付きを得るためにも、機会を捉えて積極的にこうした机上演習に参加してほしいと呼びかけ、講演を終えた。
Copyright © ITmedia, Inc. All Rights Reserved.