ゲートウェイのセキュリティ監視に意味はあるのか？

ゲートウェイとは？

ゲートウェイの定義

まず、今回キーワードとして出している「ゲートウェイ」について、本記事の定義をしておきます。
対象の製品カテゴリとしては、下記となります。

• Firewall
• IDS
• IPS
• SWGなどのクラウドゲートウェイ

その他、家庭や小規模オフィスにおいてある、Wi-Fi含むルーターもゲートウェイ製品にあたります。

ゲートウェイの意味は？

製品カテゴリを完全に無視して、ざっくりと書きます。
社内からインターネットの通信であれば、カテゴリフィルタをしたり、マルウェアからの通信をブロックしたりします。
インターネットから社内の通信であれば、攻撃と思われる通信をブロックします。

境界型とゼロトラスト

ゲートウェイセキュリティは、境界型の重要なポイントでありましたが、ゼロトラストになると、少なくともクライアント（PC、スマホ、タブレットなど）はネットワークの外にある。つまり従来までのゲートウェイには含まれないことになります。

もちろん、インターネット上にゲートウェイやプロキシを置く、SWG（セキュアウェブゲートウェイ）を導入されている企業も多いことと思います。

ゲートウェイのセキュリティ監視サービスとは？

お客様環境のFirewallやIDS/IPSのログやアラートを集約し、サービス提供者環境で、セキュリティアナリストが状況把握＝分析を行います。多くの場合、対処までは行われず、通知までの場合が多いと思います。

セキュリティアナリストの「分析」により、よくある逆三角形で説明されますが、最小限の通知で済む、というものです。

では、この「分析」は何をしているのでしょうか。
公開セグメントの場合には、検知したあと、①通信内容を確認、②構成情報などを確認します。例えば、SQLインジェクションを検知した場合でも、通信先にデータベースサーバーがなければ、問題ないと判断できます。次に、③脅威インテリジェンス^*1やIoC^*2と照らし合わせて、どのような影響があるかを確認していきます。

*1 脅威インテリジェンス（Threat Intelligence）：セキュリティの専門家が収集・分析したデータや知見の総称。
*2 IoC（Indicator of Compromise）：システムがサイバー攻撃をされた際に残る指標のこと。マルウェアのファイル名や攻撃先のIPアドレスなど。

内部セグメントの場合でも同じです。①通信内容からマルウェアの通信であるかを確認、②構成情報を確認し、③脅威インテリジェンス/IoCの情報と照らし合わせ、通信先を確認。どのような影響があるかを確認していきます。

より高度な分析をするサービスでは、ゲートウェイ製品で発生したアラートと同じ攻撃を実行し、攻撃が成功するかどうかを確認してくれる場合もあります。本当に必要最低限の通知しかされないわけで、すごく価値を感じます。

公開セグメントの場合には、外部からの攻撃を止める、緩和するといった対応が必要であり、検知してから通知が早いことは、価値があるように感じます。ただ、内部セグメントの場合はどうでしょうか。どの端末からの通信であるかは特定できたとしても、その端末で何が発生しているのか、原因と根本的な対処まではできません。端末側の調査が必要で、ゲートウェイセキュリティに価値がないとはいいませんが、監視までは疑問を感じます。
以降は、内部セグメント、社内からインターネットの通信にフォーカスして進めます。

ゲートウェイのログは何が見えるのか？

ゲートウェイの検知では、通信をブロックした、通信にマルウェアの通信がある、といったことだけで、たいしたことは分かりません。多くの場合、どのファイルが、までは通信上は見えないので、特定も対処もできません（復号した情報からファイル名は把握できる場合もあります）。
インターネットから社内への攻撃の場合、対象のIPアドレスや地域のIPアドレスをブロックする、といった対処が可能ですし、IPSで仮想パッチのような対処もできます。ただ、社内からインターネットへの通信の場合、端末を特定して対処するしかなく、ゲートウェイのログだけでは限界があります。

相関分析なら活きるのでは？

相関分析なら活きるのでは？たぶん活きます。活きますが条件があります。
WindowsやmacOSなどのOSのある場合と、IoTデバイスの場合で分けて考えてみます。

WindowsやmacOSなどの場合

ゲートウェイで検知した場合、端末側に何かが起こっているわけです。何かが起こっている端末を特定して、調査をしたい。よって、下記2つが条件となります。

• 端末にEDRが導入されていること。
• 端末とゲートウェイ製品のログが突合できること。

端末特定したあとは、多くのEDRにはある機能である、脅威ハンティングの機能を利用して、追加調査を行います。
これにより、端末の中のファイル単位、ユーザーの動きといったことまで確認し、そして対処もできることになります。

ただし、ゲートウェイのログは、ユーザー特定できない場合がほとんどです。PaloAlto PAシリーズの場合には、オンプレミスのActive Directoryと連携するUser-ID Agent機能により、ユーザー情報もログに書き込むことができます。
SaaSで提供されるSWG製品の場合は、ログインが必要な場合がほとんどであり、ユーザー特定は可能でしょう。
また、IPアドレスでしか突合できないといった場合も、DNSやEDRのログとの突合は可能とは思われますが、職人技的なところも出てくると思われます。IoT部分で触れますが、NATしていたらより困難になります。

IoTデバイスなどの場合

Windowsなどと同じですが、ゲートウェイで検知するというのは、端末・機器側で何かが起こっているということです。よって、IoTデバイスでも、同じはありますが、下記が条件となります。

• 端末とゲートウェイ製品のログが突合できること。

ゲートウェイのログ、あるあるとして、全部NATされていて同じIPアドレスで端末特定できない、といったことがあります。セキュリティ監視の対象で、端末特定できる必要があります。
端末特定のためだけでなく、残念にも事故が発生したときの被害を最小限に抑えるためにも、業務セグメントと別のセグメントになっている必要はあります。IoTデバイスの場合、EDRの導入はできないことはほとんどであり、対処はネットワークから遮断する、抜線かFirewall側での対処となるためです。

提言：EDRを優先として、補完でゲートウェイの監視をしてはいかがでしょうか？

ここまでのお話で見えてくると思いますが、EDRの情報量が圧倒的に多い。そして、対処もしやすい。ゲートウェイの監視が無意味とはいいませんが、まずはEDRの導入とEDRのマネージドを優先として行い、次にゲートウェイのセキュリティ監視を対応してはいかがでしょうか。
現在のゲートウェイ監視をされている場合は、コストを確認いただき、再検討いただくこともお勧めします。

さいごに

今回は、私個人として、長年のテーマでした。私の「ゲートウェイ監視って意味ないのではないか？」の疑問に対し、きちんと説明できたと思っています。
捉え方によっては既存のMSSPサービスを提供されている会社を敵に回すような記事となってしまいました。ただ、ゲートウェイ監視を否定するわけではなく、より効率的かつ効果的なセキュリティ対策のためであり、さらにセキュリティアナリストの価値向上という意識も持っているので（本当です）、ご理解ください。
セキュリティ事故が発生したときも、最近ではゲートウェイだけでは情報量がなく、EDRを導入して調査することがほとんどです。
まずはEDRをしっかり導入、設定、監視、運用してから、ゲートウェイを補完として使ってみてはいかがでしょうか。

こちらもあわせてご覧ください