責任ある脆弱性開示について
Tim Kadlec
2017年1月31日
0 分で読めますセキュリティの脆弱性への対処は、終わりのない戦いです。攻撃者と、攻撃を防ごうとする組織との競争でもあります。残念ながら、組織側が負けることも少なくありません。元FBI長官のRobert Muellerはこう述べています。「…企業には、ハッキングされたことのある企業と、これからハッキングされる企業の2種類しかない」
システムを守るには、アプリケーション全体を保護する必要があります。一方、攻撃者は侵入口を1つ見つけるだけで十分です。組織には先手を打つことが求められます。そのためには、コードに潜む脆弱性をどのように把握するかが重要な役割を果たします。
一見すると、問題は単純に思えます。セキュリティ上の問題を見つけたら、組織に連絡して知らせる。組織が修正すれば、皆が安心して先に進めます。しかし実際には、脆弱性の開示は長年、セキュリティ分野で最も議論の多いテーマの1つです。
リスクにさらされる期間を最小限に抑える
Bruce Schneierが広めた考え方に、「リスクにさらされる期間（window of exposure）」があります。脆弱性が悪用される危険にさらされている期間を指します。
リスクにさらされる期間は、脆弱性が本番環境に入った時点から始まります。この段階で攻撃を受けるリスクは比較的低いものです。脆弱性は存在しているものの、まだ誰にも発見されていません。
誰かが脆弱性を発見すると、リスクは高まります。その後、脆弱性が広く知られるにつれて、リスクも上昇し続けます。やがてパッチやアップグレードがリリースされます。そこからユーザーが修正を適用し始めるにつれ、リスクは徐々に低下します。ただし、修正の適用に時間がかかることは珍しくありません。
Schneierは、リスクの大きさをグラフで表す方法をよく用います。グラフの下の面積が、リスクにさらされる期間を示します。つまり、目標はこの期間を短くすることです。
そのために最善の方法は何か、という点が議論の中心です。
森で脆弱性が見つかっても、誰にもハッキングされなければ、それは存在したと言えるのでしょうか？
脆弱性を発見したら組織に報告し、公表は決してしないべきだ、という主張があります。この考え方によれば、脆弱性をライフサイクルの中でまだ広く知られていない段階にとどめ、安全を保つことでリスクを抑えられます。
この考え方にはいくつか問題があります。まず、善意の人だけが問題を発見したと危険な前提を置いている点です。悪意ある攻撃者も問題を見つけていた場合、組織が問題に気づくまで待つはずはありません。未修正の脆弱性にアクセスできることを利用して攻撃するでしょう。
もう1つの問題は、脆弱性に対処するだけの関心が企業にあることを前提としている点です。実際には、取り組む動機が不足しています。初期には、この方法が脆弱性開示の最も一般的な形でしたが、多くの場合、組織が修正に何年もかかる結果となりました。問題が公表されていないから一定の安全性が保たれる、と考える組織もありました。つまり、無知をセキュリティの層として利用していたのです。
セキュリティ問題による悪評を恐れ、報告しようとした研究者を組織が脅すケースさえありました。残念ながら、今でも時折起きています。そのため、研究者の中には、組織や個人に開示し、その相手から企業に伝えてもらうことを選ぶ人もいます。Snykでは、その対応を喜んで引き受けており、実際に行ってきました。これにより、過度に攻撃的なオーナーや組織から研究者自身を守ることができます。
完全な公開開示
その対極にあるのが、完全な公開開示という考え方です。組織に報告するのではなく、研究者が詳細をすべて公表する方法です。脆弱性は、認知度がゆっくり高まる段階を飛び越え、一気に広く知られることになります。そこからは、組織と攻撃者との競争です。
この方法は、組織が問題に迅速に対処する明確な動機を生み出します。しかし、問題点も明らかです。動機につながるのと同じ公表によって、攻撃者も脆弱性と攻撃方法をすぐに知ることになり、組織とそのユーザーが大きなリスクにさらされます。
適切な開示
その中間に、業界の大半が採用している「責任ある開示」があります。責任ある開示は、いくつかの基本的な手順で進めます。
脆弱性をオーナーまたは組織に非公開で開示する。
脆弱性の修正を作成する。通常はオーナーまたは組織が対応しますが、報告者が支援することもよくあります。
修正を公開し、ユーザーに適用する。
脆弱性を公表する。開示には、脆弱性に関する情報、悪用の方法、問題の修正方法を含めます。
脆弱性を秘密にしておく考え方に似ているように思えるかもしれませんが、重要な違いが1つあります。責任ある開示には通常、妥当な期限が設けられます。
たとえばSnykでは、開示についてパッケージのオーナーに最初に30日間の回答期間を設けています。オープンソース開発では、作者が別の本業を持つことも多いため、これは一般的な期間です。オーナーから回答があった場合は、修正に向けた案内をし、脆弱性を公表する妥当な時期について協議します。これにより、人々が自分自身を守るための措置を講じられるようになります。
理想的には、すべての脆弱性開示がこのように進むべきです。しかし、現実は少し異なり、オーナーから返答がないこともあります。責任ある開示に従う場合、組織が指定された期限内に応答しなければ、報告者は脆弱性を公表できます。そうすれば、ユーザーはリスクを把握し、自分のシステムで受け入れるかどうかを判断できます。また、問題が公になったことで、オーナーや組織が対処を優先する動機にもなります。
Snykでは、オーナーや組織が先手を打てるよう、最善を尽くしています。30日以内に返答がなければ再度連絡し、さらに10日間の猶予を設けます。それでも返答がなければ、もう一度同じ手順を繰り返します。合計で50営業日の回答期間を設けています。その期間中に返答がない場合、またはオーナーが開示の調整を望まないと表明した場合に限り、公表します。
この手順には、注目すべき例外が1つあります。エンタープライズユーザーには、脆弱性がまだ公表されないことを保証する秘密保持契約（NDA）のもとで、早期に通知します。
開示の倫理
2016年、あるサイバーセキュリティ企業が、St. Jude Medicalの医療機器（ペースメーカーや除細動器など）に脆弱性を発見しました。同社は責任ある開示の手順を踏まず、不完全な脆弱性情報を公開した後、別の組織と提携してSt. Jude Medicalの株を空売りしました。
これをきっかけに、責任ある開示をめぐる議論が再燃しました。その企業のCEOは、St. Judeとの過去の経験を踏まえると、責任ある開示は現実的な方法ではないと考えた、と主張しました。
不完全な情報を公開した後に空売りするという、疑わしい倫理面をひとまず脇に置いても、この方法による被害は甚大です。不完全な情報はSt. Judeの評判を損なうだけで、実際の問題の解決には何ら近づきません。むしろ、St. Judeと攻撃者を同じ立場に置き、双方が問題の存在を知り、どちらが先に発見するかを競い合う状況を生み出します。St. Judeが妥当な期間内に対応したかどうかは、今となっては分かりません。そもそも、St. Judeにはその機会すら与えられなかったのです。
セキュリティは興味深い分野です。適切に実践するには、サーバーやアプリケーションにアクセスする人々をある程度疑う必要があります。だからこそ、オンラインのセキュリティを向上させる取り組みでは、信頼に足る、倫理的な行動がいっそう重要になります。
ユーザーを守りながら、組織やオーナーへの被害をできる限り抑える、倫理的で責任ある方法で脆弱性を開示することが不可欠です。私たちは、責任ある開示のプロセスが最適なバランスをもたらすと確信しています。組織に先手を打つ機会を与え、脆弱性を非公開で知らせ、リスクが大きくなりすぎる前に対処する時間を確保できます。
しかも、ユーザーをリスクにさらすことはありません。組織が脆弱性への対応を優先しない場合や、返答がない場合でも、問題が闇に葬られることはありません。脆弱性を公表することで、何も知らないユーザーに問題を知らせ、適切な対策を講じてもらうことができます。
セキュリティの問題を闇に葬ることはできません。脆弱性から学べることは非常に多く、それを見過ごすべきではありません。一方で、組織には脆弱性が公表される前に対処する機会が与えられるべきです。攻撃者に不必要な先手を許さなくても、セキュリティは十分に困難なのです。
Snykにおける脆弱性開示の対応について詳しく知りたい方は、ポリシー全文を こちらからご覧いただけます。開示を支援してほしい脆弱性を発見した場合は、 ぜひご相談ください。