実践セキュリティ監視基盤構築(9): セキュリティ監視基盤で利用するデータ（アラート編）

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の9日目です。

先日に引き続き、セキュリティ監視基盤に取り込むデータの中から、「アラート」について詳しく説明します。今回は特に、セキュリティ監視基盤内で検知するものではなく、外部から取り込まれるアラートに焦点を当てます。

セキュリティ監視基盤における外部アラートの取り扱い

このアドベントカレンダーでの「アラート」とは、セキュリティ上の問題を引き起こす可能性がある事象を指します。セキュリティ監視基盤では、ログを分析したりルールを適用したりしてアラートを生成します。調査の結果、実際の影響があると判断された場合、それをセキュリティインシデントとして扱います。

通常、セキュリティ監視基盤は収集したログからアラートを検知しますが、外部からアラートを取り込むこともあります。わかりやすい例としては、PC上で動作するアンチマルウェア製品やネットワークを監視する侵入検知システム（IDS）が挙げられます。これらの既存のセキュリティ対策ソフトウェアやサービスのアラート検知機能を活用することで、より効率的にセキュリティ監視が可能です。

外部アラートを利用する理由

セキュリティ監視基盤でログを収集して検知するアラートと比べ、既存のセキュリティ対策ソフトウェアやサービスによるアラートを利用するメリットは以下の通りです。

• ✅️ 専門の検知ルールが適用される: IDS/IPSやEDRなどのセキュリティ対策ソフトウェアやサービスは、その分野に特化した検知ルールを持っています。攻撃者やマルウェアの活動に関する長年の調査・研究の結果を反映したルールが作成されており、自分たちでルールを作るよりも高度な検知が期待できます。
• ✅️ 検知ルールが常に更新される: セキュリティ対策ソフトウェアやサービスは、最新の脅威情報を基に検知ルールを更新しています。自分たちでルールを作成する場合、常に最新の脅威に対応しているか確認する必要がありますが、これを利用することでその心配がなくなります。また、精度向上のための更新も行われ、検知精度の向上が期待できます。
• ✅️ ログデータの処理が完結している: セキュリティ対策ソフトウェアやサービスでアラートを検知する場合、ログ収集と検知処理がその中で完結しているため、大量のログをセキュリティ監視基盤に取り込む手間が省けます。また、複雑な検知ルールを自前で実装する手間も省けます。

これらの理由から、セキュリティ監視基盤では、セキュリティ対策ソフトウェアやサービスが検知するアラートを活用するのが良いでしょう。ただし、これらのソフトウェアやサービスではカバーしきれないため、自分たちでの検知も必要です。

• ❌️ 複数のシステムやデータソースを組み合わせた検知: セキュリティ対策ソフトウェアやサービスは、そのソフトウェアやサービスが保護する範囲内での検知しかできません。複数のシステムから得られたログを組み合わせて検知するアラートは、セキュリティ監視基盤で行う必要があります。また、独自のIoC（Indicator of Compromise）を用いた検知もセキュリティ対策ソフトウェアやサービスでは難しいため、セキュリティ監視基盤を活用する方が良い場合が多いです。
• ❌️ 過去のログを遡及する検知: 多くのセキュリティ対策ソフトウェアやサービスは、一定期間内のログを対象にしています。そのため、過去に発生したログに対して新たな情報を基に検知することは難しいです。セキュリティ監視基盤ではログの保全の観点から過去に遡ることが容易で、セキュリティ対策ソフトウェアやサービスとの差別化となっています。
• 🤔 組織内のポリシーに基づく検知: セキュリティ対策ソフトウェアやサービスで用意されている基本的なルールは一般化されているため、組織内のポリシーに基づく検知が難しい場合があります。製品によっては独自のルールを記述することが可能ですが、通常は無視リストを整備する程度の柔軟性しかありません。組織内のポリシーに基づく検知を行う場合は、セキュリティ監視基盤で自分たちでルールを作成・運用する方が便利なケースが多いと考えられます。

外部アラートと内部アラートを統合するべきか？

今回設計したアーキテクチャでは、セキュリティ監視基盤の中で検知したアラートと外部のセキュリティ対策ソフトウェアやサービスが検知したアラートを統合して扱っています。しかし、統合する必要があるのでしょうか？ これは統合する場合、しない場合、それぞれにメリットとデメリットがあります。

• アラートを統合するメリット
  • アラートの集中管理: セキュリティ監視基盤内で検知したアラートと外部のセキュリティ対策ソフトウェアやサービスが検知したアラートを一元管理することで、組織全体のアラートの発生状況がわかりやすくなります。見通しが良くなるだけでなく、集計なども容易になります。
  • 対応ワークフローの一元化: アラートをまとめることで、その後の対応ワークフローも一元化できます。例えば通知をする、追加のメタ情報を収集する、対応者を割り当てる、などの作業を一元的に行うことができます。
