fbpx

CL LAB

HOME > CL LAB > vShieldによるランタイムでのエクスプロイトの検出と防止 #aqua #コンテナ #セキュリティ #vShield #脆弱性管理

vShieldによるランタイムでのエクスプロイトの検出と防止 #aqua #コンテナ #セキュリティ #vShield #脆弱性管理

 ★ 48

本ブログは「Aqua Security」社の技術ブログで2021年7月7日に公開された「 Detect and Prevent Exploits in Runtime with Vulnerability Shielding 」の日本語翻訳です。

vShieldによるランタイムでのエクスプロイトの検出と防止


コードの依存関係の 1つ に脆弱性があると、アプリケーション全体を危険にさらす可能性があるにもかかわらず、48% の組織が脆弱なコードを承知の上で本番環境に定期的に投入しています。アプリケーションの構築にはオープンソースソフトウェアへの依存度が高いため、無数にある脆弱性へのパッチ適用は非常に困難で時間のかかる作業となっています。コードが持つ脆弱性をタイムリーに修正することが、常に可能だとは限りません。そこで、vShieldを利用し、コンテナイメージで検出された既知の脆弱性から、実行中のアプリケーションを保護します。

ランタイムで脆弱性を緩和するための課題とは

複数の開発チームが、アプリケーションの実行に必要な多くのオープンソースコンポーネント、ライブラリ、パッケージとともに、異なる OS やプログラミング言語を使用してコンテナイメージを定期的に構築します。このように環境が非常に複雑であるため、セキュリティチームは素早いセキュリティリスクの状況の把握とコントロールが困難になります。

さらに、これらのサードパーティコンポーネントへの膨大な依存関係(その多くは開発者が気づいていない可能性があります)により、脆弱性は指数関数的に増加する可能性があります。大規模な環境では、セキュリティチームと開発者は、解析、優先順位付け、修正しなければならない膨大な数の脆弱性のリストを抱えています。優先順位付けされたリストがあったとしても、脆弱性の数が数千に上ることは珍しくありません。これほど多くの問題を手作業で修正するために、クラウドネイティブセキュリティの専門知識を社内で構築することは、非常に困難なことです。

基本的に、アプリケーションの脆弱性に対処する際の選択肢は 3つ しかありません。

社内で問題を修正する

  • 問題を修正するための開発に、時間がかかります。
  • アップグレード、パッチ、または脆弱性のあるコンポーネントを削除するためのコードの全面的な書き換えが必要です。
  • 機能性とセキュリティを確保するための開発作業と完全なテストサイクルが必要です。
  • 適切なランタイムコントロールを適用するために、セキュリティの専門知識が必要です。
  • 修正されるまでは、攻撃される可能性が残ります。

リスクを容認し、アーティファクトを変更せずに使い続ける

  • アプリケーションにおける脆弱性の深い理解と、標準化されたリスクの重大度/スコアが、特定のシナリオにおいては適切だったり、不適切だったりする可能性を受け入れることが必要です。
  • リスクを受け入れる決定の根拠となった脆弱性情報が間違っていた場合や、実運用において追加のリスク要因が発生した場合には、悪用される可能性があります。

ベンダーによる修正を待つ

  • セキュリティリスク対策が、第三者のセキュリティの妥当性や有効性に依存することとなります。
  • 修正はサードパーティの都合で行われます。

従来、修正プログラムは開発者が手作業で行う必要がありましたが、開発者は厳しいソフトウェアリリース期限を守るために非常に多忙です。また実際にはこのような修正は、パッチやアップグレードが利用可能な場合や、脆弱なコンポーネントを省略してアプリケーションをリファクタリングする場合、もしくは脆弱性の緩和要素や代償となるコントロールが実施されている場合にのみ可能です。

vShiledはどのように役立つのか

既知の脆弱性を抱えたまま実行するリスクを低減し、組織がランタイムで脆弱性を容易に緩和できるようにするため、Aqua は修正プログラムが利用できない場合やパッチ適用が実行可能な環境あるいは状況にない場合、脆弱なアーティファクトを保護する Aqua vShield を開発しました。

Aqua vShield は、イメージの再構築やコードの変更、アプリケーションの再デプロイやダウンタイムを伴うことなく、コンテナの脆弱性緩和を自動化します。開発者は、この vShield が脆弱性の悪用に対する代替コントロールとして機能するため、手動で介入して緩和する必要はありません。vShield は自動的に適用できるため、修正の遅れや実行不可能な修正に起因する本番環境のリスクを大幅に軽減できます。

