脆弱性情報の取り扱いにおける、基本的な考え方と注意すべきポイント

昨今、脆弱性に関する情報の取り扱いや報道の在り方について、様々な議論が盛り上がりました。しかし、脆弱性に関する情報（以下、脆弱性情報）について直接触れる機会がない方にとっては、報道の問題点や、そもそも脆弱性情報とは何かがわかりにくかったのではないでしょうか。また、ソフトウェア製品開発者（以下、製品開発者）の中には、今後脆弱性を発見してしまった際にどのように取り扱うのが正しいのか、報道を受けて改めて考えた方もいるかもしれません。

本記事では、脆弱性情報を取り扱う際の問題点と、ラックにおける脆弱性情報の取り扱い方針について説明します。

脆弱性とは

まず、脆弱性とは何かを整理します。独立行政法人情報処理推進機構（以下、IPA）が公開する「情報セキュリティ早期警戒パートナーシップガイドライン」では脆弱性を以下のように定義しています。

脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、その機能や性能を損なう原因となりうるセキュリティ上の問題箇所です。
なお、製品開発者の不適切な実装やウェブサイト運営者の不適切な運用によって、個人情報等が適切なアクセス制御の下に管理されておらずセキュリティが維持できなくなっている状態も含みます。

情報セキュリティ早期警戒パートナーシップガイドライン | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構「情報セキュリティ早期警戒パートナーシップガイドライン-2024年版」P.3より抜粋

端的に言えば、脆弱性とは「Webサイトやソフトウェア製品の機能を損なう攻撃が可能な問題個所」と言えるでしょう。これは、「情報セキュリティ早期警戒パートナーシップガイドライン」における脆弱性の定義ですが、例えばWebサイトの入力欄から不正な操作ができてしまうケースや、ソフトウェアの設定ミスを突いて内部情報を引き出されるケースなど、形はさまざまです。いずれも、製品の管理者以外が不正に機能や性能を損なわせることができてしまう「弱点」という点が共通しています。この考え方は、専門家に限らず広く一般にも共通認識になりつつあります。

脆弱性情報と危険性

本記事における脆弱性情報とは、「脆弱性がどの製品のどこに存在しどのように攻撃できるかといった一連の情報」を指します。脆弱性は製品の弱点である以上、脆弱性情報はそのものが取り扱いに注意を要する危険な情報です。なぜなら、世間でも報道される不正アクセスや情報漏えい、Webサイトの改ざんといったサイバー攻撃の原因の1つが脆弱性の悪用だからです。

攻撃者は、個人や企業が利用するシステムの脆弱性を常に探し、攻撃の糸口を見つけ出そうとしています。そのため、新しい脆弱性の情報は、ダークウェブと呼ばれる闇サイトで売買される程に攻撃者にとっては価値のある情報です。対策方法が存在していない脆弱性は攻撃者にとって格好の標的となり、脆弱性が悪用されることによって広く社会システムの安全を脅かす恐れがあります。

このように、脆弱性情報は扱いを誤れば被害を直接引き起こす可能性があるため、特別な注意と責任をもって取り扱う必要があります。

脆弱性情報の不適切な公開による影響

脆弱性情報が不適切に公開されると、どのような事態が起こるでしょうか。まだ対策方法が存在しない脆弱性情報の不適切な公開によって生じる影響は、大きく2つに分けて考えることができます。

直接的な影響

1つは脆弱性を直接的に攻撃されることによる、ゼロデイ攻撃（対策、修正方法が公開前の脆弱性を狙った攻撃）の発生です。

• （1） 重要インフラに対してゼロデイ攻撃が行われれば最悪の事態として、電気やガス、水道、交通機関の停止による社会経済の停止が生じる
• （2） 企業が提供するサービスの停止や、企業が保有する個人情報の漏えい等につながる
• （3） 製品開発者による対策前に攻撃が発生することによって、製品利用者の被害が拡大する

間接的な影響

直接的ではない影響として、脆弱性が存在する製品を使用している企業や、製品を開発した企業に対する信用失墜が考えられます。

• （1） 適切な脅威の説明がないまま「危険だ」という認識が独り歩きし、対象製品の利用が忌避される
• （2） 製品開発者以外からの情報公開となり、「製品開発者の対応が遅い」といった不適切な誹謗中傷にさらされ信用を失う
• （3） 脆弱性について誤情報の流布や過剰反応が発生し、社会的混乱により誤った対策の実施やパニックが生じる

