Zenn
🔎

実践セキュリティ監視基盤構築(6): セキュリティ監視の要件定義（非機能）

2024/12/06に公開
Security
monitoring
tech

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

今回は、セキュリティ監視の要件定義において重要な非機能要件について考えてみます。

非機能要件に対する考え方

セキュリティ監視基盤もシステムの一部であり、設計を考える際には非機能要件が必要です。ただし、セキュリティ監視基盤の特徴として、外部システムと多数連携し、ログやアラートを取り込む特性があります。そのため、非機能要件を定めても、それが実際に適用できるかは連携先のシステムやログの出力能力に依存します。したがって、非機能要件はあくまで目安とし、選択肢がある場合に非機能要件を優先するという考え方が必要です。

また、今回のアドベントカレンダーではセキュリティ監視基盤の設計から実装までを解説しますが、その中で読者が選択できる要件と、すでに設計に考慮されている要件があります。これらを分けて解説します。今回の設計・実装をそのまま取り込む場合、すでに考慮されている要件については再度考える必要はありません。しかし、今回の設計から外れた基盤を構築したり、既製プロダクト・サービスを利用する場合は、それらの要件についても考慮する必要があります。

今回実装するセキュリティ監視基盤で考えるべき非機能要件

まず、今回実装するセキュリティ監視基盤で考えるべき非機能要件について整理します。

ログ分析までの許容遅延

セキュリティ監視基盤は、各システムからログを取り込み、それを検索・集計可能な状態にすることで、初めて分析が可能になります。これは後ほど詳しく説明しますが、大まかに以下のステップが必要です。

  • 各システムからログを取り出す
  • ログを適切な形式・スキーマに変換する
  • ログを検索・集計できるように保存する

いわゆるDWH（Data Warehouse、データ分析基盤）におけるETL（Extract, Transform, Load）そのものの処理となります。DWHでは一般的にある程度データを貯めてから分析をするため、ログ分析までの許容遅延は数時間から1日程度であることが多いです。

一方でセキュリティ監視の文脈では、問題を一刻も早く把握したいというニーズがあります。セキュリティ上の問題の検知は、問題発生から検知までの時間が短いほど、影響を小さくしやすくなります。そのため、セキュリティ監視基盤においてはログに記録される事象が発生してからログ分析できるようになるまでの遅延を、いかに短くするかが求められています。特にシステム側から能動的にログを検索エンジンに直接送信する（プッシュ型）アプローチを取る場合、遅延は数秒程度に抑えることができ、そのようなアーキテクチャがこれまで多く採用されてきました。

しかし近年、いくつかの観点からログ分析は多少の遅延を許容するという考え方も出てきました。以下、その理由をいくつか挙げます。

  • プッシュ型で送信できないログが増えた: 自分たちが管理するアプリケーション、ミドルウェアやOSのログは生成後すぐに転送し、プッシュ型でログを投入することができました。しかしクラウドサービスやSaaSを利用する場合、ログはAPI経由で定期的に取得したり、一定期間ごとにまとめて出力される形式が多くなっており、そもそもプッシュ型で取り扱えなくなっているものが増えています。
  • プッシュ型だと障害対応の負荷が大きい: プッシュ型でログを取り込む場合、ログ送信側、受信側のどちらに障害があってもログの取りこぼしが発生します。そのため、冗長化や障害対応のための負荷が大きくなります。一方で、ログを一旦保存してから分析するバッチ処理の場合、ログの取りこぼしは発生しにくく、障害対応も比較的容易です。
  • 高度な攻撃は一定の遅延がある: 例えば昨今問題となっているランサム攻撃の場合、攻撃を開始してからランサムウェアを展開するまでに数日かかることが多いようです。そのため、ログ分析までの遅延が数時間程度であっても、対応が間に合うことが多いです。逆に機械的な攻撃に対しては、アンチマルウェア製品などの防御的な対策の方が有効であることが多いです。

これらの理由から、ログ分析までの許容遅延は必ずしも数秒のように短くする必要はないと考えられます。とはいえ数日単位での遅れだと影響が出る可能性はあるため、どの程度の遅延を許容する方針にするかは組織内での検討が必要です。

アラート検知のための許容遅延

アラートもログ分析と同様に、検知された事象からアラートが発生するまでの遅延があります。アラートは特にログが分析可能な状態になってから検出できるため、ログ分析の遅延よりさらに時間がかかります。

ログ分析ができる状態になったらすぐにアラート検知ができるかというと、これもアーキテクチャによって制約が起こります。例えばSQLなどでクエリする場合、クエリの発行頻度を上げると検索エンジンの負荷になります。また、BigQueryのように読み込んだデータ量に応じて課金が発生するようなモデルだと、むやみにクエリを発行し続けるとコストがかかりすぎる可能性があります。

したがってこれもログ分析と同様に、アラート検知までの許容遅延を検討し、組織内で合意しておく必要があります。

