Unified の包括的な IDPS でセキュリティ リスクを阻止 SASE

Secure Access Service Edge の領域内 (SASE)、侵入検知防御システム (IDPS) の統合はほぼ普遍的です。 その役割は、既知のエクスプロイトを阻止するだけでなく、IOC (侵害の痕跡) の警戒監視役として機能し、包括的な保護層を提供します。IDPS は、より多くの場合、侵害の痕跡と攻撃の痕跡に使用されているとさえ主張します。組織による最近の過去。

IDPS の威力は、ネットワーク トラフィックに関する豊富な洞察を提供する機能にあります。 接続の 5 タプルなどの接続メタデータを抽出するだけでなく、さまざまなプロトコル フィールドの微妙な詳細も掘り下げます。 この抽出の深さにより、ネットワークを通過するデータの特性に関する貴重な情報が得られ、コンテキスト認識が強化されます。

IDPS は複数の方法を使用してネットワーク セキュリティを強化します。 シグネチャベースの検出方法を通じて、既知のエクスプロイトやマルウェアを適切に検出して阻止します。 さらに、不規則なパケットまたはストリーム パターンを識別できるルールを採用することで、異常なデータから保護します。 これらのルールは、異常なプロトコル属性サイズと予期しないプロトコル値の動作を含むようにその範囲を拡張します。

IDPS の機能とセキュリティの有効性は、 SASE フレームワーク サービス プロバイダーによって若干の違いが見られる場合がありますが、通常はサードパーティの脅威インテリジェンス ベンダーから提供されるシグネチャ データベースを利用するため、コア機能はほぼ同様のままです。 さらに、IDPS テクノロジは成熟し、攻撃者が使用する複数の回避手法に直面しても、同様の機能を開発してきました。 私の評価では、プロバイダー間の主な違いは、可観測性の領域と、偽陽性と偽陰性を最小限に抑えることに重点を置いた脅威ハンティングのために提供される機能にあります。

この記事の目的は、IDPS 機能の違いを掘り下げることではありません。 SASE サービス。 むしろ、IDPS 機能が実行されるパケット パス内の正確なポイントを探索しようとします。 SASE サービス、およびこれらの挿入ポイントが元のトラフィック内の攻撃パターンを効果的に検出するかどうか。