「情報セキュリティ早期警戒パートナーシップ」に届け出されたソフトウェア製品の脆弱性は、CVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）という全世界共通の管理番号が付与され、国際的なデータベースに登録されます。登録時には、脆弱性の影響度を評価し、共通脆弱性評価システム（Common Vulnerability Scoring System：以下、CVSS）にて脅威度を数値化します。各脆弱性の危険度を共通の基準で可視化し、企業や開発者が対策の優先順位を判断しやすくしています。

しかし、CVSSの数値は専門的な要素を多く含むため、一般の方が脅威度を正確に読み解くのは容易ではありません。数字だけを見て「高い」「低い」と判断してしまうと、実際のリスクとのギャップが生じることもあります。

脆弱性情報の報告先

ここからは、日本国内における脆弱性報告の窓口を紹介します。

製品開発者

まず考えられるのは製品開発者（開発企業）に直接連絡することです。サポート窓口等にWebサイトやソフトウェア製品の脆弱性を報告し、適切な担当者にエスカレーションしてもらうことで修正対応を依頼できます。この方法であれば、第三者を挟まないため修正までの対応時間が短くなる可能性があります。

一方で、サポート窓口の担当者が脆弱性について十分な知識を持っていなかったり、個人からの連絡で信用を得られず情報が受け取られなかったりする可能性もあります。特にサポート窓口をアウトソースしている場合などは、窓口担当者がエスカレーション先を把握しておらずサポート窓口の時点で情報が止まってしまうことも考えられます。

窓口から製品開発部門にエスカレーションが行われても、これまでに脆弱性の修正や公開の経験がない場合は、修正から公開までにどのような手順を踏むべきかを担当者が把握していないこともあり得ます。こういった場合、製品開発者による脆弱性の修正や公表までの時間が長くなることもあり、発見者は自身が発見したという功績を発表できないことからフラストレーションを抱えることもあります。また、対象の製品が個人作成のオープンソースソフトウェア製品等の場合、そもそも連絡先が不明な場合もあり連絡できないという状況も考えられます。

このように、発見者と製品開発者間で直接やり取りする場合、双方の知見や認識が嚙み合うケースにおいては迅速な脆弱性情報の公表につながることもありますが、齟齬が生じるとトラブルになるリスクもあります。

情報セキュリティ早期警戒パートナーシップ

国内においては、発見者と製品開発者、その他関係者間の調整制度として「情報セキュリティ早期警戒パートナーシップ制度」があります。これは経済産業省の告示に基づき、IPAと一般社団法人JPCERTコーディネーションセンター（以下、JPCERT/CC）が協力して運営しています。受付窓口はIPAが担当し、製品開発者との調整やCVEの採番をJPCERT/CCが担当しています。

この制度の目的は、脆弱性情報の適切な流通により、不正アクセスやマルウェア等による被害発生を抑制することです。なお、あくまで制度であるため法的な拘束力はありません。

※ 情報セキュリティ早期警戒パートナーシップガイドライン | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構

制度を通じて届け出られた脆弱性情報は、IPAが脆弱性情報に不足が無いか、虚偽ではないかを精査します。そのため、製品開発者にとっては信頼性の高い情報として通知されるメリットがあります。しかし、精査に時間を要したり、「情報セキュリティ早期警戒パートナーシップガイドライン」や告示が定める脆弱性ではないとして、制度上の脆弱性ではないと判断されたりすることもあります。その場合でも、製品開発者やWebサイト運営者に参考情報として通知する場合もあります。

情報公開については、JPCERT/CCが製品開発者と調整し、脆弱性への対策が完了したことを確認したうえでCVEに脆弱性情報を登録します。その後、製品開発者の対策や脆弱性情報の公開に合わせ、一般公開されます。脆弱性の発見者に対しては、届け出の時点で第三者へ脆弱性情報の公開を控える「情報非開示依頼」が行われ、正当な理由とIPAへの事前調整なく公開しないように求めています。

この制度を利用することで、IPAやJPCERT/CCが発見者と製品開発者の間を調整し、必要な情報のやり取りや情報公開の段取りを行うため、発見者や製品開発者の情報公開の負担を軽減できます。また、脆弱性情報のデータベース（JVNやCVE）への登録も自動的に行われ、発見者情報がJVNに掲載されます。一部の脆弱性は製品開発者自身が届け出を行い、JVN登録やCVEの採番を行ったものがあります。

国内で脆弱性を発見した場合は、まずこのパートナーシップに届け出ることで、情報公開に伴う調整負担を最小限に抑えつつ、安全かつ信頼性の高い形で脆弱性情報を共有できるといえます。

※ 脆弱性関連情報の届出受付 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構

パートナーシップに届け出ないといけないか？