ログの保全期間

セキュリティ監視基盤に集めたログをどの程度保持するかも重要な要件です。ログを長期間保存することにより、インシデントが発生した場合にもより過去に遡って調査ができるようになります。しかし一方で、ログの保存にはストレージのコストがかかります。特にログが過去のものが積み上がっていくことになるので、時間が経過することでログの総量、そして保存に必要なコスト全体も増えていきます。これはストレージの種類を適切に使い分けることで一定コストを軽減できますが、無制限に保存することはできないため、保全期間をどうするかは検討が必要です。

検討材料の一つとして、侵入した攻撃者がどの程度潜伏しているか、という観点があります。侵入した攻撃者は潜伏期間を長く取ることで、より多くの情報を盗み出すことができますが、その期間中は検知を警戒して派手な行動ができないなどの制約もあります。例えば、Mandiantが出している報告書[1]では、攻撃者が最初の攻撃の痕跡を見せてから実際にランサムウェアを展開するまで、75%のケースが3日以内だったのに対し、最長のケースでは299日であったと報告しています。また、クレジットカード取り扱い業者向けのガイドラインであるPCI DSSでは、ログの保全期間を1年以上とすることが求められています。必ずしもこれに沿う必要はないと考えますが、このような観点から保全期間を検討することは有用でしょう。

もう一つの検討材料が各種法令です。例えば不正アクセス禁止法違反の時効は3年、電子計算機損壊等業務妨害罪の時効は5年です。これは時効が成立するまでは警察による調査が発生したり、訴訟が起きる可能性があることを意味します。その際に調査協力としてログを提出したほうが良い場面が起きる可能性はあります。これは自組織が被害を受けた場合だけでなく、自組織を経由して何らかの攻撃が発生したなどによって加害者として関わってしまうケースも考えられます。

ただしこれらの法令についてはあくまでログが残っていたほうが有利な場面がある、という話であり、ログ保全の義務があるわけではないという点については注意が必要です。先述した通りログの保全自体にも相応のコストがかかるため、無闇に保持期間を伸ばせば良いというわけではありません。あくまでリスクとコストを比較して検討するのが良いでしょう。

独立行政法人情報処理推進機構（IPA）が公開している「企業における情報システムのログ管理に関する実態調査」に関連する法令やガイドラインの情報がまとめられていますので、参考までに掲載します。


IPA 企業における情報システムのログ管理に関する実態調査 64Pより https://warp.da.ndl.go.jp/info:ndljp/pid/11440710/www.ipa.go.jp/files/000052999.pdf


IPA 企業における情報システムのログ管理に関する実態調査 65Pより https://warp.da.ndl.go.jp/info:ndljp/pid/11440710/www.ipa.go.jp/files/000052999.pdf

予算感

一般的には予算感というのは非機能要件には入ってこないと思いますが、（セキュリティ監視基盤に限らず）クラウドプラットフォームを利用したアーキテクチャを考える際にはサービスをどのように使えるかという制約条件として働くため、ここで触れておきます。

クラウドプラットフォームではほとんどのサービスが従量課金制ですが、使い方次第でコストのかかり方が変わります。今回、解説するシステムの中でもっともコストに影響するのは、取得するログの種類および総量とログの保全期間です。ログの種類や総量が多いほど、保全期間が長いほどコストがかかります。そのため、あらかじめどの程度までのコストなら許容できるのかという規模感を予算として事前に関係者間で合意をしておく必要があるでしょう。

今回解説するシステムとは異なるアーキテクチャの場合、さらにコスト感を考慮する必要があります。例えば、ログの処理にPubSubを使う、取得されたログを順次投入して自動分析するオンライン検知システムを構築する、ElasticSearchなどの検索エンジンを並行して導入して分析できる環境を作る、といった選択肢があり、それぞれにコストがかかります。これらは機能要件の範疇にもなりますが、それも踏まえて予算を考慮する必要があるでしょう。

今回実装するセキュリティ監視基盤ですでに考えられている非機能要件

今回実装するセキュリティ監視基盤で検討した非機能要件についても整理します。既製プロダクトやサービスを利用したり、独自の設計をする場合には、以下の要件を考慮することをおすすめします。

各要件をどのように実現したかの詳細については、今後の設計や実装の部分で解説します。

システムの可用性

セキュリティ監視基盤は、セキュリティ上の問題を検知するためのシステムです。なるべく速やかに問題を検知するためには可用性は重要ですが、直接的に売上に影響するようなサービスと違い、ダウンした場合に直接的な損失が発生するわけではありません。そのため、過度な可用性を求める必要はありませんが、運用コストを低減する目的でシステムの可用性を高める設計をすることは有用です。

