Column
自社の製品でセキュリティ脆弱性が報告されたら PART1
報告者は敵か味方か? パッチは間に合うのか?――脆弱性の報告でパニックを起こさないためにはどうしたらいいだろうか。
あなたが何カ月も奮闘を続け、ついにソフトをリリースしたとしよう。
ところが、誰かがあなたの会社に連絡してきて、脆弱性が見つかったと告げる。あなたはどうするだろうか。
「理想的な世界では、脆弱性は必ず報告され、その検証と修正が行われ、コードのQA作業やテストを経てアップデートプログラムがリリースされる。そして顧客は安心し、満足する」とマカフィーの主席セキュリティアーキテクト、デビッド・コフィー氏は、ボルティモアで開催されたSoftware Security Summitでの講演で語った。
「だが、理想とは程遠い現実の世界では、脆弱性は、可能な場合には報告されるが、無視されたり、不適切に処理されたりし、そうした中で発見者が実証コードを公開して、顧客は不安と不満を抱えてしまう。ソフトのベンダーの株主、従業員、経営陣も同様だ」とコフィー氏は述べた。
製品のリリース後に発見された脆弱性に対処する上で重要なのは、その報告を受けた場合に取るべきステップを知っておくことだ、とコフィー氏は説明した。
あなたが何カ月も奮闘を続け、ついにソフトをリリースしたとしよう。万全の準備をした自信があり、ソフトはうまく機能していてまったく安全だ。ハッキングすることなど絶対にできない。
ところが、誰かがあなたの会社に連絡してきて、脆弱性が見つかったと告げる。あなたはどうするだろうか。
「理想的な世界では、脆弱性は必ず報告され、その検証と修正が行われ、コードのQA作業(品質管理作業)やテストを経てアップデートプログラムがリリースされる。そして顧客は安心し、満足する」とマカフィーの主席セキュリティアーキテクト、デビッド・コフィー氏は、ボルティモアで開催されたSoftware Security Summitでの講演で語った。
「だが、理想とは程遠い現実の世界では、脆弱性は、可能な場合には報告されるが、無視されたり、不適切に処理されたりし、そうした中で発見者が実証コードを公開して、顧客は不安と不満を抱えてしまう。ソフトのベンダーの株主、従業員、経営陣も同様だ」とコフィー氏は述べた。
最悪の場合には、脆弱性が見つかるやいなや、発見者がただちに実証コードを公開し、ソフトベンダーは対処する準備ができない、とコフィー氏は付け加えた。
製品のリリース後に発見された脆弱性に対処する上で重要なのは、その報告を受けた場合に取るべきステップを知っておくことだ、とコフィー氏は説明した。
「脆弱性が見つかったら、それを適切に分類すれば、どう対応すべきかが分かるようにしておかなければならない」と同氏。「対応プロセスが明確になっていれば、誰もパニックにならない」
コフィー氏によると、そのプロセスは、誰が問題を報告したかなどによって違ってくる。例えば、従業員や、会社が雇っているセキュリティコンサルタントなど、内部者が発見する場合がある。こうした人々は一般に信頼できる。問題を発見して報告することは彼らの仕事の一部であり、彼らは会社と契約している。また、彼らは脆弱性を探そうという意欲を持っている。好奇心旺盛で、ほかの開発者の先を行こうとしており、脆弱性をすべて見つけて取り除くことを自分の任務と考えているからだ。
だが、1つ注意しなければならないのは、不満を持った従業員が脆弱性を発見した場合だ。彼らは動機に問題があるからだとコフィー氏は語った。
発見者が外部の場合はさらにリスクが大きい。例えば、セキュリティ研究者やビジネスパートナー、技術知識が豊富なエンドユーザーなどが発見者となる可能性がある。こうした発見者がどの程度信頼できるか、その動機は何かが分からないのが不安材料だ。お金や名声が目当てなのか、好奇心が強いだけなのか、何らかの任務を負っているのか、あなたの会社に打撃を与えたいのか――。
「たいていの場合、こうした発見者は善意で行動している。彼らは役に立ちたいと考えている」とコフィー氏。だが、そうではない人々の存在も念頭に置く必要があるという。
完全公開か、責任ある公開か
また、発見者がどのような情報公開を考えているかも考慮に入れなければならない。発見者が完全公開を掲げて、「製品の脆弱性について分かっている情報をすべて公開する」と言ってくる場合がある。これは、情報が完全に公開されるとなれば、企業はより迅速に不具合を修正するだろうという理屈によるものだ、とコフィー氏は語った。
こうした発見者は、ハッカーが作った一連のガイドラインに沿った対応を企業に求める。それは、「企業は報告に対し、5日以内に回答する」「企業は不具合の公表の仕方を発見者と調整する」「企業は不具合が見つかったことの功績を全面的に発見者に帰する」「企業への不具合の報告から情報公開までの期間は30日とする」といったものだ。
「このことは、こうした人々が開発プロセスを知らないことを示していると思う」とコフィー氏。「ほとんどの企業にとって、30日以内にパッチを開発するのは非常に困難だ」
一方、責任ある情報公開というやり方もある。これは完全公開と似ているが、企業が不具合情報の公表を要求されない、スケジュールが柔軟に設定される、発見者が、修正プログラムが用意されてから情報公開を行う、という点が異なっている。
この続き(脆弱性報告への対処、情報公開のステップなど)は7月25日に掲載の予定です。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
4
「IBM iはDXのボトルネック」は誤解 意外と知らない今風モダナイズの効果
-
5
「朝8時にバッチが終わらない」データ爆発の危機をJPX総研はどう乗り越えたか
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
7
AI導入後に発覚する「社内文書を読めない」問題 情シスは何を直せばいい?
-
8
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
-
9
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
10
「Wi-Fi」は“ネット接続が不十分”な地域の救世主になるのか?
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
プログラミング不要で誰でも実現できる、ネットワーク運用管理の自動化とは
-
5
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
6
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
9
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
10
“あのファイル転送”で暗躍するノーウェアランサム
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー