セキュリティの専門家は、OpenSSL バージョン 3.0 以降で発見された重大な脆弱性について組織に事前開示を行っており、組織への潜在的な影響について多くの人が推測しています。
OpenSSL のプロジェクトチームは、11月 1日火曜日にアップストリームの OpenSSLのセキュリティパッチを発行する予定です。このような事前情報は、パッチが利用可能になる前にどのアプリケーションが脆弱であるかを特定する機会をチームに与えるという点でユニークですが、一方で諸刃の剣でもあります。パッチが利用可能になる前のコードに対して、潜在的な弱点を攻撃するための的を絞った手法を開発する機会を悪者に与えることにもなるからです。従来の責任ある公開プロセスの重要な要素の 1 つは、誰もが平等な立場に立つべきであり、脆弱性の公開は、パッチが作成、検証され、利用可能になった後にのみ行われることが最も効果的だということです。
正式なパッチが発行されるのを待っているわけですが、マルウェアが埋め込まれた偽のバージョンを投稿することで、悪意のある人物がパッチを必要とする組織を食い物にするリスクが高まっています。もちろんこの脆弱性の影響を受ける組織は速やかに作業を開始する必要がありますが、改竄された偽のバージョンの犠牲にならないように用心する必要があります。単一の信頼できるベンダーが存在する商用パッチ プロセスに慣れている組織の場合、OpenSSL のフォークまたはブランチがいくつ存在するかを考えると、このリスクは高いと言わざるを得ません。OpenSSL の配布チャネルも多数ああるからです。
今後のパッチや脅威環境の変化に備えるために、インシデント対応チームが今できることは何でしょうか?
使っているコードを把握する
対応チームは、ソフトウェア・コンポジション解析 (SCA) ツールを使用して、すべてのソフトウェアの解析を実行する必要があります。これには、出所や機能に関係なく、作成、取得、ダウンロード、または使用する、すべてのソフトウェアが含まれます (これには商用およびオープンソース・ソフトウェアが含まれます)。アプリケーションのソース コードにアクセスできない場合は、バイナリファイルに対応した SCAツールをアプリケーションとそのライブラリ使用する必要があります。これらの解析結果には、OpenSSL が使用されている場所、使用されているバージョン、およびそのバージョンの起点がどこにあるかが示されます。ただし、一部の起点は他の起点ほど迅速に応答しない可能性があることに注意することが重要です。これは、緩和策やパッチが準備できる前に脆弱性を開示することが通常禁止される理由の一例です。
パッチと緩和策に備える
運用上、組織は、特定の OpenSSL コンポーネントのプロバイダーがパッチを発行したときにすぐに対応する準備ができている必要があります。理想的には、この脆弱性が公開されたのが 11月 1日（火曜）ですが、この開示が通常の未公表プロセスとは異なっていることを考えると、さらに早い時期になる可能性があります。2014年 4月に発生した悪名高い OpenSSLの脆弱性である Heartbleed の反省から、この問題を解決するために時間をかけている可能性があります。慎重に慎重を期して脆弱性を発見し、パッチがリリースされたときにそれを修正する準備ができている必要があります。
これはまだ解決していない問題です。 BDSA および CVE 情報が利用可能になり、この脆弱性に対する特定の修正が提供され次第、追加のブログ記事を公開する予定です。
Continue Reading
2024 OSSRA レポート：オープンソース・コンポーネントの古いコードのリスク
Apr 17, 2024 / 1 min read
