OpenSSLへのパッチ適用の時間との闘いが再び始まる

2022年10月31日、Mike Vizard

新しい脆弱性が公開されるときのその方法が変わりつつあります。そのこと自体は称賛されるべきでしょう。先週、OpenSSLプロジェクトの管理者は、とりわけ未知の重要な脆弱性に対処したアップデートを11月1日にリリースすることを発表しました。

ほどなくサイバー犯罪者を含むすべての人が、その脆弱性が何であるかを知ることになるでしょう。しかし、サイバーセキュリティチームにとってこれは、組織が直ちにOpenSSLへの更新プログラムをインストールできるよう準備せよ、という事前警告です。

OpenSSLコミュニティは、Webサイトやアプリケーションで広く利用されているTLS（Transport Layer Security）プロトコルの通信を保護するための暗号化ツールキットの開発を統括しています。最も有名なのは、2014年に発見されたOpenSSLのHeartbleedバグです。このバグを通してサイバー犯罪者は、脆弱なWebサイトやアプリケーションに対して、小さなマルウェアペイロードと大きなlengthフィールドを持つ不正なハートビート要求を送信できるようになりました。

この欠陥の発見が引き起こした混乱は相当なものでした。Heartbleedバグの発見から3年経っても、このバグを悪用した侵害の報告は後を絶ちません。今週公開されるパッチで、多くの企業のセキュリティインシデント対応能力が再び試されることになります。これは、時間との闘いなのです。サイバー犯罪者もまた、今週公開されるであろうOpenSSLの内容について、同じくらい注目していることは間違いないでしょう。

もちろん、脆弱性をどのように公開するかは、多くのサイバーセキュリティの専門家にとって頭の痛い問題です。特にオープンソースのコミュニティは、コミュニティによって維持されているプロジェクトに共通する精神に則って、開示が公に共有されるアプローチを好む傾向があります。しかしここ数年、それはとりわけ困難になってきています。というのも、さまざまなアプリケーションに組み込まれたオープンソースコードの量が飛躍的に増加したためです。多くの IT 組織は、Java アプリケーションからログデータを収集するために広く使用されているオープンソースの Log4J ソフトウェアの脆弱性のすべてのインスタンスをまだ探しています。

プラス面としては、オープンソースのセキュリティ危機が少なくとも無駄になることはないという点です。オープンソースソフトウェアプロジェクトの管理者は、実にさまざまな手段を使うようになっています。コード署名による暗号化もその一つですし、あらゆるコード片のインスタンスがどこで実行されているかを容易に発見できるようにするソフトウェア部品表（SBOM）の自動作成も同様です。

問題は、アクセス可能になった情報をもとに、セキュリティインシデント対応プロセスがどの程度改善されているかということです。ITチームはまず、脆弱性の重大性を判断し、続いて、DevSecOpsのベストプラクティスを適用して最も重要な脆弱性をできるだけ早く修正する必要があります。

今後数カ月の間に、パッチが適用されていないOpenSSLの脆弱なインスタンスに起因するセキュリティ侵害が発生することはほぼ間違いないでしょう。そして、同じくらい明らかなのは、こうしたセキュリティ侵害の発生を防ぐのに必要なアップデートをインストールしなかったことの責任がどこに求められるか、なのです。

原文はこちら
Race to patch OpenSSL is on again
October 31, 2022 Mike Vizard
https://blog.barracuda.com/2022/10/31/race-to-patch-openssl-is-on-again/