Aqua vShield を支える基本技術の1つである Aqua の脅威インテリジェンスシステムは、各脆弱性に対してアルゴリズムを実行し、潜在的な攻撃ベクターとその結果としての緩和戦略を決定します。例えば、ネットワーク上の特定のポートにアクセスすることで脆弱性を悪用される可能性がある場合、Aqua はそのポート経由のネットワークアクセスを防止することが実行可能な緩和策であると判断します。

そして、そのような行為に対してアーティファクトを事前に保護する Aqua vShield を自動的に生成でき、セキュリティ担当者は上述のランタイムにおける脆弱性緩和の煩わしい作業を回避できます。

Aqua の脅威インテリジェンスシステムからの緩和戦略の一般的な例は以下の通りです。

  1. ネットワーク攻撃一部の脆弱性は、特定のポートを介して悪用される可能性があります。例えば、CVE-2019-11331 では固定のポート番号が必要ないアプリでもポート 123 を使用しています。そのため、リモートの攻撃者がオフパス攻撃を行うことが容易になります。Aqua の脅威インテリジェンスシステムは、これらの脆弱性を発見し、それらのポートへのインバウンドおよびアウトバウンド接続をブロックするコントロールを提供します。
  2. ファイルと実行可能ファイルAqua の脅威インテリジェンスシステムは、脆弱性を悪用するために必要なファイル、ライブラリ、および実行ファイルを発見します。この発見に基づいて、Aqua はこれらのファイルや実行ファイルへのすべてのアクセスを停止することを含む緩和策を提供し、その後それぞれのイベントを監査します。一例として、CVE-2019-6715 があります。sns.php は、攻撃者が SubscriptionConfirmation JSON データの SubscribeURL フィールドを介して、サーバのファイルシステムから任意のファイルを読み取ることを可能にします。
  3. 他の例としては、1.1.23 までの musl Libc に存在する CVE-2019-14697 があります。これは、math/i386/ というファイルの機能が未知であるという重要な脆弱性に分類されており、未知の入力で操作するとメモリ破壊の脆弱性が発生し、データの機密性、完全性、可用性に影響を与える可能性があります。

    以下の例では、これらの脆弱性が musl パッケージに存在するにもかかわらず、Aqua の脅威インテリジェンスシステムは Aqua が脆弱性をブロックして緩和できるように、どのように制御するかを特定しています。

  4. パッケージをブロックAqua vShield がパッケージアクセスを完全にブロックする場合があります。このタイプのコントロールは、より広い範囲を採用しており、特定のユーザ/ロールが関連イベントを通知される監査モードでより有用です。したがって、パッケージの使用を検証し、それに基づいて適切なフォローアップアクションを選択できます。

他のランタイム保護対策ではエクスプロイトを防げないのか

Aqua には DriftPrevention、ネットワーク制御、ファイルおよびボリューム制御、動作許可リスト、ポートスキャンなどの特定の動作を対象とした脅威軽減の制御を含む、複数レイヤーのランタイム制御があります。しかし、これらの制御は特定の CVE に関連付けられていないため、直接的な制御とは見なされず、どの CVE を最初に修正すべきかの優先順位付けには役立ちません。

Aqua vShield は、特定の既知の脆弱性からのリスクを低減し、イメージを再構築することなく、環境のダウンタイムなしに悪用の試みを検出・防止できます。また、パッチの適用に優先順位をつけて自動化するための貴重なツールであり、セキュリティチームが脆弱性を修正する機会を増やせます。

コンプライアンスチームにとって、Aqua vShield は実証可能な機能であり、組織は既知の脆弱性からのリスクを低減する能力を、ソースでの修正能力をはるかに超えて拡大できます。

まとめ


手動による脆弱性の修正だけに頼ると、時間がかかり、エラーが発生しやすく、また効果的に修正するには高度なセキュリティ能力が必要です。それでもコンテナに定期的に組み込まれる脆弱性の量が多い現状では、手動での修正を大規模に行うことは不可能です。Aqua は、自動化された vShield によって組織のこの問題を解決し、緩和要因と補償制御を一貫して繰り返し実施することを可能にします。

Aqua vShield を使用するとセキュリティ管理者はコントロールを維持し、開発者の脆弱性への対応能力やパッチの有無に関わらず、脆弱性が悪用される前に行動するため、必要なすべてを手に入れられます。さらに、コンプライアンスチームと監査人は、セキュリティへの備えを証明する信頼性の高い補償コントロールを手に入れられます。

New call-to-action

CL LAB Mail Magazine

CL LABの情報を逃さずチェックしよう!

メールアドレスを登録すると記事が投稿されるとメールで通知します。

メールアドレス: 登録

※登録後メールに記載しているリンクをクリックして認証してください。

Related post