サプライチェーンセキュリティによるゼロデイ攻撃対策 #aqua #セキュリティ #ソフトウェアサプライチェーン #sscs
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2023年3月2日に公開された「 Zero-Day Attack Prevention Through Supply Chain Security 」の日本語翻訳です。
サプライチェーンセキュリティによるゼロデイ攻撃対策
SolarWinds 社の侵害事件などのおかげで、サプライチェーンセキュリティがここ最近話題として取り上げられました。この事件や同様の事件は、脆弱なソフトウェアコンポーネントを利用するゼロデイ攻撃に対し、戦略を持つことの重要性を強調しています。
私は EMEA パートナーマネージャーの Teresa Pepper 氏と一緒にウェビナーを開催しました。彼女と私は、次のような洞察を共有しました。
- ソフトウェアのサプライチェーンで発生する主な課題
- その課題がどのようにゼロデイ攻撃につながるか
- 企業が安全を確保するためにできること
ウェビナー「How to Remediate Zero Day Attacks 3x Faster」をご覧ください。以下、重要なハイライトとキーポイントに触れます。
サプライチェーンセキュリティの課題
ソフトウェアサプライチェーンセキュリティは、新しい課題ではありません。開発者がソフトウェアの構築を支援するためにサードパーティーのコンポーネントに依存している限り、存在するものです。しかしウェビナーで説明したように、近年ソフトウェア開発において、自動化への大規模なシフトが起きています。今日の開発者は、開発パイプラインを可能な限り自動化を進めようとしています。
その結果、アプリケーションに脆弱性が入り込みやすくなっています。開発者は、コードベースへ追加する際に、ソフトウェアサプライチェーン内のすべてのリンクを手作業で検証することができます。しかし、自動化ツールがさまざまなソースからソフトウェアを取り込んで統合すると、安全でないコードが制御をすり抜けるリスクが高まります。
さらにTeresa 氏が言うように、現実としてセキュリティ課題の優先順位争いもあるため、ソフトウェアサプライチェーンにおける潜在的な脆弱性が、攻撃が発生するまで後回しにされるシナリオも十分にあり得ます。セキュリティリーダーはサプライチェーンのリスクを認識しており、コードをパイプラインへ入れる前の段階で、信頼できるようにしておくことが重要だと理解しています。また、安全なサプライチェーンは、セキュリティ事故の減少や顧客との信頼関係の構築につながるため、企業の競争優位につながることも知っています。しかし、セキュリティ上の課題が山積する中、サプライチェーンのリスクを管理する能力は限られています。
ゼロデイ攻撃
サードパーティ製ソフトウェアの脆弱性によってもたらされる脅威が、さらに先の現実的なリスクに発展しなければ、サプライチェーンセキュリティの心配をする必要はそれほど無いでしょう。
残念ながら、安全でないモジュール、依存関係、その他のサードパーティ製ソフトウェアリソースの統合は、すぐに特定し、是正しなければ、ゼロデイ攻撃につながる可能性があります。ゼロデイ攻撃とは、通常は既知の悪用テクニックを利用して、攻撃者がすぐに実行できる攻撃のことです。
この意味で、サプライチェーンのセキュリティリスクは特に脅威となります。ソフトウェアの設定ミスなど他のタイプのセキュリティリスクとは異なり、攻撃者は特定の悪用テクニックを慎重に調査した上で悪用するため、効率的にターゲットを絞ったサプライチェーン攻撃が可能になります。
このため、企業はサプライチェーンの脆弱性には特に注意する必要があります。賢い企業は、ゼロデイ脆弱性に注目することを心得ています。もちろん、その他の一般的なリスクを管理することも重要ですが、ゼロデイ脆弱性の潜在的な深刻さとは比較になりません。
ゼロデイ攻撃対策の実装
これが正に課題です。企業はどうすればいいのでしょうか。
ゼロデイ攻撃対策の導入が課題となっている中、企業は既存のツールの限界を認識する必要があります。従来のツールがゼロデイ脅威に効果的に対処できていたからと言って、ソフトウェアのサプライチェーンに誤った安心感を持つことは避けなければなりません。コスト、情報のサイロ化、ツールの不完全な導入などに関連する問題は、完全なサプライチェーンの防御を弱めてしまう可能性があります。
その典型的な例が、Log4j で発覚した脆弱性で、世界中の何千もの企業にゼロデイ攻撃のリスクをもたらすことになりました。Log4j に対応するため、セキュリティチームは自社のソフトウェアパイプラインをスキャンして、安全でないバージョンのライブラリが含まれていないかどうかを判断する必要がありました。しかし、これらのスキャンがアプリケーションの未展開バージョンにのみ適用されるのであれば、本番環境における安全でない Log4j の実装を、必ずしも検出できなかったでしょう。むしろ、開発リリース内のリスクのみを検出することになります。
さらに、スキャンによって Log4j の脆弱性が検出されたとしても、すぐに修正プログラムを実行できませんでした。サプライチェーンのリスクに対して効果的な改善策を講じるには時間がかかり、遅ければ遅いほど攻撃される可能性は高くなります。
ゼロデイ攻撃に対するより良いアプローチは、Cloud Native Application Protection Platform (CNAPP) を通じて提供されるような、全体的なセキュリティ保護を採用することです。これによって、企業は以下を達成できます。
- サプライチェーンセキュリティを開発から本番までに幅広く展開し、開発および運用内の脆弱性をキャッチして対応できます。
- クラウドセキュリティポスチャー管理 (CSPM) は、サプライチェーン脆弱性を顕在化することで、安全でない構成の検出に役立ちます。
- クラウドワークロードプロテクションは、ワークロード単位でサプライチェーンのリスクに対する防御を強化します。
職場におけるサプライチェーンセキュリティ：事例
CNAPP によるアプリケーション保護の実例として、Aqua Security の顧客である FinTech 企業が、200 億ドルの収益源をサイバーセキュリティ攻撃から保護するために CNAPP ソリューションを採用した事例があります。このソリューションを採用する前、この企業は基本的なコードスキャンと CSPM の保護機能を備えていましたが、ワークロードの保護機能が欠けていました。さらに、セキュリティオペレーションとデータソースがサイロ化されていました。その結果、ゼロデイリスクにさらされるサプライチェーンの脆弱性の特定と対応ができなかったのです。
しかしCNAPP を導入することで、同社はセキュリティを一元化し、合理化できました。CNAPP によって、サプライチェーンのリスクが実際のワークロードにどのように影響するかを容易に理解できるようになり、脆弱性が検出された場合、より迅速かつ費用対効果の高い対応ができるようになりました。
ゼロデイ攻撃対策をより活用するための工夫
CNAPP の導入を成功させる可能性が高いのは、どのような要因でしょうか。また、サプライチェーンのセキュリティを補完するために利用できるオープンソースツールは何でしょうか。
サプライチェーンのゼロデイ脆弱性という現実的で差し迫った課題について、次の SolarWinds 社や Log4j の事故からビジネスを保護する方法については、ウェビナー「How to Remediate Zero Day Attacks 3x Faster」を参照してください。
