脆弱性対策は“いたちごっこ”！どのように対処すべきか？

はじめに（脆弱性に関する誤った認識）

昨今、サイバー攻撃に関するニュース・記事が紙面を賑わす機会が増えている。企業がサイバー攻撃を受けた場合、システムダウンによる業務停止、情報漏えいによるレピュテーションの低下、さらには株価低迷・販売不振にまで発展するなど、経営に与える被害は極めて甚大である。

こうしたサイバー攻撃の糸口としては、様々な要因が考えらえるものの、特に多い事由としては、脆弱性の悪用が挙げられる。脆弱性とは、製品におけるプログラムの不具合や開発者の意図しない処理など、セキュリティの棄損につながり得る欠陥のことを指す。サイバー犯罪者は脆弱性を悪用することで、攻撃対象のセキュリティの仕組みをすり抜け、冒頭に挙げたシステムダウンや情報窃取を行うことが可能となる。

脆弱性は、専門のソフトウェアやサービスを活用することで、開発段階で発見できるものもある。その一方で、それまでは問題がなかったとしても、情報システム内で使用されるソフトウェアやプログラムライブラリなどのバージョン更改や、ネットワーク・ハードウェアなどの技術進化によって、新たな脆弱性が発生するケースもあるため、完全に無くすことは困難である（「いたちごっご」が続いてしまうため）。

そのため、脆弱性への対策は企業にとっては憂慮すべき重要な課題である。このような状況を踏まえ、セキュリティ担当役員であるA氏の脆弱性に関する発言を見ていこう。

上記の3つの発言には、勘違いと呼ぶべき内容が含まれている。それはどういった点だろうか、まずは、認識を合わせるために見ていきたい。

SNSの拡散力に関する理解不足

ソーシャルメディアの拡散力は非常に強力なため、ネガティブな投稿内容の場合、その投稿を起点に炎上が発生し、企業のレピュテーションに多大な影響を及ぼす可能性があることを見落としている。

脆弱性のような経営被害につながる情報であれば尚更である。また、こうしたSNSの拡散を見逃す、または、確認が遅れてしまう一因として、その企業に問合せ窓口が存在しない、または存在したとしても、そのことが世間に認知されていないケースも往々にして見られる。

ただし、こうした場合、投稿者は良かれと思い世間に知らしめる意味で、ソーシャルメディア上に公開する、という可能性も否定できない。そのため、一概にSNSに投稿されることを発信者側のモラル不足と捉えるのは危険な考え方である。

外部情報を活用したタイムリーな情報収集が不十分

脆弱性情報が公表された場合、セキュリティベンダーや研究者による対策検討が開始される一方で、攻撃者にとってもつけ込む手段の糸口を与えることになる。そのため、公開された瞬間からいかに早くそれをキャッチアップして、自社組織としての対策につなげるかが肝要となる。例えば、その動きが1か月後、3か月後、さらに長引いて半年後になるようではもはや致命的な事態を招きかねない。

また、脆弱性情報は必ずしも自社リソースのみで調査・分析しなければならないのだろうか。近年、脆弱性情報に関する様々な分析データを提供する外郭団体や専門機関が存在するが、そもそも、そういった情報を活用することはできなかったのだろうか。

不適切な報告タイミングと社内の連携不足

脆弱性情報を公表することは大切であるが、対策や影響範囲が不明瞭なまま公開すること前述したように攻撃者につけ込む糸口を与えてしまう。また、脆弱性情報はセキュリティ部門のみに連携するだけで良いのだろうか。

セキュリティ被害が発生した場合、単に技術的な分析・対応だけでなく、広報対応、監督官庁対応、顧客対応等、様々な外部ステークホルダーを見据えた対応が必要となる。つまり、セキュリティ管理を担う組織だけでなく、社内の様々な部門に影響が及ぶのではないだろうか。

以降では、上記の3つの問題点をどのように回避すべきかを解説する。

対策1：レピュテーションリスクのコントロール

ソーシャルメディア上で企業に関するネガティブな情報が拡散・炎上した場合、最終的には謝罪会見にまで発展する場合もある。そのため、企業にとってはソーシャルメディアを軽視することは、信用失墜を招きかねないことを認識する必要がある。そのためにも、ソーシャルメディアモニタリングの実施を推奨する。

ソーシャルメディアモニタリングとは、ソーシャルメディア上で企業の信用に影響を及ぼす発言の内容・傾向を監視することである。モニタリングにはアカウント、検索キーワード、そして監視を実施する担当者が必要となる。

アカウントは投稿内容の確認や投稿者とのコミュニケーションに必要であり、組織としての公式アカウントがある場合、それを活用するケースも見られる。検索キーワードとしては、主に製品名やサービス名が中心となる。当然ながら、海外でも展開している場合は日本語や英語のキーワードだけでなく、販売している国で使用される言語の製品名やサービス名も含めるべきである。

そして、担当者がそれらのトピックに関する発言を定期的に確認し、レピュテーションに影響するようなネガティブな発言があれば、内容の確認や投稿者への連絡を行い、事態が収拾できるようコントロールする。ただし、モニタリングは多くのタスクが発生するため、社内で担当者をアサインできない場合、モニタリングサービスを専門とする企業への外部委託も検討すべきである。

