情報セキュリティの啓発を目指した、技術系コメディー自主制作アニメ「こうしす!」の@ITバージョン。第17列車は「もしも脆弱性を発見したら」です。※このマンガはフィクションです。
ここは姫路と京都を結ぶ中堅私鉄、京姫鉄道株式会社。
その情報システム(鉄道システムを除く)の管理を一手に引き受ける広報部システム課は、いつもセキュリティトラブルにてんてこ舞い。うわーん、アカネちゃーん。
「こうしす!」制作参加スタッフが、@IT読者にお届けするセキュリティ啓発4コマ漫画。
謝辞
この脆弱性情報は、情報セキュリティ早期警戒パートナーシップに基づき下記の方がIPAに報告し、JPCERT/CCが開発者との調整を行いました。
報告者:祝園アカネ氏
JVN#63981842:PowerActPro Master Agent Windows版におけるアクセス制限不備の脆弱性
JVNDB-2019-000020:PowerActPro Master Agent Windows版におけるアクセス制限不備の脆弱性
今回のテーマは「脆弱(ぜいじゃく)性を発見したときの対処法」です。
「祝園アカネの中の人」(筆者)が脆弱性をIPAに報告したときの流れと、そのときに考えたことを紹介します。
筆者が脆弱性を発見したのは、2018年9月のことでした。
当該UPS製品は、管理用のソフトウェアを同梱しています。管理用ソフトウェアは、インストール時のオプション選択で、WebブラウザでUPSを設定できるようセットアップできます。
同時にWebサーバをインストールできるのですが、その設定ファイルのアクセス権限設定に不備があり、ソフトウェアをインストールされたPCにログインできれば、一般ユーザーでも任意のプログラムを管理者権限で実行できる状態でした。
脆弱性に気が付いたエンジニアは、どのように対処すればいいのでしょうか。
基本的には推奨できないものの、もし緊急性が高いならば、Twitterで拡散するという手段が、あることにはあります。7pay、7iDの事例では、多くのITエンジニアが問題点を公開の場で検証し、指摘を行いました。
しかし同時に、その行為を疑問視する声もありました。
犯罪を誘発する可能性や、それによってさらなる被害が生じる可能性もあったからです。
脆弱性を発見者が公表すべきか、公表すべきとすればどのような場合か、そしていつ公表すべきか、という点に正解はありません。
不用意に脆弱性に関する情報を公開すれば、その結果生じた被害の責任を問われる可能性があります。
現に「不正指令電磁的記録に関する罪」の法運用を見ても、技術者に対する法的保護が十分とはいえません。脆弱性情報の公表には慎重にならざるを得ないでしょう。
正当な窓口に連絡するという方法もあります。
しかし筆者は、「連絡したのに無視された」経験があります。個人として連絡したので、クレーマー扱いされたのかもしれません。
もし業務の一環として社名を名乗って連絡したとしても、保守契約を結んでいないことを理由に、まともに取り合ってもらえない可能性も想像できます。
アニメ版「こうしす!」のように、最初に電話を受けた人がイタズラ電話と判断して担当者に伝えなかったというケースも実際にあると聞きます。
こうした可能性を考えると、開発元やWebサイトの運営者が行動を起こしやすい状況を作り、きちんと対応してもらうのがベストと言えそうです。
筆者は、「どうすれば最短で対応してもらえるか」を考えました。
サポート窓口に連絡しても、クレーマー扱いで終わってしまうかもしれません。そこでタイムロスしている場合ではありません。
第12列車のように、その会社に就職して内側から変えるという手段もありますが、そんな悠長なことは言ってられません。本件は可能な限り速やかに対応する必要があるからです。
大企業の製品なので、公的機関経由で伝えるのが効果的だと考えました。
そこで、「IPA(独立行政法人 情報処理推進機構)」の情報セキュリティ早期警戒パートナーシップに基づく脆弱性関連情報届け出制度を活用することにし、不受理とならぬよう、再現手順やスクリーンショットなど可能な限り詳しく記載して届け出ました。
その後の経過は以下の通りです。
2018年10月01日 届け出
2018年11月08日 受理
2018年11月15日 調整開始(起算日)
2018年12月26日 謝辞確認
2019年03月26日 製造元よりアップデートがリリース
2019年03月27日 公表
届け出からアップデートがリリースされるまで約半年を要しました。
想定外だったのは、調整開始までのタイムロスが1カ月半も発生したことです。このタイムロスがなければ、1つ前のバージョンの開発サイクルで修正が完了し、年内に修正版がリリースされたかもしれません。
タイムロスを防ぐために、今後は脆弱性を発見した時点で、第一報を製造元企業のサポート窓口に直接伝え、同時にIPAにも届け出した方がよいかもしれません。
注意しなければならないのは、IPAが届け出者を法的リスクから守ってくれるわけではないということです。制度上、実名で届け出る必要がある点も忘れてはなりません(ただし、謝辞への掲載は必須ではなく、また実名ではなくてもいいことになっています)。
業務で脆弱性を発見した場合は、さらなる注意が必要です。
上司や内部通報窓口に相談するなど、適切なルートで判断を仰ぎましょう。取引先との契約や、雇用契約上の守秘義務違反に問われるおそれもあるため、個人の判断で勝手にIPAに届け出ることは避けてください(IPAは公益通報者保護法上の公益通報先としては必ずしも適切とはいえません)。
また、届け出を行っても、内容によっては受理されないことがあります。他にもさまざまな留意点があります。平時から「情報セキュリティ早期警戒パートナーシップガイドライン」を熟読しておくとよいでしょう。
届け出を行って得られるメリットは、「世界が少しだけ良くなること」と、「JVNの謝辞に自分の名前が掲載されること」だけです。
これが、法的リスクや届け出に費やす時間や費用に見合うほどのメリットかというと、微妙なところです。それでも届け出をするのは、信念によるところが大きいでしょう。
今後、届け出をしやすくするためには、届け出者を明確な形で法的に守るような制度が必要だと筆者は考えます。また、バグ報奨金プログラムのような、開発者にも脆弱性発見者にもメリットがある取り組みも広がって欲しいものです。
Copyright 2012-2017 OPAP-JP contributors.
本作品は特に注記がない限りCC-BY 4.0の下にご利用いただけます
フリーイラストレーター。アニメ「こうしす!」ではキャラクターデザイン・キャラ作画担当をしています。
アニメ「こうしす!」監督、脚本。情報処理安全確保支援士。プログラマーの本業の傍ら、セキュリティ普及啓発活動を行う。商業向け新シリーズ「こうしす!EE」にて、小説版の出版が決定し、現在鋭意執筆中。
「物語の力でIT、セキュリティをもっと面白く」をモットーに、作品制作を行っています。
オープンソースなアニメを作ろうというプロジェクト。現在はアニメ「こうしす!」を制作中。
Copyright © ITmedia, Inc. All Rights Reserved.