脆弱性を速やかに公表しない輩は、わたくしが成敗いたしますわ！：こうしす！ こちら京姫鉄道 広報部システム課 ＠IT支線（53）
情報セキュリティの啓発を目指した、技術系コメディー自主制作アニメ「こうしす！」の＠ITバージョン。第53列車は「脆弱性を発見したときの対処法 続編」です。※このマンガはフィクションです。
「こうしす！」とは
ここは姫路と京都を結ぶ中堅私鉄、京姫鉄道株式会社。
その情報システム（鉄道システムを除く）の管理を一手に引き受ける広報部システム課は、いつもセキュリティトラブルにてんてこ舞い。うわーん、アカネちゃーん。
「こうしす！＠IT支線」とは
「こうしす！」制作参加スタッフが、＠IT読者にお届けするセキュリティ啓発4コマ漫画。
第53列車：少しずつ世界を良くしていくには、我慢も必要
井二かけるの追い解説
マンガのテーマは「脆弱（ぜいじゃく）性を発見したときの対処法」続編です。
以前の記事では「脆弱性を発見したときはIPAに届け出をし、早期警戒パートナーシップに基づいた対処が行われるようにすることを推奨」しました。それから数年たち、こうした窓口があることが広く知られるようになってきた一方で、対応に時間がかかるという不満があちこちで聞かれるようになりました。
そんな中、世間を騒がせることとなったのが「FeliCaの脆弱性問題」です。
ガイドラインに沿って情報が公開される前に、製品開発者の意図しないタイミングで報道があり、各社が対応に追われ、発見者が積極的に情報を提供している点が批判の的となりました。
名指しされているわけではありませんが、時期を同じくして、「お願い」が各所から発信されました。
情報セキュリティ早期警戒パートナーシップガイドラインに則した対応に関するお願い（IPA）
国内における脆弱性関連情報を取り扱う全ての皆様へ 情報セキュリティ早期警戒パートナーシップガイドラインに則した対応に関するお願い（JPCERT/CC）
国内における脆弱性関連情報を取り扱う全ての皆様へ 情報セキュリティ早期警戒パートナーシップガイドラインに則した対応に関するお願い（経済産業省）
FeliCa問題は、「公表」と「公益」のバランスの難しさを感じる事案でした。
45日は目安にすぎない
IPAの「情報セキュリティ早期警戒パートナーシップガイドライン」では、「『製品開発者への連絡』にて規定された連絡を最初に試みた日から45日後を目安」とされています。
しかし、公表日は必ずしも「45日後」となるわけではありません。
以前の記事で指摘したように、脆弱性関連情報の届け出が受理され、対応が実行されるまでには時間がかかります。
2018年10月01日 届け出
2018年11月08日 受理
2018年11月15日 調整開始（起算日）
2018年12月26日 謝辞確認
2019年03月26日 製造元よりアップデートがリリース
2019年03月27日 公表
このガイドラインを流し読みすると「45日後に公表してもいい」と誤解してしまいそうです。しかし、「起算日」は「JPCERT/CC」（JPCERTコーディネーションセンター）が「製品開発者への連絡」を「最初に試みた日」と明確に定義されている一方で、「公表日」の45日というのはあくまでも目安であり固定の日数ではないとされています。
かつては発見者が一方的に「○日以内に修正されなければ公表する」と通告する形を取ることが多くありましたが、その日数の妥当性はもちろん、脅迫と誤解されてまともに対応されない、修正が間に合わないなどの弊害が多くあったことから、発見者が一方的に期限を設定することは現実的に難しくなってきています。こうした事情から、公表時期は個別調整するようになりました。
とはいえ、上記の例でも、起算日どころか受理までに1カ月以上要しています。この「届け出から起算日までの期間」は日数にカウントされないことは、制度から抜け落ちている点だと筆者は考えています。
公表と公益のバランスの難しさ
一連の報道で、「脆弱性が修正される前に公表するのはよくない」という声も多く聞かれるようになりました。
一方でよく比較されるのが「公益通報者保護制度」です。有名な事例である食品偽装問題であれば、「食品偽装が是正される前に公表するのは悪い」という考える人は恐らくそう多くありません。
なぜなら、消費者は「その食品を食べることを避ける」という判断ができるからです。「公表によって業界に多大な悪影響が出たから、食品偽装の告発は良くないことだ」という主張に、消費者は納得しないでしょう。回避可能なリスクを放置することが、社会全体の利益にかなうとはいえないためです。
とはいえ、「使わない」という選択肢が困難なものもあります。例えば、日々の通勤に使っているICカードの場合、システムを止めることさえ事実上不可能です。公表することによって攻撃を誘発するリスクが高い場合は、対策や監視体制が整うまで公表を見送ることが公益にかなう場合もあります。
つまり、ここに公表と公益のバランスの難しさがあります。
FeliCaの脆弱性は、旧型のカードの耐タンパ性を破って取得した共通の鍵を、新型のカードでも悪用できてしまうというものだったとされています。根本的解決を目指すならば、既存のICカードを無効化し再発行するしかないのですが、そこまではできません。つまり根本対策は現実的に不可能です。
では緩和策はどうでしょうか。オンライン決済であれば残高の整合性をサーバで確認するなどの緩和策を講じられます。実際、決済各社では「システム全体の対策」が行われている旨を公表しています。
しかし、入退館の解錠システムに使用している場合はそれも困難です。「二重入場や勤務時間外の入場を防ぐ」というのが緩和策になり得ますが、根本的に最初の侵入を止めることはできません。
その意味では、公表が遅れれば遅れるほど、解錠システムの利用者は、「Type-Bを使用するよう変更する」「新たに解錠システムを導入する際にFeliCaの導入を避ける」などの選択肢を取れず、脆弱なシステムを導入してしまうという問題があります。
これは「知っていれば回避できたはずのリスク」という点で、偽装食品の例と本質は近いと言えます。従って、根本的な対策も緩和策も講じられないからといって、いつまでも秘匿することはできません。
FeliCaの脆弱性の騒動は、「入退館の解錠システムの利用者は、1日でも早く知りたい情報」であり、「決済システムの利用者は、秘匿されたままでも特に不都合はない」という、利用者同士でも利害が一致しない難しい事例だったといえるでしょう。ある意味、FeliCaがインフラとして広く普及した故の事態だったのかもしれません。
ただし、一部のスマートロックなど、カードのIDm（カード製造時に記録される固有の識別番号）のみを確認しているスマートロック製品は、今回のFeliCaの脆弱性に関係なく、もともと脆弱です。
IDmは誰でも読み出すことができますので、これのみを用いたアプリケーションは、正規カードになりすました偽造カードやカードエミュレータにより攻撃を受ける可能性があります。
FeliCa Networks モバイル FeliCa ICチップにおける製造ID（IDm）の取り扱いについて（フェリカネットワークス）
発見者の利益
そして、もう一つの視点は「発見者の利益」です。
基本的に、早期警戒パートナーシップに基づいて不具合を報告しても、報酬はありません。技術者倫理として報告することで公益、ひいては巡り巡ってわがためというのが主な利益です。
個人的利益といえば、もしかすると脆弱性情報に謝辞が載るかもしれないという程度です。しかし、制度上は最終的に公表されないことや、年単位で公表されないということもあり得ます。いつまでも秘匿されてしまえば、せっかく手間をかけて発見した脆弱性を握りつぶされたと感じてしまうかもしれません。
個人的利益だけを追求するなら、「YouTube」で再現動画を公開してSNSで騒ぐ方が名前が売れますし、不適切な市場に流通させれば短期的な利益になり得るかもしれません。早期警戒パートナーシップのルールに従わない方が圧倒的に有利となってしまえば、混沌（こんとん）とした時代に逆戻りしてしまうことでしょう。長期的には社会的な損失となります。
そこで、筆者が期待したいのは、「受理の早期化」と「受理あるいは脆弱性と確認された時点でJVN番号（ソフトウェアなどの脆弱性に対して割り振られる識別番号）を予約し、暫定CVSS（共通脆弱性評価システム）スコアと謝辞を公表する」という方法です。これであれば、発見者の利益を確保しながらも、秘匿期間を設けることによる、開発者、利用者の利益を両立させられるはずです。
結局、どうすればいいのか
とはいえ、現状はそのような制度にはなっていません。
早期警戒パートナーシップのガイドラインに従って脆弱性を報告し、もし公表するのであれば、「お願い」に言及されているように、「正当な理由がない限り脆弱性関連情報を第三者に開示せず、正当な理由により開示が必要である場合も事前にIPAに相談する」ことが、現状のベストといえます。
なるべく脆弱性が早期に修正されるために筆者が実践しているのは、「製品開発者とIPAの両方に連絡する」という方法です。早期警戒パートナーシップ制度では受理自体に時間がかかってしまうため、そのタイムロスを避けるためにも直接連絡するということです。その上で、同時に、あるいは反応がない場合にIPAにも届け出るという形であれば、脆弱性がより早期に解決される可能性が高まります。
いずれにしても、大切なことは公益の最大化です。
しかし、自分だけで考えていれば、独り善がりな判断を下してしまうリスクがあります。いろいろ欠点はあれども、こうした制度がどのような目的で作られ、運用されているかを理解した上で、活用していくことが大切でしょう。
Copyright 2012-2025 OPAP-JP contributors.
本作品は特に注記がない限りCC-BY 4.0の下にご利用いただけます
筆者プロフィール
作画：るみあ
フリーイラストレーター。アニメ「こうしす！」ではキャラクターデザイン・キャラ作画担当をしています。
原作：井二かける
アニメ「こうしす！」監督、脚本。情報処理安全確保支援士。プログラマーの本業の傍ら、セキュリティ普及啓発活動を行う。
著書：「こうしす！社内SE 祝園アカネの情報セキュリティ事件簿」（翔泳社）、「ハックしないで監査役!! 小説こうしす!EEシリーズ 元社内SE祝園アカネ 監査役編 [1]」（京姫鉄道出版）
映画：「こうしす！EE 総集編映画版」
- X（Twitter）：@k_ibuta
解説：京姫鉄道
「物語の力でIT、セキュリティをもっと面白く」をモットーに、作品制作を行っています。
原作：OPAP-JP contributors
オープンソースなアニメを作ろうというプロジェクト。現在はアニメ「こうしす！」を制作中。
- X（Twitter）：@opap_jp、@kosys_pr
- 公式サイト：Open Process Animation Project Japan（OPAP-JP）
- 貢献者一覧：こうしす！/クレジット
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
アカネちゃん、JVNに謝辞が載る
情報セキュリティの啓発を目指した、技術系コメディー自主制作アニメ「こうしす！」の＠ITバージョン。第17列車は「もしも脆弱性を発見したら」です。※このマンガはフィクションです。
社内SEの忠告もぺいっ！
情報セキュリティの啓発を目指した、技術系コメディー自主制作アニメ「こうしす！」の＠ITバージョン。第14列車は「エンジニアの職業倫理」です。※このマンガはフィクションです。
「『一回転』でググれ」と言ったら、逮捕されますか？
情報セキュリティの啓発を目指した、技術系コメディー自主制作アニメ「こうしす！」の＠ITバージョン。第13列車は「不正指令電磁的記録供用罪」です。※このマンガはフィクションです。実際の法解釈や法運用とは異なります