利用するデータソースを整理する

監視製品やサービスの検知機能の確認

• セキュリティ監視においてはログを分析してアラートを見つけるだけでなく、製品やサービスが直接アラートを検知してくれるケースもある
  • アラート を参照
• そのデータをあつかう専門家がルールを考え提供してくれるので、なるべく活用する
• 注意点
  • （特に現代において）検知してくれるアラートは日々アップデートされる製品・サービスが多い。変更を追跡できる体制にするか、あるいは変更を受容できる体制にするかのどちらかは必要
  • 検知ができることと調査ができることは別であり、その両方の機能を監視製品・サービスが提供してくれるとは限らない。検知結果に対して調査ができないと「結局よくわからない」で何もアクションできずに終わってしまうため、調査をできるための備えを用意できるかもポイント

検知や調査に利用できるログの確認

要件の整理 よりさらにテクニカルな要件に照らし合わせて、利用可能性を検討する。

検知・調査に利用するログは

• 取得可能か？
  • そもそもログとして出力できるのか
  • プロダクトやサービスとしてログを提供していない、あるいは種類によって取得できないなどがある
  • 契約形態にも依存する
• 収集可能か？
  • 継続的に取得可能か？ 組織内のシステムで検知をする場合は機械的かつ継続的にログを取得しなければならない
  • 遅延の問題
  • 流量の問題
• 保存可能か？
  • ストレージの問題

検知するためのロジックは

• 明確か？
• 計算可能か？

既存の製品・サービス v.s. 内製構築

• このあたりの段階でどちらに進むかを決断する必要がある
• データ検索エンジンを中核とするコンポーネントをどうするか
  • 既存の製品・サービス：主にSIEM（Security Information and Event Manager）
    • 大きく分けて製品（専用のハードウェア、ないし自前で用意したサーバにインストールする）ものとSaaS形式で提供されるものがある
    • SOAR（Security Orchestration, Automation and Response）機能が含まれる場合もある
  • 内製：クラウドプラットフォーム（BigQuery、Amazon Athena）やOSS、あるいは内製アプリケーションを組み合わせて構築