可用性を考える場合、全体的なアーキテクチャとしてプッシュ型にするかプル型にするかが一つの判断のポイントになります。プッシュ型の場合、ログは送信側のシステムの都合で転送されるため、受信側のシステムがダウンしていたりネットワークの障害が起きるとログを取りこぼす可能性があります。これはシステムの障害だけでなく、受信側のシステムのバッファや保存域の不足によっても起こり得るため、可用性を高めるためには様々な工夫が必要です。
一方でプル型は遅延が大きくなるものの、受信側システムの都合で転送をできるため、送信側のシステムが一時的にダウンしていたり、ネットワークの障害が起きてもログを後から取得できます。

システムの拡張性

セキュリティ監視基盤は、新たなログソース（ログを提供できるシステムとの接続）を追加することで機能を拡張できることが重要です。新たなログソースを追加することで、調査や検知の対象範囲が広がります。このログソースを追加する際に、いかに容易に追加できるかが拡張性のポイントになります。

ログソースの追加が容易であるためには、以下のような要件が考えられます。

  • ログ取得のワークフローの独立性: 例えばあるログソースを追加に伴い別のログソースの取り込みに影響があるとすると、そのログソースが適切に追加できるかどうかの検証などが必要になります。また、プッシュ型の取り込みの場合、受信側のシステムがボトルネックとなりやすく流量を増やすと他のログソースの取り込みに影響が出る可能性があります。最終的にはログを集約するのでどこかでワークフローは合流しますが、なるべく独立性を高めることで、ログソースの追加が容易になります。
  • ログ取得方法の自由度: セキュリティ監視に使われるログは様々なシステムから収集します。メジャーなプロダクト・サービスから取得する場合、既製のセキュリティ監視プロダクト・サービスではログ取り込みをサポートしている場合が多いです。しかし独自に開発したアプリケーションなどからログを取り込むためには、自前でログ取り込みの仕組みを作る必要があります。ここのログ取り込み方式をいかに柔軟にするかが拡張性のポイントになります。取り込みの際には、ログの取得方法（プッシュ型、プル型）、ログのフォーマット（JSON、CSV、syslogなど）、スキーマの指定方法などが柔軟に設定できると良いでしょう。

検知ルールの保守性

セキュリティ監視基盤において検知ルールの保守性は、見落とされがちですが重要な要件です。検知ルールは、ログからセキュリティ上の問題を発見するためのルールです。検知ルールは一度定めたらそのまま使い続けるかと思われることが多いですが、実際には頻繁に変更します。検知ルールを変更するタイミングは以下のようなものが考えられます。

  • 新たな脅威の検知: 新たな脅威を検知するために、検知ルールを追加することがあります。脅威が増えるのは、新たな攻撃手法が発見された場合や、システムの構成が変わって脅威分析の結果に影響がでた場合などです。
  • 誤検知の修正: ルールを用いて検知をする場合、必ず誤検知が発生します。これは主に、あらかじめ設定した検知ルールの想定外の事象が発生した場合に発生します。誤検知を減らすためには、検知ルールを修正する必要があります。
  • 組織ポリシーの変更: 組織内のシステム運用ポリシーが変更された場合、そのポリシーをを拠り所として設定していた検知ルールは変更する必要があります。
  • ログソースの追加・変更: 新たなログソースを追加する場合、そのログソースに対応する検知ルールを追加する必要があります。また、ログソースから取得できるログが変更した場合にも、検知ルール側で対応する必要がでてくる場合があります。

これらの変更を行う際に、検知ルールの保守性が高いほど変更が容易になります。検知ルールの保守性を高めるためには、以下のような要件が考えられます。

  • テスト可能性: 検知ルールを変更した際に、その変更が正しく動作するかどうかをテストすることが重要です。変更対象のルールだけでなく、他のルールに影響がないかどうかもテストする必要があります。そのため、検知ルールのテストが容易にできる仕組みを持つことが重要です。
  • 変更履歴の管理: 検知ルールの変更履歴を管理することで、現状のルールが設定された経緯や、過去のルールに戻す際に参考になる情報を残すことができます。これにより新たな変更を加える際に、過去の事情を考慮したうえでの変更が可能になります。
  • 検知ルールの分離: 検知ルールを分離することで、検知ルールの変更が他のルールに影響を与えにくくなります。検知ルールの分離は、検知ルールの保守性を高めるために重要です。
  • 検知ルールの構造化: 類似の検知ルールが複数あるような場合、ルールに関するデータやロジックを共通化したり、うまくまとめることでルール全体の可視性を高めることができます。可視性が高まることでルール変更のための認知負荷が減り、保守性が高まります。

まとめ

セキュリティ監視基盤の設計においては、非機能要件も重要です。今回はログ分析までの許容遅延、アラート検知のための許容遅延、ログの保全期間、予算感についてどのように考えるかをまとめました。次回からはいよいよ設計の解説に入ります。

脚注

  1. They Come in the Night: Ransomware Deployment Trends https://cloud.google.com/blog/topics/threat-intelligence/they-come-in-the-night-ransomware-deployment-trends/?hl=en ↩︎

Discussion