• アラートを統合しないメリット
  • 統合にかかるコストの削減: アラートを統合するためには、システム間の接続を実装する必要があります。システム間の接続は通信経路の確保、認証関連の実装、そしてエラー処理などの実装が必要です。これらの実装には手間と時間がかかるため、統合しないことでそのコストを削減できます。
  • 専用のユーザインターフェースの利用: セキュリティ対策ソフトウェアやサービスは、そのソフトウェアやサービスが提供する専用のユーザインターフェースを利用することで、アラートの確認や対応を行うことができるものが多いです。セキュリティ監視基盤に統合することで、その専用のユーザインターフェースを利用する機会が減るため、その利便性を活用しきれないというデメリットがあります。ただしこれは、セキュリティ監視基盤のユーザインターフェースに外部アラートへの導線を用意する（リンクを貼るなど）ことで解消できるかもしれません。

まとめると、アラートを統合するかどうかは、利用しているセキュリティ対策ソフトウェアやサービスの数と運用体制によって判断するのが良いでしょう。使用しているセキュリティ対策ソフトウェアやサービスが少ない場合は、無理に統合せず個別に運用した方が小回りが利くでしょう。逆に、セキュリティ対策ソフトウェアやサービスが多くなると、複数のユーザインターフェースを巡回する必要が出てくるため、手間がかかったり対応が煩雑になったり、あるいは見逃しが発生しやすくなるため、統合を検討するのが良いでしょう。

アラートを検知するセキュリティソフトウェア・デバイス・サービス

セキュリティ監視基盤に取り込むアラートを検知するセキュリティソフトウェア・デバイス・サービスについて紹介します。ただし、すべての製品を網羅するのは難しいため、筆者が代表的であると考えるものに絞ります。これは単純に製品数が多いことや、概念や機能が多様化しているため、カテゴライズが難しいという理由があります。

エンドポイント

• アンチマルウェア: ウイルスやマルウェアを検知するソフトウェアです。ウイルス定義ファイルを定期的に更新することで、最新の脅威に対応できます。また、EDR（Endpoint Detection and Response）と呼ばれる機能を持つ製品もあり、エンドポイント上での不審な挙動を検知することができます。
• EDR（Endpoint Detection and Response）: エンドポイント上での不審な挙動を検知するためのソフトウェアです。主な目的は端末の挙動のログを取得することですが、検知機能を備えている製品も多いです。アンチマルウェアとは異なり、シグネチャベースではなく挙動ベースで検知を行います。そのため、未知の脅威にも対応できますが、誤検知が比較的多い傾向があります。
• MDM（Mobile Device Management）: モバイルデバイスの管理を行うためのソフトウェアです。モバイルデバイスのセキュリティポリシーの適用や、デバイスのロックや消去などのリモート操作が本来の用途ですが、自動的に変更できない設定の問題や、不正なアプリのインストールなどを検知する機能もあり、それらをアラートとして扱うことができます。

ネットワーク

• IDS、IPS (Intrusion Detection System, Intrusion Prevention System): ネットワーク上での不審な挙動を検知するためのソフトウェア・デバイスです。IDSは不審な挙動を検知するだけで、IPSは不審な挙動を検知して遮断することができます。基本的にはパケットのヘッダやペイロードを解析してパターンマッチを行いますが、近年では多くの通信が暗号化されるようになったため、検知が難しくなっています。一方で通信の内容ではなく挙動をベースに検知する製品もあるため、それらを利用できる場面もあります。
• ハニーポット: 不正アクセスを誘導するための罠として設置されたサーバです。本来は攻撃者を誘い込み、攻撃手法などを分析するために利用されますが、設置されたネットワークに本来アクセスが発生し得ない場合、攻撃者がネットワークに侵入した際の偵察活動を検知することができます。

クラウド環境

• Cloud Security Posture Management (CSPM): クラウドプラットフォーム上のセキュリティ設定を監視するためのソフトウェアです。クラウドプラットフォーム上のリソースの設定がベストプラクティスに従っているかどうかをチェックし、不備があればアラートを発生させます。例えば、S3バケットがパブリックになっている、IAMロールに不要な権限が付与されているなどを検知します。
• クラウドプラットフォーム提供のセキュリティ監視サービス: クラウドプラットフォームが主体となって提供しているセキュリティ監視サービスもあります。例えば、AWSのGuardDutyやGoogle CloudのSecurity Command Centerなどがあります。これらのサービスもCSPM同様にベストプラクティスを基に設定のチェックをするだけでなく、クラウドプラットフォームのリソースアクセスやインスタンス上での不審な挙動を検知することも可能です。
• SaaSに付帯するセキュリティ監視サービス: SaaSプラットフォームを提供している企業が、そのプラットフォーム上で不審な挙動があればアラートしてくれるサービスもあります。例えば、Google WorkspaceやEntra IDなどがあります。これらは不審なログインや不審なリソースへのアクセス、不審な権限操作、脆弱と思われる設定などを検知します。

まとめ

セキュリティ監視基盤においては、ログを分析してアラートを検知するだけでなく、既存のセキュリティ対策ソフトウェアやサービスが検知するアラートを活用することで、より効率的にセキュリティ監視が可能です。アラートは別々のシステムで取り扱うこともできますが、最終的には統合して一元管理することをおすすめします。