アカウント名:
パスワード:
いくらベンダーが無視できるリスクと判断したとはいえ、ゼロデイ脆弱性を生み出すことになりかねないと思うのですが、こういうのを見つけ出す人にとっては、誰かがひどい目に遭うリスクよりも功名心のほうが上なんでしょうか…。
脆弱性が一定の猶予期間の後に公表される仕組みが無い場合、公にバレるまで修正しなくても良いと言う事になってしまうので潜在的なリスクが高まります。脆弱性が公にならなくても闇市場で未公開の脆弱性情報が取引される可能性があり、サイバーテロ、あるいはサイバー戦争の温床になりますので脆弱性は速やかに修正され、公表される事が望ましいのです。
閾値というか「やるやる詐欺」の問題もあるから難しいけど、「開発元が修正しようとしてるけど、影響調査やパッチ配布のサイクルに間に合わない」場合は、少し公開を延期するシステムは必要だと思うんだよね。
脆弱性の対策はユーザー保護のためなんだから、ユーザーを危険に晒すやり方は最小限になるよう配慮されるべきだと思う。
少し延期して、結局修正前に開示される事例が出ることに変わりはない。それに脆弱性は製品のリリース時には生まれているわけだから、ブラックマーケットで取引されていれば、少し延ばすことがユーザーを救うとは限らない。
少し公開を延期するシステムは必要だと思うんだよね。
「少し」の定義を教えてください。120日待ってるけどまだ足りない？ユーザー保護を優先させるなら絶対間に合いますよね。修正の優先度がおかしかったとしか思えない。
いや、MicrosoftのJetなんて、もう20年以上前にルーツができて、広範囲で使われてる技術だから。影響範囲の調査や、後方互換への検証を考えたら、120日はかなり厳しいでしょ……
# ユーザー保護と気楽に言うが、修正で不具合や互換性問題が出たら結局困るのはユーザーだし
いくら膨大なOSに絡むような物でも「本気」で取り組めば120日もかかるはずはないよ。MSはその辺の中小企業じゃないんだから。潤沢な資金と優秀な技術者を湯水の如く使えばすぐに終わる。ようは、そう使ってないってだけのこと。つまりはその程度の脆弱性って事。本当に全世界クラスのやばい脆弱性なら本気で取り組むさ。それこそ互換性なんて気にせずにな。
人月の神話とか読んだ方が良いのではないでしょうか人を増やせばなんでも解決できると考えるのはだめなマネージャーの典型
費用対効果も危険性も無視して何でもかんでも本気出すわけはないし。外部の大口ユーザーの利用状況確認なんかもあるから「マイクロソフト側の努力だけでは」どうにもならない部分もあるのに。
具体的な方策もなしに妄想で語っちゃっても説得力ないよ？
>MSはその辺の中小企業じゃないんだから。>潤沢な資金と優秀な技術者を湯水の如く使えばすぐに終わる。
なかなかの釣り針ですねぇ 笑さすがに、そんなでかい釣り針にひっかかるやつが・・・
いた・・・
マイクロソフトが費用対効果を鑑みて脆弱性の修正を遅らせたというなら、それは「一ヶ月くらい放置しても問題ない程度の危険性の低い脆弱性だ」と判断したってことでしょ。親コメントと何も矛盾してないじゃないか。どこが妄想なんだい？
働いたことない人の拙い批判なんで勘弁してやってください
功名心だけでなく、利用者の安全のためにも公開が必要なんですよ。自分が見つけられたのだからクラッカーも(既に)見つけている可能性がある。だから修正パッチがあるなら適用すべきだけと、無いなら製品の利用を控えるなどの運用面での対策が必要になる。
運用面での対策は情報が届かなかった利用者には効果がないが、アンテナを張っている利用者の危険を減らすことが出来る。修正パッチは運用面での対策よりも広い対象に効果があり、デメリットの有る運用面での対策を必要としなくなる。すでに脆弱性が悪用されている可能性がある以上、どちらかの対策は一定日数内に実施される事
究極的には、半端なルールによって一部界隈でのみ脆弱性情報が流通する状態よりは全世界平等に公開されてしまった方が大概マシ、という事だと思う。過渡期のインパクトは大きい場合もあるが、綻びが正される方向に流れるのは間違いない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
脆弱性をわざわざ公開するやり方って (スコア:0)
いくらベンダーが無視できるリスクと判断したとはいえ、ゼロデイ脆弱性を生み出すことになりかねないと思うのですが、こういうのを見つけ出す人にとっては、誰かがひどい目に遭うリスクよりも功名心のほうが上なんでしょうか…。
Re:脆弱性をわざわざ公開するやり方って (スコア:1)
・製品の欠陥を公表して、利用者に注意を呼びかけ、製造者には修理を迫る。
と考えれば、公益告知かと。それに大企業ってのは不都合や悪事を隠すってイメージがあるから、しょうがないかと（笑）
ただ、上記はあくまで一般的な製品にあてはまって、ソフトウェア製品になると攻撃者という存在があるのでややこしい。
一般的な製品は公表の利益があるが、ソフトウェア製品の場合は公表には不利益がある。すなわち攻撃者を有利にする。
基本的に脆弱性情報の公開は攻撃者を利し利用者の害になる。かと言って非公開をとすれば、セキュア・プログラミングが普及しないため、攻撃者有利な環境がはびこる。一般製品を例にすれば、設計ミス（製品事故）を非公開とすれば、安全な製品設計につながらない。製品事故を告発することで、安全な製品設計を牽引する。同様に、セキュアな設計とプログラミングを牽引するためには脆弱性情報の公開は必要であり、それによって利用者の利益にもなる。
・ソフトウェア製品において、脆弱性情報公開は利用者の害にも利益にもなるわけだ。
答えが単純な問題じゃなく、矛盾した答えになる問題だから、「単純な答え」を求めちゃあいけない。「矛盾した答え」を受け入れてください。
Re: (スコア:0)
脆弱性が一定の猶予期間の後に公表される仕組みが無い場合、公にバレるまで修正しなくても良いと言う事になってしまうので潜在的なリスクが高まります。
脆弱性が公にならなくても闇市場で未公開の脆弱性情報が取引される可能性があり、サイバーテロ、あるいはサイバー戦争の温床になりますので脆弱性は速やかに修正され、公表される事が望ましいのです。
Re: (スコア:0)
閾値というか「やるやる詐欺」の問題もあるから難しいけど、「開発元が修正しようとしてるけど、影響調査やパッチ配布のサイクルに間に合わない」場合は、少し公開を延期するシステムは必要だと思うんだよね。
脆弱性の対策はユーザー保護のためなんだから、ユーザーを危険に晒すやり方は最小限になるよう配慮されるべきだと思う。
Re: (スコア:0)
少し延期して、結局修正前に開示される事例が出ることに変わりはない。
それに脆弱性は製品のリリース時には生まれているわけだから、ブラックマーケットで取引されていれば、少し延ばすことがユーザーを救うとは限らない。
Re: (スコア:0)
少し公開を延期するシステムは必要だと思うんだよね。
「少し」の定義を教えてください。120日待ってるけどまだ足りない？
ユーザー保護を優先させるなら絶対間に合いますよね。
修正の優先度がおかしかったとしか思えない。
Re: (スコア:0)
いや、MicrosoftのJetなんて、もう20年以上前にルーツができて、広範囲で使われてる技術だから。
影響範囲の調査や、後方互換への検証を考えたら、120日はかなり厳しいでしょ……
# ユーザー保護と気楽に言うが、修正で不具合や互換性問題が出たら結局困るのはユーザーだし
Re: (スコア:0)
いくら膨大なOSに絡むような物でも
「本気」で取り組めば120日もかかるはずはないよ。
MSはその辺の中小企業じゃないんだから。
潤沢な資金と優秀な技術者を湯水の如く使えばすぐに終わる。
ようは、そう使ってないってだけのこと。
つまりはその程度の脆弱性って事。
本当に全世界クラスのやばい脆弱性なら本気で取り組むさ。
それこそ互換性なんて気にせずにな。
Re:脆弱性をわざわざ公開するやり方って (スコア:1)
人月の神話とか読んだ方が良いのではないでしょうか
人を増やせばなんでも解決できると考えるのはだめなマネージャーの典型
Re: (スコア:0)
費用対効果も危険性も無視して何でもかんでも本気出すわけはないし。
外部の大口ユーザーの利用状況確認なんかもあるから「マイクロソフト側の努力だけでは」どうにもならない部分もあるのに。
具体的な方策もなしに妄想で語っちゃっても説得力ないよ？
Re: (スコア:0)
>MSはその辺の中小企業じゃないんだから。
>潤沢な資金と優秀な技術者を湯水の如く使えばすぐに終わる。
なかなかの釣り針ですねぇ 笑
さすがに、そんなでかい釣り針にひっかかるやつが・・・
いた・・・
Re: (スコア:0)
マイクロソフトが費用対効果を鑑みて脆弱性の修正を遅らせたというなら、それは「一ヶ月くらい放置しても問題ない程度の危険性の低い脆弱性だ」と判断したってことでしょ。親コメントと何も矛盾してないじゃないか。どこが妄想なんだい？
Re: (スコア:0)
投入人員数と生産量が比例するよう環境をコントロールするのがマネージャーの仕事ってことだ
Re: (スコア:0)
働いたことない人の拙い批判なんで勘弁してやってください
Re:脆弱性をわざわざ公開するやり方って (スコア:1)
「本気」とか「やる気」とかを批判材料にするのは、能力の限界、資源制約という概念で物事を評価しない人なだけかと。
政治家だって、数字を駆使して計算し、計画を立てている様には見えないこともあるわけだし。
働いている人でも、本気、やる気を語る人は、広告塔には使えても、管理には使えないし、任せてはいけないと思うわけで。
（日本軍と同様の結果になってしまう。やる気があれば飲まず食わずで戦える。何そのやる気補正、という妄想設定。多分、漫画と現実の境界がおかしくなったんだろうね。まあ、多少経験があるから分かる。思考のベースが漫画的になるといえば分かりやすいかな。あるいは、人物評価の基準がマナーに偏るとか。）
多分、ここいらの住人は、「マナー」「態度」「やる気」で批判され、「リソース」で批判返しすることが日常なんでしょう。それでも出世するのがやる気派で苦労しているんだろう。
Re:脆弱性をわざわざ公開するやり方って (スコア:1)
その「優秀な技術者」を持ってして出来上がったのが、この様でございますなんですよね。（涙）
今風なタイトルにすると
「システム開発の過酷さ現実に咽び泣く優秀な技術者」
「プロジェクト成功で鼻高々な技術者、次期プロジェクトに夢と機能を詰め込み過ぎて息絶える」
「万能ツール・フレームワーク・言語を求めて騙され続ける優秀な技術者、いつになったら広告詐欺に気づく？」
Re: (スコア:0)
功名心だけでなく、利用者の安全のためにも公開が必要なんですよ。
自分が見つけられたのだからクラッカーも(既に)見つけている可能性がある。
だから修正パッチがあるなら適用すべきだけと、無いなら製品の利用を控えるなどの運用面での対策が必要になる。
運用面での対策は情報が届かなかった利用者には効果がないが、アンテナを張っている利用者の危険を減らすことが出来る。
修正パッチは運用面での対策よりも広い対象に効果があり、デメリットの有る運用面での対策を必要としなくなる。
すでに脆弱性が悪用されている可能性がある以上、どちらかの対策は一定日数内に実施される事
Re: (スコア:0)
究極的には、半端なルールによって一部界隈でのみ脆弱性情報が流通する状態よりは全世界平等に公開されてしまった方が大概マシ、という事だと思う。
過渡期のインパクトは大きい場合もあるが、綻びが正される方向に流れるのは間違いない。