Column
自社の製品でセキュリティ脆弱性が報告されたら PART1
報告者は敵か味方か? パッチは間に合うのか?――脆弱性の報告でパニックを起こさないためにはどうしたらいいだろうか。
あなたが何カ月も奮闘を続け、ついにソフトをリリースしたとしよう。
ところが、誰かがあなたの会社に連絡してきて、脆弱性が見つかったと告げる。あなたはどうするだろうか。
「理想的な世界では、脆弱性は必ず報告され、その検証と修正が行われ、コードのQA作業やテストを経てアップデートプログラムがリリースされる。そして顧客は安心し、満足する」とマカフィーの主席セキュリティアーキテクト、デビッド・コフィー氏は、ボルティモアで開催されたSoftware Security Summitでの講演で語った。
「だが、理想とは程遠い現実の世界では、脆弱性は、可能な場合には報告されるが、無視されたり、不適切に処理されたりし、そうした中で発見者が実証コードを公開して、顧客は不安と不満を抱えてしまう。ソフトのベンダーの株主、従業員、経営陣も同様だ」とコフィー氏は述べた。
製品のリリース後に発見された脆弱性に対処する上で重要なのは、その報告を受けた場合に取るべきステップを知っておくことだ、とコフィー氏は説明した。
あなたが何カ月も奮闘を続け、ついにソフトをリリースしたとしよう。万全の準備をした自信があり、ソフトはうまく機能していてまったく安全だ。ハッキングすることなど絶対にできない。
ところが、誰かがあなたの会社に連絡してきて、脆弱性が見つかったと告げる。あなたはどうするだろうか。
「理想的な世界では、脆弱性は必ず報告され、その検証と修正が行われ、コードのQA作業(品質管理作業)やテストを経てアップデートプログラムがリリースされる。そして顧客は安心し、満足する」とマカフィーの主席セキュリティアーキテクト、デビッド・コフィー氏は、ボルティモアで開催されたSoftware Security Summitでの講演で語った。
「だが、理想とは程遠い現実の世界では、脆弱性は、可能な場合には報告されるが、無視されたり、不適切に処理されたりし、そうした中で発見者が実証コードを公開して、顧客は不安と不満を抱えてしまう。ソフトのベンダーの株主、従業員、経営陣も同様だ」とコフィー氏は述べた。
最悪の場合には、脆弱性が見つかるやいなや、発見者がただちに実証コードを公開し、ソフトベンダーは対処する準備ができない、とコフィー氏は付け加えた。
製品のリリース後に発見された脆弱性に対処する上で重要なのは、その報告を受けた場合に取るべきステップを知っておくことだ、とコフィー氏は説明した。
「脆弱性が見つかったら、それを適切に分類すれば、どう対応すべきかが分かるようにしておかなければならない」と同氏。「対応プロセスが明確になっていれば、誰もパニックにならない」
コフィー氏によると、そのプロセスは、誰が問題を報告したかなどによって違ってくる。例えば、従業員や、会社が雇っているセキュリティコンサルタントなど、内部者が発見する場合がある。こうした人々は一般に信頼できる。問題を発見して報告することは彼らの仕事の一部であり、彼らは会社と契約している。また、彼らは脆弱性を探そうという意欲を持っている。好奇心旺盛で、ほかの開発者の先を行こうとしており、脆弱性をすべて見つけて取り除くことを自分の任務と考えているからだ。
だが、1つ注意しなければならないのは、不満を持った従業員が脆弱性を発見した場合だ。彼らは動機に問題があるからだとコフィー氏は語った。
発見者が外部の場合はさらにリスクが大きい。例えば、セキュリティ研究者やビジネスパートナー、技術知識が豊富なエンドユーザーなどが発見者となる可能性がある。こうした発見者がどの程度信頼できるか、その動機は何かが分からないのが不安材料だ。お金や名声が目当てなのか、好奇心が強いだけなのか、何らかの任務を負っているのか、あなたの会社に打撃を与えたいのか――。
「たいていの場合、こうした発見者は善意で行動している。彼らは役に立ちたいと考えている」とコフィー氏。だが、そうではない人々の存在も念頭に置く必要があるという。
完全公開か、責任ある公開か
また、発見者がどのような情報公開を考えているかも考慮に入れなければならない。発見者が完全公開を掲げて、「製品の脆弱性について分かっている情報をすべて公開する」と言ってくる場合がある。これは、情報が完全に公開されるとなれば、企業はより迅速に不具合を修正するだろうという理屈によるものだ、とコフィー氏は語った。
こうした発見者は、ハッカーが作った一連のガイドラインに沿った対応を企業に求める。それは、「企業は報告に対し、5日以内に回答する」「企業は不具合の公表の仕方を発見者と調整する」「企業は不具合が見つかったことの功績を全面的に発見者に帰する」「企業への不具合の報告から情報公開までの期間は30日とする」といったものだ。
「このことは、こうした人々が開発プロセスを知らないことを示していると思う」とコフィー氏。「ほとんどの企業にとって、30日以内にパッチを開発するのは非常に困難だ」
一方、責任ある情報公開というやり方もある。これは完全公開と似ているが、企業が不具合情報の公表を要求されない、スケジュールが柔軟に設定される、発見者が、修正プログラムが用意されてから情報公開を行う、という点が異なっている。
この続き(脆弱性報告への対処、情報公開のステップなど)は7月25日に掲載の予定です。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
新着ホワイトペーパー PR
-
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は? 先行企業の導入事例3選 -
技術文書・技術解説
[日本オラクル株式会社] 無自覚なリスク 秘伝Excelファイルが監査の壁、不正・ミスの温床となる理由 -
製品資料
[日本オラクル株式会社] 戦略的経理の第一歩 失敗のない「脱Excel」を実現する秘訣とは? -
技術文書・技術解説
[日本オラクル株式会社] いまさら聞けないオンプレERPとクラウドERPの違い 最適な製品をどう見極める? -
事例
[株式会社ビザスク] 連結売上高が約2倍に成長、富士フイルムが実践した新規事業創出の戦略とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
3
年収700万超エンジニアに共通するスキルと「もっと勉強すべきだった分野」
-
4
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
5
クラウド資格コレクターは評価されない? 年収1000万を分ける“OSの理解度”
-
6
脱VMwareか、継続か? 仮想化ソフト主要6製品の機能とスペックを徹底比較
-
7
JSONをやめてPythonで送る トークン消費を約7割抑えるAIの設計
-
8
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
-
9
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
10
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー