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

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

今回はセキュリティ監視基盤に取り込むデータのうち、ログについて整理します。ログはセキュリティ監視基盤において重要なデータであり、セキュリティインシデントの検知や調査に利用されます。

ログとは

ログという単語はかなり広い概念として使われますが、ここでは主に以下のようなデータをログとして扱います。

1. システム内で発生したイベントについて記録したデータ
2. システムのある時点での状態を記録したデータ

1は広義でイメージされるログに近いものであると考えられます。アプリややケーションログ、OSログ、ネットワーク機器のログ、セキュリティデバイスのログなどがあります。これらのログは、システム内で発生したイベントやエラー、アクセスログ、認証ログ、アプリケーションの動作ログなどが含まれます。2は、システムの状態を記録したデータで、システムの設定やリソースの状態、ネットワークの状態などが含まれます。プロダクトの状態やアプリケーションの導入状況といったものも、これに含まれます。

セキュリティ監視基盤で利用できるログの種類

では、実際のログの種類について整理します。セキュリティ監視基盤で利用できるログはとても幅広く、ここで挙げているものに限りません。組織によって扱えるデータが異なるため、事情にあわせてログを追加するのも良いでしょう。逆に、ここで挙げているログをすべて取り込まないと行けないということもなく、組織の要件に応じて利用可能であったり、現実的に取り込めるログを選択してください。

組織内サービス

まずは組織内で利用している、主に組織内部向けのサービスです。例えばドキュメント管理、メールサーバ、ファイルサーバ、ワークフローシステム、CRM、ERP、ID管理、ソースコード管理、チャット、オンライン会議、秘密情報管理などがあります。主に組織内部向け、というのは外部の組織との連携などにも利用することがあるためですが、ここでは管理主体が組織内であるものを指します。

• 内部向けSaaS: 内部にサーバーを持たず、クラウドサービスを利用しているサービスを指します。現代では組織内で利用するITシステムの多くがSaaSによって提供されており、完全にSaaSだけで運用されている組織も多いです。SaaSのログは専用のAPIが提供され、こちらから期間を指定してログを取得するという形式が一般的です。ただし、ログ取得のAPIは最上位プランでのみ提供されていたり、そもそもAPIが実装されていないというケースもあるので、事前に確認が必要です。
• 内部運用サービス: 内部にサーバーを設置してその上でソフトウェアを動かして提供するサービスです。OSSを利用する場合もありますし、ライセンスを購入して利用する商用ソフトウェアの場合もあります。ログの取得方法はソフトウェアによって異なりますが、サーバー内のファイルに出力されたり、Syslog 形式で出力されることが多いです。SaaSに比べるとログを取得しいやすいケースが多いですが、それでも目当てのログが出力されないケースもあるので確認は必要です。
• 内製提供サービス: 組織内で開発されたサービスで、主に組織内で利用されることを想定したいわゆる「管理サービス」です。自社内の業務効率化のために開発された既製サービスを補完するものや、自社開発プロダクトに関する管理をするサービスも含まれます。内製なのでログの出力方法については比較的自由度が高いですが、一方でどのような種類のログを、どのような情報とともに出力すればいいのかについては、精査が必要です。

クラウドプラットフォーム

SaaSと似ていますが、クラウドプラットフォーム（Google CloudやAWS、Azureなど）を利用している場合、それらのサービスに関するログも取得できます。これは一般的なSaaSと異なり、さらにログの種類が豊富なので別枠として紹介します。

厳密にはクラウドプラットフォームごとにログの種類や取得方法が異なりますが、大枠として取得出来るログは以下のように整理できます。参考までにGoogle CloudとAWSの該当するサービスも例示します。