ただし、上記は組織としてのプロアクティブな対応であるものの、その逆であるリアクティブな対応も重要となる。具体的には、問い合わせ窓口の設置・周知である。一般的には、公式ホームページ、SNSアカウントの詳細欄、または、脆弱性関連であれば脆弱性情報の共有コミュニティなど、複数のメディア上に掲載しておき、様々なシチュエーションでの問い合わせに応じる準備が重要となる。

さらに、外部からの連絡受付に際して、どのような情報を含めて欲しいか予め公開しておけば、情報不足による企業と報告者間での無駄なやり取りが発生することを防げる。

公開する情報媒体としては、ディスクロージャーポリシーや脆弱性対応ポリシーなどが挙げられる。通常それらのポリシーには、共有された情報に関する企業の対応方針が記載されており、その中には脆弱性発見のためのテスト方法や制限事項、対象製品、連絡窓口や連絡時に必要な内容、対応プロセスといった情報が含まれる。これらの内容を事前に確認してもらうことで、企業と報告者の間でのよりスムーズなやり取りが可能となるだろう。

図1　ディスクロージャーポリシーの例

U.S. SECURITIES AND EXCHANGE COMMISSION, Vulnerability Disclosure Policy, https://www.sec.gov/vulnerability-disclosure-policy

対策2：外部情報の最大限の有効活用

脆弱性は公表されて間もなく、サイバー攻撃に悪用されることも多いため、随時情報をキャッチアップすることが求められる。

脆弱性情報の収集には、Webサイトの更新を通知してくれるRSS（Really Simply Syndication）や、特定のトピックに関する情報を指定した頻度で通知してくれるGoogleアラートと言った外部ツールを活用することも可能であり、ツールの扱いに慣れればすぐに始められるだろう。

図2　RSSによるWebサイト更新の通知例

もちろん、IT資産の刷新や棚卸に合わせて脆弱性情報を収集しているケースもあると推定される。しかし、いち早く脆弱性情報を認識することで、通常運用を妨げることがない修正スケジュールや人的リソースの確保、さらにはセキュリティ製品による監視強化など、事前に脆弱性への対策を練ることが可能となる。

また、脆弱性情報は、外郭団体（IPAやJPCERT/CCなど）や製品ベンダー、セキュリティベンダーから随時発信されている。公表される脆弱性の多くには脆弱性評価のため、CVSS（共通脆弱性評価システム）によるスコアが記載されている。CVSSでは、情報セキュリティのCIA（機密性、完全性、可用性）、攻撃可能性、影響範囲など複数の観点から、0（影響無し）～10（緊急の対応が必要）のレンジで算出されるため、脆弱性の深刻度判定の参考になりうる。

加えて、ベンダーから公表される脆弱性の回避策・緩和策は、修正にかかる工数や時間の目途をつける参考になるだろう。例えば、深刻度の高い脆弱性が確認され、自社で利用している製品が影響を受ける場合は、IT部門にその旨を連携することで、対応可否や対応期限の判断に活用できるだろう。

対策3：公表タイミングと社内連携の重要性

脆弱性情報の公表は、早ければよいとは限らない。対策や影響範囲が不明瞭な状況下でむやみに公表することで、攻撃者にとってのヒントやさらなる攻撃を促進し、結果として、サイバー攻撃の被害者となる可能性も高い。そのため、公表前には以下の情報が揃っているかを最低限確認する必要がある。

• 脆弱性の詳細
• 影響範囲に関する情報（影響を受ける製品など）
• 回避策・緩和策に関する情報
• 問い合わせ窓口

上記の情報を網羅的に揃えるには、社内関係者との連携が必須である。社内関係者は開発、営業、サポート、法務部門と多岐にわたるため、体制構築時には連携の中心を担う「調整チーム」を設置するのが望ましい。

各部門が各々で情報連携を行うのではなく、「調整チーム」とのコミュニケーションに一本化することにより、必要最低限のリソースで脆弱性対応が期待できる。

図3　調整チームを中心とした社内連携例

「調整チーム」はその位置づけから、関係部門の業務を理解している人材で構成されていることが望ましく、CSIRT（Computer Security Incident Response Team）はその一例として挙げられる。CSIRTは、コンピュータセキュリティに関わるインシデントに対処・発生予防・社内外調整をすることを目的に設置されるチームであるため、「調整チーム」に適していると考えられる。また、「調整チーム」以外の各部門においても、脆弱性対応時の担当者を設置し、確認事項や意思決定者の一覧、承認プロセスなどの対応フローを予め準備することで、より連携スピードを速められるだろう。

終わりに

以上の解説を踏まえると、冒頭のA氏の発言は以下のようになることが望ましい。

脆弱性を完全に無くすことは不可能である。「いたちごっこ」は続くだろう。ただし、発生した脆弱性に対して、適切かつ迅速に対応することで、被害は極小化することができると考えられる。そのためにも、レピュテーションリスクのコントロール、外部情報の有効活用、公表タイミング検討および社内連携体制の構築は、重要な成功要因であり、こうした取組みを組織一丸となって行うことを期待したい。

本記事のPDFをダウンロード（PDF, 871KB）

【連載】勘違いセキュリティ（あなたの理解は大丈夫？）シリーズブログ記事はこちら