「責任ある開示」ガイドラインへの模索 20
ストーリー by Oliver
でっきるかっな～♪ 部門より
でっきるかっな～♪ 部門より
k3c 曰く、 "ZDnetの記事によれば、マイクロソフトなどソフトウェアメーカー各社とセキュリティ企業数社が、RSA Conference 2002会場で、脆弱性情報の「責任ある開示」のガイドラインを策定する団体、「Organization for Internet Safety」（OIS）の詳細を決めるための話し合いを行ったそうです。折りしも先日、その名も"Responsible Vulnerability Disclosure Process"なるInternet Draftが提案されています。この2つの動きが連動していくのか、それとも独立した2つの動きとなるのか…いずれにしても、脆弱性でまず被害を被ることになるユーザーの利益を守るという「責任」を果たす形で結実して欲しいものです。"
マイクロソフトが存在する限り (スコア:3, 興味深い)
なんて言っている所が自分の都合だけを押し付けていている理由になってはいないか。
マイクロソフトの言い分は沢山あるバグ [zdnet.co.jp]（仕様 [asahi-net.or.jp]）が公開 [cnet.com]されると
狙われ [sala.or.jp]やすく被害が拡大する [ipa.go.jp]というが、それは自分のシェアが減る事 [zdnet.co.jp]が嫌なだけ
更にバグ [cnet.com]がばれると修正箇所 [zdnet.co.jp]が増える。逆にバグがないと信頼が上がるが逆にユーザは
満足し買わなくなるだろう。
そう、常に儲かって [sphere.ne.jp]、しかもユーザはバージョンアップすると治るのではないかという
淡い期待を逆手にとって儲けているだけの限り無く黒 [asahi-net.or.jp]に近いグレー会社 [asahi-net.or.jp]、
それがマイクロソフトである。
マイクロソフトの狙いは何か、一企業ならその範囲で儲けるわけだがそれは景気に左右される
ＭＳが狙っているのは行政のような存在になる事、つまり人々が国へ税金を納めたりするように
ＭＳもどんな時でも安定してお金が流れる仕組みをあらゆる [zdnet.co.jp] 手段 [zdnet.co.jp]を使って
構築しようとしている。
今回行われるRSA Conference 2002でマイクロソフトの意見が通るならそれは
それはユーザの負けではないだろうか？
Re:マイクロソフトが存在する限り (スコア:1)
限りなくグレーに近い黒い会社の間違いじゃなくて？
責任？ (スコア:2, 興味深い)
メンバーもルールもまだ定まっていないようですが、ユーザの見解を代表してくれるメンバが欲しいところです。
でないと虫や安全穴のことを「仕様」とかいって逃れても、あるいは対策できるまで（そして対策とるのはサボって）秘密にしても「責任ある」ってことに･･･なりかねないような気がするのですが。
/.configure;oddmake;oddmake install
補足 (スコア:2, 参考になる)
で、そのInternet Draftを読んだのですが、Reporterが（必要に応じてCoordinatorの助けを借りながら）Vendorと協調してvulnerabilityの解決に努力する、その仲立ちとして、名のある団体（セキュリティ企業、ということになるのでしょうか…？）が両者と連絡を密接に取りあう。という構図が描かれています。
詳しいことは実物を読んでもらうしかないですが、三者ともそれぞれに果たすべき役割がかなり明確にされており、例えばReporterがVendorに報告したらVendorは7日以内にReceiptを返さなければいけない、Vendorは報告後30日以内にPatchやWorkaroundを提供する、間に合わない場合は期限の延長や部分的な情報公開の内容についてReporterやCoordinatorと話し合う…など、かなり具体的かつ詳細です。
個人的には、という一文が心強いと思いました。最近特に、パッチと脆弱性情報が公開されるや否やその脆弱性をついたウイルスが流行する…ということが何度かありましたよね。
今後、話し合いの場に企業以外のセキュリティ活動団体や著名なReporter（ってだれ？）を組み入れていけば、結構まともなものができそうな気がします。まあそれでも、声が大きいのは、例によって大企業でしょうが…。
これは意味ない (スコア:2, すばらしい洞察)
これはユーザ団体が決めるもので、業界団体が決めるものじゃない。
業界団体のできることは、せいぜいが「ガイドラインをこう作っていただけるとありがたいです」というユーザ団体に対する答申が精一杯の範囲でしょう。
なんか、この業界は昔「隙間産業」だった時代の尾っぽを引きずっているもたいね。あのころは、こんなんでもよかったよ。だって、他にわかる人がいなかったからね。でも、今は違うと思うよ。普通の産業になったんだからさ、もうちょっと大人として振る舞って欲しいと思うよ。
意味ない…ですかねぇ (スコア:1)
とお考えになる理由は何でしょうか？
ワタシは何も無いよりはあったほうがいいと思います。パッチや対処法も無いまま脆弱性の情報だけが出回ってしまうことを防ぐために、一定のガイドラインは必要だと思います。誰が作るかはあまり問題ではないような気がするのですが。逆にベンダーが作った決まりであればベンダーはそれに縛られますから、ある程度きちんとしたモノができればユーザーにとっても状況が改善されるかもしれない。とワタシは期待したい。まだ期待に過ぎないけど。
あと、Internet Draftについては、せっかく意見を述べる機会が与えられているのだから、不足があればコメントすればいいことですよね。
何もしないベンダーを問題視するのは重要ですが、こういう動きまで「ベンダーだから」とひとくくりにしてみんな悪者扱い、というのは、ちょっとあんまりではないでしょうか。
意味ないですね(Re:意味ない…ですかねぇ) (スコア:1)
推測を述べさせてもらいます。
＃横から口はさんですみません＞Futaro氏
>> これはユーザ団体が決めるもので、業界団体が決めるものじゃない。
>
>とお考えになる理由は何でしょうか？
作成者が基準を決めるのは意味がないからではないですかね？
＃業界団体=作成者の団体、と考えてます。
少なくとも、作成者ではない第三者が基準を決めないと意味ないでしょう。
それは最低レベルの必要条件ではないですか？
＃アイディアを出すのまではいいと思いますが、それを決めるのは、メーカーが主体じゃ
＃なく、それこそ、メーカーのソフトウェア製品を使用するユーザー側でないと。
＃それと、その基準を次に変えるのは誰？ メーカーでは意味ないですよね。
＃だとすると、ユーザーが決定権を持って決めるしかないでしょう。
開示の基準がメーカーの論理だけで決まってしまうのは、言ってしまえば、
始めから、メーカーの情報開示「責任」の回避では？
＃それじゃ「責任ある情報開示」の意味を成さないと思いません？
内部での監査やチェックが意味を成さないことは、周囲を見回せばいくらでも具体例が
見つかりますし、そういうのは第三者のチェックは必須だと思うのですが・・・。
＃あまつさえ、自分で決めて公表した基準を、自分でしかけた小細工を肯定するために
＃謝罪もなく後から書き直すメーカーまでいるのですからね。
＃内部で作った基準なんて、一利はあっても、それ以外に百害をもたらしかねません。
---- redbrick
Re:意味ないですね(Re:意味ない…ですかねぇ) (スコア:2, すばらしい洞察)
監査は監査される側とする側に癒着があったら、その段階で実は全然意味をなさなくなるものだからね。ましてや基準を作るところと製品を作るところが一緒というのは、もってのほかです。
コンピュータ業界/IT業界は、こういうところが他の産業に比べてまだまだ「幼稚」と言われる所以です。こういうことは「性善説」で行くと意味がなくなる(つまり信じれば良いで、終わる)から、性悪説でやるものだからです。
Re:意味ないですね(Re:意味ない…ですかねぇ) (スコア:1)
> 始めから、メーカーの情報開示「責任」の回避では？
うーん…責任を回避しようとしているかどうかは、出てきたモノを見ないと何とも言えないのではないでしょうか。それが現実に責任回避のための言い訳でしかないような成果物であれば、ユーザー側（というか報告者側）でそんな基準に従わなければいいだけの話ですよね。そんなのはベンダー側の内規であって法律じゃないんだから。ガイドラインを作ろうとする努力自体を「意味なし」と切り捨ててしまうと、改心(?)のキッカケすら与えない結果になりはしませんかね。
Internet-Draftの方は、作ったのはセキュリティ企業（MITREと@stake）のヒトだし、読む限りは、現状よりはかなりユーザー（というかセキュリティ団体や報告者）の主張に歩み寄ったカタチになっていると思います。こういうものがInternet-Draftとして世に出ること自体、セキュリティ文化が醸成されつつあることの一つの表れではないでしょうか。と思いたい。今さらの感もあるけど。
その文書を作った企業も件の会議に参加しているのだから…というのは、甘い期待でしょうか。…そんな気もしてきたな。うーむ。
ユーザ団体に決められるのか？ (スコア:1)
ユーザ団体に決めさせろというけれど、実際に脆弱性を見つけたり、報告したり、公表した経験のある者でないと、この標準を決めるための良いアイデアは出せないでしょう。少なくとも、「意味無いね」と決めつけてれば安心できちゃうような、くちばしを開けて餌を待ってるだけのユーザでは、何の役にも立たないでしょう。
むしろどちらかといえば、ユーザ団体がすべきことは、セキュリティ企業が暴走して無責任な脆弱性の開示をしてしまう（それによってユーザに被害が生ずる）ことを避ける方向へ話を持っていくことなんですが。
それなりにコイツが機能しだすと、 (スコア:2, すばらしい洞察)
このような構図に「責任を持って参加できない」ために、脆弱点への
対策がきちんとなされない、
つまりは「信頼できないソフトウェアである」となるのが目に見えて
いるんだが、
よーするに、そういう仕組の導入なんじゃないかと。かなり難しい問題を抱えますよね、コレ。
みんつ
Re:それなりにコイツが機能しだすと、 (スコア:1)
さて、RFC に対する具体的な対案は出てくるのでしょうか？
Re:それなりにコイツが機能しだすと、 (スコア:1)
あるボランティア的ソフトウェアが、実際のところ、責任ある脆弱性対応ができないのなら、それは、信頼できないソフトウェアであることは、その通りではありませんか？
Re:それなりにコイツが機能しだすと、 (スコア:1)
単に「ユーザは与えられた仕様のソフトを使う＊のみ＊である」という理念
であれば、信頼できる・できないをその点をもって主張することもできましょうが、
そもそも内部をいじれる、フィードバックできる、という特性に対して
このスキームを強要された場合には、いらぬレッテルを貼られることに
なりはしないかと思った次第です。
みんつ
Re:それなりにコイツが機能しだすと、 (スコア:1)
フィードバックして、他のユーザの心配もするとなると、フィードバックが適切に処理されるかが、気にかかるところとなるでしょう。もし、適切にアナウンスしてくれないボランティア的プロジェクトの作品に、まずいセキュリティホールを見つけたら、どのようなことを考えさせられる羽目になるでしょうか。
そんなとき、責任ある開示についての適切なRFCがあれば、そうしたプロジェクトの人たちに何かを説得するのが、やりやすくなるのは間違いないように思えます。
画期的なこと (スコア:2)
そういった不安がある程度解消されることは確かでしょう。
Re:画期的なこと (スコア:1)
Re:画期的なこと (スコア:1)
問題は、このInternet-Draft（いつかRFCになるのでしょうか？）にcomplyしてくれるCoordinatorが現れるかどうか、ということでしょうか。その役割をセキュリティ企業が演じるつもりなのかもしれません。その場合はやっぱりカネ取るのかな…？
いつものパターンだと (スコア:1)
できあがった物は「時代遅れ」or「現状追認」になってしまう可能性も大。
うじゃうじゃ
Guninski氏の意見 (スコア:1)
じゃあどんな言葉がいいですかね…Trustworthy [srad.jp]とか？…これは別の理由で却下されそうですが（笑）言葉としては悪くないと思います。