• 監査ログ（Cloud Audit Logs、CloudTrail）: クラウドプラットフォームをセキュリティ監視する上で最も重要なのが、クラウドプラットフォーム上のリソースを操作する際の監査ログです。API単位で記録されることが多く、リソースの作成、更新、削除、アクセス権限の変更などが記録されます。クラウドプラットフォーム上の挙動を細かく監視するためには、このログを取得することが必須ですが、一方で非常に多くのログが出力されるため、ログの取得や管理などにおいて細心の注意が必要です。
• リソース設定状況（Cloud Assent Inventory、AWS Config）: クラウドプラットフォーム上のリソースの設定状況を記録するログです。リソースの設定が変更された際にリソースの設定状況を把握することができます。監査ログでもリソースに対する操作が発生したことは分かりますが、詳細な変更内容であったり、変更要求がどのように適用されたのかまでは把握できません。そのため、別途リソース設定状況を記録するログを取得することで、状況把握がより効率的に実施できます。
• ネットワークログ (VPC Flow Logs)：クラウドプラットフォームにおける仮想ネットワーク（VPC, Virtual Private Cloudなど）のネットワークトラフィックを記録するログです。ネットワークトラフィックの送受信元、送受信先、ポート番号、プロトコル、パケット数、バイト数などが記録されます。ネットワークトラフィックの監視や、不正アクセスの検知に利用されます。セキュリティ監視における使い道は主に3つで、(1)外部との不審な通信、(2)異常な振る舞いをするインスタンスの検知、(3)ラテラルムーブメントの追跡、が挙げられます。(1)については比較的利活用しやすいのですが、(2)や(3)については内部から内部のログで非常のログ量が多くなりやすいです。セキュリティ監視の文脈だと網羅性が重要であり、サンプリングして取得すると効果が薄れてしまうため、取得するかどうかやどのポイントを監視するかの判断は精査が必要です。
• WAF、Firewallなどのログ (Cloud Armor Logs, AWS WAF Logs, AWS Firewall Manager Logs)：クラウドプラットフォーム上で提供されるWAF（Web Application Firewall）やFirewallなどのセキュリティデバイスのログです。これらのログは、Webアプリケーションに対する攻撃や、ネットワーク上の不審な通信を検知するために利用されます。WAFやFWのログはセキュリティ監視と密接な関係があるように思えるのですが、ブロックしたログというのは「守備に成功した」という結果のみであり、そこからセキュリティ上の問題を導き出すということはあまりしません。やるとしたらロギングモード（ブロックをしない）で設定したルールで検出されたログを複数統合して分析するという方法が考えられますが、それなりに手間とコストがかかるアプローチになる点に注意が必要です。
• インスタンスのOS・ミドルウェアログ：これらはクラウドサービスではなく、それぞれのインスタンス上から取得するログです。基本的にはオンプレミスと変わりませんが、クラウドの場合はインスタンスの生成、削除が頻繁に起こりやすく、そのライフサイクルに巻き込まれてインスタンス上のログも消えてしまいます。そのため、ログをなるべく低遅延でインスタンス外に集約するような仕組みが必要となることに留意しなければなりません。
• プロセス監視: アプリやコンテナのプロセス実行状況やシステムコールの発行などを監視するログです。クラウド標準でログ出力を備えているサービスは現状なさそうですが、サードパーティのosqueryやFalcoなどが利用できます。プロセスの状態を監視するとなるとログ量も非常に多くなるのですが、ログの内容としては利用できる要素も多いため、監視に条件をつけるなどの工夫をしつつ導入するというアプローチはあります。

自社開発プロダクト

ソフトウェアサービス（特にクラウドで提供する）の会社の場合、自社開発プロダクトに関するログも対象となります。

• アクセスログ: ミドルウェアレベルのアクセスログを指しています。たとえばIstioやEnvoyなどのAPI GatewayやService Meshのログや、データベースのログなどが含まれます。これらはあまり詳細な情報は記録しないことが多いですが、アクセスのトレースや、アクセスの可視化に利用されます。特にHTTP関連のミドルウェアのログは量が膨大になりやすい一方で利用できる場面が限られるため、利用するべきかは検討が必要です。
• 監査ログ: アプリケーション上でのイベントを記録するログです。アプリケーションの内部状態や、ユーザーの操作ログが含まれます。誰がいつどのような行動をしたかを記録することで、不審な行動の検出や問題発生時の調査に活用できます。特に機微な情報を扱ったり、金銭関係の処理が発生するアプリケーションの場合は、監査ログの取得が必須となることが多いです。
• エラーログ: アプリケーションのエラーログは、単純なアプリケーションのデバッグや障害検知に利用されることが多いですが、セキュリティ上の問題を検知したり、調査する目的でも使える場合があります。これは攻撃を受けた場合にその痕跡がエラーとなって表出することがあるためです。ただし、エラーログはプロダクト運用の観点で監視されている場合も多いので、そちらのシステムと連携するなどでも良いでしょう。

自社開発プロダクトに関連したログでは、ログの出力内容に含まれるべきではない情報が含まれないかに注意が必要です。具体的には、個人情報や機密情報、アクセス権限情報などが含まれていないかを確認する必要があります。これらが含まれた状態でログが出力されデータレイクやデータウェアハウスに保存されると、管理措置上の問題が発生する可能性があります。また、後から削除するのもアーキテクチャ上対応が難しかったり、削除後の整合を取るのが難しいなどの問題が発生する可能性があります。そのため、ログの出力内容については、よく検討する必要があります。

オフィス内インフラ

オフィス内のインフラに関するログもセキュリティ監視の対象となります。オフィス内インフラには以下のようなものが含まれます。

