セキュアアクセスサービスエッジ（SASE）の領域では、侵入検知防御システム（IDPS）の統合はほぼ一般的です。 その役割は、単に既知のエクスプロイトを阻止するだけでなく、IOC（侵害の指標）を警戒するセンチネルとして機能し、包括的な保護レイヤーを提供します。 最近の組織では、IDPSが侵害の指標（Indicators of Compromise）や攻撃の指標（Indicators of Attack）としてより多く使用されているとさえ言えるでしょう。 IDPSの威力は、ネットワーク・トラフィックに対する豊富な洞察を提供する能力にあります。IDPSは、接続の5タプルのような接続メタデータを抽出するだけでなく、さまざまなプロトコル・フィールドの微妙な詳細まで掘り下げます。 この抽出の深さによって、ネットワークを横断するデータの特性に関する貴重な情報が得られ、文脈認識が強化されます。 IDPSは、ネットワークセキュリティを強化するために複数の方法を使用します。 シグネチャベースの検出方法により、既知のエクスプロイトやマルウェアを効率的に検出し、阻止します。 さらに、不規則なパケットやストリームのパターンを識別するルールを採用することで、異常なデータから保護します。 これらのルールは、プロトコルの異常な属性サイズや予期しないプロトコル値の動作を包含するようにその範囲を拡張します。 SASEのフレームワークにおけるIDPSの機能とセキュリティ効果は、サービスプロバイダーによって若干の違いがあるものの、サードパーティの脅威インテリジェンスベンダーから一般的に提供されるシグネチャデータベースを利用することにより、中核となる機能はほぼ同様です。 さらに、IDPS技術は成熟し、攻撃者が採用する複数の回避テクニックに直面しても、同様の機能を開発しました。 私の評価では、プロバイダー間の主な差別化は、観測可能性の領域と、偽陽性と偽陰性を最小限に抑えることに焦点を当てた脅威ハンティングのために提供する設備にあります。 この記事の目的は、SASEサービス間のIDPS機能の差別化について掘り下げることではありません。 むしろ、IDPS機能がSASEサービスによって実行されるパケットパス内の正確なポイントを探り、これらの挿入ポイントが元のトラフィック内の攻撃パターンを効果的に検出するかどうかを探ります。 セキュア・アクセス・サービス・エッジ（SASE）サービスのプロキシレベルに侵入検知防御システム（IDPS）機能を組み込めば十分だという考え方もあります。 その根拠は、多くの組織がすでに一般的なトラフィックに対する侵入検知のためにOnPrem IDPSを採用しているという事実に起因しています。 OnPrem IDPSの主な課題は、TLSで暗号化されたトラフィックを検査できないことにあります。 SASEプロキシはMITM（Man-in-the-Middle）TLSインスペクションを行うため、暗号化されていないトラフィックにアクセスすることができます。 したがって、IDPSの挿入ポイントをプロキシに置くことは適切であるとの考えです。 さらに、ネットワークレベル（L3/L4）やTLSレベルの攻撃に対しては、かなりの数のシステムに十分なパッチが適用されているという意見もあります。 これを受けて、攻撃者はアプリケーション（L7）レベルやデータレベルでより巧妙な手口を用いることに重点を移しています。 そのため、IDPSの機能をネットワーク内のプロキシレベル以上に拡張しないことが正当化されるという考え方が一般的です。 しかし、この議論はすべてのケースで通用するわけではありません。 更新頻度の低い古いオペレーティング・システムで動作し続けるIoTデバイスについて考えてみましょう。 これらのデバイスは、より広範な攻撃に対して脆弱なままである可能性があり、包括的なセキュリティ・アプローチが必要となります。 また、SASEサービスが、すべてのネットワーク・トラフィックを徹底的に検査するために、プロキシとL3の両方のレベルでIDPSを組み込むことが期待されていることも、多くの人が認めています。 包括的な攻撃検知を実現するためには、IDPS の機能を、先に説明したプロキシ・レベルだけでなく、インターネットとのトラフィック用に指定されたインターフェイスにトラフィックが出入りする WAN インターフェイス・レベルにも適用する必要があります。 このアプローチは、IDPSをプロキシレベルのみで展開するよりは改善されるものの、課題が生じます。 トラフィックがプロキシを経由して流れる場合、IDPSはセッションの両方向の元のトラフィックを可視化できないことがあります。 プロキシは通常、接続を終了し、新しい接続を確立します。 ローカルのTCP/IPスタックに依存しているため、元のパケットを再組み立てし、TCPデータを再シーケンスし、IP/TCPオプションを再作成し、TLSハンドシェイクメッセージを再生成します。 その結果、WAN インターフェース・レベルの IDPS では、内部ネットワークから発生した元のトラフィックに対する可視性が欠落し、元のトラフィックの一部であった攻撃パターンを見落としてしまう可能性があります。 攻撃者は必ずしも外部とは限らず、内部攻撃者もいる可能性があることは注目に値します。 また、過去にマルウェアに感染したことが原因で、内部システムから攻撃が発生することもあります。 したがって、効果的な脅威の検出と防止を行うには、IDPSが双方向の元のトラフィックを一貫して観測することが極めて重要です。

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

私たちは、SASEサービスが、IDPSを複数のポイントに挿入する柔軟性を提供することを提唱しています。 組織は、各L3インターフェイスとプロキシレベルでIDPSを展開するかどうかを自由に選択できるべきです。 このアプローチにより、IDPSは、トラフィックがTLSで暗号化され、プロキシを経由している場合でも、セッションのクライアントとサーバーの両方のエンドポイントから元のトラフィックを検査することができます。 さらに、組織は、複数の挿入ポイントに起因する重複したアラートやログの生成を回避するSASEサービスを積極的に探すべきです。 例えば、プロキシを経由せず、複数のL3インターフェイスを通過するトラフィック（あるインターフェイスで受信し、別のインターフェイスで送信）は、2つのIDPSインスタンスで確認される可能性があり、重複したアラートやログにつながる可能性があります。 組織としては、このようなログの冗長性を最小限に抑え、すでにセキュリティ機能によって生成された大量のログに対処している管理担当者に負担がかからないようにすることが望ましい。 理想的には、SASEサービスは、トラフィックセッション単位でインテリジェンスを発揮し、SASEサービス内でトラフィックの変更が発生しない場合、IDPS機能の重複実行をインテリジェントに回避する必要があります。 さらに、組織は、特定のトラフィック・セッションについて、さまざまな IDPS インスタンスを含む複数のセキュリティ機能によって生成されたログの相関を可能にするソリューションを求める必要があります。 この相関関係により、観測可能性が向上し、セキュリティ・イベントのマッピングが簡素化されるため、脅威ハンターの作業が効率化されます。 IDPSの計算集約的な性質を認識した上で、組織は可能な限りリソースを節約するように努めなければなりません。 例えば、組織がすでにホスト IDS（HIDS）やオンプレム IDPS を採用している場合、特定のタイプのトラフィックについて、特定のインスタンスで IDPS を停止する制御を保持したい場合があります。 ポリシーベースのIDPSステアリングを提供するSASEサービスは、組織がSASEフレームワーク内の異なるIDPSインスタンスによって検査を受けるべきトラフィックを指示することができます。 要約すると、SASEのパラダイムにおけるIDPSの有効性は、その機能だけにとどまりません。IDPSの挿入ポイントに関してSASEが提供する柔軟性と、組織の特定の要件に合わせるためのコントロールの度合いによって決まります。

  • CTOインサイトブログ

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