脆弱性を発見した場合は、「情報セキュリティ早期警戒パートナーシップ制度」に必ず届け出る必要はあるのでしょうか。「情報セキュリティ早期警戒パートナーシップガイドライン」では、脆弱性を発見した場合はパートナーシップに届け出を推奨していますが、法的な義務ではありません。筆者としては、必須ではないものの特に一般の方が脆弱性を見つけた場合は、この制度を活用することを強く勧めます。

パートナーシップ制度の目的は、脆弱性情報の適切な流通と公開を行い、マルウェアや不正アクセス等の被害の発生を防止することです。法的な拘束力を持つ条項はありませんが、発見者と製品開発者、IPAやJPCERT/CCといった専門機関が連携し、情報公開の調整を円滑に進めるための仕組みです。製品開発者が、発見者からの直接の届け出を受け入れることを承諾している場合は、パートナーシップを介さず届け出ることも認められています。

そのため、脆弱性の発見者が製品開発者と適切なやり取りができ、双方の信頼関係を持って情報公開を行える場合は、必ずしもパートナーシップを利用する必要がありません。ただし、多くの発見者が製品開発者との間に信頼関係を構築できているとはいえず、製品開発者も適切な情報公開の調整ができるノウハウがあるとは言えません。また、JVNへの登録やCVEの採番といった手続きを知っている発見者や製品開発者はほとんどいないのではないかと思います。

こういった様々な情報公開の手続きを容易に、かつ十分なノウハウを持って調整してくれるのがパートナーシップの最大のメリットと言えます。

ラックでの脆弱性情報の取り扱い

脆弱性情報の発見者になりうるのは、製品ユーザやソフトウェア製品の開発企業、ラックなどサイバーセキュリティ企業があります。そのため、脆弱性を見つける可能性がある企業では、社内規定として脆弱性情報の取り扱いポリシーを定めるべきでしょう。

ラックでは「脆弱性発見奨励規程」を設定し、脆弱性の取り扱いと報告先を定めています。この制度ではラックの社員が脆弱性を発見した場合、社内の窓口に報告を求めており、社内の有識者が内容を審査したうえで「情報セキュリティ早期警戒パートナーシップ制度」へ発見した社員から届け出を行うように規定しています。その後、パートナーシップで脆弱性の届け出が受理された場合は発見した社員に対し、ラックから報奨金が支払われる制度となっています。

この制度は、ラックの社員に脆弱性発見のモチベーションを与えることも目的の1つではありますが、脆弱性の発見時の社内手続きを明確化することで円滑な対応を促進し、不正アクセスやマルウェアによる被害の抑制に寄与することを目的としています。

さいごに

脆弱性情報の取り扱いや公表、修正方法については様々な意見があり、一概に絶対の回答が存在すると言えない状況です。

しかし、ソフトウェア製品（電子機器への組み込みソフトウェア製品も含む）において脆弱性やバグが発見されることは日常的であり、製品開発者にとって脆弱性の対応は避けられない業務です。もちろん製品開発者は脆弱性が作りこまれないよう様々なテストを行ったうえで製品を販売していますが、複数のソフトウェア製品が組み合わされた結果や利用環境の特異性により想定しなかった脆弱性が発見される場合もあり、絶対に脆弱性がない製品を開発するのは不可能とも言えます。

そのため次善の対策として、脆弱性が発見された場合は速やかに修正を行い、少しでも早く修正バージョンや修正パッチの公開が求められます。この実現のためには、脆弱性の発見者が適切な方法で製品開発者に脆弱性情報を連絡し、修正が開始されることが前提となります。ただし、脆弱性が修正される前に不必要な第三者に情報がわたってしまった場合、意図せず脆弱性が公表され攻撃者に悪用される可能性があります。この場合は発見者も非難され、製品開発者も不利益を受けます。何より製品利用者に被害が及ぶため、社会における公益性が強く損なわれる状況となります。

もちろんいつまでも脆弱性情報が秘匿され続ければ、発見者の功績が発表できないことで発見者の利益が損なわれるという指摘もあります。脆弱性の発見者には、自身の功績と社会的責任の両方を考慮した慎重な対応が求められます。防止できたはずの被害を生じさせることがあってはいけません。

特に、「情報セキュリティ早期警戒パートナーシップ制度」や、製品開発者のバグバウンティプログラム等を通じて脆弱性情報の届け出を行う場合は、利用する制度が定める手順をよく確認して手続きを行う必要があります。届け出に関する情報をSNS等に投稿することが制限されていないか等、制限事項について必ず確認しておくことが重要です。

参考情報

JPCERT コーディネーションセンター 脆弱性対策情報