サプライ チェーンのリスクにうんざりしていませんか? 落ち着いて戦略を立てよう！

ソフトウェアに新たな脆弱性が発見されると、セキュリティ業界全体が正気を失います。 OpenSSL も例外ではなく、2022 年 XNUMX 月下旬から XNUMX 月上旬にかけて、XNUMX つの新しい脆弱性がニュース フィードを圧倒しました。発見と開示は、この終わることのない脆弱性サイクルの始まりに過ぎません。 影響を受けた組織は修復に直面していますが、これは IT の最前線にいる人々にとって特に苦痛です。 セキュリティ リーダーは、新しい脆弱性に関するノイズの一部をフィルタリングし、サプライ チェーンへの影響を認識し、それに応じて資産を保護するために、効果的なサイバーセキュリティ戦略を維持する必要があります。

サプライ チェーンへの攻撃は後を絶たない

約 XNUMX 年間で、次のようなコンポーネントの深刻な脆弱性に悩まされてきました。 ログ4j, 春のフレームワーク, OpenSSLの. 古い脆弱性の悪用は、誤って構成された実装や、既知の脆弱な依存関係を使用する実装からも絶えません。 2022 年 XNUMX 月、一般の人々は 連邦文民行政府に対する攻撃キャンペーン (FCEB)、国家が後援するイランの脅威に起因する。 この米国連邦政府機関は、Log4Shell の脆弱性を含む VMware Horizo​​n インフラストラクチャを実行しており、これが最初の攻撃ベクトルとして機能しました。 FCEB は、ラテラル ムーブメント、クレデンシャルの侵害、システムの侵害、ネットワークの持続性、エンドポイント保護のバイパス、およびクリプトジャッキングを含む複雑な攻撃チェーンに見舞われました。

組織は、「そもそもなぜ OSS を使用するのか?」と尋ねるかもしれません。 OpenSSL や Log4j などの脆弱なパッケージによるセキュリティ インシデントの後。 コンポーネントの再利用は、パートナーやサプライヤにとって「ビジネス上の意味がある」ため、サプライ チェーンへの攻撃は引き続き増加傾向にあります。 ゼロから構築するのではなく、既存のコードを転用してシステムを設計します。 これは、エンジニアリングの労力を軽減し、運用を拡張し、迅速に提供するためです。 一般に、オープン ソース ソフトウェア (OSS) は、世間の注目を集めているため、信頼できると考えられています。 ただし、ソフトウェアは絶えず変化しており、コーディングの誤りやリンクされた依存関係によって問題が発生します。 テストと悪用技術の進化を通じて、新しい問題も発見されています。

サプライチェーンの脆弱性への取り組み

組織は、最新の設計を保護するための適切なツールとプロセスを必要としています。 脆弱性管理やポイントインタイム評価などの従来のアプローチだけでは対応できません。 規制により、これらのアプローチが引き続き許可される可能性があり、「安全」と「準拠」の間の隔たりが永続します。 ほとんどの組織は、ある程度の DevOps 成熟度を得ることを目指しています。 「継続的」と「自動化」は、DevOps プラクティスの共通の特徴です。 セキュリティ プロセスに違いがあってはなりません。 セキュリティ リーダーは、セキュリティ戦略の一環として、ビルド、配信、およびランタイム フェーズ全体に焦点を当て続ける必要があります。

• CI/CD で継続的にスキャンします。 ビルド パイプラインを保護することを目指します (つまり、シフト レフト) が、すべてのコードとネストされたコードをスキャンすることはできないことを認識してください。 シフトレフト アプローチの成功は、スキャナーの有効性、スキャナー出力の相関関係、リリース決定の自動化、およびリリース ウィンドウ内でのスキャナーの完了によって制限されます。 ツールは、調査結果のリスクに優先順位を付けるのに役立ちます。 すべての調査結果が実行可能なわけではなく、アーキテクチャで脆弱性を悪用できない場合もあります。

• 配信中に継続的にスキャン: コンポーネントの侵害と環境のドリフトが発生します。 アプリケーション、インフラストラクチャ、およびワークロードは、レジストリまたはリポジトリから供給されてブートストラップされるときにデジタル サプライ チェーンで何かが侵害された場合に備えて、配信中にスキャンする必要があります。

• 実行時に継続的にスキャンします。 ランタイム セキュリティは多くのセキュリティ プログラムの出発点であり、セキュリティ監視はほとんどのサイバーセキュリティの取り組みを支えています。 ただし、クラウド、コンテナ、Kubernetes 環境など、あらゆる種類の環境でテレメトリを収集して関連付けることができるメカニズムが必要です。 実行時に収集された洞察は、以前のビルドおよび配信段階にフィードバックされる必要があります。 ID とサービスの相互作用

• 実行時に公開される脆弱性に優先順位を付けます。 すべての組織は、すべてをスキャンして修正するための十分な時間とリソースを確保するのに苦労しています。 リスクに基づく優先順位付けは、セキュリティ プログラム作業の基本です。 インターネットへの露出は XNUMX つの要因にすぎません。 もう XNUMX つは脆弱性の重大度です。組織は、最も影響が大きいと見なされるため、重大度が高く重大な問題に焦点を当てることがよくあります。 このアプローチでは、エンジニアリング チームとセキュリティ チームのサイクルが無駄になる可能性があります。実行時に読み込まれず、悪用できない脆弱性を追跡している可能性があるからです。 ランタイム インテリジェンスを使用して、実行中のアプリケーションやインフラストラクチャに実際に読み込まれるパッケージを検証し、組織に対する実際のセキュリティ リスクを把握します。

作成しました 製品固有のガイダンス 最近の OpenSSL の狂気に顧客を導くために。

最新の OpenSSL 脆弱性と Log4Shell は、サイバーセキュリティへの備えと効果的なセキュリティ戦略の必要性を思い出させてくれます。 CVE-ID は、公開されているソフトウェアまたはハードウェアの既知の問題にすぎないことを覚えておく必要があります。 多くの脆弱性は報告されていませんが、特に自社製コードの脆弱性や環境設定の誤りが原因です。 サイバーセキュリティ戦略では、最新の設計の分散型で多様なテクノロジーを考慮する必要があります。 ランタイム インサイトを使用してエンジニアリング チームの修復作業に優先順位を付ける、最新の脆弱性管理プログラムが必要です。 また、予期せぬ事態を回避するために、環境全体で信号を関連付ける脅威の検出と対応の機能も必要です。

著者について

Sysdig のサイバーセキュリティ戦略担当ディレクターである Michael Isbitski は、XNUMX 年以上にわたってサイバーセキュリティに関する調査とアドバイスを行ってきました。 彼は、クラウド セキュリティ、コンテナ セキュリティ、Kubernetes セキュリティ、API セキュリティ、セキュリティ テスト、モバイル セキュリティ、アプリケーション保護、安全な継続的デリバリーに精通しています。 彼は、数え切れないほどの組織のセキュリティ イニシアチブとビジネスのサポートを世界中で指導してきました。

研究とアドバイザリーの経験を積む前は、アプリケーション セキュリティ、脆弱性管理、エンタープライズ アーキテクチャ、およびシステム エンジニアリングに焦点を当てた 20 年以上の実践者およびリーダーシップの経験を通じて、IT の最前線で多くの厳しい教訓を学びました。