Secure Access Service Edge 内のプロキシ レベルで侵入検知防御システム (IDPS) 機能を組み込むという見方もあります (SASE）サービスは十分です。 その根拠は、多くの組織が一般トラフィックでの侵入検出にオンプレミス IDPS をすでに採用しているという事実に基づいています。 OnPrem IDPS の主な課題は、TLS で暗号化されたトラフィックを検査できないことです。 とすれば SASE プロキシは中間者 (MITM) TLS 検査を実行し、暗号化されていないトラフィックへのアクセスを取得します。 したがって、プロキシに IDPS 挿入ポイントを設けることが適切であると考えられています。

さらに、ネットワーク レベル (L3/L4) および TLS レベルの攻撃に対して、かなりの数のシステムに適切なパッチが適用されていると主張する人もいます。 これに応じて、攻撃者はアプリケーション (L7) レベルとデータ レベルでより高度な戦術を採用することに焦点を移しています。 その結果、ネットワーク内のプロキシ レベルを超えて IDPS 機能を拡張しないことは正当であるという考えが広まっています。 ただし、この議論はすべての場合に当てはまります。 古い、更新頻度の低いオペレーティング システムで動作し続ける IoT デバイスを考えてみましょう。 これらのデバイスは依然として広範囲の攻撃に対して脆弱である可能性があるため、包括的なセキュリティ アプローチが必要です。

多くの人もそれを認めています SASE すべてのネットワーク トラフィックを徹底的に検査するために、サービスにはプロキシ レベルと L3 レベルの両方で IDPS が組み込まれることが期待されています。 包括的な攻撃検出を実現するには、IDPS 機能を前述のプロキシ レベルだけでなく、プロキシ レベルでも適用する必要があります。 WAN インターフェイス レベル。トラフィックは、インターネットとの間のトラフィック用に指定されたインターフェイスに出入りします。 このアプローチは、プロキシ レベルのみで IDPS を展開する場合よりも改善されていますが、課題も生じます。 トラフィックがプロキシを経由する場合、IDPS はセッションの両方向の元のトラフィックを認識できない可能性があります。 通常、プロキシは接続を終了し、新しい接続を確立します。 地元に頼っているので、 TCP/IP スタック、元のパケットを再組み立てし、再シーケンスします TCP データ、IP を再作成/TCP オプションを選択し、TLS ハンドシェイク メッセージを再生成します。 その結果、IDPS は WAN インターフェイス レベルでは、内部ネットワークから発信された元のトラフィックに対する可視性が不足している可能性があり、元のトラフィックの一部であった攻撃パターンを見落とす可能性があります。

攻撃者は必ずしも外部にいるわけではないことに注意してください。 内部攻撃者が存在する可能性もあります。 さらに、以前のマルウェア感染により、内部システムから攻撃が発生する可能性があります。 したがって、効果的な脅威の検出と防止のためには、IDPS が元のトラフィックを両方向で一貫して監視していることを確認することが重要です。

Seek SASE 複数の IDPS 挿入ポイントを持つサービス

私たちが提唱するのは、 SASE これらのサービスは、複数のポイントで IDPS を挿入し、すべてを同時にアクティブにする柔軟性を提供します。 組織は、各 L3 インターフェイスおよびプロキシ レベルで IDPS を導入するかどうかを自由に選択できる必要があります。 このアプローチにより、IDPS は、トラフィックが TLS 暗号化されてプロキシを通過する場合でも、セッションのクライアントとサーバーの両方のエンドポイントからの元のトラフィックを検査できるようになります。

さらに、組織は積極的に検索する必要があります。 SASE 複数の挿入ポイントによる重複したアラートとログの生成を回避するサービス。 たとえば、プロキシを経由せず、複数の L3 インターフェイスを通過するトラフィック (XNUMX つのインターフェイスで受信され、別のインターフェイスを介して送信される) は、XNUMX つの IDPS インスタンスで認識される可能性があり、アラートとログの重複につながる可能性があります。 組織は、このようなログの冗長性を最小限に抑え、セキュリティ機能によって生成される大量のログにすでに取り組んでいる管理担当者の殺到を防ぐことをお勧めします。 理想的には、 SASE サービスは、トラフィック セッションごとにインテリジェンスを示し、トラフィックの変更がセッション内で発生しない場合は、重複した IDPS 機能の実行をインテリジェントに回避する必要があります。 SASE サービス。

さらに、組織は、特定のトラフィック セッションについて、さまざまな IDPS インスタンスを含む複数のセキュリティ機能によって生成されたログの相関関係を可能にするソリューションを模索する必要があります。 この相関関係は可観測性の向上に役立ち、セキュリティ イベントのマッピングを簡素化することで脅威ハンターの作業を合理化します。

IDPS の計算集約的な性質を認識し、組織は可能な限りリソースを節約するよう努める必要もあります。 たとえば、組織がすでにホスト IDS (HIDS) またはオンプレミス IDPS を採用している場合、特定の種類のトラフィックの特定のインスタンスで IDPS の非アクティブ化を制御し続けたい場合があります。 SASE ポリシーベースの IDPS ステアリングを提供するサービスにより、組織は、組織内でどのトラフィックが異なる IDPS インスタンスによる検査を受けるかを決定できるようになります。 SASE フレームワーク。

要約すると、IDPS の有効性は次のとおりです。 SASE パラダイムはその機能を超えて拡張されます。 それは柔軟性にかかっています。 SASE IDPS の挿入ポイントと、組織が特定の要件に合わせて調整できる制御の程度について規定しています。

• CTO の洞察ブログ

  　 Aryaka CTO Insights ブログ シリーズでは、ネットワーク、セキュリティ、およびセキュリティに関するソート リーダーシップを提供します。 SASE トピック。 のために Aryaka 製品仕様を参照してください Aryaka データシート。