IPA「脆弱性届出制度に関する説明会」が開催されました。

そこで、この制度の利用者(？)の方から、いろいろな感想が「つぶやかれています」。この点については、「脆弱性届け出制度に関する説明会のつぶやきまとめ」でまとめられています。

私(高橋郁夫)個人としては、いわゆる「中の人」になりますので、具体的なこの制度の変更にいたった議論の経緯その他についてコメントすることは避けます。

ただし、この制度について、常にウワォッチし、あるべき制度を考えていた一法律家としてのコメントをさせていただければ、以下のとおりになるかと思います。

まずは、この制度が構築されたのが、2002-2003年の時期であったということは、さけて通ることができないと思います。その当時までに、時計を巻き戻してみましょう。

研究者・実務家の方が、脆弱性を見つけた、それを企業に対して、これ、脆弱性になるから直したらいいんじゃないの？と届けたときにどうなっていたでしょうか。

多分、何か、脅迫・恐喝つもりなのですか？という態度で開発者がまともにとなりあわないということになっていたのではないでしょうか。

(その端境期において、「脆弱性に警鐘？」という報道がされた事件もありました)

理屈から考えると、脆弱性が少ないこと、もし、見つかった場合には、真剣に、その届出に対応してもらって、できるかぎり、脆弱性のないソフトウエアを提供しましょう、というのが望ましいというのは、誰もが、合意してもらえるかと思います。しかしながら、現実は、「絶望的なぐらいに」そのありうべき姿と乖離していたのです。

その姿に対して、METIのTY氏などを中心に、ちょっと調査しませんかねえ、ということになったのが、

『セキュリティホールに関する法律の諸外国調査』 報告書になります。

もう、この段階において「責任ある開示」という概念を中心にして、どのようにして脆弱性の報告をとりあつかうべきかということが議論されていたのがわかるかと思います。

そして、実際に、IPA/JPCERT/CCにおいて早期警戒パートナーシップの構築にいたっていくわけです(2003年10月頃から2004年3月まで)。

この部分の仕組みについての報告書としては、「情報システム等の脆弱性情報の取扱いに おける法律面の調査 報告書 」になります。

「脆弱性」に対する基本的なスタンスということになりますが、この報告書をよんでいただけると、脆弱性の報告書については、まさに「責任ある開示」のスタンスを積極的に採用し、その意味で、そのスタンスがどこまで、実際のセキュリティのコミュニティで支持されるのか、まずは、やってみましょう、というものであったのがわかるかと思います。

望外なことに、この脆弱性の早期警戒パートナーシップは、わが国において、非常に、共感をもって受け入れられました。報告数は、着実に増えていきましたし、また、特に、実際の研究者・実務家の方々が、脆弱性を発見したら、まずは、この早期警戒パートナーシップの枠組みで報告しましょうと考えるにいたったように感じられたのは、非常に、ありがたく思えます。

また、この制度の考えていたことは、世界的にも、早期的なチャレンジに成功したものであったということは、特筆すべきものであったように思えます。

脆弱性情報の取り扱いについては、

ベンダ内部における脆弱性取扱手順については、「ISO/IEC 30111:2013 Information technology — Security techniques — Vulnerability handling processes」

第三者によって発見された場合の脆弱性開示については、「ISO/IEC 29147:2014 Information technology — Security techniques — Vulnerability disclosure」

が制定、公表されているのに至ったというのは、私たちのチャレンジが、世界的にみて、先進的な試みであって、また、そのチャレンジを成功させた日本のセキュリティコミュニティに対する極めて高い評価であったということもできるのではないかとおもいます。私たちは、この試みとこの結果を誇りに思っていいとおもいます。

ただし、この仕組みは、如何せん、

きわめて広範な「脆弱性」の定義に該当するものについて、その重要性についてなんら評価をせずにすべて「脆弱性」の有無を調査化した上で、あると判断したものについて調整を図ろうとした点

で、制度としての致命的な問題点を有していたと考えるべきではないかとおもいます。

というのは、脆弱性についていえば、まさに

「ISO/IEC 30111:2013 Information technology — Security techniques — Vulnerability handling processes」

が、そのプロセスで明らかにするように、

ベンダは、CSIRT／PSIRTのような仕組みを設けて、その製品について、脆弱性が見つかった場合には、そのような仕組みが、脆弱性に対して対応するのが、まさに標準である

という思考を前提に構築されているものです。

現代社会においてあるべき姿を考えるときに、ベンダ(開発者)がみずからの責任であって、セキュリティ的にも問題がないソフトウエアを開発して、その態度等が、ソフトウエアの性能と評価されて、市場において、もし、そのような態度にかけるソフトウエアがあれば、そのようにソフトウエアは、市場から、退出を迫られるという姿

を前提としているように思えますし、また、そうであるべきかとおもいます。

そもそも、IPAないしJPCERT/CCのリソースといえども、有限なわけで、そのリソースを、「広範な脆弱性」の定義に該当する場合に、「脆弱性というのは、攻撃者が悪用するものであって、その攻撃によって発生する問題点の重要性を事前に評価することはできない」という理屈でもって、ふんだんに使っていいということにはならないと考えます。

翻って、2017年の状況について考えてみるときに、

• 現在においては、脆弱性のもたらすセキュリティ上の脅威が社会においても許容しうるものではないという認識が一般化しつつあるかとおもいます。
• 開発者が、積極的に、脆弱性の届出受け付けの窓口をもうけるようになってきている。
• 特に、バグバウンティ制度を導入する企業も増加している

などの事情を考えたときに

制度が構築された時期と比較して、セキュリティの重要性の認識／脆弱性解消の努力の正当な評価という観点からするとき、非常に良い方向に進展していると評価することができるのではないか、と個人的に考えます。

そうだとすると、もはや、脆弱性に関する認知が社会的に全く足りないので、それを、かなり「父権的な(パターナリスティックな)」制度でもって、脆弱性を消滅させる、そのために、IPAやJPCERT がなんでも/かんでも、脆弱性について、関与するというのをやめて、

社会的に、IPAやJPCERT が、関与するのが、許容されるような重要度の高いものに限って関与する

という制度にすべき

なのではないか、と考えます。そして、私としては、そのような考え方に基づいているのが、今回の制度改変なのではないか

と考えます。

確かに、いままでの、「脆弱性」について、これを発見したのであれば、IPAに届出て、これを前提として脆弱性の認定がなされて、調整がなされるという制度が当然であるという考えを前提とするのであれは、どういう改正なのか

という思いが生じるのは、わからないでもないです。ただし、そもそも、開発者が対応すべき「脆弱性」に対して、IPA/JPCERT/CCがリソースを避くことが当然であるという考え方のほうが、今となっては、あるべき姿からは遠ざかっているというように考えます。

むしろ、一定のスタンスを押し出して、脆弱性の対応については、「開発者」がなすべき重要な責務であるという大原則を前提とした制度にしたほうが、結果としては、更に日本におけるセキュリティ・コミュニティの成熟をみれるような気がします。

どうでしょうか。私としては、このチャレンジの結果は、むしろ、開発者さんにおいて、どれだけ私たちのメッセージをきちんと受け止めるかにかかっているかとおもいます。このチャレンジも成功することを期待しています。