• VPN装置: オフィス内のネットワークに接続したり、オフィスネットワーク経由で接続したいサービスへのアクセスを実現するためのVPN装置のログです。VPN装置のログは、VPN接続の成功・失敗、接続元・接続先などが記録されます。VPNは主に外部と内部のセキュリティ境界を超えるための役割を持つため、セキュリティ監視としてはとても重要な意味を持ちます。ただし各種システムがVPNに接続しただけでは利用できず、必ず強固な追加認証を利用していて、VPNはあくまで補助的な立ち位置だった場合、相対的に重要度は下がるでしょう。
• セキュリティデバイス（Firewall、IPS、IDS）: オフィスネットワークの境界に設置して、外部と内部の通信を監視・制御するセキュリティデバイスのログです。Firewallのログは、通信の許可・拒否、通信元・通信先、通信のプロトコル、通信のポート番号などが記録されます。IDS/IPSのログは、ネットワーク上の攻撃や不審な挙動を検知やブロックした際のログです。これらも基本的に、外部から内部に対するインカミングのトラフィックをブロックしたというログはあまり重要ではありません。一方で、内部から外部へのアウトゴーイングのトラフィックに不審な通信が含まれていたかを検証することで、マルウェアの感染などを検出できる可能性はあります。
• スイッチ、ルータ: オフィスネットワーク内の通信を制御するスイッチやルータのログです。スイッチやルータのログは、通信の許可・拒否、通信元・通信先、通信のプロトコル、通信のポート番号などのフローログになります。これらのログは内部ネットワークに不審な挙動をする端末がある場合に、その端末を検知したり、あるいは追跡するために利用されます。ただし、スイッチやルータのログは通信の量が多いため、ログの取得や管理においては注意が必要です。

組織内端末

組織内で貸与している端末は実際の業務に利用されるため、端末によっては強い権限を持つことになります。これらが適切に運用されているか、危険な状態になっていないかを把握するのはリスク監視観点から重要といえます。

• 端末セキュリティソフトウェア: EDR（Endpoint Detection and Response）やアンチマルウェアソフトによるログです。特にEDRによって得られるプロセスやネットワークのログに利用価値があります。EDRによる検知の場合、イベントが発生した瞬間にルールとして持っているIoC（Indicator of Compromise, 過去に観測された攻撃に利用されたことがあるIPアドレス、ドメイン名、ファイルのハッシュ値などの識別子）と照合して、検知したイベントが悪意のあるものであるかを判断します。しかし、イベントの発生後に明らかになったIoCについては後追いでは検知してくれない製品が多いため、EDRのログを取得しておくことで、後から検知できる可能性があります。ただしこれもログの量が多くなりがちなため、取得して活用できるかだけでなく、現実的に技術観点からセキュリティ監視基盤にログを取り込めるのかを確認することが重要です。
• 端末・資産管理ソフトウェア: いわゆるMDM（Mobile Device Management）などを利用して取得した端末の情報をログとして利用します。端末の各種システム設定であったり、端末の状態を記録するログです。特に端末にインストールされているアプリケーションの状態もセキュリティ監視に役立てることができます。

監視ツール・サービスからの脆弱性情報

近年では様々なツールやサービスの登場により、組織内の情報システムや開発プロダクトにおけるセキュリティ上の問題点、すなわち脆弱性を自動的に検知できるようになりました。こうした要素もセキュリティ監視基盤に取り込んで組織内の問題を早期に検知することで、セキュリティを向上させることに寄与します。

• 脆弱性スキャナ: 組織内のネットワークやシステムに対して脆弱性を検知するツールのログです。大きく分けるとネットワークから脆弱なホストを探し出すネットワークスキャナと、ホスト内の脆弱性を検査するホストスキャナがあります。これらは特にオンプレミスのようなネットワークやホストを自前で構築していたり、同じホスト・インスタンスを永続的に使い続けるような環境で効果を発揮します。クラウドの場合は、ネットワークがシステム的に管理されていたり、インスタンスのライフサイクルが短いため、スキャンを有効活用する場面が少ない傾向にあります。
• プロダクト検査ツール: ソフトウェア開発プロセスにおいて、コードの品質やセキュリティを検査するツールのログです。主にコード解析ツールや脆弱性診断ツールがこれに該当します。これらのツールを開発の Continuous Integration (CI) に組み込むことによって持続的にプロダクトの脆弱性の状況を把握できます。具体的なツールとしては以下のような種類のものがあります。
  • SAST (Static Application Security Testing): 静的解析によってコードの脆弱性を検出するツールです。コードの品質やベストプラクティスに従っているかを検査することができます。
  • DAST (Dynamic Application Security Testing): プロダクトを実行して、実際にアクセスしてみることで脆弱性を検出するツールです。
  • パッケージ検査ツール: パッケージマネージャやパッケージリポジトリに登録されているパッケージの脆弱性を検出するツールです。ソースコードやコンテナをスキャンすることで、パッケージに含まれる脆弱性を検出します。

まとめ

セキュリティ監視基盤に取り込むログは、組織内サービス、クラウドプラットフォーム、自社開発プロダクト、オフィス内インフラ、組織内端末など、さまざまなソースから取得することができます。ただしログの取得方法、活用方法、そしてコストなどの問題については組織ごとの要求があるため一概には説明できません。セキュリティ監視基盤を構築する際には、まず要件定義などでログが必要なのかを整理しつつ、現実的な落とし所を考えていくのが重要です。